Любопытно, почему до сих пор никто не говорит о том, как создать фундамент для уверенности в своей it-команде. Понимание процессов разработки для гендира — это его безопасность и спокойствие. Да, не каждый собственник бизнеса имеет технический бэкграунд. Но каждый, так или иначе, сталкивается с разработкой, цифровизацией или трансформацией бизнеса. При этом бизнес измеряет результаты деньгами. Разработка — количеством успешных релизов, устраненных багов и итоговой бесперебойной работой продукта. Но и те и другие фактически делают одно большое дело — создают качественный продукт, полезный для конечного клиента и создающий выручку.
Как же предпринимателям без технических знаний понять программистов и подружиться с разработкой? Я уверен, что залог успеха — партнерские отношения между бизнесом и инженерами. У инженеров есть видение, мнение и экспертиза. А у бизнеса есть свои цели. В то же время, инженерия — это всегда расходная статья бюджета, а не доходная. Либо компания, потратив деньги на разработку, получит профит, либо разработка, с точки зрения бизнеса, просто сжигает бюджет. Технический склад ума разработчиков зачастую концентрируется на красивом коде, использовании best practice, настройке, рефакторинге. На это команде разработки требуется дополнительное время. А бизнес знает, что если в определенный момент времени потребность клиента не удовлетворена, позже она просто теряет смысл. Давайте разберемся, почему возникают проблемы в общении и как можно их устранить.
![](https://static.tildacdn.com/tild6361-3930-4134-b234-663234656332/13_-___.png)
Откуда проблемы в коммуникациях? Говорим на разных языках
Инженеры меряются качеством технического решения, бизнес — выручкой и маржинальностью.
Простой пример. Продуктовая IT-компания нанимает нового CTO (технического директора). Задача от CCO (коммерческого директора) — развитие клиентского портфеля. А новый СТО уходит в рефакторинг кода, развертку новой инфраструктуры и в исправление багов — то есть начинает править то, что уже итак работает. В итоге через год СТО отчитывается, что баги исправлены и ПО «чувствует» себя стабильно, а CCO видит, что компания за это время потеряла больше 50% клиентов. Причина — клиенты ушли к конкурентам, которые внедряли новые актуальные функции в своих продуктах.
Как это исправить? Чтобы разговор пошел в правильном русле, постарайтесь найти общий язык. Начните с общего брифинга — коммерческий и технический директор должны согласовать список бизнес-целей. Например, хотим:
- Сократить количество ошибок в переносе данных, связанных с человеческим фактором, до нуля. Бизнес-эффект — сокращаем бюджет на вторую и третью линии поддержки на 15% и повышаем NPS на 5 пунктов.
- Исключить внутренний бумажный документооборот. Бизнес-эффект — уменьшаем время на согласование и подписание документов на 20% и оптимизируем затраты на канцелярию на 17%.
- Снизить время реакции на инциденты до 15 минут. Бизнес-эффект — увеличиваем аптайм производства на 10 процентных пунктов.
Техдир, получив понятные бизнес-цели, проводит работу с командой разработки — формирует свое видение вариантов достижения целей или вклада в них с помощью it-решений и обязательно определяет тот, который он и команда считают приоритетным. В рамках этого процесса техдир обязательно готовит предварительную оценку реализации в деньгах и времени, а также оценку возможных допущений и ограничений. У каждой цели обязательно должно быть экономическое обоснование. Например, если сделаем пункт 2 и 3 — сэкономим 2 млн рублей в год.
Ясность бизнес-целей и метрик их достижения — главное правило дружбы бизнеса и разработки .
Открыто доносите информацию, выкладывайте на корпоративный портал успехи в цифрах и обязательно привязывайте их к известным команде бизнес-целям — достигли того-то (бизнес-задача) благодаря тому-то (действия разработчиков).
![](https://static.tildacdn.com/tild6266-6437-4962-b431-323033646436/14_-___.png)
Верим в миф, что разработка — суперсложный процесс
Сколько раз вы слышали от своего технического директора слова «рефакторинг, архитектура, интеграции, деливери, бэклог, эпики, ретроспектива, devops» и тд? А сколько из этих слов вы поняли? Скорее всего, удалось уловить смысл в целом. Но это не точно. Неизвестность пугает — бизнес считает разработку чем-то из другого мира.
Как это исправить? Попросите разработчиков — лидеров команд и СТО рассказывать о процессах не как о технологии, а как о сути того, что они делают.
Например, зачем тратить кучу денег на разработку автотестов? Для бизнеса это не всегда понятные затраты, так как не ведут к новому функционалу или не ясна прямая связь с выручкой или другими бизнес-параметрами. Если зададите вопрос CTO, он расскажет, что автотесты не позволяют багам пробраться в продакшен. Они отрабатывают при сборке новой версии функционала или обновлении части системы, чтобы выяснить, не сломалось ли что-то в другой ее части, пока делали что-то новое. Автотесты позволяют разработчикам не отвлекаться от текущих задач на срочное исправление косяков. В свою очередь это позволяет не увеличивать бюджет на решение текущей задачи и на устранение бага, так как оплата работы программиста зависит от количества потраченных часов.
Нет ясной цели и критериев ее достижения
Приведу реальный пример из бытовой жизни. В нем я повел себя, как плохой бизнес-заказчик, а мои подрядчики — так себе инженеры.
Я оборудовал личный рабочий кабинет на балконе. Когда делал там ремонт, попросил бригаду положить теплый пол. Ширина балкона — 120 см от стены до стены. Я не особо контролировал стройку, потому что не сильно в ней разбираюсь. Пришло время Х, я «заселяюсь» на балкон и понимаю — теплый пол теплый не везде, а только под моими ногами, за рабочим столом. Я звоню прорабу, задаю вопрос. Прораб подключает рабочего, который занимался выкладкой пола. А рабочий мне и говорит: «у вас теплый мат под полом только 50 см — там, где вы сидите. Зачем вам по бокам теплый пол?». С логикой рабочего спорить трудно. Действительно, трудно представить, что когда я весь сижу за столом, мои ноги могут находиться в другом месте. Конечно, в итоге, рабочим пришлось ломать пол и все переделывать. Но представьте, через сколько людей прошло решение «делаем теплую вкладку только на 50 см»: прораб подтвердил, закупка купила материалы, рабочий руками стелил теплый мат 50 см на пол в 120 см. В итоге получилось дольше, дороже и не то, что нужно.
Как это исправить? В моем примере мне, как заказчику, нужно было обозначить — нужен теплый пол с этой точки до этой точки. А ребятам экспертам предложить варианты решений — дешево и сердито, подороже и пофункциональней, еще чуть дороже и с дополнительными удобными опциями — выбирайте.
Четко обозначайте, чего именно ждете на выходе. Не бойтесь задавать вопросы. Хороший инженер — эксперт, которому будет приятно рассказать вам о возможностях, объяснить их резонность, показать свою экспертизу и выстроить доверительные отношения.
Как гендиру понять, что в разработке что-то пошло не так
Люди редко просыпаются с мыслью «а пойду-ка я сегодня кого-нибудь обману». Чаще бывает, что нет времени/возможности сказать о каких-то нюансах, или разговор о них повлечет за собой столько сложностей для человека, что он лучше промолчит. Даже в работе суперкоманд бывают ситуации, когда кто-то с чем-то не справляется, срывает сроки и проект длится гораздо дольше, чем было спланировано. Большинство таких ситуаций можно не допустить, обнаружив их на ранней стадии. Расскажу про моменты, которые однозначно говорят, что что-то идет не так.
- Очень тревожный звонок — длинные сложные объяснения на языке программистов.
Еще один пример. Система существует несколько лет. Значительная его часть — интеграция с внешними сервисами и базами данных, из которых она собирает данные и агрегирует в удобный для обработки сводный вид. Запускала сервис команда №1, которая потом ушла — в момент очень активного развития системы. Пришла команда №2. Начала делать новую версию протокола интеграции API, при этом поддерживая (не меняя) старую версию. Работы стало очень много и было принято решение привлечь команду №3 на аутсорсе — им ничего не объяснили, но выдали задание на интеграцию с еще несколькими источниками данных дополнительно. Они создали еще одну версию API, которую успешно сдали заказчику.
После этого команде пришлось потратить дополнительное время на совмещение всех существующих версий API, а внесение изменений в систему повлекло за собой необходимость актуализировать вместо одного API все три. Соразмерно и ошибок стало на порядок больше. Сроки сдачи из-за этого постоянно срывались, разработчики были недовольны перегрузкой, а бюджет команды вырос.
Технический директор получил от финансов резонный вопрос «Почему столько денег тратится на уже существующие интеграции». Ему пришлось объяснять, как разнообразны системы, с которыми интегрирован сервис, как сложно все это поддерживать — и все это непонятными терминами. А на самом деле проблема одна — технический директор вовремя не обратил внимание структуру проекта и распределение задач в целом, а бизнес не сообщил о своих планах подключать всё больше внешних источников данных и сервисов.
Я считаю, что вопросы про общее видение и функционал проекта должны задавать инженеры. Не потому, что хочу переложить на них ответственность. А потому, что я очень высокого мнения об инженерах — они профессионалы своего дела и только они могут сказать, как оптимально решить задачу бизнеса. Заказчик не может и не должен знать все параметры, которые повлияют на выполнение результата с точки зрения разработки.
Как решить. Просите специалистов объяснить все простым языком. С помощью понятных слов и при необходимости сравнений.
- Увеличение времени на исправление багов.
Условно, команда выкатывает обновления раз в неделю. После чего проверяет систему на ошибки. 15-20% от всего производственного времени — приемлемый объём, который команда может потратить на исправление заранее описанных и найденных багов. Если показатель больше 20% — общий срок и бюджет проекта неизбежно вырастет.
Как решить. Первое, что нужно сделать — остановиться и посмотреть на все баги и задачи в работе. Выписать их, постараться сгруппировать и главное — приоритизировать. Какие-то неисправности влияют на конечный итог для бизнеса, какие-то нет. Баги — это симптомы, часто у них может быть одна причина.
Следующий шаг — найти эту причину и устранить. Редко бывает так, чтобы количество багов было так велико и с такими разными причинами, чтобы можно было копаться в них 100% времени. Для того, чтобы так запустить систему — нужно очень постараться и делать это целенаправленно.
- Как результат второго пункта, если вовремя не обратили внимание и не решили — увеличение затрат на поддержку и багфиксинг. Как следствие — низкая скорость самой разработки.
Как решить. Поговорить с разработкой. Без заумных рассуждений, на простом человеческом языке.
Общий совет — не оставляйте систему без владельца. Нельзя надеяться, что программисты сами придумают бизнес-цели и пути их решения. Даже если продукт уже на поддержке — участвуйте в процессах, спрашивайте, интересуйтесь. И просите объяснить то, что не понятно.
- Команда разработки работает 24/7, обстановка в команде нервная, сотрудники на грани выгорания
Как решить. Тут точно нужно остановиться, помочь CTO установить адекватные приоритеты и понять — нужна ли на самом деле бизнесу такая высокая скорость разработки и что произойдет, если подождать с релизом новых функций.
![](https://static.tildacdn.com/tild6239-6565-4439-b230-393539336662/11_-___.png)
Как синхронизироваться с it-командой
Ответ простой — поговорите с людьми. Задайте вопросы:
- Знают ли они, для чего ведут разработку?
- Как вы понимаете, что хорошо поработали?
Оказалось, заказчик нас просто проверял - насколько мы сами уверены в своем продукте. Вопрос, знает ли команда параметры измерения качества своей работы — очень важный.
- Что будет, если вовремя не закроете проект?
Как это работает в itMegastar
1.Каждый наш сотрудник знает миссию компании — это первое, о чем узнают новички. Мы много лет назад сформировали ее и держим красной нитью во всех проектах.
![](https://static.tildacdn.com/tild3866-6634-4336-b261-613632306465/Screenshot_1.png)
2.Дважды в год я провожу большую презентацию, где рассказываю про наши результаты и планы. Благодаря этому все сотрудники в курсе, какие цели достигла компания, как она это сделала и куда идет дальше. Ребята понимают, для чего работают.
3.Информация о компании открыта каждому. Если у сотрудника есть желание — он может найти все, что его интересует о компании и проектах. Коммуникации у нас тоже открытые. С клиентом мы никогда не встаем в позицию исполнителя. Основная ценность компании — лидерство. Это значит, что мы должны вести клиента в рамках цифровизации, а не ждать, что нам скажут, что делать.
4.Каждый в нашей команде знает нашу суперсилу — проектирование, поиск инженерного решения, определение дорожной карты по реализации. А если знаешь свою суперсилу — используешь ее на все 100%.
Не бойтесь разговаривать с разработчиками. Создание действительно крутого it-продукта — двустороннее движение. Рассказывайте подробнее о своих целях, спрашивайте о непонятном, будьте открыты сами — и результаты совместной работы не заставят себя ждать. Мы в команде itMegastar делаем именно так — и это работает. Ведь, как я сказал в самом начале, бизнес и разработка вместе ради одной цели — сделать классный, удобный, востребованный продукт для конечного потребителя, монетизация которого позволит вашей команде его развивать и поддерживать.