Некогда обсуждать, внедряем! Результаты работы с IWE (W22)

За счёт чего станет лучше? Вопрос, который я задавал всю неделю

«Внедряем спринты — думаем, задачи начнут закрываться быстрее».

Послушайте эту фразу внимательно. Тут даже нет обещания, что станет лучше. Тут — надежда. «Думаем». Не «знаем», не «проверим», а «думаем, но вообще-то не уверены». И на этой надежде принимается вполне твёрдое решение: меняем процесс всей команде.

За неделю я насчитал вокруг себя несколько таких фраз — надежд, переодетых в решения. И вся неделя у меня крутилась вокруг того, чего в них не хватает, чтобы из надежды получилась проверяемая ставка.

Надежда против гипотезы

Надежду нельзя проверить. В этом весь фокус. «Думаем, станет быстрее» — что бы потом ни случилось, фразу не опровергнуть: стало быстрее — угадали; не стало — не повезло, факторов много. Надежда всегда права задним числом. Поэтому она так удобна и поэтому так опасна.

Гипотезу проверить можно. Чтобы из надежды получилась гипотеза, ей не хватает трёх вещей — и по ним легко прощупать любое «станет лучше», хоть чужое, хоть своё:

  1. Механизм. Не «думаем, станет быстрее», а за счёт чего именно. Спринты ускоряют закрытие задач — через что? Через фокус? Через лимит на незавершёнку? Через ритм ревью? Пока не названо — это надежда, а не причина.
  2. Baseline. Меняют несколько вещей разом и без замера «как было». Даже если станет лучше — не поймёшь, что именно сработало. Конфаундинг.
  3. Метрика успеха. Заранее, до изменения: по какому числу поймём, что получилось. Иначе любой исход объявят успехом.

Когда всех трёх нет, улучшение превращается в спектакль — improvement theater. Движение есть, изменение видно, а рассудить, сработало ли, невозможно.

Где я это поймал

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

И на этой неделе понял, почему доставать его рано.

Потому что прежде «за счёт чего станет лучше» есть вопрос ещё неудобнее: а в чём, собственно, проблема? «Задачи долго закрываются» — но насколько долго? Где именно теряется время: в очередях, в блокировках, в передачах между командами? В чём корень? Пока я этого не показал, я предлагаю лекарство от болезни, которую сам не поставил, — решение задачи, которую никто не сформулировал.

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

Что с этим делать

Начинать не с решения и даже не с механизма — с проблемы. Сначала карта проблемы: насколько долго, где задержки, в чём корень. Baseline тут не ради красивого отчёта, а чтобы вообще убедиться, что менять есть что. И только потом — карта механизмов: за счёт чего изменение эту проблему снимет. Не «вот моё решение», а таблица с пустыми клетками — приглашение к разговору, а не приговор.

Но есть половина, которую я недооценивал. Найти проблему и назвать механизм — работа аналитическая, она мне даётся. А донести — совсем другое. Я смотрю на ситуацию под другим углом, чем команда. Подашь этот угол неправильно — идею не отвергнут по сути, её просто не поймут. Разрыв окажется не в идее, а в коммуникации: разные роли, разный язык, разные картины мира. Так что половина работы — не анализ, а перевод: уложить другой взгляд так, чтобы он лёг в чужую картину, а не отскочил от неё.

Что ещё было на неделе

Параллельно шла руками работа. RollKeep (мой pet-project) — рекорд репозитория, 105 коммитов: закрыл миграцию интерфейса на единую дизайн-систему (когда есть один слой токенов, весь экран меняется консистентно — это тот же принцип «сначала механизм, потом движение», только в коде).

Метрики W22

  • Коммитов: 201 в 8 репо
  • Активных дней: 7/7
  • Закрыто: аналитика процесса в новой компании, миграция интерфейса RollKeep
  • В работе: закрытие завершающего проекта по курсу Frontend-разрабоки (дедлайн 7 июня)

На следующую неделю

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

201 коммит за неделю. А унесу я из неё два вопроса, которые теперь задаю к любому «станет лучше» — в чём, собственно, проблема и за счёт чего изменение её решит. И третью, самую трудную работу: донести это так, чтобы услышали.

2 лайка