За последние двадцать лет корпоративный мир переболел, вроде как, всеми возможными методологиями.
Agile из манифеста гибкой разработки превратился в религию, где догматы важнее результата, а слово «ценности» произносится чаще, чем слово «продукт» («agile-театр», карго-культ и тд).
Scrum подарил миру священный ежедневный стендап, который из 15-минутной синхронизации мутировал в ритуальные пытки и спринты, чья главная цель - не выпустить работающую фичу, а любой ценой сжечь запланированные сторипоинты.
Kanban честно визуализирует поток задач, но при малейшем отсутствии дисциплины превращается в кладбище бесконечно висящих стикеров в колонке «в процессе» и легитимизирует многозадачность на грани нервного срыва.
А уж про Waterfall и говорить нечего - он идеален только в розовых мечтах аналитиков, которые верят, что требования не изменятся за время разработки.
Короче - полный закон Гудхарта…
И вот представляется, что общая беда почти всех этих подходов в том, что они упорно смешивают 2 разные вещи:
ответственность за дисциплину процесса;
ответственность за результат.
По итогу, само собой, порождается дикая бюрократия: ты должен не просто сделать задачу, а сделать её «с правильным выражением лица» - сидя в опенспейсе с девяти до шести, заполняя тайм-трекеры и участвуя в «ритуалах», которые создают ощущение плохо организованной секты. Это приводит к закономерному итогу: нанимают профессионалов, а затем заставляют их имитировать бурную деятельность вместо того, чтобы просто дать им сделать дело.
Однако рабочие процессы могут быть выстроены и совершенно иначе. В связи с этим и появилась данная статья - потребность концептуализировать подход.
Что за подход?
Task-Oriented Approach (TOA) - подход, ориентированный на задачи. Это методология организации рабочих процессов, построенная на радикальном разделении ответственности за результат и дисциплину процесса.
Конечно, сама по себе идея ориентации на результат вместо процесса не нова. Ещё в 1954 году Питер Друкер в книге The Practice of Management сформулировал подход Management by Objectives (MBO), где менеджеры и сотрудники совместно определяют конкретные измеримые цели, а оценка строится по итогам их достижения - не по активности, а по результату. В 1970-х Энди Гроув в Intel развил эту логику в систему OKR (Objectives and Key Results), где ключевые результаты служат объективными индикаторами выполнения целей. В 2008 году Кэли Ресслер и Джоди Томпсон, бывшие HR-специалисты Best Buy, опубликовали книгу Why Work Sucks and How to Fix It и формализовали концепцию ROWE (Results-Only Work Environment), в рамках которой сотрудники получают полную автономию в выборе времени и места работы, а оцениваются исключительно по выходу - не по отработанным часам. В культуре фриланса и аутсорса подобная логика сама по себе стала нормой - просто без единого названия и формализованных правил. TOA берёт этот же фундамент, но конкретизирует его в виде жёсткой методологии с бинарной оценкой, чётко определяемым горизонтом планирования и явным механизмом защиты исполнителя.
Дисклеймер. Здесь не предлагается готовая методология на все случаи жизни - TOA ни разу ни silver bullet. Вполне возможно, что для кого-то это совершенно не подойдёт. А некоторым может показаться, что методология слишком общая, как бы незавершённая. Но дело в том, что здесь представлена не одна конкретная методология, а скорее класс методологий - семейство подходов, объединённых принципом ориентации на результат. TOA - это скорее абстрактный базовый класс, из которого конкретные команды могут вывести собственные реализации под свой контекст. Почему в таком виде? Потому что именно так оно полезнее: специфицированная методология «для всех» неизбежно превращается в бюрократию, а вот гибкий класс - в реальный инструмент.
Фундаментальный принцип: разделение ответственности
TOA базируется на утверждении: требовать от исполнителя одновременно и жёсткой дисциплины процесса, и творческого/продуктивного результата - управленческий оксюморон, ведущий к деградации либо одного из двух показателей, либо сразу обоих.
Если организации важен в первую очередь результат, методология TOA - актуальна. Ответственность за дисциплину процесса аннигилируется, контроль присутствия и ритуалов снимается полностью. Если же важна дисциплина процесса (предсказуемость присутствия, соблюдение регламентов, traceability каждого шага) - TOA, соответственно, неактуальна.
Смешение же этих двух подходов порождает двойную бухгалтерию, имитацию бурной деятельности, выгорание и прочие весёлые неприятности.
В рамках TOA существует ровно два базовых момента:
Задача - с чётко описанными требованиями к результату.
Дедлайн - классический дедлайн подразумевается не более одной недели (в рамках одного рабочего цикла), но в целом вариабельно.
Принцип: задача должна быть выполнена строго в срок или ранее, в полном соответствии с зафиксированными требованиями. Единственный критерий успеха - бинарный: «сделано / не сделано».
Всё остальное - рабочее время, место, график, ритуалы, инструменты, тимбилдинг, способ выполнения - факультативно. Оно не запрещено, но и не обязательно. К сотруднику не могут быть предъявлены претензии, основанные на процессе, если результат достигнут в срок.
Ключевые элементы и принципы
Задача
Формулируется приёмщиком (тем, кто платит или принимает результат).
Содержит однозначные, измеримые критерии готовности.
Если на старте требования неоднозначны, исполнитель имеет право (и обязан) запросить уточнение до начала работ. Дедлайн начинает отсчитываться только после того, как задача признана обеими сторонами достаточно определённой для выполнения. Это механизм «ваучера на уточнение», защищающий обе стороны от нереалистичных ожиданий.
Дедлайн
Рекомендуемая длительность одного рабочего цикла - одна неделя. Фиксируется обеими сторонами. В сущности, срок может быть и больше, но неделя рекомендована потому, что это наименьший классический рабочий полный цикл - будни + выходные.
Крупные задачи подлежат обязательной декомпозиции на подзадачи с горизонтами равными минимальному дедлайну.
Задача может быть выполнена и за 10 минут, и за 7 дней - срок фиксируется до старта и не меняется без обоюдного согласия (за исключением официальных блокеров).
Бинарная оценка
Приёмщик оценивает только факт выполнения задачи: «да» или «нет».
Никакие промежуточные градации («почти сделано», «старался», «было сложно») не влияют на оценку. Система не принимает их во внимание.
Бинарность исключает манипуляции и необходимость оправдываться за процесс.
Свобода метода и графика
Исполнитель сам выбирает, как, где и когда работать. Контроль присутствия, учёт рабочего времени, обязательные ритуалы - отсутствуют.
Никто не вправе требовать от исполнителя отчёта о том, как именно был достигнут результат. Вопрос «как ты это делал?» может быть задан из профессионального интереса, но отвечать на него или нет - исключительное право исполнителя.
Коммуникация в процессе
Не регламентируется. Коммуникация может происходить по инициативе любой из сторон, если это помогает достижению результата, но не является обязательным требованием методологии.
Отсутствие или наличие коммуникации не влияет на итоговую бинарную оценку.
Структура рабочего цикла
Постановка задачи. Приёмщик формулирует задачу с измеримыми критериями. Исполнитель подтверждает, что требования однозначны, либо запрашивает уточнение. Также на этом этапе оговариваются те аспекты, которые нужны исполнителю для выполнения задачи (подписки, доступы и тд).
Согласование дедлайна.
Исполнение. Процесс полностью отдан на откуп исполнителю.
Приёмка. В установленный дедлайн приёмщик выносит обоснованное решение: «сделано / не сделано».
Реакция на результат.
При успехе - цикл завершён.
При неуспехе - применяется политика вторых шансов.
Политика вторых шансов и блокеры
Вторые шансы
Возможность повторного выполнения задачи, не уложившейся в дедлайн.
Порядок предоставления не жёстко фиксирован: он определяется приёмщиком (руководителем, заказчиком). Это может быть:
фиксированное количество шансов (например, 1, 5, 100500);
гибкое решение, принимаемое приёмщиком исходя из контекста, истории сотрудничества и причин срыва.
Исчерпание кредита доверия (в любой из форм) означает отказ от использования TOA в рамках данного проекта или с данным исполнителем.
Фиксированные блокеры
Это заранее оговорённые форс-мажорные обстоятельства, которые признаются обеими сторонами как объективное препятствие, не зависящее от исполнителя.
Примеры: подтверждённый больничный, отсутствие доступа к критически важному сервису по вине заказчика, непредоставление необходимых материалов в срок.
При наступлении блокера дедлайн сдвигается на время его действия, и это не считается срывом и не тратит шанс.
Рефлексия и обмен опытом
Оценка результата всегда бинарна и не обязательно должна содержать анализ процесса.
Рефлексия как таковая не запрещена. Команда или отдельный исполнитель могут по собственному желанию анализировать причины успехов и неудач, чтобы улучшить собственную эффективность или точность декомпозиции.
Подобная рефлексия проводится исключительно добровольно и не является частью формальной процедуры приёмки. Её результаты не могут влиять на уже вынесенную бинарную оценку.
Обмен техническим опытом, код-ревью, обсуждение архитектурных решений приветствуются, если инициированы снизу, но остаются полностью опциональными.
Что TOA решает
Симуляцию работы. Бесполезно притворяться занятым - важен только предъявленный результат.
Бесконечные согласования и бюрократию. Любая активность, не ведущая напрямую к сдаче задачи в дедлайн, теряет смысл.
Смешение личного и рабочего. Исполнитель не обязан оправдываться за свой режим, если результат получен.
Манипуляции через процесс. Истории о стараниях, сложностях и переработках не работают в бинарной системе.
Что не решает (и где теоретически не рекомендуется применять)
Задачи с высокой неопределённостью на старте. Они требуют предварительных исследовательских подзадач, которые сами должны быть сформулированы как TOA-совместимые (с чёткими критериями завершения исследования).
Креативные задачи без жёсткого ТЗ («сделай красиво», «придумай что-нибудь»). Потому, что для них необходимо сначала выработать измеримые критерии.
Долгие стратегические проекты. Их применение возможно только после полной и качественной декомпозиции на дедлайн-шаги.
Кому и где подходит
Фрилансерам (у них оно и так работает) и аутсорс-командам с чёткими delivery-пунктами.
Тестировщикам, верстальщикам, сборщикам, курьерам - всем, чей результат легко формализуем.
Малым автономным командам в стартапах на этапе «сделать или умереть».
Проектам с высоким уровнем доверия и автономии исполнителей.
Противопоказания
Команды, требующие постоянного контроля присутствия и «ритуалов единения».
Те среды, где процесс критичен (медицина, авиация, госзаказ, финансовая отчётность, работа сторожем, наконец).
Руководители, не способные формулировать однозначные, измеримые требования.
Ситуации, где по юридическим или корпоративным причинам необходим учёт рабочего времени.
Если же посмотреть ещё глубже, то в основе TOA лежит доверие участников процесса друг к другу, а внешний контроль нужен только там, где нет доверия.
Также из всего вышесказанного логичным образом вытекает существование и другого класса методологий - Process-Oriented Approach (POA). То есть подходов, где критична именно дисциплина процесса, предсказуемость, traceability, регламенты. Это не «плохо» - это просто другой класс задач. Scrum, Kanban в классическом виде, Waterfall, ITIL, Six Sigma - всё это реализации POA. Они хорошо изучены, широко описаны и, вероятно, не нуждаются в ещё одном манифесте. Тут же был интерес другой - в том пространстве, которое до сих пор оставалось без чётко определённого имени.