Менеджер от боженьки

2022-12-08 18:00:04 #реклама

Без чего невозможно эффективное управление рабочим процессом?

Без точной информации о состоянии потока работ. А именно без понимания:
• где в процессе узкие места;
• когда работа может быть завершена;
• какие именно задачи выбиваются из потока.

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

Может показаться, что это сложно, но на самом деле для глубинного анализа процессов необязательно досконально разбираться в статистике — нужно просто подобрать удобные вспомогательные инструменты.

WFlow Analytics — это аналитическая система, которая визуализирует поток работ при помощи графиков и диаграмм, сформированных на основе данных вашего таск-трекера — поддерживается интеграция с Jira и Trello. Удобная система фильтрации и клиентская поддержка помогут разобраться в тонкостях процессной аналитики и встать на путь непрерывных улучшений. Открыть/Комментировать

2022-12-06 18:00:03 ​Пообещать и сделать

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

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

Доверие, как баланс на карте - постоянно меняется.

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

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

Будьте осторожны с любыми обещаниями. Если сомневаетесь - обещайте меньше. Открыть/Комментировать

2022-11-29 17:00:03 ​Смещение фокуса

Представьте, что на прод вылез неприятный баг. Заказчик узнал, кто автор рокового пулл-реквеста и настаивает снять его с проекта.

Обычный менеджер говорит: "Да, мы накосячили. Но менять Валю это тяжело, больно, дорого. Да он - самый толковый разраб на проекте! Давай не будем, а?".

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

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

Другой менеджер говорит: "Да, мы накосячили. Сделаем вот это и это, чтобы в будущем подобных ошибок не было. Кстати, Валя тут, вообще ни при чем. Такую ошибку допустил бы любой программист из команды в наших условиях. Мы спешим к декабрьскому релизу и в последнее время расслабили код ревью, чтобы успеть. Закрутим обратно?".

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

----------------------

Еще о смещении фокуса на примере ограничений Chrome.

---------------------- Открыть/Комментировать

2022-11-24 17:00:03 Менеджер - щит от говна сверху

- Я страшно доволен тем, что ко мне, к руководителю, претензии есть, а к газете (команде) - нет. В этом и есть моя работа.

из последнего интервью Дудя Открыть/Комментировать

2022-11-22 19:00:03 ​Job security

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

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

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

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

Такая штука называется job security.

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

Опытный менеджер боится другого английского словосочетания - bus factor. Это когда важного человека вдруг сбивает автобус и с завтрашнего дня надо как-то жить без него. Открыть/Комментировать

2022-11-17 17:00:02 #реклама_по_любви

С легендарным Максимом Дорофеевым я познакомился в 2016 на конференции в Минске.

Помню как меня впечатлило, насколько понятно и захватывающе можно рассказывать о человеческих привычках. Я моментально узнавал себя в примерах прокрастинации и планах, выполненных лишь на 30%.

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

Возможно, вы читали книгу Максима "Джедайские техники" о том, как быть продуктивным (и воспитать ту самую обезьянку). Теперь сможете читать его еще и в ТГ.

Несколько топ постов:

Про думскроллинг
Про чаты и почту
Фрагмент третьей книги Открыть/Комментировать

2022-11-15 17:30:02 ​Функции тимлида - чеклист

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

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

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

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

Пипл менеджмет
- Фидбек для разработчиков, PDP
- Онбординг
- Настроение в команде

Инженерия
- Качество кода
- Архитектура
- Выбор инструментов и технологий
- Мониторинг, логи, технические метрики

Процессы
- Оценки и вылеты
- Процессы разработки и поставки
- Код ревью и порядок в гитхабе
- Распределение задач по разработчикам
- Капасити команды
- Проверка качества груминга
- Работа с инцидентами
- Владение техдолгом (беклог + приоритеты) Открыть/Комментировать

2022-11-11 14:00:02 ​Когда немного поработал продакт-менеджером:

"ого, 66 поездок за день!" Открыть/Комментировать

2022-11-10 17:00:03 ​Готовиться и собирать факты

Хороший софтскилл для любого ПМа - умение готовиться. К встрече с заказчиком, ретроспективе, перфоманс ревью. Всегда работает простой закон: чем лучше подготовишься, тем более предсказуемый получишь результат.

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

Прежде чем так писать, проверь факты:
1. не брал ли разработчик отгул или больничный?
2. на каких еще проектах он задействован? изменился ли там объем работы?
3. были ли зависимости? может, бекенд надо было ждать?

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

Бывает и другая ситуация, когда разработчик говорит "знаешь, меня на другом проекте завалили работой". Это звучит подозрительно, ведь другого ПМ на общем митинге сказал, что его проект завершен. Кажется, здесь нестыковка.

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

Наконец, таких менеджеров, чаще промоутят. На это счет есть древняя байка: https://habr.com/ru/post/22548/ Открыть/Комментировать

2022-11-03 19:00:03 ​Нужен ли трекинг времени

Нет, не нужен.

Давате расскажу почему.

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

Следить за прибыльностью проекта (profits & loss).

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

Чем больше часов выставим, тем больше будет прибыль компании. При этом потратить надо как можно меньше часов. Чтобы вести этот бюджет, программистов просят логать время на таски. Они плюются, но по-другому никак.

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

Так же и в продукте.

Считать попадание команды в свои оценки.

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

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

Контролировать, что человек работает весь день.

В этом, конечно, вам не признается ни один менеджер, но многие боялись идти на удаленку, потому что "ну как же они работать будут, если я раз в час не буду мимо за кофе проходить?".

Чтобы иметь больше контроля, менеджеры придумали таймшиты. Сотруднику нужно списать 8 часов в конце дня на задачу, которой он занимался.

Но это, конечно, самообман. Менеджеры умеют придумать 100 причин, как обосновать x3 эстимейт для заказчика. Программисты придумают 200. И такие, что даже не придерешься.

--------------------------------------

В продукте я выбираю жить без часов. И выстраивать культуру работы, в которой человека оценивают за результат, а не за часы.

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

А вы? Открыть/Комментировать