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

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

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

1. Фокусируйтесь на главном

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

Если важным кажется всё, сделайте паузу и задайте себе вопросы:

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

• «Связано ли это решение со скоростью, масштабом или обучением?» — каждый из этих аспектов требует разного подхода. Если речь о скорости, выбирайте проверенные инструменты и более простую архитектуру, которые позволят быстро выпустить продукт. Если же важен масштаб, вовлекайте команды заранее, чтобы с самого начала планировать рост и надёжность. Выбирайте пилотные проекты с низким риском, отслеживайте результаты и оставляйте возможность для корректировок.

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

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

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

• Что гибко: области, где можно адаптироваться. Например, внутренний запуск мог немного сдвинуться, если это минимально влияло на пользователей.

• Какие компромиссы допустимы? Мы сознательно сузили область задач — отложили аналитические отчёты на несколько недель, чтобы сохранить качество основного опыта.

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

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

2. Примите неопределённость — и действуйте, несмотря ни на что

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

Как-то раз мы выбирали новую фичу облачной платформы, и у нас не было достаточно данных, чтобы быть на 100% уверенными в принятии решения. Ожидание означало бы срыв сроков поставки. Поэтому мы запустили пилот с одним сервисом, разработали план Б и выпустили продукт. Так мы смогли изучить фичу и двигаться дальше, не рискуя всей системой.

Если вы окажетесь в похожей ситуации, вот несколько шагов, которые можно предпринять:

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

• Фиксируйте сделанные предположения в документах. Например: «Мы предполагаем X; пересмотреть после запуска».

• Если вы проводите эксперимент, установите контрольные точки: «Оценим результаты через два спринта».

Это помогает поддерживать темп без излишнего риска.

3. Вовлекайте людей на ранних этапах

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

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

Учитывая свой опыт, я теперь провожу короткие сессии предварительного согласования — 20-минутные синки с командами продукта, инфраструктуры и безопасности, чтобы обсудить наработки. Без презентаций и документации — просто место для выявления проблем на раннем этапе.

Если не знаете, с чего начать, вот что стоит сделать:

• Делитесь первыми идеями и прототипами на встречах с другими командами. Это помогает выявить неизвестные моменты до того, как идеи станут окончательными.

• Спрашивайте кросс-функциональных партнёров — продукт, инфраструктуру, безопасность: «Чего здесь не хватает?»

• Записывайте и учитывайте обратную связь до начала основной разработки.

Это экономит время в будущем и укрепляет доверие между командами.

4. Не усложняйте (особенно на ранних этапах)

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

Чтобы не попасть в ту же ловушку, всегда выбирайте самый простой путь к полезному результату.

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

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

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

5. Делайте решения видимыми

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

Другие полезные методы:

• Проводить 15-минутные «ретроспективы решений» после крупных технических встреч или когда команда идёт на риск. Обычно я приглашаю основную команду и всех, кто участвовал в принятии решения. Обсуждаем, что сработало, что осталось неясным и повторили бы мы этот выбор снова.

• Привести изменения в план в норму. Я говорю команде: «Это наша лучшая гипотеза на данный момент, и мы будем её корректировать по мере получения нового опыта».

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

Иногда помогает визуализировать следующий шаг. Вот простое дерево решений, которое я использую, когда ситуация кажется запутанной:

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

Вы можете адаптировать его, добавив такие уровни:

• Известные и неизвестные технологии: использует ли команда знакомые инструменты или пробует что-то новое с повышенным риском?

• Только для внутреннего использования или видимое пользователям: влияет ли это только на внутренние системы или будет сразу заметно клиентам?

• Краткосрочное или структурное влияние: является ли решение быстрым или оно влияет на архитектуру в долгосрочной перспективе?

6. Формируйте привычки, а не разовые успехи

Принятие правильных решений — это навык, который требует постоянной практики. Я концентрируюсь на формировании привычек, которые снижают трения:

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

• Использовать асинхронные инструменты (например, Loom или Miro) для обмена первыми идеями.

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

Заключительные мысли

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

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

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

Если вам знакомо чувство неопределенности в таких вопросах, возможно, вам стоит узнать больше на следующих уроках:

• 9 июня, 20:00
  Как системному аналитику не допустить Spaghetti Code и других проблем в архитектуре

• 17 июня, 20:00
  Монолит или микросервисы? Руководство для архитекторов, которые ценят свои нервы

• 16 июня, 20:00
  Анализ требований и их влияние на архитектуру

Полный список открытых уроков смотрите в календаре мероприятий.