Владимир Завертайлов - Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

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

Редко какие готовые проекты хотя бы на 70 % соответствуют техническому заданию. Юзабилити, бюджет, санкции – что угодно может стать причиной изменений в проекте.

В чистом Scrum-е как такового технического задания нет. Там есть бэклоги. Бэклог – это список функционала (по-другому, фич), отсортированный по приоритетам, по которым идет разработка. Можно менять фичи в любой момент, и это не вызывает проблем на стороне команды. Приоритеты при этом регулярно пересматриваются.

У бэклогов есть свои нюансы и проблемы, и мы их уже разобрали в главе про Scrum.

Но с классическим ТЗ, в котором жестко «морозятся» все требования, проблем, на самом деле, гораздо больше. Дело в том, что невозможно описать четко и однозначно требования так, чтобы люди их поняли точно так, как вы того хотели. В любом ТЗ на спор на коньяк находятся какие-то прорехи, которые можно трактовать двояко. Причем, чем толще и подробнее ТЗ, тем больше таких вещей встречается.

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

Особенно худо, если подробное техническое задание пишут несколько человек (а такое бывает) – как правило, получается шизофрения листов на 300–400. В определенный момент (часов этак через восемь чтения) человек, который внимательно изучает эти 400 листов, хватается за голову и смотрит в стену с единственным желанием – выбросить это все и начать заново. Потому что полностью разобраться в документации – займет месяцы. А этих месяцев у проекта просто нет.

Разработка прототипа и ТЗ к нему обычно съедает около 12 % бюджета проекта. На первый взгляд – много (и это реально много!). Но это не более трудозатратно, чем создание традиционного «железобетонного» технического задания на разработку сайта, которое пытается учесть каждый чих. К тому же, в первом случае процесс прогнозируем по срокам и позволяет избежать гораздо большего вылезания из сроков и бюджета.

При этом потребность рынка очень четко определена: люди привыкли к ТЗ, им нужен документ, на который можно опираться и в случае чего тыкать носом: «Вот, смотрите, вы сделали не по ТЗ». Это отличное прикрытие тылов, которое очень сильно помогает сотрудникам с той стороны проекта сохранить свои рабочие места и получить минимум негативной обратной связи от руководителей. Конечно, в теории. На практике может быть и по-другому.

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

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

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

Типовая структура нашего технического задания содержит следующие разделы:

1. Общие сведения. Здесь самое важное – приоритеты документов проекта. Наше ТЗ – приложение к прототипу сайта. В случае расхождения технического задания и прототипа – приоритет имеет техническое задание. В случае расхождения утвержденного дизайна и технического задания – приоритет имеет дизайн. Итого: что позднее сделали, то и принимается за истину. У сметы – максимальный приоритет.

2. Назначение и цели создания сайта. Пара слов: что делаем и для чего. Например, интернет-магазин на 1С-Битрикс с функциями доставки и онлайн-оплаты. Плюс сюда же мы добавляем цели, которые берутся из Агрегации.