выборка из информационного шума

Full width home advertisement

Post Page Advertisement [Top]

Техническое задание: как уберечь себя от ошибок и рисков

Техническое задание: как уберечь себя от ошибок и рисков

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

Что и как

Техническое задание — лишь часть проекта. Будь то стартап или новый сервис внутри уже существующего продукта.

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

Этапы разработки технического задания

1. Предварительное изучение брифа/задачи

Как правило, есть эфемерное представление того, что хочет заказчик — в виде брифа, письма с «хотелками», ТЗ. Изучите предметную область, составьте список вопросов.

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

2. Проведение встречи

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

Не проводите встречу как анкетирование, заказчик может почувствовать себя на допросе и замкнуться. Начать следует с «расскажите о проекте, что вы ожидаете получить от него». Заказчик расслабится, будет много говорить, а вы, тем временем, будете делать заметки, что совпало с вашим видением и пониманием, а что нет.

Ответы фиксируйте рядом с вопросами, перечитывайте их.

Если ответ так и не получен (бывает, что заказчик абстрактно отвечает на вопрос, и в итоге ответа нет), задайте вопрос снова, изменив формулировку. Например, «я представляю себе этот функционал так... Верно я вас понимаю? Это совпадает с вашим видением?»

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

3. Разработка концепции

Концепция обычно содержит краткие тезисы будущего ТЗ, а именно:

  • Цели и задачи;
  • Назначение;
  • Роли;
  • Структура;
  • Содержание;
  • Список возможностей (в виде сервисов — кратко).
  • Порой концепция содержит подробное описание бизнес-идеи, для понимания, чем выигрышен проект.

Всегда разрабатывайте концепцию — набросок будущего проекта. Зачастую это позволяет сократить риски, а также расставить все точки над i и для вас, и для заказчика.

4. Уточнение требований

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

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

Даже если все кажется понятным и очевидным, нужно задать вопрос, верно ли вы понимаете. Это сократит кучу времени и нервов. Даже говоря о простых новостях, не стоит забывать, что есть понятия «частота публикации», кто обновляет, какие материалы могут быть в новостях, etc. От ответов на подобные вопросы может кардинально меняться структура страницы и приоритетность информации.

5. Утверждение ТЗ

Заказчики делятся на два типа — те, кто несерьезно относятся к ТЗ и думают «все равно потом сделают, как я скажу» и на тех, кто старается уместить в ТЗ возможное и невозможное. В проекте важно сделать хороший рабочий продукт. Без избытков.

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

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

Трудности и как избежать

1. Срыв сроков

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

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

2. Цена-сроки-объем работ

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

3. Обратная связь

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

4. Старайтесь фиксировать все, о чем договариваетесь

Все пожелания заказчика, переданные вам в разговоре или при личной встрече, подтверждайте письмом, с перечислением пунктов для выполнения; озвучивайте сроки исполнения перечисленного.

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

5. Презентуйте результат

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

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

Маленькие рекомендации

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

Ментальные карты

Техника Mind Maps. Разрабатывайте ТЗ при помощи ментальных карт. Суть процесса состоит в том, что вы изначально рисуете будущий проект в виде схемы. Вы делите продукт на сущности, понятия; при этом в каждом пункте дерева не должно быть больше 3-4 слов. Подобная схема быстро считывается всеми участниками проекта, легко изменять и дополнять дерево. Существует множество программ для разработки таких карт.

Версии и названия файлов

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

По опыту удобно делать названия и версии следующего вида:

NameProject.0.1.doc,

Где NameProject — название проекта,

0 — версия, отправленная клиенту; если 0 — значит, не отправлялось, пока работаете внутри компании (отдела);

1 — версия, которую вы создаете внутри компании (отдела).

Например, вы отправили клиенту версию 0.1, при этом работаете над ТЗ дальше. Вы создаете версию 0.2, потому что это изменение, но уже ваши внутренние или внутри компании. Вы получаете комментарии от клиента и создаете еще более новую версию — 1.3.

Если документов несколько (например, концепция, ТЗ), добавьте тип документа в название документа — NameProject.Concept.0.1.

Структура

Имейте четкую структуру ТЗ. При сборе информации, а также разработке документа, следуйте ей. В зависимости от ожиданий заказчика существует 4 альтернативы для выбора шаблона технического задания. Это может быть ГОСТ, IEEE, Корпоративный шаблон, ваш собственный шаблон (или шаблон компании, в которой вы работаете).

Форматирование

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

Выводы

Пробуйте новые шаблоны, форматы описания. Вы тот, кто может решить бизнес-задачу, предложив грамотное и хорошее решение; тот, кто может сделать пользователей продукта счастливее (за счет удобного и логичного интерфейса). Цените себя и свое время, ведь готовый продукт — результат ваших усилий.

Примеры из жизни

Пример ТЗ, сделанного в программе Xmind

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

Комментариев нет:

Отправить комментарий

Bottom Ad [Post Page]