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

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

Многие спрашивают, как по скраму рисовать дизайн. Челлендж в том, что разработчик не может оценить фичу, пока не увидит лэйаут. Ответ простой - рисуйте дизайн на спринт вперед. Например, сейчас у вас 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), но это уже другая история.

Главный скилл менеджера

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

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

1. Трудные диалоги: Что и как говорить, когда ставки высоки. (Гренни, Макмиллан)

2. Как пасти котов (Рейнвотер)

3. Статьи о конструктивном общении и алгоритме решения проблем (Орлов).

Подборка каналов о PM

В телеграмме не так много каналов об управлении проектами, вот самые классные:

@scrummasters - заметки про скрамчик, много практики;

@psilonsk - рассуждения о тонких, глубоких штуках в управлении;

@realtoktok и @teamleading - мощнейшие советы, хаки для PM\SM;

@lovely_it_hell - проблемы менеджмента глазами head of R&D;

@pmwithloveandsqualor - канал Даши похож на радио, там все сразу, вперемежку с личным, но некоторые посты цепляют;


Другое:

@docops - как вести документацию, но не служить Сатане. Рекомендую аналитикам.

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

Делайте проект так, как продакты делают свои продукты. Темы схожие, много полезной инфы нахожу на @ruspm и на легендарном @proproduct.

​Гаджет Sprint Health

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

Хотите за полсекунды понять пора ли вашему спринту вызывать священника – бросьте взгляд на Sprint health гаджет. Он показывает:

- сколько дней спринта прошло\осталось. Помогает, если вы отлично провели вчерашний вечер 🍸

- сколько Story Points в open\in progress\done. В связке с предыдущим пунктом можно прикинуть успеете ли сделать запланированное.

- изменение скоупа, на сколько отклонились от первоначального плана (добавили\убрали стори);

- blocked\flagged тикеты. Этим, вероятно, нужно пристальное внимание;


Короче, самое важное что надо знать про спринт есть тут. Усилий по апдейту не требует, всю инфу считает автоматом. Кстати, почти все цифры кликабельные – открываются джира фильтр при нажатии.

​Релизный чеклист

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

https://telegra.ph/Reliznyj-chek-list-09-03

Если вы пушите в мастер по 6 раз в день, список будет сильно короче.

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

​Пирамида усвоения информации

Ютуб круче Библии. Ученые доказали что смотреть видео эффективнее, чем читать, с точки зрения скорости получения знаний. Остальные методы обучения они тоже исследовали и визуализировали в виде пирамиды усвоения информации (Learning Pyramid).

Как это использовать:

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

2. Обсуждайте проблемы с коллегами внутри компании или в коммьюнити.

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

Интро к ретре

Norman Kerth, апостол ретроспектив, придумал такую мантру:

Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand. 

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

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

Клиент продавливает сроки

Когда заказчик ставит недостижимые сроки, есть пара приемов, которые помогут вам вписаться в них:

1. упростить фичу;

2. упростить разработку (говнокод, выбросить юнит-тесты и т.д.);

3. добавить людей или распараллелить работу;

4. урезать качество;

5. овертаймы;

Иногда этого недостаточно, при этом сроки все еще гневают всевышнего. На этот случай вот вам цитата из книги "Мифический человеко-месяц":

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

У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым — с другого.

Budget forecast

Обычно на проектах с почасовой оплатой (T&M) или выделенной командой (Dedicated team) в начале каждого месяца высылают инвойс на оплату. Блаженные менеджеры повышают прозрачность, высылая вместе с ним прогноз затрат на будущий месяц.

Такая инфа будет полезна клиенту при планировании бюджета. Уж точно не придет ему в голову спросить “а че так много?”, получив очередной инвойс.

Не ленитесь отправлять сумму, даже если у вас постоянно работает одна и та же команда. Цифра может отличаться на 10-20% за счет отпусков и количества рабочих дней в месяце.

Icebreaker

Хорошая ретроспектива это больно. Мало кто умеет безопасно доносить критику и тем более принимать ее. Поэтому прежде чем сыпать соль на рану, растопите лед ❄️

Icebreaker это упражнение-игра на 10-20 минут. Его делают перед началом ретроспективы, чтобы отвлечь сотрудников и вынуть из рабочего контекста. Люди любят играть и быстро переключаются на что-то интересное. Человек расслабляется и более спокойно переносит критику, которая будет в основной части ретроспективы.

Суть игры может не относиться к спринту, но должна приносить что-то полезное.

Пример 1. Каждый пишет пару личных вопроса любому коллеге, тот зачитывает их и отвечает. Так вы узнаете что Дима любит старые тачки, а Саша рыбак.

Польза: новая команда быстрее срабатывается.

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

Польза: важно детально описывать требования, договоренности.

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

Айсбрейкер может быть канвой все ретроспективы, например sailboat или emotional seismograph.

«Пиши, сокращай» 🔪

Прочитайте эту книгу, если работаете с текстом - письма, документация, требования и т.д. Для аналитиков - маст хэв. Авторы учат писать в информационном стиле:

- думать о цели текста;

- структуре;

- быть последовательным;

- избавляться от оценок и мусора;

Каждая идея подкреплена понятными примерами. Отдельная глава посвящена тексту в рекламе. Будет про резюме, молодую, динамично развивающуюся компанию профессионалов ("о нас"), рассказ о продукте. Маркетологи и продакты - вам сюда.

Есть в книге одна спорная мысль - "не сглаживайте углы". ПМам нельзя принимать ее на веру. Умейте признавать свои грехи, но старайтесь сохранить лицо.

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

Pocket

Едете в метро на любимую работу, скролите ленту а там обещают увеличить ваш velocity на 3 стори поинта за месяц😱. Предвкушаете мощный лонгрид, но на следующей выходить. Не хочется упускать полезный контент, а если не сохранить его до лучших времен, то анафема неизбежна. Скопировать урл статьи и сохранить в google keep долго и неудобно. Благо существует более элегантное решение - pocket.

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

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

Критерии успешности проекта

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

📌Основные:

- Сроки

- Бюджет

- Скоуп

- Качество

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


📌Дополнительные:

- Удовлетворенность команды

- Финансовые показатели (клиент вовремя платит, команда рентабельна)

- Процессы + технологии

- Апсейл

Команда не вкладывается в оценки

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

- детализировать требования. Чем четче сформулирована задача, тем точнее оценка;

- дробить фичи мельче. Оптимально 1-4 дня;

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

- делать прототипы\инвестигейты на сложные фичи;

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

- привлекать внешних спецов, если не хватает экспертизы;

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

- трекать успеваемость (оценка vs фактические затраты) по каждому члену команды. Доносить на 1-1 митингах;

- менять ребят, которые много и часто вылетают (>60% за 3-6 месяцев);

Вылет в 20-30% считается допустимой нормой, его стоит закладывать в начальную оценку. Берегите себя и свои эстимейты.

​Гаджет time sheet

Используйте этот гаджет для:
- отслеживания прогресса по задачам;
- составления отчета по бюджету;
- таймтрекинга сотрудников;

как это работает:

Сделайте правилом логать время перед стендапом и выставлять при этом remaining estimate в задачах. Цифра обновляется автоматически, когда логаешь часы. Усилия потребуются, только если намечается вылет из оценки. Разработчик будет заранее думать сколько ему осталось на таск и приходить на стендап подготовленным. Так сэкономите время на вытягивание ответа "сколько осталось на задачу?". 

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

Вася отработал 6.5 часов в понедельник? Увидите в таблице, возьмете на карандаш, теперь полторашку должен.