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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DevOps Основы DevOps

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

Проект Феникс — DevOps на практике

Полезная деловая игра для вашей команды
 

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

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

  1. Андрей

    С одной стороны — необходимость измерения, обязательного определения и сбора четких метрик, необходимость «продавить» команду на внедрение этого.

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

    Ну так в том же SCRUM какая проблема, там кроме общепринятых бизнес метрик по сути только velocity команды есть и всё ) Ну еще из Burndown Chart можно что-то вытянуть.

  2. Nargiza Suleymanova

    Замечательная статья, жизненная. Как всегда шикарный слог автора )

    1. Ответ не очень существенен, но мне кажется, это все «потому что у них так принято». Раньше админы чувствовали и вели себя как боги, теперь тоже самое делают разработчики. Это пройдет, думаю.

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

  3. Светлана

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

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

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

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

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

    1. Олег Скрынник Автор

      Светлана, спасибо за комментарий!

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

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

  4. ВяЧЕСлав

    В современном operation конверсия Баз Знаний приближается к 80%.

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

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

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

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

    Коллеги, оцифровка идет повсеместно: в фигурном катании каждый элемент разбирается на части, каждое движение имеет свою оценку и вес …

    В системе изменений уровней зрелости процессов по CMMI (5 уровней), 4-й уровень — измеряемый и управляемый на основе количественных данных.

    VIP-обслуживание, художественные произведения hand maid и т.д. занимают и будут занимать свою узкоспециализированную нишу. Но все массовые рынки — только измеряемая цифра.

    Вспоминаем «черное зеркало» — социальный рейтинг граждан уже не за горами 🙂 Не нужно сопротивляться измерению — нужно научиться с этим жить.

  6. Юлия

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

    Как преодолевать сопротивление? Ну, например:

    1) Определить, что не все метрики = KPI и что репрессий не будет

    2) Попробовать пожить с этими метриками, анализировать статистику, регулярно предоставлять отчетность на ее основе

    3) К этому моменту, не исключено, что на основе отчетности команда сама предложит организационные/технические и прочие решения по оптимизации процесса

    4) Воплотить такие решения в жизнь, наглядно показать выгоду от их применения

    5) Двигаться в этом направлении дальше.

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

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

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

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

ОКТ
16
Учебный курс:
Основы ITIL® 4 (очно) 
ОКТ
16
Учебный курс:
Основы ITIL® 4 (очно)