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

Уверенность в собственной правоте может ослеплять

Мне было 17 лет, я только-только закончил школу и начал делать первые самостоятельные шаги в качестве студента Новосибирского государственного университета. Я учился на первом курсе (увы, это был только первый из моих первых курсов) увлекался экстремально тяжелым металлом и на этой почве впервые в жизни нашел компанию единомышленников. Одним из них был парень по прозвищу Блэк.

Однажды я с увлечением рассказывал Блэку о том, что в фильме «Эйс Вентура», оказывается, в одном из эпизодов выступает группа «Кэннибал корпс», которую мы оба очень ценили. Он был в глумливом настроении и решил меня потроллить, дескать, да ладно, быть такого не может. Я троллинг не распознал, и с пылом начал его убеждать, причем быстро разогнался буквально до крика.

В какой-то момент Блэк увидел, что я завелся не на шутку, и раскрыл троллинг, но я продолжал на него кричать:

— Вася, ты думаешь, я там Кэннибал корпс не видел?

— Думаю не видел!!!

— Вася, послушай: я смотрел этот фильм десять тысяч раз. Неужели ты думаешь, что я не видел там Кэннибал корпс?

Только после этой фразы я понял, что происходит: услышал себя, услышал Блэка, понял, что все это время он меня троллил. И в этот момент меня как громом поразил контраст между ослепительным ощущением собственной правоты, когда я с шашкой наголо мчался рубить за правое дело, и мгновенно сменившим его ощущением того, что я от начала и до конца 100% не прав. Оказывается, я могу быть 100% неправ и чувствовать при этом свою 100% правоту!

Неуверенность в собственной правоте может дать хороший толчок к развитию

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

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

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

Навык сомнения в собственной правоте очень полезен и его можно развить

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

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

1. Не идентифицироваться со своим решением. Важно понимать, что если ваше решение завернули, это не значит, что вы стали хуже. Это наверное проще сказать, чем сделать, но можно начать с осознанности: если у вас вдруг начинает бомбить от того, что ваше решение критикуют, это повод остановиться и подумать, чем обусловлена эмоциональная реакция.
2. Быть скромным и не претендовать на лавры. Автор посвящает целую главу этой крутой мысли, которая сегодня может многим показаться контринтуитивной. А смысл в том, что если вы не зависите от ощущения собственной крутизны, то позволяет гораздо проще воспринимать критику, несогласие и т. п.
3. Искать не подтверждения, а опровержения своей идеи. Продумывать, что должно произойти, чтобы вы отказались от своей точки зрения.

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

Без еженедельного обзора ваша система продуктивности будет страдать, но внедрить его сложно

Я знал о полезности практики еженедельного обзора довольно давно, примерно с первых лет, как начал заниматься тайм-менеджментом и вести свои задачи в системе, и мог лично убедиться в негативных последствиях пренебрежения им:

• Задачки теряются, потому что ты их положил «на дальнюю полку», а потом оттуда не достал вовремя. Это приводит к тому, что ты начинаешь записывать задачи куда-то поближе, или злоупотреблять напоминаниями, что, в свою очередь, приводит к неудобству системы и увеличению шансов на ее «отторжение».
• Задачки протухают и отравляют всю систему. Ты заходишь в свой таск-трекер, а там куча неактуальных задач. Получается, как у классика, «здесь играть, здесь не играть, здесь рыбу заворачивали...» Очень демотивирует.
• По закону энтропии хаос постепенно нарастает, и система становится замусоренной и неудобной.

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

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

Аналогичную ситуацию я встречал у своих клиентов.

Поможет чек-лист еженедельного обзора

Решение пришло, когда я:

1. Настроил регулярную напоминалку через Due.
2. Сделал для еженедельного обзора чек-лист на гугл-формах.

В гугл-формах я буквально за полчаса набросал список вопросов в режиме «вопрос со многими вариантами ответа», сгруппировав их в тематические группы. Что-то типа:

Завершение дел

1. Разобрать почту (zero inbox)
2. Закрыть все рабочие программы кроме аутлука
3. Закрыть окна в браузере, кроме таск-трекера

Актуализация задач

1. Актуализировать все задачи
2. Выкинуть все не актуальные задачи

Рефлексия

1. Как неделька прошла? (развернутый ответ)

Отключение

1. Закрыть аутлук и таск-трекер
2. Прибраться на столе

(Это мой пример, у вас наверняка будут свои пункты)

Но самым первым стал экран с одним обязательным вопросом, подразумевающим развернутый ответ: «Зачем тебе еженедельный обзор?». И каждый раз, заходя в систему, я сначала писал мини-сочинение, в котором приводил себе аргументы, почему мне необходим еженедельный обзор. Дописывая мини-сочинение, я чувствовал подъем мотивации и под бодрую музыку с удовольствием проходился по чек-листу.

Еженедельный обзор — отличный способ завершить неделю

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

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

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

Да, к слову сказать, подписывайтесь на меня в Телеге.

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

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

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

Документ как чек-лист

Давайте для начала посмотрим на содержание какого-нибудь управленческого документа проекта.

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

Возьмем, например, кусочек документа под названием «стратегия коммуникации».

Что мы видим? Таблица, в которой надо заполнить все ячейки по принципу «природа не терпит пустоты». При этом важно не только и не столько то, что мы их заполнили, а то, что мы обо всем этом подумали.

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

Почему нельзя просто задать один вопрос: «опишите, зачем нужен проект», — вместо того, чтобы заполнять в паспорте проекта «решаемые проблемы», «результаты» и «выгоды»? Ответ — можно, но качество ответов на этот вопрос очень сложно прогнозировать. Даже вы сами ответите на него по-разному в зависимости от вашего внутреннего состояния, запаренности в данный момент и кучи других факторов. Не говорю уже о разных руководителях проекта, которые в компании должны дать единообразный результат.

Вот недавно мы как раз смотрели документ, в котором «зачем нужен проект» описано в одном поле, и выяснили, что руководитель проекта описал массу показателей, но забыл описать собственно проблему, на решение которой нацелен проект. Упс.

Договориться и зафиксировать договоренности

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

Чтобы понять, зачем нужен паспорт проекта, мы всегда приводим метафору: «паспорт проекта = договор между компанией и командой проекта». Думаю, все прекрасно понимают, что значит работать без договора: в каких-то случаях это прокатывает, но в каких-то ты попадаешь на кучу головняков.

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

Ничего не потерять

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

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

Как сделать так, чтобы бюрократия не превращалась в бюрократизм?

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

Так вот, первое правило: детализация должна соответствовать сложности проекта.

Другой важный момент заключается в том, что каждое поле должно использоваться. Помню, мой наставник по проектному управлению, который помогал мне сделать первые шаги в качестве руководителя проектного офиса, сказал: «Если какую-то информацию ты не используешь, ты не имеешь права ее запрашивать!». Этой максимой я с тех пор и руководствуюсь. К сожалению, понимание, что потребуется, а что — лишнее, нарабатывается в основном с опытом.

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

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

Задача

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

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

Решение

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

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

На практике выясняется несколько моментов:

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

Трачу еще часа два на то, чтобы перенастроить формулы и «укомпактить» табличку. Для рассмотрения на совещаниях лишние столбцы скрываем.

С этой табличкой идем на совещание с руководством, продавцами и смежными департаментами.

Сложности

В дальнейшем я приделал к этой табличке механизм для сравнения различных отчетных периодов и расчет дельты: что сделано за выбранный период. Подсвечивались все стадии, на которых сменился статус, собиралась сводная статистика по исполнителям и категориям продуктов по периодам.

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

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

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

Я нашел единственный действенный способ с этим бороться. Он не очень системный, но довольно простой. Вот отличный туториал (кстати, рекомендую этого тренера — топовые рекомендации по экселю).

Результаты

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

В совокупности на разработку и поддержку таблички я потратил часов десять-двенадцать на протяжении пары месяцев (в начале — больше, разумеется).

Больше кейсов и полезного контента про менеджмент и продуктивность — в моей Тележке.

Очень часто, когда я занимаюсь с командами планированием проекта — в качестве руководителя проекта или «играющего тренера», — возникает проблема с планированием сроков. Дескать, как можно прогнозировать какой-то срок по проекту, когда непонятно, что делать? С другой стороны, мы же не можем поставить в плане «ХЗ пока».

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

Так как же быть?

Два вида сроков

В этой ситуации я всегда сначала объясняю, что на самом деле существует два вида сроков:

«Когда можем» — это технологически и ресурсно обусловленный срок. Мы понимаем, что нужно сделать и какие ресурсы доступны. Это позволяет нам сказать: окей, мы выполним эту работу к такому-то числу.

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

Мне рассказывали про одного члена Правления банка, который говорил: «Не можете сказать срок? Тогда я вам скажу срок!».

Начинаем «крупными мазками»

Второй нюанс заключается в том, что проект можно планировать, постепенно повышая точность. Более того, в моем любимом PRINCE2 (британская методология управления проектами) это вообще способ по умолчанию. В других источниках это называется «метод набегающей волны».

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

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

Срок — это принятие обязательств «со звездочкой»

Если вы работали в гос.органах или в гос.компаниях, возможно вы сейчас подумали: «Ага, я скажу предварительный срок, а мне потом его „пришьют“. Нет уж, спасибо!». Действительно, такое бывает. Здесь уже надо включать мастерство управления ожиданиями заинтересованных сторон.

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

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

Сроки — не самое важное

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

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

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

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

Ну и, конечно, важно помнить, что счастье заказчика = результаты — ожидания заказчика.

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

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

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

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

Как изменилось отношение к занятиям

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

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

Помню, я задался вопросом: «А когда же я его купил?» — и с удивлением понял, что пролетело целых три года. В этот момент я подумал, что если бы все эти три года я занимался всего лишь по пять-десять минут в день, они прошли бы так же быстро.

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

Не разрывай серию

После этих осознаний я решился и купил подписку на приложение Melodics, которое предназначено для музыкальных тренировок. Одна из фишек его в том, что он отмечает, сколько дней подряд ты занимаешься, и если серия не прерывается, забавно поздравляет тебя и дарит подарки (реально, приходят наборы сэмплов на почту, что очень мило). Дополнительно помогает укрепить «коммитмент» чувствительная стоимость подписки :)

Надо сказать, что принцип «не разрывай серию» — это один из самых мощных способов внедрения привычек, большая часть трекеров привычек основана на нем. В моем случае это прекрасно сработало. Самая длинная серия у меня составляет 335 дней, но я думаю, что смогу побить этот рекорд :)

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

Здоровая безамбициозность

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

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

При этом я верю в силу маленьких действий: «Быстро — это медленно, но без перерывов». Помню, увидел на каком-то тренинге эту фразу и мне она очень хорошо зашла.

Кстати, об этом много пишет горячо любимый мной Джеймс Клир, которого я уже однажды рекомендовал. Помнится, меня впечатлила его статья How to Fall in Love With Boredom and Unlock Your Mental Toughness, где как раз говорится о том, что настоящее мастерство приходит к тем кто умеет долго делать какие-то нудные повторяющиеся вещи.

Честно говоря, в данный момент у меня не так много времени на музыку. Кроме ежедневного Мелодикса я ей не занимаюсь — приходится выбирать между постами в блог, работой и музыкой. Однако я совершенно не переживаю на этот счет: я знаю, что через пару лет это намерение у меня никуда не пропадет, а навык пусть себе спокойно копится. Главное, не прерывать серию.

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

Сегодня поговорим о том, почему так происходит.

Управление организационными изменениями идет из индивидуальной психологии

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

ADKAR — это аббревиатура от awareness, desire, knowledge, ability и reinforcement, означающих последовательные стадии изменений, которые должен пройти каждый из тех, кто должен измениться. Давайте разберем суть этих стадий на примере: мы хотим заставить близкого родственника бросить курить.

Awareness. Осознание необходимости изменений. Часто это — самая сложная стадия, особенно в нашем примере. Согласитесь, что пока человек не согласен, что курить — вредно, он никуда не сдвинется. Например, говорит: «А, я курю самокрутки (или тонкие сигареты), от них нет такого вреда, как от обычных сигарет».

Desire. Желание изменений. После того, как человек осознал, что изменение необходимо, надо сделать так, чтобы он захотел меняться. Вполне возможно, что ваш курящий родственник отлично знает, что курение вредит, но не чувствует, что оно вредит персонально ему. Или ему нравится эстетика курения, он обожает фильм «Кофе и сигареты», а может курит красивую трубку. Пока на его внутренних весах негативные стороны от курения не перевесят позитивные, он не сдвинется с места.

Knowledge. Знание. Положим, человек захотел бросить курить. Возможно даже попробовал, но сорвался. И здесь ему очень пригодится знание о том, как правильно бросить курить. Тут ему зайдет книга Алана Карра, или хотя бы совет тех, кто бросал курить: «Чувак, тяга пройдет через какое-то время и станет легче». Обратите внимание, что шаг «знание» идет на третьем месте. Бесполезно пичкать обучением людей, которые не знают, зачем им это может пригодиться и не хотят этого.

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

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

С курением понятно, но как же это применить для проектов?

Основная идея ADKAR в том, что каждый субъект изменений (например, каждый пользователь внедряемой системы) должен пройти через каждую из этих стадий строго последовательно, и для проведения людей по каждой из стадий предлагаются практичные методы.

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

Чтобы повысить желание участников меняться, важно объяснить людям, чем будут полезны изменения именно для них. ADKAR предлагает лайфхак: мессадж о стратегических целях лучше исходит от высшего руководства, но рассказ о том, как изменятся условия труда конкретного сотрудника — от непосредственного руководителя.

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

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

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

У всех разное понимание того, что такое «цель»

Для начала расскажу случай из практики.

Мы запускаем портфель проектов по организационным изменениям в компании: есть стратегия СЕО, все подразделения готовят проекты. Я отвечаю за то, чтобы в каждом из проектов было корректно сформулировано, какие цели он преследует, каким образом и пр.

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

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

Это был первый раз, когда я понял, что «цели» — очень, очень размытый термин, но с тех пор я убеждался в этом неоднократно. Правда я не сразу разобрался, как с этим быть.

Так как же быть?

То, что получается в итоге и благодаря проекту, можно разделить на следующие группы (объясняю по-простому, методологов прошу заткнуть уши):

1. Продукт проекта. Это то, что непосредственно создается в ходе проекта. Какие-то физические объекты или материалы в электронном виде. Например, если мы разрабатываем новую версию сайта, продуктом проекта будут скорее всего элементы сайта (в зависимости от того, как нам удобнее управлять): отдельные страницы, онлайн-калькулятор, форма заказа — то есть, те элементы, которые мы можем разработать и передать в эксплуатацию цельными кусками. Или, например, выкинуть из проекта (хотя бы в теории).
2. Результаты проекта. Это изменение каких-то показателей, которое произошло благодаря сайту. Например, увеличение просмотров страниц (по сравнению со старым сайтом), показов рекламы, скорости регистрации/покупки — то есть, улучшение процесса, которое произошло благодаря применению продукта проекта.
3. Выгоды проекта. Это измеримое улучшение бизнес-показателей, которое произошло благодаря результатам проекта. Выгоды чаще всего про деньги: прибыль, выручка, сокращение издержек. Иногда — увеличение доли рынка или иных показателей. В чем разница с результатами? Выгоды — это то, ради чего компания делает проект. Просмотры страниц вы «на хлеб не намажете»: обычно заказчик ожидает, что благодаря просмотрам вырастут какие-то финансовые показатели. Даже если вы делаете сайт-визитку, его тоже лучше привязывать к каким-то значимым и измеримым бизнес-показателям. Иногда это сделать сложно, но важно пытаться и задавать себе этот вопрос.

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

Обратите внимание: в описанной схеме нет такого понятия как «цели проекта». Потому что «выгоды», «результаты» и «продукт» гораздо точнее и позволяют определить, что и ради чего мы делаем.

Знаю, что различие между этими терминами тяжело заходит, поэтому давайте на закрепление еще один пример. Проект «Внедрение CRM системы» (это система, где продавцы работают и ведут информацию о всех клиентах):

• Продукт: сама CRM система. Для удобства управления мы скорее всего поделим ее на модули: ключевой функционал, интеграция с соцсетями, интеграция с АТС и т. п.
• Результат: увеличилось количество звонков, увеличилось количество коммерческих встреч на продавца.
• Выгоды: увеличилась выручка компании.

P.S.: А «Цели и задачи» вообще приехали из наших студенческих времен, когда мы писали курсовые. «Задачи» в проектном управлении есть, но означает совсем другое: в принципе то, что делается в рамках проекта, и «задач» могут быть сотни и тысячи. Точно не подходит для целеполагания всего проекта.

P.P.S.: Предупреждаю: множество лучших умов в области проектной методологии сломали десятки копий над русскоязычной терминологией в этом вопросе. Я привел свою версию, но на всякий случай приведу английскую, с которой таких вопросов нет: output (продукт), outcome (результат), benefits (выгоды).

Когда речь заходит о дисциплине, я часто вспоминаю прикольную концепцию из книги Discipline without punishment. И хотя в чистом виде она применима скорее в производственных ситуациях с линейным персоналом, тем не менее, она очень наглядно иллюстрирует экологичный и вместе с тем сильный подход к дисциплине.

Техника состоит из четырех ступеней.

1. Первое нарушение дисциплины. Руководитель реагирует на нарушение в устной форме. Дескать, чувак, эта ситуация сейчас была не желательна, от нее такие-то плохие последствия (или «у нас так не принято»). Пожалуйста, не делай так больше.
2. Второе нарушение дисциплины. Руководитель опять разговаривает с сотрудником, но уже в более формальном режиме. Объясняет, в чем суть нарушения, указывает на то, что уже был разговор, и сообщает, что так дальше не пойдет. Компания требует соблюдения определенных норм, и поведение, которое им не соответствует, неприемлемо. После этого разговора руководитель отправляет формальное письмо с резюме разговора.
3. Третье нарушение дисциплины. Руководитель предоставляет сотруднику отгул за счет компании на целый день со следующим посылом: «Чувак, это поведение неприемлемо, и мы это обсуждали. Пожалуйста, возьми отгул, и в этот день, в спокойной обстановке подумай о том, как ты видишь свое будущее с компанией. После отгула поговорим, что надумал». После отгула руководитель встречается с сотрудником и обсуждает ситуацию, выслушивает, какие меры он примет, чтобы исправиться, договаривается о следующих шагах.
4. Увольнение. Это последний шаг, но это не кульминация дисциплинарной системы, а скорее ее провал.

Естественно, в последовательности речь идет об одном и том же нарушении дисциплины.

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

Понятно, что на практике все несколько сложнее.

• Сотрудник может нарушать каждый раз разное.
• Сотрудник может нарушать не со зла, просто не догонять, в чем проблема.
• Договаривались не нарушать одно, а он нарушил что-то другое, но рядом, и граница не очевидна.
• Руководитель не всегда умеет/находит силы сделать «отсечку» и дать обратную связь, начинает говорить о дисциплине, когда уже все распоясались.
• Не всегда вы можете уволить сотрудника или дать ему отгул, тем более за счет компании.

И еще сотня кейсов. Но схема от этого не перестает быть полезной, потому что «включает лампочку в голове» и как минимум помогает ориентироваться в ситуации.

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

Как узнать «переход на личности» и «оценочные суждения»?

Переход на личности заключается в том, что критике подвергается сам человек, какие-то его качества, которые ему присущи. И не только очевидные вес, сексуальная ориентация, акцент и т. п. — тут все более-менее понимают, что это прямая атака. Есть менее очевидные формы, которые в офисной жизни встретить довольно легко. Например: «Вы вечно делаете все так-то и так-то (плохо)», или «ты не разбираешься», «нихрена ты не умеешь».

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

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

Почему эти заходы неконструктивны?

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

Если я не умею, не шарю и т. д. — с этим сложно что-то поделать в моменте. Что я, вот прямо сейчас разберусь и научусь после того как мне это сказали?

«Ужасная презентация» — к чему меня подталкивает эта эмоциональная характеристика? Что мне изменить?

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

Что делать, если в отношении вас применяют этот прием?

Есть пара отличных, почти магических вопросов, которые позволят вернуть диалог в конструктивное русло:

1. В чем это выражается?
2. Чем это плохо?

Давайте посмотрим, как их применять.

— Вы прислали ужасную презентацию. Просто кошмар какой-то.
— Ужасную? В чем выражается?
— У вас все иконки из разных наборов.
— Окей. Чем это плохо?
— У нас есть корпоративный гайдлайн по разработке презентации, в котором четко указано, в каком стиле должны быть иконки. Мы не сможем никому отправить презентацию, которая не соответствует гайдлайну.

Или другой пример:

— Вы работаете отвратительно!
— В чем это выражается?
— Вы отправляете мне письма в 12 часов ночи!
— Чем это плохо?
 — У меня приходят уведомления, и муж спрашивает, кто это тебе пишет в такое время! (реальный кейс, кстати ;))

Благодаря паре простых вопросов мы быстро переводим неконструктивное обсуждение во что-то, с чем можно работать.

При этом важно не забывать про эмоции

Важно понимать, что часто люди говорят такие вещи на эмоциях, а эмоции — это химия, которая попадает в нашу кровь и мешает связно мыслить. Кроме того, эмоции чем-то вызваны, и возможно — поводом для них послужило ваше поведение.

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