О подходах к составлению ТЗ
Недавно общался с коллегами-конкурентами по сфере 1С. Обсуждали разные варианты организации разработки, включая управление кодом, составление ТЗ, разделение по ролям и т.п. Ну и заодно демонстрировали кто как работает на практике. Полезный опыт, на мой взгляд, в целом направленный на улучшение практик и методик в сфере.
Мне понравилась схема постановки задачи аналитиком и техлидом для разработчиков у коллег. Структура довольно простая, хотя и требует иногда пояснений: 1. Описание что хочет клиент, с его слов. 2. Описание пользовательских сценариев в нотации Gherkin, причем позитивный и негативный сценарии. 3. Рекомендации по реализации техническим лидом с указанием рекомендуемых действий и объектов метаданных.
Теоретически, для решения задачи мидлом и выше этого уже достаточно. Теоретически из такой постановки можно даже приготовить какие то автотесты для Vanessa. Но я бы добавил еще все таки подробную детализацию действий и технические и бизнес кейсы, которые я добавляю уже в своих ТЗ. Это позволяет упростить задачу разработки для джуна, при этом не скатываясь совсем уж в детали, а попутно еще и дать более менее точную оценку сроков и стоимости исполнения (погрешность до 20% на небольших задачах и до 10% на средних со сроком до 3 недель).
А как вы готовите постановку задачи / ТЗ для разработчиков и для клиента?
· 19.07.2024
Обычно ТЗ состоит из следующих верхнеуровневых разделов : Цели и задачи Общая информация Ни и далее идёт уже требования по функциям - описание процесса, требования к дорабатываемым объектам, требуемые доработки, выполняемые действия. Настройка процессов и исполнителей
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён