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

Из-за двух кардинально разных подходов компанию разрывают противоречия. Самый простой путь — изолироваться друг от друга и минимально пересекаться до момента релиза. Команда VK Cloud перевела статью о том, как сделать иначе: преодолеть разрозненность, создать сплоченные команды и сократить сроки выпуска продукта.

Как угодить в эту западню

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

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

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

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

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

Трудности масштабирования: симптомы

Перевод стрелок между отделами

Сотрудники ассоциируют себя в первую очередь со структурой управления или начальником отдела, а не с потоком создания пользы для бизнеса или клиента. Так команды погружаются в противостояние «мы и они».

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

У разработчиков часто стопорится работа из-за нехватки контекста

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

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

Упущенные зависимости

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

Рабочие задачи ускользают из рук

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

Отказ от переговоров о техническом долге

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

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

Команды, которые взаимодействуют, но не сотрудничают

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

Как выбраться из этой западни

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

Выявите и усильте основной состав

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

Подход «основной состав» придумал Патрик Ленсиони. Эта концепция упоминается во многих его работах, в том числе в The Advantage и The Five Dysfunctions Of A Team: A Leadership Fable. В теории кросс-функциональных команд концепция обычно используется скорее в значении «команда, перед которой я несу ответственность в первую очередь», однако она отлично подходит и для продуктовых команд.

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

Измените язык

«Чем выше готовность компании преодолеть изолированность команд, тем выше вероятность, что она будет эффективно ломать некоторые неявные противоречия, способствующие этой разрозненности».
Duena Blomstrom

Смена тональности и выражений среди сотрудников компании — простой первый шаг к разрушению барьеров и уменьшению трений.

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

Измените поведение

«Если мы стремимся изменить корпоративную культуру, нужно определиться, что мы собираемся делать, как нам себя вести и какого поведения мы ожидаем от других. Затем провести обучение и потом делать все необходимое, чтобы закрепить изменения. В результате культура изменится сама собой». 
John Shook

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

1. Руководители должны установить принципы и ожидания относительно культуры, в которой не ищут виноватых. Когда дела идут не так, как надо, это отличная возможность чему-то научиться, и ее нужно использовать для непрерывного совершенствования. Примером может служить концепция «работы над ошибками без поиска виновных».
   
2. Сформулируйте ожидания и регулярно проверяйте, укоренилось ли желаемое поведение. Требуйте, чтобы сотрудники вели себя как положено, и не делайте исключений.
   
3. Направляйте «командные конструкты» не вокруг функций, а вокруг потоков создания ценности. «Команды» — это группы, которые создают общую ценность. Отличайте их от сообществ практикующих специалистов или центров развития конкретных компетенций, таких как управление проектом или контроль качества.
   
4. Признайте, что есть некоторые типы личности, которые сочетаются друг с другом хуже, чем другие. Перетасовывайте талантливых сотрудников в поисках оптимально слаженной команды.
   

Определите и озвучьте, как ваш скейлап создает ценность

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

Активы, которые описывают ценность для клиента и пользователя

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

• концепция модели бизнеса, концепция Lean Canvas,
  
• путь потребителя,
  
• визуализация взаимосвязей между различными компонентами сервиса,
  
• типажи пользователей,
  
• карты эмпатии,
  
• раскадровки,
  
• схема приложения рабочей силы,
  
• обзоры продуктов.
  

Активы, описывающие экономическую модель

Описывают ценность, которую ваша компания получает от клиентов, стоимость создания этой ценности и методы ее измерения. Например:

• циклы развития бизнеса,
  
• карты потоков создания ценности,
  
• карты Уордли,
  
• модели удержания, предотвращения оттока клиентов,
  
• модели приобретения клиентов,
  
• модели оценки ценности клиента за его жизненный цикл,
  
• прогнозы по бухгалтерскому балансу и отчету о прибылях и убытках.
  

Активы, описывающие стратегию

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

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

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

Один простой эксперимент поможет выяснить, насколько вам это удалось. Остановите проходящего мимо сотрудника и расспросите его, о чем говорят активы. Чем лучше он справится, не подглядывая, тем лучше он сможет опираться на этот подход в своей работе. Если он вообще не имеет представления, о чем речь, вам предстоит еще много работы.

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

Формируйте многопрофильные команды вокруг потоков создания ценности

У новых компаний часто только один поток создания ценности. По мере роста приходится разбивать его на несколько потоков, чтобы отдельные команды полностью взяли на себя ответственность за разные продукты или их компоненты. Мы не будем обсуждать оптимальные способы такого разделения, хотя сами отдаем предпочтение топологиям команд. Но рассмотрим ключевые вопросы, которые помогут провести разделение:

• Может ли новый поток вместе со всеми продуктами и услугами существовать как отдельная компания, пусть даже не слишком успешная?
  
• Можно ли сопоставить потоки с конкретным способом создания ценности? Или конкретным клиентом или пользователем?
  
• Как разные потоки создания ценности взаимодействуют друг с другом?
  

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

Соберите сотрудников в команду, ориентированную на результат, а не на процесс. Откажитесь от функциональных команд. Как пишет Шрирам Нарайям в Agile IT Organization Design: 

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

Такая модель помогает ускорить работу внутри команды, ориентированной на результат. И дополнительно уменьшает трения среди сотрудников междисциплинарной команды.

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

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

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

Сформируйте соглашение о работе команд на всех уровнях

Убедитесь, что каждый сотрудник знает, какую роль играет в команде

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

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

Рабочие соглашения команды могут содержать:

1. Название — уникальный идентификатор команды.
   
2. Миссию — для чего существует эта конкретная команда? Какую ценность она должна создавать?
   
3. Метрики — как команда измеряет свой успех? Учитывайте метрики не только активности, но и создания ценности.
   
4. Обязанности — какую работу нужно проделать, чтобы достичь успеха? Какие сотрудники соглашаются взять на себя ответственность за эти пункты работы? Можно предварительно распределить типичные виды работ среди сотрудников и давать рекомендации на этот счет, но сотрудники вправе самостоятельно перераспределить их в команде.
   
5. Навыки — какие навыки нужны именно этой команде, чтобы добиться успеха?
   
6. Правила — руководства, принципы, разумные стандарты, с которыми сотрудники сверяют собственное поведение, взаимодействие с другими и принятие решений.
   

Руководители из собственных команд

Рабочие соглашения — отличный инструмент не только для кросс-функциональных команд, но и для корректировки работы на уровне кросс-функциональных руководителей.

«Безусловно, руководитель каждого направления — продуктового отдела, дизайна и технического отдела — ценный кадр и сам по себе. Но только вместе они являют миру свою истинную мощь».
Marty Cagan

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

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

«Сотрудники должны ставить результаты команды выше собственных потребностей или потребностей подразделения».
Patrick M. Lencioni

Добейтесь сбалансированного распределения инвестиций в продукт

Сбалансированное распределение инвестиций — золотая середина

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

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

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

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

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

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

Учет кросс-функциональных требований

Хорошему продукту мало постоянного притока новых функций. Он должен:

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

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

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

Равновесие в списке задач

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

Продуктивность переговоров зависит от прозрачности, способности обмениваться подробной информацией и желания посмотреть на вещи с точки зрения другого человека. Если продакт-менеджер разбирается в технической архитектуре и стратегии, он может предложить идеи, которые проще воплотить. Если технический специалист разбирается в аргументах и исследованиях, лежащих в основе стратегии развития продукта, он может предложить альтернативные идеи. Например, использовать ML/AI для решения проблемы.

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

1. Акцент на метриках DevOps и DX, ориентированных на результат. Для начала можно прочитать о том, как максимально увеличить эффективность работы разработчика.
   
2. У нас в Thoughtworks Scaleup Studio есть ряд разумных норм. Мы взяли их из исследования, изучавшего практики и технологии успешных скейлапов. Это непрерывное развертывание, предметноориентированные микросервисы, разумное использование технического долга, формирование экспериментальных процессов и инфраструктуры.
   
3. Непререкаемый уровень качества. Например, в каждом языке есть современные методы, по которым нетрудно автоматически сверять свою работу.
   

Сотрудничество продактов и разработчиков по мере роста компании: пошаговая схема

Этап 1. Эксперименты

1. Стартап — это одна команда.
   
2. Предварительные рабочие соглашения и активы для описания целей и задач.
   
3. Распределение инвестиций сильно перекошено в сторону продуктовых инвестиций. Часто работы ведутся, чтобы расширить знания, а не улучшить рабочий продукт. Например, создаются одноразовые прототипы.
   
4. Эксперименты с разными экономическими моделями.
   

Этап 2. Продвижение

1. Компания начинает распадаться на подкоманды, но все еще воспринимает себя как «одну большую команду».
   
2. Рабочие соглашения становятся более конкретными.
   
3. Активы для создания ценности для клиента детализируются и используются при онбординге и профориентации. Экономическая модель становится яснее, но все еще остается гибкой.
   
4. Компания впервые нанимает продуктового и технического руководителей не из числа основателей.
   
5. Распределение инвестиций все еще перекошено в сторону продукта и ориентировано на создание долгоиграющего решения.
   
6. Ключевые фундаментальные инвестиции делаются для поддержания масштабов бизнеса.
   

Этап 3. (Гипер)рост

1. Компания уже слишком велика, чтобы работать как «единая команда». Она распадается на потоковые команды.
   
2. Создаются кросс-функциональные команды руководителей среднего звена. Формируются первые технические команды для развития платформы.
   
3. Компания больше не ищет новые рынки. Распределение инвестиций удваивает ценность, создаваемую продуктом.
   
4. Активы ценности для клиента, бизнес-стратегии и экономической модели теперь достаточно конкретны. Они меняются медленно и используются для распространения и тиражирования.
   
5. По необходимости для каждого продукта и подпродукта создаются собственные заявления о ценностях и активы.
   

Этап 4. Оптимизация

1. Руководители должны активно противостоять угрозе разрозненности по функциональному признаку.
   
2. Структура команды начинает меняться под требования максимальной автономии и посредничества.
   
3. Появляются структуры по поддержке развития навыков и единообразия в функциональных группах.
   
4. Создается множество команд для повышения эффективности работы групп, объединенных вокруг потоков: проектирование платформы, Product Opc, Design Ops и т. д.
   
5. В распределении инвестиций в базовые продукты появляется сдвиг в сторону технических инвестиций, в том числе в удобство разработчиков.
   

Коротко о главном

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

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

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

1. Укрепляйте «основной состав». Функциональные отделы хорошо подходят для развития квалифицированных сотрудников. Но независимо от роли все, кто создает одну и ту же ценность для бизнеса или клиента, работают в одной команде.
   
2. Определите и озвучьте свое ценностное предложение. Убедитесь, что каждый сотрудник продуктовой команды знает, как он создает ценность для бизнеса и для клиентов. Это единственный способ сформировать внутренне мотивированные команды.
   
3. Создавайте многопрофильные команды вокруг рабочих потоков. Формируйте комплексные продуктовые команды, в которых есть все навыки и компетенции, необходимые для создания измеримой ценности. Обеспечьте их всеми необходимыми ресурсами.
   
4. Сформируйте соглашения о работе команд на всех уровнях. Создайте рамочную управленческую основу. Разрешите продуктовым командам и функциональным руководителям использовать ее для проведения внутренних переговоров и перераспределения ролей и обязанностей. Постоянно проводите переоценки и корректировки, пока не будет достигнуто искомое статическое равновесие.
   
5. Добейтесь сбалансированного распределения инвестиций. Именно успешная продуктовая команда делает стабильный, безопасный и масштабируемый продукт с разнообразными функциями.