Что необходимо сделать руководителю проекта в случае обнаружения нереальных требований
Как управлять рисками IT-проекта
Если какая-нибудь неприятность может произойти, она случится — гласит закон Мерфи. И сфера ИТ не исключение.
Команда SEBEKON рассказывает, как работать с рисками в IT-проекте, чтобы риски не стали управлять проектом.
В этой статье под IT-проектом подразумевается разработка сложного веб-ресурса — например, b2b-портала или интернет-магазина с множественными интеграциями с внешними системами.
Дилемма управления рисками любого IT-проекта простая: перестраховаться и заложить все угрозы в бюджет проекта, который вырастет до небес, или пропустить часть рисков — и тогда будет велика вероятность не завершить проект вовсе или получить неудовлетворительный результат.
Но даже если принять первый вариант как единственно верный, от рисков никто не застрахован.
Менеджер проектов компании SEBEKON
Генеральный директор компании SEBEKON
Как работать с рисками
Обычно ожидаемая реализация проекта не совпадает с реальной работой:
На практике управление рисками — это тонкий баланс между разумным и достаточным.
Существуют пять основных инструментов для работы с рисками:
Рассмотрим каждый из них подробнее.
Выявлять риски
Риски проекта определяются во время фиксации требований к проекту и отражаются в уставе или концепции проекта.
Устав проекта ― это документ, в котором зафиксирована основная информация о проекте: потребности заказчика, бизнес-задачи, высокоуровневые требования к проекту, критерии успешной реализации.
Концепция проекта ― документ, в котором собраны подробные характеристики проекта.
Выбор документа зависит от масштаба проекта.
Чтобы выявить риски, нужно проанализировать множество информации и сопоставить, как те или иные факторы влияют на возникновение рисков.
Рассказываем, что стоит сделать для этого.
Учесть опыт предыдущих проектов
Для примера возьмём согласование дизайна страниц сайта.
Дизайн всегда субъективная история, и нужно закладывать дополнительное время на решение вопросов в стиле «а давайте попробуем немного светлее или поиграем со шрифтами». Заказчик должен ещё до начала работ понимать, что любое изменение, требующее нескольких минут работы, в итоге выливается в часы и дни согласования.
Часто на стороне заказчика необходимо согласовать дизайн с несколькими департаментами — и не всегда сотрудники этих отделов могут быстро подтвердить изменения. Если речь идёт о крупной компании, то руководителю проекта придётся назначать собрание или созвон для обсуждения дизайна. И не всегда это получится сделать в ближайшие дни — часто согласование растягивается на недели, а то и на месяцы.
В нашей практике были разные проекты, но редко, когда удавалось согласовать дизайн в первой же итерации и по ходу работы не менять его. Гораздо чаще приходилось сдвигать сроки работ, потому что представители заказчика не смогли оперативно обсудить дизайн и согласовать его.
Оценить новизну критичных требований — как для заказчика, так и для исполнителя
Например, в проекте предполагается разработка нового функционала, которая требует совместной работы нескольких подразделений на стороне заказчика и дополнительных исследований на стороне исполнителя. Всё это увеличивает сроки согласований и влияет на срок проекта.
Принять во внимание особенности внутренней инфраструктуры заказчика
Самый очевидный пример ― требования к безопасности, которые могут существенно отодвинуть срок старта проекта. Это связано с необходимостью получения доступов в систему заказчика или требований по использованию определённого, разрешённого на стороне заказчика ПО, которые повлекут за собой дополнительную проработку архитектуры проекта.
Не забыть про покупку серверного оборудования или про согласование хостинга
Если про покупку хостинга заказчики обычно помнят, то про серверное оборудование в проектах могут забыть и не заложить в бюджет стоимость оборудования, лицензий, а также время на заключение договора с поставщиком оборудования и его доставку.
В зависимости от проекта серверное оборудование может быть стационарным — шкафы с оборудованием — или облачным, когда проект размещается в виртуальном пространстве.
Напоминание заказчику о закупке серверного оборудования на первых же обсуждениях проекта позволит избежать досадных простоев в работе.
Заложить внедрение интеграции проекта с внутренними системами заказчика
Об этом часто забывают, поскольку обычно в организации заказчика под проект выделяются не специально нанятые люди, а текущие сотрудники, у которых есть другая, основная работа. Они воспринимают новый проект как нечто второстепенное, что можно делать по остаточному принципу.
В итоге когда приходит время интеграций проекта с CRM-, ERP- и другими системами работа останавливается на неопределённый срок, потому что менеджер проекта со стороны заказчика не может оперативно подготовить необходимую документацию и доступы для интеграций.
Выявить заинтересованность в проекте ключевых стейкхолдеров
Стейкхолдеры ― это не только топ-менеджмент, но и будущие пользователи и эксперты, которые хорошо разбираются в вопросе и могут помогать с проектом или же оказывать негативное влияние.
На начальном этапе стоит понять, как взаимодействовать с так называемыми негативно настроенными стейкхолдерами, чтобы они не вредили реализации проекта. Под негативно настроенными мы понимаем не тех, кто намеренно вставляет палки в колеса, а тех, кто не понимает последствий от своих решений.
В нашей практике не раз случалось, когда некоторые стейкхолдеры не глядя согласовывали ТЗ, а на этапе тестирования готового проекта выяснялось, что всё должно быть совсем не так.
Например, руководитель департамента логистики должен был проверить сценарий по расчёту доставки товара. Но он был занят текущей деятельностью, мельком просмотрел ТЗ и отправил с пометкой «принято». В ходе тестирования этого сценария оказалось, что он должен быть реализован другим способом. В итоге пришлось откатить проект назад: пересмотреть внесение правок в сценарий, затем внести эти правки в ТЗ, согласовать это со всеми стейкхолдерами, переделать сценарий и заново его протестировать. На всё это ушло больше месяца, а кроме того, заказчику пришлось оплатить дополнительные работы.
Для наглядности можно составить матрицу влияния стейкхолдеров на проект и методы взаимодействия с ними. Например, такую:
Изучить соответствующее законодательство, поговорить с экспертами и опытными коллегами
У более опытных коллег за плечами больше реализованных проектов, они уже набили свои шишки и могут дать полезные советы. Эксперты помогут разобраться в отдельных нюансах относительно, например, сценариев пользователей или специфической функциональности.
При разработке ресурсов для государственных компаний изучение законодательства ― обязательный этап в работе над таким проектом. Например, сайты и порталы для государственных образовательных организаций должны быть сделаны с учётом требований Министерства образования.
Оценивать риски
Риски обязательно соотносятся с критичностью или некритичностью требований к проекту в целом.
Критичные требования отвечают за целевую функцию разрабатываемого продукта, включают необходимую инфраструктуру и возможности для разработки MVP.
К некритичным относятся остальные требования.
Для каждого риска выявляют следующее:
На базе этих параметров строится матрица рисков.
Остановимся подробнее на степени управляемости рисками.
Управляемые — риски, которые можно предугадать и акцентировать на них внимание уже на начальном этапе проекта, определив для них ответственных и держа под контролем.
Самый очевидный пример ― опять же дизайн сайта. Сразу понятно, что на этапе согласования могут возникнуть сложности, доработки, переделки и бесконечные правки. Поэтому мы на старте проговариваем этот момент с заказчиком, согласовываем, кто будет лицом, принимающим окончательное решение, и письменно фиксируем максимально допустимое количество дней на согласование макета — в среднем, по нашему опыту, это обычно 5.
Неуправляемые — возможные риски, появление которых мы не можем предотвратить.
Например, один из неуправляемых рисков ― более ранний выпуск конкурентами на рынок похожего продукта.
Другой пример — подключение платёжной системы. В описании API говорится, что в ответ на запрос придёт одна строка, а по факту приходит три. И платёжная система на своей стороне не готова вносить правку, потому что на это нужно время, при этом тысячи пользователей этой системы об этом не просили. Так как нужна именно одна строка, разработчику приходится самостоятельно решать этот вопрос, тратить больше запланированного времени на разработку и фиксацию данной ошибки.
Запланировать мероприятия по предотвращению рисков
Для предотвращения рисков нужно понимать, как от них защищаться.
Грамотно выстроенные коммуникации внутри проекта играют главную роль для защиты от рисков и оказывают огромное влияние на успех проекта. Это означает, что все процессы взаимодействия регламентированы, роли всех членов команды закреплены и всё это зафиксировано в понятном для участников формате.
Важно сразу выстроить коммуникацию с заказчиками проекта, создать большую команду из представителей обеих сторон и все вопросы решать совместно.Для этого фиксируем ответственных для каждого этапа проекта в матрице «Роли и зоны ответственности» (RACI Matrix).
В матрице предусмотрены четыре роли:
Однако просто зафиксировать ответственных мало — нужно проанализировать заполненную матрицу, чтобы не было перекоса в одну роль:
После того, как разобрались с матрицей ролей, проактивно управляем рисками — фиксируем их и то, что нужно сделать для предотвращения.
Вместе с этим определяем план и способ коммуникаций на протяжении всего проекта: сколько раз в неделю и месяц, каким составом и при наступлении каких событий будем проводить созвоны или очные встречи, какой формат отчётности примем для фиксации договоренностей на этих встречах.
Также определяем инфраструктуру проекта:
Профессия
Project
manager
Предусмотреть действия при наступлении рисков
Стоит предусмотреть резервный план (contingency plan) на случай непредвиденных обстоятельств.
Задача этапа — выполнить его наиболее эффективным образом, а также собрать и проанализировать информацию о наступившем риске на будущее.
Не стоит тратить время на поиск виноватых — лучше предпринять всё необходимое, чтобы двигаться дальше и продолжать реализацию проекта. На этом этапе главная роль принадлежит коммуникации и поиску оптимального решения.
В нашей практике был проект, когда нужно было разделить один сайт, реализованный на Bitrix, на два. Один из них надо было интегрировать со штатной версией 1С.
Заказчик предполагал, что на разработку на своей стороне их специалисту понадобится три недели. По факту оказалось, что ранее созданная интеграция полностью кастомная — комплекты, цвета, размеры, остатки — и на стороне заказчика нет эксперта, который смог бы выполнить задачу. Пришлось подключиться нам и помочь с решением по интеграции. Дополнительно были пересмотрены сроки проекта.
Мониторить риски
Ситуация на проекте постоянно меняется ― это нужно принять как аксиому.
Например, если работать по Agile, то перед каждым новым спринтом могут меняться параметры проекта, обрисованные на этапе обсуждения. Следовательно нужно отслеживать изменения параметров рисков, корректируя внутрикомандный перечень топ-10 рисков.
На этапе мониторинга — если возвратиться к примеру с Agile, то это нужно делать в начале каждого спринта — важно отслеживать новые риски, изменять статус выявленных рисков, корректировать планы. На протяжении проекта перечень может значительно измениться.
К примеру, на крупном проекте на финальном этапе в команде заказчика появляется эксперт, который задаёт много вопросов и предъявляет новые требования к проекту, которые подразумевают изменение архитектуры проекта и кода. Если инициировать эти изменения, то есть риск сорвать плановые сроки реализации проекта.
Как вариант — провести встречу, обсудить, что беспокоит эксперта в текущей архитектуре, объяснить, почему реализовано именно так и наметить дальнейшие шаги. При этом важно постараться не увеличить объём работ проекта и не выйти за временные и финансовые рамки.
Каждый участник команды должен понимать важность работы с рисками
Ключевой момент управления рисками — их постоянное отслеживание и предотвращение, в идеале согласованное с длительностью циклов разработки проекта.
Оценка рисков и работа с ними зависят от размера и длительности проекта. Рекомендуем возвращаться к работе над рисками один раз в 1‒2 недели, в некоторых крупных проектах периодичность может быть увеличена до месяца.
Лучше составить неполный перечень рисков, чем не составить его вовсе.
В процессе общения с разработчиками или заказчиком лучше забыть фразу «все и так всё понимают»:
Главное в работе с рисками ― донести до всех участников проектной команды необходимость работы с рисками. Прежде всего нужно стараться не допускать наступления рисков, анализировать прошлый опыт и причины наступления для составления перечня возможных рисков в новых проектах, предотвращать непредусмотренные риски.
Пример перечня рисков проекта с комментариями и статусами можно посмотреть здесь.
Этапы оценки проекта: понятия, методы и полезные инструменты
Кто такой проджект менеджер, чем он занимается и как им стать
Как компаниям общаться с клиентами: ключевые тенденции и полезные советы
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.
Управление интеграцией проекта. Управление содержанием проекта
Устав проекта
Устав проекта ( Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.
Исходными документами для разработки Устава проекта внедрения ИС являются контракт и результаты предпроектного обследования, определяющие содержание работ по проекту. Результаты предпроектного обследования оформляются в виде отчета, включая описание бизнес-процессов верхнего уровня.
Устав проекта содержит следующую информацию:
1. Название проекта.
2. Бизнес-цели компании или причины возникновения проекта.
Формулировка причины фактически дает ответ на вопрос » Зачем выполняется данный проект?».
Цели проекта определяют, что должно быть выполнено, и описывают конечный результат проекта. В Уставе проекта приводится цель проекта как результат, ожидаемый Заказчиком и полезный для него. Цель формулируется совместно Заказчиком и Исполнителем.
При формулировании цели руководитель проекта должен контролировать ее соответствие контракту, в рамках которого будут выполняться работы по проекту.
Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):
Результаты проекта должны соотноситься со спецификацией контракта, в рамках которого будут выполняться работы по проекту.
Примеры формулировок целей:
Границы проекта определяют в целом то, что включается в проект. Необходимо явно указывать, что не включается в проект (таблица 4.2), чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект.
Указываются территориально удаленные объекты, подлежащие автоматизации.
| Раздел функциональности | Процессы, не подлежащие реализации |
|---|---|
| Организационный менеджмент | Формирование фонда заработной платы по специфичным методикам. Система оповещения по функциям Управления персоналом в целом. Ведение аттестации рабочих мест, вредных условий труда |
| Администрирование персонала | Ведение параллельных данных на английском языке |
| Учет рабочего времени | Фактический учет рабочего времени (будет использоваться негативный учет). Учет рабочего времени по заказам/объектам. Учет работы во вредных условиях |
| Расчет зарплаты | Сдельная система оплаты труда |
5. Содержание проекта (задачи проекта).
Содержание проекта отвечает на вопрос «Какую конкретную работу нужно выполнить для достижения поставленных целей?» или «Какие задачи необходимо решить для достижения поставленных целей?». Содержание может быть получено от Заказчика в качестве составляющей тендерной документации.
Пример описания содержания (задач) проекта
Требования к бизнес-процессам должны включать:
Что такое управление проектами
Конкуренция на рынке постоянно растет: чтобы компания могла привлекать и удерживать клиентов, нужно подстраиваться под растущие требования аудитории, оперативно выполнять задачи и решать проблемы. Один из способов эффективно организовать работу внутри компании – проектный менеджмент. В статье расскажем, что такое управление проектами и как система помогает улучшить показатели бизнеса.
Что такое проект и его управление
Проект – комплекс мероприятий, ограниченных по времени, с общей целью: создание нового продукта или услуги, достижение определенных результатов.
Управление проектами – это способ организовать работу таким образом, чтобы выполнить все требования к проекту. Например, закрыть задачи, выдержать сроки и уложиться в бюджет. Чтобы достичь успехов, менеджеру понадобятся технические знания по проекту, качества управленца, умение решать проблемы и организовать работу в коллективе.
Чем отличается проектное управление от традиционного менеджмента
Рассмотрим отличия разных систем управления наглядно.
| Традиционный менеджмент: | Управление проектами: |
| ориентирован на ход событий | ориентировано на достижение цели |
| важен процесс работы | важен результат |
| нет дедлайнов | работа связана с соблюдением сроков |
| распределяются позиции | распределяются ресурсы |
| монотонная регулярная работа | разнообразные задачи |
| постоянный персонал, занимающий определенные позиции | проектные команды разных специалистов |
Зачем нужно управление проектами
Проектный менеджмент – это инструмент для достижения стратегических целей. Этот способ управления помогает выявить задачи, важные для развития компании, распределить и направить силы на их достижение.
Управление проектами делит рабочий процесс на части и контролирует бюджет, дедлайны и прогресс на каждом этапе. После завершения работ можно оценить результаты по каждому процессу отдельно и в ракурсе конкретного проекта.
Управление некоторыми рутинными процессами отнимает много времени и приносит неочевидные результаты, поэтому проще их автоматизировать. Например, чтобы понять, что интересует клиентов и улучшать скрипты продаж, приходилось вручную собирать и систематизировать информацию о звонках. Это долго, дорого и, в силу человеческого фактора, неточно.
Теперь эти задачи можно решить с помощью сервиса Предикт от Calltouch. Система позволяет проанализировать разговор без участия менеджера, промаркировать и упорядочить обращения, чтобы найти сильные и слабые стороны скрипта и определить эффективность рекламных кампаний.
Предикт
Стандарты управления проектами
Это рекомендации и советы, на которые нужно ориентироваться при организации работы. Какие стандарты бывают:
Есть международные стандарты управления проектами – правила организации работы в разных странах. Один из самых известных стандартов – PMBOK (A Guide to the Project Management Body of Knowledge). Это руководство по управлению проектами, где есть вся терминология и базовые принципы. Его применяют в более 160 странах мира.
Роли в проекте
Роль в проекте – это набор функций и полномочий для разделения обязанностей между членами команды. Стандарт PMBOK выделяет следующие роли:
Важный вопрос – организация работы внутри коллектива исполнителей. Чтобы создать эффективную команду, руководитель учитывает навыки, опыт, личные качества сотрудников и распределяет роли внутри команды. Какие виды ролей бывают:
Состав идеальной команды зависит от специфики и целей проекта: можно привлекать дополнительных специалистов или наоборот, исключать лишних.
Кто такой руководитель проекта
Руководитель проекта или проект-менеджер – это человек, который несет ответственность за достижение поставленных целей. Он полностью отвечает за построение рабочего процесса: составляет план, формирует команду и распределяет обязанности, контролирует ресурсы и бюджет, а также корректирует ход работы и следит за соблюдением сроков.
Требования к проект-менеджеру
Какие компетенции понадобятся руководителю проектов в работе:
Преимущества проектного метода управления и его недостатки
Плюсы проектного управления:
Основные этапы управления проектом
Управление проектом – это комплекс действий. Количество и сложность задач, их последовательность зависят от вида проекта: например, строительство дома сильно отличается от работы над разработкой мобильного приложения. Но все проекты, вне зависимости от специфики, проходят примерно одинаковые этапы развития. Их называют жизненным циклом. Рассмотрим основные этапы управления проектом.
Инициирование проекта
На этой стадии определяют суть и цели проекта, выбирают руководителя, рассчитывают предварительный бюджет и ресурсы. Инициация – первичное содержание проекта, которое уточняют и дополняют в процессе. Чем крупнее проект, тем тщательнее прорабатывается этот этап.
Планирование проекта
Теперь нужно определить, как именно будет выполняться проект:
Планирование – это не только создание плана на старте, но и способность подготовиться к будущим проблемам, правкам и изменениям требований.
Исполнение проекта
Следующий шаг – запуск операций по плану. Здесь важно качественно выстроить работу внутри коллектива: всех познакомить, четко объяснить функции и задачи, продумать мотивацию для сотрудников.
Мониторинг и контроль проекта
Нужно контролировать каждый этап работы, а не только итоговые результаты. Аналитика позволяет выявить ошибки и проблемные места, быстро их исправлять и повышать эффективность.
Контролировать работу легче с помощью автоматизированных систем: CRM и других сервисов. Например, сквозная аналитика от Calltouch поможет проанализировать эффективность интернет-рекламы. Система объединяет данные со всех площадок в одном окне. С помощью наглядных отчетов можно сделать выводы об эффективности, оптимизировать затраты и выстроить полноценную воронку продаж.
Сквозная аналитика
Закрытие проекта
На этом этапе оформляют документы и передают результаты заказчику, либо инициируют фазу нового проекта. Важно получить обратную связь от заказчика: это поможет глобально оценить итоги работы и сделать выводы, чтобы не допускать ошибок в будущем.
Подходы к управлению жизненным циклом проекта
Жизненным циклом можно управлять: от этого зависит результативность проекта. По подходам к управлению жизненные циклы делят на:
Какую выбрать методологию
Для реализации задач проектного менеджмента используют различные методы. Методология, в отличие от стандартов – это не просто набор терминов и рекомендаций, а конкретный план действий, задающий направление. К числу основных методов можно отнести следующие варианты.
Waterfall
Эту модель еще называют каскадной или водопадной. Главный принцип метода – последовательное и четкое соблюдение всех этапов по заранее продуманному плану. Например, этапы разработки IT-продукта по методологии Waterfall:
В рамках подхода влияние непредвиденных факторов сводится к минимуму: каждый шаг предварительно продумывают и фиксируют. Подходит для проектов, где все требования заранее известны, без необходимости вносить изменения и риска ошибиться.
Agile
В отличие от Waterfall, Agile – целый набор гибких методик. Его главная ценность – это качество продукта, поэтому agile-команды постоянно поддерживают контакт с заказчиком и готовы к любым изменениям и доработкам. Обычно методология используется в IT-сфере при работе небольших групп сотрудников, занятых творческой работой.
Scrum
Scrum – это часть методологии Agile. Здесь тоже в приоритете результат и удовлетворение запросов заказчика, поэтому его максимально вовлекают в процесс. Работа состоит из коротких периодов – спринтов. В рамках спринта создается часть продукта, которую тестируют демонстрируют клиенту. По обратной связи от клиента команда улучшает эффективность.
Kanban
« Kanban » переводится как «доска объявлений». Это тоже часть Agile-философии, включающая ее базовые принципы. Методологию используют для равномерного распределения обязанностей между сотрудниками, чтобы не перегрузить команду.
Инструменты для управления проектами
Чтобы руководителю было проще выстраивать и контролировать процессы, разработчики создают специальные сервисы и ПО, которые автоматизируют часть работы. Самые популярные:
Заключение
Проектный менеджмент – это один из самых прогрессивных методов управления в компании. Его применяют для решения задач в любой сфере: бизнесе, общественной деятельности или госуправлении. Проектный подход позволяет заранее обозначить важные цели и максимально эффективно использовать бюджет и другие ресурсы. Однако сама по себе система не решит проблем. Чтобы выстроить управление в соответствии со спецификой и задачами конкретного бизнеса нужен грамотный менеджер.