Как я принимаю решения о приоритетах, когда сталкиваются два…

Как я принимаю решения о приоритетах, когда сталкиваются два проекта

Некоторое время назад я одновременно поддерживал приложение для изучения языков и инструмент для AI-писательства. Оба продукта росли, но команда состояла только из меня и одного разработчика-совместителя. Каждую среду утром мы сталкивались с одной и той же проблемой: обе стороны имели срочные запросы. Что делать в первую очередь?

Я перепробовал различные инструменты управления проектами — канбан-доски, диаграммы Ганта, временные блоки. Но инструменты могут только записывать, они не могут решать за вас. Суть конфликтов планирования — не в нехватке времени, а в неясности того, чему сказать «нет».

Настоящая причина конфликтов ресурсов

Для маленьких команд конфликты между проектами редко возникают из-за превышения загрузки над мощностью. Они проистекают из трёх скрытых проблем:

Зависимости между проектами явно не отображены. Например, инструменту для AI-писательства нужен новый API, а изменение этого API повлияет на модуль грамматического разбора приложения для языков.
«Срочность» оценивается субъективно разными людьми. Клиент говорит, что срочно, партнёр говорит срочно, и вы сами чувствуете срочность — но никто не ставит их на одну шкалу.
Мы не различаем «должно быть сделано сейчас» и «лучше сделать сейчас». Многие срочные запросы на самом деле «лучше сделать сейчас» — отсрочка на неделю не убьёт продукт.

Простой фреймворк для приоритизации

В итоге я разработал метод трёхбалльной оценки. Каждый раз при конфликте я оцениваю требования из обоих проектов по трём аспектам:

Влияние на выживаемость (1-5): Если не сделать это требование, столкнётся ли проект с измеримыми рисками в ближайший месяц? Например, отток пользователей, падение дохода, разрыв критической зависимости. Вопрос не в том, «станет ли лучше», а «станет ли хуже».
Чувствительность к окну (1-5): Есть ли у требования чёткое временное окно? Например, изменение правил проверки Apple, которое нужно адаптировать до следующего четверга, или запуск новой функции конкурентом, которую нужно опередить. Если окно упущено, ценность может упасть до нуля.
Эксклюзивность ресурса (1-5): Требует ли это требование полной занятости определённого ресурса? Например, только разработчик-совместитель может написать этот модуль, или мне нужно лично развернуть сервер. Если ресурс заменим, ставьте низкую оценку.

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

Этот фреймворк кажется слишком простым? Да. Но его ценность не в цифрах — он заставляет вас записать, почему одно важнее другого. Каждый раз при оценке вы понимаете, что раньше просто следовали интуиции, говоря «это срочно».

Гипотетический пример неудачи

Предположим, я оценил два проекта по этому фреймворку:

Проект A (изучение языков): Влияние 4 (без новой сезонной активности ежемесячные активные пользователи упадут на 10%), Окно 5 (активность должна быть запущена к понедельнику), Эксклюзивность 2 (фронтенд можно заменить). Итого: 11.
Проект B (AI-писательство): Влияние 2 (просто оптимизация интерфейса, пользователи могут работать и без неё), Окно 1 (нет временной чувствительности), Эксклюзивность 4 (должен делать разработчик-совместитель, который как раз свободен). Итого: 7.

Очевидно, что сначала нужно делать A. Но если бы я смотрел только на доступность ресурсов, я бы мог поручить разработчику B, потому что «он сейчас свободен». Как только B занял его время, A был бы сделан в спешке в последний момент, качество пострадало бы, а окно было бы упущено.

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

Границы и корректировки на практике

Трёхбалльная оценка не решает все проблемы. У неё три явных недостатка:

Оценки субъективны. Разные люди могут ставить разные числа. На начальном этапе пусть один человек (например, вы) ставит все оценки, чтобы уменьшить разброс.
Она предполагает независимость требований, но на практике могут быть зависимости. В таком случае сначала нарисуйте граф зависимостей, объедините зависимые требования в один пакет и оценивайте его.
Она не учитывает долгосрочный стратегический вес. Если проект экспериментальный (например, новое направление), его влияние на выживаемость может быть низким, но стратегическая ценность — высокой. В таких случаях я добавляю «стратегический множитель» до 1.5.

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

Заключение

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

PaxLee