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

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

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

Как появился фрейм бэклога

Интернет сильно изменил сферу разработки ПО. Понятное дело! Из-за расцвета интернет-компаний нам приходится постоянно следить за рынком и слушать клиентов. Больше не получается долго и обособленно разрабатывать ПО. Рынок меняется, конкуренты появляются не раз в десять лет, а каждый месяц. Причём многие из них довольно крупные и с хорошим финансированием. В целом все стремятся сосредоточиться на самих разработчиках и быстрых изменениях, с частыми промежуточными корректировками вместо длинных плановых циклов разработки.

В конце 1990-х возникла методология под названием «экстремальное программирование» (Extreme Programming, XP). Она познакомила многих разработчиков с принципами Agile и итеративной разработкой. В этой методологии была концепция «заказчик всегда рядом» (on-site customer): у разработчиков всегда должен быть доступ к заказчику, в идеале — чтобы тот находился поблизости и с ним можно было общаться лицом к лицу. При этом разработчики должны были выяснять у заказчика, что и как нужно разрабатывать. То есть разработчики стояли у руля, а заказчики могли быть уверены в том, что всё делается как нужно. Однако по разным причинам методология не прижилась. В основном потому, что из-за интернета у компаний появились миллионы заказчиков, а экстремальное программирование создавалось в условиях внутренней разработки ПО. Слишком сложно стало придерживаться концепции «заказчик всегда рядом». Возможно, другая причина была в том, что разработчики не могли «просто разрабатывать» код, на них возложили ответственность за успешность продукта. Ожидалось, что они будут управлять разработкой и общаться с заказчиками.

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

Самым важным изменением благодаря Scrum стала роль владельца продукта (product owner). Команда больше не владела продуктом. Теперь владелец решал, над чем должны работать разработчики. Они больше не стояли у руля. Не они спрашивали заказчика, каким должен быть продукт, а владелец продукта диктовал разработчикам, какие фичи нужны заказчику. Вероятно, многие были рады этой перемене, в том числе и потому, что зарплаты стали расти как на дрожжах.

Также на сцене появились новые протагонисты — продуктологи (продакт-менеджеры, product manager). Их начали использовать успешные компании, за которыми потянулись и остальные. Становление Agile и продуктологов происходило одновременно. Компании стали переходить от иерархического управления к самоорганизующимся командам. С ними нужно было взаимодействовать и передавать им задачи. Раньше продукты обсуждали на совещаниях с техническими директорами (CTO). Затем результаты обсуждения спускали нижестоящим руководителям, превращали в проекты и передавали разработчикам. Однако с приходом Agile и самоорганизующихся команд эта схема перестала работать. 

По теме:
— Почему провалить Agile так легко;
— Опыт внедрения Agile в компании Ticketland;
— Практический онлайн-курс «Профессия Product manager».

Кроме того, когда в разработке продукта начали участвовать аналитики, понадобилось оптимизировать KPI. Но разработчики не хотели этим заниматься, их не интересовала бизнес-сфера. С кем же представители бизнеса могли обсудить разработку фич? Общаться с разработчиками напрямую было трудно, и роль посредников заняли продуктологи. К счастью, благодаря Scrum у нас появилась и организационная структура, в которую продуктологи легко встроились. Точнее, владельцы продукта! С тех пор роль владельца продукта в Scrum почти всегда описывается как работа продуктолога. Сегодня обе роли часто путают и используют как синонимы. Многие уже не осознают, что владелец продукта и продуктолог — это разные роли.

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

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

Настало время перемен

«Don’t think of an elephant!« («Не думайте о слоне!») — это название книги о фрейминге. А при чём тут слон? Хитрость в том, что если я попрошу вас не думать о чём-то, то вы будете об этом думать. Со «слоном» связан некий фрейм вашего мышления, который активируется по этому слову и привязывает все обсуждения к животному. И если я скажу «Не думайте о слоне!», то вы станете о нём думать, и слон будет определять ваши действия. Хотя книга посвящена фреймингу в политических дискуссиях, однако его можно применять в любой сфере, где встречаются разные взгляды на мир:

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

Википедия

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

Фрейм бэклога

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

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

Если исходить из бэклога, то для достижения успеха нужно реализовать все пункты списка. И если мы не добились успеха, значит, реализовали слишком мало. «Поэтому нужно работать как можно быстрее и эффективнее, ведь от этого зависит наш успех». Генеральные директоры часто задаются вопросом, почему их разработчики не работают так же долго, как и маркетологи. Руководители считают, что успех стартапов зависит от того, будут ли разработчики работать по ночам. Ведь «чем больше фич из бэклога мы реализуем, тем успешнее будем». Это совпадает с интересами технического директора: чем больше у нас разработчиков, тем больше фич мы реализуем и тем больше будет успех. При таком восприятии мира разработчики превращаются в ресурс. Чем их больше, тем лучше. Чем эффективнее используется ресурс, тем лучше.

Этот фрейм сводит задачу технарей к исполнению и доставке фич. Зачастую технические директоры гордятся тем, как организована доставка. И когда возникают проблемы, генеральные директоры думают, что «технари не доставили нужные фичи». Якобы причина проблем в том, что «IT медленно реализует бэклог». При этом разработчики не чувствуют ответственности за успех и считают, что продуктологи должны говорить им, над чем работать. И если продукт постигла неудача, то это продуктолог велел работать не над тем, чем нужно. Забавно, что так думают только разработчики, а все остальные считают, что «технари не доставили фичи».



Мышление в контексте бэклога.

Если продукт оказался успешным, то это благодаря ви?дению продуктолога. А если продукт потерпел неудачу, то это потому, что мы не полностью реализовали ви?дение продуктолога. «Мы добились бы успеха, если бы разработчики работали быстрее или больше. Или если бы разработчиков было больше». В этой системе успех и провал чётко разделены. Неудивительно, что фрейм бэклога так популярен.

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

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

Фрейм влияния

Какой недостаток у фрейма бэклога? 

Если бы iPhone вышел на рынок на два месяца позже, ничего не изменилось бы. iPhone всё равно перевернул бы мир. Apple всё равно стала бы одной из важнейших компаний. А вот если бы она не выпустила iPhone, тогда мир был бы другим. Стив Джобс не повлиял бы на рынок так, как это произошло в реальности. Ключом к успеху Apple стала не эффективность разработчиков и не доставка всех фич. Ведь у первого iPhone не было многих возможностей, которые сегодня мы считаем обыденностью, например, App Store. Компания добилась такого успеха, потому что сосредоточилась не на эффективности, а на том, чтобы оказать влияние. Стив Джобс хотел изменить рынок телефонов. iPhone создавали исходя из этой задачи, а не в соответствии с подробным списком фич от разных департаментов Apple. 

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

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

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

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

• Как отсеивать идеи на этапе их генерирования? 
• Кто это делает? 
• Нужно ли отсеивать 90 % идей или реализовывать 90 %? 

Также отбрасывайте неудачные идеи, которые уже находятся в разработке. Вы потратили на что-то время, энергию и деньги, и поняли, что это не повлияет на рынок или заказчиков? Остановитесь! Выкиньте это. Apple много всего разрабатывала и не вывела на рынок. Это нормально — отбросить то, что не оказывает влияния. Хотя я не встречал компании, которые останавливали на середине разработку продуктов или фич — «ой, мы потратили ресурсы!». Сделать это мешает фрейм эффективности.

Вы можете сказать, что мы уже отсеиваем идеи с помощью OKR (целей и ключевых результатов), пользовательских сценариев и KPI:

• OKR должны помогать нам сосредоточиться на ключевых результатах;
• пользовательские сценарии должны ставить во главу угла точку зрения заказчика;
• KPI должны отражать наше влияние. 

Но на самом деле мы всё ещё ориентируемся на бэклог. Мы научились комбинировать этот фрейм с OKR, пользовательскими сценариями и KPI.

Помните неизвестного разработчика, который молил о помощи? Работая в контексте влияния, разработчики чувствуют себя счастливее. Они создают то, что меняет рынок или заказчиков, и получают больше контроля, помогая отсеивать идеи. Этот фрейм не заточен на скорость. Здесь нет срезания углов или отказа от хороших практик разработки. Нет разделения ответственности за успех и провал. Этот фрейм помогает компаниям быть успешнее. Настала пора перемен.

Приятного кодинга!

Стефан Шмидт (Stephan Schmidt)