и еще про зарплату

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

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

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

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

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

💰Обсуждать можно не только зп, но и другие перки: дни отпуска, бонусы, всякого рода компенсации, кресло 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!

Орлопан 

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

1. Как стать менеджером в ИТ - для тех, кто делает свои первые шаги в профессии ПМ.

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

3. Белая книжная полка для менеджеров - сборник практических статей по основным вехам в управлении проектами.

Друзья, никакой коммерции, рекомендую только то, что читаю сам.

Эпик фейл

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

Эта история научила меня проверять получателей письма, прежде чем нажать кнопку отправить. Если письмо очень важное, лучше сначала написать ответ (и перечитать!), а получателей добавить прямо перед отправкой.

Фейлы бывают у всех и это ОК. Говорят даже, что фейл ценнее успеха, если сделать выводы. Давайте попробуем поучиться на чужих ошибках. Скиньте в дм самые эпичные фейлы, составлю анонимную подборку.

​Друзья, получил ваши весточки, огромное спасибо всем откликнувшимся. Текста много, скомпилировал все в телеграф для вашего комфорта.

​Чек-лист оценки проекта, часть 1

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

- WBS;

- краткое описание задач. Например, логин\регистрация - имейл, Facebook, телефон (без СМС подтверждения);

- PM+BA / DEV / QA пропорция в оценке примерно попадает в 15%/55%/30%;

- стек технологий;

- рейты согласованны с сейлом;

- все необходимые виды тестирования (авто, юнит, перфоманс, секьюрити), перечислены поддерживаемые устройства \ ОС \ браузеры;

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

- риски и асампшены;

- состав команды (специальности и количество);

- длительность проекта, желательно с визуализацией (гант чарт или разбивка по фазам);

- ссылка на доки, на основе которых сделана оценка;

Крисмас

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

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

Всем удачных праздников!

Размер команды

Джеф Безос, основатель Амазон, считает что оптимальный размер команды - 6-7 человек. Назвал он это правило "2-pizza team", потому что именно столько нужно человек, чтобы съесть 2 большие пиццы 🍕. 

В скраме похожая ситуация. Предлагают команду в 3-9 человек без учета СМ и ПО. Больше 9 - падает эффективность в коммуникациях и управлении. Меньше 3 - сложно разработать достаточный объем ценности за спринт.

Если на проекте 10+ человек, можно выделить несколько под-команд. Сразу возникает вопрос по какому признаку их организовать? Я видел два хорошо работающих варианта:

1. По фичам, если проект можно разбить на крупные модули (продукты, эпики). Тогда будет команда модуля 1 и команда модуля 2. Для своего проекта выбрал этот вариант.

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

Как продать рефакторинг 

Не все заказчики технические и понимают зачем нужен рефакторинг. Им ясна логика "фича х принесет y денег", а ценность рефакторинга туманна. Мы-то с вами знаем, что она есть, ее нужно просто сформулировать:  

- Быстродействие. Картинки на сайте будут грузиться быстрее, это увеличит конверсию.

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

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

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

- Дешевле добавлять новые фичи. Сейчас внедрение нового метода оплаты занимает x часов, а будет x/2. 

Разговаривайте с бизнесом на его языке.

Скелет ретроспективы

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

Важно:

1. Ревью договоренностей предыдущей ретры. Если они не выполняются, проку от таких митингов мало.

2. Классический подход что было хорошо / что было плохо / что стоит попробовать. 

3. Ревью результатов прошедшего спринта (сделали ли то, на что закомитились).

4. Фидбек от заказчика, если есть.


Опционально:

1. Icebreaker.

2. Выяснить настроение команды. Короткий вопрос "как для тебя прошел спринт?" с вариантами ответа зеленый (= все хорошо), желтый и красный (= все плохо). Помогает найти потенциальные проблемы, с красными стоит провести личную встречу. 

3. Рассказать о новостях компании, проекта, долгосрочных планах.