На одной из встреч нашего “Самарского профсоюза менеджеров проектов” мы вскользь рассмотрели вопрос – кто должен писать ТЗ на проект? Вы – менеджер проекта в “мааааленькой компании”, у которой персонал малым количеством выполняет много разных ролей.Приходит к вам заказчик (тоже – “мааааленький”) и просит написать техническое задание на проект, который ему нужен. Вы его пошлете писать ТЗ самостоятельно или возьметесь? “Все зависит от суммы” – скажете вы и будете правы, как бизнесмен. Ну, давайте считать, что заказчик готов платить сумму, которая вам нужна. Тогда как? Вопрос, достаточно распространенный, например, было такое обсуждение на Linux.org
Что отличает “хорошее ТЗ” от “плохого ТЗ”? То, что в хорошем задании достижение бизнес-целей ясно и исчерпывающе отражается в видах запланированных работ. Поэтому часто исполнители не любят писать ТЗ за некомпетентного в IT заказчика. Надо и цели выяснить и работы под них подогнать. Так как исполнитель в бизнесе заказчика как правило ничего не понимает, то в этом случае они берут на себя большие риски. Разработка ТЗ превращается в “challenge task”.
Фирма, разрабатывающая софт на заказ заинтересована сделать как можно больше проектов в кратчайшие сроки. Маленькая фирма всегда борется за выживание, пара невыгодных проектов вполне может подорвать бизнес. Тут уже не до того чтоб сделать все как надо. Было бы выполнено задание и подписаны акты выполненных работ. Не все проекты входят в портфолио на сайте, не все проекты оказывают существенное влияние на репутацию исполнителя.
Большинство заказчиков эту ситуацию читают. Поэтому на первом этапе настаивают на том, чтобы исполнитель сам писал техническое задание. При этом заказчик надеется, что исполнителю придется в итоге вскрыть больше задач и рисков в процессе работы над документом, потому что “ну вы же профессионал, Петров” (с).
И по совести – заказчик тут прав. Потому что программный продукт нужен не ради себя самого, а ради достижения какой то цели.
Если же стороны все таки хотят договориться, то есть приемлемый для всех подход.
Заказчик пишет видение продукта:
- Бизнес-цели – цели, которые преследует заказчик в данном проекте;
- Аудитория продукта и характеристика объекта автоматизации
- Описание основных сущностей и бизнес-процессов – необходимо для разработки структурной и функциональных моделей предметной области;
- Желаемые этапы и сроки – контрольные точки с указанием промежуточных результатов, желательные для клиента.
Исполнитель по мотивам видения пишет эскизный проект или техническую концепцию, которая содержит в себе следующие части:
- Модель ролей – какие социальные агенты и технические системы связаны с созданием данной с описанием их задач
- Макет интерфейсов – требования к организации пользовательского интерфейса
- Компонентная модель - состав, назначение и взаимосвязь технических компонентов системы;
- Описание применения выбранных технологий – краткое описание инструментов реализации предложенной компонентной архитектуры;
- Поэтапный план выполнения работ
Заказчик приходит к будущему исполнителю с видением продукта. На основе видения и предпроектного исследования исполнитель уточняет видение и пишет техническую концепцию. Это будет первым этапом работ по контракту. При таком подходе все отвечают за то, в чем действительно разбираются. Заказчик определяется со своими желаниями, исполнитель заранее говорит, как он будет добиваться успеха проекта.
А еще есть фирмы которые играют на упомянутых в этой статье рисках пишут за вас техническое задание. Но это уже другой случай.
Recent Comments