26448
Проджект менеджмент в IT. Современные деливери практики, продуктовая разработка и как быть классным менеджером. — Сообщество менеджеров: @pm_sovet Реклама: @pm_god_ads 5035224435
Менеджер - щит от говна сверху
- Я страшно доволен тем, что ко мне, к руководителю, претензии есть, а к газете (команде) - нет. В этом и есть моя работа.
из последнего интервью Дудя
Функции тимлида - чеклист
От компании к компании задачи тимлида отличаются. Они бывают разными даже в одной компании на разных проектах! Где-то тимлид лишь владеет кодовой базой, а где-то погружается в бизнес и полностью ведет разработку.
Любой команде нужно решить, как поделить функции тимлида. Часть из них может забрать проджект, продакт или сениор разработчик. Это ок, тут как договоритесь.
Если забить и не назначить ответственного, то есть шанс, что никто не будет, например, вести техдолг. Тогда команда будет тратить уйму времени при планировании, чтобы вспомнить все задачи по рефакторингу и решить, какую именно брать в спринт.
Используйте этот список как чек-лист, чтобы проверить, что на вашем проекте все эти функции кто-нибудь закрывает:
✅Пипл менеджмет
- Фидбек для разработчиков, PDP
- Онбординг
- Настроение в команде
✅Инженерия
- Качество кода
- Архитектура
- Выбор инструментов и технологий
- Мониторинг, логи, технические метрики
✅Процессы
- Оценки и вылеты
- Процессы разработки и поставки
- Код ревью и порядок в гитхабе
- Распределение задач по разработчикам
- Капасити команды
- Проверка качества груминга
- Работа с инцидентами
- Владение техдолгом (беклог + приоритеты)
Готовиться и собирать факты
Хороший софтскилл для любого ПМа - умение готовиться. К встрече с заказчиком, ретроспективе, перфоманс ревью. Всегда работает простой закон: чем лучше подготовишься, тем более предсказуемый получишь результат.
Например, утром понедельника ты видишь две незакрытые задачи у разработчика. Можно сразу написать ему в личку "а чего ты не все задачи успел?". Это быстро и экономит тебе время. Но сотрудник думает "хм, почему он спрашивает, если я на той неделе...?"
Прежде чем так писать, проверь факты:
1. не брал ли разработчик отгул или больничный?
2. на каких еще проектах он задействован? изменился ли там объем работы?
3. были ли зависимости? может, бекенд надо было ждать?
И так далее. Ответ может быстро найтись, тогда и вопрос уже не нужен. Ты сохранил себе лицо, а разработчик к тебе доверие.
Бывает и другая ситуация, когда разработчик говорит "знаешь, меня на другом проекте завалили работой". Это звучит подозрительно, ведь другого ПМ на общем митинге сказал, что его проект завершен. Кажется, здесь нестыковка.
Поэтому ПМу критично владеть именно фактами и докапываться до сути, когда необходимо.
Наконец, таких менеджеров, чаще промоутят. На это счет есть древняя байка: https://habr.com/ru/post/22548/
Как ищут баги
Поздним вечер в офисе остались только вы и тестер, остальные ушли на тимбилдинг. В канале urgent тэгают вашу команду и спрашивают все ли в порядке с видео конвертером. Вы открываете аналитику и видите, что метрики упали. Что-то идет не так 😬
Пока вы ищете программиста, готового подключиться для фикса, тестер будет искать баг:
🐞 Сделает смоук тест, но с ходу не воспроизведет. Судя по всему, проблема не из простых. Проверять будет, конечно, сразу на продакшене, чтобы избежать разницы в окружениях.
🐞 Попросит у саппорта уточнить у пользователей по каким шагам воспроизводится баг. Видят ли они какую-нибудь ошибку?
🐞 Посмотрит в Mixpanel (аналитика) есть ли зависимость по девайсам, браузерам, ОС, гео.
🐞 Посмотрит в Sentry (мониторинг) есть ли новые ошибки. Да, ошибки есть, но хрен пойми что значат, нужен программист.
🐞 Попробует корнер кейсы: отключит интернет, забьет физическую, оперативную память.
🐞 Попробует воспроизвести с разными форматами файлов. Приложение отработает с .mov, но упадет с .mp4. Кажется, дело в этом.
🐞 Попробует локализовать. Достанет предыдущую андроид сборку и пройдет те же шаги. Теперь не крашится! Скорее всего, проблема в последней сборке.
Тут уже и разработчик нашелся. Он доволен: шаги есть, логи и возможная причина бага тоже. Благодаря этому фикс будет быстрым.
Job security
Однажды я попал в большую американскую корпорацию. Она торговалась на бирже, в инженерной организации было 400 человек. Некоторые менеджеры надевали костюмы на видео-звонки. Проработал я там 3 месяца (не из-за костюмов).
В компании было несколько инженеров в возрасте 50+, которые работали уже больше 10 лет. Они знали все продукты и их взаимосвязи. Когда проектировали любую фичу, включающую несколько продуктов, сразу шли к ним, чтобы почеленджить и утвердить архитектуру. Особенно долго засиживались ребята из биллинга, в их системах было больше всего простыней с легаси.
Наши долгожители не писали код. Они лишь консультировали других разработчиков, да изредка делали код ревью. Их много раз просили перенести свои знания в любую форму документации. Но те отказывались, потому что знания, которых больше ни у кого нет - это сильный козырь и билет в счастливую пенсию.
Уволить их за отказ или просто надавить было нельзя. Потому что не дай бог уйдут, вся разработка встанет на следующий день.
Такая штука называется job security.
Опытный менеджер борется с job security и диверсифицирует проектные знания. Он распределяет задачи так, чтобы каждую частью проекта знали хотя бы несколько человек. Он выбивает у руководства время на схемы, апи доку, нормальную архитектуру.
Опытный менеджер боится другого английского словосочетания - bus factor. Это когда важного человека вдруг сбивает автобус и с завтрашнего дня надо как-то жить без него.
Когда немного поработал продакт-менеджером:
"ого, 66 поездок за день!"
Нужен ли трекинг времени
Нет, не нужен.
Давате расскажу почему.
Трекинг времени используют по трем причинам: следить за прибыльностью, следить за оценками, и следить за вами. Разберем каждый юзкейс.
1️⃣ Следить за прибыльностью проекта (profits & loss).
В аутсорсинге это жизненно необходимо. Как бы красиво сейлы ни заворачивали наши услуги, в конце концов, клиенты платят за часы программистов.
Чем больше часов выставим, тем больше будет прибыль компании. При этом потратить надо как можно меньше часов. Чтобы вести этот бюджет, программистов просят логать время на таски. Они плюются, но по-другому никак.
Но если у нас контракт dedicated team, когда человек продан на фултайм, то бюджет можно считать раз в месяц. Это значительно проще и часы здесь уже не нужны.
Так же и в продукте.
2️⃣ Считать попадание команды в свои оценки.
Любой менеджер хочет иметь систему, где будет видно, кто из команды вписывается в обещания (оценки), а кто нет. И на сколько. Тогда легко разобрать любую фичу, любой релиз, любой косяк и сразу станет ясно, где корень. Вот тут я подробно описал, как такую систему построить на основе трекинга времени.
Но если пожертвовать точностью и цифрами, можно решить и эту задачу. Например, планируете X задач на неделю и в конце смотрите, все ли завершены. За 3 месяца такой работы вам и без цифр станет ясно, кто слоупочит.
3️⃣ Контролировать, что человек работает весь день.
В этом, конечно, вам не признается ни один менеджер, но многие боялись идти на удаленку, потому что "ну как же они работать будут, если я раз в час не буду мимо за кофе проходить?".
Чтобы иметь больше контроля, менеджеры придумали таймшиты. Сотруднику нужно списать 8 часов в конце дня на задачу, которой он занимался.
Но это, конечно, самообман. Менеджеры умеют придумать 100 причин, как обосновать x3 эстимейт для заказчика. Программисты придумают 200. И такие, что даже не придерешься.
--------------------------------------
В продукте я выбираю жить без часов. И выстраивать культуру работы, в которой человека оценивают за результат, а не за часы.
В аутсорсе, где возможно, я склоняю заказчика к DT контракту, чтоб выбросить часы.
А вы?