Статьи об управлении проектами - 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>Оценка производительности командыurn:md5:f7157266735cf470fc755752664c434d2015-10-27T21:32:00+00:002015-11-17T11:38:05+00:00Алексей ВасильевПроизводительностьСкорость проходаСтатистика<p><img src="https://bipulse.ru/dotclear/public/.blog-performance-chart_s.png" alt="blog-performance-chart.png" style="float:left; margin: 0 1em 1em 0;" title="Ретроспектива проекта с точки зрения производительности команды" /> Иногда
может сложиться впечатление что ваша команда работает медленнее чем обычно. Это
может быть субъективное впечатление, а может быть и на самом деле так. Обычно
рекомендуют в таких случаях, для исправления ситуации, менеджеру проекта
поговорить с каждым участником команды..</p><p><img src="https://bipulse.ru/dotclear/public/.blog-performance-chart_s.png" alt="blog-performance-chart.png" style="float:left; margin: 0 1em 1em 0;" title="Ретроспектива проекта с точки зрения производительности команды" /> Иногда
может сложиться впечатление что ваша команда работает медленнее чем обычно. Это
может быть субъективное впечатление, а может быть и на самом деле так. Обычно
рекомендуют в таких случаях, для исправления ситуации, менеджеру проекта
поговорить с каждым участником команды..</p> <p>Но какие аргументы вы будете применять при общении с сотрудником? "Мне
показалось, что ты стал медленнее работать." аргумент не очень хороший.
Исполнитель вам возразит: "Да не, тебе только так кажется, шеф , у нас всё под
контролем" .</p>
<p>Тогда вы можете посчитать количество сделанных исполнителем задач за спринт,
и тогда ваш аргумент будет выглядеть так: "Смотри ты в прошлом спринте сделал
10 задач, а за последний только 7" , но это будет разбито возражением: "Шеф, у
тебя неверная информация, я же не только задачи делал, я еще проверял Васю, и
помогал тестировать Коле". С такими аргументами сложно спорить. Если у вас нет
цифр.</p>
<h3>Цифры</h3>
<p>Бывает три вида лжи: ложь, наглая ложь и статистика. Но как собрать
правильную статистику если ваш инструмент работы Jira, redmine, youtrack или
канбан доска?</p>
<p>Есть несколько вариантов:</p>
<ol>
<li>Самое простое решение отмечать сколько задач пришло к разработчику и ушло
от него вручную в эксельке или документе. Но я уверен, вам это надоест очень
быстро, да и нужно знать заранее что это будет нужно. А вопрос о
производительности стоит обычно в конце отчетного периода перед премией.</li>
<li>Поднять историю изменения задачи с вашего трекера задач или системы
отслеживания ошибок (bug tracking system). Да, вы можете это сделать, если
будете открывать каждую задачу и выписывать кто принял эстафету и в какой
статус перевел.</li>
<li>Использовать возможности BiPulse, импортировать проект и посмотреть на него
с точки зрения производительности команды.</li>
</ol>
<p><img src="https://bipulse.ru/blog/public/.blog-performance-chart_m.png" alt="blog-performance-chart.png" style="display:block; margin:0 auto;" title="Завершенные исполнителями задачи с точки зрения календаря в масштабе недели" /></p>
<h3>Настройка импорта активностей</h3>
<p>Чтобы правильно увидеть метрики производительности, нужно указать системе
соответствие между активностями сотрудников и статусами вашего баг-трекера.</p>
<p>Сейчас такая конфигурация задается только в виде JSON в параметрах
интеграции.</p>
<p>Для оптимального процесса в сфере разработки программного обеспечения это
может быть так :</p>
<pre>
{
"production" : {
"wait" : [ "Wait for decision"],
"plan" : ["Open", "Reopened"],
"inprogress" : ["In Progress", "Review", "Review complete"],
"complete_success" : ["Coding complite", "Won't Fix", "Duplicate"],
"complete_fail" : ["Cannot Reproduce", "Postponed"]
},
"coding" : {
"wait" : [],
"plan" : ["Open", "Reopened" ],
"inprogress" : ["In Progress"],
"complete_success" : ["Review"],
"complete_fail" : ["Cannot Reproduce", "Postponed"]
},
"review" : {
"wait" : [],
"plan" : [ "Review"],
"inprogress" : [ "In Review"],
"complete_success" : ["Review Complete"],
"complete_fail" : ["Reopened", "Open", "In Progress"]
},
"testing" : {
"wait" : [],
"plan" : ["Coding complete" ],
"inprogress" : ["Testing"],
"complete_success" : ["Closed", "Resolved", "Duplicate"],
"complete_fail" : ["Reopened", "Open", "Wait for decision"]
}
}
</pre>
<p>Это схема почти идеального процесса разработки софта, где есть:</p>
<ol>
<li>добавление идеи: <em>Wait for decision</em></li>
<li>постановка в план: <em>Open</em></li>
<li>работа над задачей от <em>In Progress</em> до <em>Review</em></li>
<li>рецензирование от <em>In Review</em> до <em>Review Complete</em></li>
<li>и тестирование которое начинается после всей работы над задачей:
<em>Testing</em></li>
</ol>
<p>Конфигурация позволяет настроить все участки производственного конвейера.
Однако, следует учесть, что первый шаг <em>production</em> является
специальным, он определяет "бутылочное горлышко" вашего конвейера по созданию
продукта. На основе этого шага рассчитываются метрики скорости выполнения
проекта.</p>
<p>Если у вас все шаги есть, в той или иной мере, то BiPulse сможет собрать
статистику и показать это с различных точек зрения:</p>
<ol>
<li>Сколько всего активностей исполнитель выполнил за день или неделю. Это
позволит понять в общих чертах, динамику производительности.</li>
<li>А чем какой именно активностью он занимался весь день или неделю? - он
делал мало кодирования потому что много рецензировал или есть другая
причина?</li>
<li>Полная детализация деятельности на календаре. С это точки зрения можно
выявить проблемные задачи которые слишком долго висели там где не положено
долго висеть.</li>
</ol>
<p>Ответы на каждый из этих вопросов может помочь Вам, как менеджеру найти
проблемы в проекте и выработать шаги по увеличению <a href="https://bipulse.ru/blog/index.php?tag/%D1%81%D0%BA%D0%BE%D1%80%D0%BE%D1%81%D1%82%D1%8C%20%D0%BF%D1%80%D0%BE%D1%85%D0%BE%D0%B4%D0%B0">
<em>скорости прохода</em></a>.</p>