Предлагаем Вашему вниманию авторскую статью нашего проект-менеджера Ильи на всегда злободневную тему.
Множество статей написано на тему технического задания. Добавлю же и я свою каплю в это море информации.
В нашей компании я руковожу проектами. За плечами есть как провалы, так и успешные проекты. По своему опыту могу выделить такие взгляды на ТЗ:
- Идём по приборам. Дайте нам тех. требования, а дальше сами разберёмся;
- Вещь нужная для отчётности. Пишем, когда проект уже на финишной прямой, и все подводные камни найдены, а наши пятые точки прикрыты;
- Формальный документ с кучей воды, чтобы создать видимость компетентности. Всё равно в начале разработки невозможно всё предусмотреть, так зачем тратить время на эту писанину;
- Времени и нервов отнимает немерено, но оно того стоит. Всесторонне проработанный документ, к созданию которого привлекаются не только тех. писатели и руководители, но и инженеры с программистами.
Да, подходы диаметрально противоположные и, в принципе, многое зависит от того, какую должность занимает человек, и какая зона ответственности у него в проекте.
Обычно крайним выступает всегда руководитель, поэтому в его интересах минимизировать риски на проекте. Инженер хочет сделать крутую штуковину, и для него строгий документ – это ограничение творческой свободы. Заказчик хочет дёшево и качественно. Желательно побыстрее. Чем лаконичнее ТЗ, тем меньше у него возникает вопросов по ходу проекта, и тем спокойнее он спит по ночам. Пока не увидит результат…
Разберём подробнее первые 3 пункта и перейдём к моему подходу.
“Идём по приборам”
При этом подходе мы не тратим время на написание ТЗ, в лучшем случае формализуем хотелки и рисуем на бумажке примерную структурную схему. Всё кажется просто и понятно. Дел на пару вечеров. Заказчик, узнав о том, что ему задёшево сделают то, что он хочет, уходит довольный ждать результата. Общаться с ним, конечно же, никто особо не будет до завершения проекта, ведь и так всё понятно.
И вот начинается разработка, точнее, “хождение по мукам”. Инженеры приходят и спрашивают, что им делать, начинают задавать множество вопросов. Проект-менеджер кое-как от них отбивается, идёт к заказчику и задает вопросы, которые надо было бы задать на стадии написания ТЗ, на которую, как мы знаем, забили.
Процесс разработки, выстроенный таким образом, превращается в хаос – куча противоречивых хотелок заказчика и креативных предложений разработчиков, которые надо как-то вместе подружить.
Но главная трагедия происходит при сдаче проекта, когда заказчик получает не то, что он хотел (а деньги уже заплачены, время потрачено). В результате, остается только негатив, так как исполнитель обижается на то, что его назвали редиской (нужные слова подставьте сами), заказчик же, потратив время и деньги, в итоге должен всё начинать сначала или оставить эту затею насовсем.
Как правило, это путь проджектов-новичков и неопытных разработчиков. После парочки увесистых оплеух из-за проваленных проектов, люди всё-таки нехотя переходят ко второму варианту.
“Вещь нужная для отчётности”
ТЗ обязательно пишем, но в конце — когда будем точно уверены, что сделали как нужно и сможем сдать проект без проблем.
На самом деле, этот вариант тоже провальный, так как исполнитель формально пытается снять с себя ответственность за отсутствие нормального диалога с заказчиком, ведь в ТЗ всё зафиксировано, значит, так и надо было делать. Как правило, когда ПМ приходит с таким документом под конец разработки, и вдруг всплывает куча нюансов и недоделок, начинается ругань, и проект просто проваливается или заканчивается существенно позже, когда все-таки с заказчиком обстоятельно побеседовали и выяснили, что ему нужно.
Но негатив никуда не деть, ведь произошёл перерасход времени, а значит, денег, и результат всё равно может получиться не таким, на который рассчитывал заказчик, ведь с ним общались не на протяжении всего хода разработки, а только под конец, когда припёрло, и из-под палки.
“Формальный документ с кучей воды”
Третий вариант — комбинация первых двух случаев. Как правило, если в ТЗ много воды, защищать проект по нему очень сложно. Ведь то, что нужно было на самом деле заказчику, там не отражено чётко, а намёки есть. Заказчик будет интерпретировать всё на свой лад, а исполнитель на свой. В результате, снова ругань и заваленный проект или кое-как сданный, но без особого удовлетворения.
“Времени и нервов отнимает немерено, но оно того стоит”
Наконец, мы приходим к четвёртому (как по мне, единственно верному) отношению к техническому заданию — доскональная проработка всех нюансов и обсуждение с заказчиком всех узких мест, которые могут навредить в будущем.
Такой подход существенно увеличивает шансы на успешное завершение проекта и помогает сохранить деловые отношения на будущее. Это конструктивный подход, который даётся очень нелегко, ведь это кропотливая и сложная работа, однако, креативная и приносит немало удовольствия.
Пишите качественные технические задания и получайте удовольствие от результатов своих трудов. Всем хорошего дня!
#разработка #электроника #it #тз #проектменеджер #edcteam