Почему ТЗ - это медленно и больно

 Корень проблемы с ТЗ

Со мной тут был анекдотический случай. Разработчик сделал задачу по-моему ТЗ и при тестировании выяснилось, что он сломал функционал соседних модулей. На поставленные баги товарищь на полном серьезе заявил: «Ну в ТЗ же не сказано, что все остальное должно работать!».

Жалобы на заказчика-дурака и разработчика, который “весь в белом” уже набили оскомину. Про это я писать не буду. Я несколько лет работал с ТЗ, а последнее время без него, хочу поделиться с вами размышлениями на эту тему и своими граблями. 

Обычно ТЗ составляет заказчик для исполнителя. В нем он сам интерпретирует задачу и придумывает, как ее можно решить (зачем решать, обычно вообще при этом за кадром). Получается ситуевина с исполнителем, изолированным от цели.

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

Хороший исполнитель, - скажете мне вы, - изучая ТЗ, задаст уточняющие вопросы, исправит неточности и противоречия! Но для него в Т.З описана граница, выход за которую ему не оплатят, и вся фантазия останется в рамках общего решения. От заказной разработки нужно быстро и качественно делать, а не задаваться философскими вопросами, типа: “а вам точно нужно приварить сюда треугольное отверстие диаметром 3 на 4?”.

Как это все выглядит: 

Вот как выглядит процесс разработки по ТЗ:   

Как видим, после ТЗ нас ожидает великолепное тянущееся болото правок, которые портят жизнь и мотают нервы не только разработчиков, большинство из них из разряда «не подумали сразу, надо прикрутить пока не поздно». Поэтому обычно после демо переделывать приходится и процессы, и документы, и, собственно, разработку - работы хватает всем.

Спустя месяцы, вы обнаруживаете себя в 5 утра редактирующим ТЗ ver 1003.0.1.  Продолжаться это может очень долго и дорого. На эту тему есть не анекдот, а суровая жиза: как-то мы по частям переписывали гигантскую IT-систему одного заказчика, а после посчитали, что на составление и согласование ТЗ очередного модуля системы со всеми подразделениями и другими подрядчиками уходит столько же времени, сколько на разработку этого модуля.  

В сухом остатке:

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

Передастический АД. Вид сбоку

Еще хуже, когда отраслевые организации запускают у себя внутри «цифровую трансформацию», имея в виду, что сейчас они соберут свой IT-отдел из 1000 человек и перестанут наконец зависеть от всех этих дорогих и неэффективных аутсорсеров. Но при этом не меняют подхода: задачу осознают одни, решение описывают другие, а реализуют третьи (тот самый свеженький штат IT-шников). И когда количество IT-шников переваливает за сотню (не успевают закрывать задачи ведь, понятное дело, из-за нехватки ресурсов же!), вся эта возня с перекидыванием заданий, правок, замечаний и внезапных осознаний «это же не так как мы хотели» почти полностью занимает бизнес и останавливает развитие. И вот тогда IT превращается в «гребанных программистов». 

На эту тему есть фантастический кейс Леруа Мерлен о том, как 400 IT-шников в штате не могли запилить фичу на сайт, и как они решили эту проблему.

Как быть

Очевидно, что нанимать 400 IT-шников также весело и результативно, как на лыжах по асфальту, однако не всем нравятся подобные формы извращений и поэтому логично, что цепочку из тех, кто думает, описывает и реализует надо замкнуть. Создать процесс, когда на вопрос: «что нужно сделать в техническом плане, чтоб снять вот это ограничение?» сразу отвечают IT-специалисты, которые будут это делать. Так под задачу собирается группа из стейкхолдера, product owner-а, разработчиков и отраслевых специалистов. Команда вместе обсуждает, как можно добиться этой цели, вместе решает, что именно им нужно изменить в процессах и, что для этого разработать.

Чем хорош подход с кроссфункциональными командами и без ТЗ:

• Разработчики сами себе планируют фронт работ - идеальная приватизация задачи, по сравнению со спущенным сверху заданием
• Всем понятна связь между конкретной фичей и бизнес-целью, а значит, специалист может сам принимать решения по ходу реализации. Это особенно важно во время разработки продуктов, когда «как правильно» не знает никто
• Если команда на самом деле кроссфункциональная (а не носится челноком согласовывать все так же, как в случае с ТЗ), то бизнес на ходу сравнивает результат с поставленной задачей, экономит на обсуждениях и переписках
• Исполнители, максимально погруженные в бизнес-процессы, проактивно подходят к решению возможных проблем. В этом случае невозможна ситуация, когда на демо вдруг выясняется, что функционал не решает задачу 
• На стыке компетенций (IT, отраслевики, бизнес) обычно находятся лучшие решения

Кому нужен такой подход

Не всем, конечно, такая история подходит. Например, по ТЗ будет проще в 51-й раз делать один и тот же функционал (грабли собраны, результат предсказуем). Если вам нужно повторить стандартное решение, команда - это точно не про вас.

Когда же бизнес решает создать что-то новое, это новое лучше планировать сразу со специалистами. Они, включившись, сами создадут и возьмут себе задачи лучше любого ТЗ.

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