Статья, которую я представляю вашему вниманию, повествует о моем личном опыте в области «Lessons Learned», вынесенном мной из множества успешно реализованных проектов, непосредственным участником которых я являлся. В ней я расскажу, что я предпринимал в качестве руководителя проектов с целью избежать ошибок, как реагировал, когда на проекте случались неприятности (или приятности) и зачем упаковал все это в полезный, как мне кажется, фреймворк.
Базовое понятие
Отправной точкой повествования, полагаю, должно стать базовое для этой статьи понятие — LL — Lessons Learned — Извлеченные уроки — Усвоенные Уроки — Выученные уроки — это новые знания и опыт, полученные на завершенном проекте, которые следует учитывать в будущих проектах. Ниже по тексту, все отсылки этому понятию будут именно в такой коннотации.
Кроме того, выученными уроками я без тени сомнения буду называть документы, встречи, методические рекомендации, фреймворк, практики, опыт и знания, тематику в целом или отдельную тему.
Выражаю искреннюю надежду, что читатель сможет продраться сквозь нагромождение душных определений и следующих за ними размытых смыслов к тем знаниям, которые он ищет.
Введение
Если дисклеймер вас не отпугнул, а может быть даже и заинтересовал, то рассмотрение темы предлагаю начать с определения фундамента, на который я наслаивал опыт усвоения уроков.
Прежде всего необходимо разобраться, зачем это нужно и кому знания об извлеченных уроках будут полезны.
Ответ на вопрос «зачем заниматься изучением уроков?» я формулирую так: для получения ценного опыта и его распространения на членов команды и сотрудников организации, а также совершенствования бизнес-процессов в компании и более эффективного проектного управления. Многосложно, местами угловато с навязчивыми нотками формализма, но ничего не поделаешь, другого ответа предложить не могу.
Если бы мне задали вопрос «кому может понадобиться изучать уроки?», я бы коротко ответил, что прежде всего это я сам. В более развернутом ответе я бы предположил, что в контексте выученных уроков руководитель проекта, члены команды, смежные команды, владельцы бизнес-процессов и руководство компании — это безусловные выгодополучатели. Они, как представляется, должны быть заинтересованы в распространении практик выученных уроков в своей организации. С сожалением вынужден констатировать, что вопросов про востребованность выученных уроков мне не задают.
По моим скромным наблюдениям от проекта к проекту команда в частности и структурное подразделение и/или организация в целом применяя практики выученных уроков может закономерно становиться эффективнее и с каждым разом обходить большее количество так называемых граблей. Скатываясь в эту аллегорию окончательно, добавлю, что скорость движения команды возрастет, а количество получаемых шишек сократиться. Вместе с тем, бытует мнение, что обходя грабли мы теряем ценный опыт. Возможно, это злые языки, возможно – народная мудрость. Что ж, единственный мой выход в попытке с этим разобраться — это продолжить повествование.
За годы, проведенные в шкуре руководителя проектов, я пришел к выводу, что для лучшего понимания и распространения изученные уроки удобно представить в виде фреймворка или методических рекомендаций релевантных для конкретного типа проектов и/или организации, в которой этот фреймворк планируется применять. Однако, польза из фреймворка может быть извлечена в полной мере, только когда компания в области управления проектами достигла некоторой зрелости и в ней в числе прочего сформулированы и задокументированы основные бизнес-процессы, заданы стандарты качества выполняемых проектов, определены основные проектные метрики.
Поскольку категорических возражений против озвученных тезисов от разъяренной толпы недовольных читателей, вооруженных вилами и факелами, не поступает, попробую развить мысль про фреймворк далее.
Фреймворк, как представляется, должен быть размазан тонким слоем сливочного масла по свежеприготовленному хрустящему тосту основного бизнес-процесса управления проектом. Только гармонируя друг с другом они принесут столь желанные и столь ожидаемые результаты. Искушенный сомелье видит такую гармонию невооруженным глазом. Неопытный же сотрудник может с легкостью демаскировать ее заметив, что выученные уроки фактически верны, оказывают реальное влияние на работу команды и определяют решения и/или процессы, которые способствуют достижению положительных результатов или снижают вероятность неудач.
В предыдущем абзаце намеренно сделана отсылка к вкусному и питательному завтраку, поскольку – это залог продуктивности на весь последующей день, если вы понимаете, о чем я.
Усилить волшебство позитивного воздействия выученных уроков можно путем их надлежащего документирования, доведения до сведения заинтересованных лиц и архивирования для последующего использования. Спрятанные в нижнем ящике стола стикеры с записями о том так все страдали на проекте, но последний герой из команды перед увольнением всех спас – прекрасный пример плохого документирования, распространения и хранения изученных уроков. Необходимость обеспечить доступ к методике и результатам работы по ней для всех вовлеченных и причастных сотрудников организации в любой удобный для них момент является очевидным фактом, но я, следуя постулатам надлежащего документирования, все же обращу на это внимание читателя дополнительно.
Встреча с такими всадниками проектного апокалипсиса как нарушение сроков, перерасход бюджета, неоправдавшиеся ожидания от продукта или тот четвертый, про которого я все время забываю – это хороший повод задуматься над тем, как предотвратить подобные рандеву системно, окончательно, бесповоротно и навсегда. Всего то на всего нужно понять, что пошло не так, почему и определить, что можно сделать по-другому в будущем. Аналогичный принцип применим и к успешным проектам, когда достоверно известно, что прошло хорошо и что стало причиной такому исходу, следует повторять успешные шаги во всех командах и закономерно добиться положительных результатов в других проектах.
Важным замечанием по обсуждаемой теме будет то, что извлеченные уроки и подведение итогов проекта — это разные активности и смешивание их в одно мероприятие приведет к снижению эффективности по обоим направлениям работы. Завязав полемику по этой теме, мы рискуем сильно отдалиться от предмета нашего основного интереса, поэтому предлагаю прикончить эту мысль в зачатке и вернуться к рассмотрению изученных уроков.
Методика
Раз уж читатель все еще увлечен моим повествованием, позволю себе предложить ему представить процесс выполнения проекта как череду или совокупность связанных с этим проектом событий.
В своей работе я опираюсь на твердую уверенность в том, что руководитель проекта, члены команды и все, кто заинтересован в успешном завершении проекта и достижении поставленных целей так или иначе, сознательно или бессознательно стремятся к тому, чтобы происходили события, которые способствуют реализации проекта и не происходили события, которые этому препятствуют.
В самом общем смысле и в числе прочего как руководитель проекта я в рамках своей профессиональной деятельности на проекте планирую исключительно события, которые способствуют его реализации и тщательно слежу, чтобы эти события происходили точно в срок. Также я прилагаю значительные усилия чтобы отслеживать события, которые препятствуют достижению поставленных целей. Минимизация ущерба для проекта в случаях, если такие события происходят или они неизбежны – это один из важнейших аспектов моей работы. Тут мне на помощь приходят сформулированные в компании основные бизнес-процессы. Благодаря им, планированию и работе с рисками предопределен сценарий и тайминги, согласно которым события на проекте должны происходить.
У читателя может сложиться ощущение, что предварительные ласки несколько затягиваются и мы в пустую ходим вокруг да около. Терпение, еще немного терпения, и скоро мы доберемся непосредственно и до предмета нашего с вами интереса.
Важным и для многих очевидным уточнением будет то, что отклонения от сценария не приветствуются, но тем не менее случаются, а также то, что отклонения могут быть как в положительную сторону, так и в отрицательную.
Таким образом, связанные с проектом события можно разделить на запланированные и незапланированные. Незапланированные события, в свою очередь легко делятся на позитивные, нейтральные и негативные. Проявив некоторую смекалку и находчивость можно было бы декомпозировать бедные и несчастные события и дальше, но делать этого я конечно же не буду, поскольку наибольший интерес в рамках рассматриваемого фреймворка представляют, разумеется, незапланированные негативные и позитивные события.
Сбор информации
Как я уже упоминал ранее, упоминаю сейчас и не перестану этого делать в будущем документирование — это очень важно и оказывает значительное влияние на результат. События, ставшие причиной отклонений от сценария, документируются мной самым беспощадным образом.
Ведомый постоянным и непреодолимым желанием увеличивать прибыль инвесторов компании в которой работаю, я стремлюсь быть в курсе происходящего на моих проектах не зависимо от того происходит что-то хорошее или что-то плохое. Сбор информации в этом случае для меня в приоритете, а вынесение суждений - вторично.
В расчете на то, что читатель, если он все еще со мной, уже подутомился и растратил свои способности к рациональному мышлению я предложу принять на веру, что время, потраченное на документирование, стоит затраченных усилий. А лучшее время для документирования чего-либо — сразу после того, как это произошло. В противном случае ключевая информация может быть случайно забыта или, в контексте негативных результатов, намеренно замалчиваться.
Проектное управление - игра командная, а извлеченные уроки — это всегда результат совместной работы. Все члены команды должны принять правила игры и действовать в рамках определенных фреймворком. Сбор информации — это моя прямая обязанность, но никогда не было такого, чтобы эта обязанность не была подкреплена желанием команды в оказании содействия в ее исполнении.
Наполнение протокола
Постоянно находясь в ресурсоемкой борьбе с бурным потоком проектного управления, я тем не менее не ленюсь накапливать в отдельном документе поступающую мне информацию о событиях, обуславливающих отклонения от сценария. Так же без сожаления я расходую ресурсы на анализ этой информации на предмет возможности ее использования в контексте фреймворка выученные уроки.
Пригодность информации к использованию для извлечения урока я безошибочно определяю по наличию в ней четырех основных характеристик:
Определение предмета урока. Это может быть часть бизнес-процесса, проекта или продукта, которые были затронуты незапланированным событием.
Описание проблемы или успеха. Информация об условиях, при которых произошло событие и подтверждение того, что это событие действительно является отклонением от сценария.
Влияние на проект. Дает оценочные суждения серьезности произошедшего события и степени влияния на проект и основные бизнес-процессы.
Рекомендации по улучшению бизнес-процессов. По сути, это и есть извлеченный урок, который, например, через трансформацию бизнес-процессов позволит закрепить в компании положительный опыт и избежать отрицательного.
Таким образом к концу проекта у меня появляется первый артефакт фреймворка - "проект протокола выученные уроки". Я множество раз провернул всевозможные кубики слов, из которых состоит предыдущее предложение, но так и не смог избавиться от повтора слова «проект». Мне остается только надеяться, что читатель, столь увлечен захватывающим развитием сюжета, что попросту не обратил внимания на эту стилистическую неровность. Перед теми же кто, заметил этот мерзкий смысловой заусенец, мне искренне стыдно.
Публикация протокола
Появление такого артефакта намекает мне на необходимость проведения с командой встречи выученные уроки.
В рамках подготовки к этой встрече я анализирую проект протокола выученные уроки, фильтрую содержащуюся там информацию, выделяю релевантные кейсы и формулирую рекомендации по улучшению бизнес-процессов.
После того как документ проанализирован, и вся не относящаяся к предмету обсуждаемых вопросов информация из него удалена, проект протокола выносится мной на обсуждение с проектной командой в рамках встречи выученные уроки.
По моему опыту наилучшее время для организации и проведения такой встречи – это когда все запланированные и не запланированные события по проекту завершены, акты приемки подписаны, счета оплачены, ретроспектива изучена, рабочие документы сданы в архив и итоговое совещание проведено.
На встрече участники команды, работавшие над проектом, знакомятся с проектом протокола, подтверждают (или опровергают) точность и достоверность содержащейся там информации, а также предлагают дополнения и исправления.
Окончательное решение касательно содержания протокола является моей прерогативой. По возможности, я стараюсь чтобы протокол носил обезличенный характер и содержал фактологическую информацию, оценки произошедших событий и рекомендации будущим исполнителям схожих проектов. Это мой вклад в легаси компании и одновременное послание будущим поколениям, которые придут управлять проектами после и/или вместо меня.
Так, результатом встречи становится еще один артефакт: "протокол выученные уроки по проекту". Протокол публикуется таким образом, чтобы к нему имели доступ проектная команда, команды, работающие над схожими проектами и/или сталкивающиеся со схожими проблемами. Также доступ к протоколу предоставляется руководству компании и/или владельцу (или владельцам) основных бизнес-процессов.
В этот момент очень важным является наличие возможности обогащения протокола информацией со стороны сотрудников компании, которые с ним ознакомились. Также, не лишним будет предусмотреть возможность осуществления контроля за тем, чтобы велся учет сотрудников, которым необходимо ознакомиться с документом. Тех же сотрудников, которые могли ознакомиться с документом, должны были это сделать, но не сделали, я предлагаю брать на карандаш и разбираться по с ними по всей строгости при первом же удобном случае.
Перед публикацией не стоит забывать о том, что доступ к протоколу будет предоставлен широкому кругу лиц. При определении круга лиц, которому будет предоставлен протокол для ознакомления, стоит учитывать, что протокол может содержать конфиденциальную информацию.
На данном этапе уже могут быть получены первые результаты.
К владельцу основного бизнес-процесса системно начнет стекаться обратная связь по функционированию его бизнес-процесса. Информация получаемая таким образом будет многократно перепроверена, структурирована и будет содержать конкретные предложения по улучшению бизнес-процессов и повышению их эффективности.
Второй положительный эффект, который может быть достигнут — это внедрение лучших практик в компании. В ходе кадровой ротации в организации или ее структурном подразделении неизбежно появляются новые сотрудники. Априори сотрудники обладают опытом, который представляет ценность и в этом случае ценный опыт должен быть рассмотрен с точки зрения его использования в компании с позиций лучших практик. Понять, какие именно практики являются лучшими и заслуживают того, чтобы их перенять, очень удобно проверив их с помощью незапланированных событий. И тут кажется, что это еще один спин-офф, на который не хотелось бы отвлекаться.
Обеспечение доступа к протоколу
Не станем подвергать сомнению, что протоколы выученных уроков по проектам предназначены для осуществления руководства будущими проектами и должны храниться в общедоступном хранилище, чтобы другие руководители проектов могли внедрить успешные процедуры и избежать ошибок, допущенных в предыдущих проектах.
Также не вызывает сомнений, что наличие этих документов и возможность доступа к ним внесут значительный вклад в обогащение знаниями сотрудников при их онбординге или ротации кадров.
Выводы
Рассуждая таким образом, я выделяю основные этапы, золотой нитью пронизывающие канву фреймворка – это сбор информации, документирование, верификация, уточнение, распространение, применение и архивирование. Полная и систематическая реализация всех этих этапов способна обеспечить эффективное извлечение и применение уроков, полученных из прошлого опыта, с целью улучшения будущих проектов и работы организации в целом.
Практика выученных уроков обладает неоспоримой ценностью для организаций и позволяет системно избегать повторения ошибок, повышать эффективность работы над проектами, улучшает коммуникации, побуждает сотрудников к развитию и работе над собой, способствует принятию обоснованных решений, обуславливает закономерное снижение рисков и так далее и тому подобное.
В целом, применение вышеописанного фреймворка способствует непрерывному улучшению процессов и повышению качества работы.
Выученные уроки, при должном к ним внимании и правильном обращении, становятся частью операционной стратегии и инициируют изменения, которые принесут пользу не только руководителям проектов, но и их командам и компаниям, в которых они трудятся.
Я лично, нахожу полезным при старте нового проекта освежить знания по выученным урокам. При наличии возможности фильтровать уроки по предмету, типу проекта и содержимому я нахожу полезной такую активность вдвойне.
Наряду с этим мне видится крайне неполезным выполнять работу по выучиванию уроков просто ради работы (впрочем, наверное, как и любую другую). Если у полученных результатов нет потребителей, если бизнес-процессы отлиты в граните, если каждый руководитель, как царь-кощей запирает свои опыт и знания в сундуке и чахнет над ним, не желая делиться ими с коллегами, то ожидать от вышеописанного фреймворка пользы весьма опрометчиво.
Эпилог
Наверное, стоило об этом предупредить в самом начале, но я не пытался открыть Америку, и этот материал не несет в себе новаторского и/или революционного налета. Данный текст написан в первую очередь для себя в попытке разобраться в вопросе и повысить эффективность как своей работы в качестве руководителя проектов, так и эффективность работы команд участником которых я являюсь.
Искренне надеюсь, что те, кто дочитал текст до этого момента нашли в нем крупицы пользы, и жду от вас, по возможности, обратную связь в комментариях, как, впрочем, жду обратную связь и от искушенных сомелье в области проектного управления.
Алексей В.
Руководитель IT-проекта / Менеджер IT-продукта