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

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

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

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

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

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

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

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

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

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

Бывает, что делегирование заканчивается примерно так (и не только у дев 😜).

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

Понятно, что когда команда большая - есть много вариантов как этого избежать.
В порядке буллитов выше, как пример:
- собрать участников, рассказать идею, заинтересовать, продать идею "добровольцу";
- поставить задачу тим-лиду, чтобы дальше ее поставил от себя;
- поставить тому, чьи hard и soft скиллы позволяют решить задачу лучше.

Что делать, у тебя всего 1-2 человека?
Два слагаемых: взаимное доверие и консенсус в направлении развития чела.
Он доверяет тебе в постановке задачи и корректировке.
Ты - доверяешь ему в способности расти, в выборе решения и даешь право на ошибки.

Иначе - SMART +детальный контроль, что для меня первый шаг к вежливому расставанию.