А ещё у меня есть анонс для разработчиков из Тбилиси! Мне написал человек, который устраивает некоммерческий оффлайн-ридинг в Тбилиси по Computer Science.

Ближайшая встреча будет 27 января (вторник) в 20:00. Ниже вставлю анонс от Дамира.

Собираю оффлайн ридинг по computer science в Тбилиси

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

Важно: это не учебный курс, а именно формат совместной работы. Встречи планируются каждые две недели. 27 января в 20:00 будем обсуждать небольшую статью «Some Constraints and Tradeoffs in the Design of Network Communications» - Akkoyunlu, Ekanadham, Huber, в которой анализируется проблема синхронизации систем по ненадёжному каналу связи (т.н. «Задача двух генералов»).

Дальше будем формировать список для чтения вместе, но пока предлагаю следующие тексты:
- «The Byzantine Generals Problem» - Leslie Lamport, Robert Shostak, Marshall Pease
- «Cognitive Complexity. An Overview and Evaluation» - Ann Campbell
- «Go To Statement Considered harmful» -  Edsger Dijkstra

Если вы хотите присоединиться, напишите @pilatsis (и, пожалуйста, добавьте пару слов о себе)

Обо мне: разрабатываю бек-энд в game-dev и люблю lock-free алгоритмы

Звучит очень круто, я бы ходил. Никто в Ереване, случаем, не устраивает? :)

Хочу поделиться способом, который помогает мне поддерживать актуальный контекст проектов, которые я веду, и более эффективно двигать их дальше

Проектом я тут называю всё, что требует нескольких шагов для реализации (прям по GTD, да 🥸 ). Поскольку карьерно я выбрал именно путь с менеджментом, то в какой-то момент таких проектов стало очень много: развитие нового стека, разработка нового сервиса, автоматизация чего-либо и так далее.

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

• Цель проекта
• Текущий статус
• Следующее действие
• Узкое место
• Люди
• Ожидания по Deadline
• Что считать успехом

Многие увидят здесь GTD, и не зря, это правда классная штука. Но он лишь частично здесь.

Цель проекта
Конкретная осязаемая польза от проекта в одном предложении. Именно цель помогает помнить зачем проект вообще нужен, а ограничение в одно предложение помогает не размывать внимание. Кроме шуток, формулированию цели можно уделить процентов 80 времени, а 20 остальным вопросам.

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

Текущий статус
Одно предложение для обозначения текущего состояния: продумана архитектура; на верификации у заказчика; разрабатывается модуль А и так далее. Помогает быстро вспомнить на чём вы остановились.

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

Узкое место/критическая проблема
Что больше всего мешает двигаться прямо сейчас? Например, вы хотите "ускорить ответ статистики с 10 до 2 секунд для аналитиков", но база перегружена обилием INSERTов (фантазирую). Тогда узким местом может быть "для чтения и записи используется одна и та же база". Этот пункт помогает сфокусировать внимание на том, что действительно его требует, а не пытаться заниматься чем-то более понятным и простым, но не сильно помогающим решить проблему.

Узкое место и проблема могут меняться по ходу работы над проектом, этот пункт важно актуализировать (как и предыдущие два).

Люди/ключевые партнёры
Кто влияет на проект? От кого проект зависит? Будет особенно здорово, если вы напишете человека и его конкретную роль, в духе "Иван – владелец, распределяет бюджет, Сергей – админ, …".

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

Ожидания по Deadline
Здесь важна не конкретная точная дата, а именно контекст, который влияет на дедлайны. Например, после какого-то события проект может вообще потерять актуальность, либо проект вполне может ждать, но лучше успеть до сезонного всплеска нагрузки и так далее.

Этот пункт помогает понять нужно ли проект пушить прямо сейчас и актуален ли он в принципе.

Чёткое понимание дедлайна с одной стороны помогает снизить когнитивную нагрузку, потому что вы смело можете выгрузить проект из головы, если он сейчас не важен. А с другой стороны помогает избежать излишнего перфекционизма, когда есть понимание, что после какого-то события он просто потеряет актуальность.

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

(продолжение)

Этот пункт и должен помочь вам в конкретный момент решить, что проект можно считать завершённым (пусть и не идеальным). Это должен быть чётко сформулированный пункт с ответом в стиле "да/нет" без размытых формулировок и идеальности. Обычно он коррелирует с "узким местом".

В итоге у вас должен получиться короткий документ на 7-8 предложений, который поможет именно вернуться в контекст проекта. Это не лог, не список задач, не inbox, это точка входа.

А как у вас устроено управление множеством проектов? К чему вы пришли за свой опыт? Будет здорово услышать ваше мнение про то, насколько вопросы выше оказались для вас банальными, или у меня когнитивное искажение "это и так понятно" 😕