В 90% случаев разработка и бизнес сталкиваются с проблемами в общении при совместной оперативной и проектной работе. Это приводит к частому изменению технических заданий и принципов работы продуктов, влияет на сроки и рамки проектов. Сложности в общении приводят к тому, что айтишники и другие сотрудники не довольны результатами работы друг друга.

Почему разработчики и представители бизнеса испытывают трудности в коммуникации друг с другом? Какие инструменты могут помочь решить эту проблему? Как программистам и другим работникам эффективно работать над совместными проектами?

1. Проблемы восприятия информации

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

Например, встреча по “Автоматизации учета дебиторской задолженности” содержала проблемы, ТЗ, распределение ролей, этапы проекта, контрольные точки и сроки. Из всего объема информации участник запомнил только проблему и срок реализации финального решения, остальное ускользнуло из его памяти.

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

Что можно сделать?

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

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

2. Разные языки

Структурные подразделения компаний используют разную терминологию, потому что в них работают профессионалы разных областей. Разработчики используют один профессиональный язык: DevOps, DAG, pipeline, backlog, sprint и т.д. Финансисты используют другой: овердрафт, кредитная линия, отложенный платеж, PL, горизонтальный анализ и т.д. 

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

Что можно сделать?

Разработка универсального языка для компании. Чтобы компания создала такой язык, потребуется бизнес-глоссарий с базовыми терминами и определениями. Глоссарий будет работать, если:

• изучение бизнес-глоссария входит в процесс адаптации сотрудника (онбординг, обучение, прием дел);

• бизнес-процессы связаны с глоссарием (запросы, планы, расчеты);

• документы формируются в соответствии с глоссарием (ТЗ, отчёты, проектная документация). 

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

Изучение чужого языка. Презентации, обучения или обмен опытом помогут разобраться в терминах смежных подразделений. Как вариант – регулярные встречи, где одно подразделение рассказывает остальным о задачах, планах и понятиях. Общение будет еще проще, если рассказчик наглядно показывает инструменты работы, демонстрирует результаты проектов и отвечает на вопросы коллег.

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

3. Уверенность в собственной исключительности

В многих компаниях каждый отдел считает себя исключительным и необходимым для бесперебойной работы фирмы.

Каждое подразделение уверено:

• Компания держится на нашем подразделении;

• Без нашего отдела работа остановится;

• Интересы нашей службы должны стоять на первом месте;

• Только наше подразделение понимает, как работает компания.

Например, в крупной рекламной компании “Рога и копыта” такая ситуация:

• Маркетологи считают, что без них не будет компании, ведь некому делать рекламу;

• Закупщики уверены, что без их работы не будет рекламы, так как не будет ни техники, ни бумаги, ни рекламных материалов;

• Продажники думают, что без них бизнес рухнет, потому что некому будет продавать рекламу;

• Бухгалтерия знает, что без них работа встанет, ведь не будет денег на закупки и зарплаты, так как никто не отразит и не проведет платежи за рекламные кампании;

• Айтишники верят, что без них компания не будет функционировать в принципе, так как сломаются пропускная и учётные системы, будут барахлить компьютеры, висеть сайты с рекламой, закупками и продажами.

Кажется, что ситуация нереальная, но на деле такое встречается в 4 из 5 компаний. Такая уверенность отделов в собственной исключительной роли в жизни фирмы приводит к проблемам в общении и конфликтам интересов. Какие могут быть совместные проекты и справедливое распределение ресурсов, если МОЙ ОТДЕЛ самый важный?!

Что можно сделать?

Осознать важность каждого. Стоит понять, что все подразделения важны и нужны компании, но только пока работают слажено и сообща. Если одни не будут производить товар, то нет смысла его продавать. Если одни не будут поддерживать 1C, то нет смысла пытаться делать проводки. Поэтому проекты – общие и ресурсы – общие. Если стремиться к совместным целям, проявлять заботу и уважение к смежным функциям, то эффективность компании будет расти.

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

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

4. Невнимание к чужим бизнес-процессам

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

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

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

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

Что можно сделать?

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

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

Заключение

Вопрос о том, что более затратно для компании: бороться с проблемами в общении между бизнесом и ИТ или исправлять последствия недопонимания между ними, остается открытым. Разработка и бизнес с трудом понимают друг друга по многим причинам, мы обозначили 4 из них:

1. Общие проблемы восприятия информации;

2. Разные языки общения;

3. Уверенность отделов в собственной исключительности;

4. Невнимание к чужим бизнес-процессам.