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