Лучший ПМ это Иисус. Посудите сами:

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

Он завещал немного советов и best practice по управлению IT проектами, которые я публикую здесь.

Dev complete

Приходит к вам разработчик и говорит ”фича готова”. Ежели за грехом был ранее замечен, можно спросить “а покажи”. Сразу возникает вопрос – а что показывать? В этот момент будет здорово, если под рукой окажется вот такой чеклист:
- Код написан;
- Создан фича бранч;
- Разработчик сам потыкал фичу, “вроде работает”;
- У тестировщика нет препятствий, чтобы начать тестирование;

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

Когда стартуете новый проект, определите внутри команды что значит “фича готова” (разработка завершена / dev complete), да положите на вики. Добавив к нему понятие “тестирование завершено”, вы получите то, что в скраме называют Definition of Done. Придерживаясь такого списка критериев, команда дает более точные оценки, потому что лучше понимает объем работы.

Аминь!

​​Workload Pie chart


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

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

2. Трекинга прогресса спринта. Принцип тот же что и в предыдущем пункте, смотрите количество часов в незакрытых тасках против остатка спринта. Эдакий аналог Burndown Chart.

3. Оперативного планирования. Если на Иакове заасайнено задач на 24 часа, а на Фоме всего 6, вероятно, какие-то таски можно перераспределить.

Как и Иисус, виджет многого не требует. До начала спринта нужно создать все задачи, да обновлять remaining estimate по каждой. Договоритесь с командой иметь актуальный ворклог к стендапу. В таком случае поле remaining будет обновляться автоматически, когда сотрудник логает время.

Настройка:
Filter: project = ID или имя вашего проекта AND status != closed AND Sprint in openSprints(). Сохраняете этот фильтр, в поле виджета вставляете его имя.
Statistic Type: Assignee
Time field to report on: Current Estimate

​За беклогом нужен глаз да глаз

Паузы в диалоге

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

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

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

Вариант 1: "Ты пропустил баг - это косяк, больше так не делай и заведи, наконец, чеклист".💩

Вариант 2: "Заказчик написал по поводу вчерашнего бага" пауза "расстроился, рассказал какие проблемы у них это вызвало" пауза "как думаешь, что можем сделать, чтобы в будущем не повторить?" пауза "это хорошо, а вот еще чеклист, дал бы положительный эффект?" 🔥

​"5 пороков команды"

Все всегда думали что смертных грехов 7, но Патрик Ленсиони запомнил только 5. Не спешите расстраиваться, книга заходит как кулич на Пасху. Если в вашей команде есть проблемы, то сможете найти здесь несколько толковых советов. Для поклонников принципа Парето и тех, кого в дрожь бросает от слова "бизнес-роман", последние 20% книги дают структурированную выжимку всех идей. Задумка крутая: для каждого порока описаны симптомы, последствия, методы лечения и даже связи другими пороками.
Автор выделяет следующие типичные проблемы команд, называя их пороками:

- недоверие;

- боязнь конфликта;

- безответственность;

- нетребовательность;

- безразличие к результату;

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

Продакшн логи

“Откупоривайте шампанское - мы вышли в прод!” Все с нетерпением ждут релиза, но самое сложное впереди. Вскоре обнаружатся дотошные грешники, которые отыщут все 500-ки вашего бекенда.

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

Сервисами логирования можно отследить:
- данные пользователя (ОС, устройство, браузер, страну и т.д.);
- последовательность запросов и ответов, которые приводят к багу;

Выбор тулы лучше отдать на откуп разработчикам. Мы используем Appsignal для Ruby и Sentry для React JS и вполне довольны. Подключить благодетель займет от пары часов, до нескольких дней, в зависимости от сложности и величины проекта.

​Фидбек на ретроспективу

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

Чем лучше вы понимаете что приводит к катарсису, а что нет, тем круче будут ваши следующие миты.

​Всем хороших выходных 😉

Как уместить дизайн в спринт

Многие спрашивают, как по скраму рисовать дизайн. Челлендж в том, что разработчик не может оценить фичу, пока не увидит лэйаут. Ответ простой - рисуйте дизайн на спринт вперед. Например, сейчас у вас 8 спринт, в процессе команда готовит стори для спринта 9. Одновременно с этим, дизайнер отрисовывает интерфейсы для спринта 10. В таком варианте, в 9ом у вас уже есть утвержденный дизайн. Варьируйте гэп "дизайн-разработка" в зависимости от скорости аппрува диза заказчиком и будет вам Вальгалла.

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

- совместить аналитику и дизайн в один спринт, как совмещаете тестирование и разработку;

- сократить длительность спринтов;

- релизиться чаще;

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

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

- создайте и поддерживайте актуальным дизайн гайдлайн.

Skype не очень

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

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

Cisco WebEx хорош в плане звонков, но он менее интуитивный и платный. В Slack хороший звук, но групповые коллы платные.

Всем хорошей связи.

​Хорошо хоть пятидневка.

Источник

​PERT

Program Evaluation and Review Technique это целая методология планирования, хоть и довольно лаконичная. Самый интересный ее элемент - метод оценки по трем точкам - чаще всего имеют в виду, когда говорят PERT.

Чтобы сделать эстимейт по перту нужно дать 3 оценки:

- оптимистичную (O)

- пессимистичную (P)

- наиболее вероятную (M).

PERT = (O+4*M+P)/6

Допустим, вы получили оценку O = 5 дней, P = 15, M = 7. Тогда ваш PERT = (5+4*7+15)/6 = 8 дней. Из формулы видно, что самой значимой является наиболее вероятная оценка. При этом учитываются как оптимистичная, так и пессимистичная оценки, но с меньшим весом.

Этот метод полезен для проектов с высокими рисками. Плюсы:

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

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

3. Используя PERT, можно удивить клиента точными цифрами, сказав "с вероятностью 68% мы сделаем эту фичу за столько-то дней". Причем это подтвердит даже ваша бывшая математичка, никаких чудес.

Вот тут чуть больше математики, но простым английским языком.

Мотивация на долгосрочном проекте

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

- Генерация идей по улучшению продукта;

- Фидбек от менеджмента вашей компании;

- Новости с прода, репорты, планы от клиента (регулярный фидбек и без того маст хэв!);

- Смена задач, технологий, делегирование ответственности. Фронтендеры берут простые задачи бека, тестировщики описывают стори и т.п.;

- Командировка;

- Семинары внутри команды;

- Общение напрямую с заказчиком;


Друзья, пришлите мне в лс какие мотиваторы сработали у вас, самые интересные опубликую на канале.

Wiki

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

General
Team, roles, responsibilities  
   Retrospectives
   Risks
   Sprint reports
   Release notes
   Non-functional requirements
   UX personas
   DOD
   DOR
   JIRA flow
   Audits
Personal meetings

Dev
   Architecture & Technologies
   Environments
   Code guidelines
   Build versions
   Gitflow
   Deployment guide
   Builds (Jenkins)

QA
   Credentials
   Performance tests results
   Integration tests
   Test plan
   Reports

Договоренности надо фиксировать, иначе, считайте, их нет. Большая часть этого списка про договоренности. Например, есть страница Code guidelines - значит все пишут более-менее одинаковый код (необходимое, но не достаточное условие). Или Environment - команда знает какие серваки существуют и для чего используются. Конечно, договоренности надо проверять (и записывать на страницу Audits), но это уже другая история.