Жизненный цикл проекта — планетарная модель

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

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

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

В этой статье я выбрал общее для более чем 50 проектов из разных сфер, в планировании и разработке которых я участвовал за последние годы. Причем многие из них не дошли до своего конца, что, при правильном анализе, делает этот опыт наиболее ценным. Я постарался сделать эти выводы не предметно-ориентированными а более общими, что, по моему мнению, расширит их область применения.

Я предлагаю рассмотреть проект - как планету, где каждый слой - это отдельная фаза жизненного цикла проекта. Причем как и у планет границы этих фаз определены лишь логически, на практике есть некая “интерференция” правил, действующих на соседних уровнях. Такая аналогия и интерпретации должны помочь в понимании того, что я хочу описать.

Так же как и у планет - ядро проекта является местом с самой высокой температурой. То есть, во время формирования идеи проекта, “градус” вовлеченности и мотивации участников проекта наиболее высок. Изменения на этом уровне имеют низкую стоимость, а скорость принятия решений очень высока.

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

На этом этапе, среди прочего, важно понимать следующее:

и

… это либо два разных человека, либо один, но в разное время. Очень важно разделять эти две активности, так как они взаимо-исключающие. На этом этапе важно заниматься только тем, чтобы определить основные цели. Нельзя отягощать творческий процесс трудностями реализации. Исходя из моего опыта, для многих задач, которые на этом этапе кажутся нереальными, потом, на этапе проектирования и реализации, решения возникают из ниоткуда. Главное чтобы была уверенность в том, что это действительно необходимо. Поэтому на этой фазе фокусируемся только на том что нам надо, а не на том, как мы это будем делать.

Так же важно понимать что не обязательно продумывать все мелочи. Гораздо важнее обозначить верхнеуровневые ожидания и определить “критерии успеха”. Это должны быть какие-то объективные показатели, которые можно измерить и которые не зависят от чьего-то настроения. Причем, в рамках первой фазы, конкретные значения этих параметров могут быть приблизительными или отсутствовать вовсе, главное определить что именно измерять.

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

Этап проектирования, зачастую недооценен. Сложно “продать” руководству затраты на проработку проекта которые выглядят как пустая трата дополнительного времени = денег. Однако именно этот этап, при правильном к нему подходе позволяет не только сдержать расходы но и в некоторых случаях их сократить. Все зависит только от того, насколько тщательно проведено проектирование (планирование).

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

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

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

Такая концепция называется MVP - minimum viable product. Это подход, который основан на том, что в проект включаются только те работы, которые нельзя исключить, и которые приносят пользу. Важно понимать что первый запуск любого проекта уже самый затратный только с организационной стороны. То есть для каждого проекта, даже в высоко-ориентированной к изменениям среде, второй запуск такого же объема работ был бы ощутимо быстрее и стоил бы меньше. Поэтому MVP позволяет минимизировать этот негативный фактор, при этом увеличивая шансы на успех проекта в целом.

Основная трудность начинающих команд на этом этапе состоит в незнании того, как построить работу, на чем фокусироваться и с чего начинать. Я не сразу приобрел необходимые навыки, но всегда когда попадал в ситуации с большим количеством неизвестных, начинал с того, что точно известно.

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

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

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

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

С организационной точки зрения, команда на этом этапе должна сфокусироваться на том, чтобы сделать максимальный объем проекта понятным. То есть минимизировать области неизвестного в проекте. Бывает так что некоторые компоненты идеи на этом этапе пересматриваются. Однако если проект свернул совсем в другую сторону - возникает большой риск срыва проекта в последствии, так как участники все же “подписывались на другое”.

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

Здесь хочется привести результаты исследования, которые уже стали байкой, но посыл все же актуальный. Сравнивали результаты работ двух строительных компаний и искали причины успеха одной из них. И выяснилось что в отстающей компании, например кладчики, когда их спросили чем они занимаются, ответили: - “Мы кирпич кладем” а в другой ответили: - “Мы здание строим”. То есть видение глобальной картины проекта всеми его участниками - залог успеха самого проекта.

По аналогии с корой планеты, реализация проекта это то место где уже и температура ниже (то есть мотивация), и сама она находится в более твердом состоянии, то есть изменения уже более критичны, так как здесь все уже должно быть в твердом состоянии. И, пожалуй, самое главное - именно эта часть подвергается большей радиации - критике проекта.

Сопротивление изменениям - когда сотрудники чьи процессы затрагиваются в ходе проектов, было и всегда будет. И с этим можно и нужно бороться. Тем не менее важно еще и понимать что как только точка сопротивления пройдена сотрудники впадают в другую крайность - начинают добавлять работ проекту - находить новые способы оптимизации и улучшений. В общем так или иначе выходить за рамки, описанные в проекте. Мы описывали этот эффект как “Аппетит приходит во время еды”.

Учитывая что не все участвуют в проекте и понимают его скоуп, не руководствуются принципами MVP, этот “аппетит” создает давление на проектную команду со стороны других сотрудников. Важно отвести это давление от проектной команды, например заведя “Журнал предложений” или вообще прописать соответствующий процесс.

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

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

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

Не все новое улавливается всеми и сразу. Каждый человек по-разному легко переносит изменения его деятельности. Потому кому-то нужно будет помогать, а кто-то будет пытаться саботировать, к этому надо готовиться заранее.

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

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

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

Важно понимать, что сколько бы не тратили время на проработку и дизайн проекта, его результаты всегда будут использоваться сотрудниками или клиентами так как им удобнее и выгоднее. Допустим если вы в ходе проекта ввели какие-то новые процессы или инструменты по контролю трудовой дисциплины, их будут пытаться взломать и использовать лазейки в своих целях. Не всегда это имеет негативный подтекст, иногда люди просто пытаются облегчить себе труд.

Еще одна вещь которую нужно понимать - не все что вы внедрили будет использоваться. Допустим для приложений около 50% функций используется редко или не используется вообще. Зачастую это из за неудобства интерфейса, или из за того, что непонятно где и как этим пользоваться. Такая же картина и с процессами - некоторыми просто перестают пользоваться по причине того, что они слишком бюрократизированные.

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

Ведение проектов - самая незаурядная деятельность. Нельзя прописать какие-то шаблонные правила, применимые ко всем проектам. Тем не менее, есть много общего между проектом по разработке приложения и, например, проектом по реорганизации структуры предприятия. Очень важно понимать какие подводные камни есть не столько в предметной деятельности проекта сколько в ведении самого проекта. Правильный mindset команды проекта позволяет успешно адаптироваться к изменениям в обстановке при переходе от одной фазы к другой и заниматься тем, что действительно релевантно и эффективно в каждый момент времени. Это позволяет не только повысить шансы какого-то одного проекта на успех но и увеличить степень принятия нововведений всей компанией, уменьшая ее инертность повышая динамичность всей компании в целом.