Информационные системы всерьез и на долго вошли в жизнь челоека, а на современных предприятиях они зачастую являются ядром бизнеса. Современные информационные системы позволяют компаниям создавать и предлагать клиентам новые высокотехнологичные сервисы и товары.
Эволюция технологий разработки программного обеспечения за последние 20 лет совершила огромный рывок вперед. Тем не менее, проекты разработки программного обеспечения и в наше время страдают от всё тех же проблем и «болячек», что и несколько лет назад, независимо от применяемых технологий, это: срывы сроков, незапланированное увеличение бюджета, низкое качество продукта.
Отчет Standish Group за 2009 год свидетельствует о том, что качество реализации проектов разработки программного обеспечения за последние годы кардинально не изменилось. И доля успешных проектов по-прежнему не столь высока, хоть и наблюдается тренд по изменению ситуации в лучшую сторону (рис.2).
Рис. 1: Проекты по разработке ПО (49% — успешны; 23% — имели препятствия; 28% — потерпели крах)
Попробуем разобраться — почему же разработка программного обеспечения настолько рискованна и непредсказуема?
Неизбежность изменений
Каждый проект по разработке ПО имеет свои риски. Главным, и пожалуй, основным источником рисков являются изменения, происходящие на протяжении всего жизненного цикла проекта. К наиболее частым изменениям относятся изменения требований заказчика к результату проекта. Но это не единственные изменения, влекущие возникновение рисков для проекта. Существует огромное количество других изменений, которые могут порождать критичные для проекта риски, например:
- Изменения в команде участников проекта
- Изменения используемых в ходе реализации проекта технолгий
- Изменения во внешних системах, которые должны работать совместно с разрабатываемой системой
Ваше умение работать с изменениями проекта, является непреклонным требованием к снижению рисков проекта и повышению вероятности успешного завершения проекта. Какой же путь реализации выбрать? Основное влияние на данный аспект управления проектом оказывает выбранный процесс разработки, а не используемые технологии.
Выбор правильного процесса
Как руководитель проекта вы, скорее всего, будете стремиться исключить изменения в вашем проекте используя такой популярный подход как — строгая политика «никаких изменений!».
Как вы, наверное, уже догадались, фактически это пример водопадной модели, которая исходит из предположения, что разработка ПО двигается линейно и предсказуемо. Процессы водопадной модели разработки имеют четко определенную последовательность этапов. Каждый из этапов должен быть завершен и принят до того, как будет сделан переход к следующему этапу разработки.
Например, на рис. 3, сбор Требований (англ. Requirements) завершается точно до старта этапа Анализа (англ. Analysis). Дизайн продукта (англ. Design) не может быть начат до того, как будет завершен и принят этап Анализа и т.д.
Рис. 2: Водопадная модель разработки
Возможно, на первый взгляд водопадная модель выглядит вполне обоснованным подходом. Проблема же заключается в том, что разработка ПО довольно часто обладает свойством непредсказуемости, а следовательно такой подход не может эффективно справляться с изменениями. В результате применения такого подхода разработки ПО почти никогда не удается избежать рисков. Но еще хуже то, что используя водопадную моделью разработки, вы очень часто можете испытывать ложное чувство спокойствия относительно того, что проект прогрессирует. Следуя строгому правилу одобрения каждого этапа проекта по его завершению, вы начинаете верить в то, что проект упрощается, становится предсказуемым и уровень его риска уменьшается по ходу приближения к финальной стадии.
Но изменения неизбежны на протяжении всего жизненного цикла проекта, и очень часто эти изменения являются результатом отзывов заказчика. Как вы можете заметить на Рис. 4, водопадный процесс разработки программного обеспечения предполагает поздний сбор обратной связи и отзывов в той части, которая наиболее важна, а именно — код программного обеспечения, а не одобренная и принятая документация.
Рис. 3: Работа с изменениями
В результате, изменения в разрабатываемом ПО чаще всего должны быть сделаны на последних этапах проекта, таких как интеграция (когда различные модули системы собираются в единую систему) и тестирование. Только представьте себе, что значит проавалить проект с трудозатратами в 100 человеко-лет после того, как 90 из них уже были потрачены, — и все из-за принципиального недопонимания требований заказчика!
Профиль риска водопадной модели разработки, изображенный на Рис. 5, не подходит для разработки ПО.
Рис. 4: Водопадный профиль риска
Фундаментальным недостатком водопадной модели является тот факт, что она ориентируется на предсказуемость прогресса проекта разработки с определенной точностью, а дата завершения проекта может быть рассчитана базируясь на данном предположении. Опираясь на то, что цикл разработки ПО предсказуем, вы невольно начинаете считать, что высокий риск маловероятен в этом проекте, а это, как показывает практика, опасно и глупо! Водопадная модель разработки — это неверный подход к разработке программного обеспечения.
Итеративная разработка и низкий уровень риска
Риски проекта почти всегда ассоциируются с чем-то неизвестным в данный момент. Это могут быть организационные или технические риски, риски, ориентированные на внешнее окружение проекта и бизнес в целом, например, такие как:
- Как будет наша система X взаимодействовать с системой Z?
- Можем ли мы управлять удаленной командой разработчиков?
- Действительно ли требования к ПО отображают требования заказчика и нужды пользователей?
Те, кто пытаются улучшать процессы разработки, осознают, что создание программного обеспечения — это рискованный бизнес с высоким уровнем непредсказуемости. Также они осознают и то, что наилучшим механизмом успешного достижения результата проекта является постоянный контроль и избежание рисков, путем регулярного предоставления промежуточной версии ПО, которую можно протестировать. Это дает реальную возможность отслеживать прогресс и отчитываться перед заказчиком на протяжении всего жизненного цикла проекта.
Ключевые принципы снижения рисков проекта
Не существует единственно верного правила, которое бы гарантировало успех проекта, но ниже перечисленные ключевые принципы могут значительно увеличить шансы на успешную реализацию проекта:
- Принятие и использование итеративного подхода
- Преданность и вовлеченность в проект высшего руководства
- Налаженные коммуникациями между всеми членами команды проекта
- Высококвалифицированная команда проекта
- Принятие и использование подхода, основанного на сценариях использования (англ. Use Case)
- Принятие и использование комплексной системы управления изменениями
- Использование инструментов визуального моделирования (англ. Visual Modelling)
Принятие и использование итеративного подхода
Применение итеративного подхода, основанного на риске, может снизить уровень риска проекта путем предоставления отдельных готовых частей системы в сжатые сроки (не более 4 недель для крупных проектов). В конце каждого цикла разработки исполнитель должен продемонстрировать заказчику результаты и получить отзывы пользователей о функциональности, работоспособности системы и ее стабильности. Использование такого подхода снижает уровень риска проекта с самого начала разработки. Это происходит по той причине, что команда проекта фокусируется на ключевой функциональности системы и снижает риски с высоким уровнем на ранних этапах разработки ПО.
В качестве примера эффективности использовании итеративного подхода приведу случай, произошедший в 2004 году, когда я руководил разработкой системы мониторинга финансовых операций. Одно из главных требований заказчика звучало как — система должна обрабатывать не менее одного миллиона финансовых операций в восьмичасовом окне.
Заказчик настаивал на том, что это ключевое требование, и что система должна стабильно работать на дешевом оборудовании. Я с самого начала четко понимал, что у нас возник риск того, что мы не сможем предоставить требуемую производительность при таких требованиях, поэтому мы создали рабочий базовый прототип в течение двух недель и предоставили заказчику отчет, в котором говорилось, что мы смогли добиться всего лишь 20% от требуемой производительности.
В результате этого заказчик пересмотрел свои требования и принял решение о снижении уровня производительности системы. Это была победа! Ключевой риск проекта удалось избежать всего за две недели разработки.
На рисунке 6 изображен сравнительный анализ типовых профилей риска итеративной и водопадной моделей разработки ПО. Итеративный цикл позволяет избегать рисков на протяжении всего проекта, начиная с самых ранних этапов, что является результатом постоянной обратной связи от заказчика.
Рис. 6: Сравнение профилей риска итеративного и водопадного методов разработки
Преданность и вовлеченность в проект высшего руководства
В любом бизнесе сложно изменить то, как люди привыкли работать, а если учесть технических специалистов, то все еще сложнее. Крайне важно иметь полную поддержку высшего руководства для проведения любых изменений процессов. Вам понадобится страховка со стороны руководства для того, чтобы выполнить изменения на ранних стадиях, но как только процесс начнет работать и появятся первые результаты, люди естественно захотят быть частью этого процесса.
Налаженные коммуникациями между всеми членами команды проекта
Основу любого проекта составляют люди — без слаженной работы всех участников проекта у вас не будет команды проекта, и ваш проект с большой долей вероятности потерпит сокрушительный крах.
Коммуникации крайне важны в среде команды, но еще важнее иметь хороший уровень общения с заказчиками и спонсорами. Коммуникации должны быть регулярными на каждом этапе проекта — каждый день стоит общаться с командой, а с заказчиком и спонсорами — хотя бы раз в неделю. Ваша основная цель заключается в том, чтобы все эти группы заинтересованных в проекте лиц стали частью общей команды проекта. Итеративная разработка значительно повышает уровень общения между членами команды.
Коммуникации могут быть выражены в разных формах, а не только в вербальной, хорошая проектная документация также может быть использована в качестве средства обмена информацией. Убедитесь в том, что уровень документации соответствующий и она содержит только то, что нужно для успешной реализации проекта. Для того, чтобы поднять уровень коммуникации в проекте, используйте визуальное моделирование (ключевой принцип) при любой возможности.
Высококвалифицированная команда проекта
Высококвалифицированная команда проекта, где каждый участник понимает свою роль и как работать вместе с другими, должна составлять ядро вашей команды. Такая команда будет очень эффективна и производительна. Если часть вашей команды не обладает требуемым набором ключевых навыков и компетенций, то вам стоить вложить средства в обучение, нацеленное на реализацию нужд вашего проекта. Но все же, не стоит тратить деньги и главное время на курсы «для всех». Стоит обратить свое внимание на найм необходимых экспертов для помощи команде и ускорение успешного выполнения проекта.
Принятие и использование подхода, основанного на сценариях использования
Сценарии использования очень эффективный инструмент управления требованиями и ожиданиями заказчика, так как они предоставляют контекстное представление требований заказчика к системе. Главная причина, почему вам стоит начать их использовать, является то, что они носят нетехнический прикладной характер и предоставляют пошаговое описание взаимодействия ролей (пользователей системы — людей или другие системы) с системой. Простота использования сценариев является их большим преимуществом.
Часто документы, которые должны содержать полное описание требований к системе, на самом деле содержат лишь список нужд пользователей. Для того, чтобы проект шел вперед, вам необходимо описать все цели и задачи, для этого как раз более всего подходят сценарии использования. Они связывают весь процесс разработки — от сбора требований заказчика до тестирования и сдачи программного обеспечения.
Принятие и использование комплексной системы управления изменениями
Это нечто иное, чем принцип избегания изменений в вашем проекте, рассмотренный в водопадной модели разаработки программного обеспечения. Вместо этого, уделите внимание новым запросам и решайте (c заказчиком), каким образом данные изменения могут быть реализованы. Например, что следует сделать, если дата завершения строго оговорена, а вам предъявлено новое требование? Стоит ли вам в таком случае опустить реализацию какого-либо другого требования в ущерб общему функционалу, или же стоит перенести дату выпуска системы?
Использование инструментов визуального моделирования
Визуальное моделирование — это всего лишь новое название для различного рода блок-схем, которые применялись раньше при разработке ПО. Визуальное сопровождение проекта крайне важно и очень ценится, т.к. помогает быстрее донести идеи и решения до команды проекта и заказчика. Я рекомендую использовать диаграммы в течение всего проекта.
Менеджеру проекта необходимо требовать использования одной определенной системы обозначений от всех участников проекта, начиная от бизнес-аналитиков и заканчивая дизайнерами, программистами и тестировщиками. UML (англ. Unified Modeling Language) — универсальный язык моделирования — является де-факто стандартом разработки схема программного обеспечения и может использоваться для визуализации решений в течение всего проекта. Его использование может быть одним из условий.
На рисках ли ваш фокус?
Я часто работал со различными заказчиками и спонсорами проектов, различными топ-менеджерами и просто техническими специалистами, которые утверждали, что они учитывают, оценивают и контролируют все риски и четко следуют итеративному подходу к разработке. И вы, вероятнее всего, столкнетесь с тем же. Но как узнать, действительно ли ваша команда разработчики следует итеративному методу разработки?
Вот вопросы, которые помогут вам ответить на этот вопрос:
Как долго длится одна итерация?
Правильный ответ — несколько дней, но не больше 4 недель. Ответ «два месяца и более» говорит о том, что процесс разработки до сих пор имеет водопадную модель, которая отличается длинными циклами и связана с большим риском пойти по неверному пути, с большой вероятностью обнаружения и понимания этого в конце разработки, когда ситуацию уже невозможно исправить.
Что является результатом каждой итерации?
Ответом должна быть демонстрация заказчику какого-либо рабочего прототипа системы, с получением обратной связи. Если ответом является документ с одобрением фазы проекта, то команда не понимает сути итерационного метода.
Когда заказчик увидит результат проекта?
Верным ответом на этот вопрос будет – «в конце каждой итерации», а ответ «только во время тестирования перед выпуском» недопустим!
Когда вы начнете тестирование интеграции?
Ответом должно быть то, что тестирование интеграции — это продолжительный процесс, который происходит во время каждой итерации в ходе всего проекта. Но ни как не в конце проекта.
Как вы управляете рисками?
Необходима регулярная оценка рисков, представленная в виде влияния и вероятности рисков на графике разработки. Для рисков должны быть разработаны стратегии избегания и реагирования. Менеджер проекта должен иметь список возможных рисков, который доступен всем участникам проекта. Менеджер проекта должен непрерывно заниматься тем, что называется — снижение рисков проекта.
Длительная непрерывность бизнес-процессов
Что же получит ваш бизнес в результате использования всего вышеописанного опыта?
Мы знаем, что разработка ПО — это очень рискованный бизнес, который требует много времени, затрат и усилий. Но самые большие затраты следуют по завершению начальной стадии разработки, как это показано на рисунке 7, когда система выходит на этап поддержки и сопровождения.
Рис. 7: Структура расходов на разработку ПО
Переняв этот опыт и фокусируясь на разработке ПО, предоставляющего заказчикам то, что им нужно, можно создавать высококачественные системы, подходящие бизнесу лучшим способом. Такие системы легче поддерживать, сопровождать и модифицировать. А это в свою очередь снижает последующие эксплуатационные расходы и вероятность дальнейших рисков в процессе эксплуатации.