Важность технического задания при разработке ПО
ТЗ является ключевым документом при разработке программного обеспечения. Его основная цель — четко и подробно описать требования и ожидания заказчика, а также определить функционал, архитектуру и технологии, которые будут использоваться в процессе разработки.

Что дает техническое задание:

Используем таблицы, когда это актуально. Таблицы обеспечивают более ясное и структурированное представление информации.

Пример использования таблицы в техническом задании

Схематичное изображение процессов. Когда необходимо визуализировать процессы, взаимодействие компонентов или потоки данных в ПО, добавляем схемы или диаграммы. Это помогает наглядно представить логику работы системы и улучшить понимание требований.

Пример использования схемы работы в техническом задании

Повышение эффективности. Хорошо структурированное ТЗ с активной внутренней перелинковкой значительно повышает эффективность рабочего процесса команды разработчиков, уменьшая время на поиск и анализ информации и упрощая процесс принятия решений.


Внутренняя перелинковка в техническом задании.

Язык написания технического задания
При написании ТЗ используем классический русский язык, избегая специфических слов и профессионального жаргона. Наша цель — создать понятный и доступный документ, который будет понятен всем участникам проекта, включая заказчика, разработчиков и других заинтересованных сторон.

Исходим из того, что ТЗ должно быть доступным для понимания для всех независимо от уровня технической экспертизы. Стремимся к простоте и ясности, чтобы любой человек владеющий русским языком мог легко понять и согласовать требования и функциональность ПО.

Такой язык написания ТЗ способствует более эффективной коммуникации и сотрудничеству между всеми участниками проекта. В результате получается документ, который ясно передает задачи и требования, а также служит основой для успешной разработки программного обеспечения.

Уровень образования для чтения ТЗ
Уровень образования не является определяющим фактором для чтения технического задания. Главным критерием является нормальный уровень владения русским языком и желание вникнуть в суть ТЗ.

Роль ТЗ при оценке стоимости разработки ПО
При оценке стоимости ПО разработчики и специалисты в области проектного менеджмента изучают ТЗ, чтобы полностью понять объем работы, требуемые ресурсы и сложность проекта. Они анализируют функциональные и нефункциональные требования, описанные в ТЗ, и определяют, какие задачи и этапы разработки требуются для достижения поставленных целей.

ТЗ помогает оценить затраты на разработку ПО, такие как трудозатраты, необходимость специфических навыков, использование сторонних ресурсов или инструментов. Оно предоставляет основу для определения временных рамок и планирования ресурсов, позволяет провести оценку бюджета проекта.

Благодаря детальности и структурированности ТЗ, команда разработчиков может провести точную оценку стоимости ПО. ТЗ дает возможность разбить проект на отдельные задачи, определить зависимости и риски, а также учесть дополнительные факторы, которые могут влиять на стоимость разработки.

Примеры технических заданий:

	ТЗ на разработку онлайн сервиса бронирования чартерных рейсов
	ТЗ на разработку системы учета клиентов (лидов) торговой компании)
	ТЗ на разработку системы управления торговой компании (управление складским комплексом)
	ТЗ на разработку системы управления транспортной компании
	ТЗ на разработку системы управления программой гармонизации нейро-активности

Если проанализировать историю человечества, главной движущей силой была и остается польза. Моисей организовал исход из Древнего Египта; Колумб поплыл пошел в Индию и случайно открыл Америку; Джобс разработал Макинтош — всё ради пользы.

Деньги полезны, но польза — это не деньги. Деньги это последствие полученной пользы. Мы помогаем достичь пользу, совершаем полезное действие. Вы приобретаете не набор механических действий, а билет в точку где необходимая польза у вас уже есть.

Мы можем многое, но не все. Прежде чем пообещать — изучаем задачу, считаем. Стоимость зависит от достижимости пользы, но стоит ли польза этих денег — решает клиент.

Польза и проект — не одно и тоже. Часто, чтобы реализовать проект нужно выполнить несколько итераций. Результат выполнения каждой итерации — пусть небольшая, но польза. Только так, иначе пропадает всякий смысл.

Flex по-английски — гнуть. Иногда бывает так, что лучше «подогнуть» проект, но сдать в срок и в рамках бюджета, чем продолжать жить без реализованного проекта. Если польза от запущенного проекта важнее некоторых неудобств, лучше флексить.

Николай Товеровский из Бюро Горбунова проделал большую работу — выделил и описал приёмы флекса (за что ему большое спасибо). Представляю «выжимку» из его работы со ссылками на статьи.


Виды флекса:

1. Зафиксировать

Часть системы делается статичной, её невозможно изменять или настраивать, поведение определяется заранее запрограммированным алгоритмом.
Подробнее

2. Снизить управляемость

Систему делают менее управляемой, но не жертвуют качеством и работоспособностью.
Подробнее

3. Уменьшить глубину проработки

Работа ведётся только над тем, что необходимо для решения задачи.
Подробнее

4. Рассогласовать

Изменяют только необходимую часть системы, игнорируя рассогласование с другими частями.
Подробнее

5. Убрать в гаражик

Неблаговидная часть системы прячется так, чтобы не портила вид.
Подробнее

6. Заменить решение

Если решение не подходит или его невозможно реализовать в срок, замените решение на другое.
Подробнее

7. Не выходить в надсистему

Решение не затрагивает других частей системы.
Подробнее

8. Отступить от идеала

Если реализовать идеальное решение невозможно или нерационально, отступите на шаг назад.
Подробнее

9. Перенести на следующую итерацию

Часть функций откладывают на потом.
Подробнее

Сделать говно

Сделать говно — это не пофлексить.
Подробнее

Флексить — больно. Если есть возможность обойтись без флекса — лучше её использовать. Если же поджимает время или ограничен бюджет, приходится флексить. Такова суровая реальность.

Лучше синица в руках, чем журавль в небе. Мы помним, что такой инструмент как флекс существует и умеем им пользоваться.

Обращаясь к пользователю со страниц сайта, мы обладаем ограниченным арсеналом инструментов. Сейчас можно использовать видео, аудиозаписи, изображения, анимацию, иконки. Но без текста не может обойтись практически ни одна страница.

Текст — важнейшая составляющая веб-дизайна. Часто этот компонент недооценивают, в том числе благодаря стереотипу «писать умеют все». На самом деле — все умеют сложить из букв услышанное или то, что хотели сказать. Но донести мысль, вложить её в голову, вызвать нужные эмоции, побудить на действия — могут далеко не все.

Написание текстов и редактура — наука и ремесло. Можно брынчать на гитаре по праздникам когда собираются гости, а можно играть профессионально и зарабатывать этим на жизнь. Никто не запрещает дурачиться на дружеской вечеринке, но на ответственное мероприятие лучше звать профессионалов.

Существуют разные стили языка, которыми пользуются исходя из функций текста. Есть разговорный стиль. Юристы пользуются официально-деловым. Диссертации пишут научным стилем, а романы — художественным. В интернете все сначала писали кому как вздумается. Но когда появилась возможность заработать с помощью сайта, стали думать — как писать, чтобы доверяли написанному.

Появился информационный стиль. Вообще, этот стиль существовал в журналистике и раньше, но обрел новый смысл. Методы и правила применения информационного стиля структурировал Максим Ильяхов, они изложены в книге «Пиши, сокращай».

Если коротко, тексты в информационном стиле не навязывают мнение и настроение. У них нет цели загипнотизировать пользователя или манипулировать им. Информационный стиль не ставит своей целью заискивать с посетителем, или развлечь его. Инфостиль объективно, точно и лаконично доносит информацию «как есть». Автор неформально и однозначно информирует пользователя и помогает принять взвешенное решение. Причем, взвешенное решение может быть «не покупать». Принимать решение — дело посетителя, решение зарождается внутри его головы, а не навязывается вычурным текстом.

Это сжатое представление об информационном стиле. Если бы я мог описать его принципы на одной странице — Максиму Ильяхову не пришлось бы много лет собирать материал и писать книгу. Если хотите углубиться в тему — изучите справочник Главреда или прочитайте упомянутую книгу.

Взглянем на примеры. Как инфостиль преображает текст.

Да, информационный стиль сокращает текст, если сравнить с текстом изобилующим пустыми, ничего не значащими словами. Инфостиль бьет сразу в цель, доносит суть, а выводы и оценки — делать пользователю. Мы, в маленьком бюро, уделяем тексту особое внимание — беспощадно вырезаем желчь и добавляем «мясо». Пишем текст для людей, который консультирует, вызывает доверие и продает.


Примеры статей в информационном стиле:
Хорошо ли продавцы в электричках хвалят свой товар Людмила Сарычева
Как устроен банкомат Сергей Король
Почему дисциплина лучше мотивации Андрей Банников

Текст в инфостиле на сайтах:
Энциклопедия услуг «Почты России»
Сайт дилера сотовых операторов
Агентство спортивного маркетинга

Ссылка по теме: Лекция Максима Ильяхова об информационном стиле

Картинки без программирования, как усилие воли без действия — ничто. Но, как без усилия воли не будет действия, так и без визуального представления проект не запрограммировать.

Программируем каталог товаров. «А какая структура каталога?» — спросит программист. Что ему ответить, если нет макета, если не представляем как будет выглядеть сайт? Вся логика продумывается на этапе проектирования дизайна, но не всё просматривается глядя на макеты. Что будет, если вместо квадратных иллюстраций (как нарисовано в макете) загрузить горизонтальные? «Как их выравнивать?„ — последует следующий вопрос программиста. Нельзя забывать о том, что дизайн не статичен. Реакция интерфейса на действия пользователя — это тоже дизайн.

Третий участник, больше всех заинтересованный в пуске проекта — клиент. Рассмотрим варианты взаимодействия и к чему они приводят на практике.

Дизайнер → Клиент ↔ Программисты

Дизайнер ↔ Клиент ↔ Программисты

Клиент ↔ Дизайнер ↔ Программисты

Продолжу аналогию, приведенную в начале поста. Если дизайнер это усилие воли, программист — действие, то клиент это мозг. Из мозга поступает сигнал, возникает усилие воли (намерение), в результате чего производится действие.


Мозг → Намерение → Действие

Мы, в маленьком бюро, запускаем проекты в тандеме с проверенными разработчиками. С клиентом разговариваем на понятном ему языке и не беспокоим по пустякам.

Иллюстрация макета веб-страницы: совет Артёма Горбунова о модульной сетке

Обманывать — плохо. Обманывать ожидания хуже вдвойне. Это неприятно как для обманутого, так и для обманувшего. Особенно если у обманувшего не было такого намерения.

Чтобы не обмануть ожидания клиента, чтобы клиент не потерял деньги и время за зря, а я не испытывал неловкость и муки совести — мы, в маленьком бюро, сначала убеждаемся, что поняли задачу.

Пример реальной заявки на разработку сайта:

Тут вроде как подойдет любое решение. Но если подходит любое решение — это не решение. Не понятно, зачем нужен сайт — для привлечения клиентов, которые будут покупать товар? Если так, то что за товар — ткани, услуги по пошиву, или готовые изделия? Может быть сайт нужен для того, чтобы фабрику находили поставщики тканей, и польза будет именно в этом.

Формулируйте задачу на языке бизнеса, не нужно её формулировать на языке дизайнера. Ведь сайт, система управления, мобильное приложение — это инструменты для решения задач в бизнесе. Но это не единственные инструменты и не всегда все работает так, как задумано. Чтобы привлечь внимание на выставке — девушка модельной внешности в костюме красной шапочки может сработать эффективнее, чем отличная статья и детально продуманная инфографика.

Прежде чем взяться за работу я дотошно стараюсь понять бизнес клиента. Задаю много вопросов и мы совместно приходим к формулировке задачи на языке бизнеса. Часто существует соблазн сформулировать задачу как «увеличить прибыль», но это следствие, нам нужна причина.

Повторю, причину (побудившую обратиться к дизайнеру) нужно сформулировать на языке бизнеса.

По итогам первых переговоров клиент получает документ «понимание задачи», который представляет из себя обычное электронное письмо. Документ не влечет никаких обязательств, но со старта дисциплинирует работу над проектом и позволяет клиенту убедиться в том, что дизайнер понял задачу. Одно дело кивать головой и поддакивать, совсем другое — письменно описать понятное. В тексте описывается не только задача на языке бизнеса, но и способ решить её (на языке дизайнера). Мы приходим у формуле:

Сделать то-то, сделав это

Вышесказанное можно проиллюстрировать проще. Мы приходим в парикмахерскую и объясняем причину, побудившую нас обратиться к парикмахеру (в чем дискомфорт сегодняшней прически, для каких целей нужна другая). Мастер входит в положение и советует как постричься. Если предложение устраивает — стрижемся.

Конечно, можно прийти к парикмахеру и обозначить параметры стрижки — длину локонов на каждом участке головы, угол скоса челки, интенсивность прореживания. Но опытный парикмахер не возьмется за такую задачу. Ведь если прическа не понравится виноват, все равно, будет парикмахер (хотя сделал как просили). Опытный парикмахер ценит клиента и своё душевное спокойствие. Смотрит глубже, устраняет дискомфорт и приближает к цели. Поэтому хорошие парикмахеры ценятся и к ним всегда возвращаются. Даже несмотря на то, что у них дороже.

Ссылка по теме: Лекция Ильи Бирмана о понимании задачи