Введение

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

Личная жизнь

Для простоты примеров начну со своего опыта. Я уже около 10 лет пользуюсь Evernote как «личным дневником», больше для планирования дел и в меньшей степени – для личной рефлексии.

В Evernote у меня есть:

1. Ежемесячные заметки со списками дел на каждый день:
   

   1. По работе

   2. По личным делам

2. В каждой заметке на каждый день – чеклисты, при этом важно:
   

   1. Использовать тэги на основе категоризации дел по «Матрице Эйзенхауэра» – для краткости я пишу UI/NI/UN/NN (UI – «Urgent & Important», далее аналогично).

   2. Не просто поставить галочку, а при необходимости указать, что именно было сделано для выполнения этого пункта. Пример – «[v] <NI> Проверить старые внешние жёсткие диски – один выкинул, второй работает».

3. В списке дел на каждый рабочий день есть пункты «Планирование (не забывать смотреть список ожидания и бэклог)» и «Подведение итогов и предварительное планирование следующего дня».

4. Бэклог месяца для накидывания идей, которые непонятно когда брать в выполнение, но забывать не хочется.

5. «WKLY» и подобные тэги для личных задач + планирование следующей недели в воскресенье, включая добавление таких тэгированных регулярных задач.

6. Заметки по методике GTD.

Evernote синхронизируется на всех моих ноутбуках (ThinkPad X1 Carbon на GNU/Linux и MacBook Pro) и смартфонах (Samsung и Apple), поэтому идя например в город, я (чаще всего) не забываю, если нужно зайти в магазин и что-то купить из продуктов.

И немного статистики – в Evernote у меня 345 заметок в 21 блокноте.

Работа

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

Jira

1. Необходимо по полной использование структуру Epic/Story/Task для семантической группировки и спринты/планы для временной группировки.

2. Важно создавать эпики для OKR работ, для Adhoc и «Technical Excellence» задач, при этом в соответствии с приоритетами рабочие дни делятся на дни под эти эпики, например 3 дня под OKR, по одному для Adhoc и TE задач (но без фанатизма в случае необходимых корректировок по ходу недели).

3. Полезно писать «status update» комментарии по своим задачам в работе, даже если они никому кроме вас не нужны, например просто чтобы не забыть что уже сделано. Своего рода как сохранение контекста процесса при переключении задач процессором.

4. Требуется каждую задачу оценивать в «story points», как только оценка стала возможна и корректировать эту оценку при необходимости. Вопрос оценки по такому методу отдельно как-нибудь разберу, тут тоже есть целая система.

5. Жизненно важно иметь чёткие описания к задачам, а не только заголовки. Наиболее важные пункты:
   

   1. Контекст задачи – зачем она создана и какую проблему решает или какую возможность создаёт.

   2. Заинтересованные лица, как внутри так и вне компании.

   3. К какому компоненту/процессу относится.

   4. Ссылки на переписку и созвоны по теме задачи

   5. Критерий принятия – как можно проверить, что задача действительно успешно выполнена.

GitHub

1. Даже если пока нет времени именно писать код – создавать ветку с привязкой к задаче в системе управления проектом, постараться хотя бы наметить TODO-комментарии в коде там, где планируются правки, с описанием что планируется сделать. Это занимает 5-15 минут чаще всего, но очень помогает.

2. Не стоит пренебрегать использованием автотестов и стилевых проверок (для Python это например «PEP 8»). Хотя эта рекомендация и выглядит очевидной, опыт показывает, что про реализацию автопроверок PR перед мерджем в мастер люди часто забывают (или забивают на них).

3. Обязательно стоит использовать CODEOWNERS файл и настроить процедуру мерджа в мастер так, чтобы хотя бы кто-то из команды кроме автора PR посмотрел код.

Slack

1. При получении нового сообщения и отсутствии возможности мгновенного ответа – сообщить о получении и планировании к рассмотрению. Как вариант можно просто поставить эмоджи «?» ?. Однако в дополнение к этому стоит где-то для себя (см. выше раздел про Evernote) записать, что нужно ответить человеку, или он/она могут обидеться ?

2. Если нет времени ни отвечать, ни записывать себе, то стоит воспользоваться механизмом напоминания о сообщении.

3. Если вы решили условно «сообразить на троих», то есть создаёте обсуждение на несколько человек, лучше создать приватный канал, чем держать в списке чатов что-то типа «Аня, Вася, Маша».

Google Calendar

1. Для каждой регулярной встречи описывать своего рода «workflow». Например:
   

   1. Разобрать алерты.

   2. Разобрать очередь запросов.

   3. Обсудить дэшбоард с задачами спринта, проговорить про сделанную работу и поделиться планами.

2. Для каждой adhoc встречи – прописывать по поводу чего собираемся, какие есть подготовительные материалы и чего хотим достигнуть встречей. Иначе от совещаний будет только головная боль и видимость работы.

Miro

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

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

3. Когда с кем-то обсуждаешь какую-нибудь доску и человек говорит замечания – опять же делать заметки в комментариях на той же доске, чтобы не потерялось и для себя и для коллег.

Confluence

О последнем, но не в смысле важности, инструменте, я напишу лишь кратко:

1. Не стоит увлекаться огромным объёмом текста. Ваше эго это конечно потешит, но люди скорее всего просто не будут читать.

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

3. Существует огромное количество плагинов, используйте их. Например, вместо выделения текста цветом для описания предупреждения о плохой практике – лучше использовать виджет «Warning box». Оно и выглядеть будет лучше и в едином стиле позволит выдержать разные страницы документации, что облегчает восприятие.

Над развёрнутым описанием предлагаю подумать на основе перечисленных выше мыслей.

Заключение

Человеческий мозг ограничен, он просто неспособен держать и обрабатывать тот объём информации, который сейчас нас окружает в личной жизни и на работе. А вот мозг в связке с современной техникой и программным обеспечением – поднимает нас на просто немыслимые ранее высоты. Вот только для начала надо «загрузить свой мозг», чтобы было что «выгружать» в заметки. Пустой голове никакой софт не поможет ?