Как составить квартальный план работы

Как провести распределённое безбумажное квартальное планирование и не облажаться?

Дано: Компания, использующая фреймворк Scaled Agile (SAFe) для масштабирования Agile-разработки в рамках всей организации; 10 команд разработки, объединённых в одну большую команду (Agile Release Train, согласно терминологии SAFe), доставляющую общий продукт; необходимость проведения двухдневного квартального планирования (PI Planning) для определения плана работы ИТ-команд на ближайшие 3 месяца*; три офиса разработки, расстояние между самыми удалёнными превышает 6 тысяч километров с соответствующей разницей в 5 часов рабочего времени; предыдущий опыт планирования, предусматривавший физическое присутствие ключевых коллег в одном помещении и использование аналоговых досок/вайтбордов/маркеров/липких бумажечек.

* Тяжеловесный конструкт “План работы ИТ-команд на ближайшие 3 месяца” грозит серьёзно увеличить объем текста, поэтому в дальнейшем я планирую вместо него писать просто – “коммитмент”. Соответственно, составить и принять план работы – “закоммититься”.

Зачем это понадобилось?

1) Усталость от аналоговых методов работы. В то время, как космические корабли бороздят просторы, а Илон Маск роет тоннели, мы, «айтишники», упорно пишем маркерами на липучих бумажках и лепим их на доски – есть в этом некий диссонанс. Так выглядел наш коммитмент некоторое время назад:

Да, это лист бумаги размером примерно 2х5 метров, и каждую бумажку следовало после планирования превратить в задачу в Джире…

2) Усталость коллег-кочевников. Несмотря на то, что головной офис у нас расположен в довольно таки приветливой, тёплой стране, к моему удивлению в прошлом году я узнал, что они совсем не рады такой своей кочевой жизни, и мои аргументы в стиле «да ладно, в море покупаетесь, на солнышке погреетесь», которые я имел неосторожность высказать, были восприняты не очень тепло – не все готовы к частым командировкам, их домочадцы не всегда это приветствуют, у кого-то организм на частые перелёты реагирует не очень хорошо.

3) Подключение большего числа коллег из ИТ к процессу планирования. Как понятно из предыдущего пункта, весь офис отправлять на планирование мы позволить себе не могли, поэтому отправляли только Избранных, тем самым исключая остальных из процесса, что к общей морали плюсов не добавляло.

4) Оптимизация финансовых затрат. Да, это чувствительный момент – ключевых людей достаточно много, и возить их самолётами туда-сюда четыре раза в год – накладное дело.

Часть Нулевая, или Работа с Портфолио-Бэклогом

А начинается всё гораздо раньше – для того, чтобы плодотворно работать над коммитментом во время планирования, необходимо, чтобы было под что коммититься. Чтобы обеспечить это, мне приходится “загружать” бизнес-владельцев работой над предполагаемыми инициативами (или, в терминологии SAFe, Эпиками, но я буду использовать привычный для меня термин) как можно раньше. В идеале этот процесс должен быть полностью оторван от цикличности квартальных планирований и идти своим, канбанным путём. За основу мы взяли SAFe portfolio Kanban:

У нас есть отдельный JIRA-проект с тремя типами задач: эпики, бизнес-инициативы и архитектурные инициативы; а также соответствующая Канбан-доска. Алгоритм для бизнес-владельца инициативы прост: он добавляет задачу в этот проект, и она по дефолту попадает в Бэклог – это первый статус нашего канбана — Funnel:

Там хранятся инициативы, еще не готовые к ревью. Бизнес-владелец работает над содержанием инициативы, пока не почувствует себя готовым к следующему шагу. Минимум, необходимый на этом этапе – заполненные поля Problem Statement, Desired Outcome и Measure of Success, а также чуть более развёрнутая, но простая и понятная презентация. На данном этапе важно уйти от упоминания технических решений и сконцентрироваться на бизнес-параметрах. Когда все данные собраны, владелец двигает задачу в следующий статус – Reviewing.

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

• уйти обратно в бэклог на доработку
• упраздниться без шанса на дальнейшую жизнь (для этого я использую отдельный статус Out-of-Date, скрытый на Канбан-доске)
• получить согласование и пройти на следующий этап – Analyzing.

На этом этапе мы – ура! – можем привлечь сотрудников из ИТ: аналитиков, архитекторов, лидов, кого угодно. Под “мы” я подразумеваю себя как Release Train Engineer’a, но в идеальном случае бизнес-владельцев, которые уже обрели некий опыт работы и самостоятельность, необходимую для привлечения нужных команд и самостоятельного запуска процесса аналитики. Пишу про идеальный случай, поскольку уровень самоорганизации наших коллег плавает, и в некоторых случаях они просят помощь в виде специально назначенного фасилитатора, но от данной практики я стараюсь понемногу отойти.

Цель данного этапа — предварительная аналитика, или, как мы её называем, пре-дискавери. На выходе мы должны получить тот минимум, который позволит нам закоммититься: предлагаемые решения, риски и зависимости, нефункциональные и инфраструктурные требования, пользовательские карты (user maps), архитектурные схемы. Дополнительно мы просим команды дать предварительную оценку в стори-поинтах (story points) на уровне фичей – это позволит нам в конце квартала определить приоритеты.

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

Также на этапе аналитики в этот процесс привлекаются архитекторы или, как у нас принято в последнее время, их доверенные люди – “амбассадоры” (EA Ambassadors). Их задача – донести до участников процесса видение архитектурного департамента, помочь найти наилучшее решение и в конце концов согласовать данное решение с главным архитектором компании (Head of Enterprise Architecture).

Когда команды считают, что инициатива достаточно проработана и готова к следующему шагу, они двигают её в следующий статус – Portfolio Backlog.

На этом этапе важный шаг – провести WSJF-приоретизацию (Weighted Shortest Job First). Для этого за 3 недели до планирования мы проводим большую встречу, которая пока, к сожалению, занимает многие часы, и во время этой встречи с помощью покера по шкале Фибоначчи члены менеджмент-борда оценивают бизнес-ценность (Business Value), критичность по времени (Time Criticality), потенциальное уменьшение рисковости (Risk Reduction) и реализацию возможностей (Opportunity Enablement):

Чтобы иметь возможность отслеживать историю инициатив, к каждой из них я добавляю ярлык (label) в джире с данными о квартале: 2018Q4, 2019Q1 и т.д.

Забегая вперёд, опишу следующие возможные статусы. После проведения коммитмента инициативы, успешно взятые в работу, переезжают в статус Implementing, а “невлезшие” получают статус Parked и в дальнейшем имеют возможность быть рассмотренными для следующих кварталов. Доставленные же инициативы переезжают в Done.

Как результат, мы имеем примерно следующую картинку на Канбан-доске:

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

• Бизнес-владельцы стали детально прорабатывать инициативы и серьезно готовиться к ревью
• Ревью стали более дотошными в хорошем смысле
• Команды имеют больше времени на пре-дискавери
• я не теряю старые инициативы – всегда можно вернуться к запаркованным, недоставленным или забытым инициативам и работать над ними дальше

Инструменты, используемые на данном этапе:

• Atlassian Jira Software Server
• Плагин Colors for Jira – для подсвечивания бизнес- и архитектурных инициатив
• Плагин ‘Structure – Project Management at Scale’ — для визуализации структуры из инициатив с прилинкованными к ним фичами и их WSJF-приоретизации
• Atlassian Confluence – источник внутренней документации
• Lucidchart и его плагины для Jira и Confluence – для рисования диаграм

Часть I. Подготовка к планированию

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

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

Техническая подготовка. С переходом на удалённое планирование возникли специфические запросы, такие как качество интернет-связи (приоритизация и оптимизация маршрутов для JIRA и Confluence) и теле- и аудиоприсутствие (мы используем комплекты Logitec Group, микрофоны Jabbra и персональные наушники в различных комбинациях, веб-камеры, ПО Zoom для видеоконференций).

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

Аудитория. Соответственно, полный список всех приглашённых.

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

Часть II. Планирование и коммитмент

После всей подготовительной беготни наступает, наконец, этот момент – старт квартального планирования. За два дня мы должны успеть разобрать все инициативы, убедиться, что информации достаточно и закоммититься. После нескольких коротких, но зажигательных речей рабочие группы расходятся по местам и берутся за дело. На данный момент количество групп распределено между тремя офисами по формуле 4х4х2, а удалённые пользователи подключаются к необходимому столу через выделенный Zoom-канал.

По окончанию дискавери каждой из инициатив фасилитатор, убедившись, что все необходимые данные – такие, как например критерии приёмки, описание технического решения, риски, зависимости, наличие необходимости в новой инфраструктуре – имеются, отмечает инициативу чекбоксом IT Session Finished для прозрачности прогресса и рабочая группа может переходить к следующей.

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

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

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

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

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

По окончанию сего немудрёного процесса команды на флаге компании торжественно клянутся доставить коммитмент (шутка) и разбегаются по домам (тоже шутка – все разбегаются по барам).

Инструменты, используемые на данном этапе:

• Atlassian Jira Software Server
• Плагин ‘Structure – Project Management at Scale’ – для мониторинга процесса дискавери и во время выполнения коммитмента.

Часть III. Клонирование задач в рабочую JIRA-экосистему компании

Пока все пьют водку, RTE работает над созданием коммитмента в том виде, в котором его можно раздать в бэклоги команд разработки и мониторить в течение всего квартала. Для этого я использую плагин ‘Bulk Clone Professional for Jira’ — он добавляет пункт, обеспечивающий коллективное клонирование, в меню Bulk Change, и обладает такими нужными для меня возможностями, как клонирование ссылок, обновление ссылок между свежесозданными клонами, обновление эпик-линков, добавление префикса в заголовок и автоматическое добавление ярлыка:

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

Сначала я клонирую абсолютно все задачи в отдельный проект Global Backlog, поскольку в нём мы храним эпики, а мне нужно иметь актуальные связи эпик — стори в свежесклонированных задачах. И уже в качестве второго шага я делаю запросы по каждой команде разработки отдельно и перемещаю стори в конечные проекты команд.

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

В целом, преимущества, которые появились в результате такого подхода, следующие:

• Как ни банально, но новые фичи и стори человеку из ИТ легче напечатать, чем написать маркером на липкой бумажечке.
• Многие вещи, такие как остаток капасити и апдейт WSJF в зависимости от оценок сторей, рассчитываются автоматически с помощью формул.
• Благодаря клонированию изначальный слепок коммитмента сохраняется для истории и к нему можно всегда вернуться.
• Очень сильно экономится время и энергия на подготовке планирования – работа с бумагой отнимает силы.
• Конечно, здорово, что больше не нужно набивать таски в джиру с бумажечек.

Инструменты, используемые на данном этапе:

• Atlassian Jira Software Server
• Плагин ‘Bulk Clone Professional for Jira’ – для клонирования фичей и стори в конечные JIRA-проекты.
• Плагин ‘Structure — Project Management at Scale’ – для создания финальной структуры.

Эпилог

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

И еще один момент – тяжело верится в то, что это возможно, но всеми силами хотелось бы избежать срача вокруг эджайла, фреймворков, эффективных и “эффективных” менеджеров. Пожалуйста, помните, что я описал весь процесс в надежде заинтересовать людей, которым это близко, его технической реализацией, и очень жду соответствующих дискуссий.

До встречи в комментариях!

How often do you look back at the last few months and wonder where the time has gone? What did you actually get done? It feels like you were just running around, dealing with one fire after another, but the list of ideas you wanted to implement is still just that– a list. The disappointment settles in as you realize, you’ve yet again failed to fulfill the majority of your quarterly plans. 

Briefly put, quarterly planning means setting goals for the next three months and breaking them into actionable steps or projects. At Toggl Plan, every person, in alignment with their team’s goals and the overall company strategy, comes up with their personal quarterly plan. Teams then present these quarterly plans to the whole company at the beginning of the quarter. We also make sure to share our plans on a Toggl Plan timeline and follow up mid- and end of quarter to assure progress is taking place. 

To Plan or Not to Plan

This is not the question. We, at Toggl Plan, find planning an important part of our routine. We start with the big picture and defining the overall strategy before cutting it down into more manageable chunks. The short-term planning is important to stay motivated and flexible. Priorities can change, and they often do, so revisiting our plans every three months keeps the whole company aligned.

Writing down goals and actions for the upcoming quarter, as well as openly sharing them with the team, helps everyone have a clear understanding of

• what is expected of them
• where the company is heading
• what the current priorities are

It makes sure we’re moving forward, rather than just reacting to anything and everything that comes up. To put it simply– quarterly planning helps us take control of our time.

But let’s not focus on how to come up with goals and action points. Let’s take a look at how we make sure the beautifully crafted plans get executed.

How to Do Quarterly Planning

The process of quarterly planning doesn’t end with coming up with a list of things to do or goals to achieve. It’s the actual execution and follow-up that makes the difference. While quarterly planning, in some way or another (be it through OKRs, KPIs or some other framework), is a common practice, many companies struggle to keep the plans meaningful, resulting in end-of-quarter reviews where goals haven’t been met and actions haven’t been taken. This can result in two situations:

• The organizational strategy isn’t implemented, and the company isn’t moving forward.
• The employees become unmotivated due to the lack of direction and stop taking set goals seriously. 

To avoid either of the above mentioned scenarios, we’ve made Toggl Plan an integral part of our quarterly planning. In addition to writing down the actions each of us intends to take in the next quarter, we also mark them down on our timeline for all to see. 

Why Use Toggl Plan for Quarterly Planning

Toggl Plan is a web-based solution for task scheduling, project planning, and team management. Users create and schedule tasks using a drag-and-drop interface, producing a color-coded timeline of the work to be completed. Marking tasks as done gives an even better understanding of progress and increases accountability within a team.

Mapping out your quarterly plan on a visual timeline makes you actually consider the reality of set activities.

• It helps you visualize how long each activity might take and if three months is enough time to get things done.
• Oftentimes, fulfilling one’s own plans requires input from other people in the organization. On Toggl Plan’s timeline, the workload and availability of everyone is visible for all. Knowing this information in advance helps you plan your projects for success.
• It increases accountability, as anyone in the company can go back and check what everyone is up to and what’s been done. It’s definitely a step up for accountability from just the one-off end-of-quarter summary (if even that exists).
• By marking tasks as done, it is super easy to track your progress on the go. Nothing is set in stone; however, and with the drag-and-drop functionality, plans can be moved around easily, while still taking the availability or other stakeholders into account.
• Using Toggl Plan’s timelines significantly improves the communication within the company. It decreases time spent on back-and-forth messaging over when things get done or what someone is working on. Open communication and trust are integral to employees who are engaged and feel accountable for their actions.

Setting up Quarterly Plans in Toggl Plan

For quarterly planning, we suggest using Team view in Toggl Plan. Ideally, you’d create a group for either the whole company or one department at a time.

You still start off by defining your goals and actions to be taken in the next three months. But instead of leaving it at that, encourage everyone to map out their actions on their personal timeline.

This doesn’t have to be super specific. It’s a rough estimation of how long various projects or actions can take and mapping that out.

If a task absolutely can’t be guesstimated on a timeline (e.g., it depends on a pending feature release), feel free to use the icebox to still keep it in the same system.

Once the task becomes relevant, you can just drag-and-drop it right where it belongs – on your timeline.

If you wish, you can also add notes, attachments or to-do lists within each task. This way, you’ll have all your initial ideas in one place and when the time comes, it’ll be easy to pick the project up.

As mentioned, the plan mapping above is just a rough schedule for the whole upcoming quarter. Toggl Plan’s team view can also be super useful for weekly standups or team meetings. That is when you can plan your upcoming week in detail and cut the bigger ideas down into smaller tasks. Toggl Plan’s color-coding makes it easy to visually differentiate various projects and plans to keep a clear overview of everything that’s going on.

We also encourage using milestones to remind people of time passing by. For example, you can create eye-catching milestones for mid-quarter and end of quarter to remind people to check  their progress.

Conclusion

Quarterly planning helps ensure work is done proactively, rather than just reactively. However, it doesn’t end with listing down the actions needed to take within the upcoming three months.

The execution and follow-up are key to keeping everyone motivated and engaged. With the help of Toggl Plan, it is much easier to communicate quarterly plans, keep an eye on progress and set plans that are actually reasonable. Try out our beautifully simple visual timeline and get more done.

To learn about other features of Toggl Plan, check out this video.

PS. The video is long, but it has timestamps to help you quickly find what you’re looking for!

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

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

В деловой жизни оправдали себя следующие
плановые периоды:

— долгосрочные цели = 3—5 лет (или более)
—> несколько лет;

— среднесрочные цели = 1—3 года —>
годовые планы;

— текущие цели = 1 неделя — 3 мес.
—>месячные, декадные планы.

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

По истечении соответствующего планового
периода посредством сравнения «план—факт»
определяются результаты периода, которые
могут учитываться для корректировки
планов на последующий период.

План на несколько лет вперед

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

План на 1990—1994 гг.

№	Цели (задачи)	1990	1991	1992	1993	1994
1 2 3	Построить собственный дом Стать руководителем службы сбыта Достичь годового дохода в 100 000 марок

Годовой план

Из плана на несколько лет вперед Вы
выводите годовой план, перенося в него
из соответствующего «годового столбца»
все те задачи и цели, которые Вы там
наметили. Следите за тем, чтобы не взяться
за задачи, которые относятся к более
поздним целям.

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

Квартальный план

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

Месячный план

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

Предпосылка составления реальных
месячных и недельных планов состоит в
том, что Вы определяете еще и так
называемое свободно планируемое время.
Предусматривайте в своем временном
плане также резервы времени («буферы»)
для решения дополнительных задач так,
чтобы можно было соблюсти плановые
сроки без стресса и цейтнота.

Соседние файлы в папке Дополнительная

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #