История разработчика SI
#9. После ввода в проект SI - начало полноценной разработки

После ввода в проект и некоторого времени на адаптацию начинается полноценная разработка. Разработка ведется в соответствии с требованиями, указанными в RFP (спецификация требований), по графику WBS. В SI предполагается, что функционал может быть изменен в любое время, поэтому модули проектируются с минимальной связью друг с другом.

Это связано с тем, что заказчики, хотя и знают свой бизнес, не всегда могут четко сформулировать требования к функционалу, описать структуру интерфейса и т.д. Поэтому часто бывает, что после демонстрации готового интерфейса заказчик высказывает новые требования или вносит изменения.

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

В SI основная цель - заставить систему работать, поэтому чистый код и эффективность уходят на второй план.

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

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

При разработке в SI следует помнить о следующем.

• Информация может измениться в любое время.
• Заказчики ничего не знают. Показывать проект по частям и часто получать обратную связь.
• Дополнительные запросы следует принимать только в случае необходимости.
• Я не Билл Гейтс. Заказчикам важнее быстрый интерфейс, чем хорошо написанная программа.