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

Завертайлов Владимир

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

желанием – выбросить это все и начать заново. Потому что полностью разобраться в документации – займет месяцы. А этих месяцев у проекта просто нет.

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

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

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

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

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

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

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

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

3. Требования к верстке.

4. Настройка прав доступа. Например, два пользователя, администратор и контент-менеджер.

Конец ознакомительного фрагмента.