Портал №1 по управлению цифровыми
и информационными технологиями

Сопротивление измерению

Известная фраза “Нельзя управлять тем, что не измеряешь” приписывается разным уважаемым управленцам: Джеку Уэлчу из GE, Эдварду Демингу, отцу QA, возможно ещё кому-то. Некоторые считают, что это народная пословица – общеизвестная истина, сформулированная кратко и ёмко. Действительно, выстраивая систему управления неплохо бы сделать так, чтобы принимаемые решения опирались на объективные данные, а не мнение отдельных участников о состоянии дел. В этом случае решения могут быть более взвешенными, а потому – более результативными.

Занимаясь организацией процессов управления, скажем, в ITSM, современный консультант не забудет про KPI и метрики. Разрабатывая для заказчика регламент какого-либо процесса, управления инцидентами, проблемами, конфигурациями, изменениями, уровнем услуг… – любого процесса, консультант добавит в этот регламент необходимые слова про точки измерения, выполнение оценки, принятие решений. Более того, не просто добавит слова, а приложит все усилия, чтобы практика измерения у заказчика появилась, прижилась, дала результаты.

Всё это понятно и привычно для той самой ITSM-области. В области же разработки ПО картина, по моим наблюдениям, иная.

Некоторые команды ничего не измеряют вовсе. Они объективно не знают про свой процесс ни-че-го. Люди просто ходят на работу и что-то делают, а на совещаниях и прочих контрольных мероприятиях пространно рассуждают, а то и дают невыполнимые обещания.

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

Некоторые команды разработки ПО всё ещё (в 2019-м!) исповедуют проектное управление, а потому имеют и менеджера проекта, и календарный график, и полный набор заблуждений относительно проектного управления как способа получения результата.

То есть – исходная ситуация схожа с той, что мы наблюдали лет 15 назад в области ИТ-эксплуатации.

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

Одни вам скажут, что метрики неизвестно как собирать и верить данным нельзя (враки, конечно).

Другие посетуют, что ничего не понятно (несмотря на состоявшиеся обучения и разъяснения).

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

Четвёртые будут всё же регистрировать события, на основе которых формируется измерение, но таким образом, что в полный рост невооружённым глазом виден принцип “garbage in – garbage out”.

Пятые ничего не скажут и ничего не сделают, а будут просто игнорировать вопрос, как будто он рассосётся сам собой. Похожи на детей, закрывающих лицо ладошкой – меня же теперь не видно, да?

Активно или пассивно, осознанно или бессознательно, но сопротивление измерению в разработке ПО присутствует и мешает. Мешает в первую очередь тем, что замедляет любую трансформацию – то, что можно было сделать за месяц-два, получается сделать наполовину за год. Простите, это никуда не годится.

К сообществу нашего портала у меня два вопроса:

  1. Почему так? Чем принципиально отличается область разработки ПО от области эксплуатации?
  2. Что с этим делать? Действовать убеждением, или жёстко? Как не потратить на вопрос измерения (всего лишь один из вопросов трансформации!) месяцы и кварталы?

Буду рад услышать ваши соображения и ваш опыт.

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

Комментариев: 11

  • Андрей

    С одной стороны – необходимость измерения, обязательного определения и сбора четких метрик, необходимость “продавить” команду на внедрение этого.
    С другой стороны – странное утверждение “Некоторые команды разработки ПО всё ещё (в 2019-м!) исповедуют проектное управление, а потому имеют и менеджера проекта, и календарный график, и полный набор заблуждений относительно проектного управления как способа получения результата.”. А что, проектное управление с ПМ уже всё, списано и забыто? Всегда и везде залогом успешной разработки являются только гибкие методологии?
    Ну так в том же SCRUM какая проблема, там кроме общепринятых бизнес метрик по сути только velocity команды есть и всё ) Ну еще из Burndown Chart можно что-то вытянуть.

    • > А что, проектное управление с ПМ уже всё, списано и забыто? Всегда и везде залогом успешной разработки являются только гибкие методологии?

      Поддерживаю вопрос.

      • Вопрос к теме заметки не относится. Возможно, заслуживает отдельного обсуждения, но точно не здесь.

  • Nargiza Suleymanova

    Замечательная статья, жизненная. Как всегда шикарный слог автора )
    1. Ответ не очень существенен, но мне кажется, это все “потому что у них так принято”. Раньше админы чувствовали и вели себя как боги, теперь тоже самое делают разработчики. Это пройдет, думаю.
    2. Я бы взяла обязательно третьих (это важно) плюс первых и пятых, и именно с ними, путем задабривания, а иногда запугивания (шучу), разработала бы таки метрики. Третьи – потому что если с ними не договориться, то будет совсем плохо. И да, именно они (по моему опыту) в итоге часто хорошие варианты выдают. Первые и пятые – обычно те, к которым редко прислушиваются, а зря. По мне, самый ужасный вариант, это когда все радостно со всем соглашаются и не спорят с консультантом – вот тут последствия катастрофические.

    • Раньше админы чувствовали и вели себя как боги, теперь тоже самое делают разработчики. Это пройдет, думаю.

      Наргиза, вот это очень интересная мысль!
      Вполне возможно, что объяснение ровно такое.

  • Светлана

    Приветствую.

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

    Процесс эксплуатации, на мой взгляд, более понятен и предсказуем.

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

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

    • Светлана, спасибо за комментарий!
      Да, разработка ПО может выглядеть как нечто сакральное и очень творческое. Однако мне кажется, что отчасти это ровно потому, что она, разработка, как правило, устроена кое-как. Был бы порядок – было бы меньше тайны и больше пользы 🙂

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

  • ВяЧЕСлав

    В современном operation конверсия Баз Знаний приближается к 80%.
    Если Вам удастся свести разработку на 80% к применению набора алгоритмов – Вы получите тот же уровень достоверности экспресс-оценки и тот же уровень сопротивления.

    Пока разработчики считают себя “художниками” – гуманитариями, а не “строителями”- технарями попытки их оцифровать будут им противоестественны.

    пы.сы. ровно на столько же снизится уровень творчества и прорывных идей.

  • Владимир Невский

    Коллеги, оцифровка идет повсеместно: в фигурном катании каждый элемент разбирается на части, каждое движение имеет свою оценку и вес …
    В системе изменений уровней зрелости процессов по CMMI (5 уровней), 4-й уровень – измеряемый и управляемый на основе количественных данных.
    VIP-обслуживание, художественные произведения hand maid и т.д. занимают и будут занимать свою узкоспециализированную нишу. Но все массовые рынки – только измеряемая цифра.
    Вспоминаем “черное зеркало” – социальный рейтинг граждан уже не за горами 🙂 Не нужно сопротивляться измерению – нужно научиться с этим жить.

  • Юлия

    Сопротивляются ровно потому, что многим попытка “алгеброй поверить гармонию” кажется кощунственной. А во-вторых, сначала нас оцифруют, потом прикрутят KPI, к ним уровень оплаты и заверте… Нет, пусть уж будет творчество, неведомое колдунство, так проще.

    Как преодолевать сопротивление? Ну, например:
    1) Определить, что не все метрики = KPI и что репрессий не будет
    2) Попробовать пожить с этими метриками, анализировать статистику, регулярно предоставлять отчетность на ее основе
    3) К этому моменту, не исключено, что на основе отчетности команда сама предложит организационные/технические и прочие решения по оптимизации процесса
    4) Воплотить такие решения в жизнь, наглядно показать выгоду от их применения
    5) Двигаться в этом направлении дальше.

  • Владимир

    Любые измерения это один из процессов обеспечения принятия управленческих решений. Отсюда следует простой вывод: сперва нужно понять кто и какие решения собирается принимать и нужны ли для этого какие-либо измерения.
    Далее, любые измерения это набор связанных с ними факторов: 1) повышение качества принимаемых управленческих решений при правильном использовании 2) затраты на сбор измерений; 2) отрицательное влияние на мотивацию персонала из-за самих измерений и необходимости тратить время на их сбор.

    Теперь некие рассуждения, которые из этого следуют, необходимые для пояснения последующих выводов.
    У вас средние зарплаты по рынку. Поиск технического специалиста на вакансию занимает от 2 месяцев и более. При этом производственные процессы формально не определены и не стандартизованы – работаем, как работается. Скрам во все поля и всё такое. Вы решаете (причины опустим), что было бы хорошо детальнее измерять ваши процессы, чтобы добиться повышения эффективности производства. При этом вы не готовы принципиально (+20-30%%) изменять зарплату. Прежде чем заниматься определением и внедрением так называемых метрик вам придётся найти ответы на ряд вопросов:
    Кто и что делает с полученными данными? Допустим обнаруживается, что есть чего подкрутить. Время есть на это или проектами всё забито? А деньги? А готовы потерять часть персонала и долго не нанять замену, поскольку и так люди плохо идут? А знания есть, чтобы понять, что следует сделать для улучшения? А увольнять готовы нерадивых, с выплатой выходного пособия и прочими судами?
    Вообще это даже не треть всех вопросов, которые возникнут. НО есть самый главный: А ОНО НАМ НАДО? Если бизнес идёт, если он не требует строгого соблюдения сроков релизов софта. Если ничего принципиально не изменится, из-за сдвига сроков выпуска нового чего-нибудь месяцев на шесть, поскольку деньги не на этом зарабатываются, то зачем? Может экономически эффективнее включить в «соцпакет» расслабуху и творческий бардак – платить можно меньше реальными деньгами?

    А там, где разработка и есть бизнес уже давно всё измеряется.

    Что можно сказать в качестве выводов: Первое. Измерения самостоятельной ценности не имеют, от слова совсем. Это механизм повышения качества управленческих решений. Второе. Организация (или её подразделение – не суть) должна быть готова к введению измерений, и это важнее самих измерений. Я каждый раз вижу одну и ту же картину – метрики собираются, никаких связанных с ними решений не принимается (или не исполняются), корректирующие действия не инициируются (или до конца не доводятся). И третье. Введение измерений должно быть экономически обосновано на уровне основного бизнеса компании. Если влияния нет – смысла в них тоже нет.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM