GTD *

Как новенький сервис превращается в легаси помойку

Свершился тот день, когда начальство аппрувнуло переписать один из ключевых сервисов. У нас появился шанс начать всё с чистого листа. Сделать как надо, а не как сделали обезьяны до нас. Давайте рассмотрим самый частый сценарий во время переписывания сервиса.

1 шаг. Восторг и энтузиазм

Залетаем на радостях. Думаем над архитектурой. Пишем чистейший, как слеза младенца, код. Применяем все свои знания и опыт, а ещё выплескиваем все паттерны и технологии, которые накопились за годы воздержания.

2 шаг. Не хватает тяги

Наша ракета отлично стартанула. Вкушаем первые плоды переписанного сервиса. Радуемся. Но начинаются первые проблемы. Бесплатный пробный период хорошей жизни закончился - нагрузка начинает возвращаться обратно. В начале нам дали люфт. Но халява быстро кончилась — бизнесу снова понадобились фичи "на вчера". Вынуждены меньше фокусироваться на прекрасном будущем и всё больше концентрироваться на грустном настоящем. Начинаем активно поддерживать текущую версию сервиса и параллельно разрабатывать новую.

3 шаг. Кто же убийца?

Задач у нас в работе много, релиз на носу. Поддержка фичей на старой версии становится приоритетом, ведь бизнес пользуется именно ей. Кидаем все силы на релиз. За разработку нового сервиса пока будет отвечать разработчик Вася. Остальные поддерживают текущий сервис. Мы не должны останавливать ни на секунду разработку нового.

4 шаг. Кто мы и откуда пришли

Энтузиазма поубавилось. Сервис уже переживает первые послабления в качестве в угоду скорости. Надо скорее дописывать MVP. Качество, структура и масштабируемость перестали быть приоритетом. Руководство уже и не помнит, зачем всё это затеяли. Сама идея становится всё более призрачной.

5 шаг. Мы не сеем, мы жнём

MVP готово. Переезжаем на наше новое детище. На старый сервис можно поставить печать [DEPRECATED] и убрать на задворки. Начинаем пользоваться и выполнять новые задачи уже там.

6 шаг. Мне кажется, мы здесь уже были

Через пару недель разработки появляется стойкое ощущение дежавю. Сервис вроде новый, построен аккуратнее. Но почему-то замечаются те же ошибки. Местами - те же подходы. Уже есть зоны кода, в которые никто не решается лезть. "Чёрные дыры" проекта. Да и багов меньше не стало. Мы же не сделали вторую версию такой же кривой, как первая? Мы же могли потратить время и ресурсы впустую? Ведь так?

7 шаг. Убийцей был дворецкий!

Давайте анализировать, как так вышло. Собирается команда на митинге и начинает ретроспективу. Кто виноват?

Первое, что приходит в голову - ограниченный фокус внимания на новом сервисе. Мы параллельно поддерживали старую систему, и ресурсы постоянно утекают туда.

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

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

Четвертое - ретроспективу стоило провести до старта. Определиться какие ошибки были совершены в старом сервисе и учесть их в новом.

Может, дело во всех этих факторах сразу. Кто знает. Но итог мы видим: новый сервис довольно быстро начал повторять судьбу старого. Возможно, правильнее было есть слона по кусочкам - переписывать раздел за разделом в старом сервисе, интегрировать и тестировать на ходу, а не замахиваться на «новое идеальное» целиком.

Заметки в никуда

Ценность разработчика. Мысли о том самом…

Собрал парочку мыслей о тех качествах, которые должен иметь в себе действительно ценный разработчик.

Баланс между качеством и скоростью

Качество и скорость - это две противоположные крайности одного спектра.

Если мы ставим на высокий темп разработки, то всегда платим качеством. Вследствие этого стоимость разработки растет за счет повышения энтропии проекта. Сразу появляется тяжело поддерживаемая кодовая база, а скорость доставки фичей падает. Со временем поддержка начинает пожирать все больше ресурсов.

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

Хороший разработчик должен быть посередине этого спектра. Каждое решение им принятое должно:

• закладывать минимальную архитектуру, которую без проблем смогут понять и поддерживать другие

• иметь возможность базового масштабирования, без фанатизма, но с заделом на возможные изменения завтра

• учитывать временные рамки, воспринимая время как ограниченный ресурс

• работать с ограничениями, которые всегда есть, иначе легко сойти с намеченного плана

Продуктовое мышление

Хороший разработчик не ограничивается своим куском кода и клочком текста в ТЗ. Перед тем как приступить к задаче, важно выстроить полную картину. Зачем эта задача бизнесу? Кому это нужно? Какую боль пользователя решает? Чего это нам будет стоить? Иногда ответы на эти вопросы проясняют картину лучше, чем ТЗ от менеджера.

Спор "как правильно"

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

Предсказуемость

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

Работа с неопределенностью

Пора привыкнуть - ТЗ чаще всего пишется через жопу. Заказчики переобуваются на ходу. Менеджеры не фильтруют хотелки бизнеса. Классика: переделывать функционал на ходу, искать недостающую инфу и работать с минимумом данных. Неопределенность - это главное ограничение, и его нужно учитывать всегда, особенно при оценке сроков. Хороший разработчик закладывает время не только на код и риски, но и на поиск информации, а также на возможные дыры в ТЗ.

Долгосрочность решений

Хороший разработчик думает "как этот кусок кода будут поддерживать через год", а не как бы закрыть задачу и быстрее взять новую. Долгосрочные решения выгоднее бизнесу: платим в начале больше, но потом пользуемся бесплатно. С краткосрочными наоборот - получаем результат быстро и дешево, но расплачиваемся постоянно.

Заметки в никуда. Подписаться

Как не сливать бюджет на разработчиков без задач?

Представим ситуацию. Большой аутсорс, 5 распределённых команд, у каждой обычно в работе по 1–3 проекта. Наступает момент, когда текущий проект сдан, а новый проект ещё не утверждён: документы в стадии подписания, а ТЗ ещё не сформировано. Команда разработчиков ждёт отмашки, возникает свободное время между проектами. Что делать? Бюджет утекает на разработчиков, которые ничем не заняты. Какой выход из ситуации, когда кончились задачи?

Я очень часто сталкиваюсь с этим кейсом, и по моему опыту есть решение. Если дать разработчику волю, он скорее свалит в кофейню, чем будет просиживать штаны, пока нет проекта или задач. Пустая трата ресурсов для вас обоих. Но из свободного времени можно извлечь выгоду как для команды, так и для самого разработчика - последний выиграет даже больше. Речь идёт об обучении. И я говорю не о курсах или конференциях. Лучшее обучение - это практика. В одной из команд мы сделали следующее. Каждому разработчику дали задание: описать свой пет-проект, который он хочет реализовать, и список технологий, которые он при этом прокачает.

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

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

Что мы в итоге имеем и в чём выгода?

Вместо просиживания штанов разработчик качает навыки, причём те, которые он сам выбрал, на проекте, который он сам захотел. Тем временем мы не вкладываем дополнительный бюджет на курсы и прочее обучение. Сотрудник прокачивается более органически. Компания по-прежнему платит оклад, но команда продолжает быть в тонусе, потому что мы даём им творческий карт-бланш. Мотивация от этого выше, чем скучать в ожидании нового проекта.

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

Заметки в никуда

Гигачад на сцене, быдлокодер в опенспейсе

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

Пока очередной гигачад рассказывает на конференции о новой модной технологии, которая поменяет направление твоей работы на 180 градусов и заставит чувствовать себя устаревшим, тем временем твои "сокамерники" продолжают ковырять устаревшие npm-пакеты и разбирать очередную легаси-свалку из "новых" и "инновационных" подходов.

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

Мне кажется, давно пора признаться самим себе, что разработка делится на два типа: "сказки об идеальных решениях" и "настоящая работа", где первые треплют языком, а вторые решают проблемы бизнеса - хоть это в 95% случаев и превращается в жопоболь через какое-то время.

На самом деле мы имеем две крайности: "глянец" и "решения быстрого приготовления". Наша задача - соблюдать баланс между этими двумя полюсами.

Заметки в никуда

Я узнал о... #2: Obsidian

Obsidian - это система для ведения заметок с построением графов связей и open source плагинами. Все заметки хранятся локально в .md файлах, но умеют синхронизироваться между устройствами всего за $5.

Много раз слышал о ней от разработчиков и GTD‑извращенцевфанатиков. Причём многие за счёт плагинов из программы для заметок делают звездолёт - с календарями, Kaban'ами, SQL запросами и всевозможными синхронизациями.

Вот и я решил попробовать писать в нём заметки и понять, действительно ли удобно так структурировать информацию.

Вообще, у меня есть самописная CRM‑система для себя же самого. В ней есть Kanban‑доски по всем моим активностям, календарь с планированием в рамках дня и недели, система заметок, сделанная из WYSIWYG‑редактора и система трекинга привычек.

Всё это с синхронизацией между компьютером и телефоном.

В какой-то момент она даже бэкапила все мои проекты до появления Postgresus'a.

Но вот заметки - была большая боль. Эдакий Apple Notes на минималках. Нет вложенности, нет нормального форматирования, нет связей и немного притормаживает.

За неделю использования Obsidian вижу следующие плюсы:

• всё работает очень шустро за счёт локального хранения и .md формата;

• добавляет спокойствие из-за хранения всего локально (даже если Obsidian умрёт — все файлы останутся);

• удобное форматирование и связи;

• удобно рисовать графики через Canvas и mermaid диаграммы (как PlantUML, но для .md);

• я начал структурировать всё, что читаю или узнаю.

Пока не нравится:

• не хватает AI с автокомплитом/автофиксом (как в Cursor'e);

• хотелось бы в заметки вставлять Google таблицы.

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

Потом посмотрю, какие всё-таки плагины стоит затянуть, и снова вернусь с отчётом в канал.

---

Мой Telegram канал про разработку.

Не хотелось бы попасть в зону стресса. А в зону паники - тем более. Поэтому закладывайте время достаточно на случай, если всё пойдёт не по плану.

Пост, закрывающий мою «неделю списков» на Хабре

Представьте себе торговый зал какого-нибудь большого супермаркета. Покупатели снуют по проходам между полками со своими тележками. Кто-то хаотично бродит по рядам, задумчиво разглядывая товары. Кто-то быстро и со знанием дела перемещается от отдела к отделу. Но никто не сравнится по твёрдости и целенаправленности с мужчиной, у которого в руках Список Покупок, написанный аккуратным женским почерком. Этот человек точно знает, что ему надо купить — все маркетологи и мерчендайзеры мира перед ним бессильны. Ни на йоту не отступая от заданной программы, он последовательно и методично наполняет свою тележку. Этот покупатель предельно серьёзен и сосредоточен, ведь все требования списка должны быть соблюдены безукоризненно. Можно только гадать, что бы он делал без этого ценного листочка бумаги, заполненного важной информацией о наименованиях и требуемом количестве продуктов и предметов.

Актуальное... 😎

Жена отправляет мужа-программиста в магазин:
— Купи батон хлеба, если будут яйца — возьми десяток.
Муж возвращается из магазина с десятью батонами.
— Ты зачем столько хлеба купил?
— Так ведь яйца были...

Почитать про списки:

• Строкам грустно в одиночестве. Мои простые правила оформления списков

• Список дел в бумажном блокноте — островок реальности в виртуальном море

Подкаст «Айтидо» №4: phygital-продукты, Markswebb и поиск баланса

Привет! Это подкаст «Айтидо» от команды мобильной разработки Альфа-Банка 🎙

В новом выпуске беседуем с Сергеем Болдыревым, CPO Phygital stream.

Обсуждаем карьерный путь от создания рок-группы до управления продуктами. Сергей делится опытом развития продуктов и рассказывает про рутину продакт-менеджеров. Он объясняет, почему продактам иногда легче в менеджменте, чем IT-специалистам, и почему важно избегать превращения в «пушеров». Говорит о лидерстве в рейтинге Markswebb и обсуждает с ведущими, как балансировать между бизнес-целями и IT-задачами.

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

Ссылки на подкаст:

🔗 RuTube
🔗 YouTube
🔗 ВКонтакте
🔗 Яндекс Музыка

А ещё подписывайтесь на Tелеграм-канал Alfa Digital, там много интересного о корпоративной культуре и технологиях.

12 техник управления временем и задачами, помимо «Метода помидора»

Часть вторая

Правило 3-2-1. Каждый день вы фокусируетесь на трех основных задачах, двух дополнительных и одной по саморазвитию или личному росту. Помогает сосредоточиться на ключевых целях и приоритетах.

Reverse Planning. Сперва определяем желаемый результат и план шагов по его достижению. Затем каждый этап разбиваем на мелкие задачи и временные рамки. Получается ясный план действий с таймлайном.

Swiss Cheese. По аналогии с головкой швейцарского сыра с дырками, разбиваем большие и сложные задачи на более мелкие и управляемые. Остается только разрезать всё это на куски-задачи выполнить их. 

Метод Айви Ли. Разработан в начале 20-го века консультантом по управлению временем Айви Ли. Метод заключается в составлении списка из шести наиболее важных задач, которые вы выполняете за день в порядке приоритетности. Начинать нужно с первой задачи, и пока вы ее не закончите, нельзя переходить к следующей. Невыполненные задачи переносятся на следующий день.

Task batching. Это техника группировки задач, где для каждой группы выделяется свой период времени. Например, вы объединяете ответы на письма и звонки и выполняете их в установленное время. Это помогает не распыляться.

Правило 90/90/1. Метод предполагает, что вы посвящаете первые 90 минут каждого утра в течение 90 дней на работу над самым важным проектом или задачей. Это помогает создать привычку приоритизации важных задач и эффективно расходовать силы.

Часть первая — по ссылке.

12 техник управления временем и задачами, помимо «Метода помидора»

Часть первая

Техника GTD. Эта система поможет организовать все ваши задачи и освободить ум от стресса и беспокойства о них. Принцип работы с задачами по GTD в пяти шагах: сбор, обработка, организация, обзор, действие.

Метод Парето. В его основе — тезис о том, что примерно 80% результатов происходит от 20% усилий. Другими словами, большинство наших результатов происходят от небольшой доли наших усилий. Следовательно, важно сосредоточиться на этих ключевых 20% для супердостижений.

Eat That Frog. Если начать день с выполнения самой неприятной задачи — буквально «съесть эту лягушку», — то остальные задачи покажутся легкими по сравнению с ней. Помогает избежать прокрастинации и повышает продуктивность.

Time Blocking. Этот метод заключается в разделении рабочего дня на временные блоки под конкретные задачи. Например, вы можете зарезервировать отдельные отрезки для работы над проектом, ответов на письма, звонков и т. д. Это помогает создать структуру и фокусироваться на конкретных задачах.

Zero-Based Calendar. Этот метод предполагает, что вы планируете каждый час рабочего дня заранее, не оставляя пустых слотов. Так не остается места для пустой траты времени и простоев.

2-Minute Rule. Этот метод предложен в книге Getting Things Done. Он гласит, что если задача занимает менее двух минут, ее следует выполнить немедленно, а не откладывать на потом. Это помогает избежать скопления небольших задач и повышает производительность.

? Ещё раз об интеграции Notion и Apple Shortcuts

Пару лет назад я рассказывал, как можно использовать Apple Shortcuts, чтобы настроить быстрое добавление записей в инбокс. А в прошлом году поделился шаблоном, где для использования достаточно вставить токен notion и идентификатор базы. Но вчера я заметил, что теперь даже этого делать не нужно.

Наконец-то, Notion добавил готовые экшины для добавления записей в Inbox, всё настраивается за минуту.  Жаль, что новый способ работает только на телефоне, приложение Notion для Mac не поддерживает эти действия.

Как реагировать на обесценивание

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

Первая мысль - ответить хейтеру и поставить его на место.

Вот только нет у меня нет никакого желания атаковать человека в ответ. Я понимаю, какая огромная боль и одиночество стоит за таким поведением. Это его беда, а не вина.

Как же отреагировать на агрессивное обесценивание правильно?

Не надо воспринимать людей, критикующих Вас, как врагов. Нужно воспринимать их как своих учителей. Если Вас что-то цепляет, значит у Вас что-то торчит.

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

Вот тогда появляются “хейтеры”. И в комментариях, и в жизни. Вот это раздувшееся Эго они и подсвечивает.

Именно “хейтеры” помогают нам сохранить объективный взгляд на себя и не впасть в гордыню, болезненные иллюзии собственного величия.

Понимание этого простого факта меняет все!

Лично у меня вместо злобы и раздражения появилось внутри тепло и чувство благодарности.

Не важно, что Вы отвкетите. Гораздо важнее, что Вы при этом почувствуете. Наполнитесь ли ядом злобы и сомнений или выработаете иммунитет к обесцениванию и лести, который позволит Вам объективно относится к себе и другим, признавать свои слабости и ошибки и идти вперед!

Круговорот обесценивания в природе

Знаете, почему Вас часто пытаются обесценить, помножить на ноль и обвинить в некомпетентности?

Люди это делают, чтобы не чувствовать собственной неполноценности и ущербности. Они хотят, пусть на краткий миг, почувствовать себя хорошими и достойными людьми.

Я не могу себе представить самодостаточного и довольного собой и жизнью человека, обесценивающего кого-то другого.

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

А потом жертва превращается в агрессора и сама начинает обесценивать других, чтобы поправить пошатнувшуюся самооценку.

Обесценивание заразно. Оно передается от человека к человеку, распространяясь как пожар. Причем, люди делают это автоматически, даже не отдавая себе отчета, что причиняют кому-то боль.

Есть только один способ это остановить - перестать обесценивать самого себя. Перестать концентрироваться на промахах и ошибках, начать видеть свои успехи и достижения. Осознать и принять свою ценность, которая не зависит от чужих оценок. Снять себя с тормоза, наконец.

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

Люди не рождаются лидерами и творцами. Они становятся ими!

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

Вот только много ли Вы знаете таких людей?

Гораздо больше тех, которым не так повезло. Они так и не смогли вырасти. В глубине души они остались маленькими детьми, которым не хватило внимания и поддержки, чтобы расти и развиваться, не бояться делать первый шаг и пробовать новое.

У них тоже много внутренней энергии. Они тоже могли бы быть лидерами, созидателями и творцами. Но их энергия полностью уходит на борьбу с внутренними конфликтами, страхами и запретами, на борьбу с самим собой.

Это сжатая пружина, которая разворачивается с огромной силой, если убрать все те проржавевшие болты, которые ее так долго сдерживали. Вот тогда освобождается такое количество энергии, которое не заметить и не использовать по назначению просто невозможно.

Как будто у Сизифа отобрали камень и сказали: “Ты свободен. Ты можешь делать все, что ты хочешь. Весь мир перед тобой!”

Стоит только снять себя с тормоза, избавиться от внутренних страхов и запретов. Разрешить себе быть!

Быть лидером, созидателем и творцом.

Оставить прошлое в прошлом и сделать шаг в будущее.

Вы готовы сделать этот шаг?

Как перестать себя обесценивать и начать жить и работать в свое удовольствие

Раньше я часто обесценивал себя и свою работу. Поэтому выработал ряд правил, которые помогают мне не скатываться в негатив и самобичевание.

? Записывайте и перечитывайте свои достижения. Я делаю это в Телеграмм.
? Не обобщайте (Я ничего не умею). Найдите, чем конкретно Вы недовольны и как это исправить.
? Ставьте реальные и достижимые цели. На день. Неделю. Месяц. 
? Хвалите себя за все, что сделало Ваш день лучше.
? Смотрите на себя как на победителя (что имеем то и было целью).
? Создайте опору внутри себя на прошлое и настоящее. (Я сделал, я делаю)
? Не предсказывайте будущее (Я не справлюсь). 
? Будьте активным. Воплощайте мечты в жизнь. Пробуйте новое.
? Не откладывайте. Делайте сразу.
? Сместите акцент с вопроса «Кто я?» на вопрос «Что я делаю?», «С кем делаю?»,  «Для кого делаю?».
? Не замыкайтесь в себе, идите к людям.
? Проявляйтесь. В соцсетях, на конференциях. В личном общении.
? Будьте внимательны и к своим чувствам, и к чувствам других
? Не пытайтесь помочь, если Вас об этом не просят.
? Составьте список людей, к которым вы можете обратиться за помощью по разным вопросам
? Определите для себя, чем хотите и можете помочь другим Вы.
? Не сравнивайте. Если Вы видите чужой успех - мысленно похвалите человека. Он тоже молодец!
? Не общайтесь с теми, кто Вас обесценивает. Удаляйте их из своего окружения и из друзей в соцсетях.

А как Вы себе помогаете сохранять позитив и веру в себя?

После того, как вы становитесь лидом, у вас резко возрастает объем информации, который нужно обрабатывать. В этом помогут следующие инструменты:

Календарь. Используйте его, чтобы планировать встречи со своей командой, проводить встречи один на один, общаться с другими отделами в ходе согласований, бронировать время для себя (обед или сессия какой-либо работы). Обязательно используйте автоматические напоминания. Главное помните, что календарь - это не список дел.

To-Do-List. Создавайте приортизированные списки дел, которые необходимо выполнить в течение дня или недели. Заносите туда даже самые банальные вещи, которые кажутся глупыми: "Проверить борду спринта". Чем меньше вы будете держать в голове, тем проще вам будет сосредоточиться на деле.

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

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

Сделайте работу с этими инструментами ежедневным ритуалом, и вам станет гораздо легче работать.