А можно разработчик сам будет решать, какие задачи ему делать?

Я Android-разработчик и хотел бы сам решать, какие задачи мне делать, а какие нет. У вас бывало такое желание? Можно ли так делать на работе? Мой краткий и возможно интригующий ответ — можно. И ключ к этому — это погружение разработчика в бизнес.

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

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

Свой рассказ, я разделил на 3 составляющие:

1. Что вообще стоит считать погруженностью в бизнес?

2. Как понять, что ты, как разработчик, уже достаточно погрузился и постиг дзен?

3. Бонусы, которые мы получаем от этого (например, избавление от типичных проблем программистов).

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

1. Что такое погруженность разработки в бизнес?

Итак, давайте разбираться, что такое погруженность в бизнес. Или что я под этим понимаю, работая в Dodo Brands. Я начну с небольшого примера. Он будет немного издалека, но нам нужен этот контекст, чтобы понять суть. 

Задача: открыть Dodo Pizza в Германии

Я работаю в продукте International Master Franchising. Мы готовим мобильное приложение Dodo Pizza к запуску в новых странах, учитывая все локальные особенности. 

Сейчас Dodo Pizza работает в 12 странах. И каждый год мы планируем открывать по 4 или более новых стран. Раньше наше приложение не умело динамически поддерживать новые страны, нужно было на клиентах обязательно делать много мелких (и не всегда мелких) доработок, чтобы приложение нормально работало. В 2020 году мы запускали приложение в новой для нас стране — Германии.

Кажется, есть проблема

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

Изначально мы планировали открыть пиццерию в Мюнхене 10 сентября. Это была общая цель для нашей компании и для франчайзи. Мы сделали все доработки и запустили приложение. Но из-за различных операционных сложностей пиццерия открылась только 5 ноября, и то, только на доставку. А сам ресторан встретил первых гостей вообще в середине декабря.

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

Кажется, есть решение

Тогда нашей команде пришло в голову научить приложение «отключать» страну — показывать вместо меню лендинг. С помощью такого лендинга мы бы добились сразу 2-х вещей.

1. Мы не будем смущать пользователя как бы работающим приложением.

2. Мы сможем запускать различные маркетинговые активности, собирать контакты будущих клиентов и т.д.

Мы, как команда, вышли с предложением такой задачи и её решения, задача попала в бэклог, и теперь мы ее делаем. Если говорить простым языком — мы нашли проблему, сами предложили решение и взяли задачу в работу. Круто!

С виду ситуация простая, но давайте ее разберем:

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

• Команда знает, что приложение — фокусный канал продаж в Додо Пицце, а перед запуском новой страны у нас проводятся стартовые маркетинговые кампании в этом канале.  

• Бизнес осознает свои фокусы и тоже видит проблему. Команда разработки постоянно переключает фокус, тратит время на ручное управление оплатой в приложении, делает какие-то костыли, бубня себе что-то под нос. 

• Команда разработки сама решает, какую задачу делать. В результате того, что команда разработки была погружена в бизнес и понимала его потребности, и родилась такая задача с «отключением» страны — показом лендинга со сбором контактов.

Разработка и бизнес: работаем вместе

То был пример. Но что значит «быть погруженным в бизнес»? Что делать и куда бежать? Ответ в наших процессах. Мы в компании любим и придерживаемся Agile-ценностей и принципов разработки (Agile-манифест разработки программного обеспечения). Один из Agile принципов, описывающий близость разработки и бизнеса звучит так:

На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

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

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

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

• Бизнес и разработка вместе проводят квартальное планирование. Бизнес не приходит и не озвучивает нам цели. Мы вместе сидим и принимаем участие в планировании. Конечно, ведущие роли берут на себя бизнес-лидеры. Но любой разработчик может внести предложение, что-то дополнить или почеленджить предложение бизнес-девелоперов.

• Понимаем стратегию развития продуктов. В каждом продукте есть своя стратегия, максимально простая и понятная. Например, у нас в продукте IMF, ключевые результаты по стратегии завязаны на открытии новых пиццерий за рубежом и на выручку этих пиццерий (мобильное приложение, кстати говоря, главный канал онлайн-продаж, так что это очень понятная для нас цель).

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

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

В книге «Сильнейшие. Бизнес по правилам Netflix» (всем очень рекомендую эту книгу) директор по персоналу Netflix Патти МакКорд пишет очень классную вещь:

Людям нужно видеть ситуацию глазами первых лиц компании, чтобы чувствовать полную сопричастность к решению проблем, и это должно быть сделано на всех уровнях и во всех командах: компания должна видеть трудности и возможности в каждом уголке бизнеса и эффективно работать с ними. Ирония заключается в том, что компании много инвестировали в программы всевозможных тренингов, мотивирующие мероприятия и анализ результативности, но не смогли по-настоящему объяснить своим сотрудникам, как работает их бизнес.

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

Я рекомендую вам проделать мысленный эксперимент. Представьте себе, насколько хорошо вы знаете как работает бизнес в вашей компании? Можете ли вы видеть ситуацию глазами первых лиц? Кажется ли вам это важным?

2. Как понять, что ты, как разработчик, уже достаточно погрузился и постиг дзен?

После того, как мы разобрались, что такое погруженность (или как минимум то, что мы под этим понимаем), теперь можно порассуждать, а как её достичь. И как понять, что ты погрузился или нет.

Я выделю 3 составляющих, которые, на мой взгляд, наиболее ярко помогают понять, что должно быть, чтобы разработчик погрузился в бизнес. А именно:

• Партнерский (предпринимательский) подход к работе.

• Быть в среде, где доверие — это ценность.

• Как разработчик, никогда не забывать про Technical Excellence.

Партнерский (предпринимательский) подход к работе

Нам в пет-проекте всё понятно. Мы знаем проблему, которую хотим решить. Мы сами принимаем решения, какие технологии и подходы использовать. По сути мы являемся и владельцем, и руководителем, и разработчиком, и маркетологом, продавцом и т.д. У нас не возникает желания ждать задач сверху. Мы сами решаем, что делать и какие фичи нужны, какая инфраструктура подойдет или какой дизайн нужен. Скорее всего, мы не профессионалы во всем этом, но это наша ответственность, поэтому мы принимаем эти решение сами и делаем наш пет-проект. Если представить, что наш пет-проект «стрельнул» и стал развиваться и расти, то, скорее всего, появится команда, делегирование, роли и т.д.

А что же на работе? Почему на работе может казаться, что мы хотим делать одно, а нам говорят другое? «Работа» — это такой же пет-проект, только намного больше, и с командой. И мы часть этой команды. В отличие от пет-проекта, тут не мы всё сами делаем и решаем, а команда. Наши коллеги продакты знают все проблемы, которые должен наш продукт решать. Маркетологи знают, как позиционировать продукт. Ну и так далее. А если учесть, что наши коллеги не дураки и они знают что делают (а если ваши коллеги дураки, то зачем вы там работаете?), то нам надо немного погрузиться в то, чем они занимаются, и станет понятно, зачем мы делаем наши задачи. Погружаться можно совсем немного, но этого может быть вполне достаточно, чтобы всё стало так же как и с пет-проектом: мы будем полностью понимать, что и зачем мы делаем. Просто конкретно наша роль будет — разработка, так как именно в этом мы профессионалы.

Короче говоря, я хочу сказать, что разработчик может сделать свою основную работу такую же увлекательную, как и свой пет-проект или хобби. Она может также драйвить и приносить удовольствие от создания чего-то своего.

Быть в среде, где доверие — это ценность

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

Одна из ключевых ценностей у нас в Dodo Brands — это доверие. Эта ценность не просто написана где-то на бумажке или в файлике на корпоративном портале. Носителями этой ценности являются люди. И доверие в работе неизбежно рождает ответственность, что в свою очередь неизбежно способствует предпринимательскому подходу. 

Доверие в Dodo Brands идет на всех уровнях. Например, в пиццериях мы доверяем нашим клиентам. Мы не проверяем документы, если человек говорит, что у него день рождения. В разработке мы тоже доверяем друг другу. Например, бизнес доверяет техническим оценкам и решениям разработчиков. А разработчики доверяют PO и стейкхолдерам в их вижене и бизнес приоритетам.

Как разработчик, никогда не забывать про Technical Excellence

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

Чуть-чуть теории. Для начала обратимся опять к тому же Agile-манифесту, который говорит:

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Или очень краткое и емкое описание из документации по LeSS:

Organizational Agility is constrained by Technical Agility.

Что можно перевести, как: организационная гибкость ограничена технической гибкостью.

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

Задача: открыть Dodo Pizza в UK

Приведу другой пример из нашей команды. В конце 2020 года мы запускали новую пиццерию в Великобритании в небольшом городе Royal Leamington Spa. Особенность этого запуска была в том, что здесь был совершенно другой продукт, чем во всех остальных странах. Здесь была премиальная пицца (ресторанного качества) на римском тесте, с совершенно другим позиционированием, другим временем приготовления — одним словом был сильно другой пользовательский опыт.

Кажется, есть проблема

Со стороны может показаться, что здесь не может быть ничего особенного, но по факту разница большая: много операционных и бизнес процессов изменились. Это отразилось на нашей ИТ-системе и мобильном приложении. В приложении, в частности, надо было перейти на другие размерные схемы и типы теста. Изначально архитектурно на это не закладывались (и в целом это нормально), поэтому, чтобы начать отображать другие размеры и тесто пицц, надо было сделать большой рефакторинг, который затрагивал все слои и почти все экраны приложения. Работа была на месяц плюс раскатка. Но дело шло к концу декабря, а выпускать приложение после 15 декабря было уже нельзя — был предновогодний код фриз.

Кажется, есть решение

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

Обычно бизнес просит (иногда очень настойчиво) накостылить и сделать по-быстрому. И потом никогда не дает времени на переделку и нормальное решение. А здесь мы сами предложили быстрый и неидеальный вариант. И сделали так, что новая пиццерия смогла запуститься в срок — к 5 декабря. Но потом взяли месяц, чтобы всё поправить как надо. Win-win.

Потом была большая декомпозиция и большой рефакторинг. Сама работа заняла около месяца. И потом еще постепенная раскатка под фича-тогглом.

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

Это не противоречит той «битве за архитектуру», о которой пишет всем известный Роберт Мартин в своей книге «Чистая архитектура»:

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

То, что я описал выше, как раз и является разновидностью той борьбы. 

Этот пример показывает, как погруженность в бизнес помогает работать всему механизму в целом.

Последний принцип Agile, который я хочу здесь привести, и который тесно связан с тем, что мы только что обсудили:

Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

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

3. Рубрика «Программисты жалуются». Избавление от типичных проблем

Часто в продуктовых командах можно услышать такие жалобы разработчиков:

• Не хочу делать быстрые костыли, хочу делать нормально.

• Скучно (нет мотивации) делать рутинные, нудные задачи.

• Я не понимаю, зачем я делаю это (зачем я перекрашиваю эту кнопочку в 10-й раз).

• Не отвлекайте меня. Пусть бизнес занимается бизнесом, а я буду писать код.

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

Я не хочу делать быстро костыли, я хочу делать нормально.

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

Решение: предпринимательский подход и принцип Technical Excellence.

Нет мотивации делать рутинные, скучные задачи.

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

Решение: автоматизация всего, что можно автоматизировать, рост сотрудников.

Я не понимаю, зачем я делаю это (зачем я перекрашиваю эту кнопочку в 10й раз).

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

И да, и нет. Здесь всё зависит от компании, её культуры и ценностей. Если вас нанимали писать код 8 часов, то всё так, и вас не будут отвлекать. Но все меняется если компания относится к разработчику по-партнерски. Не с позиции «Я плачу за 8 часов, ты давай пиши код». А с позиции «Давай вместе сделаем крутой продукт. Ты умеешь классно программировать, значит будешь ответственный за эту часть, а мы за другую. И в итоге мы сделаем классный продукт». 

Погруженность в бизнес должна работать в две стороны. В этом и заключается дух партнерства. Я, как разработчик, хочу погружаться в бизнес, но и бизнес должен погружаться в техническую суть проекта. Кстати, на эту тему недавно вышла статья CEO Dodo Engineering Саши Андронова «Компания становится технологичной тогда, когда любой ее менеджер умеет разговаривать на языке технологий».

Решение: разработчик относится к бизнесу, а бизнес к разработчику по-партнерски.

Выводы

На вопрос, можно ли я, как разработчик, сам буду придумывать себе задачи, я отвечаю, да можно. Если я погружен в бизнес и понимаю систему изнутри, то я могу придумывать и предлагать задачи, которые мы будем потом делать.

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

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

И если мы не будем забывать о Technical Excellence, то мы способны быстро драйвить бизнес, делая MVP-решения, и не забывая при этом о техническом качестве наших систем.

Я все это писал с точки зрения разработчика и для разработчиков. При этом никто не держал дуло пистолета у меня над висками. Принципы и ценности, которые я описал в этой статье, не обязаны подходить всем и каждому. Как и шаблоны проектирования, которые не следует бездумно пихать в каждый кусок кода. Но они отлично работают у нас в Dodo Brands, помогают работать эффективнее как на короткой, так и на длинной дистанции.

Кстати, мы ищем людей! Например, в мою команду по международному развитию. Мы ищем не только мобильных разработчиков, но и других профессионалов в разные продукты. Так что заходи на Dodo Engineering в раздел jobs и ты найдешь, кого мы сейчас ищем.

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