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

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

Рассмотрим, как описанные ранее проблемы команд в 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. Слабая документация ↔ Недостаточная вовлеченность

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

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

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

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

• Аналитик — фиксирует требования устаревшими методами (например, в блокноте);
• Разработчик — пишет код без комментариев, считая: «И так всё понятно»;
• Тестировщик — не обновляет чек-листы, полагаясь на память;
• Менеджер — не выделяет время на документирование, фокусируясь только на сроках.

Ситуация:

1. Клиент попросил добавить согласование договоров через электронную подпись. Аналитик устно обсудил задачу с разработчиком, но не занес требования в ТЗ.
2. Разработчик реализовал функционал, но не описал логику в коде («Это займет лишний час»).
3. Через месяц тестировщик уволился, а новый сотрудник не смог разобраться в модуле из-за отсутствия чек-листов.
4. При обновлении конфигурации возник конфликт версий: недокументированный алгоритм проверки подписей сломался, и договоры перестали согласовываться.

Результат:

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

Почему это связано с недостаточной вовлеченностью?

1. Документация — не «моя» задача:
   • Команда считает, что «документировать должен кто-то другой» (аналитик, техписатель, менеджер).
2. Отсутствие видения ценности:
   • Разработчик не понимает, как комментарии в коде помогут лично ему в будущем.
3. Пассивное согласие:
   • Все знают, что документация нужна, но молчат, чтобы не брать на себя лишние обязательства.

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

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

1. Проведите воркшоп «Зачем нам документация?»:
   • Соберите команду и задайте вопросы:
     • «Что произойдет, если завтра я заболею? Смогут ли коллеги продолжить мою работу?»
     • «Как документация защитит нас от претензий клиента?»
   • Зафиксируйте ответы в формате: «Если мы не будем документировать, то...» (например, «...потеряем неделю на разбор чужого кода»).
2. Создайте шаблоны документации вместе с командой:
   • Разработайте стандарты, которые упростят процесс:
     • Для разработчиков: комментарии к сложным алгоритмам в коде (пример):
     • Для аналитиков: шаблон ТЗ с обязательными разделами (цель, сценарии использования, ограничения).
     • Для тестировщиков: чек-листы в формате «Шаги → Ожидаемый результат → Фактический результат».
3. Внедрите «дни документации» в рабочий график:
   • Выделите 2 часа в неделю, когда вся команда:
     • Обновляет комментарии в коде.
     • Пополняет базу знаний (например, в Confluence).
     • Проводит взаимное ревью документов.
   • Пример: разработчик проверяет тест-кейсы тестировщика, а аналитик ревьюит ТЗ.
4. Свяжите документацию с KPI:
   • Введите метрики:
     • % задач с обновленной документацией.
     • Время, сэкономленное благодаря комментариям/инструкциям.
   • Публикуйте еженедельные отчеты:
     • «Благодаря детальному ТЗ Марии, разработка модуля заняла на 20% меньше времени».
5. Используйте инструменты, которые делают документирование легким.

Итог

Слабая документация в 1С-проектах — это не лень, а следствие того, что команда не чувствует своей роли в общем успехе.

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

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

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

4. Отсутствие стандартов кодирования ↔ Избегание ответственности

Порок «отсутствия стандартов кодирования» в проектах 1С часто маскирует более глубокую проблему — избегание ответственности.

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

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

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

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

• Алексей — опытный, но пишет код «как придется», без комментариев;
• Мария — следует своим правилам (например, именует переменные с префиксом «м_»);
• Иван — новичок, копирует стиль того, чей код попался под руку.

Ситуация:

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

Результат:

• Клиент получил нестабильную систему, где часть функционала работает только при определенных условиях.
• Команда тратит 70% времени на поиск и исправление чужих ошибок.
• Алексей обвиняет Марию в «недальновидности», Мария — Ивана в «непрофессионализме». Ответственность перекладывается по кругу.

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

1. Нет критериев для оценки качества:
   • Если нет стандартов, нельзя сказать, что код «плохой» или «хороший». Разработчики оправдываются: «Я же не знал, как надо».
2. Страх осуждения:
   • Мария не указала Алексею на ошибку, чтобы не прослыть «занудой».
3. Коллективная безответственность:
   • Все понимают, что код — мешанина, но считают, что «это не моя проблема».

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

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

1. Создайте стандарты вместе с командой:
   • Проведите воркшоп, где разработчики самостоятельно выработают правила:
     • Именование переменных.
     • Структура модулей (разделение на регистры, обработчики событий, общие модули).
     • Обязательные комментарии для сложной логики.
   • Зафиксируйте правила в документе (например, в Confluence) и подпишитесь под ним. Это превратит стандарты в публичное обязательство, а не «спущенное сверху».
2. Внедрите код-ревью на основе стандартов:
   • Назначьте «дежурного по качеству» на каждую итерацию. Его задача — проверять код на соответствие правилам.
   • Используйте встроенные инструменты 1С (например, «Сравнение и объединение конфигураций») для наглядности изменений.
3. Легализуйте «неудобные» разговоры:
   • Если Мария видит, что Алексей нарушил стандарты, она должна сказать: «Давай обсудим твой код. Здесь глобальные переменные могут вызвать проблемы в будущем».
   • Автор книги рекомендует не персонализировать критику. Фокус — на правилах, а не на личности:
     • Как нежелательно давать обратную связь: «Ты опять написал ерунду».
     • Как лучше давать обратную связь: «Этот блок не соответствует нашему стандарту пункт 3.1. Давай перепишем его вместе».
4. Автоматизируйте контроль:
   • Внедрите статические анализаторы кода для 1С.
   • Публикуйте отчеты анализатора в общем чате. Это создаст «здоровое давление» — никто не захочет быть в топе антирейтинга.
5. Вознаграждайте ответственность:
   • Введите ежемесячную номинацию «Чистый код» с символическими призами (например, выбор места для следующей неформальной встречи коллегами).
   • Показывайте примеры, где соблюдение стандартов сэкономило время команды:
     • «Из-за комментариев Марии Иван исправил баг за 1 час вместо 3 дней».

Итог

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

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

• Создайте черновик стандартов и обсудите его на ближайшем митинге.
• Начните практику 15-минутных ежедневных код-ревью (разбирайте по 1-2 модуля).
• Добавьте в описание задач в Jira пункт «Соответствие стандартам».

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

5. Пренебрежение тестированием ↔ Невнимание к результатам

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

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

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

Контекст: Команда разрабатывает модуль интеграции «1С:Управление торговлей» с маркетплейсом Wildberries. Проект сжат по срокам, клиент требует запустить систему к началу сезона распродаж. В команде:

• Разработчик — оптимизирует код для скорости, пропуская проверки;
• Тестировщик — проверяет только «основные сценарии» из-за нехватки времени;
• Менеджер — давит на команду: «Главное — успеть, остальное починим позже».

Ситуация:

1. Разработчик не стал писать тесты для обработки выгрузки остатков, посчитав это «лишней работой».
2. Тестировщик проверил только успешные кейсы (например, выгрузка 100 товаров), но не учел пограничные случаи (5000 товаров, некорректные артикулы).
3. Менеджер проигнорировал риск, заявив: «Клиент не заметит, если что-то сломается».
4. После запуска система работала 2 дня, затем:
   • При выгрузке большого объема данных возникали ошибки памяти.
   • Некорректные артикулы блокировали весь процесс синхронизации.
   • Клиент потерял 3 дня продаж во время пикового сезона.

Результат:

• Команда перешла в режим «аврала», тратя 90% времени на «латание дыр» вместо развития проекта.
• Репутация компании пострадала: клиент отказался от дальнейшего сотрудничества.
• Разработчик уволился из-за выгорания, менеджер обвинил тестировщика в «халатности».

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

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

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

Автор подчеркивает: здоровая команда ставит общий результат выше личных амбиций. Вот как это применить к тестированию в 1С:

1. Переопределите «результат» вместе с командой:
   • Проведите сессию, где сформулируете:
     • Что для клиента успех? «Стабильная синхронизация, даже при нагрузке 5000 товаров».
     • Что для команды успех? «Ночные авралы и паника — это провал».
   • Зафиксируйте это в виде «декларации качества» и разместите в своей базе знаний (например, в Confluence).
2. Внедрите тестирование как часть Definition of Done:
   • Задача не считается выполненной, пока:
     • Написаны автоматические тесты для ключевых сценариев.
     • Проведено нагрузочное тестирование (для модулей интеграции).
     • Тестировщик подтвердил, что покрыты пограничные случаи.
3. Визуализируйте качество как KPI:
   • Создайте дашборд с метриками:
     • % покрытия кода тестами.
     • Количество ошибок в продовой среде.
     • Время, потраченное на исправление багов после релиза.
   • Пример: если в прошлом проекте 40% времени ушло на «латание дыр», покажите это команде: «Каждый день без тестов = два дня исправлений».
4. Проводите «демо-дни» для клиента:
   • Раз в две недели показывайте рабочую версию модуля, включая тестовые сценарии.
   • Если клиент просит ускориться, приведите данные: «Сокращение тестирования на 20% увеличит риск сбоев на 65%».
5. Поощряйте командную ответственность:
   • Введите правило: «Баги в продовой среде — проблема всей команды, а не одного человека».
   • Если тестировщик пропустил ошибку, спросите: «Как мы можем улучшить процесс, чтобы это не повторилось?» вместо поиска виноватого.

Итог

Пренебрежение тестированием в 1С — это не просто «лень писать тесты». Это симптом того, что команда не считает качество продукта своим главным результатом.

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

• Добавьте в график еженедельный «Тест-день», где вся команда участвует в проверке критических сценариев.
• Используйте специальные инструменты для создания регрессионных тестов.
• Начните митинг с вопроса: «Что мы сделали на этой неделе, чтобы снизить риски для клиента?».

Когда качество станет общей ценностью, а не «проблемой тестировщика», пренебрежение тестированием исчезнет само собой.

Заключение

Проблемы в 1С-проектах часто коренятся не в технологиях, а в «человеческих» дисфункциях. Книга «5 пороков команды» Патрика Ленсиони дает инструменты, чтобы их устранить:

• Постройте доверие через открытость.
• Превратите конфликты в источник решений.
• Напоминайте о целях и вовлекайте команду в их достижение.

Примените эту философию к вашим 1С-проектам, и вы увидите, как растут качество и скорость разработки.