С вероятностью 95% мы закончим этот проект через 3 недели. Часть 1

Осознание проблемы

Уделяете много времени планированию, но сроки срываются?

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

Находите отговорки вроде "приоритеты часто меняются", "заказчик не знает чего хочет", и т.д.?

Закладываете в 2-3 раза больше времени, и считаете это нормальным?

Является ли для вас озвученное выше проблемой?

Если да, самое время перейти к следующему разделу.

Поиск решения

Есть две дороги, которые открываются после осознания проблемы:

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

Самое эффективное на наш взгляд, это совмещение этих двух подходов, но это не всегда возможно, и не всегда уместно.

Про консалтинг

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

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

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

Разобраться самим

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

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

Статью мы разобьем на три части:

1. Выявление проблем и что можно сделать "здесь и сейчас".
2. Гибкие методологии управления: что же это такое на самом деле. Кто такие Scrum и Kanban и при чем тут прогнозирование сроков?
3. Какие знания актуальны, тренды, рекомендации.

Поехали!

Выявление проблем с помощью визуализации процессов

Пока вы не видите что происходит, вы вряд ли сможете что-то исправить.

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

Начните с одной команды

Создайте доску с задачами*, которая отражает текущее состояние дел.

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

Разделите визуально задачи к которым предъявляются разные требования

Есть задачи, которые надо: "сделать срочно", которые вы делаете в "порядке приоритета", а есть, например, которые надо сделать к "фиксированной дате".

Для этого мы рекомендуем использовать "дорожки".

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

Ваши дорожки могут быть совершенно другими.

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

Зафиксируйте ваши возможности

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

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

Мы рассмотрим достаточно простой способ наблюдать за "стабильностью" системы.

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

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

Вы скорее всего часто будете нарушать эти лимиты, но теперь перед вами открылась совершенно новая картинка:

1. Вы знаете где в текущий момент наибольшая загруженность и куда нужно сфокусировать силы команды.
2. Вы знаете что весь процесс слева от проблемного участка "стоит".
3. Вы можете анализировать ситуацию и пробовать разные решения по оптимизации процесса.

Что в данном случае важно? Карточки в колонке "Программирование / Готово" также учитываются как задачи в работе. Если мы сделаем между Программированием и Поставка очередь без ограничений и поместим туда ожидающие поставки карточки, то эта очередь в какой-то момент будет переполнена. Как следствие – Поставка не будет справляться со скоростью в Программировании.

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

Итак, картинка выше говорит нам о следующем:

1. нужно скорее включать задачи в Поставку;
2. не нужно спешить с пополнением очереди задач, стоит сфокусироваться на текущей работе в Программировании.

Оптимизируйте текущий процесс, управляйте потоком задач

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

Какие этапы чаще всего "засоряются", и как следствие – негативно влияют на время прохождения задач?

Какой этап является слабым звеном? Согласно Теории ограничений Ильяху Голдратта, вам нужно сфокусироваться на разрешении одной самой большой проблемы, чтобы успешно оптимизировать процесс и только потом двигаться дальше.

Теперь у вас есть возможность эту самую большую проблему видеть.

Дизайны досок в сложных случаях

Конечно, дизайн доски, который приведен в примерах – это достаточно простой процесс, самое интересное начинается, когда 2 команды, например, утилизируют одних и тех же людей на определенной стадии процесса.

Что делать в таком случае?

Первое что приходит в голову, создать 2 доски и попросить людей работать и там и там.

Допустим, команда Тестирование работает на две команды:

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

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

Обратите внимание, теперь нет стадии Программирование / Готово. Теперь когда разработчик из любой команды готов передавать задачу в тестирование, он переводит её во Входящее. Здесь команды уже могут приоритизировать работу, так как задачи не расплываются более на 2 доски.

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

* - Доски из статьи смоделированы в kaiten.io