Сначала код?

Золотая лихорадка программного обеспечения, о которой я писал в предыдущей статье, зачастую приводит к такому широко распространённому мнению, что, в первую очередь, важно выпустить продукт, а потом его можно будет улучшить. Не могу не отметить, что такая точка зрения в корне не верна: обычно «потом» не наступает никогда и тому есть несколько причин. Желание сделать быстрые деньги значительным образом сказывается на качестве продукта (помните — быстро, дёшево, качественно — одновременно возможны только два из трёх). Непроработанные пользовательские сценарии в совокупности с короткими сроками разработки приводят к запутанному интерфейсу, работающему с ошибками. С такой программой невозможно работать без частых всплесков негативных эмоций, и клиенты, которые платят деньги и определяют прибыль компании, будут рады перейти на альтернативные версии, чтобы больше никогда не испытывать таких мук. Несколько таких продуктов одной фирмы покроют её вечной славой производителя пыточных инструментов, а не программного обеспечения. С другой стороны, плохо продуманные, а значит и сформулированные, требования оказывают отрицательное влияние на гибкость и масштабируемость проекта. Часто меняющиеся спецификации приводят быстрому росту количества так называемого legacy кода. Байки о нецензурных многоэтажных конструкциях, возводимых разработчиками при столкновении с ошибками в таком коде, думаю, слышали даже те, кто не связан напрямую с IT-индустрией. PDCA cycle within ISO 9001 Почему же происходит так, что, начиная разработку с реализации, мы неизменно сталкиваемся со значительным снижением качества как со стороны продукта, так и со стороны технической поддержки? По международному стандарту ISO-9001 процессы, позволяющие эффективно контролировать качество продукта, основываются на цикле PDCA (plan-do-check-act). В описанном выше примере пропущен шаг планирования и сразу совершён переход к действию. Однако без планирования невозможно объективно оценить результат работы, так как не были сформулированы цели и средства их достижения, отчего страдает качество продукта. В свою очередь, без корректных оценок итогов работы сложно повлиять на сам процесс разработки и повысить его эффективность. Таким образом, уделение процессу планирования слишком малого внимания может привести (и чаще всего приводит) к хаосу на остальных этапах проекта и, как следствие, увеличению сроков выполнения работы, увеличению издержек на разработку, увеличение числа ошибок после сдачи проекта и т.д.

Известно, что систематическое улучшение процесса разработки программного обеспечения обеспечивает значительные результаты. Исследования, проведённые институтом инженерии ПО, дают следущие количественные характеристики:

Показатель Среднее улучшение Наилучшее устойчивое улучшение
Производительность 35% в год 58% в год
Сокращение сроков 19% в год 23% в год
Снижение числа дефектов после выпуска 39% в год 39% в год
Ценность для бизнеса 500% 880%

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

Поделиться
This entry was posted in Management, Programming and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>