​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 - сокращайте. Это не только экономит время, но и дает больше шансов разглядеть главное - смысл.

​Как искать косяки в проекте

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

Посмотрите на пример, тут большую часть времени занимает разработка (синяя область) - это окей. В багфиксинге (коричневый, почему-то) задачи почти не задерживаются - отлично. А вот в Ready for test проводят много времени, примерно 20%. То есть 20% времени задачи просто ждут очереди, над ними не идет работа. Значит, по тестированию поступает больше задач, чем команда может делать, это узкое место системы.

Оговорка: на графике ось y - количество задач, а не время, но смысл и выводы от этого не меняются.

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

Нужны еще косяки? Посмотрите вопросы в ПМ аудите.

45 татуировок менеджера

Книжка Максима Батырева отлично заходит за счет сторителлинга. Каждую менеджерскую мудрость он называет татуировкой и рассказывает короткую историю о том, как она у него появилась. Такой твиттер-тред менеджера получился.

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

8 сверкающих золотом куполов из 10.

Ожидание vs реальность

Раньше я думал "вот щас сдадим майлстоун 3 с жестким дедлайном, и будем спокойно работать". Потом думал "вот щас автотестами все покроем и будем спокойно работать". Затем "вот щас аналитика наймем и ....". Ну и так далее.

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

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

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

​Почему увольняются

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

📌Скучные задачи | нет роста
Спросите чем хочется заниматься, дайте новые обязанности. Это самый частый и простой, с точки зрения решения, вариант. Еще не встречал проекта, где нельзя было что-то поменять. У нас, например, один тестер стал автоматизатором, а другой автоматизатор - разработчиком.

📌Не сработался с командой
Токсичных и бездельников не стесняйтесь увольнять сами. Если в команде их нет, значит человек не поладил с 1-2 другими людьми. Разведите их по разным углам, чтобы работа пересекалась по минимуму.

📌Позвали в более крутую компанию
Здесь мало что можно сделать, особенно если предложили релокейт.

📌Мало денег
Дайте денег. В такой ультимативной форме зп можно поднять только раз, иначе начнутся финансовые крестовые походы.

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

​Лайфхаки рабочего места

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

1. Распечатанный календарь. Хорошо отмечать спринты, чтобы было видно сколько дней осталось до конца. Всякие важные даты, типо релизов туда же.

2. Маркерная поверхность. Сюда классно записывать отпуски членов команды и долгосрочные задачи. Когда перед носом маячит "напиши статью", шансы сделать это повышаются где-то на 7,43%

3. Телефон с календарем. Это моя нереализованная мечта, поэтому на фото макет. Крепим какой-нибудь дешевенький самсунг к стене (навечно), подключаем в розетку, открываем календарь. Сохраняем секунды и внимание на alt+tab, должно сработать, когда в день по 5-7 встреч.

Что надо сделать до отпуска

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

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

2. команде достаточно работы на время вашего отсутствия

3. отправить Out Of the Office имейл, с указанием замен

4. настроить автореплай

Выходное интервью

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

1️⃣ что нравилось на проекте?
2️⃣ что не нравилось?
3️⃣ что бы ты глобально изменил на месте заказчика? на моем месте?
4️⃣ чего не хватает команде?
5️⃣ чего не хватает компании?
6️⃣ чего не хватает твоему лиду?

Результат был поразительный, я узнал кучу полезной инфы, инсайтов, в том числе и о себе! На персональных встречах градус откровенности не тот, люди боятся рубить правду, боятся последствий. А уходя уже нечего терять и народ охотнее рассказывает о реальной картине вещей.

Увольнение - это болезненно и печально, но даже из него можно извлечь пользу.

Откуда берутся ПМы

Хотел написать, что боженька не придумал такого "Института управления проектами", который надо закончить, чтоб стать ПМ. А оказывается, придумал, он так и называется - PMI. Но учиться там необязательно.

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

📌 aналитики

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

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

📌 программисты

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

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

📌 тестировщики

Из тестеров получаются одни из лучших ПМов, что я встречал. Думаю, так происходит по двум причинам:

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

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

📌 маркетинг\сейл

Частый сценарий: окончил языковой университет -> попал в маркетинг\сейл благодаря крутому английскому -> перешел в продакшн.

Отлично чувствуют клиента, умеют убеждать, договариваться и заворачивать результаты работы в красивую обертку. Таких навыков иногда не хватает технарям, и наоборот - ребятам и девчатам из БДСМ (Business Development, Sales & Marketing) порой не достает технической экспертизы. Ее и нужно качать на старте.

И еще они очень веселые ребята, обожаю.

📌 P.S.

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

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

Скрам сертификация (PSM, CSM)

Если хотите сдать на скрам сертификат, имеет смысл смотреть на эти два:

1. Professional Scrum Master от Scrum.org

2. Certified Scrum Master от Scrum Alliance

Это две конкурирующие конторы, причем обе создал автор скрама - Кен Швабер. Кстати, до сих пор он служит в Scrum.org

Чтобы сдать на CSM нужно:

📌 Пройти курсы у сертифицированного тренера. Часто проводятся в крупных городах, рассказывают основы, стоят 700-1000$.
📌 Пройти тест, ответив правильно на 74% вопросов. По сравнению с PSM, вопросы гораздо проще.

Scrum Alliance напоминает некоторые конфессии и просит за членство 50$ в год. Если не платишь, то как бы и нету у тебя никакого сертификата. Есть пути без доната, но мне неизвестно, насколько они легковыполнимые.

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

В scrum.org не нужно ни курсов, ни членских взносов, можно сразу сдавать онлайн тест. В нем 80 вопросов, зачет от 85%. На экзамен дается 60 минут, то есть в среднем 45 секунд (!) на вопрос. Тест на английском, формулировки массивные, а кое-где нарочно построены так, чтобы сбить с толку. Немного напоминает экзамен в ГАИ, где тебя хотят надурить хитрым вопросом, вместо того, чтобы проверить знания.

Каждая попытка сдачи стоит 150$, т.е., если набрать меньше 85%, то придется платить еще раз. В случае успеха вы получаете сертификат на почту + публичную ссылку на него на scrum.org.

Как готовиться:

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

- Бесплатный тест от scrum.org. Значительно проще настоящего теста, но из него может попасться 10% вопросов. Потренируйтесь проходить на 100% каждый раз. Здесь еще тесты, очень близкие в реальным.

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

- Изредка в тесте попадаются вопросы из Professional Product Owner, Scaled Professional Scrum или Professional Scrum Developer. Для всех этих сертификаций тоже есть бесплатные тесты на сайте, потренируйтесь на них. Глубоко копать не надо, если такие вопросы будут, они обычно простые.

- Обязательно купите книжку Scrum Narrative. В ней 70-80% вопросов из теста!

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

Сертификат будет небольшим плюсом в резюме и хорошо упорядочит знания о Скраме. Конечно, его наличие или отсутствие ничего не говорит о том, умеет ли человек эти знания применять 😀

Я сдавал PSM 2 года назад, возможно, с тех пор что-то изменилось. Напишите в лс свои впечатления\опыт\мысли, буду рад обсудить!

Подборка каналов о PM, часть 2

С момента выхода первой подборки прошло аж 1,5 года и почти все каналы по сих пор актуальны! Хочу сказать большущее спасибо авторам, знаю по себе, как сложно не забить на длинной дистанции 🙂

Ниже перечислены те каналы, которые я читаю сам. Рекламирую их бесплатно, потому что они классные.

@pmdaily - точно и лаконично о проблемах на стыке инженерии и управления. Рубрика "вопрос читателя" - 👍

@product_love - много "менеджерских штучек", придуманных самим автором (или про них мало где пишут)

@necodernotes - про IT в Беларуси, автор много общается со топами минской айтишки, показывая точку зрения бизнеса

@xpinjection_channel - иногда про процессы, часто про технику, особенно джавистам понравится

@productionpain - классные посты про софт скиллы, иногда смешные картинки


Крутые проджекты втихаря молятся еще и продуктовым богам. А про продукты хорошо пишут тут:

@analysis_paradisis - рубрика "продуктовые задачки" с ответами и пояснениями - 👍

@bossofyourboss - кейсы продукта в реальном времени, интересно, как будто сериал смотришь

@betternotworse - примерно то же, но больше теории и процессов

@program_man - yet another product channel, пост про стоимость отказа зацепил

Присылайте в лс что читаете сами, накраудсорсим третью часть!

​Классный босс

Самое важное на работе - иметь классного босса. Это человек, благодаря которому становишься умнее, сильнее и дороже.

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

Есть простой способ оценить класность своего босса. Если завтра он уйдет в другое место и позовет с собой, стоит перейти за ним или нет? Если стоит - причисляем к лику святых.

3 года на одном проекте

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

Наверняка он был бы еще лучше, если бы не ошибки, которые допустил. Чтобы подытожить этот период, я составил список уроков, которые усвоил за это время:

❗Управление проектами в аутсорсинге - это не только инжиниринг, но и политика. Чем больше компания, на которую вы работаете -> тем больше стейкхолдеров -> тем больше политики.

❗Вопросы легче решать с друзьями, чем просто с коллегами. Еще проще решать их офлайн, поэтому командировки - класс.

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

❗Две главные вещи в проекте - команда и продажи (выстраивание ожиданий). Крутых спецов сложно найти, но они сэкономят кучу времени и денег. Чем точнее ожидания клиента совпадут с реальностью поставки, тем круче ПМ.

❗Не на все можно повлиять и не всегда можно что-то сделать. Некоторые события нужно воспринимать как данность или ограничение.

❗К проекту нужно относиться как к своему продукту, быть его мини-боженькой. И команде это проповедовать, тогда результат будет максимальным.

❗Еще раз: команда - главное, на что нужно тратить силы и время!

Такая вот ретроспектива.