Итак, в предыдущем посте я перечислил вопросы для определения направления изменений, по итогам которых у нас появились проекты этих самых изменений, четко определяющие их границы. И, если мы подробно, глубоко и честно ответили на все вопросы, у нас в голове уже появились идеи для первых конкретных шагов.
Каждый шаг в рамках проекта называется «циклом», он как бы переводит нас из одного состояния в другое, постепенно изменяя нас и окружающий мир. И, учитывая зависимость скорости эволюции от скорости выполнения циклов, мы должны стараться сделать эти шаги как можно более короткими. В идеале — один рабочий день.
Тут принцип простой: если мы останавливаемся и анализируем результаты нашей работы всего один раз в месяц, мы будем учитывать реальный отклик от рынка, нашу реальную эффективность, оптимизировать свою работу и корректировать направление движения в 30 раз медленнее, чем в случае с ежедневными циклами. Можно посчитать, во что выльется 30-кратная разница в сложных процентах на длительных периодах.
И, учитывая что каждый цикл может кардинально изменить наше видение проекта и все последующие шаги, нет смысла заниматься долгосрочным планированием, прописывая последовательность циклов на несколько дней вперед. Может так случиться (и хорошо, на самом деле, когда это происходит), что этот план рассыпется уже после первого шага.
Если вдруг у нас получилось сделать планы на несколько дней вперед, и мы уверенно исполняем его, первый вопрос всегда: а действительно ли мы анализируем отклик от реального мира на нашу работу, или продолжаем работать в вакууме, игнорируя реальность? Основная проблема стартапов, к слову.
Тут можно было бы найти оправдание вида: «Ну что я могу показать клиентам, у меня ведь еще и продукта нет?». Я даже не буду спорить с этим аргументом, поскольку демо — всего лишь один из методов получения фидбека от рынка, причем даже не самый эффективный. Даже просто общение с клиентами «ни о чем» в процессе разработки позволит разбавить этот вакуум реально ценными идеями и инсайтами, кардинально меняющими направление разработки.
Соответственно, мы всегда работаем исключительно в рамках текущего цикла, не заглядывая далеко в будущее, но остаемся погружены в текущий контекст проекта. Наша ежедневная цель — найти следующий шаг, разработать выполнимый план, выполнить его и проанализировать полученные результаты. И уже анализ результатов даст нам идеи для следующего шага.
На практике, весь этот процесс диагностики, планирования и анализа занимает не больше часа, но экономит, по моей практике, дни и недели за счет отсекания лишней и бессмысленной работы. Когда мы чуть глубже задумываемся и о выборе следующего шага, и о конкретике его исполнения с пониманием жесткого ограничения по срокам (6-8 рабочих часов), уже нет соблазна витать в облаках. С таким подходом мы просто вынуждены выбирать наиболее простые и быстрые шаги и подходы, дающие максимально быстрый отклик от рынка.
И, даже если мы не успели сделать все запланированное в течение дня, цикл все равное завершается, что дает нам возможность проанализировать и адекватность нашего диагноза и плана, и нашего исполнения, и его результатов. В итоге любой, даже самый хреновый исходный план, будет естественным образом и достаточно быстро скорректирован в сторону адекватности, исполнимости и эффективности.
Даже если мы прокрастинировали весь день и вообще не приступили к исполнению, цикл все равно завершается, поскольку он только что дал нам ценную информацию: «Мы провалились в исполнении плана, значит либо план хреновый, либо нам нужно что-то менять в своих рабочих процессах». И, волей-неволей, приходится все-таки искать то, что реально сработает лично для нас.
Самый важный этап тут — даже не диагноз и не планирование, а именно стадия анализа в конце предыдущего дня, поскольку именно она будет показывать нам объективную реальность, а не мечты. И именно эта стадия анализа будет давать факты и идеи для диагностики и планирования следующего этапа. Каждый последующий цикл появляется естественным образом из результатов предыдущего, они неразрывно связаны друг с другом, как звенья одной цепи.
Да, самый первый цикл опирается на итоги анализа причин и требований к нужному нам изменению, поэтому мы будем опираться исключительно на теорию, наши мнения и заблуждения. Хорошо, если на этом этапе мы хотя бы потрудились посмотреть на чужой опыт и знания. Но уже второй цикл будет опираться на первый отклик с рынка, и хреново если мы продолжим избегать столкновения с реальностью.
Соответственно, стоит планировать циклы исходя из максимально возможного отклика от рынка, чтобы было от чего отталкиваться в анализе. Чем больше фидбека мы получаем, тем быстрее будем эволюционировать.
Теперь давайте разберем стадии каждого цикла:
Диагноз
На этой стадии мы кратко описываем контекст проекта сверху-вниз, делая упор на результаты анализа предыдущего шага. Мы должны понять, в какой ситуации мы находимся в текущий момент, и что нам стоит сделать в качестве следующего шага, чтобы ускорить необходимое нам изменение.
На выходе должно получиться четкое понимание наилучшего следующего шага в текущей ситуации. Такого шага, который мы могли бы выполнить за один рабочий день.
Соответственно, тут придется жестко приоритизировать все наши идеи, отдавая предпочтение тем, которые могли бы дать наиболее быстрый отклик от реального мира, чтобы каждый последующий шаг стал еще ближе к реальности.
Лично у меня в этом пункте обычно 2-4 параграфа, поскольку со временем контекст проекта более-менее стабилизируется и нет нужды описывать одни и те же вводные раз за разом. Когда же проект только начинается, тут может быть и больше текста, поскольку приходится думать чуть глубже, чем просто текущая задача.
На старте, подобная диагностика может привести и к смене направления проекта, и вообще к его закрытию. Этого не нужно бояться, поскольку это — лишь причина и следствие быстрой эволюции.
Это правда?
Когда диагноз вроде как готов, мы должны стресс-тестировать его, что означает: «Задавать гнилые вопросы, пытаясь доказать свою неправоту.» Мы не пытаемся отвечать на эти вопросы в тексте, поскольку иначе скатимся в рационализацию, но отвечаем на них у себя в голове, продолжая «бомбардировать» диагноз новыми вопросами.
Лишь когда мы на 100% уверены, что диагноз больше не вызывает вопросов, мы можем перейти к следующему этапу. Если мы поняли, что диагноз никуда не годится, можно переписывать его раз за разом, пока не придем к тому, что нас устроит. Эта работа, на самом деле, экономит гораздо больше времени, чем требует.
По итогам, мы можем записать краткий вывод типа: «Да, это — правда, поскольку я не нашел опровержений и не вижу вариантов получше».
План
Тут мы отвечаем на простой вопрос: «Что конкретно нам нужно сделать в течение рабочего дня?» Я обычно использую формат простого списка дел, ставя галочки по мере их завершения.
Но, если вдруг в процессе исполнения возникает мысль поменять план, не нужно кидаться его переписывать, а лучше сформулировать новый план, оставив исходный в качестве пищи для последующего анализа своих ошибок в планировании.
Это правда?
Тут мы опять задаем себе кучу «гнилых» вопросов, пытаясь опровергнуть исходный план, суть и последовательность шагов. Основное на этом этапе — упростить план настолько, чтобы мы реально могли его выполнить за отведенное время.
На выходе мы можем сказать себе что-то вроде: «Да, план вроде как нормальный, можно по нему работать».
Исполнение
Я обычно начинаю этот пункт с указания даты, когда я закончил планирование, а не исполнение, чтобы потом было проще отлавливать «зависшие» на длительное время проекты. Когда возвращаешься и видишь, что проект не движется уже пару недель, приходится делать выводы :)
Тут я вкратце описываю наиболее важные инсайты, возникшие в процессе исполнения, которые не всегда относятся непосредственно к проекту.
Допустим, может так случиться, что придет важная информация с рынка, которая сделает этот шаг или даже весь проект целиком не актуальным, и нам нужно понимать причины, по которым мы его завершаем досрочно.
Тут стоит понимать, что мы устраиваем всю эту писанину для самообучения в процессе будущего анализа на длительных периодах. Тогда то, что не видно изнутри торнадо, станет резко заметно: и наша прокрастинация, и бег по кругу, и хреновые идеи и планы. Соответственно, если лениться записывать важные инсайты в процессе, потом придется гадать о причинах резкой смены направлений. Не стоит надеяться на свою память, короче.
В конце рабочего дня, вне зависимости от результатов исполнения, цикл завершается и мы переходим к анализу, который лучше делать сразу, пока мозг еще погружен в проект.
Но, что касается диагностики и планирования следующего цикла, лучше делать это на свежую голову утром следующего дня, чтобы успеть «переварить» всю полученную вчера информацию.
Продолжение: анализ результатов.
«И, даже если мы не успели сделать все запланированное в течение дня, цикл все равное завершается»
Если у тебя в работе несколько проектов одновременно, ты все равно стараешься сделать хоть что-то по каждому из них?
Я обычно уделяю день целиком одному проекту.
Но, в последнее время стал делить день на две части: утром и вечером, по 2-3 часа каждая.
В итоге, можно два проекта тянуть, но это все равно тяжело.
Сделал это временно и осознанно, чтобы ускорить выход из рисковой стадии.
Когда выйду, снова, скорее всего, вернусь в прежний режим, либо (есть такая идея) оставить на вечер тип задач, не требующий особого напряга, вроде маркетинг-менеджмента.