惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

酷 壳 – CoolShell
酷 壳 – CoolShell
G
Google Developers Blog
V
V2EX
美团技术团队
H
Help Net Security
月光博客
月光博客
爱范儿
爱范儿
Engineering at Meta
Engineering at Meta
The Cloudflare Blog
U
Unit 42
大猫的无限游戏
大猫的无限游戏
Recent Announcements
Recent Announcements
A
About on SuperTechFans
博客园 - Franky
The GitHub Blog
The GitHub Blog
N
Netflix TechBlog - Medium
人人都是产品经理
人人都是产品经理
博客园 - 司徒正美
MyScale Blog
MyScale Blog
B
Blog
雷峰网
雷峰网
Y
Y Combinator Blog
云风的 BLOG
云风的 BLOG
T
The Blog of Author Tim Ferriss

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Нулевой этап проекта: как подготовить команду и не сорват...
Kot_begemot1 · 2026-05-06 · via Все публикации подряд на Хабре

Нулевой этап проекта: как подготовить команду и не сорвать внедрение

Время на прочтение5 мин

Охват и читатели54

Мнение

В корпоративных проектах обычно много внимания уделяют срокам, бюджету, функциональности и интеграциям. Но на практике успех или провал проекта часто определяется и другим фактором — готовностью людей к изменениям.

Если пользователи не понимают, зачем меняется их работа, если опасения не проговариваются, а решения спускаются сверху, проект почти неизбежно сталкивается с сопротивлением. Формально он может идти по плану, но согласования затягиваются, старые инструменты продолжают жить параллельно, а после запуска компания получает не новую рабочую модель, а затяжной конфликт между бизнесом, ИТ и пользователями.

Именно поэтому до старта внедрения полезно пройти нулевой этап — подготовку команды к изменениям. Это не про технологии. Это про людей, роли, ожидания и внутреннюю готовность, без которой даже хорошо спроектированный проект начинает буксовать.

Почему сопротивление возникает почти неизбежно

Любой проект — это изменение привычного порядка работы. Меняются инструменты, процессы, зоны ответственности, а иногда и сами правила принятия решений.

Компании часто предполагают, что достаточно выбрать систему, описать требования и провести обучение. Но на деле пользователи нередко оказываются вовлечены в проект по остаточному принципу: после основной работы, «если будет время». Формально команда участвует, но не воспринимает изменения как свои. В итоге решения зависают, новые процессы не приживаются, а старые практики — чаще всего Excel — продолжают работать как ни в чем не бывало.

Это не обязательно саботаж в прямом смысле. Чаще люди просто выбирают понятное и безопасное. Если новая модель выглядит как лишняя нагрузка, потеря влияния или риск не справиться, сопротивление становится естественной реакцией.

Особенно остро это проявляется там, где уже был неудачный опыт внедрений. Тогда любое новое изменение быстро вызывает у команды понятный сценарий: переработки, стресс, хаос и отсутствие результата.

Где проходит настоящая линия напряжения

В проектах обычно говорят о трех уровнях изменений: инструменты, процессы и управление.

С инструментами все относительно понятно: новые формы, сервисы и отчеты можно поддержать обучением. Процессы требуют регламентов и дисциплины. Управление — новых правил принятия решений.

Но наибольшее напряжение возникает не здесь, а на уровне ролей — формальных и неформальных. У каждого подразделения есть люди, на которых реально держится работа. Иногда они не занимают высоких должностей, но обладают уникальной экспертизой или сильным влиянием на коллег. Если таких людей не увидеть заранее, проект рано или поздно столкнется с сопротивлением, которого не было ни в одном плане.

Люди сопротивляются не потому, что хотят помешать проекту. Чаще они защищают свое профессиональное положение. Сотрудник понимает, за что его ценят сегодня, и боится, что новая система обесценит накопленную экспертизу или сделает его роль менее значимой.

Поэтому простое «надо объяснить пользователям» работает не всегда. Если за внешним согласием остаются невысказанные страхи и сомнения, они все равно проявятся — в кулуарных разговорах, затягивании решений и возврате к привычным инструментам.

Что такое нулевой этап

Нулевой этап — это управленческая работа с готовностью команды к изменениям. Его задача — не продавить проект сверху, а создать условия, при которых пользователи сами включаются в обсуждение будущих изменений и начинают воспринимать их как ответ на свои реальные проблемы.

По сути, речь идет о том, чтобы общение с людьми начиналось еще до классического сбора требований. В этот момент важно не только определить стейкхолдеров, роли и карту изменений, но и понять, что именно мешает подразделениям работать эффективнее и чего они сами ждут от будущего проекта.

Когда это получается, технология перестает быть целью и становится инструментом.

Как это работает на практике

Один из показательных кейсов в моей практике связан с производственной компанией, работающей на международном рынке. У нее был сложный финансовый контур: поступления из разных стран, расчеты в золоте, драгоценных камнях или крипте и сильная зависимость от команды аналитиков, где каждый отвечал за свой регион.

Проблема заключалась в том, что ключевая экспертиза существовала в головах конкретных людей. Процессы менялись, но знания почти не были формализованы. Один из эпизодов это особенно хорошо показал: сотрудница, отвечавшая за Корею, ушла в декрет — и направление фактически остановилось. Чтобы сохранить управляемость, ей пришлось организовать полноценное рабочее место дома.

Компания уже пыталась автоматизировать этот контур — силами своей ИТ-команды и внешних подрядчиков. Под задачи бизнеса даже разработали отдельный финансовый блок. Но Excel никуда не делся. Пользователи конфликтовали с ИТ и интеграторами, а затем возвращались к привычным инструментам. Доверие к любым внедрениям оказалось практически исчерпано.

В этой ситуации было решено начать не с новой системы, а с нулевого этапа: провести двухдневную стратегическую сессию до проекта. Принципиально важно, что она не была завязана на обсуждение конкретной платформы или учета. Разговор шел о работе подразделения и о том, что реально мешает людям.

Участники работали в группах с фасилитацией. Им не навязывали готовые решения и не подталкивали к заранее выбранной технологии. Их задача была другой — самим сформулировать, что именно нужно менять, чтобы подразделение работало лучше.

Это быстро вывело разговор за пределы чисто ИТ-повестки. Обсуждали не только процессы и отчетность, но и вполне приземленные вещи: неудобные рабочие места, потери времени на бумажные отчеты, бытовые раздражители. Но именно через такие детали команда вышла на более глубокие проблемы и начала формулировать содержательные решения.

На выходе получились вполне прикладные результаты: карта процессов, список ограничений, перечень улучшений, приоритизированный бэклог, дорожная карта первых шагов и распределение ролей. Но главное было не в этом. Пользователи перестали быть объектом изменений и стали их соавторами.

Что это меняет для проекта

После такой подготовки команда входит в обследование уже в другом состоянии. Люди не ждут, что им в очередной раз принесут чужое решение и попросят «просто работать по-новому». Они сами понимают, какие проблемы хотят решить и чего ждут от изменений.

Это принципиально меняет динамику проекта. Снижается скрытое сопротивление, быстрее идут согласования, а у спонсора появляется возможность показать быстрый результат в первые недели — а это критично для удержания доверия.

В описанном кейсе именно это и стало поворотной точкой. Руководство получило более прозрачный финансовый контур и снизило зависимость от носителей уникальной экспертизы. Но еще важнее было то, что сама команда приняла идею изменений, потому что воспринимала ее как свою.

Почему это важно бизнесу

Нулевой этап не гарантирует, что проект пройдет без сложностей. Но он создает среду, в которой изменения становятся управляемыми.

Когда пользователи включены в процесс осмысленно, снижается уровень конфликтов, команда меньше выгорает, а сам проект перестает быть противостоянием между заказчиком, исполнителем и внутренними подразделениями. Вместо этого появляется ощущение общей работы на результат.

Главный эффект в том, что проект переходит из режима «нам навязали изменения» в режим «мы сами хотим получить результат». А это и есть та точка, с которой обычно начинаются устойчивые изменения.