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