Привет, Хабр! Меня зовут Екатерина Горшкова я старший аналитик Битрикс24 в ZeBrains. Девять лет в продажах, шесть в IT, ещё год в образовании. Звучит как разные вселенные, но если честно, это одна и та же профессия под разными вывесками. Потому что везде нужно было понять человека напротив и договориться так, чтобы результат устроил обе стороны. 

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

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

Это, кстати, только один типаж из целой галереи, которую можно увидеть на почти любом проекте:

• Всезнайка — пример выше. Работает через фиксацию решений и делегирование ответственности.

• Не хочу, не буду — заказчик, который саботирует любые изменения процесса просто потому, что раньше было по-другому. Здесь почти никогда не помогает давление, помогают маленькие безопасные эксперименты с понятным путём отхода назад.

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

• Ещё одна маленькая доработка — классика жанра, скоуп-крип в чистом виде. Про него отдельно ниже.

• Реалист — на самом деле мечта, а не тип, с ним всё решается напрямую, без надстроек.

Вывод к которому мы в итоге пришли: проблема не в заказчике и не в жадности до фичей, а в том, что у него просто нет доступа к внутренней картине системы, которая есть у вас. Он не видит связей. Единственное, что реально работает не спорить, а каждый раз кратко объяснять, что стоит за изменением и подтверждать оценку письменно до начала работы. 

У нас общая цель, просто мы про это забываем

Мораль простая: не стоит искать корень зла исключительно на стороне заказчика. Команда контактирует друг с другом каждый день и там тоже своя динамика со своими слепыми зонами.

Если разложить типовые конфликты по причинам, получается не так уж много вариантов:

1. Все мы люди — эмоции, усталость, плохой день никто не отменял.

2. Плохая осведомлённость на стороне заказчика — он реально не знает, как устроена разработка изнутри.

3. Плохая осведомлённость на стороне подрядчика — команда не до конца понимает бизнес-процессы заказчика.

4. Неправильная декомпозиция и оценка задач.

5. Отсутствие договорённостей или разное видение конечного результата.

6. Некомпетентность или конфликтность конкретных людей — да, иногда дело правда в этом, и это нормально признать.

Если честно проанализировать десяток конфликтных ситуаций, девять из десяти окажутся про пункты 2–5, то есть про информационный разрыв, а не про личные качества. И это хорошая новость, потому что информационный разрыв единственная из шести причин, которая полностью в зоне влияния команды.

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

• коммуникация со всеми участниками проекта;

• информационная поддержка в процессе работы;

• проработанное и понятное каждой роли техническое задание;

• организация обсуждения фич и предложений;

• понятные формулировки — без двойных прочтений.
  

  

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

Этапы продаж — да, они применимы и к команде

Немного неожиданный поворот, который лично мне помог сильнее всего: классическая воронка продаж (установка контакта → выявление потребности → презентация → работа с возражениями → закрытие сделки) работает не только с заказчиком, но и внутри команды. Закрытие сделки в проектном контексте это завершение проекта, но микро-циклы этой воронки повторяются на каждой задаче, на каждом ревью, на каждом обсуждении фичи.

Отдельно мы спросили команды, с какими проблемами люди чаще всего сталкиваются, работая в связке с аналитиком. Список ответов получился длинным — от «неточное ТЗ» до «нет отраслевой экспертизы»  и на первый взгляд разрозненным. Но если сгруппировать проблемы по навыкам, которые нужны, чтобы их решить, картина упрощается до трёх категорий:

• Навыки аналитика (58%) — хард-скиллы вроде написания технического задания, проектирования системы, приоритизации задач, а также смежные софт-скиллы.

• Коммуникация (28%) — проблемы, связанные напрямую с общением: непонятные формулировки, отсутствие обсуждения фич, разночтения при передаче информации.

• Опыт в сфере (14%) — то, что решается только насмотренностью: знание внедряемой системы, глубокая техническая экспертиза, знание бизнес-процессов заказчика.

Больше половины проблем — это база: банально плохо написанное ТЗ создаёт больше конфликтов, чем токсичный заказчик. Но и 28% на чистую коммуникацию — тоже не мелочь, которую можно списать на «сработаемся как-нибудь».

С хард-скиллами всё довольно приземлённо. Написание технического задания и отрисовка схем — это навык, который прокачивается практикой и хорошими источниками. Пара ориентиров, которые реально пригодились: статья «Как составить техническое задание» — лаконичная, без воды, и книга Карла Вигерса «Разработка требований к программному обеспечению», которую многие аналитики не зря называют настольной.

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

С коммуникацией — самое интересное, потому что здесь легче всего почувствовать сопротивление, а не результат. Например, ретроспектива — казалось бы, простой формат: раз в квартал (частота зависит от проекта) собираться и честно говорить, что понравилось, а что нет. На практике это один из самых сложных барьеров: люди боятся говорить прямо, особенно про коллег, с которыми работать ещё полгода. У нас был проект, где первые две ретроспективы прошли формально — «всё ок, вопросов нет» — а через месяц накопившееся недовольство одного из разработчиков вылилось в резкий конфликт на созвоне с заказчиком. После этого мы поменяли формат: стали начинать ретро с анонимного сбора тезисов до обсуждения вслух, чтобы человеку не приходилось быть первым, кто скажет вслух неудобную вещь. Конфликтов такого масштаба больше не было — не потому что все стали идеально дружелюбны, а потому что недовольство перестало копиться месяцами.

Из инструментов, которые реально стоит попробовать:

• деловые игры для отработки коммуникации — с обязательным разбором результатов после (хорошо ложится книга «Взломай код общения» Ванессы ван Эдвардс);

• регулярные ретроспективы с честной, но безопасной структурой обратной связи;

• работа с эмоциональным интеллектом — тема объёмная, но полезно начать хотя бы с разбора того, как эмоции влияют на принятие решений в моменте конфликта;

• книга Максима Дорофеева «Джедайские техники» — не столько про коммуникацию напрямую, сколько про то, как не тащить в диалог с командой усталость и перегруженный инбокс, которые сильно портят тон разговора;

• мозговые штурмы — формат, который на удивление редко используют по назначению, а зря: часть лучших решений на моей памяти родилась именно там, а не в личных задачах.

Если вынести из всего этого одну мысль, то вот она: техническая экспертиза закрывает часть проблем проекта, но не все. Больше половины сложностей действительно решаются прокачкой хард-скиллов. Но почти треть проблем, с которыми сталкивается команда, лежит в зоне чистой коммуникации, и эта зона обычно остаётся на самотёк до первого серьёзного конфликта. Дешевле выстроить процесс заранее чем разгребать последствия постфактум.

Проект не тонет из-за плохого кода чаще, чем тонет из-за того, что два человека были уверены, что говорят об одном и том же, а на деле — о разном.