Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 3
В течении следующих двух недель я проводил коллективные встречи следующего содержания.
Разбирал написанные Вадимом ТЗ, объясняя почему он сделал именно так, а не иначе
Объяснял как правильно работать с требованиями и зачем
Показывал абстрактные примеры исследования предметной области
davvol, можно чуть подробнее про два последних пункта, возможно с примерами? Иначе трудно понять что за ними стоит… Спасибо…
Привет!
Первое — это то для чего вообще мы (команда разработки, вендоры, аутсорсеры, тот кто делает софт) собираем требования и делаем/дорабатываем приложения. Это business value заказчика. Рассказывал что заказчику в целом совершенно плевать на архитектуру, красоту кода и технологический стек, при условии что приложение будет удовлетворять его бизнес-потребности.
Что это всегда надо держать в голове, рассматривая бизнес-требования, переводя их в функциональные и накладывая на них ограничения по бизнес-правилам и всему остальному.
Второе — просто по Вигерсу показывал как начать от диаграммы вариантов использования, проверить ее полноту и в итоге закончить наброском будущей архитектуры приложения в разрезе интерфейс/логика/данные.
Первое — это то для чего вообще мы (команда разработки, вендоры, аутсорсеры, тот кто делает софт) собираем требования и делаем/дорабатываем приложения. Это business value заказчика. Рассказывал что заказчику в целом совершенно плевать на архитектуру, красоту кода и технологический стек, при условии что приложение будет удовлетворять его бизнес-потребности.
Что это всегда надо держать в голове, рассматривая бизнес-требования, переводя их в функциональные и накладывая на них ограничения по бизнес-правилам и всему остальному.
Второе — просто по Вигерсу показывал как начать от диаграммы вариантов использования, проверить ее полноту и в итоге закончить наброском будущей архитектуры приложения в разрезе интерфейс/логика/данные.
Спасибо, теперь понятно.
Из собственного опыта: обычно в ТЗ всегда добавляю общий раздел со приоритезированным списком бизнес-требований, основным сценарием использования и кратким описанием наиболее важных требований в свободной форме. Для простого функционала это может быть 1-2 абзаца, для сложного — до 1-2 десятков страниц.
Этого обычно вполне достаточно, чтобы сделать последующее общение с любым программистом продуктивным и включить его мозги на улучшение показателя цена/качество продукта, а также уменьшает число отмазок типа «что написали в ТЗ, то я и сделал». А джуниорам позволяет за год-два превратиться из кодеров в полноценные разработчики.
Из собственного опыта: обычно в ТЗ всегда добавляю общий раздел со приоритезированным списком бизнес-требований, основным сценарием использования и кратким описанием наиболее важных требований в свободной форме. Для простого функционала это может быть 1-2 абзаца, для сложного — до 1-2 десятков страниц.
Этого обычно вполне достаточно, чтобы сделать последующее общение с любым программистом продуктивным и включить его мозги на улучшение показателя цена/качество продукта, а также уменьшает число отмазок типа «что написали в ТЗ, то я и сделал». А джуниорам позволяет за год-два превратиться из кодеров в полноценные разработчики.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Авторитет аналитика как фактор производительности команды