Чтобы завести реквест нужно потратить 15 мин. Чтобы его реализовать- нужно не меньше дня.

У нас реализация недели по 1-3 на один реквест. Задачи на день - это скорее к починка аварий и подобное, но там надо просто починить скорее.

На счет метрик. Мы снимаем время выполнения задач в команде. Я могу сказать сколько времени ушло аналитику, кодинг на фиксы, развертывание и т.д в рамках проекта, его версии или на одну какую то задачу.

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

Оценка ЧЧ на проблемах.  Например, когда убираешь рутину, то  пишу скринкаст по повторяющейся операции. Затем  нахожу как узнать сколько этот сотрудник таких операций выполняет в день. Наблюдаю недельку. Ищу данные как рутина изменяется в рамках сезонности ну и много чего ещё проверяю. Иногда используются всякие логеры и прочее. Там много вариантов и много случаев как чего и в каком объемах измеряется. Я не занимался особо изучением этого вопроса по книжкам. М. б. есть какие то решения, но судя потому что у нас нет внедрений, с которых я бы мог взят эти параметры автоматически, мне придется делать это ручками.

На счет цифры в 50%/ 9 мес. было бы точнее.  Положа руку на сердце, это почти отфонарно. Я не знаю в какую сторону тут думать чтобы сформулировать эту цифру. Знаю, что смогу заметить её в графике по нашей метрике.  НА этом мысли заканчиваются.

При таком подходе функциональность ваших решений будет неуправляемо "разбухать"

Поддержка наших же решений нас действительно давит. Чем больше пишем, тем больше поддерживаем.  Я не понимаю, что значит "разбухает".

Кстати, с увеличением размера команды этот показатель, скорее всего, снизится

Я тоже думаю снизится. Но если команду настроить нормально, то вернется в обратное положение. Суть не в показателе. Увеличение команды мне поможет выйти на проекты поинтереснее где побольше интерфейсов, аналитики и прочее. Я примитивный. Люблю когда в работе есть вызов и когда вижу в лицах заказчиков радость от того что мы им заимплементили. Ненавижу бесполезную работу в стол. 

Многие задачи вообще не высвобождают ЧЧ, при том что они объективно полезны. Например, что-то направленное на улучшение клиентского сервиса

Согласен. Мой показатель показывает картину только на определенном круге задач, а не характеризует всю моею деятельность.

Про увеличение команды:
Есть у меня теория, что поток мелких реквестов обычно интересует бизнес только на
предмет занять чем-нибудь команду между деланием Больших Проектов, исправления багов и задачек, которые реально интересует топов. Сделает команда 30 мелких реквестов или 50 бизнес волнует очень мало. Для компании в целом они ничего принципиально не меняют - высвобожденные ЧЧ будут потрачены на ещё какую-нибудь малозначимую хрень - не только вам веселее работать в большой команде. Предположу, что именно поэтому эту задачу у вас заделегировали чуть ли не на уровень ИТ. Т.е. наращивание описываемого вами KPI - это плохое обоснование для увеличения команды. Лучше это обосновывается под какой-то проект который топам заметен.

Всё верно. На что потратят освобожденные ЧЧ решают другие люди.  Надеюсь что они хорошо решают.
Я не знаю как смотрят наши топы и на какие проекты. М.б им заметно только то, что у них с бизнесом всё ок или не ок.     

Если не получится с командой тут - перейду в другое место.  Буду там получать удовольствие от работы Я люблю аналитику и интерфейсы. Меня вполне устроило бы место в команде где всё решено и организовано до меня и без меня, когда можно идти и работать на благо компании/проекта.

Про процесс в целом:
Обслуживание маленьких реквестов дело принципиально неблагодарное. Чтобы завести реквест нужно потратить 15 мин. Чтобы его реализовать- нужно не меньше дня. Помножьте это на то что реквесты заводят потенциально все сотрудники организации, а делают сами знаете сколько программистов. Но т.к. человек альтруистично потратил свои 15 минут, на то чтобы сделать организацию лучше, а тупые бюрократы не оценили его порыв, то весь это процесс сопровождается плохими вибрациями. Истерики, письма президенту, разочарования итп. Ну и конечно же виноваты во всём неэффективные ИТшники, которые непонятно чем занимаются, вместо того чтобы тупо выполнить все реквесты в трекере.

Этот нехитрый расклад, рано или поздно понимают в большинстве организаций. Что, по моему опыту, с этим делается:
- Процесс создания реквеста максимально усложняется - нужно заполнить 100500 листов специальной хитрой формы, подсчитать хитрые показатели эффективности итд.
- Реквесты фильтруются путём утверждения по всей вертикали начальников подразделения, где работает заявитель.
- Реквесты фильтруются на входе в ИТ. Тут разные подходы я видел и слышал:
- Специальный комитет, который утверждает [план ближайших работ]. Чем более влиятельны его участники тем лучше. На моей прошлой работе туда даже CEO входил (компания среднего размера - ок.1000 сотрудников). Подразделения-заказчики защищают свои доработки перед Комитетом. CIO, естественно, был участником комитета.
- В большой компании, где я сейчас работаю, запросы поступают в особое бизнесовое Подразделение-Координатор, которое, среди всего прочего, курирует развитие нескольких взаимосвязанных систем. Подразделения-заказчики договариваются с менеджерами этого подразделения. Подразделение-координатор путём переговоров с ИТ, формирует скоуп следующего релиза системы.
- Слышал про систему жетонов. Подразделениям-заказчикам раздаются жетоны из каких-то общих соображений. Эти подразделения покупают на эти жетоны время ИТ-подразделения. Тут много подробностей не знаю, сам слышал только рассказы.
Вобщем, вопрос ранжирования, в том или ином виде, остаётся за бизнесом. И это прекрасно, с моей точки зрения.

Слушайте, а это очень полезная для меня информация. 
И теперь я пожалуй немного больше стал понимать что bas имел ввиду под Хабаровском.
 

Чтобы завести реквест нужно потратить 15 мин. Чтобы его реализовать- нужно не меньше дня.

У нас реализация недели по 1-3 на один реквест. Задачи на день - это скорее к починка аварий и подобное, но там надо просто починить скорее.

На счет метрик. Мы снимаем время выполнения задач в команде. Я могу сказать сколько времени ушло аналитику, кодинг на фиксы, развертывание и т.д в рамках проекта, его версии или на одну какую то задачу.

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

Оценка ЧЧ на проблемах.  Например, когда убираешь рутину, то  пишу скринкаст по повторяющейся операции. Затем  нахожу как узнать сколько этот сотрудник таких операций выполняет в день. Наблюдаю недельку. Ищу данные как рутина изменяется в рамках сезонности ну и много чего ещё проверяю. Иногда используются всякие логеры и прочее. Там много вариантов и много случаев как чего и в каком объемах измеряется. Я не занимался особо изучением этого вопроса по книжкам. М. б. есть какие то решения, но судя потому что у нас нет внедрений, с которых я бы мог взят эти параметры автоматически, мне придется делать это ручками.

На счет цифры в 50%/ 9 мес. было бы точнее.  Положа руку на сердце, это почти отфонарно. Я не знаю в какую сторону тут думать чтобы сформулировать эту цифру. Знаю, что смогу заметить её в графике по нашей метрике.  НА этом мысли заканчиваются.

При таком подходе функциональность ваших решений будет неуправляемо "разбухать"

Поддержка наших же решений нас действительно давит. Чем больше пишем, тем больше поддерживаем.  Я не понимаю, что значит "разбухает".

Кстати, с увеличением размера команды этот показатель, скорее всего, снизится

Я тоже думаю снизится. Но если команду настроить нормально, то вернется в обратное положение. Суть не в показателе. Увеличение команды мне поможет выйти на проекты поинтереснее где побольше интерфейсов, аналитики и прочее. Я примитивный. Люблю когда в работе есть вызов и когда вижу в лицах заказчиков радость от того что мы им заимплементили. Ненавижу бесполезную работу в стол. 

Многие задачи вообще не высвобождают ЧЧ, при том что они объективно полезны. Например, что-то направленное на улучшение клиентского сервиса

Согласен. Мой показатель показывает картину только на определенном круге задач, а не характеризует всю моею деятельность.

Про увеличение команды:
Есть у меня теория, что поток мелких реквестов обычно интересует бизнес только на
предмет занять чем-нибудь команду между деланием Больших Проектов, исправления багов и задачек, которые реально интересует топов. Сделает команда 30 мелких реквестов или 50 бизнес волнует очень мало. Для компании в целом они ничего принципиально не меняют - высвобожденные ЧЧ будут потрачены на ещё какую-нибудь малозначимую хрень - не только вам веселее работать в большой команде. Предположу, что именно поэтому эту задачу у вас заделегировали чуть ли не на уровень ИТ. Т.е. наращивание описываемого вами KPI - это плохое обоснование для увеличения команды. Лучше это обосновывается под какой-то проект который топам заметен.

Всё верно. На что потратят освобожденные ЧЧ решают другие люди.  Надеюсь что они хорошо решают.
Я не знаю как смотрят наши топы и на какие проекты. М.б им заметно только то, что у них с бизнесом всё ок или не ок.     

Если не получится с командой тут - перейду в другое место.  Буду там получать удовольствие от работы Я люблю аналитику и интерфейсы. Меня вполне устроило бы место в команде где всё решено и организовано до меня и без меня, когда можно идти и работать на благо компании/проекта.

Про процесс в целом:
Обслуживание маленьких реквестов дело принципиально неблагодарное. Чтобы завести реквест нужно потратить 15 мин. Чтобы его реализовать- нужно не меньше дня. Помножьте это на то что реквесты заводят потенциально все сотрудники организации, а делают сами знаете сколько программистов. Но т.к. человек альтруистично потратил свои 15 минут, на то чтобы сделать организацию лучше, а тупые бюрократы не оценили его порыв, то весь это процесс сопровождается плохими вибрациями. Истерики, письма президенту, разочарования итп. Ну и конечно же виноваты во всём неэффективные ИТшники, которые непонятно чем занимаются, вместо того чтобы тупо выполнить все реквесты в трекере.

Этот нехитрый расклад, рано или поздно понимают в большинстве организаций. Что, по моему опыту, с этим делается:
- Процесс создания реквеста максимально усложняется - нужно заполнить 100500 листов специальной хитрой формы, подсчитать хитрые показатели эффективности итд.
- Реквесты фильтруются путём утверждения по всей вертикали начальников подразделения, где работает заявитель.
- Реквесты фильтруются на входе в ИТ. Тут разные подходы я видел и слышал:
- Специальный комитет, который утверждает [план ближайших работ]. Чем более влиятельны его участники тем лучше. На моей прошлой работе туда даже CEO входил (компания среднего размера - ок.1000 сотрудников). Подразделения-заказчики защищают свои доработки перед Комитетом. CIO, естественно, был участником комитета.
- В большой компании, где я сейчас работаю, запросы поступают в особое бизнесовое Подразделение-Координатор, которое, среди всего прочего, курирует развитие нескольких взаимосвязанных систем. Подразделения-заказчики договариваются с менеджерами этого подразделения. Подразделение-координатор путём переговоров с ИТ, формирует скоуп следующего релиза системы.
- Слышал про систему жетонов. Подразделениям-заказчикам раздаются жетоны из каких-то общих соображений. Эти подразделения покупают на эти жетоны время ИТ-подразделения. Тут много подробностей не знаю, сам слышал только рассказы.
Вобщем, вопрос ранжирования, в том или ином виде, остаётся за бизнесом. И это прекрасно, с моей точки зрения.

Слушайте, а это очень полезная для меня информация. 
И теперь я пожалуй немного больше стал понимать что bas имел ввиду под Хабаровском.