Этой весной я выступал на Codefest в Новосибирске. Рассказывал, как перейти от проектного мышления к продуктовому. После доклада меня позвали дать интервью, где я рассказал о переходе от проектного мышления к продуктовому, кросс-функциональных командах и о том, где взять крутого Product Owner'а.
Написание подробного Технического задания для IT-проекта вошло в привычку и воспринимимается как стандарт. Все пишут ТЗ, стараясь снизить риски и упростить работу. Но с работой по ТЗ связан ряд проблем, которые стоит учитывать, чтобы снизить риски в проекте. Об этих проблемах ниже.
Перед Заказчиком стоит почти неподъёмная задача — поместить в голову Исполнителя свою идею и замотивировать его на достижение бизнес-результата.
Почему из всех вариантов решения этой задачи часто выбирают написание подробного плана действий в форме технического задания? Не обязательно перед начало работ иметь 100% контроль над проектом от текущего момента и на два года вперед. Более того, бывает вредно и дорого делать Big Upfront Design. Гонщик Mario Andretti говорил об этом так: «Если вы контроллируете всё, значит едите недостаточно быстро».
Тем не менее, существует ряд объективных причин, которые подталкивают подробно описывать весь план работ до начала проекта.
Люди не любят жить в неопределенности. Нам хочется 100% предсказать будущее, спланировать работу на год вперед и идти по плану шаг за шагом без сюрпризов. С этой точки зрения подробное Техническое задание — чудодейственное средство, которое предскажет какие задачи, как, когда и за сколько будут сделаны.
При описании задач в ТЗ мы балансируем между двумя крайностями:
Как понять, что в ТЗ написано достаточно? Как понять, что критичные риски закрыты? Давайте обсудим по каким критериям ориентироваться в этом вопросе.
В офис Byndyusoft в Челябинске снова пришли ребята с канала Бизнес в стиле диджитал. В прошлый раз мы общались на тему устройства компании, собеседования сотрудников и IT-архитектуры.
Темы из интервью:
