Бизнес и разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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