Владимир!
Если разработчик не думает о бизнесе, то с большой вероятностью он сделает не то, что нужно.
Вот к примеру, делаете вы электронную базу клиентов для своей компании. Договариваетесь с разработчиком на максимально простой формат данных — название компании, телефон, имя и электронная почта.
Ближе к запуску вы понимаете, что забыли сообщить разработчику, что у половины ваших клиентов вообще‑то не одно контактное лицо, а несколько. И у каждого контактного лица — своё имя, свои телефон и почта. Теперь структуру таблицы с клиентами нужно переделывать, а вместе с ней — и структуру всех зависимых таблиц. К примеру, в каждой сделке кроме связи с клиентом придётся указывать ещё и связи со всеми ответственными лицами со стороны клиента — а это уже совсем другой продукт.
Если разработчик в начале проекта подумает о бизнесовой части задачи, попросит у вас существующие файлы с клиентами и сделками, а затем зальёт их в новую базу данных — проблема не случится: разработчик увидит несоответствие и сразу создаст в БД таблицы для контактных лиц. А если разработчик просто сделает так, как вы сказали — в конце вместо работающей системы вы получите гору никому не нужного кода.
P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.
