Есть такое понятие, как I-shaped специалист — человек, который является экспертом в какой-то области и развивает свои знания в ее рамках. А еще есть понятие дженералист — этот человек уже разбирается во многих областях, но при этом не является ни в одной из них экспертом. В восьмидесятых-девяностых годах появилось понятие “T-shaped специалист”, тот, кто является экспертом в какой-то одной области и имеет поверхностные знания в одной или нескольких других. Сразу оговорюсь, что мы в продукте Кошелька под областями понимаем платформы разработки — бэкенд, QA, IOS, Web и так далее.
Наша команда горит идеей T-shape, мы считаем, что благодаря этому инструменту мы получили заметное количество плюшек, как для команды и продукта, так и лично для себя. Но это не значит, что в рамках компании или даже продукта нам легко продать T-shape. Мы сталкиваемся с большим количеством противоречий. Поэтому сегодня я хочу рассказать о том, почему T-shape — это круто, что вы можете получить, применяя его, и, возможно, задуматься над тем, не начать ли применять этот подход и в ваших командах.
Четыре года назад я работала в продукте QIWI Кошелек. Мы работали по Agile и внедряли SCRUM. Продукт состоял из платформенных команд: QA, бэкенд, Web и мобилки. При этом у каждой команды был свой отдельный product owner и свой отдельный бэклог задач.
Вот как выглядел процесс донесения инкремента до пользователя.
Задача попадала в бэклог бэкенда.
Бэкенд эту задачу делал и отдавал в QA.
QA в рамках своего спринта писали на нее автотесты (при этом, возможно, задачу возвращали бэкенду на исправление багов).
Задачи попадали в бэклоги мобилок и Web’а.
Там уже в рамках своих спринтов независимо друг от друга пилили фронтовую часть.
Затем задачи отдавали обратно в QA.
QA писали UI-автотесты.
После всего этого фичу можно было доводить до пользователя.
Если схематично, то вот.
Естественно, в таком подходе фича до пользователя доходила не в рамках каких-то недель, а в рамках месяцев. При этом еще и UI/UX между фронтами был рассинхронизирован, потому что в разных командах были разные дизайнеры. А бизнес при этом хотел иметь возможность быстро тестировать гипотезы — чтобы мы в рамках спринта могли сделать MVP, разлить на пользователя и быстро собрать обратную связь. При таком подходе сделать это было абсолютно невозможно.
Вместе с этим бизнес стал смотреть в сторону фреймворка под названием Large-Scale Scrum, сокращенно LeSS. Создатели этого фреймворка позиционируют его как “Скрам, применяемый ко множеству команд, работающих совместно над одним продуктом”.
Так же, как и в классическом SCRUM, в LeSS есть рекомендация, что команды должны быть самоуправляемыми и кросс-функциональными. Это позволяет сократить Time-to-Market, то есть скорость доведения фичи до пользователя, и быстро тестировать гипотезы, синхронизировать UI/UX между платформами и избавиться от межкомандных зависимостей на пути фичи к пользователю.
Поэтому четыре года назад в Кошельке началась первая итерация перехода к LeSS. У нас образовались две фиче-команды, у которых был один общий product owner и один общий бэклог. При этом платформенные команды мобилок и Web’а остались, но они стали заниматься задачами по развитию платформы, а именно фичи для пользователей стали пилить фиче-команды. Проработали мы так несколько месяцев и получили довольно классный результат: за два спринта получалось полностью довести инкремент до пользователя, дизайн наконец-то стал синхронизирован между всеми фронтовыми платформами, а во время реализации задач у нас не было зависимостей от других команд.
Особенности подхода
При этом мы поняли, что у такого подхода есть некоторые особенности, о которых мы не задумывались, работая в платформенных командах.
Прежде всего: что делать разработчику, когда по его платформе закончились задачи? У нас довольно часто бывало так, что ребята с Web’а могли все свои задачи сделать за несколько дней. При этом были коллеги с бэкенда, у которых задач было море, и они в течение спринта постоянно зашивались в них. А задачи QA откладывались на конец спринта, и мы часто не успевали их доделать.
Что бы могли делать ребята с Web’а? Они могли заниматься саморазвитием, техдолгом, какими-то дополнительными задачами, но при этом они никак не могли помочь коллегам с бэкенда и остальной команде по цели спринта. По себе могу сказать, что в такой ситуации ты вроде как работаешь в команде, но с другой стороны, ты в отрыве от всех и от общей цели, это сильно демотивирует. По сути, ты из команды выпадаешь.
Во время спринтов мы все равно продолжили общаться в рамках платформ, например, команда собиралась на планирование и как и раньше разделялась по платформам. Например, я как представитель бэкенда могла декомпозировать цели спринта на задачи по бэкенду и высказывать свое мнение, но при этом помочь ребятам с Web, с IOS и Android не могла.
А ещё когда мы собирались на DSM, обсуждали, кто что делал, я снова могла помочь по бэкенду, но по другим платформам у меня знаний не было. Поэтому фокус у меня всегда был с ребятами с бэкенда, а когда что-то рассказывали ребята с других платформ, оставаться в контексте было очень сложно.
Время T-shape
В какой-то момент мы поняли, что эти две основные проблемы нам может помочь решить T-shape. Мы стали обсуждать это в рамках двух фиче-команд и пришли к выводу, что T-shape может принести нам много выгоды. Что случилось дальше? На самом деле, ничего. Этому было две причины. Первая — в рамках компании ни у кого не было опыта применения T-shape. Вторая — в Интернете довольно много статей про T-shape, там описаны его плюсы, минусы, советы, нужен ли он вообще в вашей компании, но нет абсолютно ни одного примера внедрения T-shape в какой-нибудь компании.
Это стало для нас блокером, потому что мы вроде бы и хотели его применять, но абсолютно не знали, с чего начать. На этом, в принципе, все и заглохло.
Два с половиной года назад мы в Кошельке окончательно завершили переход от платформенных команд к кроссплатформенным. У нас образовались три новые feature-team с единым product owner’ом и бэклогом. Наверное, в большой степени мне повезло, но в нашей новой команде из семи человек большая часть людей идею T-shape поддержала. Мы решили, что с первого же дня нашей совместной работы будем применять этот подход. Опыта у нас не было, но было четкое понимание необходимости делиться знаниями в своей экспертной платформе. Мы не знали, как это эффективно делать, поэтому импровизировали.
Например, брали себе вторую платформу-специальность, в которой был приоритет T-shape, или составляли документацию и списки литературы для тишейперов, то есть для тех, кто развивает другие платформы. Устраивали внутрикомандные воркшопы, дробили задачи на более атомарные для тишейперов и много чего еще.
Что-то из этого заходило, что-то нет, до чего-то мы даже не дошли на практике. Но у нас сформировался некоторый процесс: в начале спринта мы собирались на планировании и дробили задачи. Делали мы это не по платформам отдельно, как раньше, а все вместе, для того, чтобы у тишейперов начинало формироваться поверхностное представление о других платформах.
Также мы стали выстраивать задачи в порядке приоритета, и делали мы их не как обычно (одна задача на одного человека), а одну задачу всей командой. Эксперт, в чьей платформе была текущая задача, брал ее, скидывал в командный чат и прикреплял ссылку на Zoom. Вся команда присоединялась к конференции, эксперт в режиме online шарил экран, делал задачу и попутно рассказывал, что, почему и как именно он делает, а также отвечал на возникающие вопросы.
Так мы проработали пару месяцев, в итоге у тишейперов сформировался поверхностный объем знаний, и мы смогли начать применять парное программирование.
Мы всё так же собирались группами, но с чуть меньшим количеством людей, 3-4 человека, и делали задачу в формате mob programming. При этом тишейперы в рамках одной сессии парного программирования могли меняться между собой в качестве драйвера. В таком формате мы проработали еще где-то 2-3 месяца.
Итог — какие-то простые задачи по платформам разработчики уже могли делать самостоятельно, без эксперта в роли навигатора. Такие задачи мы стали шарить между собой: простые задачи тишейперы забирали себе и делали их оффлайн, а какие-то более сложные мы продолжали делать вместе.
В принципе, мы так работаем и сейчас, за исключением того, что сейчас тишейперы могут уже более сложные задачи делать в одиночку. С таким же подходом при необходимости онбордим и новых людей в команду. При этом, если есть какой-то вопрос или если ты не знаешь, что делать, то всегда можно написать в командный чат, написать эксперту или созвониться с ним, при необходимости — и со всей командой.
Сложности внедрения
Первый, самый заметный момент – сильно снизилась скорость работы команды. Мы начали изучать что-то новое, и, самое главное, в начале внедрения T-shape из подхода, при котором один человек делал одну задачу, перешли к подходу, при котором вся команда делает одну задачу.
Что с этой проблемой можно сделать? На самом деле, ничего, с этим стоит смириться. Нужно донести до команды и product owner’а, что не будет такого — начали вы применять T-shape, и через пару недель ваша скорость работы взлетела. Увы. Потому что T-shape — это все-таки про дальнейшую перспективу, и результат вы увидите скорее всего через N месяцев.
Вторая проблема — задачи. Был такой момент, когда несколько спринтов подряд наша команда делала задачи только на бэкенд. С точки зрения ребят с других платформ это было круто: у них появилось много времени на T-shape и огромный scope задач, на которых они могли попрактиковаться. Но, с точки зрения ребят с бэкенда, все было не так радужно, потому что задач на T-shape не было, соответственно, они никак не могли развиваться в другие платформы.
К счастью, с нами случилось такое всего один раз, и при этом мы выработали для себя план, как такую проблему можно решить. Поэтому, если в вашем продукте несколько команд, и, скажем, десять спринтов подряд одна команда делает задачи только на бэкенд, то на планировании между командами можно договориться поменяться задачами. Это позволит избежать ситуации, когда часть команд развивается, а часть — стоит на месте в развитии.
Третья проблема — не все разделяют идеологию T-shape. Как я уже сказала, большая часть людей в команде идею поддержала, но были два человека, которые сказали, что T-shape им не интересен и они не хотят его применять. Важно понимать, что это абсолютно нормально: кому-то интересно развиваться вширь, а кому-то нет. Есть два основных решения такой проблемы. Первое — вы с командой и с product owner’ом решаете, что вам это подходит и в вашей команде часть людей тишейпится, часть людей не тишейпится, и вы спокойно так работаете. Второе — вы собираете команду только из тишейперов.
Плюшки T-shape
Выгоду, которую мы получили с применением T-shape, можно разделить на несколько групп.
Первая — плюсы конкретно для команды. Во время шаринга знаний и постоянных сессий парного программирования у нас как side-effect прокачалась в команде эмпатия. Также у нас выровнялась нагрузка между участниками команды и, например, если у экспертов по их платформе задачи заканчиваются, они всегда могут взять задачи с других платформ и разгрузить тем самым других экспертов.
Повысился bus-фактор. Мы долгое время работали в команде в составе шести человек. В QIWI Кошельке пять платформ, поэтому несложно понять, что у нас было по одному эксперту на четырех платформах и еще два человека-эксперта на одной платформе. Когда кто-то из представителей этих четырех платформ уходил в отпуск, мы уже не могли взять любую задачу из продуктового бэклога. Сейчас же у нас могут быть 1-2-3 человека параллельно в отпуске, но это нам никак не мешает взять любую задачу. Да, мы выполним меньший объем работы, но с точки зрения product owner’а это круто — ему не нужно подбирать задачи под конкретный состав команды в каждом спринте.
Мы стали лучше понимать задачи друг друга, и, если раньше я смотрела наш спринт-бэклог и понимала, что делают ребята с бэкенда, но при этом абсолютно не понимала, что делают остальные, то сейчас все абсолютно прозрачно. Я знаю, кто чем занимается и сколько по времени и по объему каждая задача занимает.
У нас появился единый фокус на цели спринта. Нет такого, что “часть задач мои, а часть задач других людей”, у нас все задачи общие, и до цели спринта мы доходим вместе.
А что для бизнеса?
Сложно было бы продать T-shape, если бы не было плюсов и для бизнеса. Самое важное — снижение Time-to-Market’а фич. Если раньше в рамках двухнедельного спринта мы могли запилить фичу, разлить ее на тест и протестировать, то сейчас за две недели мы можем успеть не только сделать задачу в тестовой среде, но и зарелизить ее на пользователя, а иногда и собрать обратную связь.
С точки зрения бизнеса полезно и то, что команды становятся более гибкими и адаптивными. А в условиях часто меняющихся задач, частого перекоса объема задач в рамках целей спринта в какую-то одну платформу это очень круто. В командах становится меньше рисков и “бутылочных горлышек”, например, когда из участников команды кто-то вдруг выпадает посередине спринта, вся остальная команда может его задачи подхватить на себя, не нужно останавливать спринт или выкидывать какие-то задачи.
У членов команды становится более широкий взгляд на продукт, разработчики смотрят на задачу уже не с точки зрения своей экспертной платформы, а более широко, с точки зрения пользователя и его потребностей.
Не забываем про разработчиков
В T-shape есть плюсы и для самого разработчика. У меня прокачался технический кругозор, и это даже не столько про какие-то hard-skills в других платформах и изучение новых языков программирования, сколько про возможность посмотреть, как работают другие платформы, какие техники и подходы они используют, и спроецировать это на свою экспертную платформу.
T-shape помог шире взглянуть на продукт — раньше на PBR я была вовлечена, когда мы обсуждали бэкенд, но при этом, когда мы углублялись во фронты, мне в какой-то момент становилось неинтересно. Я не понимала, о чем говорят люди. Возникала мысль: что я вообще делаю на этой встрече, не трачу ли я зря время? Сейчас такого нет, потому что накопился опыт и знания в других платформах.
Soft-skills с точки зрения разработчика — тоже круто и ценно, это не только про эмпатию или про коммуникативность, но и про критическое мышление.
Важный плюс — смена контекста. Не знаю, как у вас, но лично мне иногда надоедает пилить бэкенд. Теперь же у меня появилось множество возможностей делать какие-то другие задачи: сверстать страницу на Web’е, запилить на Kotlin Native какой-нибудь модуль для IOS и Android, сделать модалку на IOS или view на Android. Это круто, для меня это в прямом смысле профилактика выгорания.
Как я уже сказала, мы в команде любим T-shape, но продать его кому-то не так легко.
Есть некоторый набор вопросов, с которыми мы чаще всего сталкиваемся.
Люди ассоциируют себя со своей платформой — они пришли работать в нее и хотят развиваться только в рамках нее. Во-первых, это нормально, во-вторых, не нужно никого заставлять это делать, потому что даже если вы вдруг и сможете заставить кого-то тишейпиться, то это скажется на мотивации и результатах человека, а в самом худшем случае он просто уволится.
Присутствует и синдром самозванца, когда людям вроде было бы интересно попробовать T-shape, но у них есть некоторые опасения — что у них не получится, страшно изучать что-то новое, не хочется подвести команду. Тут важно поддержать человека, донести до него, что нет ничего страшного в изучении нового, мы все с этого начинали.
Есть опасения потерять экспертизу в своей основной платформе. Тут в игру вступает time management: нужно понимать, что, если вы решили тишейпиться, не стоит уделять T-shape сто процентов времени. На планировании надо грамотно распределять время и задачи, чтобы часть времени уходила на свою платформу и только часть времени на T-shape, потому что броситься в T-shape с головой — не самая хорошая идея.
Итого
В середине лета я работала в Кошельке, у нас уже было четыре feature-команды, нас собрал product owner и сказал: “В Кошельке есть area под названием P2P или peer-to-peer, в ней всего одна команда и огромный продуктовый бэклог.” Естественно, одна команда этот бэклог не успевает сжигать, поэтому бизнес принял решение — одна команда из Кошелька перейдет на время в продукт P2P.
Так волею судьбы в P2P перешла именно наша команда. Отличительной особенностью P2P от Кошелька явился не столько даже другой контекст продукта, а то, что если в QIWI Кошельке было пять платформ, три платформы фронтов, то в новом продукте все задачи в бэклоге на бэкенд. Ретроспективно оглядываясь на последние два месяца, несмотря на то, что я топлю за T-shape, я все равно не могу не гордиться тем, как ребята с фронтов пережили эту ситуацию.
У нас был случай, когда на неделе меня два дня не было на работе, а второй бекендер вообще был в отпуске, но ребята-тишейперы отлично справились с задачами и без нас. Это очень круто. Круто, когда тебе нравится твоя работа, когда тебе нравится продукт, в котором ты работаешь, задачи, но за последние пару лет я поняла, что команда — очень важно.
Что ещё важно — благодаря такому подходу у нас в компании сохраняется (и реально используется) возможность перехода. Куда угодно: если человек осознал, что хочет пойти и поработать в соседнюю команду в другой для себя роли, если у него есть для этого навыки и желания, можно просто взять и осуществить горизонтальный переход.
Когда вы с командой на одной волне, очень здорово, если вы полностью доверяете друг другу. Это дорогого стоит.
Кстати, про вертикальный и горизонтальный рост в разработке мы общались с экспертами в нашем подкасте DevOne — подписывайтесь, слушайте нас на досуге, пробежках или сидя на диване.
