С вероятностью 95% мы закончим этот проект через 3 недели. Часть 1
Осознание проблемы
Уделяете много времени планированию, но сроки срываются?
Проводите многочасовые совещания с командой и руководством с целью митигировать риски, но в итоге завершаете проект все равно сильно позже?
Находите отговорки вроде "приоритеты часто меняются", "заказчик не знает чего хочет", и т.д.?
Закладываете в 2-3 раза больше времени, и считаете это нормальным?
Является ли для вас озвученное выше проблемой?
Если да, самое время перейти к следующему разделу.
Поиск решения
Есть две дороги, которые открываются после осознания проблемы:
- позвать консультантов для проведения аудита существующих процессов и дальнейшей оптимизации;
- разобраться самим в существующих методологиях и подходах в управлении проектами/процессами (конференции, обучение, наступления на грабли и другие приятные хлопоты).
Самое эффективное на наш взгляд, это совмещение этих двух подходов, но это не всегда возможно, и не всегда уместно.
Про консалтинг
Итак, вы обладаете деньгами, которые готовы отдать консультантам в надежде на то, что они улучшат ваши процессы, и вы достигните желаемого результата.
Для многих компаний это правильный подход, единственное что мы можем сказать – знания, которые вы получите в процессе работы с профессионалами, должны остаться в вашей компании.
Всегда должен быть человек (или группа людей), который разберется, поймет и примет всю работу, проделанную сторонними специалистами. А то вся проделанная работа рискует превратиться в тыкву в ночь, когда консалтинговый контракт истечет.
Разобраться самим
По сути вы принимаете решение – сделать шаг вперед, получить новые знания и попробовать применить их на практике. Возможно, в вашей компании пока еще нет ресурсов на профессиональных консультантов, а возможно, вы привыкли делать все сами :)
Мы хотим рассказать как далеко вы можете продвинуться с точки зрения выстраивания здоровых процессов "своими руками", и получение каких знаний имеет смысл оплачивать, чтобы получить максимальную отдачу.
Статью мы разобьем на три части:
- Выявление проблем и что можно сделать "здесь и сейчас".
- Гибкие методологии управления: что же это такое на самом деле. Кто такие Scrum и Kanban и при чем тут прогнозирование сроков?
- Какие знания актуальны, тренды, рекомендации.
Поехали!
Выявление проблем с помощью визуализации процессов
Пока вы не видите что происходит, вы вряд ли сможете что-то исправить.
Сначала надо разобраться в причинах проблем, потом выстраивать стратегию по их решению.
Начните с одной команды
Создайте доску с задачами*, которая отражает текущее состояние дел.
Обратите внимание на то, что сегментация стадий на шаги позволит вам лучше разобраться в нюансах текущего процесса.
Разделите визуально задачи к которым предъявляются разные требования
Есть задачи, которые надо: "сделать срочно", которые вы делаете в "порядке приоритета", а есть, например, которые надо сделать к "фиксированной дате".
Для этого мы рекомендуем использовать "дорожки".
Посмотрите как видоизменилась доска, теперь мы получили еще больше полезной информации, и возможность лучше приоритизировать текущую работу.
Ваши дорожки могут быть совершенно другими.
Кстати, часто дорожки используются для того, чтобы разметить исполнителей и следить за их загрузкой. Но в большинстве случаев это может задать вам неправильный приоритет в работе над задачами. Суровая правда заключается в том, что попытки максимально загрузить всех исполнителей могут негативно сказаться на финальных сроках и результатах. Об этом мы будем рассказать во 2-й части статьи.
Зафиксируйте ваши возможности
Забегая вперед (к теме о гибких методология) хотим сказать следующее: невозможно прогнозировать какие-либо параметры системы (например, сроки), если работа системы хаотична.
Например, вы можете нагрузить людей сверхурочной работой, но постоянная работа в таком режиме скорее всего плохо отразится в долгосрочной перспективе на сроках сдачи новых проектов.
Мы рассмотрим достаточно простой способ наблюдать за "стабильностью" системы.
Определите "комфортное" количество задач, которое может выполняться одновременно на каждом этапе в рассматриваемом процессе, и зафиксируйте его.
На картинке можно заметить, что появились цифры у названий колонок.Первая цифра - сколько задач в работе, вторая – та самая "зона комфорта".
Вы скорее всего часто будете нарушать эти лимиты, но теперь перед вами открылась совершенно новая картинка:
- Вы знаете где в текущий момент наибольшая загруженность и куда нужно сфокусировать силы команды.
- Вы знаете что весь процесс слева от проблемного участка "стоит".
- Вы можете анализировать ситуацию и пробовать разные решения по оптимизации процесса.
Что в данном случае важно? Карточки в колонке "Программирование / Готово" также учитываются как задачи в работе. Если мы сделаем между Программированием и Поставка очередь без ограничений и поместим туда ожидающие поставки карточки, то эта очередь в какой-то момент будет переполнена. Как следствие – Поставка не будет справляться со скоростью в Программировании.
Следствие из этого простое – на пути от начала и до конца процесса не должно быть "бесконечных" очередей, они дестабилизируют систему и лишают вас возможности что-либо прогнозировать.
Итак, картинка выше говорит нам о следующем:
- нужно скорее включать задачи в Поставку;
- не нужно спешить с пополнением очереди задач, стоит сфокусироваться на текущей работе в Программировании.
Оптимизируйте текущий процесс, управляйте потоком задач
Так картинка может выглядеть, когда вы попытались разгрузить этап Программирование, теперь Вам нужно наблюдать за своей системой.
Какие этапы чаще всего "засоряются", и как следствие – негативно влияют на время прохождения задач?
Какой этап является слабым звеном? Согласно Теории ограничений Ильяху Голдратта, вам нужно сфокусироваться на разрешении одной самой большой проблемы, чтобы успешно оптимизировать процесс и только потом двигаться дальше.
Теперь у вас есть возможность эту самую большую проблему видеть.
Дизайны досок в сложных случаях
Конечно, дизайн доски, который приведен в примерах – это достаточно простой процесс, самое интересное начинается, когда 2 команды, например, утилизируют одних и тех же людей на определенной стадии процесса.
Что делать в таком случае?
Первое что приходит в голову, создать 2 доски и попросить людей работать и там и там.
Допустим, команда Тестирование работает на две команды:
В этом случае могут возникнуть конфликты с приоритетами. Люди будут разрываться между двумя командами и ограничения не будут выполнять свою роль.
Возможно, в данном случае стоит рассмотреть более гибкий вариант визуализации, когда команда тестирования превращается в полноценного участника такой системы c единой точкой входа:
Обратите внимание, теперь нет стадии Программирование / Готово. Теперь когда разработчик из любой команды готов передавать задачу в тестирование, он переводит её во Входящее. Здесь команды уже могут приоритизировать работу, так как задачи не расплываются более на 2 доски.
Конечно все эти стадии для примера, как будет выглядеть ваш процесс – зависит от вас, от вашей команды.
* - Доски из статьи смоделированы в kaiten.io
