Как описать проект автоматизации / изменений и не сесть в лужу

12 лет моей профессиональной деятельности связаны с различными проектами, причем почти постоянно участвую в нескольких проектах сразу. И в самом проекте, и после его завершения регулярно приходят мысли о том – что в проектах автоматизации нужно улучшать.

В очередной раз, размышляя над тем, что же можно/нужно сделать лучше, я углубился в тему подготовки описания проекта (устава проекта). Документ важный с разных сторон, т.к. на основании Устава проекта одни участники формируют свои ожидания от проекта, а другие определяют для себя приоритеты в работах.

Важность этапа описания проекта обусловлена еще и тем, что даже небольшие ошибки/неточности/неоднозначности могут привести к серьезным проблемам на этапе выполнения и завершения проекта.

Сразу оговорюсь, что опишу только основные, наиболее важные, на мой взгляд, выводы о корректной подготовке проектной документации:


                                Правильно формулируйте цель                                  (как бы банально это не звучало)

// Есть очень хорошая цитата на эту тему — «Скорость важнее силы, но точность важнее скорости».

Какое правило описания цели сформулировал для себя я:

  • во-первых, нужно определить проблему/задачу, которую мы хотим решить (как правило если нет проблемы, то нет смысла что-то изменять)
  • во-вторых, нужно понять ожидаемый эффект от решения проблемы и оценить – насколько он значителен, чтобы затевать перемены

После того, как мы определились с проблемой и желаемым эффектом, можно формулировать цель проекта, которая должна отражать способ решения проблемы.

Причем целесообразно разложить цель на более локальные задачи. Приведу пример:

  1. Выделяем проблему: низкий уровень клиентского сервиса при исполнении заказов покупателей (92%)
  2. Формулируем ожидаемый эффект: повышение уровня клиентского сервиса до 96%
  3. Определяем возможные варианты решения проблемы, выбираем наиболее актуальный и формулируем на его основании цель.

В данном примере у нас может быть как минимум 2 варианта решения проблемы:

  • увеличение складских остатков готовой продукции для повышения вероятности обеспеченности принимаемых заказов готовой продукцией
  • развитие системы прогнозирования принимаемых заказов для формирования заявки на производство под ожидаемые заказы

Первый вариант довольно просто реализуется, но в нём есть много минусов (дополнительные затраты на хранение, замороженные деньги в готовой продукции на складах и т.п.). Второй же вариант более сложный в реализации, но если мы ограничены в складских помещениях, денежных средствах или сроки годности продукции не позволяют хранить её долго на складе, то второй вариант единственно возможный.

Выбираем второй вариант, и тогда наша цель будет выглядеть таким образом:

«Оптимизация и автоматизация алгоритмов формирования заявки на производство на основании прогнозирования спроса»

       4. Чтобы цель была более ясной, выделим в ней задачи (крупные «камни», определяющие результат):

  • Организация учета в ИТ-системе проводимых трейд маркетинговых мероприятий (плановые и фактические приросты объёмов продаж)
  • Автоматизация алгоритма прогнозирования отгрузок на основании истории, сезонности, влияния акций и динамики развития
  • Формирование заявки на производство на основании остатков и прогноза отгрузок
  • Проверка ограничений по рабочим центрам (по узким горлышкам)

Договаривайтесь о правилах игры

После определения целей проекта нам необходимо составить план работ. Однако для этого нужно договориться – какие правила организации работ будет соблюдать проектная команда.

Одно из самых понятных противоречий, которые возникают при этом, — это процент времени, выделяемый участниками на проект. Зачастую функциональные заказчики, участвующие в проекте, не освобождаются от своей текущей работы (т.е. для них проект- это факультативная задача). Соответственно, если загрузка до проекта у них уже была 120% (а это нередкость, цифра может быть и выше), то назначение их на проект приведёт к растягиванию сроков работ до бесконечности.

Также здесь нужно договариваться о формате проведения рабочих совещаний, как будет проходить сбор требований, тестирование ИТ-системы, обучение пользователей и т.п. Надо договариваться о всех особенностях выполнения работ, которые влияют на объём ресурсов и, как следствие, на сроки проекта. И уже только после этого можно строить календарный план проекта.


Формализуйте критерии завершённости

Одна из частых проблем на проектах – это потеря точных ориентиров (критериев завершённости) и, как следствие, переход проекта в состояние хаоса. Когда все много работают, но из-за рассогласованности ориентиров результаты не фиксируются.

Проект – это по определению временное мероприятие, которое нацелено на получение конкретных результатов. Так вот эти результаты должны быть максимально точно и полно формализованы. Кроме критериев завершённости всего проекта необходимо описывать критерии завершённости каждого шага, чтобы не накапливать «хвосты».

Для примера, у такой задачи проекта, как организация учета трейд маркетинговой активности, критерий завершённости может быть сформулирован так:

«В ИТ-системе создано не менее 3-х трейд-маркетинговых мероприятий, по ним рассчитана плановая эффективность акции на основании определенных аналитиком плановых приростов.

По результатам завершения акций в системе автоматизировано рассчитан объём фактических продаж по акции.

План-фактный анализ эффективности акций сформирован в ИТ-системе автоматически».

Приведённые три пункта не покрывают все аспекты, которые должны быть отражены в уставе. Просто считаю их одними из определяющих, с одной стороны, и в то же время одними из наиболее формально описываемых, с другой.

В завершение хочу поделиться тем, что подтолкнуло меня к написанию данного лайфхака. Так сказать, на сладкое.  Недавно один потенциальный клиент прислал нам описание своего проекта по внедрению ИТ-системы, для оценки нашей готовности взяться за его выполнение.

Что ж, ситуация не уникальная, но я очень давно не читал настолько пустых описаний проектов – много «умных» слов, красивых схем и почти ничего по существу – какие понятные и измеримые цели стоят перед проектом. Мы, конечно, обратную связь дали, но приниматься за проект без целей не стали.

Надеюсь, что описанное выше поможет тебе, дорогой читатель, в подготовке своих ИТ-проектов и позволит избежать неудач.

Печать статьи

Отправить ответ

Оставьте первый комментарий!

avatar
  Подписаться  
Уведомлять о