Документация: Тех.задание на работы

Ответственность за тех.задание, Procurement statement of work (SOW), по каждой закупке лежит на РМ. Для подготовки ТЗ, мы всю работу по проекту разбиваем, на ту что будем делать сами, и ту что отдадим на сторону.
ТЗ должно быть полным, ясным, цельным; оно должно описывать все работы и задачи и требования к поставке. В том числе, собрания, отчеты, и коммуникации. Также должны быть описаны критерии приемки, и сам процесс приемки. Как правило, затраты на включение в ТЗ чего-либо в процессе работ существенно выше, чем на старте, так что думать надо сразу и ответственно.
Термин "полнота ТЗ" зависит от того, что мы закупаем.

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

Уровень описываемых деталей будет влиять на выбор типа контракта, и создание закупочной документации.

Всегда полезно поставить себя на позицию поставщика и прочитать ТЗ его глазами. Это снимет многие риски (которые в конечном счете всегда выливаются в цену).

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

О запросах на изменение думаем заранее: они стоят денег и времени, так что нужно минимизировать их шансы. Так что, хорошее ТЗ должно явно говорить, что вы хотите, когда, и какими качествами оно должно обладать.

Типы ТЗ можно классифицировать так.

1. Перфоманс. Описываем скорее то, что должен уметь конечный продукт, чем то, какими способами это должно быть достигнуто. Например, "хочу машину с разгоном 4 сек до сотки"
2. Функциональное. Описываем конечную цель или результат, а не какие-то процедуры или подход. Например, "хочу машину с 3 рядами кожаных сидений"
3. Дизайн. Описываем работу, которую надо сделать, включая материалы и сам ее процесс. Например, "построить гараж по данным чертежам и смете"
4. ТЗ на услуги (terms of reference, TOR). Используется в случае услуг. Включает работы поставщика, стандарты их исполнения, данные или сервис которые получит покупатель