Подскажите, как рассчитать трудоемкость программистов и сисадминов?
Есть организация, и в ней IT-отдел, порядка 20 человек. Человек 5 занимаются написанием мелких вещей, облегчающих жизнь остальных сотрудников организации (сравнить 2 таблицы, сделать автоматическое формирование отчета из какой-либо системы и т.п. Все задачи в основном больше 1 дня не занимают). Они же сопровождают информационные системы — добавить туда-то пользователя, установить БД для комплекса и т.д. Пара человек выполняют роль сисадминов.
Как подсчитать-то их трудоемкость? Это к вопросу — доказать руководству, что численности не хватает, или наоборот, что её в избытке (но это показывать не надо=)). Измерять в написанных строчек кода? Так там не только написание, а и просто в визуальном интерфейсе есть задачи которые делаются. Или для сисадминов исходить из количества обслуживаемых рабочих станций и серверов? В общем, такая вот задача интересует...
Здравствуйте, symantis, Вы писали:
S>Подскажите, как рассчитать трудоемкость программистов и сисадминов? S>Есть организация, и в ней IT-отдел, порядка 20 человек. Человек 5 занимаются написанием мелких вещей, облегчающих жизнь остальных сотрудников организации (сравнить 2 таблицы, сделать автоматическое формирование отчета из какой-либо системы и т.п. Все задачи в основном больше 1 дня не занимают). Они же сопровождают информационные системы — добавить туда-то пользователя, установить БД для комплекса и т.д. Пара человек выполняют роль сисадминов. S>Как подсчитать-то их трудоемкость? Это к вопросу — доказать руководству, что численности не хватает, или наоборот, что её в избытке (но это показывать не надо=)). Измерять в написанных строчек кода? Так там не только написание, а и просто в визуальном интерфейсе есть задачи которые делаются. Или для сисадминов исходить из количества обслуживаемых рабочих станций и серверов? В общем, такая вот задача интересует...
Отдел состоит из 20 человек, следовательно, организация имеет численность не менее 500. Организация такого размера не может работать без системы трекинга запросов, следовательно, трекинг есть. В форме трекера есть поле, куда ставятся плановая и фактическая трудоемкости. Вписываете туда значения фактической, а потом считаете ее автоматом. Делите на количество занятых в запросах людей и получаете загрузку. Если она превышает 50 часов в неделю — пора идти к шефу с цифрами в руках, это гораздо более сильный аргумент, чем восклицание "Ну не хватает же людей, я вам сто раз говорил!"
Можно пойти и другим путем. В трекере есть незакрытые запросы. Если их число ежедневно растет — строится график динамики роста запросов за месяц и кладется на стол шефу. После чего предлагается добавить людей или корректировать SLA — соглашение об уровне сервиса. Собственно, я бы начал с последнего — в случае недовольства (письменно зафикированным) уровнем сервиса вы получите в организации массу союзников, которые сами будут просить ваше руководство набрать вам еще людей. Вы же, белый и пушистый, стоите в сторонке и лишь киваете с печальным видом.
Одно важное условие — через запросы в трекер делается абсолютно все, что требует более 5-10 минут. Нет запроса — нет реакции. Если это не так, то все вышенаписанное не имеет смысла.
И это все очень, очень сильно упрощено. Есть ITIL, смотрите туда.
Здравствуйте, symantis, Вы писали:
S>Как подсчитать-то их трудоемкость? Это к вопросу — доказать руководству, что численности не хватает, или наоборот, что её в избытке (но это показывать не надо=)). Измерять в написанных строчек кода? Так там не только написание, а и просто в визуальном интерфейсе есть задачи которые делаются. Или для сисадминов исходить из количества обслуживаемых рабочих станций и серверов? В общем, такая вот задача интересует...
Для ваших целей достаточно посчитать velocity.
При отсутствии системы учета работ (issue tracker), заведите ее. В ней, считайте количество входящих тикетов (среднее количество запросов на работу в неделю/месяц), и среднее количество их убывания (темп разрешения тикетов).
При превышении темпа появления запросов над темпом их разрешения, надо расширять команду.
Здравствуйте, nvb, Вы писали:
nvb>Отдел состоит из 20 человек, следовательно, организация имеет численность не менее 500. Организация такого размера не может работать без системы трекинга запросов, следовательно, трекинг есть. В форме трекера есть поле, куда ставятся плановая и фактическая трудоемкости.
Дедуктивный метод, однако. Дайте и мне проявить дедукцию. Ммм... Вы недавно посмотрели "Шерлока Холмса" с Дауни младшим в главной роли, коллега? Как вам кино?
Здравствуйте, Gaperton, Вы писали:
G>При отсутствии системы учета работ (issue tracker), заведите ее. В ней, считайте количество входящих тикетов (среднее количество запросов на работу в неделю/месяц), и среднее количество их убывания (темп разрешения тикетов). G>При превышении темпа появления запросов над темпом их разрешения, надо расширять команду.
Я думаю все глубже. Превышение темпа появления запросов над темпом их разрешения может обозначать что команда работает неэффективно (с низкой производительностью) и решать проблему надо другими методами, а не обязательно расширением.
Здравствуйте, MozgC, Вы писали:
G>>При отсутствии системы учета работ (issue tracker), заведите ее. В ней, считайте количество входящих тикетов (среднее количество запросов на работу в неделю/месяц), и среднее количество их убывания (темп разрешения тикетов). G>>При превышении темпа появления запросов над темпом их разрешения, надо расширять команду. MC>Я думаю все глубже. Превышение темпа появления запросов над темпом их разрешения может обозначать что команда работает неэффективно (с низкой производительностью) и решать проблему надо другими методами, а не обязательно расширением.
Правильно мыслите. Еще вариант действия — применить правило value/cost при приоретизации запросов в такой ситуации. Итого — всего три варианта действия при указанном симптоме.
Triage (pronounced /ˈtriɑʒ/) is a process of prioritizing patients based on the severity of their condition. This rations patient treatment efficiently when resources are insufficient for all to be treated immediately. The term comes from the French verb trier, meaning to separate, sort, sift or select.[1] There are two types of triage: simple and advanced.[2] The outcome may result in determining the order and priority of emergency treatment, the order and priority of emergency transport, or the transport destination for the patient, based upon the special needs of the patient or the balancing of patient distribution in a mass-casualty setting.
Начинать с управления приоритетами. Даст немедленный эффект.
Продолжать — оптимизацией процесса разрешения issues. Включая замену персонала. Тонкая и скользкая тема. Эффекта, скорее всего, не даст. Тонкая работа, зависит в основном от личности того, кто ее проводит. Учить бесполезно.
Заканчивать — расширением группы поддержки. Может дать эффект, если с умом.
Здравствуйте, Gaperton, Вы писали:
nvb>>Отдел состоит из 20 человек, следовательно, организация имеет численность не менее 500. Организация такого размера не может работать без системы трекинга запросов, следовательно, трекинг есть. В форме трекера есть поле, куда ставятся плановая и фактическая трудоемкости.
G>Дедуктивный метод, однако. Дайте и мне проявить дедукцию. Ммм... Вы недавно посмотрели "Шерлока Холмса" с Дауни младшим в главной роли, коллега? Как вам кино?
Кино, увы, не смотрел — не люблю, в кинотеатр только ребенка выгуливаю. Мне сюжетов из жизни пока хватает
Но вы разбередили струны следопыта в моей душе И я посмотрел на эту ветку сверху. Интересно получается — мы говорим почти одно и то же про одно и тоже, но:
1. Раньше я выражался "умными словами" (с)Gaperton, а вы объяснялись простыми. Теперь наоборот.
2. Раньше я делал упор на "зачем", а вы на "как". В этой ветке мы поменялись акцентами.
Лично меня это радует — оказывается, мы чему-то научились друг у друга
S>Подскажите, как рассчитать трудоемкость программистов и сисадминов?
Простите мою педантичность, но трудоемкость — величина, относящаяся к какой-либо операции, либо единице продукта труда.
Не знаю смысла "трудоемкости программиста", есть, например, "трудоемкость установки винды".
nvb>Одно важное условие — через запросы в трекер делается абсолютно все, что требует более 5-10 минут. Нет запроса — нет реакции. Если это не так, то все вышенаписанное не имеет смысла.
Полнотью согласен, но вот тут добавлю: не важно сколько требует — все в трекер! При не четких условиях будут споры. А требование наличие заявки — очень четкое условие.
Здравствуйте, nvb, Вы писали:
nvb>Но вы разбередили струны следопыта в моей душе И я посмотрел на эту ветку сверху. Интересно получается — мы говорим почти одно и то же про одно и тоже, но: nvb>1. Раньше я выражался "умными словами" (с)Gaperton, а вы объяснялись простыми. Теперь наоборот. nvb>2. Раньше я делал упор на "зачем", а вы на "как". В этой ветке мы поменялись акцентами.
nvb>Лично меня это радует — оказывается, мы чему-то научились друг у друга
Но кое-что осталось постоянным. Вы все еще делаете слишком много предположений, чтобы потом положиться на них при ответе. В данном случае — хорошо, что вы явно отделяете предположения от фактов.
Второе. Вопрос был про трудоемкость — вы отвечаете как ее посчитать. В целом, правильно отвечаете, хорошо.
Но в данном случае слишком прямолинейно. Почему. Управлять через трудоемкость активностью, которая
1) хаотична по своей природе (поддержка, хелпдески, и т.д.), и
2) состоит из большого количества относительно несвязанных и небольших по затратам тикетов
методологически неправильно.
В данном случае более правильно применять методы, основанные на количестве самих тикетов, и средних темпах их появления/исправления. Что можно найти по ключевым словам velocity, burn-up chart, burn-down chart. Это
1) Гораздо проще делать чисто технически, и
2) Гораздо нагляднее.
3) Позволяет делать все то же самое. В том числе — сроки предсказывать.
"Умные слова" я в данном случае употребил только потому, что мне лень было писать развернутый ответ. Их употребление позволяет сделать ответ короче.
ЗЫ: Фильм с Дауни получился не очень, на мой вкус. Хотя вполне мило .
Здравствуйте, Gaperton, Вы писали:
G>В данном случае более правильно применять методы, основанные на количестве самих тикетов, и средних темпах их появления/исправления. Что можно найти по ключевым словам velocity, burn-up chart, burn-down chart. Это
Кстати, если продолжать умные слова. На эту тему есть прикольная и полезная математика из неожиданной области — управления коллцентрами. Все детально проработано, и разложено по полкам, причем — есть и в варианте для тупых, что особенно ценно. Формулы Эрланга, упомянутый вами уровень сервиса, и все такое. Практически полностью переносится на поддержку.
К примеру, важным показателем работы коллцентра является среднее время ожидания в очереди. И матаппарат позволяет связать это время с прочими показателями, — в частности, количеством персонала. Прикол в том (и это видно на моделях, и на реальной статистике), что среднее время ожидания растет скачкообразно и резко, когда в коллцентре становится на одного человека меньше определенного порога. Этот порог точно рассчитывается формулами. К слову о количестве людей в группе поддержки .
Еще один момент, обычный для коллцентра, и которого я никогда не видел в трекерах запросов. Считается хорошим тоном автоматически прогнозировать время ожидания выполнения запроса (на основании данных о velocity и длине очереди), и сообщать его пользователю. Это сильно повышает его, пользователя, удовлетворенность, и снижает процент отказов — люди готовы ждать.
Современные коллцентры работают не только со звонками, но и с электронной почтой, и с чатами, и с instant messaging. И называются "контакт-центры".
Не знаю насчет ITIL, может оно все и там то же самое, но мне почему-то кажется, что в книгах про коллцентры изложение будет более доступно. Все эти процессные стандарты разрушают мозг.
Уф..
Чтобы внедрить весь этот расчет, подбить практикой эту теорию, а самое главное — научно показать и рассказать шефу в виде красивой презентации с формулами, графиками — этож мне надо специалиста выделить и чтоб он только и занимался этим анализом...
Хотя, наверное, стоит попробовать.
По сути. Заявки от внутренних пользователей конечно существуют, правда не по всем задачам и не в электронном виде, так, макет заявки на бумаге. Правда, все это заведено под систему менеджмента качества, процессный подход и всё такое... еще бы это всё приносило ощутимые плоды...
Здравствуйте, Gaperton, Вы писали:
nvb>>Лично меня это радует — оказывается, мы чему-то научились друг у друга
G>Но кое-что осталось постоянным. Вы все еще делаете слишком много предположений, чтобы потом положиться на них при ответе. В данном случае — хорошо, что вы явно отделяете предположения от фактов.
И в этом мы тоже поменялись местами Помнится, я как раз за это вас упрекал в ветке про 1С
G>Второе. Вопрос был про трудоемкость — вы отвечаете как ее посчитать. В целом, правильно отвечаете, хорошо.
G>Но в данном случае слишком прямолинейно. Почему. Управлять через трудоемкость активностью, которая G>1) хаотична по своей природе (поддержка, хелпдески, и т.д.), и G>2) состоит из большого количества относительно несвязанных и небольших по затратам тикетов G>методологически неправильно.
А какая разница?
Если взять книгу Джоэла "И снова о программировании" — там описано Evidence-based sheduling планирование. В частности, там учитывается такая штука как непредвиденные случайности. То есть если в процессе работы к программисту подошел шеф и в течение пары часов распространялся о рыбалке в выходные, можно записать эту пару часов в накладные расходы, но правильнее записать их в задачу. Ибо в оценке следующей группы задач хорошо учитывать вероятность того, что шеф подойдет к вам с этим еще раз, а нам ведь надо при оценке иметь реальное, а не идеальное время выполнения задачи.
Все это сильно упрощенно, конечно — у Джоэла это излагается на десятке страниц.
Так и здесь. Да, хаос — но имеющий в сумме вполне приличный объем и свое матожидание. Их можно и нужно вычислять и учитывать в планировании.
Другое дело, что учесть можно не все — например, звонки по минуте-две, тут больше времени займет тикет создавать и трекать его. Ну что же, не удастся добиться идеальной точности.
G>ЗЫ: Фильм с Дауни получился не очень, на мой вкус. Хотя вполне мило .
Здравствуйте, symantis, Вы писали:
S>Уф.. S>Чтобы внедрить весь этот расчет, подбить практикой эту теорию, а самое главное — научно показать и рассказать шефу в виде красивой презентации с формулами, графиками — этож мне надо специалиста выделить и чтоб он только и занимался этим анализом... S>Хотя, наверное, стоит попробовать.
Да, пора уже Иначе так и будет продолжаться вечный диалог с шефом:
— Иван Иваныч, люди зашиваются! Дайте хоть двоих еще...
— Людей тебе еще? Как не выйду на лестницу — стоят по пятеро, дым коромыслом и анекдоты травят!
S>По сути. Заявки от внутренних пользователей конечно существуют, правда не по всем задачам и не в электронном виде, так, макет заявки на бумаге. Правда, все это заведено под систему менеджмента качества, процессный подход и всё такое... еще бы это всё приносило ощутимые плоды...
А мы-то тут, блин, спорим... ITIL, колл-центр, статистика запросов
Здравствуйте, symantis, Вы писали:
S>Подскажите, как рассчитать трудоемкость программистов и сисадминов? S>Есть организация, и в ней IT-отдел, порядка 20 человек. Человек 5 занимаются написанием мелких вещей, облегчающих жизнь остальных сотрудников организации (сравнить 2 таблицы, сделать автоматическое формирование отчета из какой-либо системы и т.п. Все задачи в основном больше 1 дня не занимают). Они же сопровождают информационные системы — добавить туда-то пользователя, установить БД для комплекса и т.д. Пара человек выполняют роль сисадминов. S>Как подсчитать-то их трудоемкость? Это к вопросу — доказать руководству, что численности не хватает, или наоборот, что её в избытке (но это показывать не надо=)). Измерять в написанных строчек кода? Так там не только написание, а и просто в визуальном интерфейсе есть задачи которые делаются. Или для сисадминов исходить из количества обслуживаемых рабочих станций и серверов? В общем, такая вот задача интересует...
Имею схожую ситуацию.
Куча внутренних отделов — куча заявок на дописывание или создание с нуля всяких хотелок(мелких) в различных инф.системах нашей структуры.
Пока все было тихо и спокойно учета этих заявок не велось.Как только возникли конфликтные ситуации между поддержкой и сотрудниками.
Что-то вроде: Мы же Вам говорили еще два дня назад, а Вы ни чего не сделали или сделали не так как говорили.
Все задачи, кроме консультаций, стали приниматься в электронном виде(меня ставят в копию) по почте+попросил руководителей отделов написать(тоже в электронном виде) основные хотелки их отделов.Завел все это в todo-list расставил приоритеты и исполнителей.Те кто занимается выполнением хотелок проставили предполагаемые сроки+дописали подзадачи к каждой задачке.Получился некий план на ближайший месяц.
Какие плюсы:
— выявились однотипные задачи от разных пользователей
— появился контроль над исполнителями
— заявки стали формализованные(то есть, что пишут, то и получают, а не то как мы там додумали со слов)
Минусы
— все заявки заводятся руками(на начальном этапе это жутко не удобно,затем количество хотелок уменьшилось в разы, поэтому заводить их не так трудно)
— Некоторые люди упорно не хотят оформлять свои заявки в письменном виде.
— в todo-list есть не все что хотелось бы, то есть надо смотреть на более взрослую систему учета заявок(хотя для таких маленьких как мы в полне подходит
G>В данном случае более правильно применять методы, основанные на количестве самих тикетов, и средних темпах их появления/исправления. Что можно найти по ключевым словам velocity, burn-up chart, burn-down chart. Это
Помнится, пару лет назад, когда я работал в другой фирме всему нашему отделу регулярно выговаривали за низкую производительность по сравнению с соседним. Пока они решали 5 заявок, мы одну.
На то, что у них типичная заявка называлась "расширить поле редактирования", а у нас "создать подсистему", никто не смотрел.
При этом ПМ у нас был один на всех.
Здравствуйте, VGn, Вы писали:
G>>В данном случае более правильно применять методы, основанные на количестве самих тикетов, и средних темпах их появления/исправления. Что можно найти по ключевым словам velocity, burn-up chart, burn-down chart. Это
VGn>Помнится, пару лет назад, когда я работал в другой фирме всему нашему отделу регулярно выговаривали за низкую производительность по сравнению с соседним. Пока они решали 5 заявок, мы одну. VGn>На то, что у них типичная заявка называлась "расширить поле редактирования", а у нас "создать подсистему", никто не смотрел. VGn>При этом ПМ у нас был один на всех.
Есть простое решение, если возникает столь редкая проблема — заполнять поле "Планируемая трудоемкость" при принятии заявки
Либо оно утверждается автором заявки в переговорах, либо автор получает бесплатный совет, куда идти со своей заявкой
При вопросах о производительности начальника тыкают носом в значение этого поля.
Здравствуйте, linker, Вы писали:
L>Имею схожую ситуацию. L>Куча внутренних отделов — куча заявок на дописывание или создание с нуля всяких хотелок(мелких) в различных инф.системах нашей структуры. L>Пока все было тихо и спокойно учета этих заявок не велось.Как только возникли конфликтные ситуации между поддержкой и сотрудниками. L>Что-то вроде: Мы же Вам говорили еще два дня назад, а Вы ни чего не сделали или сделали не так как говорили. L>Все задачи, кроме консультаций, стали приниматься в электронном виде(меня ставят в копию) по почте+попросил руководителей отделов написать(тоже в электронном виде) основные хотелки их отделов.Завел все это в todo-list расставил приоритеты и исполнителей.Те кто занимается выполнением хотелок проставили предполагаемые сроки+дописали подзадачи к каждой задачке.Получился некий план на ближайший месяц. L>Какие плюсы: L> — выявились однотипные задачи от разных пользователей L> — появился контроль над исполнителями L> — заявки стали формализованные(то есть, что пишут, то и получают, а не то как мы там додумали со слов)
Ежики плакали, кололись, но продолжали кушать кактус Извините, но именно эта фраза приходит в голову
Ставите на сервер любой бесплатный трекер — bag, issue. Инсталляторы сейчас настолько примитивные, что даже я могу поставить Заводите в нем базу сотрудников — это еще легче.
И дальше:
L>Минусы L> — все заявки заводятся руками(на начальном этапе это жутко не удобно,затем количество хотелок уменьшилось в разы, поэтому заводить их не так трудно)
Это, вообще говоря, нехорошо. Цель поддержки — помогать сотрудникам, а не искать способ послать их поизощренней. Другое дело, что при написании заявки человек обычно подробно описывает проблему и к концу ее описания в большинстве случаев уже сам находит решение. Это и есть причина уменьшения количества заявок.
L> — Некоторые люди упорно не хотят оформлять свои заявки в письменном виде.
Принимайте по телефону и заносите в трекер сами. И автора заявки ставьте сами. Ничего страшного тут нет, если только религиозные соображения не мешают. Трекер автоматом отсылает юзеру письмо с текстом заявки.
А вообще принято писать инструкцию и на вопль "Мне не понятно, как заполнять заявку" — просите показать конкретное непонятное место в инструкции. Во второй раз, как правило, уже не звонят.
L> — в todo-list есть не все что хотелось бы, то есть надо смотреть на более взрослую систему учета заявок(хотя для таких маленьких как мы в полне подходит
В этой конфе пробегало сообщение со ссылкой на полную страницу с названиями этих трекеров. Ищите и обрящете. В крайнем случае, наберите запрос в Гугле, хотя и поступите совершенно не по-русски
Здравствуйте, nvb, Вы писали:
nvb>Есть простое решение, если возникает столь редкая проблема — заполнять поле "Планируемая трудоемкость" при принятии заявки nvb>Либо оно утверждается автором заявки в переговорах, либо автор получает бесплатный совет, куда идти со своей заявкой
nvb>При вопросах о производительности начальника тыкают носом в значение этого поля.
А смысл? "Средняя трудоемкость задания" = Период (скажем, месяц) * количество человек / количество закрытых заданий за период (тоже за месяц).
И зачем его заполнять, если его и так можно посчитать? Ну "ткнете вы носом" кого-то в цифру, которую сами и придумали. Что это изменит?
