Устав, карта, ЛПР: как успешно контролировать сроки IT-проектов и не только
Постановка и контроль сроков — одна из главных задач менеджмента. По опыту Extyl, сроки проекта идут на втором месте по важности после цены, а иногда и на первом. Несоблюдение сроков при внедрении нового решения — это потери вместо зарабатывания или экономии средств, простой персонала, снижение конкурентных преимуществ, удар по квартальным и годовым KPI.
Именно поэтому в 2020 году, проведя стратегическую сессию внутри компании, мы решили сделать контроль сроков центральной частью нашей дальнейшей стратегии. Это очень хорошо ложится на девиз компании, где говорится о вечном клиенте — таком, который остается с нами надолго или навсегда. Как он будет вечным или как он станет вообще заказывать что-либо, если сроки будут сдвигаться? Extyl занимается заказной разработкой порталов, многие крупные бизнесы и государственные структуры используют наши решения. Каждый проект у нас всегда начинался с фиксирования общих сроков проекта, сроков по каждому этапу и так далее. Однако, несмотря на планирование, срок реализации смещался на 30–60%. И это надо было исправлять.
Мы проанализировали позитивную практику работы с большими и опытными клиентами: Сбером, Роснефтью, Роскосмосом. Выяснилось, что самые опасные с точки зрения сроков этапы в разработке порталов, да и вообще IT-решений — это проектирование (техническое задание) и интеграции. Эти два этапа включают больше всего взаимодействий между заказчиком и подрядчиком и, как следствие, больше чреваты рисками перекидывания задач и длительных согласований. Но, если у вас есть исчерпывающее описание задачи и программисты с четким распределением ответственности, предсказать сроки и уложиться в них гораздо проще, нежели ждать Х дней согласования того или иного документа, согласитесь?
Новые правила и инструменты мы внедряли не одномоментно, а постепенно — в течение четырех лет. В результате смещение сроков сократилось в несколько раз — сейчас оно составляет в среднем не более 10%. И вот благодаря чему это удалось.
1. Договариваемся на берегу.
Уже в начале проекта нужно определиться, кто за что отвечает с обеих сторон, и, что намного сложнее, у кого какие реальные полномочия и кто какие решения принимает. Для этого часто используется устав проекта — небольшой документ, описывающий, кто участвует в проекте, как и для чего ведется коммуникация. У нас устав проекта впервые появился шесть лет назад благодаря Роснефти. Дополнительно в уставе можно зафиксировать другие ключевые договоренности — например, релизную политику (политику выпуска новых версий продукта), особенности информационной безопасности клиента (проекты часто делаются долго). Когда на любой из сторон появляется новый человек, первое, что он делает, — читает устав проекта.
2. Техзадание и интеграции: ищем ЛПР, используем Big Data.
Как правило, эти два этапа выполняются одновременно или близко по времени. Общее у них то, что нужно сразу определять заинтересованные стороны (для техзадания это, как правило, бизнес-заказчик, а для интеграций — IT-отдел) и договариваться с ними о том, чтобы все действия и процессы шли связно. А опыт работы с Big Data мы стали использовать после кейса Роскосмоса, чтобы автоматически проверять те данные, которые нам присылает клиент. Невозможно вручную отсмотреть десятки тысяч записей на предмет их корректности и заполненности, а вот нехитрый скрипт в несколько строчек делает это почти моментально.
3. Управление ожиданиями: диаграмма Ганта, карта коммуникаций.
Впервые мы сделали диаграмму Ганта, когда разрабатывали портал для «СберСпасибо». Диаграмма Ганта — это этапы реализации проекта, наложенные на сроки. Кроме того, необходимо указывать сроки приемки этих этапов заказчиком. Здесь мы опираемся на статистические данные по реализованным проектам, а не вписываем те, которые нам часто называют — так оказывается точнее. И если возникает ситуация сдвига сроков, мы сразу указываем, насколько, почему, и обсуждаем это с заказчиком, а не ставим его перед фактом. А вот как именно и как часто мы обсуждаем дела по проекту, указано в карте коммуникаций, в рамках которой фиксируем еженедельные статус-встречи и ежемесячные с руководством, — это позволяет держать руку на пульсе всем участникам проекта. В рамках встреч проговариваем текущую точку проекта, ближайшие планы, открытые вопросы и риски, которые могут повлиять на текущие сроки по каждому из блоков работ.
Бесспорно, полностью обойтись без сдвигов сроков невозможно — форс-мажоры никто не отменял. Но благодаря нашим клиентам и собственному желанию измениться мы смогли снизить риски таких сдвигов и в целом сделать разработку менее нервной и более прогнозируемой.
Этот материал опубликован на платформе бизнес-сообщества Forbes Экспертиза
Именно поэтому в 2020 году, проведя стратегическую сессию внутри компании, мы решили сделать контроль сроков центральной частью нашей дальнейшей стратегии. Это очень хорошо ложится на девиз компании, где говорится о вечном клиенте — таком, который остается с нами надолго или навсегда. Как он будет вечным или как он станет вообще заказывать что-либо, если сроки будут сдвигаться? Extyl занимается заказной разработкой порталов, многие крупные бизнесы и государственные структуры используют наши решения. Каждый проект у нас всегда начинался с фиксирования общих сроков проекта, сроков по каждому этапу и так далее. Однако, несмотря на планирование, срок реализации смещался на 30–60%. И это надо было исправлять.
Мы проанализировали позитивную практику работы с большими и опытными клиентами: Сбером, Роснефтью, Роскосмосом. Выяснилось, что самые опасные с точки зрения сроков этапы в разработке порталов, да и вообще IT-решений — это проектирование (техническое задание) и интеграции. Эти два этапа включают больше всего взаимодействий между заказчиком и подрядчиком и, как следствие, больше чреваты рисками перекидывания задач и длительных согласований. Но, если у вас есть исчерпывающее описание задачи и программисты с четким распределением ответственности, предсказать сроки и уложиться в них гораздо проще, нежели ждать Х дней согласования того или иного документа, согласитесь?
Новые правила и инструменты мы внедряли не одномоментно, а постепенно — в течение четырех лет. В результате смещение сроков сократилось в несколько раз — сейчас оно составляет в среднем не более 10%. И вот благодаря чему это удалось.
1. Договариваемся на берегу.
Уже в начале проекта нужно определиться, кто за что отвечает с обеих сторон, и, что намного сложнее, у кого какие реальные полномочия и кто какие решения принимает. Для этого часто используется устав проекта — небольшой документ, описывающий, кто участвует в проекте, как и для чего ведется коммуникация. У нас устав проекта впервые появился шесть лет назад благодаря Роснефти. Дополнительно в уставе можно зафиксировать другие ключевые договоренности — например, релизную политику (политику выпуска новых версий продукта), особенности информационной безопасности клиента (проекты часто делаются долго). Когда на любой из сторон появляется новый человек, первое, что он делает, — читает устав проекта.
2. Техзадание и интеграции: ищем ЛПР, используем Big Data.
Как правило, эти два этапа выполняются одновременно или близко по времени. Общее у них то, что нужно сразу определять заинтересованные стороны (для техзадания это, как правило, бизнес-заказчик, а для интеграций — IT-отдел) и договариваться с ними о том, чтобы все действия и процессы шли связно. А опыт работы с Big Data мы стали использовать после кейса Роскосмоса, чтобы автоматически проверять те данные, которые нам присылает клиент. Невозможно вручную отсмотреть десятки тысяч записей на предмет их корректности и заполненности, а вот нехитрый скрипт в несколько строчек делает это почти моментально.
3. Управление ожиданиями: диаграмма Ганта, карта коммуникаций.
Впервые мы сделали диаграмму Ганта, когда разрабатывали портал для «СберСпасибо». Диаграмма Ганта — это этапы реализации проекта, наложенные на сроки. Кроме того, необходимо указывать сроки приемки этих этапов заказчиком. Здесь мы опираемся на статистические данные по реализованным проектам, а не вписываем те, которые нам часто называют — так оказывается точнее. И если возникает ситуация сдвига сроков, мы сразу указываем, насколько, почему, и обсуждаем это с заказчиком, а не ставим его перед фактом. А вот как именно и как часто мы обсуждаем дела по проекту, указано в карте коммуникаций, в рамках которой фиксируем еженедельные статус-встречи и ежемесячные с руководством, — это позволяет держать руку на пульсе всем участникам проекта. В рамках встреч проговариваем текущую точку проекта, ближайшие планы, открытые вопросы и риски, которые могут повлиять на текущие сроки по каждому из блоков работ.
Бесспорно, полностью обойтись без сдвигов сроков невозможно — форс-мажоры никто не отменял. Но благодаря нашим клиентам и собственному желанию измениться мы смогли снизить риски таких сдвигов и в целом сделать разработку менее нервной и более прогнозируемой.
