По порядку:
Ещё придумывать всегда стоит, вдруг что-то интересное раскопается

Внутренние юзеры довольны - имею ввиду удовлетворяется потребность, следовательно у них нет блокеров чтобы выполнять свою работу, например

Про сравнение с уже существующим, согласен, спасибо! А что если такого на рынке то и нет, например, всё очень контекстно специфичное.

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

Если у вас вопрос об показателе успешности возник ПОСЛЕ сбора команды, постановки задач и их выполнения - поздравляю, вы полностью про..бались с управлением

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

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

Ээээ, ну это совсем плохая бизнес-метрика. У вас своего рода вендер-лок на внутренние продукты, то есть вы вместо того чтобы мерить полезность продукта, будете измерять необходимость его использования. Это никак с качеством не коррелируют.

1. По каждой задаче должен быть определен definition if done. Это было сделано? Если да - можно объективно понять, выполнена ли задача. Если нет - вы про..бали управление.

2. По каждой задаче должна быть предварительная и согласованная оценка себестоимости. Если есть, то можно объективно понять, попали мы в нее или нет, превышен расход бабла или наоборот, вышла офигенная экономия. Если нет - вы про..бали управление!

3. По каждой задаче должно быть дизайн-ревью. То есть ответ на вопрос "как решать будем?" Сделано? Значит можно сравнить план с фактом. Не сделано - см. выше про потерю управления.

1. По каждой задаче должен быть определен definition if done. Это было сделано? Если да - можно объективно понять, выполнена ли задача. Если нет - вы про..бали управление.

2. По каждой задаче должна быть предварительная и согласованная оценка себестоимости. Если есть, то можно объективно понять, попали мы в нее или нет, превышен расход бабла или наоборот, вышла офигенная экономия. Если нет - вы про..бали управление!

3. По каждой задаче должно быть дизайн-ревью. То есть ответ на вопрос "как решать будем?" Сделано? Значит можно сравнить план с фактом. Не сделано - см. выше про потерю управления.