Управление разработкой программного продукта на основе рисков
Эта статья адресована тем, кто имеет отношение к разработке программного продукта. Понимание принципов управление процессом разработки не менее важно, чем фактические знания технологий программирования. Статья не адресована только тем, кто хочет стать или работает руководителем проекта (Project Manager), Понимание принципов управления принесет пользу на любой должности и в любой команде.
Перед тем, как перейти к самим техникам управления не плохо осознавать, как вы сами ведете себя в команде проекта. Я выскажу несколько основополагающих принципов взаимоотношений в команде:
• Не врите. Даже если очень страшно сказать правду. Ибо она все равно лучше обмана. Правду надо «одевать», для правильного восприятия, и нужно искать подходящий момент, но нельзя врать. Все равно истина откроется и ущерб будет больше.
• Старайтесь понять вашего коллегу. Будет ли это ваш босс, подчиненный, сотрудник или заказчик — встаньте на его место и поймите, что бы вы хотели на его месте, тогда многие вопросы отпадут сами собой.
• Будьте снисходительны, но не попустительствуйте. Любой человек имеет право на ошибку, но никто не может злоупотреблять доверием.
• Не делайте любимчиков и изгоев. Одинаковые критерии отношения ко всем членам команды основа авторитета.
• Чем менее заметно ваше поведение, тем более оно будет заслуживать внимания — не ругайтесь, не бегайте по офису, не говорите громко. Англичане говорят, что джентльмен не смеется, а улыбается.
Теперь, когда вы стали практически идеальным сотрудником, давайте подумаем — что нужно заказчику, тому кто платит деньги? Он наверняка хочет деньги вернуть, да еще с прибылью. Самые неприятные слова для него — мы не успеваем, у нас не получилось, они дали неверные требования… и еще что угодно, что не даст ему желаемое за его деньги. Все это можно объединить одним понятием — риск потери инвестиций. Именно поэтому, мы будем рассматривать различные техники управления разработкой с позиции рисков. Можно с гарантией сказать, что в процессе разработки вам встретятся непредвиденные ситуации, причем не в вашу пользу. Они то и являются рисками. Если не попытаться проанализировать и предположить возможные неприятные ситуации заранее, то придется все время находиться в ситуации спасения проекта и защиты от «нежданных сюрпризов». Для примера можно привести до боли знакомый случай, когда жесткий диск перестает читаться именно тогда, …, а резервные копии увы… Так что друзья, без анализа неприятностей наперед, придется встречать их в самый неподходящий момент. Следует так же помнить, что риск — это не всегда потеря денег заказчика, но зачастую другие негативные эффекты — потеря доверия, будущих заказов или возможного повышения в должности.
Однако не стоит относиться к рискам, как к чему то однозначно отрицательному. Зачастую, появившаяся неприятность, заставляет нас мобилизоваться, найти нестандартное решение, быстро выучить предметную область и уж точно позволит запомнить метод решения и выработать защиту на будущее. Без рисков жизнь была бы скучна.
Вместе с тем, не существует ни одной единой методики управления проектом, даже если риски были бы сами по себе однотипны. Так же, как не существует идеального языка программирования, операционной системы, средств тестирования и пр. Разработка методики управления проектом — это так же проект. И здесь важны следующие входные факторы:
• Степень готовности проекта в голове заказчика, а соответственно наличие материалов, описывающих, что надо разработать. Здесь так же следует учесть подверженность изменениям проекта в силу внешних обстоятельств, когда сам документ описывающий задание, претерпевает изменение. Например поменялась версия операционной системы.
• Характеристики команды разработчиков. Не только с точки зрения профессиональных навыков, но и навыков командной работы, готовности к критике и личным неудобствам.
• Размер проекта во времени и ресурсах (людях).
• Требуемая надежность продукта и правильность методов реализации
В самом начале необходимо понять насколько проект сформирован у заказчика:
• Есть точное представление о запрашиваемом продукте. Например, разработать протокол связи описанный в стандарте.
• Или у заказчика примерное представление о проекте. Например, разработать систему поиска в интернете с заданными опциями и параметрами. Однако очевидно, что в процессе разработки, могут меняться критерии и их взаимосвязь друг с другом.
• Может быть заказчик имеет очень общее представление. Например у клиента есть система Унифицированных коммуникаций, нечто вроде «все в одном» для целей общения в компании. И теперь стоит задача разработать дополнительные «плюшки». Есть список из многих вариантов, но клиент еще не знает, что бы лучше, выгоднее разработать сначала, а что потом. А выгоднее для него — это отношение интересно/затратно.
Определим управление разработкой на основе анализа рисков, как последовательность действий по упреждающему определению отрицательные события в процессе выполнения проекта, и шагов по минимизации вреда проекту от них. Имейте ввиду, что абсолютно избавиться от потерь связанных с рисками не возможно, как не возможно человеку не болеть. Но можно выделить наиболее критичные и дорогостоящие риски, быть готовыми к ним и контролировать их возникновение.
По статистике только 28% программных проектов завершены в срок и в рамках бюджета, 23% разработок отменяются до завершения, и половина проектов превышает бюджет на 50%. Вы получите значительно более спокойную жизнь в конце проекта, если подумаете о возможных проблемах в начале и не будете закрывать глаза на возникновение «нештатной» ситуации в процессе разработки.
Управление рисками включает в себя две группы действий и точку переосмысления (принятия решения об изменении — Дизайн). Первая группа это Оценка рисков и вторая Управление рисками.
Оценка риска, в свою очередь, включает в себя выявление, анализ и приоритезацию рисков. Управление рисками включает в себя планирование, противодействие и мониторинг рисков.
Выявление рисков.
В этой части команда или ее руководитель должны составить список всех возможных неприятностей, ожидающих проект при его реализации. Риски могут быть разделены на Социальные и Технологические. К социальным рискам будут относится все риски не связанные непосредственно с технологией. Например потеря ключевого специалиста (болезнь, увольнение) или временное отключение электричества, интернета, изменение требований к проекту и др. К технологическим рискам относятся все те аспекты, которые могут возникнуть из-за неправильного выполнения задания, не важно по чей вине. Это может быть неверно сформулированное задание, неудобный фреймворк, несогласующийся интерфейс между модулями и пр.
Список рисков должен включать в себя:
• Условие возникновения риска и его описание
• Симптомы его заблаговременного обнаружения (если возможно)
• На что повлияет случившийся риск (время, деньги, репутация)
• Что случиться если риск станет событием и мы не сможем противодействовать ему
Анализ
Когда список рисков готов, переходим к их анализу. Для каждого риска выявляются:
Вероятность возникновения и тяжесть наносимого вреда. Обе характеристики квантуются примерно из 4х величин от «мало» до «большой». Оценку вероятности проводят в команде как мозговой штурм. Существует много методов оценки вероятности возникновения риска. Я здесь приведу некоторые из них:
• На основании сравнения с историей подобных проектов
• Покер метод, когда каждый участник в тайне ставит оценку и потом сравнивают результат. Берут за основу либо чаще всего полученную оценку, либо средне арифметическое.
• Групповой метод оценки каждого риска в небольшой группе и представление его всей команде.
• Метод «адвоката дьявола». Риски разбираются командой и каждый пытается обрисовать его в самом плохом виде. В конце может быть устроен «торг» рисками для выявления менее и более вероятных.
Каждый из методов, повторяется в нескольких итерациях до прихода к понятной величине для каждого риска.
В итоге обсуждения должна появиться таблица похожего содержания
| Приоритет | Описание риска | Симптомы | Вероятность | Вред | Был Уровень | Противодействие |
Такая таблица не должна содержать слишком много пунктов, их должно быть 1–2 на количество участников проекта. Так, если группа насчитывает 5 человек, то нет смысла иметь более 10ти рисков. При группе в 20 и более человек необходимо делить риски по группам, а коллективная оценка не должна превышать общее количество сотрудников.
Приоритезация
Риски выстраиваются в порядке — самый существенный первый. Приоритет вычисляют по формуле (в системе исчисления размерности оценки, в нашем случае 4):
Приоритет = Вероятность х Вред
Планирование
Планирование должно быть сделано для каждого риска в отдельности. Так же в таблицу заносятся симптомы возникновения риска, которые могут указывать на приближение события.
Противодействие
Существует два подхода к защите от событий риска — избежать и защититься. Полная аналогия с реакцией на удар. Можно либо от него уклониться либо поставить защиту. Однако любая защита имеет свою цену. Так например, защита информации на диске имеет стоимость резервного диска и действий по систематическому бэкапу. Но в более сложных ситуациях, бывает так, что сама система защиты становиться коммерчески неоправданной. Поэтому для противодействия выводят формулу ее эффективности:
Эффективность защиты = (Стоимость риска до противодействия — Стоимость риска с применением противодействия) / Стоимость противодействия.
Понятно, что если эффективность ≤ 1, то применение такого противодействия не целесообразно.
Мониторинг
Когда все элементы разработаны и таблица рисков заполнена, команда начинает работу над проектом и следит за возможным наступлением риска или его упреждающих симптомов. Риски должны пересматриваться с определенной регулярностью, например раз в неделю, но не позже «демо» или сдачи фазы работ. Если используется метод управления «Stage and Gate», то после прохождения каждых ворот вся таблица пересматривается. В результате пересмотра риска и изменения его положения в таблице, прежний уровень риска записывается в колонку «Был уровень». Это дает возможность команде отслеживать динамику изменения риска и соответственно понимать, точку приближения риска или прохождения его.
Ключевым моментом в эффективном управлении проектом на основе рисков является постоянный обмен информацией между участниками команды, руководством и заказчиком. Это важно! Без обмена информацией по рискам, вы будете как полководец без разведки.
Есть две основополагающие техники разработки программного продукта — Последовательное проектирование и проектирование методом итераций. Большинству разработчиков известны такие термины как Waterfall и Agile методы. Ниже мы рассмотрим правильный баланс использования их в применении к модели управляемой рисками на основе пятиступенчатой модели Б.Бема и Р.Тернера.
Но сначала необходимо отметить плюсы и минусы обоих технологий
| Waterfall | Agile | |
|---|---|---|
| Возможность клиента корректировать разработку | Низкая. Основа разработки документ HLD / LLD* или ТЗ | Высокая. Разработка ведется этапами и каждый следующий этап обсуждается перед началом реализации |
| Надежность решения | Высокая, в рамках описанного функционала | Низкая. В большей степени реализуется идея |
| Объем ресурсов | Большие группы | Малые группы |
| Продукт получается | Медленно | Быстро |
| Правильность выбранной архитектуры | Продумано и проанализировано. | Приносится в жертву быстрому решению |
| Процент юниоров | Может быть большой под руководством экспертов | Не большой — все члены команды зависят друг от друга |
* HLD — High Level Design, LLD — Low Level Design
Одним из основополагающих факторов в данной модели являются характеристики команды. Бем и Тернер разработали шкалу квалификации сотрудников:
| Уровень | Характеристика | Подходящая модель |
|---|---|---|
| 3 | В непредвиденной ситуации, может пересматривать инструкции метода разработки самостоятельно | Годиться для работы в любой модели. Как правило является руководителем звена |
| 2 | Может адаптировать метод под ситуацию. После некоторой практики может перейти в уровень 3 | Хорошо применим для Agile группы или небольшой Waterfall, как Team Leader |
| 1А | Имеет опыт нескольких проектов и в состоянии оценить ресурсы/риски небольших задач | Применим в обоих моделях под руководством Team Leader |
| 1B | Программист или тестировщик с небольшим опытом | Не желателен в Agile команде. |
| -1 | Может иметь технические знания, но плохо сотрудничает в команде. | Можно использовать как FreeLancer или консультант, но не как участник обоих методик |
Удачное управление проектом использует обе методики, но одна из них должна быть выбрана за базовую. Ниже приведена таблица определения базовой модели управления проектом:
| Характеристики проекта | На базе Agile | На базе Waterfall |
|---|---|---|
| Область применения | ||
| Основная задача | Быстрая выдача результата. Не до конца определенная задача. | Архитектурная правильность, производительность, надежность. |
| Размер | Небольшие команды и проекты | Большие команды и проекты |
| Среда | Высокая изменчивость | Низкая изменчивость |
| Управление | ||
| Взаимоотношения с клиентом | Нацеленность на удовлетворение клиента | Нацеленность на выполнение ТЗ |
| Планирование и контроль | Группа сама осуществляет контроль и планирование | Удовлетворение описанным в плане требованиям |
| Передача информации | При личном тесном общении | Определено документом |
| Технически | ||
| Требования | Приоритезированы и оформлены в виде историй. Могут легко меняться заказчиком | Описаны в ТЗ и редко меняются в соответствии с ТЗ, как правило уточнения |
| Развитие | Простой дизайн, небольшие шаги разработки | Обширный дизайн, большие изменения за шаг итерации. |
| Тесты | Автоматические с пере использованием и постоянным развитием. | Документированы, как правило в виде тестов «черного ящика» |
| Персонал | ||
| Доступность заказчика | Доступен легко и часто | Отделен и часто не доступен |
| Команда | По крайней мере 30% уровень 2 и 3. Почти нет 1В | От 10% уровень 3 и до 30% уровень 1В |
| Внутреннее устройство команды — культура | Команда готова брать ответственность и пользоваться свободой | Свободы и ответственности ограничены в рамках трудового договора |
На основании следующей таблицы выбирают базовый метод управления проектом. Бем и Тернер выделили пять факторов для определения базовой модели. Они представлены в таблице ниже:
| Фактор | Agile | Waterfall |
|---|---|---|
| Количество разработчиков в группе | Небольшая группа. Каждый участник отвечает за все. Личное доверие и коллективная мотивация в группе | Годиться для больших групп и проектов. Взаимоотношения формализованы в рамках договора |
| Надежность и устойчивость продукта | Слабо тестирован и мало надежен. Не документирован и часто не попадает в требования. Эффективен при прототипировании | Применим для критически важных продуктов. Трудно применим для прототипирования |
| Изменчивость | Простота дизайна и легкость в реализации. Риск высокой стоимости при переносе в надежный релиз | Пригоден для хорошо документированных продуктов, например реализации протоколов. |
| Персонал (квалификация команды), ее уровень | Должна быть постоянно критическая масса 2–3 уровня. Опасно использование 1В уровня | Критическая масса 2–3 уровня необходимо только на стадии проектирования. Применимы сотрудники уровня 1В |
| Внутреннее устройство группы — культура | Высокая свобода внутри группы с коллективной ответственностью | Действуют в рамках трудового договора с высокой трудовой защищенностью. |
Для визуализации проекта была разработана полярная диаграмма.
Чем ближе проект находиться к центру диаграммы, тем более он подходит для Agile метода, как базы для проекта.
Ну и наконец, когда базовый метод выбран, переходим к корректировке с использованием альтернативного метода.
В итоге процесс формирования концепции управления проектом на базе анализа рисков приобретает 5 шагов:
Первый шаг — анализ рисков:
Проектирование таблицы рисков.
Оценка рисков для Agile и WaterFall методик
Шаг второй — сравнение рисков:
Если выявлен базовый метод, то переходим к шагу 4.
Если его выяснить однозначно не удается — идем в промежуточный шаг №3
Шаг три — архитектурный анализ:
Если однозначного результата по базовому методу получить не удается или некоторые части находятся внутри зоны Agile, а некоторые снаружи, команда пытается вычленить те участки проекта, где методология Agile наиболее применима, а остальная часть делается по Waterfall.
Шаг четвертый — построение жизненного цикла разработки:
Команда следует намеченному базовому методу разработки сверяя себя с рисками таблицы из шага №1.
Шаг пятый — выполнение и мониторинг:
Команда постоянно пересматривает риски и приходя в точку Дизайн переписывает таблицу рисков.
На блок диаграмме ниже графически представлена схема процесса разработки на базе анализа рисков и балансировки двух методик — Waterfall и Agile
Следует учесть, что в методике разработки должны участвовать руководители групп и ведущие программисты. В то время как юниорам лучше не присутствовать на Скрам митингах.
Успешных вам проектов друзья!
Использованные Источники:
Boehm, B. and R. Turner (2003). Balancing Agility and Discipline: A Guide for the
Perplexed. Boston, MA, Addison Wesley.
Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide. Boston,
Addison Wesley.
