Когда мы видим плохо обработанную поверхность мы точно знаем, что её нужно до-отшлифовать. А что нужно сделать, чтобы команда работала качественней?

Непрерывное совершенствование это как?

snake.jpg

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

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

Вы можете возразить: Это всё, конечно хорошо может работать в производстве, как написано в книжке Элии Голдрадтта "Цель", Но что делать если наша система состоит из людей? Что является ограничением системы?

Человеческий фактор

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

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

В большинстве случаев, после такой мысли руководитель проекта или подразделения начинает свою команду всячески мотивировать или даже МОТИВИРОВАТЬ толком не разобравшись в проблеме. Отсюда появляются дополнительные отчеты "А что ты сегодня сделал?" или "летучки" которые нужны исключительно для того, чтобы устранить ограничение которого на самом деле нет.

Но что делать, если ощущение неправильности есть, а фактов нет? Или факты появляются только когда проект сдается с опозданием на 30%?

Добываем факты

retrieve-facts.jpg

Ощущение, что "команда медленно работает", это только ощущение, а чтобы с ним начать что-то делать нужно найти доказательства. Самый простой способ найти доказательства это:

  1. Приклеить на стену стикер с надписью "команда плохо работает"
  2. Задать себе вопрос : "В чём это выражается?"
  3. Первый ответ, скорее всего, будет типа : "Проект не успевает в сроки", пишем на стикер и размещаем под первым стикером. Теперь у нас есть зацепка.
  4. Задаем второй вопрос: "Почему проект не успевает в сроки?"
  5. Есть риск зациклить нашу цепь рассуждений: "Дык команда медленно работает!" , Это не совсем правильный ход, лучше подойдут иные варианты, например: "Вася тупит", "Низкая скорость разработки" , записываем все что нашли на стикеры и приклеиваем ниже. Мы уже дошли до уровня конечных исполнителей. Поэтому
  6. Задаём еще один вопрос "почему?" : "А почему скорость разработки низкая?" , и приклеиваем стикер с ответом ниже. Скорее всего, тут уже будут подозрения на конкретных людей "Вася тупит" или "Тестирование отстает". Тут мы дошли до конечных людей, и нужно разбираться уже в причинах такого поведения.
  7. Задаем вопрос: "Почему тестирование отстает?" , "Всегда ли так было?" , ответы также пишем на стикеры и приклеиваем ниже.

Если соединить все стикеры стрелками, то получится дерево текущей реальности (ДТР). Это один из инструментов Теории Ограничений Систем для поиска причин. То есть выявления ЧТО менять.

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

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

Например:

"Отдел тестирования стал медленней работать" - это утверждение пригодное для общего анализа, но не пригодное для принятия решения. Гораздо лучше: "В начале проекта задача висела в тестировании 5 дней, сейчас 2 месяца, почему так?"

performance-tasks-length.png

или вместо "Вася стал плохо работать" : "Раньше Вася делал 5 задач в неделю, а в последние два месяца, только 2 задачи. Что-то произошло?"

performance-tasks-count.png

Получаем цифры

Вариант первый - дешево и сердито

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

Плюсы:

  • Работает всегда
  • Сделать относительно просто.

Минусы:

  • Использовать общую цифру надо осторожно, если исполнитель был занят на других проектах или делал еще что-то, то можно получить возражение "А я еще Николаю с тестированием помогал, и ревью кода делал, знаешь сколько их было сделано?"

Это следует учитывать. Иначе преждевременные обвинения могут поставить вас в неудобное положение.

Вариант второй - это же Agile команда

Если команда работает по методологии SCRUM / Agile / XP то основной метрикой такой команды является скорость реализации задач. Поэтому руководитель проекта (которого быть и должно, но он есть) может не вдаваться в подробности, и взять скорость работы команды как "количество всех задач" за календарный месяц и вручить эту цифру команде, чтобы сами разбирались.

Плюсы:

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

Минусы:

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

Вариант третий - дотошный

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

Разбираем по косточкам каждую задачу:

  • Кто что и сколько сделал.
  • Сколько раз задача возвращалась из тестирования.
  • Сколько задача "висела" в каждой фазе

Плюсы:

  • Будет детальная картинка затрат каждого участника команды
  • Можно будет избежать встречных возражений "А я еще..."

Минусы:

  • Если делать вручную, то требует уйму времени. Однако, решаемо, об этом следующий раздел.

К чему всё это

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

Данное обновление помогает руководителю проекта

  • Понять, из-за чего проект отклоняется от графика.
  • Определить "бутылочное горлышко" в команде.
  • Выявить причины увеличения времени работы над задачей.
  • Акцентировать внимание команды на увеличении скорости прохода (lead time)

За счет того что:

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

И для того чтобы это всё попробовать, Вам не нужно приобретать продукт, мы всё ещё даем 60 дней бесплатного пользования. Загрузите свой проект в BiPulse из вашего трекера Jira или YouTrack. Если возникли вопросы по внедрению и интеграции пишите нам info@bipulse.ru или звоните по телефону +7-965-776-44-08.

Следите за нами в сетях

И держите руку на BiPulse