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

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

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

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

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

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 +детальный контроль, что для меня первый шаг к вежливому расставанию.

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

В таких задачах у РП есть два больших вызова:

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

2. Неочевидный.
Так как задача - на несколько трайбов, а то и организаций,
то рано или поздно выясняется, что всем недостает описания сквозного процесса или хотя бы зафиксированных еnd-to-end бизнес-требований (БТ).
А нет их потому, что с внедрением Agile в компаниях исчезла как класс роль бизнес-аналитика.
Аналитик любой из команд знает функционал своего продукта и может быть еще пары своих соседей. А если команд, скажем, 15, то требований как должен работать новый процесс в целом - писать просто некому.

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

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

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

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

Когда энтузиазм и желание достичь результата - есть, а компетентности - немного не хватает

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