У 1С-команд часто повторяются одни и те же проблемы.
В одной команде всё держится на сильном разработчике: он знает все обмены, регламентные задания, расширения, обработки, историю доработок и почему “вот этот реквизит лучше не трогать”.
В другой — постоянные авралы: бизнес приносит срочные задачи, релизы собираются на ручном управлении, ошибки всплывают уже у пользователей, а фраза “надо было вчера” давно стала частью корпоративной культуры.
В третьей — наоборот: регламентов стало много, согласований стало много, протоколов стало много, но скорость разработки почему-то упала. Все формально работают правильно, а результата стало меньше.
На первый взгляд это разные проблемы. Но часто причина одна: команда находится на одной стадии зрелости, а управляют ей так, будто она уже на другой.
Для такой диагностики хорошо подходит модель жизненного цикла организации Ицхака Адизеса. Обычно её применяют к компаниям, но она хорошо ложится и на 1С-команды: внутренние отделы разработки, команды сопровождения, проектные группы внедрения, франчайзи и небольшие продуктовые команды внутри компании.
В этой статье попробую адаптировать модель Адизеса к практике управления 1С-командой: как понять, где вы сейчас, какие симптомы нормальны для вашей стадии и что стоит усиливать, чтобы команда не застряла в вечных пожарах или не превратилась в бюрократический механизм без результата.
Коротко про модель Адизеса
Адизес описывает жизненный цикл организации как последовательность стадий: компания рождается, растёт, взрослеет, достигает расцвета, затем может начать стареть и постепенно терять гибкость.
В классической модели есть такие стадии:
- Ухаживание
- Младенчество
- “Давай-давай” / Go-Go
- Юность
- Расцвет
- Стабильность
- Аристократия
- Ранняя бюрократия
- Бюрократия
- Смерть
Звучит немного драматично, но в управлении это полезная диагностика.
Главная мысль не в красивых названиях стадий. Главная мысль в том, что на разных этапах развития команде нужны разные управленческие акценты.
То, что спасает команду на одной стадии, может мешать ей на другой.
- если маленькую команду в режиме выживания перегрузить регламентами, она может просто перестать двигаться;
- если быстро растущую команду не ограничивать правилами, она может утонуть в хаосе;
- если зрелую команду продолжать закручивать контролем, она может потерять инициативу и скорость.
PAEI: четыре роли, которые нужны команде
В модели Адизеса есть четыре управленческие роли — PAEI.
P — Producer / Производитель результата
Это фокус на результате здесь и сейчас.
В 1С-команде это:
- закрыть задачу;
- исправить ошибку;
- выпустить релиз;
- настроить обмен;
- обновить конфигурацию;
- сделать обработку;
- решить проблему пользователя.
Без P команда много обсуждает, но мало делает.
A — Administrator / Администратор
Это порядок, правила, качество и предсказуемость.
В 1С-команде это:
- единый бэклог;
- правила постановки задач;
- оценки трудозатрат;
- регламент релизов;
- code review;
- тестирование;
- документация;
- контроль качества;
- понятные зоны ответственности.
Без A команда может много делать, но результат будет нестабильным.
E — Entrepreneur / Предприниматель
Это развитие, изменения, идеи и поиск новых решений.
В 1С-команде это:
- автоматизация ручных процессов;
- внедрение CI/CD;
- переход на расширения там, где это оправдано;
- улучшение архитектуры;
- новые интеграции;
- пересмотр старых решений;
- поиск способов делать быстрее и качественнее.
Без E команда постепенно превращается в “службу поддержания прошлого”.
I — Integrator / Интегратор
Это команда, доверие, договорённости и культура взаимодействия.
В 1С-команде это:
- нормальная коммуникация с бизнесом;
- доверие внутри команды;
- обмен знаниями;
- наставничество;
- договорённости по приоритетам;
- умение решать конфликты;
- снижение зависимости от одного “незаменимого” человека.
Без I команда может формально работать, но внутри будет много напряжения, обид, скрытых конфликтов и “каждый сам за себя”.
Если очень коротко:
- рост обычно держится на P + E;
- взросление требует добавлять A + I;
- старение начинается, когда A становится самоцелью, а E умирает.
Стадия 1. Ухаживание: “давайте создадим 1С-направление”
Эта стадия бывает, когда команда или направление ещё не сформированы.
Например:
- компания понимает, что 1С надо развивать внутри, а не только “тушить пожары”;
- руководитель хочет собрать внутреннюю команду вместо постоянной зависимости от подрядчиков;
- франчайзи думает открыть новое направление;
- внутри компании появляется идея создать отдельную продуктовую или интеграционную команду;
- есть желание автоматизировать процессы, но пока нет людей, бюджета и понятного плана.
На этой стадии много разговоров:
- “нам нужна нормальная система задач”;
- “надо бы навести порядок в 1С”;
- “надо уходить от ручных операций”;
- “надо создать команду сопровождения”;
- “надо развивать архитектуру, а не только пилить доработки”.
Но реальных действий ещё мало.
Главный риск этой стадии — остаться в обсуждениях.
В 1С это встречается часто: все понимают, что надо менять подход, но годами продолжают жить в режиме “заявка в мессенджере — разработчик поправил — никто не знает, что изменилось”.
Что усиливать: P.
Нужны первые конкретные действия:
- назначить ответственного;
- собрать список текущих болей;
- выбрать систему учёта задач;
- описать хотя бы минимальный процесс постановки задач;
- выделить первые регулярные часы на развитие;
- определить, какие проблемы решаем в первую очередь.
На этой стадии не надо сразу строить идеальную методологию управления 1С-разработкой. Надо перейти от разговоров к первому работающему результату.
Стадия 2. Младенчество: “мы уже работаем, но всё держится на руках”
Команда появилась. Задачи идут. Пользователи обращаются. Бизнес ждёт результата.
Но всё ещё очень хрупко.
Как это выглядит в 1С-команде:
- задач больше, чем людей;
- многое делается вручную;
- знания хранятся в головах;
- документации почти нет;
- тестирование нерегулярное;
- релизы собираются “как получится”;
- срочные задачи постоянно ломают планы;
- один-два разработчика знают почти всё;
- бизнес обращается напрямую к тем, кто “быстрее решит”.
Это стадия выживания.
Здесь нормально, что команда устаёт. Нормально, что процессы ещё слабые. Нормально, что часть решений принимается на ходу.
Ненормально — делать вид, что так можно жить всегда.
Главная ошибка на этой стадии — преждевременно строить тяжёлую бюрократию.
Например, команда из двух-трёх человек ещё не успевает закрывать критичные задачи, а ей уже пытаются внедрить многоуровневое согласование, сложные шаблоны ТЗ, еженедельные комитеты, длинные регламенты и отчёты ради отчётов.
В итоге команда не становится зрелой. Она просто начинает медленнее выживать.
Что усиливать: P и немного A.
Практические действия:
- завести единый список задач;
- договориться, какие задачи считаются срочными;
- определить минимальные требования к постановке задачи;
- фиксировать, что было изменено и зачем;
- начать учитывать трудозатраты хотя бы приблизительно;
- описать самые критичные обмены, регламентные задания и внешние обработки;
- убрать хаотичные обращения напрямую к разработчикам.
Ключевое слово — “минимальные”.
На стадии младенчества команде нужны не идеальные процессы, а простые правила, которые помогают не развалиться.
Стадия 3. Go-Go: “растём быстро, но всё горит”
Это стадия, которую легко перепутать с успехом.
Задач много. Бизнес доволен, потому что команда “берётся за всё”. Разработчики героически закрывают доработки. Руководитель чувствует, что направление полезно и востребовано.
Но внутри постепенно накапливается хаос.
Как Go-Go выглядит в 1С-команде:
- команда берётся почти за все задачи;
- приоритеты часто меняются;
- сроки обещаются раньше, чем задача нормально оценена;
- один сильный разработчик становится узким горлышком;
- релизы делаются в авральном режиме;
- техдолг растёт, но его постоянно откладывают;
- обновления конфигураций страшно трогать;
- обмены работают, но никто не уверен, почему именно так;
- бизнес привыкает, что любую проблему можно решить “вручную и срочно”;
- героизм становится частью процесса.
Типичная фраза этой стадии:
“Сейчас некогда наводить порядок, надо делать задачи”.
Проблема в том, что без порядка задач со временем становится не меньше, а больше.
Каждая срочная доработка без анализа добавляет риски. Каждое изменение без документации увеличивает зависимость от конкретного разработчика. Каждый ручной релиз повышает вероятность ошибки.
Главный риск Go-Go — зависимость от героев.
Если один ключевой человек заболел, ушёл в отпуск или уволился, команда внезапно обнаруживает, что “система” на самом деле была не системой, а конкретным человеком с хорошей памятью и высокой стрессоустойчивостью.
Что усиливать: A и I, но не убивать P/E.
Это важный момент. На стадии Go-Go нельзя просто сказать: “Теперь живём по регламенту, шаг влево — расстрел”. Так можно убить скорость и инициативу.
Нужно вводить порядок постепенно.
Что можно сделать:
- завести единый бэклог;
- ввести понятные приоритеты;
- разделить срочные, плановые и проектные задачи;
- определить Definition of Ready для задач;
- начать оценивать задачи в часах;
- ввести регулярное планирование;
- описать зоны ответственности;
- начать проводить code review хотя бы по критичным изменениям;
- выделить время на техдолг;
- описать критичные участки системы;
- перестать принимать задачи в обход общего процесса.
Особенно важно усиливать I — командность и договорённости.
Потому что внедрение процессов почти всегда вызывает сопротивление.
Разработчики могут сказать:
“Раньше просто делали, а теперь бумажки”.
Бизнес может сказать:
“Раньше написал напрямую — и мне быстро сделали”.
Руководитель может думать:
“Я хотел порядок, а получил конфликт”.
Но конфликт на этой стадии — не всегда плохой знак. Часто это признак взросления.
Стадия 4. Юность: “мы пытаемся стать системой, и это больно”
Юность — одна из самых сложных стадий.
Команда уже поняла, что жить только на героизме нельзя. Начинаются попытки внедрить правила, роли, планирование, контроль качества, ответственность.
И тут выясняется, что не все этому рады.
Как юность выглядит в 1С-команде:
- появляется нормальный бэклог;
- задачи начинают проходить через аналитику;
- вводятся оценки трудозатрат;
- появляются правила релизов;
- вводится тестирование;
- часть задач перестают брать “с голоса”;
- разработчики начинают документировать решения;
- появляются роли: аналитик, разработчик, тестировщик, ответственный за релиз;
- руководитель пытается перестать быть единственным центром принятия решений.
Всё вроде правильно. Но становится больно.
Почему?
Потому что старые привычки сталкиваются с новыми правилами.
Раньше можно было договориться напрямую. Теперь нужно поставить задачу нормально.
Раньше сильный разработчик сам решал, как лучше. Теперь нужно согласовывать архитектурные решения.
Раньше бизнес мог прийти с фразой “срочно надо”. Теперь его спрашивают: “А что срочно? Почему? Какой приоритет? Что можно отложить?”
Раньше релиз выпускали, когда “вроде готово”. Теперь нужно пройти проверки.
На этой стадии часто появляются конфликты:
- между бизнесом и ИТ;
- между старыми и новыми сотрудниками;
- между быстрыми разработчиками и сторонниками качества;
- между руководителем и командой;
- между желанием “делать быстрее” и необходимостью “делать устойчивее”.
Главная ошибка юности — построить правила, но не построить доверие.
Если просто добавить регламенты, но не объяснить смысл, команда быстро скатится в формализм:
- задачи будут оформляться “для галочки”;
- оценки будут ставиться “как попросили”;
- тестирование будет проходить номинально;
- ретроспективы превратятся в ритуал;
- разработчики будут искать способы обойти процесс.
Что усиливать: I и здоровый A.
На этой стадии важно не только внедрять правила, но и договариваться.
Что делать:
- объяснять, зачем вводятся процессы;
- показывать команде, что порядок нужен не для контроля ради контроля, а для снижения хаоса;
- договориться с бизнесом о правилах постановки задач;
- разделить ответственность и полномочия;
- определить, кто принимает решения по архитектуре;
- ввести прозрачные критерии срочности;
- обсуждать конфликты, а не замалчивать их;
- обучать сотрудников новым ролям;
- не превращать каждое правило в бюрократическую стену.
Юность — это переход от “команда держится на людях” к “команда держится на системе”.
Но система не должна убить людей.
Стадия 5. Расцвет: “результат, порядок, развитие и команда”
Расцвет — это состояние, к которому хочется прийти.
В 1С-команде это выглядит так:
- задачи понятны и приоритизированы;
- бизнес знает, как ставить задачи;
- команда умеет оценивать сроки;
- релизы проходят предсказуемо;
- критичные изменения тестируются;
- есть контроль качества;
- знания не хранятся только в одной голове;
- архитектурные решения обсуждаются;
- техдолг не игнорируется;
- команда умеет делать не только срочные доработки, но и системные улучшения;
- пользователи получают результат без постоянных авралов;
- руководитель не является единственным узким горлышком.
В терминах PAEI здесь есть баланс:
- P — команда даёт результат;
- A — есть порядок и предсказуемость;
- E — команда развивается и улучшает систему;
- I — люди умеют взаимодействовать и договариваться.
Но расцвет — это не точка, в которой можно расслабиться.
Главный риск Prime — постепенно начать стареть.
Сначала всё выглядит хорошо: процессы работают, задачи идут, кризисов меньше. Потом появляется осторожность. Потом изменения начинают восприниматься как угроза. Потом команда всё чаще говорит: “Лучше не трогать, оно работает”.
И вот расцвет постепенно превращается в стабильность, а затем — в бюрократию.
Что делать:
- не душить инициативу контролем;
- регулярно пересматривать процессы;
- оставлять место для экспериментов;
- не превращать регламенты в священные тексты;
- следить за скоростью принятия решений;
- измерять не только выполнение процесса, но и эффект для бизнеса;
- развивать сотрудников;
- снижать зависимость от отдельных людей;
- не забывать про архитектурное развитие системы.
Зрелая команда — это не та, где всё зарегламентировано. Это та, где порядок помогает результату, а не заменяет его.
Стадия 6. Стабильность: “всё работает, но драйва меньше”
Стабильность выглядит приятно.
Пожаров стало меньше. Релизы идут спокойнее. Пользователи привыкли к процессу. Команда знает свои системы. Руководитель может немного выдохнуть.
Но есть скрытая опасность: команда начинает терять инициативу.
Как это выглядит в 1С:
- задачи выполняются, но улучшений становится меньше;
- команда чаще поддерживает старое, чем создаёт новое;
- рискованные изменения откладываются;
- обновления делают только когда уже нельзя не делать;
- старые костыли становятся “особенностями системы”;
- сотрудники реже предлагают улучшения;
- появляется фраза: “Зачем менять, если работает?”;
- бизнес перестаёт видеть в 1С-команде источник развития и воспринимает её только как поддержку.
На этой стадии начинает снижаться E — предпринимательская функция, энергия изменений.
Что усиливать: E и немного P.
Практические действия:
- регулярно искать процессы, которые можно автоматизировать;
- пересматривать старые решения;
- проводить ревизию техдолга;
- анализировать, какие доработки дают реальный эффект;
- изучать новые возможности платформы и типовых конфигураций;
- выделять время на внутренние улучшения;
- задавать вопрос: “Что мы продолжаем делать просто по привычке?”;
- возвращать связь с пользователями и бизнес-целями.
Стабильность сама по себе не плоха. Плохо, когда стабильность превращается в осторожность, а осторожность — в запрет на развитие.
Стадия 7. Аристократия: “главное — выглядеть правильно”
Аристократия начинается тогда, когда форма становится важнее результата.
В 1С-команде это может выглядеть так:
- согласований становится больше;
- простая доработка проходит слишком длинный путь;
- важнее правильно оформить процесс, чем решить проблему пользователя;
- много совещаний, но мало решений;
- отчёты есть, но по ним не принимают действий;
- люди боятся ошибиться сильнее, чем хотят улучшить систему;
- инициатива снизу воспринимается как нарушение порядка;
- появляются фразы: “Так не принято”, “Сначала согласуйте”, “Мы всегда так делали”.
Команда ещё может быть профессиональной. Системы могут работать. Но энергия развития уже уходит.
Здесь особенно опасно то, что внешне всё выглядит прилично.
Есть регламенты. Есть статусы. Есть протоколы. Есть согласования. Есть отчётность.
Но если посмотреть на результат, может оказаться, что команда стала медленнее, пользователи недовольны, бизнес ищет обходные пути, а сильные сотрудники теряют интерес.
Что усиливать: E и P.
Что делать:
- вернуть фокус на эффект для бизнеса;
- убрать лишние согласования;
- сократить путь принятия решений;
- пересмотреть устаревшие правила;
- чаще общаться с реальными пользователями;
- оценивать задачи не только по факту выполнения, но и по пользе;
- разрешить небольшие безопасные эксперименты;
- вернуть команде право предлагать изменения.
Главный вопрос для этой стадии:
Мы это делаем потому, что это помогает результату, или потому что так исторически сложилось?
Если честно отвечать на этот вопрос, часть процессов может неожиданно оказаться декоративной.
Стадия 8. Ранняя бюрократия: “ищем виноватых”
На этой стадии команда или организация начинает тратить больше энергии на защиту, чем на результат.
Как это выглядит:
- люди стараются не брать ответственность;
- решения принимаются медленно;
- ошибки обсуждаются в формате “кто виноват”, а не “как исправить”;
- подразделения начинают воевать друг с другом;
- ИТ обвиняет бизнес в плохих задачах;
- бизнес обвиняет ИТ в медлительности;
- разработчики обвиняют аналитиков;
- аналитики обвиняют пользователей;
- пользователи обвиняют “1С, которая опять не работает”.
Знакомая картина, правда?
В ранней бюрократии проблема уже не только в процессах. Проблема в культуре взаимодействия.
Люди перестают говорить прямо. Начинают страховаться письмами. Решения принимаются так, чтобы потом можно было показать: “Я предупреждал”.
Результат уходит на второй план.
Что усиливать: I и E.
Нужно возвращать доверие и смысл.
Что делать:
- перестать использовать ошибки только как повод для наказания;
- разбирать проблемы по процессу, а не по персоналиям;
- сделать правила принятия решений прозрачными;
- убрать конфликтующие зоны ответственности;
- сократить лишние уровни контроля;
- вернуть регулярный диалог между ИТ и бизнесом;
- определить общие цели, а не локальные KPI отделов;
- поддерживать инициативы, которые реально улучшают систему.
Самое сложное на этой стадии — признать реальность.
Пока все делают вид, что проблема в “неправильных людях”, система продолжает воспроизводить те же конфликты.
Стадия 9. Бюрократия: “форма вместо результата”
Бюрократия — это состояние, когда процесс окончательно победил смысл.
В 1С-команде это может выглядеть так:
- задача может долго ходить по статусам, но не приближаться к решению;
- пользователи уже не верят, что их проблема будет решена быстро;
- разработчики не предлагают улучшения, потому что “всё равно не согласуют”;
- важнее соблюсти процедуру, чем получить эффект;
- отчётность существует ради отчётности;
- любые изменения воспринимаются как угроза;
- сильные сотрудники уходят или эмоционально выключаются.
Такие системы могут существовать долго, особенно если у них нет внешней конкуренции или бизнес вынужден пользоваться именно этой внутренней ИТ-функцией.
Но с точки зрения развития это тяжёлая стадия.
Что делать?
Тут уже не помогут маленькие косметические улучшения. Нужна серьёзная трансформация:
- пересмотр целей;
- смена управленческого подхода;
- сокращение лишних уровней согласования;
- возвращение ответственности за результат;
- усиление сильных лидеров изменений;
- честная диагностика процессов;
- иногда — изменение структуры команды.
Но лучше, конечно, не доводить до этой стадии.
Быстрая диагностика: где ваша 1С-команда сейчас?
Ниже простой чек-лист. Он не заменяет полноценную диагностику, но помогает увидеть симптомы.
Похоже на младенчество, если:
- задачи есть, но общего процесса почти нет;
- всё держится на нескольких людях;
- знания хранятся в головах;
- релизы и изменения делаются вручную;
- команда постоянно работает в режиме “надо успеть”;
- документация почти отсутствует.
Что делать: усиливать P + минимальный A.
Похоже на Go-Go, если:
- команда берётся почти за всё подряд;
- срочные задачи постоянно ломают планы;
- руководитель или ведущий разработчик — узкое горлышко;
- героизм и авралы стали нормой;
- техдолг растёт;
- качество зависит от конкретного исполнителя;
- процессы слабые, но все говорят: “Потом наведём порядок”.
Что делать: усиливать A + I.
Похоже на юность, если:
- вы внедряете правила, роли и планирование;
- появляются конфликты из-за новых процессов;
- бизнес сопротивляется формализации задач;
- разработчики спорят с новыми правилами;
- команда пытается перейти от героизма к системе;
- часть людей скучает по временам, когда “можно было просто договориться”.
Что делать: усиливать I + здоровый A.
Похоже на расцвет, если:
- есть результат и предсказуемость;
- задачи понятны и приоритизированы;
- релизы проходят управляемо;
- команда не держится на одном человеке;
- есть развитие, а не только поддержка;
- процессы помогают работе, а не мешают ей;
- бизнес понимает правила взаимодействия с командой.
Что делать: удерживать баланс P + A + E + I.
Похоже на стабильность, если:
- всё работает, но инициативы стало меньше;
- команда стала осторожнее;
- улучшения откладываются;
- старые решения редко пересматриваются;
- фраза “лучше не трогать” звучит слишком часто;
- бизнес перестаёт видеть в 1С-команде источник развития.
Что делать: усиливать E + P.
Похоже на аристократию или бюрократию, если:
- согласований много, результата мало;
- люди боятся ошибиться;
- отчёты важнее изменений;
- простые задачи проходят слишком длинный путь;
- пользователи ищут обходные каналы;
- инициатива снизу почти не появляется;
- процессы существуют потому, что “так принято”.
Что делать: возвращать E, P и I. Иногда — радикально пересматривать саму систему управления.
Сводная таблица
| Стадия | Как выглядит в 1С-команде | Главный риск | Что усиливать |
|---|---|---|---|
| Ухаживание | Есть идея создать команду или навести порядок, но мало действий | Остаться в разговорах | P |
| Младенчество | Всё держится на руках, задач много, процессов мало | Не выдержать нагрузки | P + немного A |
| Go-Go | Быстрый рост, авралы, героизм, зависимость от сильных людей | Хаос и выгорание | A + I |
| Юность | Внедряются роли, правила, планирование, возникают конфликты | Бюрократия без доверия | I + здоровый A |
| Расцвет | Есть результат, порядок, развитие и командность | Расслабиться и начать стареть | Баланс PAEI |
| Стабильность | Всё работает, но инициативы меньше | Потеря развития | E + P |
| Аристократия | Много формы, статуса и согласований | Потеря смысла и скорости | E + P |
| Ранняя бюрократия | Поиск виноватых, политика, страх ошибок | Разрушение доверия | I + E |
| Бюрократия | Процесс важнее результата | Угасание команды | Сильный E + новый P |
Несколько практических выводов для руководителя 1С-команды
Первый вывод: не все проблемы лечатся усилением контроля
Иногда контроль действительно нужен. Например, если команда находится в Go-Go и тонет в хаосе, без минимальных правил, планирования, приоритизации и контроля качества она будет всё глубже уходить в авралы.
Но если команда уже в стабильности или аристократии, дополнительный контроль может только ускорить старение.
Второй вывод: героизм полезен только как временная мера
Сильные разработчики, которые “вывозят всё”, очень ценны. Но если система держится только на них, это не зрелость, а риск.
Хорошая команда должна быть сильнее суммы отдельных героев.
Третий вывод: процессы нужны не ради процессов
Регламент релизов, Definition of Ready, code review, тестирование, документация, планирование — всё это полезно только тогда, когда помогает команде давать более качественный и предсказуемый результат.
Если процесс не помогает результату, его надо менять.
Четвёртый вывод: взросление почти всегда вызывает сопротивление
Когда команда переходит от “делаем как получится” к “работаем по системе”, сопротивляться будут почти все:
- бизнесу не понравится, что задачи нельзя ставить в обход процесса;
- разработчикам не понравится дополнительная формализация;
- руководителю не понравится, что внедрение порядка сначала замедляет работу;
- пользователям не понравится, что “быстро поправить” теперь не всегда возможно.
Это нормальная боль роста.
Главное — не перепутать взросление с бюрократией.
Пятый вывод: стадия команды важнее модного инструмента
Можно внедрить Jira, YouTrack, 1С:Документооборот, EDT, Git, CI/CD, автотесты, красивые дашборды и регулярные встречи.
Но если команда не понимает, какую проблему решает инструмент, он не спасёт.
Инструмент должен соответствовать стадии зрелости команды.
Вместо заключения
В проблемах 1С-команды редко виноваты только “плохие пользователи”, “ленивые разработчики”, “непонятливый бизнес” или “неправильный руководитель”.
Чаще причина системнее:
- команда находится на одной стадии зрелости, а управляют ей инструментами другой стадии;
- усиливаются не те управленческие роли;
- симптомы лечат быстрее, чем причины;
- героизм путают с эффективностью;
- порядок путают с бюрократией;
- стабильность путают с развитием.
Если команда в Go-Go, ей не помогут ещё большие авралы. Ей нужны фокус, роли, минимальные правила и снижение зависимости от героев.
Если команда в юности, ей мало просто написать регламенты. Ей нужно выстроить доверие и договориться о новых правилах игры.
Если команда в стабильности, ей опасно бесконечно усиливать контроль. Ей нужно возвращать инициативу, развитие и связь с реальными задачами бизнеса.
Модель Адизеса полезна не тем, что даёт красивую классификацию. Она помогает задать правильный вопрос:
Что нашей 1С-команде действительно нужно усилить сейчас — результат, порядок, развитие или командное взаимодействие?
И если честно ответить на этот вопрос, становится понятнее, что делать дальше.