О подходах к составлению ТЗ

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

Мне понравилась схема постановки задачи аналитиком и техлидом для разработчиков у коллег. Структура довольно простая, хотя и требует иногда пояснений: 1. Описание что хочет клиент, с его слов. 2. Описание пользовательских сценариев в нотации Gherkin, причем позитивный и негативный сценарии. 3. Рекомендации по реализации техническим лидом с указанием рекомендуемых действий и объектов метаданных.

Теоретически, для решения задачи мидлом и выше этого уже достаточно. Теоретически из такой постановки можно даже приготовить какие то автотесты для Vanessa. Но я бы добавил еще все таки подробную детализацию действий и технические и бизнес кейсы, которые я добавляю уже в своих ТЗ. Это позволяет упростить задачу разработки для джуна, при этом не скатываясь совсем уж в детали, а попутно еще и дать более менее точную оценку сроков и стоимости исполнения (погрешность до 20% на небольших задачах и до 10% на средних со сроком до 3 недель).

А как вы готовите постановку задачи / ТЗ для разработчиков и для клиента?

#1с #техническоезадание #аналитик