- PVSM.RU - https://www.pvsm.ru -
«Риски и выгода всегда ходят рука об руку» (с) Том Демарко, Тимоти Листер.
6 декабря 2013 года в Казани состоялась 3-я Международная конференция в области управления проектами «Software Project Management Conference» [1]. В своем выступлении я попытался рассказать о главном, что надо знать об управлении рисками в программном проекте.
Разработка продукта длилась 5 лет вместо одного года. Бюджет проекта был превышен более, чем в 5 раз.
Руководителю проекта разработки ПО надо уметь делать немногое. Надо лишь уметь управлять рисками. Рисками не уложиться в срок. Рисками сделать не то, что требуется. Рисками перерасходовать проектный бюджет. Всё остальное – производные активности.
Можно, разумеется, рисками не управлять. Чувствовать себя Ником Валлендом [2] от разработки ПО и ходить по канату без страховки нацеливать себя и свою команду исключительно на благоприятное развитие событий.
Таким большим оптимистам можно дальше и не читать. Для остальных продолжу.
Бытует мнение, что каждый новый проект разработки является уникальным предприятием. Это не совсем так. В отрасли уже накопился определенный опыт и большинство значимых рисков проектов разработки ПО известны и собраны коллекции (контрольные списки) грабель, на которые особенно часто наступают начинающие руководители программных проектов, предпочитающие учиться на собственном опыте.
Оговорюсь сразу, что самый значимый риск в разработке ПО – неадекватный РП [3]. Но сейчас не об этом.
(с) Barry W. Boehm. «A Spiral Model of Software Development and Enhancement», Computer, May 1988 [4]
И что теперь с этим делать?
Как это происходит в обыденной жизни. Предположим нам надо доставить очень ценный груз через горный перевал. Мы можем: уклониться от риска обойдя горный хребет; передать риск, наняв вертолетную компанию; снизить последствия риска, вбивая страховочные костыли через каждые пять метров подъема, и, наконец, принять риск и ничего не делать.
О чем следует помнить. Надо понимать, что реагирование на риски — это всегда затраты. Поэтому не стоит планировать мероприятия, направленные на борьбу с риском, стоимость которых превышает убытки от реализации самого риска. И еще, управляя рисками, мы меняем наш план. Поэтому стоит проанализировать вторичные риски, связанные с этими изменениями.
О каких требованиях обычно забывают. Функциональные: программы установки, настройки, конфигурации, миграция данных, интерфейсы с внешними системами, справочная система. Нефункциональные: производительность, надежность, открытость, масштабируемость, безопасность, портируемость, эргономичность. Заказчик, как правило, предполагает, наличие подобных требований по умолчанию. Поэтому разумно, не дожидаться приемо-сдаточных испытаний и обсудить с заказчиком все эти требования на этапе подготовки контракта.
Методы реагирования: переоценка проекта каждый раз, когда требования добавляются; итерационная разработка; контракт на основе «Time&Materials»; учет (резервирование) в оценках трудоемкости и сроков возможности роста требований, например, на 50%.
Что делаем: устанавливаем доверительные отношения с заказчиком, непрерывно с ним взаимодействуем, прототипируем и согласовываем пользовательские интерфейы, периодически ставим тестовые версии конечным пользователям.
Как можно бороться: привлечь экспертов-консультантов на начальных этапах, учесть в оценках обучение сотрудников, уменьшить потери от текучести кадров, привлекая избыточное число участников, учесть в оценках «время разгона» для новых сотрудников.
Работы в вашем проекте: обучение, координация, уточнение требований, управление конфигурациями, поддержка автосборки, разработка автотестов, создание тестовых данных, обработка запросов на изменения. Проходим по списку и работы, которые нужны в проекте, оцениваем и включаем в план. Другие, как правило, более оприоритетные работы, на которые будут тратить время участники: сопровождение действующих систем, повышение квалификации, участие в пресейлах, административная работа, отпуска, праздники, больничные. Боремся, планируя загрузку бойцов в проекте на 60-80%.
Как боремся, в этот пост, к сожалению не поместится. В другой раз.
Конечно, вряд ли кто-нибудь когда-нибудь составит исчерпывающий список всех возможных рисков программного проекта. Думать своей головой никто не отменял. Необходимо внимательно изучать особенности вашего конкретного проекта. Но начинать анализировать риски разумно с исследования наличия на вашем пути уже хорошо известных перечисленных граблей.
Успехов!
Автор: craft_brother
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-riskami/56010
Ссылки в тексте:
[1] «Software Project Management Conference»: http://spmconf.ru/ru/index-news.sdf/spmconf/spmconf3
[2] Ником Валлендом: http://www.rbc.ru/rbcfreenews/20130624071138.shtml
[3] неадекватный РП: http://citforum.ru/SE/project/antipatterns/
[4] (с) Barry W. Boehm. «A Spiral Model of Software Development and Enhancement», Computer, May 1988: http://csse.usc.edu/csse/TECHRPTS/1988/usccse88-500/usccse88-500.pdf
[5] (с) Том Демарко, Тимоти Листер, «Вальсируя с Медведями. Управление рисками в проектах по разработке программного обеспечения», М., Компания p.m.Office, 2005: http://www.ozon.ru/context/detail/id/2314340/
[6] Матчасть.: http://marketplace.pmi.org/Pages/ProductDetail.aspx?GMProduct=00101388701
[7] мы: http://www.mcc.rsa.ru/
[8] используется и теперь уже для МКС: http://news.rambler.ru/11891561/
[9] Источник: http://habrahabr.ru/post/214029/
Нажмите здесь для печати.