📌 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 человек. Получился классный продукт, которым я горжусь.

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

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

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

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

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

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

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

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

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

Фаза анализа (discovery)

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

📌 Архитектуру ПО - интерфейсы, интеграции, дизайн, вот это все тут;

📌 Спецификацию - бизнес-требования, вайрфреймы;

📌 Тест план - все виды тестов, которые будут выполняться по ходу проекта;

📌 Оценку - человеко-часы, состав команды, стоимость;

📌 Проектный план - длительность с разбивкой на фазы, обычно делают диаграммой Ганта;


Производство этих доков стоит $5,000-20,000. Для клиента это удобный подход, потому что:

1️⃣ потратив небольшой бюджет, он понимает профессионализм вендора, стоит ли ему доверять остальной проект;

2️⃣ с пачкой таких документов он может пойти к любому другому вендору и найти команду, которая сделает проект;

Не идиот

❗Важнейший навык менеджера №64:

Разговаривать так, чтобы собеседник не чувствовал себя идиотом (даже если он выглядит как идиот и говорит как идиот!)

​Конверсия от короновируса

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

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

А вы что чувствуете?

Почему работает Скрам

Потому что в нем есть:

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

📌 ценности, которые увеличивают шансы на победу в любой ситуации - будь смелым, коллаборативным, честным и т.д.;

📌 быстрая проверка гипотез, направляющая бизнес в прибыльное русло;

📌 вера в то, что все будет хорошо. К 2020 столько успешных кейсов, Фейсбук, Гугл, Амазон, все работают по скраму, горя не знают, значит и у меня получится;

Деплой по кнопке

Написать хороший код это еще полбеды. Вторая половина - доставить его на продакшн так, чтобы по дороге ничего не отвалилось.

Чем меньше шагов в процедуре деплоя, тем выше шанс ничего не сломать. В этом и есть суть автоматизации девопс.

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

Анонимный тест на проектную грешность. Максимум 400 баллов (угадайте, сколько у меня, правильно, 400 😆).

По мотивам теста на продуктовую испорченность.

Ребята, сорри, с опросом я налажал, можно выбрать только один вариант, но отредактировать его уже нельзя :(

Вот примерно так выглядит результат пункта 4 «релизил без тестирования»

Навигация

👯‍♂️Команда
Персональные митинги (one-on-one)
Выходное интервью
Как работают американские команды
Мотивация на длинном проекте
Размер команды
Почему увольняются
Похвала
Давать негативный фидбек
Баланс джунов, мидлов и сеньоров
Сколько времени уходит на 1 разработчика


💪Scrum
Сердце Скрама
Скрам сертификация
DoR, DoD
Scrum аудит
Интро к ретроспективе
Scrum guide 2020
Icebreaker для ретроспективы
Структура ретроспективы
Результаты ретры в беклог
Как выбрать длительность спринта


🎮 Кейсы
Небольшая доработка
Плохие новости
Выбор кандидата


😇Софт скилы
Не идиот
Проводник культуры
Выгорание
Орки
Удобные письма
Главный скилл менеджера
Импульсивные решения
Что бесит любого ПМа
Потеря времени
Косячат все
Дать облажаться
Смещение фокуса
Право отказаться


👨‍💻Практики, лайфхаки, менеджерские штучки
Как продать рефакторинг
Что писать в контракте
Чек-лист ведения проекта
Прогноз бюджета
Какие отчеты обязательно делать
Что надо сделать до отпуска
Meeting notes
Как готовиться к командировке
Паузы в диалоге
Подборка ПМ каналов
Как понять, что на проекте все ок
Спринт репорт
Как отвечать за то, в чем не разбираешься
Проектный треугольник 2.0
Закрыть неготовую задачу
Кик офф
Фидбек от клиента
Изменения = терпение
Выясни кто стейкхолдер

Принципы планирования

Бест, прости господи, практис:

1️⃣ Команда говорит "когда будет готово", а не клиент или менеджер.

2️⃣ Оценивать должны те люди, которые будут делать. Или переоценивать на старте, если оценили другие.

3️⃣ В описании стори должна быть цель, все остальное вариативно. Чем детальнее описание, тем точнее оценка.

4️⃣ В каждый спринт надо закладывать хотя бы 1 рефакторинг, чтобы не копить техдолг.

5️⃣ Надо брать запас и закладывать риски. Лучше пообещать меньше, а сделать больше, чем наоборот.

6️⃣ DoD поможет уточнить оценку, определив какие именно задачи надо сделать, чтобы закрыть сторю.

7️⃣ Лучше не грумить больше чем на ~3 спринта вперед. Из-за меняющихся приоритетов, это может оказаться бесполезным.

8️⃣ Декомпозируйте на подзадачи, занимающие ~6-12 часов.

Задача менеджера - следить за тем, чтобы все понимали, принимали и следовали подобным принципам.