Управление проектами в маленькой команде: лёгкие методы

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

Я набил немало шишек. В начале, когда я разрабатывал продукты в одиночку, никакого управления не было — фича, которая должна была занять две недели, растянулась на два месяца, потому что я постоянно отвлекался на новые идеи. Когда команда выросла до трёх человек, я попытался скопировать подход крупных компаний: Jira, диаграммы сгорания задач, еженедельные отчёты. Через неделю один из коллег спросил меня в личном чате: «Можно ты просто скажешь, что мне делать завтра?»

После всех этих мучений я выработал несколько лёгких методов, адаптированных под команды из 2–5 человек. Ключевой принцип прост: заменить коммуникацию инструментами, а назойливость — привычками. Разберём по порядку.

От списка задач к канбан-доске

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

Для маленькой команды колонок должно быть мало. Оптимальный набор, который я опробовал:

Бэклог (пул идей, не нужно детального разбиения)
На этой неделе (задачи, которые войдут в разработку)
В работе (кто-то активно делает)
На проверке (нужно тестирование или ревью другим человеком)
Готово (завершено на этой неделе)

Каждый понедельник мы тянем 5–7 задач из бэклога в «На этой неделе», обсуждаем их вместе, и после этого замораживаем набор — новые задачи не добавляются, пока кто-то не закончит свою раньше и не освободится ёмкость. Это называется «заморозка батча» и помогает бороться с расползанием требований.

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

Ежедневный стендап: 5 минут, три вопроса

Стендапы легко превращаются в отчёты. Чтобы этого избежать, я ограничиваю структуру тремя пунктами на человека (1–2 минуты максимум):

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

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

Стендап нужен для выявления проблем, а не для их решения. Если есть серьёзный вопрос, мы задерживаемся на 2–3 минуты после стендапа.

Двухнедельные итерации со светофором

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

Для каждой задачи используем простой статус-светофор:

🟢 Зелёный: по плану, серьёзных задержек нет.
🟡 Жёлтый: есть риски, нужно вмешательство.
🔴 Красный: точно не успеем к дедлайну, нужно пересмотреть объём.

У каждой задачи есть ответственный, который сам назначает цвет. Если кто-то ставит красный, он должен предложить новую оценку или отказаться от части функционала. Я никогда не наказываю за красный; вместо этого спрашиваю: «Как мы могли бы заметить это раньше?» Так команда учится чувствовать время, а не бояться его.

Автоматизация вместо надоеданий

Ничто не убивает моральный дух команды быстрее, чем человек-контролёр. Моё решение: пусть машины напоминают.

Мы используем GitHub Projects как канбан-доску и написали простой GitHub Action, который запускается каждый вечер в 20:00 по пекинскому времени. Он проверяет карточки в колонке «В работе»; если карточка висит там больше 3 дней, отправляет уведомление в командный чат.

name: Check stalled cards
on:
  schedule:
    - cron: '0 12 * * *'  # UTC 12:00 = Пекин 20:00
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v6
        with:
          script: |
            const { data: cards } = await github.rest.projects.listCards({
              column_id: YOUR_IN_PROGRESS_COLUMN_ID
            });
            const now = new Date();
            cards.forEach(card => {
              const createdAt = new Date(card.created_at);
              const days = (now - createdAt) / (1000*60*60*24);
              if (days > 3) {
                console.log(`Карточка ${card.note} в работе ${days.toFixed(1)} дней`);
                // здесь можно добавить отправку вебхука
              }
            });

Это всего лишь пример — нужно будет настроить ID колонки и вебхук. Но такое безличное напоминание работает гораздо лучше, чем мои упоминания каждого в чате, и не портит отношения.

Чек-лист: понедельничная 15-минутная синхронизация

Вот чек-лист, который мы проходим каждый понедельник утром (ведущий меняется по очереди):

Все ли задачи в колонке «На этой неделе» назначены конкретным людям?
Есть ли задачи в «В работе» больше 3 дней? Если да, нужно ли их разбить или разблокировать?
Есть ли карточки в «На проверке», которые висят более 2 дней? Очистить как можно скорее.
Отмечено ли в календаре неотменяемое время каждого (встречи, отпуск)?
Каковы риски для следующего релиза? Нужна ли какая-то подготовка?

Весь чек-лист занимает меньше 5 минут. Если всё зелёное, оставшееся время уходит на неформальное общение; если есть красные флаги — быстро обсуждаем.

Границы: когда стоит отказаться от процесса

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

Команда из одного человека: никаких процессов, достаточно простого файла TODO или стикера.
Этап исследования (например, создание первого MVP в неизведанной области): сократить стендапы до одного раза в неделю; ежедневные отчёты бессмысленны, когда всё неопределённо.
Члены команды прямо говорят, что стендапы отвлекают их, и исторические данные показывают, что они сдают задачи вовремя и без них: отменить стендапы, заменить еженедельной синхронизацией.

Однажды я работал над AI-музыкальным продуктом, где мы понятия не имели, что сработает. Мы втроём меняли направление почти ежедневно. Я сказал: «Забудьте про стендапы — просто напишите мне в пятницу, что вы попробовали и что обнаружили». На следующей неделе кто-то сделал полный демо-прототип, и направление стало очевидным.

Главное преимущество маленькой команды — гибкость. Не дайте процессу её убить.

Итоги

Если вы руководите командой из 5 или менее человек, попробуйте следующие базовые принципы:

Используйте канбан с ≤5 колонками для визуализации прогресса.
Ограничьте стендапы по времени, три вопроса, никакого решения проблем на месте.
Двухнедельные проверки со светофором; отделите предупреждение от обвинения.
Автоматизируйте напоминания вместо надоеданий.
Знайте, когда не нужно управлять — не перегружайте процессами.

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

PaxLee