Введение
Личная жизнь – штука сложная, работа – ещё сложнее. В условиях поистине огромной кучи «контекстов» не забывать даже самые важные вещи бывает непросто, а делать то, что надо и когда надо – порой просто невозможно. Нерешаемая задача? Отнюдь. Всё уже на самом деле давно изобретено для решения этой проблемы, просто надо знать методы и инструменты, а также немного научиться на собственном опыте. В этой статье я расскажу как об известных, так и о моих собственных методиках «упорядочивания хаоса».
Личная жизнь
Для простоты примеров начну со своего опыта. Я уже около 10 лет пользуюсь Evernote как «личным дневником», больше для планирования дел и в меньшей степени – для личной рефлексии.
В Evernote у меня есть:
Ежемесячные заметки со списками дел на каждый день:
По работе
По личным делам
В каждой заметке на каждый день – чеклисты, при этом важно:
Использовать тэги на основе категоризации дел по «Матрице Эйзенхауэра» – для краткости я пишу UI/NI/UN/NN (UI – «Urgent & Important», далее аналогично).
Не просто поставить галочку, а при необходимости указать, что именно было сделано для выполнения этого пункта. Пример – «[v] <NI> Проверить старые внешние жёсткие диски – один выкинул, второй работает».
В списке дел на каждый рабочий день есть пункты «Планирование (не забывать смотреть список ожидания и бэклог)» и «Подведение итогов и предварительное планирование следующего дня».
Бэклог месяца для накидывания идей, которые непонятно когда брать в выполнение, но забывать не хочется.
«WKLY» и подобные тэги для личных задач + планирование следующей недели в воскресенье, включая добавление таких тэгированных регулярных задач.
Заметки по методике GTD.
Evernote синхронизируется на всех моих ноутбуках (ThinkPad X1 Carbon на GNU/Linux и MacBook Pro) и смартфонах (Samsung и Apple), поэтому идя например в город, я (чаще всего) не забываю, если нужно зайти в магазин и что-то купить из продуктов.
И немного статистики – в Evernote у меня 345 заметок в 21 блокноте.
Работа
Теперь к опыту использования заметок в работе. К сожалению, не все перечисленные программные решения доступны в России, но аналоги достаточно легко гуглятся, а подход в принципе примерно один и тот же, независимо от конкретного технического решения.
Jira
Необходимо по полной использование структуру Epic/Story/Task для семантической группировки и спринты/планы для временной группировки.
Важно создавать эпики для OKR работ, для Adhoc и «Technical Excellence» задач, при этом в соответствии с приоритетами рабочие дни делятся на дни под эти эпики, например 3 дня под OKR, по одному для Adhoc и TE задач (но без фанатизма в случае необходимых корректировок по ходу недели).
Полезно писать «status update» комментарии по своим задачам в работе, даже если они никому кроме вас не нужны, например просто чтобы не забыть что уже сделано. Своего рода как сохранение контекста процесса при переключении задач процессором.
Требуется каждую задачу оценивать в «story points», как только оценка стала возможна и корректировать эту оценку при необходимости. Вопрос оценки по такому методу отдельно как-нибудь разберу, тут тоже есть целая система.
Жизненно важно иметь чёткие описания к задачам, а не только заголовки. Наиболее важные пункты:
Контекст задачи – зачем она создана и какую проблему решает или какую возможность создаёт.
Заинтересованные лица, как внутри так и вне компании.
К какому компоненту/процессу относится.
Ссылки на переписку и созвоны по теме задачи
Критерий принятия – как можно проверить, что задача действительно успешно выполнена.
GitHub
Даже если пока нет времени именно писать код – создавать ветку с привязкой к задаче в системе управления проектом, постараться хотя бы наметить TODO-комментарии в коде там, где планируются правки, с описанием что планируется сделать. Это занимает 5-15 минут чаще всего, но очень помогает.
Не стоит пренебрегать использованием автотестов и стилевых проверок (для Python это например «PEP 8»). Хотя эта рекомендация и выглядит очевидной, опыт показывает, что про реализацию автопроверок PR перед мерджем в мастер люди часто забывают (или забивают на них).
Обязательно стоит использовать
CODEOWNERSфайл и настроить процедуру мерджа в мастер так, чтобы хотя бы кто-то из команды кроме автора PR посмотрел код.
Slack
При получении нового сообщения и отсутствии возможности мгновенного ответа – сообщить о получении и планировании к рассмотрению. Как вариант можно просто поставить эмоджи «?» ?. Однако в дополнение к этому стоит где-то для себя (см. выше раздел про Evernote) записать, что нужно ответить человеку, или он/она могут обидеться ?
Если нет времени ни отвечать, ни записывать себе, то стоит воспользоваться механизмом напоминания о сообщении.
Если вы решили условно «сообразить на троих», то есть создаёте обсуждение на несколько человек, лучше создать приватный канал, чем держать в списке чатов что-то типа «Аня, Вася, Маша».
Google Calendar
Для каждой регулярной встречи описывать своего рода «workflow». Например:
Разобрать алерты.
Разобрать очередь запросов.
Обсудить дэшбоард с задачами спринта, проговорить про сделанную работу и поделиться планами.
Для каждой adhoc встречи – прописывать по поводу чего собираемся, какие есть подготовительные материалы и чего хотим достигнуть встречей. Иначе от совещаний будет только головная боль и видимость работы.
Miro
Визуальный подход к формализации своих мыслей – очень сильный инструмент. Я например, когда начал пользоваться Miro (так совпало, что это произошло с трудоустройством туда), был просто восхищён и восхищаюсь до сих пор. Тут я ограничусь лишь парой пунктов ниже, лучше, как говориться «один раз попробовать, чем сто раз услышать».
Когда готовлю какую-то презентацию и не уверен в каком-то моменте – я просто оставляю комментарий, фиксирую мысли пусть даже в не очень чёткой форме, потом возвращаюсь. Даже если это комментарий просто для себя.
Когда с кем-то обсуждаешь какую-нибудь доску и человек говорит замечания – опять же делать заметки в комментариях на той же доске, чтобы не потерялось и для себя и для коллег.
Confluence
О последнем, но не в смысле важности, инструменте, я напишу лишь кратко:
Не стоит увлекаться огромным объёмом текста. Ваше эго это конечно потешит, но люди скорее всего просто не будут читать.
Если всё-таки нужно «много букв» – постарайтесь сделать хорошую структуру, чтобы пользователи могли быстро находить нужную информацию и эта информация была легко воспринимаема.
Существует огромное количество плагинов, используйте их. Например, вместо выделения текста цветом для описания предупреждения о плохой практике – лучше использовать виджет «Warning box». Оно и выглядеть будет лучше и в едином стиле позволит выдержать разные страницы документации, что облегчает восприятие.
Над развёрнутым описанием предлагаю подумать на основе перечисленных выше мыслей.
Заключение
Человеческий мозг ограничен, он просто неспособен держать и обрабатывать тот объём информации, который сейчас нас окружает в личной жизни и на работе. А вот мозг в связке с современной техникой и программным обеспечением – поднимает нас на просто немыслимые ранее высоты. Вот только для начала надо «загрузить свой мозг», чтобы было что «выгружать» в заметки. Пустой голове никакой софт не поможет ?
