Как разговаривать с мудаками

Сегодня порекомендую книгу "Как разговаривать с мудаками" Марка Гоулстона. Автор рассказывает о том, как вести себя с иррациональными людьми, разбирая примеры из практики. Многие из них отлично ложатся на управленческие сценарии.

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

Немного теории. В 60-х нейробиологи описали трехслойную модель мозга:

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

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

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

Зачем ходить на конференции

...митапы, семинары, воркшопы и т.д.:

Знания - если опыта не очень много, то есть шанс услышать что-то новое для себя. Однако, после 2-3 конференций начинает казаться, что где-то я это уже слышал :)

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

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

​Декомпозиция задач

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

Любую фичу можно разбить, абсолютно любую. Если говорят, что нельзя - лукавят. Цель менеджера - помочь команде раздробить фичу на мелкие задачи. Для этого существуют сессии планирования. Их ценность в том, что проговаривая фичу, зачастую обнаруживаются неочевидные нюансы, влияющие на длительность. Мысля категориями "неделя" при быстрой оценке, найти их гораздо сложнее.

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

Оптимальная длительность задачи при разбиении - 6-12 часов. Меньше - микроменеджмент и дорого обслуживать (создавать тикеты, обновлять статусы). Больше - риск недооценки.

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

Пример декомпозиции:

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

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

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

​Jira для планирования

Недавно я выступал на митапе Agile team tools. Рассказывал как использовать джиру для операционного и стратегического планирования:

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

Это был мой первый опыт в качестве спикера и я волновался, как перед Страшным судом. Получилось вот так:

https://www.youtube.com/watch?v=qVze2m-FLOM&feature=youtu.be&t=45

Тут слайды.

​Что писать в контракте

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

По ссылке - важные пункты, которые можно вписать в fix price договор.

выгорание в 3 картинках

О работе менеджером

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

Освоить хард скилы, действительно, не очень сложно. В интернете куча приличной инфы о том, как настроить борды в джире, чем Redis отличается от MongoDB и как пользоваться диаграммой Ганта. Набив руку на паре проектов можно безгрешно вести новые. Если в компании зрелые процессы, это также сильно ускоряет рост. Разумеется, эти знания можно и нужно прокачивать вглубь, но ватерлиния, выше которой можно комфортно вести проекты, располагается невысоко.

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

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

Я верю в универсальность менеджеров. То есть, хороший менеджер в ИТ может относительно легко стать хорошим менеджеров в строительстве. Да, надо шарить в бетоне, ГОСТах и так далее, но эту проблему можно решить подбором компетентной команды. Управленческие принцип работают везде одинаково. В конечном итоге, менеджер всегда отвечает за срок, бюджет и качество в той или иной форме.

​Картоха

Вот так выглядел бы наш мир, если вместо ИТ продуктов, мы бы с вами выращивали картошечку. Я из Беларуси, не смог пройти мимо такой блестящей аналогии.

​Вики лайфхаки

Проектную документацию надо где-то хранить. Если пользуетесь Jira, то наилучший инструмент для этого - Confluence. Поскольку это продукты одной компании Atlassian, интеграция между ними, как у пасхи с куличом.

Вот тут писал про структуру и страницы, которые полезно иметь, а сегодня скомпилировал наикрутейшие фичи для работы с контентом:
https://telegra.ph/Confluence-tools-06-02

​Исследование Agile

Почитайте ежегодное исследование State of Agile за 2019: https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report

Интересные факты:

- 77% опрошенных - Европа + Америка
- 72% исповедуют Scrum или гибрид, 30% - SAFe
- 46% используют аутсорс команды, 78% имеют распределенные команды
- 41% выбирает Agile из экономии.

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

Топовые техники - стендап, спринт планинг, ретроспектива, спринт ревью - ровненько то, что описано в скарм гайде.

Инструменты, используемые для управления проектом:

Как планировать баги

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

1. Как планировать баги в беклоге?
Речь идет о всех существующих на данный момент дефектах в проекте. Здесь все тривиально - схема та же, что и с фичами. Приоритезируем все баги в беклоге, берем в спринт важные, предварительно оценив. Определяем с заказчиком комфортную пропорцию "баги-фичи", чтобы бизнес понимал на какую производительность он может расчитывать (их больше фичи интересуют).

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

2. Как планировать фича баги в спринте?
Если в ваш DoD входит фикс всех дефектов (обратное грешно!), нужно прикинуть сколько это займет. Закладываем примерное время на стабилизацию каждой фичи на основе исторических данных. Например, фичу оценили в 3 дня, в среднем тратится 30% от разработки (как это посчитать), значит планируем +1 день на багфикс.

3. Как планировать баги, прилетающие в середине спринта (например, с продакшена)?
Оцениваем средний объем прилетающих багов за спринт, закладываем на них буфер. При этом:
- в спринт добавляем только блокеры и критикалы, остальные - в беклог.
- если в спринт не влазит, проводим трейд-офф, как с фичами
- пересматриваем буфер по ситуации - запланированные релизы, большая нагрузка и т.д.

Что бесит ПМов

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

https://telegra.ph/CHto-besit-PMov-06-19


Почему я вообще про это пишу:

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

2. Чем больше разработчиков, заказчиков, боссов понимают, что болит у ПМ, тем больше шансов, что об этом вспомнят в следующий раз.

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

Боженька велел открыть комментарии, хочет узнать, что еще всех раздражает.

Оценки в часах и стори поинтах

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

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

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

Работать с СП легче, чем с часами, тк порядок цифр меньше. Банально, арифметические операции с 30 СП проще, чем с 300 часами работы.

Часы нужны, чтобы:

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

Самый популярный вопрос об оценках:

Можно ли матчить оценку в часах, на оценку в СП. Например, фича на 12 часов - 1 СП, 36 часов - 3 СП и т.п.

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

Проводник культуры

В нашем менталитете должность менеджера ассоциируется с начальством. Это отражается даже в языке - ПМ вакансии часто называются "руководитель проекта".

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

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

"Один их худших корпоратов, активации детские, бухло через час кончилось, ну десерт норм. И кто вообще слушает Bon Iver? играть не умеют, тексты унылые"

или

"За десерт душу готов продать, а вот активации слабоваты. Не фанат Bon Iver, но любителям, наверное, зашло. Проблема с количеством алко налицо, организаторы, наверное, уже сейчас начинают закупать на след корпорат, чтоб всем хватило 🙂 Но, вообще, они молодцы, такой ивент организовать - это куча работы"

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

​DoR, DoD

- Фича готова!
- Красавчик, пойду обрадую клиента.

спустя один звонок с обрадованным клиентом

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

Обманутые ожидания заставляют грустить. Чтобы было веселее, Скрам подарил нам 2 божественных артефакта - Definition of Ready и Definition of Done. Это набор критериев, по которым можно определить, что фича готова к разработке (DoR) и фича завершена (DoD).

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

Для каждого проекта DoD и DoR будут разными, они зависят от процессов, требований и конечного продукта. Вот типичный пример: https://telegra.ph/DoD-DoR-07-21

В гайде очень классно описана задача скрам-мастера в этой связи:
Scrum Master can detect incomplete transparency by detecting differences between expected and real results.

Потеря времени

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

Рома привет
------следующее сообщение-----
В понедельник к нам выходит новый...

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

Потери времени можно обнаружить повсюду: затянутые встречи, письма, ТЗ. Учите вашу команду работать быстро, например, описывать задачи коротко. Если из 4х строк можно сделать 2 - сокращайте. Это не только экономит время, но и дает больше шансов разглядеть главное - смысл.