|
 Плохое управления проектом по разработке ПО зачастую выглядит как невыполнение работы в срок, перерасход бюджета или даже крах проекта. Каким образом ваша компания может избежать этой проблемы индустрии? В данной статье вы получите лучшие советы для успешного завершения проекта по разработке ПО.
Проекты по разработке ПО полны рисков и угроз краха. Согласно отчету 2006 года от The Standish Group, всего лишь треть (35%) изученных проектов по разработке ПО, выполняемых в предыдущие годы, считались "успешными", то есть они выполняли все требования и были завершены в срок, при этом не превышая бюджет. Около половины проектов (46%) были отмечены как "проблематичные", поскольку они были завершены, но продукт был предоставлен позже установленного срока, разработка превысила бюджет, или же товар не поддерживал всю требуемую функциональность. 19 процентов проектов считались проваленными или закрытыми до завершения. Согласно отчету, 41 цент каждого доллара, потраченного на разработку ПО, считаются выброшенными. Все, кто вовлечены в проекты по разработке ПО, знают, почему достижение успешного завершения настолько трудоемкий процесс. Наиболее часто упоминаемыми факторами, которые могут помешать на этом пути, являются: - Плохой уровень общения. Легендарная щель в общении между разработчиками и клиентами или заинтересованными лицами зачастую приводит к плохо определенным требованиям, что в свою очередь приведет к неадекватно разработанному ПО, которое не предоставляет требуемую клиентам функциональность.
- Время. Быстрое развитие и изменение рыночных сил ведет к тому, что чем дольше выполняется проект, тем меньше шансов у разработчиков предоставить такое ПО, которое будет удовлетворять текущим нуждам клиента. Требования и приоритеты могут меняться несколько раз за то время, пока происходит планирование, тестирование и выполнение проекта.
- Масштаб. Плохой уровень общения и увеличение масштаба, а также высокий уровень конкуренции рынка могут привести к изменению масштаба, особенно в случае, когда требования часто изменяются и добавляются в проект без должного уровня оценки их истинной ценности, а также без соответствующего увеличения ресурсов, бюджета и выделенного времени. Проект, масштаб которого очень широк, станет слишком сложным, превысит бюджет не уложится в сроки и, в конце концов, будет провален. Проект, масштаб которого был определен слишком четко, может быть завершен в сроки, но, скорее всего, не сможет удовлетворить истинные требования клиента.
- Плохо организованный процесс разработки. Несмотря на доступные данные о лучшем опыте в разработке ПО (такие как модель (СММ) интегрирования завершённого программного обеспечения института по разработке программного обеспечения), многие отделы по разработке не следуют логической методологии. Исследования, проведенные SEI в 2005, показывают, что относительно качества процессов разработки практически 40% компаний дают себе 1- 2 балла из возможных 5 по шкале CMMI.
- Бюджет, ресурсы и график. Разработка ПО зачастую сопровождается нереально низким бюджетом, неадекватными ресурсами и ограниченными временными рамками.
- Риски. Успех множества ИТ-проектов, в частности разработки ПО, во многом зависит от эффективного управления рисками как на ранних стадиях, так и на протяжении всего цикла проекта. Не так давно риски определялись практически только в негативных тонах, но за последние пару лет философия управления рисками была расширена и теперь включает в себя и положительные возможности. Риск может быть определен как что-то неточное - неточности, при их наличии, могут навредить проекту, но они также могут ему и помочь.
К примеру, новые кадры могут принести новый опыт, что положительно скажется на проектах. Компания может обнаружить неизвестный ей ранее код, который можно использовать повторно. Определенные части проекта могут быть завершены раньше, что откроет новые перспективы, казавшиеся до этого невозможными. Вы можете надеяться либо на удачу, либо же быть активнее и искать такие возможности. Существует множество подходов к управлению рисками. Наиболее известным из них наверняка является тот, который перечислен в своде знаний по управлению проектами(PMBOK - Project Management Body of Knowledge), опубликованом институтом управления проектами (PMI), и считается библией для многих руководителей проектов. Как любой религиозный текст, PMBOK имеет своих последователей и оппонентов, тем более что существуют также и альтернативные методологии. Однако многие подходы к управлению рисками следуют общим шагам, описанным ниже. Шаг #1: определение Определение рисков проекта обычно выполняется посредством собраний, в которые вовлечены участники проекта и команда разработчиков. Включение в данный процесс всех заинтересованных сторон очень важно для развития хороших каналов общения и получения полного понимания всех рисков, связанных с проектом. К примеру, финансовый календарь компании может влиять тогда, когда определенные бухгалтерские или другие финансовые системы должны быть установлены. Учет представителей владельцев проекта также служит способом увеличения их опыта, доступности и способности к принятию решений относительно их части проекта. В случае с разработкой ПО многие из анализируемых рисков будут выведены из факторов, указанных выше (то есть общение, время, масштаб). Эксперты в управлении рисками следуют двум основным принципам. Первый заключается в избегании свободного, не конкретизированного обсуждения. Собрание должно быть спокойным и структурированным. Свод PMBOK включает в себя структуру декомпозиции рисков (RBS), которая может помочь компании отметить риски иерархическим и более детальным способом. Другим полезным инструментом для работы с внутренними и внешними угрозами и возможностями является SWOT -анализ (достоинства, недостатки, возможности, угрозы). Он также пригоден для создания и адаптирования списков рисков, взятых с предыдущих похожих проектов, что может помочь в текущем проекте. Второй принцип успеха в определении рисков заключается в обеспечении того, чтобы собрание не стало пустым занятием, сделанным ради соответствия стандартам , так сказать , для галочки. Проблема заключается в том, что люди зачастую выполняют данные шаги без приложения усилий и ума. Все заканчивается заполнением формуляров, но с упущением истинного предназначения. Политика компании играет большую роль в управлении рисками проекта, и избегание риска зачастую также включает факторы, которые находятся за пределами проекта. Эти факторы должны быть игнорированы. Вся идея данного процесса заключается в том, чтобы вы мыслили за рамками привычного мышления - настоящее управление рисками заключается в исключениях в повседневной работе. Шаг #2: взвешивание и придание приоритетов Как только вы отметили найденные риски, команда должна придать им приоритеты относительно вероятности и уровня влияния. Определенные риски могут уничтожить проект – вот почему, даже если их вероятность низка, они все же должны быть отмечены высоким приоритетом. Риски, которые обладают низким уровнем влияния и низкой вероятностью, зачастую могут быть проигнорированы. На этом этапе хорошо было бы отметить определенные ранние знаки для каждого риска. Шаг #3: разрешение проблем Следующим шагом будет разработка стратегии разрешения каждого риска. Классическими стратегиями являются: - Избегание. Иногда есть возможность использовать стратегию полного избегания риска. К примеру, существует ведь риск того, что определенный поставщик предоставит важную часть слишком поздно, тем самым вы можете не вложиться в установленные сроки. В таком случае вы можете просто найти другого поставщика.
- Снижение уровня. Успех могут обеспечить некоторые способы уменьшения риска, которые включают в себя: планирование чрезвычайных обстоятельств и затрат; вовлечение новых членов команды, которые обладают опытом и могут взять на себя выполнение задачи в случае, если кто-то покинет команду; создание положительных отношений с людьми, находящимися за пределами команды, но чье партнерство может быть жизненно важным. Следует избегать ситуации, когда потеря одного члена команды может быть чревата значительной отсрочкой проекта. В каждой организации существует сеть людей, находящихся вне организации, но которые тем не менее выполняют определенные - составьте свою команду таким образом, чтобы вы были вовлечены в такую сеть с самого начала. Наиболее правильным путем станет подбор команды, состоящей из людей гибких и готовых приспосабливаться к новым обстоятельствам.
- Передача риска. Иногда вы можете передать ответственность за определенные риски поставщикам, внешним консультантами или даже заинтересованным лицам.
- Принятие факта. Влияние и вероятность рисков иногда может быть минимальна, и в таком случае вы можете даже и не беспокоиться о них.
Опять-таки, хорошей идеей является ведение учета успешных стратегий из прошлых проектов, которые могут пригодиться для разрешения рисков текущего проекта. На данном этапе вам стоит назначить ответственных за определение и разрешение каждого риска. Шаг #4: наблюдение Закон Мёрфи присутствует практически в каждом проекте. Частые обзоры рисков должны быть выполнены для того, чтобы постоянно наблюдать за знаками, оповещающими об их возникновении, оценивать прогресс в определении рисков, закрывать некоторые риски и находить новые, которые ранее не были замечены. Также важны постоянное обсуждение прогресса с участниками проекта и передача профиля риска. Тут вам стоит оценить вероятность больших проблем в вашем проекте. Некоторые ключевые оповещающие знаки, такие как высокий уровень неразрешенных проблем, постоянное несогласие в том, что должно быть сделано, и раннее несоответствие с графиком - любые из этих условий могут означать необходимость в переоценке всего профиля управления рисками и стратегии реализации проекта. Шаг #5: запись Обзоры после завершения проекта могут быть очень полезными для планирования будущих проектов. Вам стоит выполнить конечную оценку проекта - от старта до завершения. Сравните риски, которые вы уже определили, с теми, с которыми вам в конечном итоге пришлось работать, какие стратегии были успешными, и что вам стоит сделать по-другому в следующий раз. Запишите данную информацию и используйте ее для создания списков, которые будут доступны при следующем похожем проекте. Техника гибкой разработки (Agile) В последние годы гибкая модель разработки получила большую популярность в качестве пути снижения уровня рисков, связанных со временем, масштабом и общением. Вместо того, чтобы выполнять весь проект разом, методика гибкой разработки предлагает пошаговую разработку конечных отдельных частей. Программное обеспечение по своей природе развивается, поэтому проекты, которые растягиваются на длительное время, в большей степени обладают высокой вероятностью потерпеть крах. Вам стоит выполнять все менее чем за 6 месяцев. Если суть дела поменяется, вы всегда сможете сделать что-то иначе. Будьте реалистом Структурированный процесс управления рисками жизненно важен для успеха, но также необходимо сопоставить структуру, размер и тип проекта с философией вашей организации. Процесс управления рисками должен иметь возможность быть расширенным. Маленький проект, скорее всего, требует немного усилий – наверняка достаточно одночасового собрания каждую неделю. С другой стороны, большому проекту в большой компании, при наличии множества заинтересованных лиц и участников, может понадобиться высокоструктурированный детальный подход к управлению рисками. Тем не менее, скорее всего, важнее будет культивация культуры организации, в которой каждый понимает и живет принципами инстинктивного управления рисками. Ваша компания должна принять такую позицию, которая ставит управление рисками на высший уровень важности.
Newer news items:
Older news items:
|
