Посоветуйте метрики поставщиков в части Agile?

1
0
-1

Как мерить смешенные (внутренние и внешние разработчики) команды, которые работают по Agile?

Более подробно:

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

Наша компания в рамках закупочных процедур (в данном случае привлечение поставщика ИТ-услуг) проводит конкурс. По победителю и по всем остальным поставщикам, с кем мы уже работаем, раз в месяц даётся оценка по заранее определенным КПЭ (единые для всех). В зависимости от результатов КПЭ, поставщику присваивается итоговая классификация и определяется тренд (восходящий, без изменений, на понижение) относительно предыдущего месяца. Тем поставщикам, которые на протяжении нескольких месяцев показывают негативный тренд, присваивается понижающий коэффициент на следующем конкурсе (тут нужно пояснить, с точки зрения ФАС, мы не можем вообще запретить кому либо участвовать в конкурсе, но на основании объективных КПЭ, можем впаять понижающий коэффициент).

Проблема заключается в том, что мы от waterfall'a переходим к Agile и нам нужны соответствующие объективные показатели (это важно, ибо субъективные показатели можно оспорить и ФАС их не одобрит.

Вопрос, какие показатели/метрики (КПЭ) поставщиков использовать при Agile? Объективные и которые меряют работу поставщика, а не всей команды?

587 просмотров.
Answer

Комментарии

А каким образом это в waterfall'е решить, не совсем понятно?

- lulabot - 5 месяцев назад.

Таймшиты, из которых понятен план и факт + Ответственный за задачу. Накладываешь фильтр по внешним ресурсам и готово. Предварительно определяешь кпэ, по которым меряешь поставщика. Например отклонение по времени, по количеству выполненных работ и т.д.

Это объективные кпэ, публикуешь в конкурсной документации методику расчёта кпэ, допустимые отклонения и ФАС пропускает.

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

- Grabber - 5 месяцев назад.
1 ответ

1
0
-1

Что если мерить на уровне задач? Оценка трудозатрат дана, сколько по факту затрачено - тоже известно. Человек мог сделать 3 задачи из фичи, в которой 12 задач, и все равно можно человека оценить. Тогда неважно, когда задача появилась, в начале спринта или посередине.

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

Как вариант ещё проводить изменения, но это не Agile.

Комментарии

Так мы и пытаемся мерять на уровне задач. Т.е. предлагается по завершению спринта, корректировать план и уже от скорректированного мерять? (Была такая мысль)

Спринт 2 недели, классическое изменение просто не актуально, т.к. ты, как заказчик, сможешь в текущем спринте исключить задачу, а через две недели вставить новые.

Как вы проводите ретроспективный анализ?

- Grabber - 5 месяцев назад.

Ретроспективный анализ, это субъективная оценка, необходимая для понимания, где подтянуться))) а нам субъективная оценка не подходит - ФАС

- Grabber - 5 месяцев назад.

Похожие вопросы

Agile Просмотров: 174 Голосов: 1 Ответов: 2
Agile Просмотров: 161 Голосов: 1 Ответов: 1
Agile+ 1 ещё Просмотров: 144 Голосов: 0 Ответов: 0