Cumulative Flow Diagram

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

💡Что такое Накопительная диаграмма потока (CFD)?

CFD — это диаграмма, которая отображает количество задач в проекте в разрезе их статусов (например, "Бэклог", "В работе", "Тестирование", "Готово") на протяжении всего времени.

По оси X: Откладывается время (дни, недели).
По оси Y: Откладывается кумулятивное (накопленное) количество задач.
Цветные полосы (слои): Каждая полоса представляет собой один из статусов workflow. Ширина полосы в любой момент времени показывает, сколько задач находится в этом статусе.

💡Зачем она нужна?

🟢Визуализация потока и выявление узких мест (Bottlenecks)

Это главная сила CFD. Если какая-то из полос (например, "Тестирование") начинает резко расширяться, это явный сигнал, что на этом этапе возник затор. Задачи прибывают быстрее, чем убывают. Команда может среагировать и "разгрузить" проблемный этап.

🟢Расчет ключевых метрик

Из диаграммы можно легко извлечь три фундаментальные метрики Kanban/Agile:

🟠Скорость выполнения (Throughput): Количество задач, завершаемых за единицу времени (крутизна верхней линии "Готово").

🟠Время цикла (Cycle Time): Среднее время, которое задача проводит в системе (от момента начала работы до завершения). На диаграмме это горизонтальное расстояние между входом в работу и выходом.

🟠Время выполнения заказа (Lead Time): Общее время от поступления задачи в систему (бэклог) до ее завершения.

💡Как "читать" CFD? Анализ паттернов

🟢Здоровый поток: Диаграмма выглядит как набор параллельных полос, которые плавно поднимаются вверх. Верхняя линия ("Готово") имеет стабильный наклон. Это значит, что команда работает предсказуемо.

🟢Расширяющийся средний слой ("В работе"): Полоса "В работе" становится шире. Это признак перегруженности команды (Work in Progress, WIP). Начато много задач, но мало что завершается.

🟢Расширение конкретного слоя (Узкое место): Как уже упоминалось, если слой "Тестирование" растет, значит, тестировщики не справляются с потоком.

🟢Уменьшение скорости завершения: Верхняя линия ("Готово") становится более пологой. Это значит, что скорость выполнения задач падает.

✨ Для желающих разобраться подробнее с CFD есть отличная статья, которая покрывает множество кейсов использования данной диаграммы.

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

💡Ключевая идея: мы не бездельничаем, а подчиняемся более сильным и импульсивным сигналам от наших "неявных списков" (чаты, почта, открытые вкладки), которые вытесняют задачи из нашего основного, формального плана.

🟠Правильный вопрос: Не "почему задача не делается?", а "почему я её не делаю?" и "это системная проблема или единичный случай?".

🟠Диагностика: Если проблема не в одной задаче, а в классе задач, и вы при этом всё равно чем-то заняты, значит, у вас есть неявный список задач.

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

🟢Решение: Необходимо осознать существование этих неявных списков, переносить задачи из них в единый основной список и дисциплинированно работать именно из него.

❔ Делитесь на сколько много неявных списков у вас и как вы с ними боретесь.

Ну что я готов прокачивать управленческие скилы 🤓

У каждого своя боль 🚩

Зависимости в программном обеспечении (Coupling)

Ни одна программа в мире не существует в вакууме. Все её компоненты зависят друг от друга. Задача архитектора — не избавиться от зависимостей полностью (это невозможно), а управлять ими. Сегодня разберем, какие бывают типы связности (coupling) и почему это важно для создания гибких и надежных систем.

Связность — это степень зависимости между компонентами.

Любой компонент А зависит от компонента Б, если ему нужен Б для компиляции, работы, установки или тестирования. Связность бывает на разных уровнях: не только в коде, но и в инфраструктуре.

Типы связности — это инструмент для принятия правильных решений.

Знание конкретных типов помогает архитекторам предвидеть последствия изменений и выбирать оптимальные способы взаимодействия между модулями.

Давайте разбираем типы связности

🟢Связность через использование/delegation
Класс А напрямую использует публичные переменные или методы класса Б. Поможет инкапсуляция. Делайте переменные приватными и обращайтесь к ним через геттеры.

🟢Связность через композицию
Жесткая связь, когда класс Б является неотъемлемой частью класса А и не может существовать без него (как двигатель в автомобиле).

🟢Связность через создание
Класс зависит от фабрики или другого класса, который его создает (паттерны Factory, Abstract Factory).

🟢Связность через наследование
Самая жесткая связь в ООП. Дочерний класс тесно связан с родительским, наследуя всё его поведение. Изменения в родителе немедленно влияют на всех потомков.

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

🟢Временная связность
Компонент А не может выполнить свою работу, пока компонент Б не завершит свою и не отдаст результат (например, нельзя оплатить заказ, пока не добавлены товары в корзину).

🟢Связность через типы данных
Многие классы зависят от одного центрального типа данных (например, UserEntity). Любое изменение в этом типе заставляет меняться всех, кто его использует.

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

🟢Связность через оборудование
Низкоуровневая связь, когда компоненты взаимодействуют через общую память или аппаратные ресурсы.

💡Связность неизбежна, но ею можно управлять.

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

Сильная связность (наследование, композиция) — не всегда зло, но требует осторожности, так как делает изменения дорогими и рискованными.

Готов ли ты стать тимлидом?

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

1. Про лидерство и управление командой
🟢Почему я хочу стать тимлидом?
🟢Какой у меня стиль управления? (Авторитарный, демократический, либеральный?)
🟢Готов ли я брать ответственность не только за свой код, но и за работу команды?
🟢Как я буду мотивировать команду?
🟢Как я буду справляться с конфликтами в команде?

2. Про технические навыки
🟢Хорошо ли я разбираюсь в технологиях, с которыми работает команда?
🟢Готов ли я тратить меньше времени на программирование и больше на архитектуру, ревью кода, менеджмент?
🟢Как я буду развивать технические навыки команды?

3. Про менеджмент и процессы
🟢Какие методологии управления проектами я знаю (Agile, Scrum, Kanban)?
🟢Как я буду планировать работу команды?
🟢Как я буду расставлять приоритеты между задачами?
🟢Как я буду оценивать сроки выполнения задач?
🟢Как я буду проводить ретроспективы и улучшать процессы?

4. Про коммуникацию
🟢Умею ли я ясно и понятно объяснять задачи?
🟢Как я буду общаться с заказчиками, менеджерами продукта, другими командами?
🟢Как я буду давать и принимать обратную связь?
🟢Готов ли я быть "щитом" между командой и внешними давлениями?

5. Про развитие команды
🟢Как я буду помогать команде расти профессионально?
🟢Как я буду распределять задачи в зависимости от навыков сотрудников?
🟢Как я буду оценивать работу членов команды?
🟢Как я буду нанимать новых людей в команду?

6. Про стресс и баланс
🟢Как я буду справляться со стрессом?
🟢Как я буду сохранять баланс между технической и управленческой работой?
🟢Готов ли я к тому, что теперь моя работа — это не только код?

7. Про карьерные ожидания
🟢Вижу ли я себя в менеджменте в долгосрочной перспективе?
🟢Хочу ли я дальше расти до CTO, VP of Engineering или останусь на уровне тимлида?

🚀 Если ты ответил себе на большинство вопросов и уверен в своих силах — значит, ты на правильном пути!

💡 Если есть сомнения — подумай, какие навыки нужно прокачать.

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

Как настоящий тимлид, желаю вам:
🟢чтобы задачи приходили чётко сформулированными — без «надо что‑то сделать, сами разберётесь»;
🟢чтобы дедлайны были реалистичными — а не «вчера»;
🟢чтобы ревью кода приносило радость, а не желание всё переписать с нуля;
🟢чтобы баги находили себя сами — и исчезали без следа.

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

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

И помните: если что‑то не работает — попробуйте перезагрузить не только компьютер, но и себя. А если и это не помогло — зовите тимлида!