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

Опять же, список простых вопросов для «разогрева»:

  • Как часто я меняю цели и планы?
  • Как часто я возвращаюсь к прошлым целям и планам? Почему?
  • Бывает ли, что я хожу по кругу?
  • Какой шанс того, что именно новая цель или план будут финальными?
  • Что случится в случае поступления важного аргумента, не учтенного на этапе планирования?
  • Существуют ли тогда вообще финальные цели и планы?
  • Стоит ли избавляться от ощущения, что вот именно сейчас у меня будет финальная версия?
  • Стоит ли бояться изменения планов и целей?
  • Если не стоит, почему бы тогда не записывать их не в виде «единственно правильного» и «финального» варианта, а называть их как есть — «текущая цель» и «текущий план»?

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

Когда я, наконец, встал на скользкую дорожку стресс-тестирования, все не мог отделаться от ощущения, что делаю что-то не так: планы непрерывно менялись и заменялись новыми, но привычное по прошлому подходу ощущение завершенности все не приходило. Вот вроде и хочется верить, что вот именно текущий план — самый лучший и последний, авотхрен!

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

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

Тут есть, конечно, тонкая грань в виде «А когда же хватит уже стресс-тестировать и пора переходить к реализации?»

Сначала кажется, что на этот «гнилой» вопрос невозможно ответить точно, пока не придешь к ещё одному простому вопросу: «Сколько времени сэкономит дополнительный час стресс-тестирования?»

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

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

К слову об экономии времени: на верхних уровнях, особенно на старте, будет даже не «экономия», а тотальное выкидывание старых идей и проектов в топку. Это, конечно, можно как-то сконвертировать в человеко-часы, но чаще волосы на голове шевелятся: «Бетонная плита упала в метре от седого мальчика.»

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

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

Из этого правила «часа экономии» есть одно большое исключение: стратегические планы и цели. Их можно и нужно тестировать бесконечно, всю жизнь. Мы, фактически, не в состоянии принять столь серьёзные решения в условиях дефицита информации на старте, и с накоплением опыта мы неизбежно будем и пельмени разлеплять, и фарш обратно проворачивать. Я эту работу обычно оставляю на выходные, когда ничто не отвлекает уже. И, к слову, каждый раз нахожу что-то, более чем достойное потраченных пары часов работы мозга.

Да, до сих пор нахожу. Да, не собираюсь останавливаться.

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

Теперь, собственно, вернёмся к версионированию:

  • Стоит ли сохранять предыдущие версии целей и планов? Зачем?
  • Удобнее ли тогда станет сохранение и накопление аргументов?
  • Что важнее: версии планов или аргументы к ним?
  • Так ли вообще важна текущая версия плана или цели?
  • Если аргументы — гораздо важнее самих планов, достойны ли они выделения в отдельные подзаметки?
  • Удобнее ли эти подзаметки писать под версиями, корректируя версии их по ходу?
  • Избавляет ли это от повторного обсасывания одних и тех же аргументов в новой версии плана?
  • Если сама по себе версия не так важна, то может ли она считаться просто вечным черновиком?
  • Когда нужно переходить к следующей версии?
  • Стоит ли сразу писать первую версию, или лучше начать с предисловия в свободной форме?
  • Когда именно могут понадобиться сохраненные и разобранные аргументы?
  • Могут ли они меняться по ходу, как и моё отношение к ним?
  • Если они меняются, что происходит с планом и целью?
  • Как лучше организовать всю эту структуру?
  • Как с ней удобнее было бы работать?
  • Стоит ли таким же образом логгировать процесс выполнения плана?
  • Зачем это может понадобиться?

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

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

Если планы и цели ценности не имеют, то вот что по-настоящему ценно: весь этот массив контраргументов и фактов, к которым мы будем ещё не раз неизбежно возвращаться при тестировании новых идей и версий планов. Именно контраргументы старого/аргументы нового являются «скелетом» всех последующих версий, которые за счет усиления этого «скелета» будут становиться все лучше, и лучше. Этот момент сложно описать словами, пока его не увидишь на своей практике, так что я даже и не буду пытаться.

«Контраргумент» — это важный вопрос или потенциальная проблема, разбираемая в виде цепочки вопросов, пока не появится нечто похожее на решение или хотя бы реалистичный метод минимизации риска. И, что важно, часто именно в процессе поиска контраргументов к какому-то отдельному вопросу весь план кардинально меняется, а не только лишь этот вопрос. И к этому нужно быть готовым, и не тормозить мозг, если он вдруг выходит за рамки исходной проблемы.

Собственно, в этом и состоит суть стресс-тестирования: включение мозга на поиск решений, что может привести к совершенно неожиданным инсайтам совершенно в другой точке, или даже вообще в другом плане. Ценность тут — в самой работе мозга, а не в решаемой им в текущий момент задаче. Задача всего лишь настраивает его на правильное направление работы вместо мыслей о бабах да о лесе, а дальше ему нужно только не мешать. Я об этом потом подробнее расскажу, в следующих сериях. Там же, где и про внешнюю экспертизу будет, о чем тут пока ни слова было не сказано.

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

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

Поэтому, кстати, хороший способ увидеть действие метода на практике — попробовать его на других для начала. Сразу будет видна вся «глубина кроличьей норы», как метко выразился один из комментаторов. Если своих тараканов нам ловить сложно (мы не можем быть психоаналитиками для самих себя), то вот на других уже развернемся по-полной. И, увидев весь трагикомизм ситуации со стороны, начнем и себя на этом ловить, да по рукам бить. Нужно только подальше от «лабораторного хомячка» стоять, чтобы что-нибудь в лицо не прилетело, да.

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

Я ещё веду там небольшой лог исполнения плана, опять же на случай «разбора полётов» в будущем. Это сейчас лишь кажется, что свои нетленки забыть невозможно, а через пару месяцев будешь смотреть на свои прошлые труды как пятиклассник — на свои же тетради из первого класса.

Лично мне версионирование зашло на отличненько. Может, потому, что эта концепция оказалась привычной ещё по роли разработчика.

Важное предупреждение для людей с проблемами с сосудами:

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

Со временем, к счастью, входишь в ритм, и это уже не столь заметно. Мозг, видимо, быстро адаптируется к нагрузкам. Но вот первые дни были даже сомнения в том, что эта работа мне подойдёт по здоровью, особенно если заниматься ей с утра и до вечера ежедневно. Жена не даст соврать :)

А как вы боретесь с той проблемой изменения планов?
Какие решения используете?

VN:F [1.9.20_1166]
Rating: 3.5/5 (6 votes cast)
Версионирование целей и планов, 3.5 out of 5 based on 6 ratings
Share