Менеджер от боженьки
26.6K subscribers
44 photos
2 videos
267 links
Проджект менеджмент в IT.

Рома Ковалевский — о современных деливери практиках, продуктовой разработке и как быть классным менеджером.



Сообщество менеджеров: @pm_sovet

Реклама: @pm_god_ads

Для РКН: 5035224482
加入频道
«Пиши, сокращай» 🔪

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

- думать о цели текста;

- структуре;

- быть последовательным;

- избавляться от оценок и мусора;

Каждая идея подкреплена понятными примерами. Отдельная глава посвящена тексту в рекламе. Будет про резюме, молодую, динамично развивающуюся компанию профессионалов ("о нас"), рассказ о продукте. Маркетологи и продакты - вам сюда.

Есть в книге одна спорная мысль - "не сглаживайте углы". ПМам нельзя принимать ее на веру. Умейте признавать свои грехи, но старайтесь сохранить лицо.

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

Едете в метро на любимую работу, скролите ленту а там обещают увеличить ваш velocity на 3 стори поинта за месяц😱. Предвкушаете мощный лонгрид, но на следующей выходить. Не хочется упускать полезный контент, а если не сохранить его до лучших времен, то анафема неизбежна. Скопировать урл статьи и сохранить в google keep долго и неудобно. Благо существует более элегантное решение - pocket.

Работает он просто. На каждом сайте есть блок с шэйринговыми кнопками. В их списке ищите иконку покета. Нажимайте поделиться и статья сохранится в список to read, вроде беклога. Возвращайтесь к нему, когда будет время и читайте христа ради. У сервиса есть веб-версия и мобильное приложение, которое кеширует статьи, так что их можно прочитать даже без интернета. Лайк!

К сожалению, не на всех сайтах есть кнопка "сохранить", например на медиуме она отсутствует. Проблему решает плагин для Хрома "Save Pocket". После его установки, нажимаете правой кнопкой на любой странице, выбираете "Save to Pocket", и страница сохраняется в ваш список.
Критерии успешности проекта

У каждого ПМа есть босс, перед которым тот отвечает за успех проекта. Очень круто, если у них есть возможность встретиться раз в неделю и обсудить как идут дела. Так или иначе, на таком мите будут затронуты следующие темы (они же критерии успешности проекта):

📌Основные:

- Сроки

- Бюджет

- Скоуп

- Качество

- Удовлетворенность клиента


📌Дополнительные:

- Удовлетворенность команды

- Финансовые показатели (клиент вовремя платит, команда рентабельна)

- Процессы + технологии

- Апсейл
Команда не вкладывается в оценки

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

- детализировать требования. Чем четче сформулирована задача, тем точнее оценка;

- дробить фичи мельче. Оптимально 1-4 дня;

- разбивать фичи на задачи (декомпозиция). Выделяйте таски на бекенд, фронтенд, тестинг, и т.д. Максимум 1.5 дня на каждую. Если не выходит меньше - см. пункт 1;

- делать прототипы\инвестигейты на сложные фичи;

- проводить ретры, обсуждать причины вылетов с командой;

- привлекать внешних спецов, если не хватает экспертизы;

- закладывать средний вылет в будущие оценки;

- трекать успеваемость (оценка vs фактические затраты) по каждому члену команды. Доносить на 1-1 митингах;

- менять ребят, которые много и часто вылетают (>60% за 3-6 месяцев);

Вылет в 20-30% считается допустимой нормой, его стоит закладывать в начальную оценку. Берегите себя и свои эстимейты.
Гаджет time sheet

Используйте этот гаджет для:
- отслеживания прогресса по задачам;
- составления отчета по бюджету;
- таймтрекинга сотрудников;

как это работает:

Сделайте правилом логать время перед стендапом и выставлять при этом remaining estimate в задачах. Цифра обновляется автоматически, когда логаешь часы. Усилия потребуются, только если намечается вылет из оценки. Разработчик будет заранее думать сколько ему осталось на таск и приходить на стендап подготовленным. Так сэкономите время на вытягивание ответа "сколько осталось на задачу?". 

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

Вася отработал 6.5 часов в понедельник? Увидите в таблице, возьмете на карандаш, теперь полторашку должен.
Icebreaker на эмпатию

Что такое icebreaker и зачем нужен.

Реквизит: доска, 1 маркер и 1 стикер на каждого члена команды. Заранее нарисуйте на доске 6 ликов со следующими эмоциями: грусть, злость, стресс, радость, энтузиазм, спокойствие.

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

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

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

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

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

- научился новым навыкам, которые помогают в работе;

- провел обучающий тренинг для коллег в отделе;

- улучшает процессы в компании;

- растит людей в своей команде;

- прошел сертификацию, получил почетный сан;

- развивает аккаунт, помогает клиенту;

- выросла команда = выросла нагрузка, не пострадало качество;

- допродал людей / новый проект;

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

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

Звонил боженька, просил добавить к предыдущему посту:

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

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

💰Не говорите своих ожиданий по зарплате, пока работодатель не озвучит свои. Это первое правило, которому учат на всех переговорах.

💰Второе правило - не соглашайтесь на первое предложение. Не стесняйтесь говорить о деньгах и улучшать свои условия.

💰Обсуждать можно не только зп, но и другие перки: дни отпуска, бонусы, всякого рода компенсации, кресло Herman Miller, наконец.

💰Даже если зарплату подняли, не забудьте узнать что надо прокачать к следующему ревью.
Personal meetings, часть 1

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

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

Структура:

- что было хорошо, что можно улучшить (фидбек от сотрудника);

- что было хорошо, что можно улучшить (фидбек от менеджера);

- ставим задачи, исходя из 1 и 2;

- планируем развитие в рамках проекта, новые обязанности (при желании сотрудника);

- смотрим вылеты за эстимейты, разбираем почему случились;

- золотая коллекция вопросов;

Главная задача менеджера на персонале - узнать об проблемах/эмоциях/ожиданиях сотрудника и помочь скорректировать их. 

Во второй части будет та самая коллекция вопросов и несколько хороших практик. Не переключайтесь.☝️
Personal meetings, часть 2

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

Оцени от 1 до 10:
- Насколько комфортно работать с лидом (qa, dev), остальной командой?
- Интересен ли проект, задачи?
- Как оцениваешь процессы?
- Насколько ты счастлив на этой работе?

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

Субъективно, оценки 6 и меньше - индикатор серьезных проблем и угроз. 💣

Для обратной связи на работу ПМ, отлично заходит такой вопрос, который я подсмотрел у Ани Булдаковой:
Есть ли что-то, что я должен начать/прекратить/продолжить делать как твой менеджер, чтобы тебе стало лучше работать?

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

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

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

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

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

Пара советов:

- просите заказчика подтвердить что все верно в ответном письме. Двойная страховка.

- берегите время - пишите кратко. Фиксируйте только конкретные договоренности, которые играют роль, типо "отправим билд завтра".

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

Друзья, нас уже тыща! Спасибо что читаете боженькины манускрипты.

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


P.S. В четверг буду на Product Sense в Минске, пишите в дм, если будет желание потрещать.
Статистика проекта

Люди врут, а цифры нет. С помощью статистики можно увидеть проблемы, которые так просто не заметишь. Это огромное поле для анализа и экспериментов. Если агрегировать данные за период, можно строить тренды и теории.

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

- разработка
- стабилизация (багфикс)
- коммуникации
- ручное тестирование
- автоматизированное тестирование
- фикс автотестов
- ПМ
- БА
- юнит-тесты

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

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

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

2. Посты действительно выходят нечасто. К сожалению, сейчас вдохновения и времени хватает только на 2 поста в неделю. Не хочется ухудшать качество ради скорости, пока оставлю так.

Всем божественной недели!
Personal meetings, часть 3 

Часть 1, часть 2.

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

- Всегда предполагать хорошие намерения. В большинстве случаев люди не хотят навредить, когда совершают ошибки. Вероятнее всего, они чего-то не знали\умели\не могли. Исходите из того, что человек хотел сделать добро. 

- Давать сказать.

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

- Готовиться. Сложно вспомнить на ходу все достижения\косяки, подобрать корректные формулировки. 10-минутная подготовка перед митингом упростит задачу. Лайфхак - значимые достижения\косяки можно записывать когда они случаются, тогда еще быстрее справитесь.

- Иногда достаточно лишь выслушать. Некоторые вопросы не имеют \ не требуют решения от ПМ, но людям становится легче, когда они выговорятся. Как правило, это что-то личное - проблемы со здоровьем, не хватает времени и т.п.

- Документировать результаты встреч (пример из жизни). Через 2 месяца сложно вспомнить все проблемы, которые были в прошлый раз. Доступ к результатам есть только у ПМ и сотрудника, чтобы поддержать атмосферу приватности.

Коллеги, осталась нетронутой тема эстимейтов. Сделаю из нее отдельный пост, поскольку она выходит за рамки персоналов.
Попадание в оценки как метрика, часть 1

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

- налажен процесс оценки;

- есть рабочая система для измерения вылетов;

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

Эта метрика хороша тем, что ее легко измерить. Сложно (но возможно) оценить насколько эффективно программист делает код ревью или фиксит баги. Еще сложнее увидеть прогресс по сравнению с предыдущим периодом. Разумеется, стоит учитывать и другие показатели, при оценке сотрудников ☝️.

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

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

- задачи должны быть оценены до старта работ;

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

- механику planning poker можно использовать, чтобы достичь договоренности в сложных тасках;

В следующем посте расскажу как построить систему измерения вылетов и как интерпретировать цифры.
Попадание в оценки как метрика, часть 2

Чтобы мерить вылеты, в джире должно быть как в храме - чистота, порядок, ощущение величия. На практике это означает, что каждая фича разбивается на подзадачи (sub-task) и асайнится на разработчика, который будет ее делать. Затраченное время логается строго в подзадачу. 

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

- багфикс и инвестигейты (их лучше вообще не оценивать);

- задачи, которые начал один сотрудник, а закончил другой;

- подозрительные тикеты (плохо оцененные изначально, измененные по ходу и т.д.)

Гаджет Rich filter Statistics визуализирует данные. Если гаджета нет, можно сделать выгрузку в эксель и посчитать вылет, поделив original estimate на time spent. В итоге должно получиться примерно как на картинке внизу. 


Теперь анализируем результат. Вылет до 25% - ок, все что больше - не ок. Кроме персонального вылета полезно исследовать еще две цифры:

1. Общий вылет по команде. В соотношении с личным вылетом, можно сделать какие-то выводы.
Пример 1: общий = 25%, личный = 10% - сотрудник молодец.
Пример 2: общий = 10%, личный = 25%. Хоть 25 и находится на приемлемой границе, остальная команда вылетает меньше, нужно разбирать почему у сотрудника не получается вкладываться в оценки.
Пример 3: Общий = 40%, личный = 40%. Хоть 40 и превышает приемлемую границу, у остальной команды тот же результат. Вероятно, проблема в процессах, оценках, чем-то еще.

2. Общий вылет по технологии (если их больше 1). Похоже на предыдущее, только выборка уже, а результат репрезентативнее. Логичнее же сравнивать оценки андроид команды между собой, чем с бекендом+тестировщиками.
Сердце Скрама

В скрам гайде есть глава Scrum Theory, где описаны 3 основы эмпирического подхода (pillars of empiricism):

- Transparency - представлять факты в их истинном свете, доставлять нужным людям нужную инфу, быть на одной странице;

- Inspection - проверять процессы / продукт / людей / практики;

- Adoption - исправлять косяки, найденные в предыдущем пункте;

Вокруг них строится весь фреймворк. Это как фундамент дома - без него никак. Скрам работает не благодаря ролям, ивентам и артефактам, а именно из-за этих принципов. Сравниться с ними по значению могут только ценности, также включенные в скрам гайд - commitment, courage, focus, openness and respect.
Куда расти проджект менеджеру

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

Resource - хэд отдела ПМов, такие встречаются в компаниях 100+ человек. Помогает менеджерам расти, нанимает новых, распределяет между проектами. Иисус, наверное, был RMом - без любви к человеку здесь никак. 

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

Programm - ПМ ПМов. Бывает заказчику так нравится тратить деньги на одну команду, что он покупает еще несколько. У каждой из этих тим есть менеджер, а самый главный из них - программ. 

Account - развивает отношения с существующим клиентом. Главный по контрактам, доп. продажам, сбору фидбека и поздравлениям на праздники. 

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

Product - отвечает за фичи, метрики, пользователей, прибыль. В СНГ сейчас бум на эту специальность, много вакансий, курсов, конференций. Классный опыт, чтобы потом запустить свой проект.
Орки

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

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

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

Always assume positive intent!