Mushroom management
Это немного не про разработку, но последствия ощущаются и в коде. Есть такая история — «Mushroom management», когда вместо задачи даются требования. Причём частями.
Название отсылает к принципам выращивания грибов: их держат в темноте и удобряют. Так и команду, лишённую контекста, образно «держат в темноте», выдавая информацию дозированно.
Симптомы
- Вместо задачи и цели — поток сырых требований «по факту».
- Контекст открывается частями, когда «пришло время».
- Команда узнаёт о реальных целях на приёмочных тестах.
- Интеграции ломаются, потому что интерфейсы договаривались на лету.
Почему возникает
Чаще всего — из желания «не перегружать» команду, ошибочной секретности или плохо налаженного процесса сбора требований. Иногда — из-за того, что заказчик сам не знает, чего хочет, и «выдаёт частями».
Пример
«Плохой» вариант: команда собирает интерфейс по неполному ТЗ, а контракт меняется на финальной приёмке:
# требования приходят частями:
# 1) "сделайте форму заявки"
# 2) "добавьте поле «сумма»"
# 3) "сумма должна быть в копейках, а не в рублях"
«Хороший» вариант: цель, контекст и критерии приёмки известны заранее:
# цель: приём заявки на кредит
# критерий: заявка валидируется, попадает в очередь, статус отслеживается
# контракт API фиксируется до начала разработки
Как исправить
- Добиваться постановки задачи с целью и критериями приёмки, а не «требований частями».
- Фиксировать API-контракты и интерфейсы до разработки.
- Проводить приёмочные тесты и интеграции по заранее согласованным сценариям.