Посоветуйте метрики поставщиков в части Agile?
Как мерить смешенные (внутренние и внешние разработчики) команды, которые работают по Agile?
Более подробно:
У нас в гос.компании (вид деятельности - финансовые услуги, банк) существует направление деятельности - управление поставщиками. Управлять поставщиками необходимо с целью повышения качества предоставляемых ими услуг. У нас собрана информация по каждому поставщику и все они объединены в портфель (необходимо для категоризации, классификации и оптимизации).
Наша компания в рамках закупочных процедур (в данном случае привлечение поставщика ИТ-услуг) проводит конкурс. По победителю и по всем остальным поставщикам, с кем мы уже работаем, раз в месяц даётся оценка по заранее определенным КПЭ (единые для всех). В зависимости от результатов КПЭ, поставщику присваивается итоговая классификация и определяется тренд (восходящий, без изменений, на понижение) относительно предыдущего месяца. Тем поставщикам, которые на протяжении нескольких месяцев показывают негативный тренд, присваивается понижающий коэффициент на следующем конкурсе (тут нужно пояснить, с точки зрения ФАС, мы не можем вообще запретить кому либо участвовать в конкурсе, но на основании объективных КПЭ, можем впаять понижающий коэффициент).
Проблема заключается в том, что мы от waterfall'a переходим к Agile и нам нужны соответствующие объективные показатели (это важно, ибо субъективные показатели можно оспорить и ФАС их не одобрит.
Вопрос, какие показатели/метрики (КПЭ) поставщиков использовать при Agile? Объективные и которые меряют работу поставщика, а не всей команды?
Что если мерить на уровне задач? Оценка трудозатрат дана, сколько по факту затрачено - тоже известно. Человек мог сделать 3 задачи из фичи, в которой 12 задач, и все равно можно человека оценить. Тогда неважно, когда задача появилась, в начале спринта или посередине.
Мы ретроспективный анализ делаем периодически даже без участия внешних ресурсов. И видно, кто ударник, а кто лажает.
Как вариант ещё проводить изменения, но это не Agile.
Комментарии
Так мы и пытаемся мерять на уровне задач. Т.е. предлагается по завершению спринта, корректировать план и уже от скорректированного мерять? (Была такая мысль)
Спринт 2 недели, классическое изменение просто не актуально, т.к. ты, как заказчик, сможешь в текущем спринте исключить задачу, а через две недели вставить новые.
Как вы проводите ретроспективный анализ?
Ретроспективный анализ, это субъективная оценка, необходимая для понимания, где подтянуться))) а нам субъективная оценка не подходит - ФАС
Похожие вопросы
Просмотров: 2,711
Голосов: 1
Ответов: 1
Комментарии
А каким образом это в waterfall'е решить, не совсем понятно?
Таймшиты, из которых понятен план и факт + Ответственный за задачу. Накладываешь фильтр по внешним ресурсам и готово. Предварительно определяешь кпэ, по которым меряешь поставщика. Например отклонение по времени, по количеству выполненных работ и т.д.
Это объективные кпэ, публикуешь в конкурсной документации методику расчёта кпэ, допустимые отклонения и ФАС пропускает.
Одна из основных проблем заключается в том, что команда берёт на себя задачи и решает их в рамках спринта, но в середине спринта появляется например более приоритетная задача или дефект, люди ломятся решать её или его, что логично. В итоге, команда не выполняет план, но решает важную задачу (что более ценно для бизнеса), а мы наказываем члена команды за то, что он ломанулся помогать решать приоритетную задачу.