БИЗНЕС И ЦИФРОВИЗАЦИЯ

Команда клонов: почему одинаковое мышление ломает IT-проекты

5,9 тыс. просмотров набрал материал о том, почему командам вредно мыслить одинаково и как выбирать режим обсуждения задач.

✍️ Редакция iTech News | 25.09.2026 | ⏱ 4 мин | Источник: Habr / Карьера
💹

Материал на Habr / Карьера с охватом 5,9 тыс. читателей снова поднял старую, но болезненную тему: команда из людей, которые думают одинаково, может быстро прийти не к решению, а к общей слепой зоне. В центре текста — дивергентное мышление и его пара, конвергентное: первый режим помогает расширять набор вариантов, второй — выбирать и действовать. Для русскоязычных IT-команд это почти прикладная инструкция по тому, почему хорошие аналитики, продакты и тимлиды иногда мешают друг другу именно своими сильными сторонами.

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

Раньше автор объяснял эту разницу через популярную цветовую типологию DISC: «синие» любят факты и точность, «красные» — результат и скорость, «жёлтые» — идеи и общение, «зелёные» — стабильность и отношения. Он честно оговаривается: защищать научность такого подхода не собирается. Зато признаёт, что как бытовая карта поведения она помогает заметить простую вещь: удобный для менеджера сотрудник и полезный для команды сотрудник — не всегда один и тот же человек.

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

Главная ошибка, по версии автора, не в том, что один режим лучше другого. Ошибка в тайминге. Если включить оценку рисков в момент генерации идей, обсуждение быстро сожмётся до первого безопасного варианта. Если продолжать придумывать альтернативы, когда уже пора принимать решение, команда уйдёт со встречи с красивым набором возможностей и без результата. А самый дорогой сценарий для бизнеса — перейти к реализации до того, как поняли проблему. Так рождаются отчёты, дашборды и автоматизации, которые аккуратно решают не ту задачу.

Хороший пример из текста — заказчик просит новый отчёт. Формально можно сразу собрать требования: поля, фильтры, период, формат выгрузки. Но за просьбой может скрываться другая проблема: важные клиентские обращения застревают между подразделениями, а команда узнаёт об этом слишком поздно. В конвергентном режиме все будут уточнять отчёт. В дивергентном сначала спросят: что именно нужно заметить раньше, что изменится после просмотра данных, почему текущий процесс не ловит сбой и какие способы обнаружения вообще возможны. Иногда после такого разговора выясняется, что отчёт не нужен.

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

Практический вывод у текста простой и полезный: перед обсуждением стоит спросить, что должно быть на выходе. Не абстрактная повестка, а конкретный результат разговора: уточнённая формулировка проблемы, пять возможных решений, выбор одного варианта или список действий с владельцами. От ответа зависит, кто сейчас помогает, а кто тормозит. Генератор идей ценен в начале и опасен ближе к финалу. Скептик раздражает на старте, но становится незаменимым, когда пора проверять ограничения.

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

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

Поделиться: Telegram X LinkedIn