Проблемы роста маленькой ИТ-команды: процессы или найм?

Надеюсь, что в комментариях вы подскажете мне, из какого учебника открываю я эту Америку: по экономике, менеджменту или по физике.

Бывают ведь маленькие (и не очень) ИТ-команды которые работают «на износ»? Высокая специализация труда, высокая нагрузка на каждого сотрудника. Заказчик очень ревностно относится к затратам на поддерживающие технологии, и требует максимальной отдачи от специалистов, и не приветствует расширение штата.

Руководитель такой команды, естественно, желает ее увеличить для того, чтобы обеспечить взаимозаменяемость и снизить стрессовую нагрузку на своих подчиненных. Поэтому он ищет управленческие инструменты, которые позволили бы доказать заказчику (владельцу, спонсору) необходимость инвестиций в увеличение числа сотрудников ИТ. Открыв для себя своды знаний по управлению ИТ-услугами, такой руководитель надеется, что объективную отчетность о трудовой нагрузке сможет дать ему процессная модель управления.

И вот тут я бы предостерег такого руководителя от резкого погружения в управление инцидентами, изменениями, далее везде.

Процессная модель управления подразумевает дополнительную нагрузку: на самого управленца (проектирование и реализация новых правил работы), а затем и на сотрудников.

Зрелые процессы как инструмент прозрачного измерения работы потребуют трудовых ресурсов. А где их взять, если и так все работают на пределе своих возможностей?!

У меня такая картинка и слова сложились после общения с подобной небольшой командой:

  • Процессы – это интенсивный способ повышения производительности ИТ-службы
  • Увеличение штата – это экстенсивный способ.

А последовательность выбора из этих двух должна быть строгой:

  1. Достигай предела интенсивного роста.
  2. Затем обеспечивай экстенсивный рост.
  3. Когда до предела производительности в имеющихся ресурсах есть еще немного места – вот тут для процессов самое время. Процессы позволят достигнуть предела производительности опять, т.е. вернуться на шаг 1.

Резюмирую: Новые ИТ-процессы не нужны тем ИТ-командам, в которых высока специализация труда и нагрузка на исполнителей.

Как вы думаете, коллеги, можно ли численно определить, сколько еще запаса времени, сил, желания должно оставаться во всё более нагружаемой ИТ-команде, чтобы успешно начать играть в ИТ-процессы?

COBIT Основы COBIT 5

Подробный трёхдневный учебный курс.
 

Узнайте больше!

Комментарии и мнения

  1. Станислав Уштей

    Процесс — это конвейер. Это собственно Ваша (Сleverics) позиция.

    «...сколько еще запаса времени, сил, желания должно оставаться...» — для конвейера этот вопрос неактуален.

    Другой вопрос — если скажем в деятельности этого коллектива намешаны и стратегические, и тактические, и операционные задачи и Все, с сияющими энтузиазмом глазами, делают все.

    Я бы сказал что времени уже не осталось — кому-то становиться лидером, превращая остальных в ресурс. и Ему-то принимать решения — на сколько для него эффективны «бездушные конвейеры»

    1. Константин Нарыжный Автор

      Станислав, конечно же конвейер. Но только на высоком уровне зрелости. А до него, в малой, специализированной команде, применимы и другие инструменты управления (как ниже Владимир написал), например, микроменеджмент, инструменты личностной мотивации сотрудников — вот всё то, что лидер должен уметь делать. Так что еще можно поспекулировать на тему того, что на конвейере лидер не нужен.

  2. Vladimir Ivanov

    Ну а для управления «конвейером» есть свои инструменты...

    Lean en.wikipedia.org/wiki/Lean_manufacturing

    Six Sigma en.wikipedia.org/wiki/Six_Sigma

    Поэтому я бы добавил, что более оптимального эффекта добьётся тот, кто применяет по контексту наиболее подходящие инструменты, а не слепо следует процессной модели управления.

    «...У англичан ружья кирпичом не чистят: пусть чтобы и у нас не чистили, а то, храни бог войны, они стрелять не годятся...»

  3. Вадим

    мне тезисы этой статьи кажутся весьма спорными. регулярно сталкиваясь с подобными командами, могу отметить, что специализация там как раз низкая (практически каждый должен уметь подменить товарища), а концентрация на операциях как раз высокая (т.е. не достает им управленческих целей, типа качества услуг, — не до этого, инциденты б вовремя отработать). а управленческие цели — как раз задача руководителя. и для этого он должен неплохо разбираться в том, какое место занимают ИТуслуги в работе заказчика.

    по-моему, отсюда и возникает проблема подмены понятий: что в данном случае будет улучшением деятельности? может мотив заказчика на экономию все-таки обоснован? и его устраивает фактическое качество услуг? а руководитель ИТ коллектива вместо того, чтобы оперировать рисками деградации этого качества, понятными заказчику, пытается повысить свою значимость как квалифицированного менеджера, добавив себе персонала? ))))

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

    1. Константин Нарыжный Автор

      Вадим, мне тоже кажутся спорными эти идеи, поэтому и пытаюсь их осмыслить с помощью обсуждения.

      Я писал о таких командах, как например: начальник, сисадмин, бизнес-аналитик (пишет ТЗ), программист 1С, телефонист. Возможность подмены в таком коллективе, согласитесь, ниже.

      > а руководитель ИТ коллектива вместо того, чтобы оперировать рисками деградации этого качества, понятными заказчику

      Руководитель как раз этими рисками и мотивирован на увеличение штата. Он, в отличие от заказчика, понимает, что вот-вот произойдет нечто, с чем его команда не справится — окажутся неспособны устранить сбой, или реализовать новую хотелку к «вчерашнему сроку». Как доказать заказчику, не запугивая его этими рисками — вот запрос руководителя, о котором я говорил. И об этом же вы пишете ниже: ему нужно собрать статистику. Объективность этой статистики и нормировку дадут ему процессы. Так ему кажется, по крайней мере.

      1. Вадим

        Тогда ладно))) соглашусь с этим )))

        Между прочим, много лет назад (блин, действительно уже много лет назад, еще до эпохи ITIL'а) я как раз работал в подобном коллективе и имел сомнительное счастье наблюдать ряд авралов, типа умирания сервера))) и пинания воздуха всем коллективом компании в течение недели (а может даже и более)... кончилось дело тем, что купили новый сервер и еще какое-то время потратили на его запуск и т.п.

        Так что, как видите, ситуация мне вполне знакома.

        В более близкие ITIL'овские времена, также неоднократно сталкивался с клиентами, у которых «те же десять айтишников», что и 5-10 лет назад, практически за ту же зарплату тащат кратно увеличенный объем работ. Так практически во всех подобных случаях что начальник ИТ, что сотрудники видят выход в автоматизации, а не в процессе (точнее только в автоматизированном процессе), для чего пытаются нарыть либо бесплатные, либо недорогие (типа Itilium'а и т.п. — не реклама) решения для работы с инцидентами и т.п. CFG и SLM рассматриваются редко. С управлением финансами, кстати, дела обстоят по-разному: кому-то я бы твердую «пятерку» поставил бы, а кто-то ни бе, ни ме, ни кукареку. А ведь это тот самый язык, с использованием которого нужно говорить с заказчиком.

  4. Роман Журавлёв

    Сразу несколько комментариев родилось.

    1. Не всякий процесс — конвейер. Конвейер — это предопределенные операции и минимум потерь между ними. Так не может работать, например, управление проблемами, во многих случаях — управление изменениями, иногда даже управление инцидентами (major incident review). Для всех этих процессов во многих случаях эффективнее модель «мастерская» — когда все, кто нужен, собираются вместе и вместе анализируют ситуацию, определяя следующие шаги.

    Мне кажется, что в заметке термин «процесс» указывает на степень формализации и контроля, а не на предопределенность цепочки получения результата. Поэтому и термин «конвейер», и соответствующие техники применимы к описываемой ситуации ограниченно.

    2. Что же до самой описанной ситуации, то, мне кажется, выбор у руководителя довольно обычный: риски-качество-цена. Работающая на износ команда профессионалов обеспечивает сравнительно высокое качество при сравнительно низких затратах и сравнительно высоком уровне риска: выпадет один специалист из системы — и не будет качества. Снижение уровня риска может быть достигнуто снижением нагрузки на каждого исполнителя и/или снижением зависимости от каждого исполнителя. В первом может помочь увеличение численности, во втором — накоплением знаний, формализацией и упрощением операций, автоматизацией и т.п. Что потребует увеличения управленческих и прочих накладных расходов, конечно.

    3. Но с чем я точно согласен, так это с тем, что процессы из книжек не помогают снижать затраты в краткосрочной перспективе. И качество, кстати, тоже в краткосрочной перспективе не повышают. И рисков скорее добавляют. СМК — это здоровый образ жизни, гомеопатия и физкультура, а от них мало толку, когда нужна экстренная операция.

    Поэтому я бы резюмировал так: новые ИТ-процессы не нужны тем ИТ-командам, в которых кризис. Они нужны тем ИТ-командам, в которых развитие.

    4. Ну и про кирпич я согласен, конечно, тоже.

  5. Сергей Посыльный

    Считал что качественный учёт в одном-двух первоначальных процессах, займёт дополнительно 5-10% времени специалистов и минимум 40% Старших групп (команд). Если люди готовы напрячься в краткосрочной перспективе что бы обосновать необходимость найма дополнительных специалистов — они сделают это, если уже предел — они побегут.

    Надо беседовать, выяснять, и конечно агитировать если необходимо...

  6. Дмитрий Исайченко

    «А последовательность выбора из этих двух должна быть строгой: 1 ... 2 ... 3 ...»

    Думаю, я бы в таких рассуждениях заходил немного с другого конца — не от возможности внедрения / изменения процесса, а от необходимости. То есть от задачи.

    Например, представьте, что Вам нужно обеспечить сокращение среднего времени решения инцидентов. Или увеличить долю звонков, отвеченных на первой линии. За счет чего? Если ли у нас в процессе или в технологиях резервы / возможности для решения этой задачи или она решается только с привлечением доп. людей? Анализируем, где теряется время при обработке инцидентов, и принимаем решение. Или Вам нужно увеличить количество изменений, реализуемых за месяц. И опять смотрим, анализируем, принимаем решение. И ответ далеко не всегда в новом процессе, а скорее в тюнинге или более жестком применении существующих, где-то в лучшей автоматизации.

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

  7. Grigory Kornilov

    Напоминает из «Формула любви»:

    ...

    — Ну, ежели постараться — можно и за пять.

    — А за десять?

    — Ну, барин, ты задачи ставишь! За десять дён одному не справиться, тут помощник нужен — хомо сапиенс!

    — Бери помощников, но чтобы не раньше!

    ...

    «Руководитель надеется, что объективную отчетность о трудовой нагрузке сможет дать ему процессная модель управления» — а без процессной модели отчетности нет или она не объективна?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

СЕН
27