В своей книге «Пять пороков команды» Патрик Ленсиони описывает дисфункции, которые разрушают эффективность коллективов. Эти пороки образуют пирамиду:

Отсутствие доверия → Страх конфликтов → Недостаточная вовлеченность → Избегание ответственности → Невнимание к результатам.

Рассмотрим, как описанные ранее проблемы команд в 1С-проектах связаны с моделью Патрика Ленсиони и как их преодолеть, используя его рекомендации.

Но, я считаю, что есть еще два порока:

• Боязнь делегирования (для руководителей).
• Чрезмерная эскалация (для сотрудников).

Первому подвержены практически все молодые руководители. И данный страх кроется в боязни потерять свою экспертность и уникальность. Второй поток – это боязнь сотрудников брать на себя обязательства. Самый простой пример: в переписку с Клиентами (Заказчиками) ставить в копию своего руководителя и руководителя Клиента (Заказчика).

Ну а сейчас рассмотрим пороки из книги Патрика Ленсиони и посмотрим, как они визуализируются в командах на проектах 1С.

1. Недостаточная коммуникация ↔ Отсутствие доверия

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

Например, разработчик в 1С может скрыть неясные требования, опасаясь критики.

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

Пример из практики 1С

Контекст: Команда внедряет модуль расчета зарплаты в конфигурации «1С:Зарплата и управление персоналом». В проекте участвуют:

• Аналитик (собирает требования от HR-отдела заказчика),
• Разработчик (делает разработку по ТЗ от аналитика),
• Тестировщик (проверяет функциональность),
• Менеджер проекта (координирует сроки).

Ситуация:

1. Аналитик не до конца понял специфику расчета премий у заказчика, но не стал уточнять, чтобы не показаться непрофессионалом.
2. Разработчик, получив расплывчатые требования, написал код, но не спросил коллег о возможных «подводных камнях» (например, интеграции с бухгалтерским модулем).
3. Тестировщик обнаружил ошибки в расчетах, но постеснялся сообщить о них, так как ранее его критиковали за «придирки».
4. Менеджер проекта, видя, что сроки горят, скрыл от заказчика реальное состояние дел, чтобы избежать конфликта.

Результат:

На этапе внедрения выяснилось, что:

• Премии рассчитываются некорректно из-за неучтенных KPI сотрудников.
• Данные из модуля зарплаты не синхронизируются с бухгалтерией.
• Заказчик в ярости, проект сорван, команда демотивирована.

Почему это связано с отсутствием доверия?

1. Страх показаться некомпетентным:
   • Аналитик и разработчик не задавали вопросы, чтобы не «подставить» себя.
   • Тестировщик молчал, опасаясь осуждения.
2. Нежелание делиться ошибками:
   • Менеджер скрыл проблемы от клиента, пытаясь сохранить иллюзию контроля.
3. Отсутствие обратной связи:
   • Команда не проводила регулярных обсуждений, где можно было бы открыто говорить о рисках.

Как решить проблему, следуя модели Патрика Ленсиони

Автор подчеркивает: доверие строится на готовности быть уязвимым. Вот как применить его подход в 1С-проекте:

1. Создайте безопасную среду для ошибок:
   • Проводите ретроспективы без обвинений. Пример вопроса: «Что мы можем улучшить в коммуникации?».
   • Внедрите правило: «Нет глупых вопросов». Например, разработчик может сказать: «Я не понял, как работает этот бизнес-процесс. Давайте обсудим».
2. Практикуйте открытость на старте проекта:
   • Проведите воркшоп с упражнением «Личные истории». Пусть каждый участник расскажет:
     • Свой самый провальный проект и что он из него вынес.
     • Что его пугает в текущей задаче.
   • Это снимет барьеры и покажет, что ошибки — часть работы.
3. Визуализируйте прогресс и проблемы:
   • Используйте Kanban-доску (Trello, Jira), где все видят статус задач, риски и «блокеры».
   • Пример для 1С: карточка «Интеграция с бухгалтерией» помечается красным, если есть нерешенные вопросы.
4. Вовлекайте заказчика в коммуникацию:
   • Организуйте еженедельные демо-сессии, где команда показывает промежуточные результаты.
   • Если заказчик замечает ошибку, поблагодарите его: «Спасибо, что заметили это сейчас, а не на этапе внедрения».
5. Поощряйте прямые диалоги:
   • Разработчик и аналитик должны общаться напрямую, без посредников.
   • Пример: если в модуле «Отчеты по расчету заработной платы» есть противоречивые требования, пусть разработчик сам спросит у заказчика: «Почему этот отчет важен? Как вы его используете?».

Итог

В 1С-проектах недостаток коммуникации — это не просто «недоговорили». Это симптом глубокой проблемы — страха быть уязвимым.

Что внедрить завтра же:

• Начните митинг с вопроса: «Какие риски мы пока не обсуждали?».
• Добавьте в чат команды канал «Сомнения и идеи», где можно анонимно задавать вопросы.
• Разрешите разработчикам говорить: «Я ошибся, давайте это исправим» — без последствий для репутации.

Когда команда перестанет бояться быть «неидеальной», коммуникация станет инструментом, а не проблемой.

2. Хаотичное планирование ↔ Страх конфликтов

Порок «хаотичного планирования» в проектах 1С часто коренится в страхе конфликтов. По мнению Патрика Ленсиони, если команда избегает здоровых споров о приоритетах, сроках и рисках, это приводит к нерешительности, дублированию задач и срыву сроков. Вместо того чтобы находить оптимальные решения, участники предпочитают «плыть по течению», что оборачивается хаосом.

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

Пример из практики 1С

Контекст: Команда внедряет модуль управления цепочками поставок в «1С:ERP» для логистической компании. Участники:

• Менеджер проекта — избегает конфронтации, соглашается со всеми;
• Аналитик — боится оспаривать требования заказчика;
• Разработчик А — доминирует в обсуждениях, подавляя идеи коллег;
• Разработчик Б — молчит, даже если видит ошибки в плане;
• Тестировщик — не решается сказать, что сроки нереальны.

Ситуация:

1. На старте проекта заказчик потребовал реализовать 3 ключевые функции:
   • Интеграцию с TMS (Transportation Management System).
   • Автоматический расчет оптимальных маршрутов.
   • Дашборд аналитики в реальном времени.
2. Менеджер проекта, опасаясь конфликта с клиентом, согласился на все требования без оценки рисков.
3. Разработчик А настаивал: «Сначала сделаем интеграцию с TMS, это основа».
4. Разработчик Б хотел начать с дашборда, но промолчал, чтобы не спорить.
5. Тестировщик не стал напоминать, что на нагрузочное тестирование нужно +2 недели.
6. В итоге:
   • Оба разработчика начали работать параллельно над разными модулями.
   • Интеграция с TMS застряла из-за неучтенных API-ограничений.
   • Дашборд оказался бесполезен без данных из TMS.
   • Заказчик отказался принимать «сырой» продукт.

Результат:

• Проект превысил бюджет на 40%, сроки сорваны.
• Команда в упадке: Разработчик Б уволился, клиент требует компенсацию.
• Менеджер обвиняет команду в «непрофессионализме», разработчик А — менеджера в слабохарактерности.

Почему это связано со страхом конфликтов?

1. Избегание сложных тем:
   • Никто не решился сказать клиенту: «Три функции за месяц — нереально».
2. Подавление мнений:
   • Разработчик Б промолчал, хотя понимал, что дашборд без интеграции бессмысленен.
3. Иллюзия согласия:
   • На планерках все кивали, но после встречи обсуждали «невозможность плана» в кулуарах.

Как решить проблему, следуя модели Патрика Ленсиони

Автор считает: конструктивные конфликты — это инструмент поиска лучших решений. Вот как применить его подход к планированию в 1С:

1. Создайте правила для «здоровых конфликтов»:
   • Внедрите «красные карточки» на митингах. Пример:
     • Если разработчик Б видит риск, он поднимает карточку и говорит: «Дашборд без данных TMS — это пустая трата времени. Давайте обсудим приоритеты».
   • Запретите фразы вроде «Как скажете» или «Мне всё равно». Вместо этого: «Я не согласен, потому что...».
2. Проведите сессию «Самый страшный риск»:
   • Попросите команду анонимно написать на стикерах главные страхи по проекту. Примеры:
     • «Интеграция с TMS не будет работать с большим объемом данных».
     • «Заказчик не предоставит тестовый доступ к API вовремя».
   • Обсудите каждый риск открыто и пересмотрите план, учитывая их.
3. Используйте метод «Приоритетная матрица»:
   • Нарисуйте матрицу с осями «Срочность» и «Важность». Вместе с командой распределите задачи:
     • Высокая важность/срочность: Интеграция с TMS.
     • Высокая важность/несрочно: Нагрузочное тестирование.
     • Низкая важность: Кастомизация интерфейса дашборда.
   • Если возникают споры, голосуйте. Пример: «5 голосов за TMS, 2 — за дашборд. Начинаем с интеграции».
4. Внедрите Agile-инструменты:
   • Разбейте проект на спринты по 2 недели. На каждый спринт:
     • Проводите планирование с обсуждением задач.
     • Ежедневно обновляйте доску прогресса (Trello, Jira).
     • В конце спринта — ретроспектива: «Что прошло хорошо? Что нужно улучшить?».
5. Назначьте «адвоката дьявола»:
   • Каждую неделю один из участников команды играет роль критика. Его задача — задавать неудобные вопросы:
     • «Почему мы до сих пор не согласовали API с заказчиком?».
     • «Что будет, если TMS выдаст ошибку при 1000+ накладных?».
   • Это легализует конфликты и заставит команду думать наперед.

Итог

Хаотичное планирование в 1С-проектах — это не просто «плохой менеджмент». Это следствие страха услышать друг друга и пойти на конфликт ради общего успеха.

Что внедрить завтра же:

• Начните митинг с вопроса: «Какие риски мы замалчиваем?».
• Используйте доску с задачами, где каждый может оставить комментарий-возражение.
• Введите правило: «Если ты не споришь — ты не участвуешь».

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

3. Слабая документация