Мне кажется, самые интересные и полезные прикладные штуки очень часто рождаются на стыке нескольких дисциплин. Если что-то очень хорошо работает в одной области, то велика вероятность, что похожие принципы можно успешно применить и в другой. В том числе поэтому мы считаем гениальным наследие людей вроде Леонардо да Винчи: обладая глубокими знаниями и умениями в целом ряде областей (живопись, астрономия, анатомия и т.д.), он мог синтезировать на их основе открытия, которые трудно было бы сделать узкому специалисту.

Поэтому сегодня мы будем обсуждать, как принципы разработки программного обеспечения могут помочь вам разобраться с собственной жизнью. Крепитесь!

Что такое Agile

Software-девелоперы сейчас, наверное, будут негодовать, но вот моя обывательская трактовка эволюции подходов к разработке ПО:

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

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

Быстрая обратная связь и гибкая реакция на нее – это ключевое преимущество Agile перед традиционным подходом. Можно потратить сколько угодно времени на подготовку детального плана проекта на два года вперед – но гарантированно учесть в нем все возможные нюансы невозможно. И какие-то вещи, которые окажутся очевидными на этапе тестирования продукта, заставят отправиться в мусорную корзину и сам план, и долгие (уже потраченные) месяцы разработки. Agile-подход лишен этого недостатка – он не боится внесения корректировок в план и ориентирован на быстрое получение «промежуточного» результата, помогающего оценить правильность выбранного направления.

Как управлять жизнью в стиле Agile?

Моей натуре зануды и задрота очень сильно импонирует именно классический, «каскадный» подход к планированию. Потратить кучу времени на составление подробных жизненных планов на 10 лет вперед, и отложить их реализацию «на завтра» – это про меня. Поэтому для себя главную ценность в Agile-подходе я вижу именно в смещении приоритетов от планирования к действию. Особенно мне нравятся две следующих концепции:

• Bias for Action («склонность к действию»). Если ты собираешься попробовать что-то новое, то не трать кучу времени на скрупулезное изучение вопроса и подготовку «идеального плана». Лучше вместо этого начни с конкретных действий, на практике приближающих тебя к конечной цели: начни ходить в зал, запишись на курсы программирования, познакомься с владельцем бизнеса и обсуди с ним свою идею. Разобраться в нюансах и составить толковый план будет гораздо проще по ходу, чем теоретизируя на диване.
• Minimum Viable Product («минимально жизнеспособный продукт»). Не пытайся сразу же сделать идеально – такая высокая планка обычно труднодостижима, и ты гарантированно будешь «буксовать», пытаясь ее осилить. Лучше подходить к вопросу поэтапно – сначала реализуй минимально допустимое решение (которое, тем не менее, будет хоть как-то работать), а потом можешь его постепенно улучшать. Это гораздо легче, чем пытаться сразу сделать идеально; более того, в процессе поэтапного улучшения может оказаться, что идеал и не нужен – приближения к нему на 70–80% вполне может оказаться достаточно (по принципу Парето).

Как это работает на практике? Например, в начале года мне пришла в голову идея запустить свой блог. Я был бы склонен подойти к этому вопросу наиболее вдумчиво: четко определить концепцию и позиционирование, оценить целевую аудиторию, выбрать наилучшую платформу, заказать безупречный дизайн, и т.д. Думаю, пойди я этим путем, я бы до сих пор занимался решением всех этих (безусловно, важных) вопросов.

Вместо этого я решил сделать упор на максимально быстром получении минимально жизнеспособного продукта – зарегистрировал домен, купил относительно приятный «коробочный» дизайн на WordPress, начал писать на размытый круг тем, интересных лично мне. В результате, куски дизайна до сих пор не переведены на русский, позиционирование постоянно претерпевает стихийные изменения – зато блог функционирует уже полгода, я получил массу полезного опыта и обратной связи (и, самое главное, – подтверждение, что само занятие мне не надоело).

Вот два основных для меня практических вывода по внедрению Agile в систему личного планирования:

• Каждый раз, когда я ставлю цели на год, а потом превращаю их в конкретные задачи на квартал, месяц, неделю и день – я стараюсь максимально подогнать их под принципы Minimum Viable Product и Bias for Action. Для этого я задаю себе вопросы: «Как быстрее всего получить первый результат?», «Какие конкретные действия могут приблизить меня к результату уже завтра?»
• Любой план в любой момент может быть изменен, если он стал неактуален. Нет смысла продолжать «тянуть лямку» достижения целей просто потому, что они когда-то были поставлены. С другой стороны, это, конечно, не повод отменять свои планы просто потому что «стало лень» их исполнять – идея тут не в этом.

Пара слов в защиту не-Agile подходов

Уверен, к этому моменту многие читатели ухмыляются: «Планы на год? Бро, ты неправильно понял идею Agile!» Возможно. Но мне кажется, что «гибкие» подходы к планированию совсем не обязательно должны полностью отрицать саму идею долгосрочного планирования.

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

Суть скорее в том, чтобы прикинуть, какие последствия может иметь общий вектор твоих текущих действий в «глобальной» картине мира. Какие-то вещи могут выглядеть разумными на горизонте года, но вести в тупик, если повторять их 10 лет подряд. Например, вкладывать деньги в акции, зная о возможности просадки –50% в каждый конкретный год кажется рискованным; но если расширить горизонт хотя бы до десяти лет, то становится очевидным, что не вкладывать – гораздо более рисковый вариант (подробнее писал об этом здесь). Аналогичные примеры можно подобрать из других сфер жизни.

Поэтому мой ответ: планировать нужно, держа в голове долгосрочные горизонты и последствия. На базе этого долгосрочного видения нужно формировать краткосрочные цели и гипотезы, которые можно быстро протестировать – Двигают ли они тебя в нужном направлении? Приближают ли долгосрочную цель? Или, может быть, проверка гипотезы показывает, что долгосрочные цели надо поменять? Тогда не бойся их менять – пусть у тебя каждый год будет новое видение на 10 лет вперед, ничего плохого в этом нет.

Второй момент, который мне кажется важным отметить, это необходимость адекватной оценки рисков своих действий. Подход Agile лучше всего работает в ситуациях, где отрицательные риски неглубоко продуманных действий малы, а потенциальная выгода от них – велика. Если вы собираетесь поменять карьеру, то попробовать в свободное время познакомиться и попрактиковаться в новой профессии – неплохая идея (в худшем случае вы просто поймете, что это не ваше). А вот сразу увольняться с текущего места работы и сжигать все мосты (особенно без наличия финансовой подушки безопасности) – такое решение уже выглядит гораздо менее очевидным и разумным. Это не значит, что оно неправильное – но просто помните, что Agile не стоит воспринимать как «не планируйте и не анализируйте наперед ничего и никогда – простой делайте!»

Книга Катерины Ленгольд «Просто Космос»

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

В целом, книга представляет собой очень краткий сборник всех актуальных методик тайм-менеджмента (местами, может быть, даже lifestyle-менеджмента), популярных в среде старт-аперов из Кремниевой долины: Ставьте гибкие цели. Обманывайте прокрастинацию. Ищите баланс, не забивайте на важные сферы жизни. Медитируйте. Спите достаточно, не ешьте всякое дерьмо, и т.д. Если вы читали хотя бы одну-две нормальных книги по тайм-менеджменту – вряд ли вы здесь откроете для себя что-то кардинально новое (помимо первых пары глав с фокусом на Agile). С другой стороны, книга короткая, Катерина не льет лишней воды – поэтому освежить основные принципы в памяти тоже будет не лишним.