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

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 контракту, чтоб выбросить часы.

А вы? Адкрыць / каментаваць

2022-10-27 18:00:02 ​Как ищут баги

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

Пока вы ищете программиста, готового подключиться для фикса, тестер будет искать баг:

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

Попросит у саппорта уточнить у пользователей по каким шагам воспроизводится баг. Видят ли они какую-нибудь ошибку?

Посмотрит в Mixpanel (аналитика) есть ли зависимость по девайсам, браузерам, ОС, гео.

Посмотрит в Sentry (мониторинг) есть ли новые ошибки. Да, ошибки есть, но хрен пойми что значат, нужен программист.

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

Попробует воспроизвести с разными форматами файлов. Приложение отработает с .mov, но упадет с .mp4. Кажется, дело в этом.

Попробует локализовать. Достанет предыдущую андроид сборку и пройдет те же шаги. Теперь не крашится! Скорее всего, проблема в последней сборке.

Тут уже и разработчик нашелся. Он доволен: шаги есть, логи и возможная причина бага тоже. Благодаря этому фикс будет быстрым. Адкрыць / каментаваць

2022-10-25 17:00:03 ​#реклама

PMP сертификация - канал о сертификации Project Management Professional PMP PMI.

Актуальная информация об экзамене PMP, о тонкостях и лайфхаках, об интересных находках (например, недавно опубликован промокод на скидку 20% от стоимости экзамена).
Реальные кейсы от сдавших экзамен.

Об экзамене PMP:
+ 3 причины получить сертификат PMP
+ Как получить сертификат Project Management Professional
+ Требования к кандидатам в PMP
+ Как подготовиться к экзамену
+ На каком языке сдавать экзамен

О том где и как сдавать в текущих условиях:
+ Можно ли сдавать экзамен PMP с Российским паспортом из России
+ С каким паспортом нельзя сдавать экзамен
+ Сдача экзамена в тестовом центре: плюсы и минусы
+ Сдача экзамена онлайн из дома или офиса в другой стране: плюсы и минусы
+ Сдача экзамена онлайн из России: плюсы и минусы

1-2 раза в неделю на канале публикуются вопросы, максимально близкие к реальному экзамену. Адкрыць / каментаваць

2022-10-19 17:00:04 ​Календарный этикет

Несколько советов, которые сделают из вас английского лорда (или леди) в сфере гугл календаря.

Если пришел непонятный мит, куда вы не хотите идти, напишите организатору "Объясни зачем я там нужен".

Если отменяете или переносите встречу - напишите причину, чтобы люди понимали, что произошло. "Дима болеет, поэтому переносим на след неделю".

Если отклоняете инвайт, напишите письмом (кнопка "email guests") почему не придете, чтобы организатор понимал, почему вы отклонили и что с этим делать. Если неудобное время - используйте propose new time.

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

Не ставьте митинг на сегодня без предупреждения, это "ломает" день. Если очень надо - спросите в лс удобно ли.

Если у вас в середине дня личные дела, то сделайте ивент с названием busy. Так никто не возмутится тем, что в 3 у вас бассейн, и не поставит синк на это время.

Поставьте working hours в своем календаре и расскажите коллегам об этой фиче. Может кому-то миты в 8 утра тоже ОК, а вы боялись так рано ставить.

Не ставьте встречи больше часа.

Агенда. Добавьте 3-5 вопросов, которые будете обсуждать, чтобы человек понимал, о чем пойдет речь.

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

Пишите в комментах, какие у вас календарные обычаи. Адкрыць / каментаваць

2022-10-12 17:00:04 ​Моментальная ретроспектива

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

Задача заняла 3 дня вместо 2? Пользователи отрыли какой-то специфичный баг? Упустили кусок стори?

ОК, бывает, но как нам не облажаться в будущем?

Мы не ждём ретроспективы, и разбираем проблемы сразу. Часто, в тот же день. Детали забудутся, накопится ещё пять новых проблем, и мы просто не успеем разобрать каждую хорошо.

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

Я радуюсь этому моменту, потому что он означает, что ребята хорошо справятся уже и без меня . Адкрыць / каментаваць

2022-10-06 17:00:04 Что будете делать с рентабельностью?

Давайте прикинем общую рентабельность.

На проекте 12 человек. Если на тимлиде зарабатывали 1,000, то на остальных, в худшем случае, 1,500. Суммарно получается $17,500 в месяц, а после рейза станет на 6% меньше.

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

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

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

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

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

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

Как и в карьере, пересмотры хорошо привязывать к успехам проекта. Сделали хороший релиз, затащили новую интеграцию - можно и про рейты поговорить. Адкрыць / каментаваць

2022-10-06 17:00:03 Что будете делать c рейзом?

Выбрав вариант Предложу дождаться следующего ревью, тимлид с большой вероятностью уйдет.

Сейчас он получает ниже рынка и его запрос вполне справедлив. Он даже не просит максимум из того, что ему предлагают. Да, есть процесс пересмотра раз в год, но зачем ему столько ждать? Свою работу он делает хорошо (почти). Какое ему дело до процессов и бюрократии, когда он в одном шаге от хорошей прибавки? И тем более до рентабельности? Эти вопросы - не его забота.

Но готовы ли мы его потерять?

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

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

Вариант Предложу исправить косяки, тогда и поговорим немного лучше. За выслугу лет в ИТ не доплачивают. Зп растет, когда сотрудник повышает свои навыки, которые компания может "перепродать". Раз у тимлида есть косяки, резонно предложить ему их исправить, а после сделать рейз. Но вы все еще платите ниже рынка (это стоит проверить), поэтому большой шанс, что тимлид не согласится на этот вариант и уйдет. Ведь где-то его ждут соблазнительные +$1,500.

Я выбираю вариант 500+500. Вы показываете, что компания идет на диалог, и признает, что платите ниже рынка. И делает моментальную компенсацию, сразу исправляя свои ошибки. Отличный ход! Вы также признаете ценность тимлида, ведь основные вопросы он решает хорошо. При этом, обозначив косяки, вы показываете, что ему есть над чем работать. Пофиксил - держи свои +500, и ровно ту зп, которую и просил. Следующий пересмотр можно назначить через 4 месяца, чтобы формально соблюсти процесс годового ревью.

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

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

Вариант Повышу на 1,5К, чтобы перебить конкурентов сработает, если вы работаете в условном Нетфликсе. У них действительно есть такая политика моментально матчить зп, даже если сотрудник этого не просил. Но в обычной аутсорсинговой фирме, где борются за каждую копейку, это выстрел себе в ногу (точнее, в кошелек). Адкрыць / каментаваць