Здарова 👋
Тут все просто. У меня есть немного экспертизы в пиэмных и продуктоунерских делах, а ещё я последние лет пятнадцать так или иначе кем-то руковожу.
В связи с этим у меня накопилось какое-то количество мыслей про менеджмент, разработку продуктов, ведение проектов и все такое.
Буду сюда понемногу эти мысли выкладывать.
Очевидно, что все это ни в коем разе не является советами как нужно или не нужно поступать. У всех разные ситуации, проекты и команды. Воспринимайте все эти записки охотника сугубо как разговор с другом за бокалом пива.
Глобально есть несколько правил:
Обязательно заходите в комментарии и высказывайтесь по теме
Если тема зацепила — закидывайте в избранное и шарьте друзьям
В комментах ведите себя прилично
Если есть предложения по темам — пишите в комменты.

Расфокус у манагеров

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

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

Fake it until you make it (Part 1)

Нужно, наверно, написать заметку про главный принцип карьерного успеха : «Fake it until you make it”, хотя мне больше нравится формулировка «if you want a quality, act as if you already have it». Тема эта объемная и, чтобы подробно в ней разобраться, нам потребуется несколько подходов.

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

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

Fake it until you make it (Part 2)


Че, давайте продолжим. Мы остановились на том, что у нас появился некий первый квази опыт.
Дальше нужно стать инициативным. Тут важный момент, если инициатива это прям не ваше, то на этом лучше закончить и не мучаться себя. Людям без инициативы в менеджменте делать нечего.
Что такое инициатива? Когда за большим столом главный босс спрашивает кто будет ответственным за новый проект, и все сидят рассматривая туфли, инициативный чувак скажет, что он готов. Отдельный вопрос конечно как оказаться за таким столом (обсудим позже).
Как проявлять инициативу в проектных делах? Универсального ответ нет. У меня однажды попросили дать экспертную оценку по идее одного проекта. Фирма думала над новым направлением, а у меня была техническая экспертиза. Вместо сугубо оценки, я расписал подробно как бы я запустил этот проект, этапы, требуемые ресурсы, скоуп (см. предыдущий пост). Отправил и забыл. А через пару месяцев мне позвонил зам директора и предложил попробовать заменеджерить этот проект. Логика была примерно такая, свободного менеджера в конторе не было, быстро найти не могли, а боссу было важно запустить к определенной дате. Получается проявил инициативу.

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

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

Два подхода к ресурсу кадров

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

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

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

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

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

Вот и получается, что эффективная эффективность в долгую не всегда эффективна.

Вопрос: Что НЕ нужно делать при управлении проектами, чтобы не зафейлить все? Ну условно, какие самые частые ошибки делают люди при управлении проектами, которые грамотный прожект не сделает никогда?

****
Серебряной пули тут, разумеется, нет. Все зафейлить можно всегда. Расскажу что делаю я, но, на всякий случай повторюсь, это не панацея и у каждого свой путь.

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

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

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

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


Ошибка в управлениями ожиданиями заказчика. Заказчик (внешний либо внутренний) всегда давит по срокам и скоупу. Если не умеешь выстроить общение так, чтобы не соглашаться на все, то по-любому окажешься в ситуации когда вся команда задолбалась, ничего не успели и ещё и получили за это от боссов. Хотя на ранних этапах можно было аккуратно съехать, мол вот есть комитмент на обьем и срок, и девять беременных за месяц ребенка не родят…

Что ещё может привести к краху проекта?
Отсутствие «второй пары глаз». Как там говорят, что один в поле не воин. Мой подход, что все всегда нужно обсуждать с кем-то ещё. Любо важный документ, схема, решение, комитмент должны проходить верификацию второго человека. В идеале круто иметь адекватного зама/ помощника, но можно просто найти адекватного чела в команде и попросить проверить все ок.

В комментах предлагаю оставить свои советы, как все не зафакапить.

Из опытного девелопера в менеджеры

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

Но я не про то хотел сказать. Технари с 10 стажем однозначно крутые менеджеры если у них есть набор менеджерских скилов. Но проблема в том, что таких технарей мало, а тех, кто хочет после 10 лет хочет брать на себя ответственность и управлять живыми людьми и общаться с живыми заказчиками и того меньше. Более того, часто услышав о желании технаря пойти в манагеры боссы рассуждают так: «Ну и что в итоге? Мы потеряем хорошего девелопера, а получим хренового менеджера». Да и вообще, проекты исчисляются десятками, если не сотнями. Где вы в рамках даже большой конторы найдете столько технарей которым стало тесно?

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

Что думаете?

Трудовая дисциплина

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

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

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

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

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

Умеренность в планировании

Вопрос из комментов:

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

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

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

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

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

Что думаете? Обсудим отпуска?

Отпуск

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

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

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

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

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

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

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

Обратная связь
Если вы кем-то руководите, то наверняка ваши сотрудники в какой-то момент либо косячили либо наоборот показывали неожиданно хороший результат. В обоих случаях от вас, как от руководителя, они должны получить обратную связь.
В каком формате эта связь должна даваться?
Строго говоря, это зависит от человека. Есть несколько типажей, кому-то важно тупо премия, кому-то чтобы об его успехах объявили публично, а кому-то то, наоборот, лучше получить одобрения с глазу на глаз.
К слову о премиях, маленькая премия хуже, чем никакой премии. Типа если бюджет ограничен, то лучше подкопить и дать хорошую премию чем часто номелкие.
С негативной обратной связью все немного проще. Ее дают либо один на один либо с hrbp, при этом важно критиковать не человека а его поступки и результаты и все такое. Ещё при негативной обратной связи важно обсудить, что будем делать, чтобы это не повторилось. Причем это нужно фиксировать не как «мы за все хорошее» а в максимально конкретных терминалах, типа «до пятницы настроим бекапы на такие-то окружения».

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

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

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

Премирование

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

Кого премируют и как часто. Премируют только за явные достижения либо если работник делал то, что делать не должен был.
С перым понятно. Команда круто поработала, проект запустили без задержек и косяков. Работали над проектом полтора года. После запуска все получили премию в размере 3-4 оклада. Круто? Конечно! Удачный запуск это достижение, и, я уверяю, все запомнят эту премию.
Но, при этом, они не получали каждый месяц премии за работу над проектом. Т.е. премия не воспринималась как зарплата.

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

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

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

Особенности трудоустройства в загнивающей

Что скажет чат?

Неплохая статья про рост синьоров в манагеры и о том что делать, если не хочешь в манагеры. https://devby.io/news/kuda-rasti-senoru

Че думает чат?