Хочу поделиться способом, который помогает мне поддерживать актуальный контекст проектов, которые я веду, и более эффективно двигать их дальше Проектом я тут называю всё, что требует нескольких шагов для реализации (прям по GTD, да 🥸 ). Поскольку карьерно я выбрал именно путь с менеджментом, то в какой-то момент таких проектов стало очень много: развитие нового стека, разработка нового сервиса, автоматизация чего-либо и так далее. Самое сложное – переключаться между разными контекстами. Буквально каждое переключение у меня сопровождалось ступором. И спустя много итераций сформировались 7 вполне банальных вопросов, которые снижают сложность возвращения к проекту. • Цель проекта • Текущий статус • Следующее действие • Узкое место • Люди • Ожидания по Deadline • Что считать успехом Многие увидят здесь GTD, и не зря, это правда классная штука. Но он лишь частично здесь. Цель проекта Конкретная осязаемая польза от проекта в одном предложении. Именно цель помогает помнить зачем проект вообще нужен, а ограничение в одно предложение помогает не размывать внимание. Кроме шуток, формулированию цели можно уделить процентов 80 времени, а 20 остальным вопросам. Во время работы будет множество выборов: где упороться и сделать сложнее, где поискать существующий опыт, а где можно не заморачиваться. Если вы хорошо сформулируете цель и ответ на вопрос "зачем?", то такие решения будут даваться намного проще. Текущий статус Одно предложение для обозначения текущего состояния: продумана архитектура; на верификации у заказчика; разрабатывается модуль А и так далее. Помогает быстро вспомнить на чём вы остановились. Следующее действие Конкретное осязаемое действие, которое вам нужно совершить, чтобы двигать проект дальше. Заполнять его надо до того, как вы переключитесь на другой проект (до момента выхода), а конкретно после того, как сделали предыдущее действие. Помогает быстро понять, что от вас требуется дальше. Узкое место/критическая проблема Что больше всего мешает двигаться прямо сейчас? Например, вы хотите "ускорить ответ статистики с 10 до 2 секунд для аналитиков", но база перегружена обилием INSERTов (фантазирую). Тогда узким местом может быть "для чтения и записи используется одна и та же база". Этот пункт помогает сфокусировать внимание на том, что действительно его требует, а не пытаться заниматься чем-то более понятным и простым, но не сильно помогающим решить проблему. Узкое место и проблема могут меняться по ходу работы над проектом, этот пункт важно актуализировать (как и предыдущие два). Люди/ключевые партнёры Кто влияет на проект? От кого проект зависит? Будет особенно здорово, если вы напишете человека и его конкретную роль, в духе "Иван – владелец, распределяет бюджет, Сергей – админ, …". Благодаря этому вы знаете, кому нужно распределять знания по проекту, к кому обращаться в случае определённых проблем, какие у вас риски, кто знает, кто решает и кто делает. Ожидания по Deadline Здесь важна не конкретная точная дата, а именно контекст, который влияет на дедлайны. Например, после какого-то события проект может вообще потерять актуальность, либо проект вполне может ждать, но лучше успеть до сезонного всплеска нагрузки и так далее. Этот пункт помогает понять нужно ли проект пушить прямо сейчас и актуален ли он в принципе. Чёткое понимание дедлайна с одной стороны помогает снизить когнитивную нагрузку, потому что вы смело можете выгрузить проект из головы, если он сейчас не важен. А с другой стороны помогает избежать излишнего перфекционизма, когда есть понимание, что после какого-то события он просто потеряет актуальность. Что считать успехом Любой проект при желании можно продолжать бесконечно, рефакторить, пересматривать и так далее. И это нормально. Но проект про конечную цель. Ваше внимание всегда можно потратить на принесение новой пользы, а хвосты этому мешают.