Бизнес и разработка — как понять друг друга и подружиться?

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

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

Как же предпринимателям без технических знаний понять программистов и подружиться с разработкой? Я уверен, что залог успеха — партнерские отношения между бизнесом и инженерами. У инженеров есть видение, мнение и экспертиза. А у бизнеса есть свои цели. В то же время, инженерия — это всегда расходная статья бюджета, а не доходная. Либо компания, потратив деньги на разработку, получит профит, либо разработка, с точки зрения бизнеса, просто сжигает бюджет. Технический склад ума разработчиков зачастую концентрируется на красивом коде, использовании best practice,  настройке, рефакторинге. На это команде разработки требуется дополнительное время. А бизнес знает, что если в определенный момент времени потребность клиента не удовлетворена, позже она просто теряет смысл. Давайте разберемся, почему возникают проблемы в общении и как можно их устранить. 

Откуда проблемы в коммуникациях?

Говорим на разных языках

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

Простой пример. Продуктовая IT-компания нанимает нового CTO (технического директора). Задача от CCO (коммерческого директора) — развитие клиентского портфеля. А новый СТО уходит в рефакторинг кода, развертку новой инфраструктуры и в исправление багов — то есть начинает править то, что уже итак работает. В итоге через год СТО отчитывается, что баги исправлены и ПО «чувствует» себя стабильно, а CCO видит, что компания за это время потеряла больше 50% клиентов. Причина — клиенты ушли к конкурентам, которые внедряли новые актуальные функции в своих продуктах.

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

1. Сократить количество ошибок в переносе данных, связанных с человеческим фактором, до нуля. Бизнес-эффект — сокращаем бюджет на вторую и третью линии поддержки на 15% и повышаем NPS на 5 пунктов.

2. Исключить внутренний бумажный документооборот. Бизнес-эффект — уменьшаем время на согласование и подписание документов на 20% и оптимизируем затраты на канцелярию на 17%.

3. Снизить время реакции на инциденты до 15 минут. Бизнес-эффект — увеличиваем аптайм производства на 10 процентных пунктов.

Техдир, получив понятные бизнес-цели, проводит работу с командой разработки — формирует свое видение вариантов достижения целей или вклада в них с помощью it-решений и обязательно определяет тот, который он и команда считают приоритетным. В рамках этого процесса техдир обязательно готовит предварительную оценку реализации в деньгах и времени, а также оценку возможных допущений и ограничений. У каждой цели обязательно должно быть экономическое обоснование. Например, если сделаем пункт 2 и 3 — сэкономим 2 млн рублей в год. 

Ясность бизнес-целей и метрик их достижения — главное правило дружбы бизнеса и разработки

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

Верим в миф, что разработка — суперсложный процесс 

Сколько раз вы слышали от своего технического директора слова «рефакторинг, архитектура, интеграции, деливери, бэклог, эпики, ретроспектива, devops» и тд? А сколько из этих слов вы поняли? Скорее всего, удалось уловить смысл в целом. Но это не точно. Неизвестность пугает — бизнес считает разработку чем-то из другого мира. 

Как это исправить? Попросите разработчиков — лидеров команд и СТО рассказывать о процессах не как о технологии, а как о сути того, что они делают. 

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

Нет ясной цели и критериев ее достижения

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

Я оборудовал личный рабочий кабинет на балконе. Когда делал там ремонт, попросил бригаду положить теплый пол. Ширина балкона — 120 см от стены до стены. Я не особо контролировал стройку, потому что не сильно в ней разбираюсь. Пришло время Х, я «заселяюсь» на балкон и понимаю — теплый пол теплый не везде, а только под моими ногами, за рабочим столом. Я звоню прорабу, задаю вопрос. Прораб подключает рабочего, который занимался выкладкой пола. А рабочий мне и говорит: «у вас теплый мат под полом только 50 см — там, где вы сидите. Зачем вам по бокам теплый пол?». С логикой рабочего спорить трудно. Действительно, трудно представить, что когда я весь сижу за столом, мои ноги могут находиться в другом месте.  Конечно, в итоге, рабочим пришлось ломать пол и все переделывать. Но представьте, через сколько людей прошло решение «делаем теплую вкладку только на 50 см»: прораб подтвердил, закупка купила материалы, рабочий руками стелил теплый мат 50 см на пол в 120 см. В итоге получилось дольше, дороже и не то, что нужно. 

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

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

Как гендиру понять, что в разработке что-то пошло не так?

Люди редко просыпаются с мыслью «а пойду-ка я сегодня кого-нибудь обману». Чаще бывает, что нет времени/возможности сказать о каких-то нюансах, или разговор о них повлечет за собой столько сложностей для человека, что он лучше промолчит. Даже в работе суперкоманд бывают ситуации, когда кто-то с чем-то не справляется, срывает сроки и проект длится гораздо дольше, чем было спланировано. Большинство таких ситуаций можно не допустить, обнаружив их на ранней стадии. Расскажу про моменты, которые однозначно говорят, что что-то идет не так.

1. Очень тревожный звонок — длинные сложные объяснения на языке программистов. 

Еще один пример. Система существует несколько лет. Значительная его часть — интеграция с внешними сервисами и базами данных, из которых она собирает данные и агрегирует в удобный для обработки сводный вид. Запускала сервис команда №1, которая потом ушла — в момент очень активного развития системы. Пришла команда №2. Начала делать новую версию протокола интеграции API, при этом поддерживая (не меняя) старую версию. Работы стало очень много и было принято решение привлечь команду №3 на аутсорсе — им ничего не объяснили, но выдали задание на интеграцию с еще несколькими источниками данных дополнительно. Они создали еще одну версию API, которую успешно сдали заказчику. 

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

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

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

Как решить. Просите специалистов объяснить все простым языком. С помощью понятных слов и при необходимости сравнений.

2. Увеличение времени на исправление багов. 

Условно, команда выкатывает обновления раз в неделю. После чего проверяет систему на ошибки. 15-20% от всего производственного времени — приемлемый объём, который команда может потратить на исправление заранее описанных и найденных багов. Если показатель больше 20% — общий срок и бюджет проекта неизбежно вырастет.   

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

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

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

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

4. Команда разработки работает 24/7, обстановка в команде нервная, сотрудники на грани выгорания

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

Как синхронизироваться с it-командой?

Ответ простой — поговорите с людьми. Задайте вопросы:

1. Знают ли они, для чего ведут разработку? 

Если ответ отрицательный, тогда вопрос к вам — вы объяснили ребятам, зачем мы здесь сегодня собрались? Что за деятельность ведете, зачем команда автоматизирует процессы?

2. Как вы понимаете, что хорошо поработали? 

Кажется, что это довольно скользкий вопрос. Однажды меня спросил заказчик — Семен, приложение-то хорошее получилось? Я перенервничал, честно. Внутри усомнился — а правда, хорошее приложение? А все там сделано как надо? Наш менеджер проекта не растерялась, ответила — конечно, хорошее. А заказчик говорит — и что, прям в AppStore не стыдно будет выложить? Конечно, не стыдно. 

Оказалось, заказчик нас просто проверял - насколько мы сами уверены в своем продукте. Вопрос, знает ли команда параметры измерения качества своей работы — очень важный. 

3. Что будет, если вовремя не закроете проект?

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

Как это работает в itMegastar

1. Каждый наш сотрудник знает миссию компании — это первое, о чем узнают новички. Мы много лет назад сформировали ее и держим красной нитью во всех проектах.

2. Дважды в год я провожу большую презентацию, где рассказываю про наши результаты и планы. Благодаря этому все сотрудники в курсе, какие цели достигла компания, как она это сделала и куда идет дальше. Ребята понимают, для чего работают. 

3. Информация о компании открыта каждому. Если у сотрудника есть желание — он может найти все, что его интересует о компании и проектах. Коммуникации у нас тоже открытые. С клиентом мы никогда не встаем в позицию исполнителя. Основная ценность компании — лидерство. Это значит, что мы должны вести клиента в рамках цифровизации, а не ждать, что нам скажут, что делать. 

4. Каждый в нашей команде знает нашу суперсилу — проектирование, поиск инженерного решения, определение дорожной карты по реализации. А если знаешь свою суперсилу — используешь ее на все 100%.

Не бойтесь разговаривать с разработчиками. Создание действительно крутого it-продукта — двустороннее движение. Рассказывайте подробнее о своих целях, спрашивайте о непонятном, будьте открыты сами — и результаты совместной работы не заставят себя ждать. Мы в команде itMegastar делаем именно так — и это работает. Ведь, как я сказал в самом начале, бизнес и разработка вместе ради одной цели — сделать классный, удобный, востребованный продукт для конечного потребителя, монетизация которого позволит вашей команде его развивать и поддерживать.