Авторитет аналитика как фактор производительности команды

[smith_s]

В течении следующих двух недель я проводил коллективные встречи следующего содержания.

Разбирал написанные Вадимом ТЗ, объясняя почему он сделал именно так, а не иначе
Объяснял как правильно работать с требованиями и зачем
Показывал абстрактные примеры исследования предметной области

davvol, можно чуть подробнее про два последних пункта, возможно с примерами? Иначе трудно понять что за ними стоит… Спасибо…

[davvol]

Привет!

Первое — это то для чего вообще мы (команда разработки, вендоры, аутсорсеры, тот кто делает софт) собираем требования и делаем/дорабатываем приложения. Это business value заказчика. Рассказывал что заказчику в целом совершенно плевать на архитектуру, красоту кода и технологический стек, при условии что приложение будет удовлетворять его бизнес-потребности.
Что это всегда надо держать в голове, рассматривая бизнес-требования, переводя их в функциональные и накладывая на них ограничения по бизнес-правилам и всему остальному.

Второе — просто по Вигерсу показывал как начать от диаграммы вариантов использования, проверить ее полноту и в итоге закончить наброском будущей архитектуры приложения в разрезе интерфейс/логика/данные.

[smith_s]

Спасибо, теперь понятно.
Из собственного опыта: обычно в ТЗ всегда добавляю общий раздел со приоритезированным списком бизнес-требований, основным сценарием использования и кратким описанием наиболее важных требований в свободной форме. Для простого функционала это может быть 1-2 абзаца, для сложного — до 1-2 десятков страниц.
Этого обычно вполне достаточно, чтобы сделать последующее общение с любым программистом продуктивным и включить его мозги на улучшение показателя цена/качество продукта, а также уменьшает число отмазок типа «что написали в ТЗ, то я и сделал». А джуниорам позволяет за год-два превратиться из кодеров в полноценные разработчики.