Статьи об управлении проектами - BIPULSE - Тег - ТРИЗСтатьи об управлении проектами 2024-01-20T16:04:00+03:00urn:md5:35302335e75ffebb40f91d5a35574eceDotclearКачество команды или опять о производительностиurn:md5:f88579baff819cf550ef8c902b7bb4e82015-11-19T21:45:00+00:002023-06-10T11:31:06+01:00Алексей ВасильевAgileПроизводительностьСкорость проходаСтатистикаТОСТРИЗ<p>Что такое качество команды? В каких попугаях его мерить?</p>
<p><img src="https://bipulse.ru/dotclear/public/.snake_s.jpg" alt="snake.jpg" style="float:left; margin: 0 1em 1em 0;" title="В каких попугаях мерить качество команды?" />
Качество команды величина субъективная, однако его можно выразить через скорость поставки качественного продукта решающего задачу клиента. Если записать это в терминах <a href="https://bipulse.ru/blog/index.php?tag/%D0%A2%D0%A0%D0%98%D0%97">ТРИЗ</a>, через идеальный конечный результат, то получим, что <em>качественная команда поставляет качественный Продукт за ноль времени, и потери связанные с переделкой сделанной работы отсутствуют.</em></p>
<p>Но если мы знаем, что такое качество, и оно нас не удовлетворяет, то как мы можем его улучшить? Как улучшить то, что нельзя пощупать?</p><p>Что такое качество команды? В каких попугаях его мерить?</p>
<p><img src="https://bipulse.ru/dotclear/public/.snake_s.jpg" alt="snake.jpg" style="float:left; margin: 0 1em 1em 0;" title="В каких попугаях мерить качество команды?" />
Качество команды величина субъективная, однако его можно выразить через скорость поставки качественного продукта решающего задачу клиента. Если записать это в терминах <a href="https://bipulse.ru/blog/index.php?tag/%D0%A2%D0%A0%D0%98%D0%97">ТРИЗ</a>, через идеальный конечный результат, то получим, что <em>качественная команда поставляет качественный Продукт за ноль времени, и потери связанные с переделкой сделанной работы отсутствуют.</em></p>
<p>Но если мы знаем, что такое качество, и оно нас не удовлетворяет, то как мы можем его улучшить? Как улучшить то, что нельзя пощупать?</p> <p>Когда мы видим плохо обработанную поверхность мы точно знаем, что её нужно до-отшлифовать. А что нужно сделать, чтобы команда работала качественней?</p>
<h2>Непрерывное совершенствование это как?</h2>
<p><img src="https://bipulse.ru/dotclear/public/snake.jpg" alt="snake.jpg" style="display:table; margin:0 auto;" title="В каких попугаях мерить качество команды?" /></p>
<p>Для того, чтобы сделать команду качественней, нам может помочь <a href="https://bipulse.ru/blog/index.php?tag/%D0%A2%D0%9E%D0%A1">процесс непрерывного совершенствования</a> состоящий из пяти простых шагов:</p>
<ul>
<li>Найти ограничение системы</li>
<li>Понять как максимально использовать ограничение</li>
<li>Подчинить всю систему систему работе ограничения</li>
<li>Расширить (расшить) ограничение</li>
<li>Не поддаться инерции.</li>
</ul>
<p>Вы можете возразить: <em>Это всё, конечно хорошо может работать в производстве, как написано в книжке Элии Голдрадтта "Цель", Но что делать если наша система состоит из людей? Что является ограничением системы?</em></p>
<h3>Человеческий фактор</h3>
<p>Люди и являются нашим ограничением. Или их эффективность. Исходя из определения идеального конечного результата качество команды можно выразить, как функцию зависящую от скорости поставки продукта и количества ошибок. И одновременно с этим, она прямо пропорциональна личной эффективности каждого сотрудника.</p>
<p>Когда личная личная эффективность падает, то у руководителя проекта возникает мысль "Как-то не быстро ребята работают, Может быть качество команды понизилось и пора кого-то заменить?"</p>
<p>В большинстве случаев, после такой мысли руководитель проекта или подразделения начинает свою команду всячески мотивировать или даже МОТИВИРОВАТЬ толком не разобравшись в проблеме. Отсюда появляются дополнительные отчеты "А что ты сегодня сделал?" или "летучки" которые нужны исключительно для того, чтобы устранить ограничение которого на самом деле нет.</p>
<p>Но что делать, если ощущение неправильности есть, а фактов нет? Или факты появляются только когда проект сдается с опозданием на 30%?</p>
<h2>Добываем факты</h2>
<p><img src="https://bipulse.ru/dotclear/public/.retrieve-facts_m.jpg" alt="retrieve-facts.jpg" style="float:right; margin: 0 0 1em 1em;" title="добыча фактов" /></p>
<p>Ощущение, что "команда медленно работает", это только ощущение, а чтобы с ним начать что-то делать нужно найти доказательства. Самый простой способ найти доказательства это:</p>
<ol>
<li>Приклеить на стену стикер с надписью "команда плохо работает"</li>
<li>Задать себе вопрос : <em>"В чём это выражается?"</em></li>
<li>Первый ответ, скорее всего, будет типа <em>: "Проект не успевает в сроки"</em>, пишем на стикер и размещаем под первым стикером. Теперь у нас есть зацепка.</li>
<li>Задаем второй вопрос: <em>"Почему проект не успевает в сроки?"</em></li>
<li>Есть риск зациклить нашу цепь рассуждений: <em>"Дык команда медленно работает!"</em> , Это не совсем правильный ход, лучше подойдут иные варианты, например: <em>"Вася тупит"</em>, <em>"Низкая скорость разработки"</em> , записываем все что нашли на стикеры и приклеиваем ниже. Мы уже дошли до уровня конечных исполнителей. Поэтому</li>
<li>Задаём еще один вопрос "почему?" : <em>"А почему скорость разработки низкая?"</em> , и приклеиваем стикер с ответом ниже. Скорее всего, тут уже будут подозрения на конкретных людей "Вася тупит" или<em> "Тестирование отстает"</em>. Тут мы дошли до конечных людей, и нужно разбираться уже в причинах такого поведения.</li>
<li>Задаем вопрос:<em> "Почему тестирование отстает?"</em> ,<em> "Всегда ли так было?"</em> , ответы также пишем на стикеры и приклеиваем ниже.</li>
</ol>
<p>Если соединить все стикеры стрелками, то получится дерево текущей реальности (<a href="https://bipulse.ru/app/dictionary/docs/дерево%20текущей%20реальности">ДТР</a>). Это один из инструментов Теории Ограничений Систем для поиска причин. То есть выявления ЧТО менять.</p>
<p>Однако, чтобы выбирать модель воздействия лучше всего иметь факты в виде цифр или наглядной картинки, а не домыслов.</p>
<p>Цифры можно вынести на ретроспективу спринта, для обсуждения ситуации, или использовать с личном разговоре.</p>
<p>Например:</p>
<p><em>"Отдел тестирования стал медленней работать"</em> - это утверждение пригодное для общего анализа, но не пригодное для принятия решения. Гораздо лучше: <em>"В начале проекта задача висела в тестировании 5 дней, сейчас 2 месяца, почему так?"</em></p>
<p><img src="https://bipulse.ru/dotclear/public/.performance-tasks-length_m.png" alt="performance-tasks-length.png" style="display:table; margin:0 auto;" title="Тестирование долго, почему?" /></p>
<p>или вместо <em>"Вася стал плохо работать"</em> :
<em>"Раньше Вася делал 5 задач в неделю, а в последние два месяца, только 2 задачи. Что-то произошло?"</em></p>
<p><img src="https://bipulse.ru/dotclear/public/.performance-tasks-count_m.png" alt="performance-tasks-count.png" style="display:table; margin:0 auto;" title="Скорость выполнения задач снизилась, почему?" /></p>
<h3>Получаем цифры</h3>
<h4>Вариант первый - дешево и сердито</h4>
<p>Самый простой способ получить какую-то осмысленную метрику это, рассчитать вручную на основании отчетов, количество закрытых задач в прошлом месяце и в текущем.</p>
<p>Плюсы:</p>
<ul>
<li>Работает всегда</li>
<li>Сделать относительно просто.</li>
</ul>
<p>Минусы:</p>
<ul>
<li>Использовать общую цифру надо осторожно, если исполнитель был занят на других проектах или делал еще что-то, то можно получить возражение "А я еще Николаю с тестированием помогал, и ревью кода делал, знаешь сколько их было сделано?"</li>
</ul>
<p>Это следует учитывать. Иначе преждевременные обвинения могут поставить вас в неудобное положение.</p>
<h4>Вариант второй - это же Agile команда</h4>
<p>Если команда работает по Scrum / <a href="https://bipulse.ru/blog/index.php?tag/Agile">Agile</a> / XP то основной метрикой такой команды является скорость реализации задач. Поэтому руководитель проекта (которого быть и должно, но он есть) может не вдаваться в подробности, и взять скорость работы команды как "количество всех задач" за календарный месяц и вручить эту цифру команде, чтобы сами разбирались.</p>
<p>Плюсы:</p>
<ul>
<li>Не нужно общаться с каждым и выяснять причины, и получать возражения.</li>
</ul>
<p>Минусы:</p>
<ul>
<li>Это перекладывание с больной головы на здоровую, команде задачи решать надо, а не искать проблемы производительности. Такое пожелание руководителя может просто отложиться в долгий ящик.</li>
</ul>
<h4>Вариант третий - дотошный</h4>
<p>Если предыдущие варианты явно не очень годятся, то начинаем сами собирать <a href="https://bipulse.ru/blog/index.php?tag/%D0%A1%D1%82%D0%B0%D1%82%D0%B8%D1%81%D1%82%D0%B8%D0%BA%D0%B0">метрики</a> задач.</p>
<p>Разбираем по косточкам каждую задачу:</p>
<ul>
<li>Кто что и сколько сделал.</li>
<li>Сколько раз задача возвращалась из тестирования.</li>
<li>Сколько задача "висела" в каждой фазе</li>
</ul>
<p>Плюсы:</p>
<ul>
<li>Будет детальная картинка затрат каждого участника команды</li>
<li>Можно будет избежать встречных возражений "А я еще..."</li>
</ul>
<p>Минусы:</p>
<ul>
<li>Если делать вручную, то требует уйму времени. Однако, решаемо, об этом следующий раздел.</li>
</ul>
<h3>К чему всё это</h3>
<p>Как я уже писал выше, самое идеальное, это использовать в ретроспективе проекта и анализе точные цифры. Потому, что менять можно только то, что можно измерить. А чтобы измерения командных метрик не были проблемой, мы выпустили обновление <a href="http://bipulse.ru">BIPULSE</a>.</p>
<p>Данное обновление помогает руководителю проекта</p>
<ul>
<li>Понять, из-за чего проект отклоняется от графика.</li>
<li>Определить "бутылочное горлышко" в команде.</li>
<li>Выявить причины увеличения времени работы над задачей.</li>
<li>Акцентировать внимание команды на увеличении скорости прохода(lead time)</li>
</ul>
<p>За счет того что:</p>
<ul>
<li>Дополнительная детализация по Активностям позволяет видеть все перебрасывания задач между тестированием и разработкой.</li>
<li>Визуализация активностей на календаре позволяет быстро найти проблемные задачи и выработать стратегию, чтобы такого в будущем не повторялось.</li>
</ul>
<p>И для того чтобы это всё попробовать, Вам не нужно приобретать продукт, мы всё ещё даем 60 дней бесплатного пользования.
Загрузите свой проект в <a href="http://bipulse.ru">BIPULSE</a> из вашего трекера Jira или YouTrack (и много других). Если возникли вопросы по внедрению и интеграции пишите нам info@bipulse.ru или звоните по телефону +7(812) 408-19-78.</p>
<p>Следите за нами в сетях</p>
<ul>
<li><a href="https://www.facebook.com/bipulsetool/">Facebook</a></li>
</ul>
<p>И держите руку на <a href="http://bipulse.ru">Пульсе</a></p>