В своей книге «Пять пороков команды» Патрик Ленсиони описывает дисфункции, которые разрушают эффективность коллективов. Эти пороки образуют пирамиду:
Отсутствие доверия → Страх конфликтов → Недостаточная вовлеченность → Избегание ответственности → Невнимание к результатам.
Рассмотрим, как описанные ранее проблемы команд в 1С-проектах связаны с моделью Патрика Ленсиони и как их преодолеть, используя его рекомендации.
Но, я считаю, что есть еще два порока:
- Боязнь делегирования (для руководителей).
- Чрезмерная эскалация (для сотрудников).
Первому подвержены практически все молодые руководители. И данный страх кроется в боязни потерять свою экспертность и уникальность. Второй поток – это боязнь сотрудников брать на себя обязательства. Самый простой пример: в переписку с Клиентами (Заказчиками) ставить в копию своего руководителя и руководителя Клиента (Заказчика).
Ну а сейчас рассмотрим пороки из книги Патрика Ленсиони и посмотрим, как они визуализируются в командах на проектах 1С.
1. Недостаточная коммуникация ↔ Отсутствие доверия
Порок «недостаточной коммуникации» в проектах 1С часто возникает из-за отсутствия доверия между участниками команды. По модели Патрика Ленсиони, это базовая дисфункция, которая провоцирует цепную реакцию: если члены команды не доверяют друг другу, они избегают открытого обсуждения проблем, скрывают ошибки, избегают сложных вопросов и не делятся идеями, что ведет к неэффективности, недопониманию и ошибкам.
Например, разработчик в 1С может скрыть неясные требования, опасаясь критики.
Автор предлагает создавать атмосферу психологической безопасности. Проводите ретроспективы, где каждый может высказаться без страха, и практикуйте личные истории (упражнения на раскрытие слабостей). Это укрепит доверие и улучшит коммуникацию.
Пример из практики 1С
Контекст: Команда внедряет модуль расчета зарплаты в конфигурации «1С:Зарплата и управление персоналом». В проекте участвуют:
- Аналитик (собирает требования от HR-отдела заказчика),
- Разработчик (делает разработку по ТЗ от аналитика),
- Тестировщик (проверяет функциональность),
- Менеджер проекта (координирует сроки).
Ситуация:
- Аналитик не до конца понял специфику расчета премий у заказчика, но не стал уточнять, чтобы не показаться непрофессионалом.
- Разработчик, получив расплывчатые требования, написал код, но не спросил коллег о возможных «подводных камнях» (например, интеграции с бухгалтерским модулем).
- Тестировщик обнаружил ошибки в расчетах, но постеснялся сообщить о них, так как ранее его критиковали за «придирки».
- Менеджер проекта, видя, что сроки горят, скрыл от заказчика реальное состояние дел, чтобы избежать конфликта.
Результат:
На этапе внедрения выяснилось, что:
- Премии рассчитываются некорректно из-за неучтенных KPI сотрудников.
- Данные из модуля зарплаты не синхронизируются с бухгалтерией.
- Заказчик в ярости, проект сорван, команда демотивирована.
Почему это связано с отсутствием доверия?
- Страх показаться некомпетентным:
- Аналитик и разработчик не задавали вопросы, чтобы не «подставить» себя.
- Тестировщик молчал, опасаясь осуждения.
- Нежелание делиться ошибками:
- Менеджер скрыл проблемы от клиента, пытаясь сохранить иллюзию контроля.
- Отсутствие обратной связи:
- Команда не проводила регулярных обсуждений, где можно было бы открыто говорить о рисках.
Как решить проблему, следуя модели Патрика Ленсиони
Автор подчеркивает: доверие строится на готовности быть уязвимым. Вот как применить его подход в 1С-проекте:
- Создайте безопасную среду для ошибок:
- Проводите ретроспективы без обвинений. Пример вопроса: «Что мы можем улучшить в коммуникации?».
- Внедрите правило: «Нет глупых вопросов». Например, разработчик может сказать: «Я не понял, как работает этот бизнес-процесс. Давайте обсудим».
- Практикуйте открытость на старте проекта:
- Проведите воркшоп с упражнением «Личные истории». Пусть каждый участник расскажет:
- Свой самый провальный проект и что он из него вынес.
- Что его пугает в текущей задаче.
- Это снимет барьеры и покажет, что ошибки — часть работы.
- Проведите воркшоп с упражнением «Личные истории». Пусть каждый участник расскажет:
- Визуализируйте прогресс и проблемы:
- Используйте Kanban-доску (Trello, Jira), где все видят статус задач, риски и «блокеры».
- Пример для 1С: карточка «Интеграция с бухгалтерией» помечается красным, если есть нерешенные вопросы.
- Вовлекайте заказчика в коммуникацию:
- Организуйте еженедельные демо-сессии, где команда показывает промежуточные результаты.
- Если заказчик замечает ошибку, поблагодарите его: «Спасибо, что заметили это сейчас, а не на этапе внедрения».
- Поощряйте прямые диалоги:
- Разработчик и аналитик должны общаться напрямую, без посредников.
- Пример: если в модуле «Отчеты по расчету заработной платы» есть противоречивые требования, пусть разработчик сам спросит у заказчика: «Почему этот отчет важен? Как вы его используете?».
Итог
В 1С-проектах недостаток коммуникации — это не просто «недоговорили». Это симптом глубокой проблемы — страха быть уязвимым.
Что внедрить завтра же:
- Начните митинг с вопроса: «Какие риски мы пока не обсуждали?».
- Добавьте в чат команды канал «Сомнения и идеи», где можно анонимно задавать вопросы.
- Разрешите разработчикам говорить: «Я ошибся, давайте это исправим» — без последствий для репутации.
Когда команда перестанет бояться быть «неидеальной», коммуникация станет инструментом, а не проблемой.
2. Хаотичное планирование ↔ Страх конфликтов
Порок «хаотичного планирования» в проектах 1С часто коренится в страхе конфликтов. По мнению Патрика Ленсиони, если команда избегает здоровых споров о приоритетах, сроках и рисках, это приводит к нерешительности, дублированию задач и срыву сроков. Вместо того чтобы находить оптимальные решения, участники предпочитают «плыть по течению», что оборачивается хаосом.
Патрик Ленсиони в книге призывает легализовать конструктивные конфликты. Используйте техники мозгового штурма, где поощряются споры о приоритетах задач. Назначьте модератора, который не даст дискуссии перейти в эмоциональную плоскость.
Пример из практики 1С
Контекст: Команда внедряет модуль управления цепочками поставок в «1С:ERP» для логистической компании. Участники:
- Менеджер проекта — избегает конфронтации, соглашается со всеми;
- Аналитик — боится оспаривать требования заказчика;
- Разработчик А — доминирует в обсуждениях, подавляя идеи коллег;
- Разработчик Б — молчит, даже если видит ошибки в плане;
- Тестировщик — не решается сказать, что сроки нереальны.
Ситуация:
- На старте проекта заказчик потребовал реализовать 3 ключевые функции:
- Интеграцию с TMS (Transportation Management System).
- Автоматический расчет оптимальных маршрутов.
- Дашборд аналитики в реальном времени.
- Менеджер проекта, опасаясь конфликта с клиентом, согласился на все требования без оценки рисков.
- Разработчик А настаивал: «Сначала сделаем интеграцию с TMS, это основа».
- Разработчик Б хотел начать с дашборда, но промолчал, чтобы не спорить.
- Тестировщик не стал напоминать, что на нагрузочное тестирование нужно +2 недели.
- В итоге:
- Оба разработчика начали работать параллельно над разными модулями.
- Интеграция с TMS застряла из-за неучтенных API-ограничений.
- Дашборд оказался бесполезен без данных из TMS.
- Заказчик отказался принимать «сырой» продукт.
Результат:
- Проект превысил бюджет на 40%, сроки сорваны.
- Команда в упадке: Разработчик Б уволился, клиент требует компенсацию.
- Менеджер обвиняет команду в «непрофессионализме», разработчик А — менеджера в слабохарактерности.
Почему это связано со страхом конфликтов?
- Избегание сложных тем:
- Никто не решился сказать клиенту: «Три функции за месяц — нереально».
- Подавление мнений:
- Разработчик Б промолчал, хотя понимал, что дашборд без интеграции бессмысленен.
- Иллюзия согласия:
- На планерках все кивали, но после встречи обсуждали «невозможность плана» в кулуарах.
Как решить проблему, следуя модели Патрика Ленсиони
Автор считает: конструктивные конфликты — это инструмент поиска лучших решений. Вот как применить его подход к планированию в 1С:
- Создайте правила для «здоровых конфликтов»:
- Внедрите «красные карточки» на митингах. Пример:
- Если разработчик Б видит риск, он поднимает карточку и говорит: «Дашборд без данных TMS — это пустая трата времени. Давайте обсудим приоритеты».
- Запретите фразы вроде «Как скажете» или «Мне всё равно». Вместо этого: «Я не согласен, потому что...».
- Внедрите «красные карточки» на митингах. Пример:
- Проведите сессию «Самый страшный риск»:
- Попросите команду анонимно написать на стикерах главные страхи по проекту. Примеры:
- «Интеграция с TMS не будет работать с большим объемом данных».
- «Заказчик не предоставит тестовый доступ к API вовремя».
- Обсудите каждый риск открыто и пересмотрите план, учитывая их.
- Попросите команду анонимно написать на стикерах главные страхи по проекту. Примеры:
- Используйте метод «Приоритетная матрица»:
- Нарисуйте матрицу с осями «Срочность» и «Важность». Вместе с командой распределите задачи:
- Высокая важность/срочность: Интеграция с TMS.
- Высокая важность/несрочно: Нагрузочное тестирование.
- Низкая важность: Кастомизация интерфейса дашборда.
- Если возникают споры, голосуйте. Пример: «5 голосов за TMS, 2 — за дашборд. Начинаем с интеграции».
- Нарисуйте матрицу с осями «Срочность» и «Важность». Вместе с командой распределите задачи:
- Внедрите Agile-инструменты:
- Разбейте проект на спринты по 2 недели. На каждый спринт:
- Проводите планирование с обсуждением задач.
- Ежедневно обновляйте доску прогресса (Trello, Jira).
- В конце спринта — ретроспектива: «Что прошло хорошо? Что нужно улучшить?».
- Разбейте проект на спринты по 2 недели. На каждый спринт:
- Назначьте «адвоката дьявола»:
- Каждую неделю один из участников команды играет роль критика. Его задача — задавать неудобные вопросы:
- «Почему мы до сих пор не согласовали API с заказчиком?».
- «Что будет, если TMS выдаст ошибку при 1000+ накладных?».
- Это легализует конфликты и заставит команду думать наперед.
- Каждую неделю один из участников команды играет роль критика. Его задача — задавать неудобные вопросы:
Итог
Хаотичное планирование в 1С-проектах — это не просто «плохой менеджмент». Это следствие страха услышать друг друга и пойти на конфликт ради общего успеха.
Что внедрить завтра же:
- Начните митинг с вопроса: «Какие риски мы замалчиваем?».
- Используйте доску с задачами, где каждый может оставить комментарий-возражение.
- Введите правило: «Если ты не споришь — ты не участвуешь».
Когда команда перестанет бояться конфликтов, хаос в планировании сменится осознанным выбором решений.
3. Слабая документация ↔ Недостаточная вовлеченность
Порок «слабой документации» в проектах 1С часто указывает на более глубокую проблему — недостаточную вовлеченность команды. По Ленсиони, если участники проекта не чувствуют личной ответственности за результат, они воспринимают документирование как формальность, а не как часть своей работы. Это приводит к «тихому саботажу»: код пишется наспех, требования не фиксируются, а знания остаются в головах отдельных людей.
Убедитесь, что все понимают, зачем нужна документация. Вовлеченность рождается, когда команда участвует в принятии решений. Проведите воркшоп, где совместно разработаете шаблоны документов и распределите зоны ответственности.
Пример из практики 1С
Контекст: Команда разрабатывает кастомный модуль для «1С:Документооборот» в крупной компании. В проекте участвуют:
- Аналитик — фиксирует требования устаревшими методами (например, в блокноте);
- Разработчик — пишет код без комментариев, считая: «И так всё понятно»;
- Тестировщик — не обновляет чек-листы, полагаясь на память;
- Менеджер — не выделяет время на документирование, фокусируясь только на сроках.
Ситуация:
- Клиент попросил добавить согласование договоров через электронную подпись. Аналитик устно обсудил задачу с разработчиком, но не занес требования в ТЗ.
- Разработчик реализовал функционал, но не описал логику в коде («Это займет лишний час»).
- Через месяц тестировщик уволился, а новый сотрудник не смог разобраться в модуле из-за отсутствия чек-листов.
- При обновлении конфигурации возник конфликт версий: недокументированный алгоритм проверки подписей сломался, и договоры перестали согласовываться.
Результат:
- Клиент потребовал срочного исправления, но команда потратила 3 дня на реверс-инжиниринг кода.
- Разработчик, который писал модуль, был в отпуске и не мог помочь.
- Проект вышел за бюджет, а доверие клиента было подорвано.
Почему это связано с недостаточной вовлеченностью?
- Документация — не «моя» задача:
- Команда считает, что «документировать должен кто-то другой» (аналитик, техписатель, менеджер).
- Отсутствие видения ценности:
- Разработчик не понимает, как комментарии в коде помогут лично ему в будущем.
- Пассивное согласие:
- Все знают, что документация нужна, но молчат, чтобы не брать на себя лишние обязательства.
Как решить проблему, следуя модели Патрика Ленсиони
Ленсиони утверждает: вовлеченность рождается, когда команда участвует в принятии решений и видит связь своей работы с общим успехом. Вот как это применить к документации в 1С:
- Проведите воркшоп «Зачем нам документация?»:
- Соберите команду и задайте вопросы:
- «Что произойдет, если завтра я заболею? Смогут ли коллеги продолжить мою работу?»
- «Как документация защитит нас от претензий клиента?»
- Зафиксируйте ответы в формате: «Если мы не будем документировать, то...» (например, «...потеряем неделю на разбор чужого кода»).
- Соберите команду и задайте вопросы:
- Создайте шаблоны документации вместе с командой:
- Разработайте стандарты, которые упростят процесс:
- Для разработчиков: комментарии к сложным алгоритмам в коде (пример):
- Для аналитиков: шаблон ТЗ с обязательными разделами (цель, сценарии использования, ограничения).
- Для тестировщиков: чек-листы в формате «Шаги → Ожидаемый результат → Фактический результат».
- Разработайте стандарты, которые упростят процесс:
- Внедрите «дни документации» в рабочий график:
- Выделите 2 часа в неделю, когда вся команда:
- Обновляет комментарии в коде.
- Пополняет базу знаний (например, в Confluence).
- Проводит взаимное ревью документов.
- Пример: разработчик проверяет тест-кейсы тестировщика, а аналитик ревьюит ТЗ.
- Выделите 2 часа в неделю, когда вся команда:
- Свяжите документацию с KPI:
- Введите метрики:
- % задач с обновленной документацией.
- Время, сэкономленное благодаря комментариям/инструкциям.
- Публикуйте еженедельные отчеты:
- «Благодаря детальному ТЗ Марии, разработка модуля заняла на 20% меньше времени».
- Введите метрики:
- Используйте инструменты, которые делают документирование легким.
Итог
Слабая документация в 1С-проектах — это не лень, а следствие того, что команда не чувствует своей роли в общем успехе.
Что внедрить завтра же:
- Начните с малого: добавьте комментарий к одному модулю и покажите команде, как это упростило жизнь коллегам.
- Создайте в общем чате канал «Документация», где можно задавать вопросы и делиться шаблонами.
- Внедрите правило: «Перед закрытием задачи проверь, всё ли задокументировано».
Когда команда увидит, что документация экономит их же время и нервы, она станет частью рабочего потока, а не обузой.
4. Отсутствие стандартов кодирования ↔ Избегание ответственности
Порок «отсутствия стандартов кодирования» в проектах 1С часто маскирует более глубокую проблему — избегание ответственности.
Если команда не придерживается четких правил, участники перестают чувствовать ответственность за общий результат, перекладывая вину за ошибки на других или внешние обстоятельства. Например, один разработчик нарушает структуру, а другие закрывают глаза, чтобы избежать конфликта.
Внедрите публичные обязательства. На этапе согласования стандартов кодирования проведите совещание, где каждый явно подтвердит их соблюдение.
Пример из практики 1С
Контекст: Команда дорабатывает конфигурацию «1С:Управление торговлей» для сети магазинов. В проекте участвуют три разработчика:
- Алексей — опытный, но пишет код «как придется», без комментариев;
- Мария — следует своим правилам (например, именует переменные с префиксом «м_»);
- Иван — новичок, копирует стиль того, чей код попался под руку.
Ситуация:
- Менеджер проекта не внедрил корпоративные стандарты кодирования, решив: «Пусть пишут как хотят, лишь бы работало».
- Алексей написал обработку заказов с использованием глобальных переменных, что нарушило модульность кода.
- Мария, обнаружив это, промолчала, чтобы не вступать в конфликт.
- Иван, пытаясь исправить баг в обработке, добавил дублирующий код, так как не понял логику Алексея.
- При попытке обновить конфигурацию возникли ошибки из-за конфликта версий и «хаотичных» зависимостей.
Результат:
- Клиент получил нестабильную систему, где часть функционала работает только при определенных условиях.
- Команда тратит 70% времени на поиск и исправление чужих ошибок.
- Алексей обвиняет Марию в «недальновидности», Мария — Ивана в «непрофессионализме». Ответственность перекладывается по кругу.
Почему это связано с избеганием ответственности?
- Нет критериев для оценки качества:
- Если нет стандартов, нельзя сказать, что код «плохой» или «хороший». Разработчики оправдываются: «Я же не знал, как надо».
- Страх осуждения:
- Мария не указала Алексею на ошибку, чтобы не прослыть «занудой».
- Коллективная безответственность:
- Все понимают, что код — мешанина, но считают, что «это не моя проблема».
Как решить проблему, следуя модели Патрика Ленсиони
Автор подчеркивает: ответственность возникает, когда команда сама устанавливает правила и следит за их выполнением. Вот как это применить в 1С:
- Создайте стандарты вместе с командой:
- Проведите воркшоп, где разработчики самостоятельно выработают правила:
- Именование переменных.
- Структура модулей (разделение на регистры, обработчики событий, общие модули).
- Обязательные комментарии для сложной логики.
- Зафиксируйте правила в документе (например, в Confluence) и подпишитесь под ним. Это превратит стандарты в публичное обязательство, а не «спущенное сверху».
- Проведите воркшоп, где разработчики самостоятельно выработают правила:
- Внедрите код-ревью на основе стандартов:
- Назначьте «дежурного по качеству» на каждую итерацию. Его задача — проверять код на соответствие правилам.
- Используйте встроенные инструменты 1С (например, «Сравнение и объединение конфигураций») для наглядности изменений.
- Легализуйте «неудобные» разговоры:
- Если Мария видит, что Алексей нарушил стандарты, она должна сказать: «Давай обсудим твой код. Здесь глобальные переменные могут вызвать проблемы в будущем».
- Автор книги рекомендует не персонализировать критику. Фокус — на правилах, а не на личности:
- Как нежелательно давать обратную связь: «Ты опять написал ерунду».
- Как лучше давать обратную связь: «Этот блок не соответствует нашему стандарту пункт 3.1. Давай перепишем его вместе».
- Автоматизируйте контроль:
- Внедрите статические анализаторы кода для 1С.
- Публикуйте отчеты анализатора в общем чате. Это создаст «здоровое давление» — никто не захочет быть в топе антирейтинга.
- Вознаграждайте ответственность:
- Введите ежемесячную номинацию «Чистый код» с символическими призами (например, выбор места для следующей неформальной встречи коллегами).
- Показывайте примеры, где соблюдение стандартов сэкономило время команды:
- «Из-за комментариев Марии Иван исправил баг за 1 час вместо 3 дней».
Итог
Отсутствие стандартов кодирования в 1С — не просто «техническая» проблема. Это признак того, что команда не готова нести ответственность за коллективный результат.
Что внедрить завтра же:
- Создайте черновик стандартов и обсудите его на ближайшем митинге.
- Начните практику 15-минутных ежедневных код-ревью (разбирайте по 1-2 модуля).
- Добавьте в описание задач в Jira пункт «Соответствие стандартам».
Когда стандарты станут частью культуры, разработчики начнут спрашивать друг друга: «А как лучше сделать?», вместо того чтобы прятаться за фразой «Это не моя проблема».
5. Пренебрежение тестированием ↔ Невнимание к результатам
Порок «пренебрежение тестированием» в проектах 1С часто сигнализирует о том, что команда фокусируется на выполнении задач, а не на достижении общего результата. По Ленсиони, это высшая дисфункция пирамиды — невнимание к результатам, когда индивидуальные цели (закрыть тикет, уложиться в срок) ставятся выше качества продукта и удовлетворенности клиента.
Напомните команде о главной цели — успешном запуске проекта. Визуализируйте результаты (например, графики покрытия тестами) и поощряйте коллективные достижения, а не личные победы.
Пример из практики 1С
Контекст: Команда разрабатывает модуль интеграции «1С:Управление торговлей» с маркетплейсом Wildberries. Проект сжат по срокам, клиент требует запустить систему к началу сезона распродаж. В команде:
- Разработчик — оптимизирует код для скорости, пропуская проверки;
- Тестировщик — проверяет только «основные сценарии» из-за нехватки времени;
- Менеджер — давит на команду: «Главное — успеть, остальное починим позже».
Ситуация:
- Разработчик не стал писать тесты для обработки выгрузки остатков, посчитав это «лишней работой».
- Тестировщик проверил только успешные кейсы (например, выгрузка 100 товаров), но не учел пограничные случаи (5000 товаров, некорректные артикулы).
- Менеджер проигнорировал риск, заявив: «Клиент не заметит, если что-то сломается».
- После запуска система работала 2 дня, затем:
- При выгрузке большого объема данных возникали ошибки памяти.
- Некорректные артикулы блокировали весь процесс синхронизации.
- Клиент потерял 3 дня продаж во время пикового сезона.
Результат:
- Команда перешла в режим «аврала», тратя 90% времени на «латание дыр» вместо развития проекта.
- Репутация компании пострадала: клиент отказался от дальнейшего сотрудничества.
- Разработчик уволился из-за выгорания, менеджер обвинил тестировщика в «халатности».
Почему это связано с невниманием к результатам?
- Подмена целей:
- Команда считала KPI «запустить к сроку», а не «запустить стабильно».
- Индивидуализм:
- Разработчик хотел показать «скорость», тестировщик — «закрыть чек-лист», менеджер — «отчитаться о выполнении».
- Игнорирование долгосрочных последствий:
- Все понимали риски, но предпочли «срезать углы» ради сиюминутных показателей.
Как решить проблему, следуя модели Патрика Ленсиони
Автор подчеркивает: здоровая команда ставит общий результат выше личных амбиций. Вот как это применить к тестированию в 1С:
- Переопределите «результат» вместе с командой:
- Проведите сессию, где сформулируете:
- Что для клиента успех? «Стабильная синхронизация, даже при нагрузке 5000 товаров».
- Что для команды успех? «Ночные авралы и паника — это провал».
- Зафиксируйте это в виде «декларации качества» и разместите в своей базе знаний (например, в Confluence).
- Проведите сессию, где сформулируете:
- Внедрите тестирование как часть Definition of Done:
- Задача не считается выполненной, пока:
- Написаны автоматические тесты для ключевых сценариев.
- Проведено нагрузочное тестирование (для модулей интеграции).
- Тестировщик подтвердил, что покрыты пограничные случаи.
- Задача не считается выполненной, пока:
- Визуализируйте качество как KPI:
- Создайте дашборд с метриками:
- % покрытия кода тестами.
- Количество ошибок в продовой среде.
- Время, потраченное на исправление багов после релиза.
- Пример: если в прошлом проекте 40% времени ушло на «латание дыр», покажите это команде: «Каждый день без тестов = два дня исправлений».
- Создайте дашборд с метриками:
- Проводите «демо-дни» для клиента:
- Раз в две недели показывайте рабочую версию модуля, включая тестовые сценарии.
- Если клиент просит ускориться, приведите данные: «Сокращение тестирования на 20% увеличит риск сбоев на 65%».
- Поощряйте командную ответственность:
- Введите правило: «Баги в продовой среде — проблема всей команды, а не одного человека».
- Если тестировщик пропустил ошибку, спросите: «Как мы можем улучшить процесс, чтобы это не повторилось?» вместо поиска виноватого.
Итог
Пренебрежение тестированием в 1С — это не просто «лень писать тесты». Это симптом того, что команда не считает качество продукта своим главным результатом.
Что внедрить завтра же:
- Добавьте в график еженедельный «Тест-день», где вся команда участвует в проверке критических сценариев.
- Используйте специальные инструменты для создания регрессионных тестов.
- Начните митинг с вопроса: «Что мы сделали на этой неделе, чтобы снизить риски для клиента?».
Когда качество станет общей ценностью, а не «проблемой тестировщика», пренебрежение тестированием исчезнет само собой.
Заключение
Проблемы в 1С-проектах часто коренятся не в технологиях, а в «человеческих» дисфункциях. Книга «5 пороков команды» Патрика Ленсиони дает инструменты, чтобы их устранить:
- Постройте доверие через открытость.
- Превратите конфликты в источник решений.
- Напоминайте о целях и вовлекайте команду в их достижение.
Примените эту философию к вашим 1С-проектам, и вы увидите, как растут качество и скорость разработки.