Работа на результат: как она устроена и когда подходит

Большинство программных проектов строятся вокруг одного из двух вопросов: сколько времени команды мы используем и построили ли мы всё по списку? Оба вопроса разумны. Ни один не говорит, получил ли бизнес то, что ему было нужно.

Работа на результат начинается с третьего вопроса: какой результат должна дать эта работа и как мы поймём, что она его дала? В этой статье о том, чем это отличается на практике, как выбрать измеримый результат и когда эта модель подходит.

Три способа организовать работу

Модели полезно сравнивать как способы работы, а не как коммерческие договорённости.

• Время и материалы (time and materials). Команда идёт по бэклогу, а клиент корректирует курс неделя за неделей. Это гибко и подходит для работы, объём которой никто не может знать заранее. Слабость в том, что прогресс обычно описывают как активность: закрытые задачи, выпущенные функции, завершённые спринты.
• Фиксированный объём. Объём согласуют заранее и сдают к сроку. Это подходит для хорошо понятной работы со стабильными требованиями. Слабость в том, что всё, что команда узнаёт по ходу проекта, превращается в запрос на изменение, поэтому команду подталкивают сдать исходный список, даже когда уже ясно, что часть его не поможет.
• Работа на результат. Заранее согласуют результат и способ его измерения, а объём выбирают и пересматривают так, чтобы сдвигать этот показатель. Это подходит для работы, где цель ясна, а путь к ней неясен.

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

Выберите измеримый результат

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

Хороший результат для этой модели обладает несколькими свойствами:

• Он важен для бизнеса в его собственных терминах. Человеку вне инженерной команды было бы не всё равно, если бы он сдвинулся.
• Его можно измерить данными, которые у вас есть или которые можно собрать. Если цифру невозможно получить, результатом невозможно управлять.
• Команда может влиять на него напрямую. «Выручка растёт» слишком далеко от работы: на выручку влияет слишком многое другое. «Пользователи пробного периода доходят до первого отчёта» достаточно близко, чтобы этим управлять.
• У него есть исходный уровень и срок. Зафиксируйте, где находится показатель до начала работы, и договоритесь, когда будете его оценивать.

Запишите его в одном или двух простых предложениях: показатель, источник данных и как часто его будут снимать. Если такая формулировка занимает страницу, результат ещё недостаточно ясен.

Опережающие и запаздывающие показатели

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

Опережающий показатель меняется раньше и предсказывает запаздывающий. Если цель в лучшем удержании, опережающим показателем может быть доля новых аккаунтов, которые завершают настройку в первую неделю, или частота использования ключевой функции. Команда видит их изменение в течение нескольких дней после релиза.

Используйте оба:

• По запаздывающему показателю оценивают результат.
• Один или два опережающих показателя направляют решения от недели к неделе.
• Время от времени проверяйте, что опережающие показатели всё ещё предсказывают запаздывающий. Если доля завершённых настроек растёт, а удержание нет, команда оптимизирует не то.

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

Как меняется планирование

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

Это меняет несколько привычек:

• Работа упорядочена по ожидаемому эффекту, и самый прямой путь идёт первым. Пунктам, которые не связаны с результатом, нужна отдельная причина быть в плане, например безопасность или поддержка.
• Ставки называются ставками. У каждой значимой части работы есть короткая заметка: что, как мы ожидаем, она сделает с показателем и как мы это проверим.
• Сначала небольшие релизы. Чем раньше что-то попадает к пользователям, тем раньше показатели скажут, сработало ли это.
• Остановка считается нормальным итогом. Если подход не сдвигает показатель, план меняется. Это значит, что модель работает, а не даёт сбой.

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

Как меняются отчёты

Отчёт в этой модели начинается с показателя: где он был в начале, где он сейчас и что, по мнению команды, вызвало изменение. Список того, что построено, идёт вторым, как объяснение.

Полезный отчёт отвечает на четыре вопроса:

1. Как изменились запаздывающий и опережающие показатели с прошлого отчёта.
2. Что вышло в релиз и какой эффект, судя по всему, дал каждый релиз.
3. Что не сработало и что команда делает вместо этого.
4. Что команда планирует дальше и почему ожидает, что это поможет.

Честно говорите о причинах. Метрики двигает и другое: маркетинговая кампания, сезонный спад, запуск у конкурента. Отмечайте такие события рядом с цифрами, вместо того чтобы приписывать себе каждое изменение или открещиваться от него.

Когда подходит, а когда нет

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

Хуже она подходит в нескольких ситуациях:

• Когда важен сам факт сделанной работы. Изменение под требования регулятора, миграция платформы или интеграция по договору должны быть сделаны, что бы ни говорили метрики. Честнее здесь часто оказывается фиксированный объём.
• Когда пока нечего измерять. У продукта без пользователей нет исходного уровня. Ранняя работа может быть направлена на то, чтобы дойти до точки, где результаты можно наблюдать.
• Когда результат слишком далёк от работы. Если команда не может повлиять на показатель в отведённый срок, она либо потеряет мотивацию, либо начнёт подгонять цифры.
• Когда клиент не может делиться данными. Модель держится на том, что обе стороны смотрят на одни и те же цифры.

Когда мы сами работаем на результат, результат и способ его измерения согласуются письменно до начала работ, а план меняется, когда этого требует показатель.

С чего начать

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

Через несколько циклов разговор меняется. Вместо вопроса, занята ли команда, все спрашивают, помогает ли работа, а в этом и был смысл с самого начала.