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

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

​Право отказаться

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

Отказаться - не значит проявить слабость.

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

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

✅в команде нет культуры юнит тестов -> убежу 1 программиста, проведем эксперимент на нескольких фичах, потом сделаю презу для всех с примерами и цифрами -> усилие

⛔команда отказалась писать тесты безо всяких аргументов -> есть другие показатели низкой инженерной культуры, а для меня это на первом месте в работе -> насилие

Менеджерский приём - смещение фокуса

Сравните:

Мы не можем записывать экран пользователя без его согласия, это невозможно.

или

API гугл хрома не позволяет записывать экран без согласия пользователя.

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

Смещайте фокус.

via copout.me

Не все баги надо фиксить

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

Баги, как и фичи, решают задачи пользователей. Они имеют ценность, которую надо оценить и приоритизировать.

Например, SMS нотификации - ценность 5, а поехавшая верстка в IE - 0.05. Пользователей IE всего 2%, их можно долго мариновать внизу беклога и ничего не случится.

Забейте на красивую статистику, поставляйте в продукт максимум ценности.

​Из проджекта в продакты. 3 истории перехода

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

Вот что получилось: https://bit.ly/2XDQhTR

Внутри:

1. Ценят ли компании опыт проджекта?
2. Что сделать сегодня на проекте, чтобы уже завтра стать продактом (максимум, послезавтра)?
3. Какие скиллы качать, а какие нет?

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

​Scrum аудит

Менеджеров хлебом не корми, дай что-нибудь измерить и оценить. Даже Scrum умудряются превратить в число.

Рассуждают так: если весной Scrum на условные 3, а летом уже на 5, значит дела идут в гору, а менеджер не зря ест свой хлеб.

Идея не лишена смысла, а воплотить ее поможет Scrum аудит.

Он оценивает процессы в команде, опираясь на фреймворк и его лучшие практики. Советую использовать его не как линейку, а как предлог для поиска улучшений (те самые inspection & adaption из гайда).

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

​Проджект менеджеры не нужны

Работа ПМа критична на старте проекта: построить отношения с клиентом, отладить процессы, помочь команде выйти на стабильную производительность. Тут ПМ незаменим. А что потом?

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

Через 8-12 месяцев можно освободить добрых полдня. За этот срок команда в состоянии научиться работать без менеджера.

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

Разумеется, такой подход работает, пока проект не переживает резких изменений - тот же заказчик, команда и продукт. Как только радостный клиент сообщает, что подписал Google и нужно нанять 5 фронтендеров, чтобы подпилить для него функционал - все начинается сначала.

​Post-mortem шаблон для инцидентов

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

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

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

После того, как пожары потушены, надо отдышаться и провести мини-ретроспективу инцидента (post-mortem). Бизнес будет чувствовать заботу и вовлеченность, если написать такое письмо:

Что случилось: Европейский сервер чекаута упал из-за переполнения памяти.
Ущерб: Часть пользователей не могла оплатить покупки. Приблизительно 200 заказов не завершились на протяжении 2 часов.
Решение: Подняли сервер вручную.
Выводы (что мы сделаем, чтобы проблема не повторилась): Перепишем автоподъем серверов с помощью инструментов Амазона (ссылка на задачу в джире).

Для работы с инцидентами есть специальные тулы, например Opsgenie от Atlassian. В нем 200+ интеграций, чтобы делать всю продакшн поддержку в одном месте: мониторинг, оповещения, графики дежурств и т.д. Можно даже настроить автоматический звонок на мобильный именно той команде, чей модуль упал.

Маст хэв для больших проектов в лайве.

Когда сделал все дела

На любом проекте всегда можно найти чем заняться.

Если поможете клиенту написать имейл рассылку, то выиграют оба: вы получите опыт написания рассылок и плюс в карму, а клиент сэкономит время.

Если ничего не приходит в голову, вот 5 дел, которые можно делать при любых обстоятельствах:

📌 посмотреть аналитику, где отваливаются пользователи, подумать почему;

📌 почистить беклог;

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

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

📌 подумать, как ускорить поставку новых фич (например, через cumulative flow diagram или control chart)

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

Что спрашивают на собеседованиях

Большую часть интервью занимают кейсы. Это практические вопросы, чтобы посмотреть как менеджер поведет себя в бою. Например, что делать, если клиент продавливает недостижимые сроки?

От компании к компании вопросы часто повторяются, вот эти - самые популярные:

https://telegra.ph/Voprosy-na-PM-sobesedovaniyah-06-30

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

Удачи на интервью!

​"Новые правила деловой переписки"

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

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

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

👉Как именно заботиться в переписке:

1️⃣ одно дело - одно сообщение, не надо обсуждать 3 проекта в 1 треде;
2️⃣ объяснять что внутри прикрепленных ссылок;
3️⃣ называть файлы так, чтобы их потом было легко найти на компьютере;
4️⃣ хвалить работу, достижения человека, а не его самого;
5️⃣ если накосячил, надо предлагать варианты решения проблемы, а не просто «прости, мне стыдно»

В тексте запросто теряются интонации и эмоции. Иногда даже смысл можно потерять по дороге. Поэтому главный совет выглядит вот так:

​Закрыть незавершенную задачу в спринте

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

Зависит от условий.

Посчитать сторю завершенной не будет проблемой, если:

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

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

​Cycle time

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

Чтобы узнать скорость выпуска фич, эджайлисты придумали такую метрику - cycle time. Это среднее время, которое занимает производство фичи.

Как снизить cycle time:

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

Измерить cycle time можно в джире с помощью отчетов control chart и cumulative flow diagram. В клауд и next-gen джирах их отчетов нету, там достать эту цифру можно только через запрос в базу.

​Похвала

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

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

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

На моей прошлой работе был один топ-менеджер. Столкнешься с ним бывало в лифте, а он скажет "о, Рома, круто вы сделали то-то и то-то, молодцы".

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

Короче, хвалите друг друга. А вот пара очевидных советов:

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

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

- Хвалите при свидетелях. Это х2 к силе действия 😉

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

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

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

- Люди объединяются и помогают друг другу в тяжелые времена. Компании дают дополнительный отпуск пострадавшим сотрудникам. В линкедине десятки постов про бесплатное переобучение и менторство для силовиков. Даже заказчики входят в положение и не сердятся из-за задержек в поставках.

Держитесь, друзья. Надеюсь, скоро все закончится.

​Asana

На моем новом месте работы используют Asana. Предыдущие 5 лет я провел в Jira, поэтому сначала это казалось трагедией. Спустя 2 месяца ежедневного использования, готов поделиться наблюдениями.

Минусы:
- Очень базовые отчеты. Красивые графики есть, но толковой аналитики на них не построишь.

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

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

- Слабый функционал поиска. В джире ты чувствуешь себя богом, способным заглянуть в самые темные закоулки беклога. С помощью JQL (встроенный язык поиска в джире, похож на SQL) можно найти любой тикет. Из трех раз, что я что-то искал в Asana, нашел только один.


Плюсы:
- Asana работает быстро, разница с Jira видна невооруженным взглядом. Интерфейс свежий и вылизанный. По ощущениям это как перейти с Windows XP на Mac с ретина дисплеем 🙃

- Задачи можно держать в нескольких проектах одновременно. Это мегаудобно, например, когда 2 команды делают одну фичу.

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

- Есть простой Гант чарт, в котором можно вести роудмап или делать визуализацию планов.

-------

Asana проигрывает Jira по функционалу, но на голову впереди в плане удобства использования. Она подойдет маленькому стартапу, но большой компании в ней будет неудобно.

​Как качать технические навыки, ч2

Недавно я пришел в новую компанию, которая делает мобильное SDK. Здесь большая часть разработки это нейросети, С++ модули и немного мобил. После 7 лет в вебе, я как будто попал в первый класс 😀

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

📌 Спрашивай программистов “как это работает?”. Не бойся выглядеть глупо и не думай, что крадешь время у коллеги. Многие ребята на самом деле любят рассказывать про свою работу, им кайфово поделиться знаниями. Здесь важен баланс: не приходи с банальными вопросами, которые можно найти на первой странице в гугле, пытайся сперва разобраться самостоятельно.

📌 Нарисуй дизайн (архитектуру) продукта, над которым сейчас работаешь. Узнай для чего нужен каждый компонент, с точки зрения бизнеса. Что будет, если его убрать? Почему выбрали именно MondgDB, а не Redis?

📌 Потренируйся на вопросах дизайн-интервью. Это задачки, в которых нужно построить схематичную архитектуру приложения, например, Youtube или Skype.

📌 Читай Хабр, Медиум, Dou, в общем, любой технический ресурс, который нравится. Мне очень заходит подкаст Запуск завтра, в котором объясняют сложные инженерные штуки простым языком. Это формат интервью с гостями из легендарных компаний, вроде Сбера, Авиасейлз или Спотифая.

​Инфраструктурные баги

В тестировании есть хорошее правило - проверять баги на окружении, максимально приближенном к реальному.

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

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

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