В прошлых статьях мы разбирали, как 1С-команда может жить в режиме Go-Go: много задач, много срочности, много героизма, но мало устойчивой системы.
Это знакомое состояние: задачи летят в личку, релизы собираются на ручном управлении, техдолг признают, но откладывают, а критичные участки системы держатся на одном-двух сильных разработчиках.
Но Go-Go — не финальная точка развития. Это стадия, через которую многие команды проходят на росте. Вопрос в другом: куда идти дальше?
В модели жизненного цикла Ицхака Адизеса одним из самых здоровых состояний организации считается Расцвет — Prime. Это момент, когда у команды есть и энергия результата, и порядок, и развитие, и способность договариваться.
Если перевести на язык 1С, Расцвет — это не идеальная команда без проблем. Проблемы остаются: пользователи ошибаются, релизы иногда горят, интеграции падают, типовые конфигурации обновляются не сами, а техдолг всё равно появляется.
Разница в другом:
Зрелая 1С-команда не живет только на героизме. Она умеет превращать повторяющиеся проблемы в процессы, знания и управляемые решения.
В этой статье разберем, как выглядит Расцвет 1С-команды на практике: в задачах, релизах, техдолге, коммуникации с бизнесом, работе разработчиков, аналитиков и руководителей.
Расцвет — это не идеальная команда
Важно сразу убрать одно заблуждение.
Расцвет — это не состояние, где:
- нет срочных задач;
- нет ошибок в релизах;
- все требования всегда идеальны;
- пользователи всё понимают с первого раза;
- разработчики никогда не спорят;
- техдолг исчез навсегда;
- документация написана на всё и всегда актуальна.
Такой команды, скорее всего, не существует. А если кто-то говорит, что у него так, возможно, он просто давно не открывал бэклог.
Расцвет — это не отсутствие проблем. Это способность команды работать с проблемами системно.
Например:
- инцидент случился — команда не только потушила пожар, но и разобрала причину;
- релиз прошел тяжело — команда улучшила чек-лист или порядок проверки;
- пользователи снова ставят задачи в личку — команда разбирает, почему официальный канал не работает;
- обмен упал третий раз — команда не просто перезапустила задание, а решила, как снизить повторение;
- внешняя обработка сломалась после обновления — команда включила её в реестр и smoke-проверку перед релизом.
Зрелость начинается там, где команда перестает только реагировать и начинает учиться.
Четыре признака Расцвета через PAEI
У Адизеса есть модель PAEI:
- P — результат;
- A — порядок;
- E — развитие;
- I — интеграция, доверие и командность.
На стадии Go-Go обычно много P и E: команда много делает, быстро реагирует, пробует, запускает, чинит, вытаскивает.
Но часто не хватает A и I: порядка, повторяемости, договоренностей, устойчивой коммуникации.
Расцвет 1С-команды появляется тогда, когда все четыре функции начинают работать вместе.
| Роль | Как выглядит в зрелой 1С-команде | Что происходит при перекосе |
|---|---|---|
| P — результат | Задачи закрываются, релизы выходят, пользователи получают работающие решения | Если только P — команда живет в авралах и героизме |
| A — порядок | Есть понятные правила задач, релизов, тестирования, документации и качества | Если только A — появляется бюрократия и страх изменений |
| E — развитие | Команда улучшает архитектуру, инструменты, процессы, автоматизирует рутину | Если только E — много идей, но мало завершения |
| I — командность | Разработчики, аналитики, бизнес и пользователи умеют договариваться | Если только I — много обсуждений, но мало решений |
Расцвет — это не когда одна роль победила остальные. Это когда роли сбалансированы.
Команда умеет быстро делать, но не превращает скорость в хаос. Умеет вводить порядок, но не душит им работу. Умеет развиваться, но не распыляется на десятки инициатив. Умеет договариваться, но не заменяет решения бесконечными обсуждениями.
Признак 1. Задачи прозрачны и не живут только в личке
В незрелой команде значительная часть работы может существовать в переписках:
- пользователь написал разработчику;
- аналитик договорился голосом;
- руководитель переслал задачу в мессенджере;
- разработчик “быстро поправил”;
- в общем бэклоге этого никто не увидел.
В зрелой 1С-команде живое общение никуда не исчезает. Люди всё равно пишут друг другу, созваниваются, уточняют детали. Но работа не растворяется в личных договоренностях.
Главное правило:
Обсуждать можно где угодно, но работа должна быть видна в общем контуре.
Это не значит, что каждая мелочь должна превращаться в огромную заявку на три страницы. Но у команды есть понятное место, где видно:
- что сейчас в работе;
- какой у задачи приоритет;
- кто ответственный;
- какой ожидается результат;
- что уже сделано;
- что заблокировано;
- что вошло в релиз;
- что отложено.
Для 1С-команды это критично. Потому что задачи часто касаются учета, документов, обменов, прав, печатных форм, регламентных операций и связанных бизнес-процессов.
Если такая задача живет только в личке, команда теряет управляемость. А если она видна в общем контуре, руководитель, аналитик, разработчик и бизнес могут говорить об одной и той же реальности.
Признак 2. Релизы предсказуемы, а не героичны
В Go-Go релиз часто похож на аврал:
- в последний момент выясняется, что вошло не всё;
- непонятно, какие внешние обработки обновились;
- расширение проверили только “на глаз”;
- пользователи тестировали выборочно;
- описание изменений собирается после установки;
- план отката существует только в голове у разработчика;
- после релиза команда тушит неожиданные ошибки.
В зрелой команде релиз не обязательно становится тяжелым enterprise-процессом. Но у него появляется минимальная повторяемость.
Например:
- есть состав релиза;
- понятно, кто отвечает за сборку;
- есть минимальный чек-лист проверки;
- понятно, какие внешние обработки и расширения затронуты;
- есть тестовый контур;
- есть список пользователей или ключевых ролей, которые должны проверить изменения;
- есть короткое описание, что поменялось;
- после релиза фиксируются ошибки и выводы.
Зрелость не в том, что релизы никогда не ломаются.
Зрелость в том, что после каждого релиза команда становится чуть лучше подготовлена к следующему.
Признак 3. Техдолг виден и управляется
В незрелой команде техдолг существует в разговорах:
- “эту обработку надо переписать”;
- “этот обмен страшно трогать”;
- “тут запрос тяжелый, но пока работает”;
- “это расширение давно пора разобрать”;
- “документации нет, но Вася помнит”.
Все знают, что проблема есть. Но в плане её нет.
В зрелой 1С-команде техдолг не обязательно закрывается мгновенно. Но он становится видимым.
У него появляется хотя бы минимальная структура:
- что именно является техдолгом;
- где находится риск;
- на какой процесс влияет;
- что будет, если ничего не делать;
- какой уровень критичности;
- кто владелец участка;
- когда команда вернется к этому вопросу.
Главный сдвиг — техдолг перестает быть внутренней болью разработчиков и становится управляемым риском для бизнеса.
| Как часто говорят | Как лучше формулировать зрелой команде |
|---|---|
| Код старый и некрасивый | Изменения в этом участке занимают в 2 раза больше времени и чаще дают ошибки |
| Обмен написан костылями | Есть риск остановки процесса при изменении формата или обновлении |
| Нет документации | Критичный участок зависит от одного человека |
| Нужно переписать отчет | Отчет тормозит работу пользователей и создает нагрузку на базу |
| Расширение непонятное | Перед обновлением сложно оценить, что оно затрагивает и что может сломаться |
Такой перевод на язык риска помогает бизнесу понять, что техдолг — это не “разработчики хотят красиво”, а реальная стоимость будущих изменений.
Признак 4. Команда не держится на одном герое
В сильных 1С-командах почти всегда есть люди, которые знают больше остальных. Это нормально.
Проблема начинается, когда знание становится единственной точкой отказа.
Например:
- только один человек знает, как устроен обмен с ЭДО;
- только один человек понимает закрытие месяца;
- только один человек умеет обновлять конфигурацию;
- только один человек знает, где актуальные внешние обработки;
- только один человек может объяснить, зачем сделано конкретное расширение.
В зрелой команде экспертиза не исчезает, но становится передаваемой.
Это не означает, что все должны знать всё. Это невозможно и не нужно.
Но по критичным участкам должны быть:
- минимальное описание;
- второй человек, который понимает базовую логику;
- инструкция на случай типовой проблемы;
- понятное место хранения артефактов;
- чек-лист проверки после изменений;
- история важных решений.
Зрелая команда уважает героев, но не строит всю систему на их постоянной доступности.
Признак 5. Аналитики, разработчики и бизнес спорят продуктивно
В любой живой 1С-команде будут споры.
Разработчик может говорить:
“Так делать опасно, мы сломаем типовой механизм”.
Аналитик может отвечать:
“Но бизнесу нужен именно такой сценарий, иначе процесс не взлетит”.
Бизнес может давить:
“Нам нужно к пятнице, иначе пользователи опять будут вести это в Excel”.
В незрелой команде такие споры быстро превращаются в обвинения:
- разработчики “тормозят”;
- аналитики “не умеют ставить задачи”;
- бизнес “сам не знает, чего хочет”;
- руководитель “просто давит сроками”.
В зрелой команде спор не исчезает, но становится рабочим инструментом.
Люди обсуждают не личности, а ограничения:
- что нужно бизнесу;
- какие есть технические риски;
- какие есть ограничения типовой конфигурации;
- что можно сделать быстро;
- что нужно вынести в отдельный этап;
- какой минимальный результат можно дать сейчас;
- что потом надо улучшить.
Это и есть зрелая интеграция: не все всегда согласны, но команда умеет приходить к решению без разрушения доверия.
Признак 6. Порядок не душит скорость
После Go-Go команда часто пытается навести порядок. И тут есть риск уйти в другую крайность.
Было:
“Делаем быстро, потом разберемся”.
Стало:
“Без идеального описания, трех согласований и полного комплекта документов ничего не делаем”.
Это не Расцвет. Это движение в сторону бюрократии.
В зрелой 1С-команде порядок помогает результату, а не заменяет его.
Например:
- шаблон задачи помогает быстрее понять результат, а не просто заполнить поля;
- code review снижает риск ошибки, а не превращается в поиск виноватых;
- релизный чек-лист помогает не забыть критичное, а не тормозит каждую мелочь;
- документация фиксирует важные решения, а не описывает очевидное ради галочки;
- регламент срочных задач помогает управлять приоритетами, а не запрещает реальность.
Хороший порядок почти незаметен. Он просто делает работу спокойнее и предсказуемее.
Признак 7. Развитие не тонет в текущей поддержке
В 1С-командах легко застрять в текущей поддержке:
- поправить отчет;
- разобрать ошибку пользователя;
- перезапустить обмен;
- обновить печатную форму;
- проверить права;
- подправить внешнюю обработку;
- срочно закрыть задачу к релизу.
Все эти задачи нужны. Но если команда занимается только ими, она не развивается.
В Расцвете у команды есть место не только для реакции, но и для улучшений.
Например:
- автоматизировать ручную проверку;
- вынести повторяющиеся действия в обработку;
- улучшить диагностику обмена;
- настроить smoke-проверку внешних обработок;
- сделать реестр расширений;
- описать критичный процесс;
- убрать один старый костыль;
- снизить количество однотипных обращений пользователей.
Развитие в зрелой команде — это не только большие проекты. Иногда это маленькие улучшения, которые уменьшают будущий хаос.
Что часто путают с Расцветом
“У нас мало конфликтов”
Отсутствие конфликтов не всегда означает зрелость.
Иногда это значит, что люди просто перестали спорить, потому что не верят, что их услышат.
В Расцвете конфликты не исчезают. Они становятся конструктивнее.
“У нас много регламентов”
Количество регламентов не равно зрелости.
Можно написать десятки инструкций, но если пользователи всё равно идут в личку, релизы всё равно горят, а техдолг никто не планирует — процесс не работает.
Зрелость — это не наличие документов. Зрелость — это когда правила помогают работе.
“У нас сильный разработчик всё вытягивает”
Сильный разработчик — это хорошо.
Но если без него команда не может выпустить релиз, обновить базу, починить обмен или разобраться в критичной обработке — это не Расцвет.
Это всё ещё зависимость от героя.
“У нас всё стабильно, мы ничего не трогаем”
Стабильность сама по себе не плоха.
Но если команда перестала улучшать систему, боится изменений, откладывает обновления и выбирает “не трогать, чтобы не сломать” как основную стратегию — это уже не Расцвет.
Это может быть начало старения.
Как двигаться к Расцвету после Go-Go
Переход к Расцвету не делается одним приказом.
Нельзя сказать:
“С понедельника мы зрелая команда”.
Но можно постепенно создавать условия, в которых команда перестает жить только героизмом.
1. Сделать работу видимой
Первый шаг — вытащить работу из личек, устных договоренностей и памяти отдельных людей.
Не обязательно строить сложную систему управления проектами. Но должен быть общий контур, где видно:
- задачи;
- приоритеты;
- ответственные;
- статусы;
- состав релизов;
- техдолг;
- критичные артефакты;
- повторяющиеся проблемы.
То, что не видно, почти невозможно управлять.
2. Навести порядок в критичных артефактах
Для 1С-команды это особенно важно.
Критичные артефакты — это:
- внешние обработки;
- внешние отчеты;
- расширения;
- регламентные задания;
- интеграции;
- обмены;
- печатные формы;
- доработанные участки типовой конфигурации;
- скрипты и служебные обработки сопровождения.
Минимум, который стоит знать:
- где лежит актуальная версия;
- кто владелец;
- для чего используется;
- какую конфигурацию поддерживает;
- когда проверялась последний раз;
- что может сломаться после обновления;
- как быстро проверить работоспособность.
Это не роскошь. Это база для спокойного сопровождения.
3. Ввести минимальный релизный процесс
Не надо начинать с тяжелого регламента.
Для старта достаточно:
- фиксировать состав релиза;
- проверять критичные сценарии;
- отдельно проверять внешние обработки и расширения;
- заранее предупреждать пользователей;
- фиксировать ошибки после релиза;
- разбирать повторяющиеся проблемы.
Если релиз стал чуть менее нервным — процесс уже дает пользу.
4. Перевести техдолг в язык риска
Разработчики часто говорят о техдолге техническим языком. Бизнесу он может быть непонятен.
Лучше формулировать так:
- какой бизнес-процесс пострадает;
- какой риск возникает;
- какая стоимость бездействия;
- какие изменения станут дороже;
- какая зависимость от людей сохраняется;
- что можно сделать маленьким шагом.
Тогда техдолг становится не “внутренней проблемой ИТ”, а частью управления системой.
5. Оставить место для развития
Если вся загрузка команды забита текущими обращениями, Расцвет невозможен.
Команде нужно хотя бы небольшое пространство для улучшений.
Это может быть:
- 10% времени на техдолг;
- одна задача улучшения в каждом релизе;
- один день в месяц на внутренние инструменты;
- регулярный разбор повторяющихся проблем;
- маленькие автоматизации ручной работы;
- улучшение диагностики и поддержки.
Зрелая команда не только закрывает поток задач. Она периодически уменьшает сам поток.
Чек-лист зрелости 1С-команды
Ниже — простой чек-лист. Это не формальная методика, а способ быстро посмотреть на команду со стороны.
| Вопрос | Да / Нет |
|---|---|
| Можно ли понять статус ключевых задач без личных уточнений? | |
| Есть ли понятный состав ближайшего релиза? | |
| Проверяются ли критичные внешние обработки и расширения перед обновлением? | |
| Есть ли список критичного техдолга? | |
| Понимает ли бизнес, какие технические риски есть в системе? | |
| Есть ли критичные участки, которые знает только один человек? | |
| Фиксируются ли причины повторяющихся инцидентов? | |
| Есть ли время на улучшения, а не только на срочные задачи? | |
| Пользователи доверяют официальному каналу постановки задач? | |
| Порядок помогает работе, а не существует ради контроля? |
Если большинство ответов “да”, команда уже движется к зрелому состоянию.
Если большинство ответов “нет”, это не повод обвинять людей. Это повод признать: система управления пока не догнала сложность работы.
Как выглядит день зрелой 1С-команды
Попробуем описать не идеальную картинку, а реалистичный рабочий день.
Утром команда видит актуальный список задач. Срочные обращения есть, но они фиксируются и не ломают весь план автоматически.
Аналитик уточняет требования не “в воздухе”, а в контексте задачи и процесса. Разработчик понимает, что считается результатом. Пользователь понимает, когда ждать изменение и где смотреть статус.
Если появляется инцидент, команда реагирует быстро. Но после решения хотя бы коротко фиксирует причину: это ошибка данных, проблема обмена, недоработка, права, регламентное задание или человеческий фактор.
Релиз готовится не идеально, но понятно: есть список задач, есть проверка критичных сценариев, есть понимание, какие обработки, расширения и обмены затронуты.
Техдолг не исчезает. Но у него есть место, где он виден. По части пунктов понятно, почему они важны бизнесу. Иногда команда закрывает не только “новые хотелки”, но и старые риски.
Руководитель не является единственным диспетчером всего. Часть решений команда принимает по понятным правилам. Часть вопросов эскалируется, но не каждая мелочь требует ручного вмешательства.
Разработчики спорят. Аналитики спорят. Бизнес спорит. Но спор идет вокруг результата, рисков и приоритетов, а не вокруг того, кто виноват.
Это и есть практический Расцвет: не отсутствие сложности, а способность команды с этой сложностью справляться.
Главная опасность Расцвета
У Расцвета тоже есть риск.
Когда команда наконец навела порядок, стала предсказуемее и снизила хаос, появляется соблазн зафиксировать всё как есть.
“Теперь работает — не трогайте”.
“Зачем менять процесс, он же нормальный”.
“Мы уже навели порядок, хватит экспериментов”.
Так Расцвет может начать двигаться в сторону Стабильности, а потом — к бюрократизации.
Поэтому зрелой команде важно не только поддерживать порядок, но и сохранять способность меняться.
Хороший вопрос для команды в Расцвете:
Что из того, что помогало нам вчера, уже начинает мешать нам сегодня?
Ответ на этот вопрос помогает не застрять.
Вместо заключения
Расцвет 1С-команды — это не сказка про идеальных разработчиков, идеальных аналитиков и идеальных пользователей.
Это более земное состояние.
Команда всё ещё сталкивается с ошибками, срочными задачами, обновлениями, техдолгом, спорными требованиями и ограничениями типовой конфигурации.
Но она уже не живет только на героизме.
Задачи видны. Релизы становятся предсказуемее. Техдолг обсуждается языком риска. Критичные знания не заперты в голове одного человека. Бизнес и ИТ могут спорить, но не разрушают доверие. Порядок помогает результату, а развитие не тонет полностью в текущей поддержке.
Если Go-Go — это “мы всё вывезем, потому что у нас сильные люди”, то Расцвет — это:
“Мы справляемся не только за счет сильных людей, но и за счет системы, которая помогает им работать”.
Для 1С-команды это, пожалуй, один из самых здоровых ориентиров.
Не убить скорость процессами. Не задушить развитие регламентами. Не держать всё на героях. Не превращать порядок в бюрократию.
А собрать баланс: результат, порядок, развитие и доверие.
Именно этот баланс и делает 1С-команду по-настоящему зрелой.
Почему задачи буксуют после согласования: CAPI Адизеса на практике
PAEI в 1С-команде: почему разработчики, аналитики и руководители спорят о задачах
От героизма к системе: как понять зрелость 1С-команды по модели Адизеса
1С-команда в режиме “Давай-давай”: почему всё держится на героях и как из этого выйти