О том, как писать протоколы рабочих встреч.

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

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

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

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

Из написанного выше легко объяснить,
что должно быть и чего не должно быть в хорошем протоколе:

➕- принципиальные решения, которые нужно на будущее сохранить и использовать при необходимости, достав из загашника протокол;

➕- поручения c максимально однозначно трактуемыми формулировками, с указанием ответственных и сроков;

➖:
- размытые формулировки;
- фразы, неоднозначно трактующиеся или не имеющие ценности как результат встречи;
- фразы, которые не позволят или затруднят его пересылку внешним читателям.

Практические советы по написанию протоколов встреч.

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

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

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

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

Пара хинтов, которые позволят не создать такого впечатления по неосторожности:
🐣 Если после встречи и до отправки протокола ситуация поменялась - прямо так открыто написать. Я для этого употребляю слово update, ты можешь выбрать другое.
Например: update: обсудили после встречи с {тем-то}, не получится так, как договорились, поставлю отдельную встречу.
или update: узнал, что есть приказ, и поэтому не получится как договорились. Предлагаю...

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

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

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

Менеджер поддерживает приоритетный проект во время созвона по другому проекту.

Топ событий, которые помогли мне вырасти как менеджеру

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

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

Так случилось, что я почти одновременно стал развиваться и как руководитель проекта и как линейный руководитель. Мне дали проект (-ы) и дали подчиненную, а потом еще двух.

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

1. Замечание моего руководителя: "да дай ты ей ошибиться!".
Моя первая подчиненная и ключевой аналитик в первом проекте оказалась уровня Junior, а сидели мы рядом. И я видел просто каждую ее ошибку в реальном времени и тут же корректировал.
Объяснить все заранее на 100% было невозможно, а девушка, естественно для junior'а ошибалась. А я видя ошибки - тут же корректировал.
В общем, получилось, что я ее завалил замечаниями и корректировками и, в конце концов "затрахал". Не получилось у нас работать вместе.

Нынешний я даю возможность человеку ошибиться. Мне гораздо важнее, чтобы он ошибку осознал и сам исправил. Или я помогу ее осознать и исправить, но уже не в реальном времени. Да и на ошибки реагирую спокойнее.
А еще стараюсь, чтобы между мной и junior' ом был посредник уровня lead.

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

3. Три подчиненных отреагировали по-разному в сходной ситуации.
Так случилось, что трое первых моих подчиненных в разное время в сходных ситуациях почти одинаково ошиблись.
Важность ошибки примерно такая: сильно наказывать не надо, но не отреагировать нельзя.
Всем троим я сказал +/- один и тот же текст. С чуть негативной интонацией, но не пережестил (как я считал).
Реакция у каждого из трех была разная.
Один - начал в деталях уточнять а что не так, и как надо было
Другой - сказал ок, и пошел дальше работать
Третий - обиделся.

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

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

#СлучилосьСоМной

О принятии менеджерских решений.

#Пятничныймем

@ManagersThinks

О хорошем для принятия решений Excel-файле.

У хорошего для принятия управленческих решений XLS-файла должны быть следующие свойства:

1. Он должен легко фильтроваться по заголовку.
2. Из него легко получается сводная таблица со статистикой
3. В строках не должно быть разнородной информации вида мухи + котлеты.

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

Сводная таблица помогает сделать вывод из всей инфы на листе.
Как для коммуникаций (всего - Х, из них Х1 - таких-то, Х2 - сяких, как в этом примере), так и для принятия управленческих решений.
Хорошо помогает группирующий столбец, в котором немного значений.

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

@ManagersThinks

РБК вырывается вперед с мемами

⬆️ Часто доводилось в своих проектах слышать об ограничениях, которые логически объяснить невозможно.

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

Моя рекомендация - потратить чуть время и копнуть.
Почему так? А чья это позиция? Чем он объясняет?
В общем, "метод 5 почему".

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

Что можно потерять: от одного до нескольких часов на выяснения. Да и то в результате получить объяснение для себя почему так - и успокоиться.

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

Хотя исходно принцип KISS - Keep It Simple Stupid был придуман для инженеров, буквально

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

в менеджменте этот принцип работает даже еще более явно.

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

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

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

Немного о себе и о мотивации.

⚽️В юности я играл в футбол. Много, часто. Дорос до любительских чемпионатов на большом поле, с судьями и экс-профи в командах. В общем, вот так как-то.

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

Перерыв.
Погода противная, игра у команды не клеится.
Подводит тренер футболистов к трибуне - а на трибуне ровно один болельщик, с флагом.
- Видите вон того одинокого болельщика? Вот для него мы и играем.

Вот и с телеграм-каналом как-то так :)

#ПроМеня
@ManagersThinks

Шикарнейшую мысль прочитал у В. Мараховского. Приведу полностью, с моим выделением.

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

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

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

Увы, мы не то что редко признаёмся в наличии таких предохранителей — мы даже не всегда о них знаем. Это затрудняет и их преодоление.

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

Но на самом деле это - актуально для любого человека, включая меня и читателей этого канала.
До какого-то момента человек стремится добиться успеха - будь-то социальный лифт, карьерный рост, достижение личных целей.
А потом считает, что дальше рвать жилы и не обязательно - и так не плохо.
Для объяснения себе этого подхода каждый человек выбирает комфортные для себя формулировки:
"work-life-balace,
мне нужно больше времени уделять семье,
всех денег не заработаешь,
хочу больше пожить для себя,
хочу сократить уровень стресса в своей жизни..."

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

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

Делегировать не задачу, а идею.

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

А вот если ты делегировал идею, то зрелый чел будет ставить нужные задачи себе и другим сам.
И решит.

Как делегировать идею?

1. Найти "бесхозную" идею.
Но не "внедрить проект качественно", а, например:
"продумать как раскатать новое решение не сразу на всю клиентскую базу, а по частям, и по каким + план отката"

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

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

4. Профит.

Когда получил срочное поручение руководства, а у тебя было много всего распланировано на сегодня.

#Пятничныймем

О принципе "не я - так никто" в корпорациях

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

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

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

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

Означает ли это, что инициативность - это плохо?
Ни в коем случае.
Просто в какой-то момент необходимо свою работу передать тому, кто за этот функционал отвечает.

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

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

Когда не знаешь, какое проектное решение принять и обратился за помощью к проектной методологии

#Пятничныймем

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

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

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

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