Пример из руководства
Руководство предлагает следующий шаблон (R1.2:3), я планирую написать более детальный регламент на его основе.
“Заказчик формулирует своё представление о том, какую задачу надо решить, выделяя отдельно, какую цель надо достичь, и описывает задачу способом, записанным в регламенте постановки задач. Затем идёт обсуждение с исполнителем, в ходе которого заказчик убеждается, что исполнитель понимает цель решения задачи. Заказчик и исполнитель обсуждают и выбирают метод решения задачи, обеспечивающий достижение цели, договариваются о необходимых для решения задачи ресурсах и о сроках завершения задачи с учётом всех прочих задач исполнителя. Исполнитель уходит решать задачу. Если возникли какие-то затруднения, с которыми исполнитель не может справиться самостоятельно, то он немедленно сообщает об этом заказчику, и далее совместно вырабатывается решение”
Моделирование: как это у нас устроено сейчас
- Задачи могут прилетать изнутри команды или извне (это не так важно в данном случае, но задачи извне часто описываются с более дальнего понятийного расстояния).
- Заказчик открывает тикет в джире и описывает задачу как-то (как умеет). Обычно сообщает о тикете кому-то из команды.
- Этот кто-то:
- как минимум помечает тикет как принадлежащий команде (помещает в бэклог), чтобы мы его увидели на сессии планирования.
- Опционально, если человек в теме (и в хорошем настроении – не сильно задолбан текущими задачами), он улучшает описание, беседует с заказчиком, беседует с шефом, чтобы прикинуть приоритеты, и делает соответствующие пометки в тикете.
- Как максимум, для срочных задач, человек берёт её себе или назначает кому-то. Срочные задачи добавляются в текущий спринт прямо по ходу спринта. Чуть менее срочные задачи отправляются на следующий спринт в момент поступления, минуя бэклог.
- На сессии планирования, команда коллективно выбирает задачи из бэклога и назначает исполнителям на следующий спринт.
Проблемы
- Спринты у нас по 3 недели, сессии планирования гарантированно случаются только перед новым спринтом, так что задачи потенциально долго пылятся в бэклоге. Поэтому, на самом деле мы заглядываем в бэклог чаще (но не систематично).
- На планировании спринта описание задачи в тикете нередко оказывается недостаточным, чтобы что-то понять, спланировать ресурсы, или даже выбрать приоритет – ошибки планирования неизбежны.
- На планировании я часто соглашаюсь на задачу или на оценки сроков, не подумав достаточно (не могу быстро сообразить, не готовы возражения, не помню, какие ещё задачи запланированы).
- Общения исполнителя с заказчиком обычно достаточно для выяснения целей, но недостаточно для выбора методов, так как контекст и доступные ресурсы неясны. Приходится делать несколько совещаний, с привлечением менеджеров и опытных инженеров. После этого нередко корректируются выделенные ресурсы и сроки (например, задача может пойти обратно в бэклог, если нет ресурсов, или задача зависит от чего-то, что ещё не готово).
- Обсуждения со всеми могут занять много времени, которое сложно предсказать (зависит от доступности людей). Отчасти поэтому (а отчасти из-за отсутствия явного регламента/чеклиста), обычно время на обсуждения не учитывается при планировании работ.
- Иногда достаточных обсуждений не происходит. Исполнитель выполняет работу как может/как понял – это приводит к ошибкам и потерянным ресурсам.
- Выбор метода может быть сразу невозможен – нужно исследовать (так как мы унаследовали много кода и оборудования, которые мы пока не знаем), нужно делать несколько итераций, или “поразмышлять” в спокойной обстановке, иногда “пожить” в проблеме несколько дней. Из-за этого, оценки времени делать сложно. Задачи схожие на первый взгляд могут занять 2 часа или 2 недели.
- Как в таких случаях набирать задачи/инициативы на месяц?
- Лично мне сложно понять грань между перфекционизмом и самоуважением (нежеланием делать свою работу плохо).
- Сложно планировать сроки, так как никто не знает сколько когда будет свободно людей – ведь их текущие задачи имеют свойство растягиваться сильно дольше запланированного.
- На созвонах команды (статус, планирование) многие из тем меня не касаются. Ощущение потерянного времени, мультитаскинг.
Важные наблюдения и цитаты из руководства
Ограничение Work in Progress
- Люди склонны забрасывать “почти доделанные” задачи и переключаться на что-то новенькое. Это в нас, похоже, встроено эволюционно, но это вредит бизнесу.
- Не брать в работу больше инициатив чем я реально могу сделать – от этого пропускная способность может увеличиться!
- Людям свойственно искать социальное одобрение здесь и сейчас. В том числе соглашаться на нереалистичные сроки выполнения задачи чтобы избежать обострения/конфликта в моменте. За этим либо следует переработка либо отодвигание сроков с оправданиями.
Слепота к реальности
Я считаю, что команда не справляется с объемом задач, что не хватает специалистов (это реальность или моё заблуждение типа impostor syndrome?). Кажется, шеф это тоже подсознательно понимает (но не говорит явно). Шеф склонен набирать задачи, соглашаться на всё (чтобы не выглядеть плохо?), но потом качество и/или сроки страдают.
Лечение слепоты к реальности начинается с обеспечения безопасности коммуникации с самим собой и окружающими. Акцент не на поиск виноватых и самоутверждение (“а я же говорил”), а на “мы не станем плохими людьми от того что признаем реальность”. Надо договориться с окружающими, что мы не ищем виноватых а пытаемся разобраться что вообще происходит, чтобы избежать этого в будущем.
Если вы общаетесь с начальством и понимаете, что решения начальства уже привели к негативным последствиям, но начальники не торопятся сменить курс – обеспечьте им возможность безопасно поменять решение, не поступившись их представлениями о себе в их глазах и глазах окружающих. Тогда вам будет гораздо легче договариваться. Подробнее об этом можно прочитать в книге “Психологическое айкидо” психолога Михаила Литвака.
Регламенты (TBD)
Планирую написать регламент(ы), описывающие прохождение задачи по состояниям, от постановки, уточнения и планирования до выполнения и контроля выполнения.