Главное Свежее Вакансии Образование
1 648 4 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

Как перестать тратить уйму времени на прогнозирование сроков и при этом знать когда наступит финал. Как подходить плавно к изменениям, которые существенно повысят производительность ваших команд.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поехали!

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

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

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

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

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

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

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

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

b_56bf443d4e4f3.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b_56bf6a20e7dce.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+1
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Симулятор бизнес-процессов
Сервис имитационного моделирования и оптимизации бизнес-процессов
Prolis Labkk
Почему предлагаете ограничить количество параллельно выполняемых задач? Ладно бы, если это, например, количество управляемых проектов менеджера. Но количество задач на этапе с пулом доступных ресурсов может быть бесконечно-большим и ни на что это не влияет. Например одна задача в разработке висит - ждет дизайн-макета, а вторая согласования ТЗ - обе задачи не влияют на производительность и загруженность пула задачами.
Ответить
GanttPRO
Онлайн Конструктор Диаграмм Ганта
Alexandra Igorevna
Мне кажется, если бы вы написали расширенную статью об управлении проектами, о методологиях, сравнениях систем и т.д., ваша статья набрала бы больше посмотров, позитивных отзывов, т.д. и, как итог, была бы более эффективна потенциально для вашего сервиса, чем простая реклама. Пис
Ответить
Dmitry Zheltov
Это не в первой части статьи надо писать, а в первой книге трилогии :)
Ответить
Голосовые рассылки
Сервис голосовых рассылок, триггерных звонков
Rinat Shamsiev
Вы уверены, что при таком уровне усложнения все еще имеет смысл пользоваться досками? Вы сами пробовали такие (возможно даже многомерные) доски?
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.