Принимать в ТЗ разработческие решения, будучи аналитиком
Один из самых спорных и часто задаваемых вопросов - это "насколько глубоко аналитик должен погружаться в техническую часть при написании ТЗ?". Документы и уровень погружения аналитика бывает разный и зависит всегда от того, что принято в компании: где-то аналитик пишет совсем верхнеуровневые бизнес-требования, где-то углубляется на уровень протокола, а где-то прописывает за разработчика взаимосвязи между компонентами и схему БД.
В слишком глубокий уровень я отношу: архитектуру системы (включая решения про синхронность-асинхронность, если решение не продиктовано какой-то реальной бизнес-необходимостью), взаимодействие между компонентами (передача событий, шины, обработка технических исключений), структура БД, наименования таблиц, колонок и т.д.
Лично мне нравится такая точка зрения: если вы компетентнее разработчика (например, вы N лет были крутым архитектором, а теперь аналитик в каком-то стартапе, где все делается джунами на коленке), то вы можете внутри ТЗ расписать техническое решение. Если нет, то даже не пытайтесь.
Три причины сказать себе "стоп", когда ТЗ становится слишком техническим:
- В 99% случаев аналитик в этом плане НЕ компетентнее разработчика
- Бывает так, что младший разработчик делает все, как написано в ТЗ вместо совета старшего товарища, а на ревью ему прилетает про "кто вообще тебе так сказал делать" (я видела такие случаи, и см. первый пункт)
- Разработчики в большинстве своем придерживаются точки зрения, что такие ТЗ расхолаживают и отучают думать самих разработчиков
Один из самых спорных и часто задаваемых вопросов - это "насколько глубоко аналитик должен погружаться в техническую часть при написании ТЗ?". Документы и уровень погружения аналитика бывает разный и зависит всегда от того, что принято в компании: где-то аналитик пишет совсем верхнеуровневые бизнес-требования, где-то углубляется на уровень протокола, а где-то прописывает за разработчика взаимосвязи между компонентами и схему БД.
В слишком глубокий уровень я отношу: архитектуру системы (включая решения про синхронность-асинхронность, если решение не продиктовано какой-то реальной бизнес-необходимостью), взаимодействие между компонентами (передача событий, шины, обработка технических исключений), структура БД, наименования таблиц, колонок и т.д.
Лично мне нравится такая точка зрения: если вы компетентнее разработчика (например, вы N лет были крутым архитектором, а теперь аналитик в каком-то стартапе, где все делается джунами на коленке), то вы можете внутри ТЗ расписать техническое решение. Если нет, то даже не пытайтесь.
Три причины сказать себе "стоп", когда ТЗ становится слишком техническим:
- В 99% случаев аналитик в этом плане НЕ компетентнее разработчика
- Бывает так, что младший разработчик делает все, как написано в ТЗ вместо совета старшего товарища, а на ревью ему прилетает про "кто вообще тебе так сказал делать" (я видела такие случаи, и см. первый пункт)
- Разработчики в большинстве своем придерживаются точки зрения, что такие ТЗ расхолаживают и отучают думать самих разработчиков