В 90% случаев разработка и бизнес сталкиваются с проблемами в общении при совместной оперативной и проектной работе. Это приводит к частому изменению технических заданий и принципов работы продуктов, влияет на сроки и рамки проектов. Сложности в общении приводят к тому, что айтишники и другие сотрудники не довольны результатами работы друг друга.
Почему разработчики и представители бизнеса испытывают трудности в коммуникации друг с другом? Какие инструменты могут помочь решить эту проблему? Как программистам и другим работникам эффективно работать над совместными проектами?
1. Проблемы восприятия информации
Первая проблема: память. Представим объем информации, полученный на рабочей встрече за единицу, тогда в среднем человек запоминает ⅛ этого объема. Так происходит, потому что мозг экономит энергию и тратит ресурс на восприятие неохотно. Без дополнительного закрепления то, что человек запомнил, сохранится только в краткосрочной памяти. Через неделю большая часть незакрепленной информации сотрется.
Например, встреча по “Автоматизации учета дебиторской задолженности” содержала проблемы, ТЗ, распределение ролей, этапы проекта, контрольные точки и сроки. Из всего объема информации участник запомнил только проблему и срок реализации финального решения, остальное ускользнуло из его памяти.
Вторая проблема: концентрация. Есть разные мнения о том, какое время человек может оставаться сфокусированным: от 12 секунд до 20 минут. В любом случае не стоит ожидать, что в течение всей часовой встречи по дебиторской задолженности человек будет оставаться максимально сконцентрированным. Он может, например, сфокусироваться в начале встречи на проблеме и в конце – на сроке.
Что можно сделать?
Повторять. Повторить лишний раз – не лишнее. Повторить тезисы в начале и конце встречи, продублировать главную идею, пояснить одну мысль на 2-3 примерах – всё это поможет участникам лучше запомнить информацию.
Записывать. Писать резюме, фиксировать планы и решения, закреплять ответственных за задачи письменно сразу после встреч – способ повысить качество общения и ничего не упустить.
2. Разные языки
Структурные подразделения компаний используют разную терминологию, потому что в них работают профессионалы разных областей. Разработчики используют один профессиональный язык: DevOps, DAG, pipeline, backlog, sprint и т.д. Финансисты используют другой: овердрафт, кредитная линия, отложенный платеж, PL, горизонтальный анализ и т.д.
Само по себе это не проблема, но при общении структурно далёких отделов появляется недопонимание. Финансисты не понимают, зачем нужен DAG, а айтишники не знают, чем овердрафт отличается от отложенного платежа. Строго говоря, разработка и бизнес не обязаны понимать друг друга. Но если нужно сделать проект общий, который требует коммуникации разных подразделений, то разбираться в чужом языке придется.
Что можно сделать?
Разработка универсального языка для компании. Чтобы компания создала такой язык, потребуется бизнес-глоссарий с базовыми терминами и определениями. Глоссарий будет работать, если:
изучение бизнес-глоссария входит в процесс адаптации сотрудника (онбординг, обучение, прием дел);
бизнес-процессы связаны с глоссарием (запросы, планы, расчеты);
документы формируются в соответствии с глоссарием (ТЗ, отчёты, проектная документация).
Если бизнес-глоссарий работает, то отделы общаются друг с другом на универсальном языке. При погружении в частные и внутренние процессы используется профессиональная терминология, но кросс-функциональные проекты реализовать становится проще.
Изучение чужого языка. Презентации, обучения или обмен опытом помогут разобраться в терминах смежных подразделений. Как вариант – регулярные встречи, где одно подразделение рассказывает остальным о задачах, планах и понятиях. Общение будет еще проще, если рассказчик наглядно показывает инструменты работы, демонстрирует результаты проектов и отвечает на вопросы коллег.
Конечно, после одной встречи разработчик не станет финансистом, а маркетолог не станет аналитиком 1С, но понимать язык других подразделений станет проще. Потому что термины из абстракций превращаются в конкретные явления, факты и инструменты, о которых коллеги доходчиво рассказывают друг другу.
3. Уверенность в собственной исключительности
В многих компаниях каждый отдел считает себя исключительным и необходимым для бесперебойной работы фирмы.
Каждое подразделение уверено:
Компания держится на нашем подразделении;
Без нашего отдела работа остановится;
Интересы нашей службы должны стоять на первом месте;
Только наше подразделение понимает, как работает компания.
Например, в крупной рекламной компании “Рога и копыта” такая ситуация:
Маркетологи считают, что без них не будет компании, ведь некому делать рекламу;
Закупщики уверены, что без их работы не будет рекламы, так как не будет ни техники, ни бумаги, ни рекламных материалов;
Продажники думают, что без них бизнес рухнет, потому что некому будет продавать рекламу;
Бухгалтерия знает, что без них работа встанет, ведь не будет денег на закупки и зарплаты, так как никто не отразит и не проведет платежи за рекламные кампании;
Айтишники верят, что без них компания не будет функционировать в принципе, так как сломаются пропускная и учётные системы, будут барахлить компьютеры, висеть сайты с рекламой, закупками и продажами.
Кажется, что ситуация нереальная, но на деле такое встречается в 4 из 5 компаний. Такая уверенность отделов в собственной исключительной роли в жизни фирмы приводит к проблемам в общении и конфликтам интересов. Какие могут быть совместные проекты и справедливое распределение ресурсов, если МОЙ ОТДЕЛ самый важный?!
Что можно сделать?
Осознать важность каждого. Стоит понять, что все подразделения важны и нужны компании, но только пока работают слажено и сообща. Если одни не будут производить товар, то нет смысла его продавать. Если одни не будут поддерживать 1C, то нет смысла пытаться делать проводки. Поэтому проекты – общие и ресурсы – общие. Если стремиться к совместным целям, проявлять заботу и уважение к смежным функциям, то эффективность компании будет расти.
Рассказывать о вкладе. Проводить встречи и рассказывать о вкладе каждого подразделения в результаты компании. Пока у бизнеса есть проблемы и цели, нужны разработчики, которые будут помогать в достижении целей. Пока у разработчиков есть продукты и инструменты, нужен бизнес, который будет использовать продукты.
Высокий уровень конкуренции между отделами – вопрос корпоративной культуры. Поэтому решить проблему с коммуникацией и разобщенностью быстро не выйдет, но двигаться в эту сторону нужно.
4. Невнимание к чужим бизнес-процессам
Есть мнение, что бизнесу не за чем знать, как устроен процесс разработки. Якобы представителей бизнеса интересуют только результаты, а как это будет сделано – никого, кроме самих айтишников, не волнует. Это может быть правдой, если сотрудничество бизнеса и разработки единоразовое, краткосрочное и носит характер заказа. Если взаимодействие регулярное, коммуникация постоянная, а совместные проекты сменяются один другим, то такое мнение ошибочно и опасно.
Например, в аэропорту необходимо разработать софт, который будет прогнозировать вероятность задержки рейса. Заказчик – операционный отдел, разработчик – ИТ отдел. Заказчик формирует ТЗ, участники согласовывают и айтишники приступают к разработке.
В середине проекта оказывается, что изменились программы с исходными данными, и появились новые факторы, влияющие на задержку рейса. Заказчик уверен, что это не сильно повлияет на процесс разработки, и не торопится об этом сообщить. Когда все вскрывается, сроки по проекту увеличиваются на 40%, потому что разработчикам придется переделывать бэкэнд: заново настраивать интеграции, тянуть данные в хранилище из новых источников и переделывать прогнозную модель.
В результате недовольны все: и заказчик, и разработчик. Сроки затянуты, бюджет увеличен. А все потому, что коллеги не постарались вникнуть в бизнес-процессы друг друга. Если бы заказчик знал, что изменения ТЗ могут привести к таким последствиям, он бы сказал об изменениях заранее. Если бы айтишники знали, что из-за гибкости авиации, как отрасли, источники данных заказчика быстро меняются, а факторы в модели корректируются, они бы учли это в плане проекта и сдвигов по срокам не было.
Что можно сделать?
Документировать бизнес-процессы. Например, создать базу знаний со схемами бизнес-процессов подразделений. Схемы должны включать этапы, участников и документы, нужные в рамках бизнес-процесса. Так можно узнать о работе смежного подразделения, не отвлекая никого от рабочих процессов, и оценить последствия изменений в проекте на разных этапах.
Проводить ротации. Сотрудники одних подразделений приходят в другие и изучают бизнес-процессы. В результате они выдвигают предложения по улучшению работы подразделений и кросс-функционального взаимодействия. Ротации не имеют смысла, если реализуются в токсичной и конкурентной среде. Это сложный корпоративный процесс, но он помогает повысить эффективность общения между отделами и уровень понимания чужих бизнес-процессов.
Заключение
Вопрос о том, что более затратно для компании: бороться с проблемами в общении между бизнесом и ИТ или исправлять последствия недопонимания между ними, остается открытым. Разработка и бизнес с трудом понимают друг друга по многим причинам, мы обозначили 4 из них:
Общие проблемы восприятия информации;
Разные языки общения;
Уверенность отделов в собственной исключительности;
Невнимание к чужим бизнес-процессам.
