Гвозди в гусенице

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

Давайте вобьём с одного конца гусеницы гвоздь. Это будет наш дедлайн.

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

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

Чёткость. Гвоздь должен быть забит как чёткая договорённость. Например, три макета к четвергу в 15:00 по московскому времени. Это хороший гвоздь. Если гвоздь звучит как «Давай на этой неделе, чтобы всё было хорошо сделано» — это слишком мягкий, неметаллический, из пластилина сделанный гвоздь, который запросто согнётся, порвётся, и пользы от него будет мало.

Несдвигаемость. Забитые гвозди нельзя сдвигать. Даже если исполнитель говорит, что у него ничего не готово, и просит передвинуть встречу попозже, не соглашайтесь с этим. Гвоздь значит гвоздь. Если ничего не готово, встреча всё равно состоится. Что есть, то на встречу пусть и приносит.

Во‑первых, подход, когда гвоздь не сдвигается, помогает сделать дела. Если вы встречаетесь, допустим, с этим нерадивым исполнителем, который ничего не успел, вы лучше поймёте, что происходит. Возможно, прямо на встрече откроете документ, файл, картинку и что‑то улучшите, поможете продвинуть дела вперёд.

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

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

Инкапсуляция ада. Во время работы от одного гвоздя до другого могут возникать различные неожиданности. Работа руководителя проект — рулить проектом так, чтобы проблемы, которые возникли внутри одной итерации, в промежутке от одного гвоздя до другого, не переносились на следующую итерацию. Гвозди фиксируют, как две стены работают, и весь ад, который происходит в одной итерации, должен оставаться внутри этой итерации, и через гвоздь не перескакивать. Если что‑то идёт не так, надо врубать флекс, резать функции, что‑то придумывать, но итерация должна закончиться вовремя. После этого начинается следующая итерация, и там тоже ад, как в ячейке, инкапсулирован.

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

Простой пример формата гвоздей, который довольно легко забить, — это всем известная помидорная методика Франческо Чирилло.

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

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

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

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

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

Предположим, что в проекте задумано четыре функции.

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

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

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

В конце каждой итерации вбиваем гвоздь — запуск очередной полезной фичи. Мы не все их копим, не варим на бесконечном котле бульон, а фокусируемся на конкретной функции. При этом дедлайн мы видим, вот он — в конце месяца очередной запуск витрины.

Команда взбадривается, фокусируется на том, что запуск почти на носу, и дожимает. Кроме того, для команды нет ничего более приятного, чем очередной запуск, про который можно сказать: «Ура, мы открыли новую фичу!»

Мы запустили первую функцию, двигаемся дальше, таким же образом запускаем следующую. Если мы всё спланировали идеально, ровно через четыре месяца будут те же самые четыре функции, не кривые, не косые, а чётенькие. Команда будет всё ещё свежа, всё будет хорошо. А если мы узнаем в середине проекта, что изначальный план был неправильный — например, надо было не корзину делать, а ассортимент в магазине увеличивать — в этом случае тоже нет проблем, потому что мы уже что‑то запустили и можем скорректировать план. Мы можем гибко подходить, так как есть информация из реального мира. Не наши домыслы, а информация, полученная после запусков предыдущих функций о том, что работает, что пользователи хотят и так далее.

На огромном масштабе гвозди тоже можно прибивать. Например, в компании Гугл используют известный метод ЦКР — цель и ключевые результаты. Часто используют английское название OKR — objective and key results.

Этот метод придумали и внедрили практически в самом начале, в первый год или через год после основания Гугля. Его придумал Джон Дор, и метод используется в компании до сих пор. По сути дела он прибивает работу огромной компании квартальными гвоздями, и таким образом всё держится под контролем.