Техническое задание как база знаний о проекте

Разработка ПО - это процесс создания знания. Общая идея продукта, прототипы дизайна и концепция архитекутры могут появиться до начала разработки, но их правильность или неправильность будет проверена только в ходе работы над проектом.

ТЗ — источник потерь

Я всегда довольно скептически относился к подробным техническим заданиям и со временем эта позиция только усиливается.

Что значит получить подробное ТЗ до начала работ?

1. Заказчик рассказывает про проект и просит его оценить
2. Мы просим описание проекта, чтобы понять объем работы
3. Получаем техническое задание по проекту (оно не будет исчерпывающим, особенно в больших проектах)
4. Читаем, анализируем, даем оценку. Нас попросят подписаться под сроком, поэтому оценка сразу включает наши риски, т.е. увеличиваем время и деньги
5. Заказчик соглашается и просит нас подписаться под сроком и ценой
6. На что мы, защищая свои интересы, поясняем, что после подписывания ТЗ изменения в него будет сложно внести. Придется пересогласовать и цену и срок
7. Чтобы не идти на пересогласования, заказчик пытается заранее учесть в этом ТЗ всё что только можно и нельзя

Ситуация проиграл-проиграл

Давайте посмотрим, что каждая сторона получит в итоге:

• Заказчик все равно будет вносить изменения в ТЗ, можно принять это за факт. Чем больше проект, чем чаще мы делаем релизы, тем больше изменений будет внесено. Мы все-таки не ТЗ делаем, а бизнес-задачу решаем, только в этом до последнего никто не признается
• Если мы заранее согласовали архитектуру с техническими специалистами заказчика, то сразу после начала работы мы начнем вносить в нее изменения. Чем подробнее была эта изначальная архитектура, тем больше изменений в нее будет внесено. Опять же, если архитектура входила в ТЗ, то придется пересогласовывать сроки и бюджет
• В ТЗ оказалось много задач, которые никогда не понадобятся заказчику, но раз они в ТЗ, значит нам надо будет их сделать. Это влечет потери времени и денег с обеих сторон
• С помощью ТЗ мы хотели ограничить «хотелки» заказчика, а получили их с избытком: первая часть добавлена в ТЗ заказчиком на будущее + вторая часть пришла в виде изменений по ходу проекта
• Хуже всего в этой ситуации пользователям, т.к. сроки реализации растягиваются

Проблемы пересогласования ТЗ

Самое интересное в таком подходе - процесс пересогласования сроков и бюджета. Это магическая процедура редко бывает с выходом win-win. Заказчик может сдвинуть сроки релиза, но будет до последнего упираться в изменении бюджета.

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

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

История знает и случаи успешного пересогласования бюджета, но это большая редкость.

Agile без ТЗ

Вы скажете, что этот рудимент в виде ТЗ уже не существует в Agile проектах. У нас есть заказчик под рукой, мы делаем Story Mapping, держим Kanban-доску у всех на виду, делаем релизы каждый день, всем понятно текущее состояние проекта. В этом случае никому не придет в голову полгода писать подробное ТЗ и только потом отдавать его в работу.

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

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

Случай из практики: Мне удалось поработать с гос. заказчиком по моделе Agile. Изначально было некое ТЗ, жесткие сроки и бюджет, но заказчик хотел получить именно работающий продукт, а не реализованное ТЗ. Внутри жесткого waterfall'а мы устроили обычный Scrum. В итоге заказчик получил продукт на несколько месяцев раньше, чем требовалось.

Реинкарнация ТЗ

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

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

В этом случае получилось следующее:

• Мы планируем задачи в понедельник
• Каждый день делаем релизы
• Раз в неделю проводим демо
• Ведем документ, который описывает всю функциональность системы

Последней частью занимается Product Owner вместе с техническим писателем. Получающийся документ остает от разработки и постоянно меняется по ходу работы. Заказчик видит продукт, проводит демо для клиентов, получает обработную связь и хочет сделать продукт лучше. Мы получаем наброски дизайна и примерное описание. Реализуем, показываем, получаем более подробные User Story, доделываем задачу.

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

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

Избавляемся от потерь

Написание подробного ТЗ до начала работы, как и Big Design Up Front, приводят к потерям на IT-производстве.

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

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

Эта статья входит в цикл статей о техническом задании:

1. Когда надо прекратить писать Техническое задание и начать делать проект? Дана схема как балансировать между чрезмерно подробным, а значит дорогим, ТЗ и слишком абстрактным, что ведет к рискам и ошибкам.
2. 5 причин написать ТЗ, где перечислены причины, которые подталкивают подробно описывать весь план работ до начала проекта.
3. 12 проблем при работе по техническому заданию в IT-продукте. Описаны проблемы, которые превращают написание ТЗ в потери для бизнеса.
4. Откровенное общение с заказчиком, где решился спор о том, на сколько подробным должно быть ТЗ.
5. Техническое задание как база знаний о проекте, где описано, что написание ТЗ — это потери для бизнеса.
6. Как и какое техническое задание писать при работе по Agile, где описывается, как использовать подходящие инструменты планирования, прекратить фиксировать объем работ надолго в будущее и строить коммуникацию вокруг бизнес-целей.