Garbage In, Garbage Out

Известный принцип в разработке гласит: “мусор на входе, мусор на выходе”.

В отношении процессов разработки я вижу такое применение этого принципа.

Если вы приносите разработчикам ворох плохо подготовленных требований, в результате вы получите очень плохо работающую систему.

Пусть думает программист

Некоторые менеджеры сваливают на разработчиков работу по подготовке требований. Описывают задачу как попало и отдают в разработку.

Если повезло и разработчик очень умный, коммуникативный и ответственный, он всех расспросит, всё уточнит и сделает всё как надо. Ну, точнее, как понял.

Если же это обычный человек которого не особенно беспокоит результат, то он сделает так, как написано.

Тем самым повергнув заказчика в большое недоумение — всё работает как описано, но никуда это не годится. Переделывать!

Я распишу что надо сделать

Другие менеджеры, обжёгшись на таких случаях, начинают “программировать за программиста”, придумывать по каким таблицам разложить данные и как назвать поля, чтобы программист “просто закодил” то что они подробно описали.

Это тоже к хорошему не приводит, так как проектирование получается хуже, чем если бы его сделал программист.

К тому же программисту приходится работать в заданных рамках, что ограничивает его возможности найти лучшее решение.

Что же делать?

Описать требования на языке бизнеса. Не пытаться программировать за программиста. Внятно и детально распишите что вы хотите и зачем.

Ну а если вам лень думать над требованиями и расписывать их, то готовьтесь — вы получите мусор.