На днях меня тут спросили замечательный вопрос, который поставил меня в тупик: “А как написать правильное ТЗ для разработки чего-нибудь с нейронными сетями? Можете скинуть примеров?”.
Первое что я понял – скинуть не могу. Ибо любой ТЗ – это глубоко личное для того бизнеса, для которого он написан. Нельзя такое скидывать даже обезличенное.
Втрое, что я понял – нельзя сказать что такое хороший ТЗ. Один и тот же ТЗ может быть и замечательным, и омерзительным. ТЗ – это результат диалога двух сторон. Нет ТЗ на ресёрч написанного в пространство.
А вот как провести диалог, и какие общие правила есть – я могу попробовать рассказать.
Из глубин СССР
Когда-то в СССР был впереди планеты всей по большому числу исследований. Были разработаны хорошие методологии и классные подходы для того чтобы формализовать исследования.
Исследования состояли из двух частей:
- НИР – научно исследовательская работа
- ОКР – опытно конструкторская работа
Выглядело это как-то так ( картинка из просторов интернета):
Как вы видите – ТЗ это результат НИР. ТЗ на НИР формально не делается, там делается краткое описание направления исследований.
Ну ок, это СССР. А как сейчас?
Вариант выше – идеальный. Когда для написания ТЗ можно провести исследование, результатом которого будет понимание проблемы и путей её решения. Такое сейчас встречается, но обычно на уровне крупных лабораторий / крупных заказчиков. Лично мы (в cvml) такое делали раза 2-3.
Конечно, когда заказчик небольшой, у него нет денег на исследование. И в первую очередь ему нужен результат. Так что ТЗ должно быть как на НИР, а результат как от ОКР:)
А это значит что ТЗ должен быть краток, чтобы определять намерения, но не фиксировать работы.
Я поднял наши последние ТЗ за год-полтора. Из них:
- 4 фирмы, которые заказывали у нас регулярно (3-5 заказов) – длинна ТЗ 1-2 листа.
- 2 фирмы – ТЗ порядка 10 листов, каждая заказывала один раз, но работа была длительная
- 2 заказа – ТЗ 0 листов, продавали готовые наработки продукта, там был только договор на услугу (пусть даже он включал в себя ресёрч).
Исключение по размеру, зачастую – это когда есть сложный интеграционный процесс, расписанный в задании. Тогда такое может занять 90% текста. Когда описывается какие данные на вход, на выход, где кто эти данные размечает, и.т.д.
Эта часть не про CV, зачастую мы выносим её в отдельную часть ТЗ, чтобы оно разделяла ресёрч и интеграцию.
Что должно быть в ТЗ?
Текущий наш шаблон ТЗ включает:
- Цель исследования – тут в двух словах должно быть сформулировано итоговое пожелание. То, ради чего затевается весь сыр бор
- Задачи – тут должны быть сформированы основные булет поинты, которые должны быть сделаны. Например: “исследовать зависимость а от б”, или “попробовать такой подход и такой подход”, или “использовать такие методы и такие методы”. Короче набор ключевых точек которые были сформулированы в ходе обсуждения задачи
- Результаты работ. Тут явно указывается в каком формате должен быть оформлен результат. Код на Python, репозиторий на Гитхабе, докер образ с RestApi, и.т.д.
Что важно
Для меня важно чтобы ТЗ был полностью проговорен с заказчиком, и заказчик понимал его. Понимал риски, понимал спектр того что но может получить. Если заказчик говорит “мне надо чтобы всё работало идеально” – обычно договориться не получается.
Вот тут более подробно я писал на ту тему: 1, 2
Без этого вся идеология “ТЗ должен быть краток” – на работает.
З.Ю.
В последнее время свои статьи я публикую на очень разных платформах.
И, так получилось, что единое место куда я их свожу тут – https://vk.com/cvml_team (дублирую в https://t.me/CVML_team )
Тот проект в рамках которого всё это сбадяжил – буду на Хабре публиковать скорее всего. Так что ссылка тоже только там будет.
Так что советую подписаться!