Что делать, если разработка ТЗ не самого сложного проекта занимает пару месяцев? Какие шаги при разработке ТЗ могут уберечь от рисков и ошибок? В данной статье мы рассмотрим проблему не содержания документа, а методологию его разработки.
Техническое задание — лишь часть проекта. Будь то стартап или новый сервис внутри уже существующего продукта.
В любом случае ТЗ должно представить фантазии Заказчиков и Исполнителей в адекватном и возможном для реализации виде. Когда мы говорим о методологии разработки, не стоит делить ТЗ на ТЗ для малых или больших проектов. Это всегда серьезный документ, где виноватым в случае чего будет разработчик технического задания (и менеджер, конечно).
Как правило, есть эфемерное представление того, что хочет заказчик — в виде брифа, письма с «хотелками», ТЗ. Изучите предметную область, составьте список вопросов.
Собирайте информацию о компании, рынке, клиентах, конкурентах. Просмотренная информация даст вам понимание бизнеса заказчика, что, в свою очередь, поднимет вас в его глазах.
Всегда составляйте конкретный список вопросов и потихоньку выясняйте все у заказчика.
Не проводите встречу как анкетирование, заказчик может почувствовать себя на допросе и замкнуться. Начать следует с «расскажите о проекте, что вы ожидаете получить от него». Заказчик расслабится, будет много говорить, а вы, тем временем, будете делать заметки, что совпало с вашим видением и пониманием, а что нет.
Ответы фиксируйте рядом с вопросами, перечитывайте их.
Если ответ так и не получен (бывает, что заказчик абстрактно отвечает на вопрос, и в итоге ответа нет), задайте вопрос снова, изменив формулировку. Например, «я представляю себе этот функционал так... Верно я вас понимаю? Это совпадает с вашим видением?»
Не бойтесь задавать вопросы, какими бы неожиданными они не казались. Многие вещи настолько очевидны внутри конкретного бизнеса, что вам могут забыть о них упомянуть.
Концепция обычно содержит краткие тезисы будущего ТЗ, а именно:
Всегда разрабатывайте концепцию — набросок будущего проекта. Зачастую это позволяет сократить риски, а также расставить все точки над i и для вас, и для заказчика.
После утверждения концепции вы уточняете и формализуете недостающие требования. Фиксируйте требования в ТЗ, формируйте их в готовые блоки с описаниями (а желательно и с интерфейсами). Заказчику проще воспринимать информацию о том, что он хочет, когда есть графическое сопровождение описанных требований.
Пройдите несколько итераций по разработке ТЗ, каждый раз дополняя и изменяя документ по комментариям заказчика.
Даже если все кажется понятным и очевидным, нужно задать вопрос, верно ли вы понимаете. Это сократит кучу времени и нервов. Даже говоря о простых новостях, не стоит забывать, что есть понятия «частота публикации», кто обновляет, какие материалы могут быть в новостях, etc. От ответов на подобные вопросы может кардинально меняться структура страницы и приоритетность информации.
Заказчики делятся на два типа — те, кто несерьезно относятся к ТЗ и думают «все равно потом сделают, как я скажу» и на тех, кто старается уместить в ТЗ возможное и невозможное. В проекте важно сделать хороший рабочий продукт. Без избытков.
Пример аргумента для разбиения проекта на этапы: «Давайте реализуем вначале хорошую рабочую версию, с основными функциями, а потом будем дорабатывать и придумывать дополнительные фичи. Но в описанную вами возможность мы изначально закладываемся».
Старайтесь всегда думать о том, кто будет пользоваться продуктом. Предоставить все возможности пользователю — можно, но либо во вред удобству, либо во вред времени реализации.
Порой бывает, что нет так называемой музы, чтобы написать документ. Сядьте, почитайте интересную книжку, посмотрите интересную передачу или мультик. Не надо «серфить по сети». Новые эмоции от книги или просмотренного может сильно развить воображение, придать силы и вдохновение. Не откладывайте все на самый последний день.
Не давайте ложное представление о сроках проекта и ваших возможностях, закладывайте в план работ сроки на согласование. Планируйте время, выделенное на проект: расписывайте дни по задачам, и придерживайтесь разработанного графика.
Всегда задумывайтесь, что у любой задачи есть сроки реализации и цена. Важно предлагать решения не абстрагируясь от этих значений.
Всегда отвечайте на письма и звонки. Для заказчика немаловажно наличие обратной связи с вами. Он должен быть уверен, что при возникновении спорных моментов, вопросов, уточнений, он может позвонить или написать и получить ответы.
Все пожелания заказчика, переданные вам в разговоре или при личной встрече, подтверждайте письмом, с перечислением пунктов для выполнения; озвучивайте сроки исполнения перечисленного.
Если заказчик присылает по 15 писем в день с пожеланиями, попросите заказчика собирать пожелания в одно письмо. Так вы уменьшите риски, что часть информации затеряется в переписке, а вам придется потратить время на внесение изменений.
Множество идей отвергаются потому, что не были поданы с правильным описанием. Например, если заказчик хочет одним образом реализовать функцию, а вы с этим не согласны, разработайте свою версию, обоснуйте ее, опишите идею реализации, расскажите о преимуществах вашего решения.
Старайтесь не делать только как пожелает заказчик. Как правило, худший вариант в данном случае и будет принят.
Когда вы уже не первый раз работаете над созданием технического задания, следуйте своим правилам. Например, правила могут быть следующие:
Техника Mind Maps. Разрабатывайте ТЗ при помощи ментальных карт. Суть процесса состоит в том, что вы изначально рисуете будущий проект в виде схемы. Вы делите продукт на сущности, понятия; при этом в каждом пункте дерева не должно быть больше3-4 слов. Подобная схема быстро считывается всеми участниками проекта, легко изменять и дополнять дерево. Существует множество программ для разработки таких карт.
Называйте файлы грамотно. Например, это может быть название проекта — закодировано или целиком. Пишите в названии каждого файла версии. Так будет легче вам понять, какой файл был последний.
По опыту удобно делать названия и версии следующего вида:
NameProject.0.1.doc,
Где NameProject — название проекта,
0 — версия, отправленная клиенту; если 0 — значит, не отправлялось, пока работаете внутри компании (отдела);
1 — версия, которую вы создаете внутри компании (отдела).
Например, вы отправили клиенту версию 0.1, при этом работаете над ТЗ дальше. Вы создаете версию 0.2, потому что это изменение, но уже ваши внутренние или внутри компании. Вы получаете комментарии от клиента и создаете еще более новую версию — 1.3.
Если документов несколько (например, концепция, ТЗ), добавьте тип документа в название документа — NameProject.Concept.0.1.
Имейте четкую структуру ТЗ. При сборе информации, а также разработке документа, следуйте ей. В зависимости от ожиданий заказчика существует 4 альтернативы для выбора шаблона технического задания. Это может быть ГОСТ, IEEE, Корпоративный шаблон, ваш собственный шаблон (или шаблон компании, в которой вы работаете).
Хороший документ — это грамотный и правильно оформленный документ. Хорошо оформленные документы легко читать, потому что в них нет десятков стилей, множества блоков текста различного оформления.
Пробуйте новые шаблоны, форматы описания. Вы тот, кто может решить бизнес-задачу, предложив грамотное и хорошее решение; тот, кто может сделать пользователей продукта счастливее (за счет удобного и логичного интерфейса). Цените себя и свое время, ведь готовый продукт — результат ваших усилий.
Николай Евдокимов, руководитель проекта Seopult.ru, самостоятельно делает ТЗ на проекты и считает, что хорошее ТЗ — это готовый макет в PSD. Его макеты полностью показывают работу сервиса, поэтому не нуждаются в описании.
Пример ТЗ, сделанного в Photoshop
Для Анара Бабаева, основателя сервисов Setup.ru и Flirteka.ru, хорошим опытом стала разработка ТЗ с помощью Mind Map. Если раньше на разработку документации у его команды уходили месяцы, то с помощью данной технологии, а также словесного объяснения участникам проекта идеи продукта, процесс по разработке ТЗ стал занимать меньше недели.
Пример ТЗ, сделанного в программе Xmind
Примечание редактора. Подобная «формализация» хороша в проектах, где все друг друга знают, и проект делается внутри компании. Для студий, реализующих проекты на заказ, важна полная формализация и рамки.