-
Владислав Балин
Модуль
-
С 1996 до 2000 года занимался разработкой и внедрением корпоративных информационных систем для торговых и производственных компаний в качестве аналитика, архитектора, разработчика и менеджера проектов.
С 2000 по 2005 год работал в компании CQG Int., занимался разработкой ключевых алгоритмов многозадачности, сервера хранения и обработки котировок, и интерпретатора встроенного языка обработки данных.
С 2006 года руководит разработкой ПО в области телекоммуникаций, программно-аппаратных комплексов и микроэлектроники. Является экспертом по управлению высокотехнологичными проектами в условиях присутствия больших технических рисков.
Сертифицированный Carnegie-Mellon SEI инженер по PSP/TSP. Окончил факультет Вычислительной Математики и Кибернетики МГУ им. Ломоносова в 1998 году. Известен на форумах RSDN и в ЖЖ под ником Gaperton.
Природа рисков в разработке ПО или почему плохо работает классический риск-менеджмент
Есть распространенный в форумах вопрос от руководителя небольшой группы программистов ("тим-лидера"). Он повторяется относительно регулярно, с небольшими вариациями:
- Помогите проанализировать риски! Мне ничего, кроме того, что "программист Вася заболел", в голову не приходит!.
Руководитель недавно ознакомился к классическими подходами к управлению рисками. Прочитал книгу, или сходил на тренинг. Все разумно, доступно, и понятно. И он пытается составить таблицу с планом рисков для своего текущего проекта, как положено. Вероятность. Серьезность. Описание риска. Меры противодействия. Но почему-то, несмотря на то, что в тренингах все проходило гладко, когда он берется за _свой_ проект, в голове моментом образуется звенящая пустота, и ничего осмысленного не приходит в голову...
...означает-ли это, что в его проекте нет рисков?
Нет. Более того, известно, что, независимо от масштаба проекта, разработку ПО отличает от других видов проектной деятельности невероятно большое количество рисков. Хорошим индикатором наличия которых являются как затруднения выдать прогноз сроков работ, так и частота вылета проектов за график.
В чем же тогда дело? Почему у тим-лидов возникают затруднения в составлении плана рисков по классике? И почему его наличие плохо помогает им делать реалистичный прогноз сроков - ведь раз план рисков есть, то риски вроде как учтены?
Причина в том, что значительная доля рисков в разработке ПО имеют особенную природу. И, если ее учитывать, над большинством из них мы имеем прямой контроль.
В докладе будет будет рассмотрена природа технологических рисков, и показана их взаимосвязь с процессом проектирования, планом работ, и процессом разработки в целом.
Также, будут рассмотрены методы управления рисками, которые в инженерной деятельности работают. Они достаточно сильно отличаются от содержимого классических курсов по управлению рисками. Они очень просты в понимании и применении. Они помогают составить реалистичный план работ, и повысить вероятность успеха проекта.
