Текст книги "Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT"

Команда как продукт
Практическое руководство по созданию и управлению продуктовой командой в IT
Михаил Михайлович Кузьмицкий
Владимир Александрович Пулион

© Михаил Михайлович Кузьмицкий, 2024

© Владимир Александрович Пулион, 2024

ISBN 978-5-0064-9266-0

Создано в интеллектуальной издательской системе Ridero

ВВЕДЕНИЕ

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

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

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

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

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

– – – – – – – – – – – – – – – – —

Кейс: из каменного века в век цифровизации

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

Мы начинали свой путь в одной крупной компании федерального масштаба, в которой на тот момент насчитывалось более 300 тыс. сотрудников по всей стране. Это была компания, которая располагала собственной ИТ-инфраструктурой и решениями, но на тот момент это больше напоминало 20-е годы и всем в то время привычный синий экран в стиле Norton’а и окон от Windows 98. Обслуживать цепочку взаимосвязей на уровне всей страны – тяжелейший труд, но команде компании удалось добиться в этом огромных успехов. Но сейчас мы поговорим немного о другом.

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

Не сказать, что это был совсем каменный век в области цифровизации, но о UX11
  UX – user experience – «пользовательский опыт».


[Закрыть] и API22
  API – Application Programming Interface – программный интерфейс, с помощью которого приложения, веб-сервисы и программы обмениваются информацией.


[Закрыть] в то время точно никто еще не думал, как и об оптимизации процессов на уровне всей компании. А деревянные счеты порой не вызывали агрессивной реакции у сотрудников. Это интересное для нас состояние и стало отправной точкой для начала работы.

Биллинг 1.0

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

По итогам работы нашей команды уровень цифрового взаимодействия вышел на очень высокий уровень и достиг 70% в части взаимодействия b2b клиентов с компанией через WEB, а уровень внутренней оптимизации процессов и оцифровка работы сотрудников компании позволили поддерживать этот уровень на должном качественном уровне. Внутренняя CRM система обеспечивала моментальное заключение договора оферты с новым клиентом, давала плавный переход в личный кабинет компании и старт работы уже в течение 24 часов, когда ранее на это уходило до 1,5 месяца.

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

– – – – – – – – – – – – – – – – – – – —

ПРЕДИСЛОВИЕ

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

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

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

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

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

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

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

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

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

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

ГЛАВА 1
ФОРМИРОВАНИЕ КОМАНДЫㅤ

Структура продуктовой команды

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

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

Начнем наш разбор структуры команды с более административной части, если это можно так назвать.

– – – – – – – – – – – – – – – – – – – —

Кейс: владелец продукта – друг или начальник?

Суть: работая в окружении огромного количества команд, особенно в крупных компаниях, наблюдаешь очень интересную и в то же время очень грустную картину. Владелец продукта считает себя руководителем тех людей, кто работает над созданием продукта в продуктовой команде. Довольно часто встречаются два вида работы такой команды. Первый – когда владелец продукта является действующим административным руководителем, например занимает должность руководителя отдела или направления, а в его подчинении находятся все участники команды. Второй – когда владелец продукта является внешним сотрудником для команды продукта, как и все ее участники, например вертикаль дизайна или тестирования, разработки, а может и аналитики. В таком случае команда собирается под продукт из разных доменов и начинает работать над созданием продукта, после чего с большой долей вероятности переключается на следующие продукты, а иногда и вынуждена отключаться или переключаться на другие задачи вертикали. В первом варианте владельцы продукта допускают очень частую ошибку – ставят себя руководителями, а не членами команды. Кто такой владелец продукта в команде, спросишь ты. Да все просто: такой же сотрудник в команде, выполняющий множество задач, связанных с созданием или развитием продукта, общением со стейкхолдерами, планированием и стратегий и т. д. Так почему он руководитель? Он скорее проводник команды и капитан корабля, движущийся к достижению поставленных целей. Это очень тонкая грань: быть в меру руководителем и одновременно быть другом наравне со всеми, кто совместно с владельцем продукта создает ценность.

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

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

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

– – – – – – – – – – – – – – – – – – – —

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

– – – – – – – – – – – – – – – – – – – —

Кейс: техлид и тимлид в одном лице – такое возможно?

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

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

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

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

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

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

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

– – – – – – – – – – – – – – – – – – – —

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

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

Поиск и найм команды

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

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

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

– – – – – – – – – – – – – – – – – – – —

Кейс: системный и бизнес-аналитик в одном лице

Суть: нам довелось поработать с несколькими аналитиками, которые на тот момент не смогли однозначно идентифицировать себя в одной или другой области анализа. В чем выражалась некоторая неопределенность, разберемся подробнее. Бизнес-аналитик начинает свой путь с проработки новых или уже существующих бизнес-процессов, составляет схемы процесса, прокапывает детали и взаимосвязи. Результатом его работы должен стать оптимальный клиентский путь, который является максимально дешевым с точки зрения разработки для снижения time to market и в то же время решает ключевую бизнес-задачу с понятной ценностью для компании или клиента. Суть работы системного аналитика – имея понятный бизнес-процесс, наложить все это на системы и сервисы, описать взаимодействие систем, новые функции и модели данных, что уже после перейдет непосредственно в команду разработки.

Именно тут и кроется распыление активностей в аналитике. Если быстро перейти к проработке системной аналитики, не уделив должного внимания самому процессу, то впоследствии это превращается в ряд доработок после обсуждения с владельцем продукта или проведением внутреннего демо для бизнес-заказчика. А все потому, что не учтены специфические нюансы бизнеса и, как следствие, процесс, дальнейшее описание работы системы и ожидаемый после разработки результат являются ложными. К сожалению, такие вещи несут под собой не только double costs для команды и компании, но и сильно увеличивают time to market для критических для бизнеса фичей. А теперь представьте ситуацию: в Сибири появился новый логистический хаб, куда свозят товары крупнейшие поставщики из Китая или других стран. В ритейл-компаниях появляется задача оптимизации логистики до конечных клиентов, которая учитывает изменение маршрутов с учетом наличия ассортимента на новом складе. Если поддержку такой бизнес-фичи затянуть, то конкуренты, оптимизировав доставку раньше, смогут снизить цены на товары в своих интернет-магазинах и, как следствие, для тебя и твоей компании это будет потеря GMV33
  GMV – Gross Merchandise Value – общий объем оборота товаров.


[Закрыть] и просадка по остальным бизнес и продуктовым показателям.

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

Вывод: лучше не комбинировать в одном специалисте две или более функций, если ты не находишься в стартапе с максимально коротким сроком на его запуск и являющийся по сути проверкой идеи CVP44
  CVP – Customer Value Proposition – ценностное предложение покупателя.


[Закрыть] для конечного клиента.

– – – – – – – – – – – – – – – – – – – —

В процессе разработки продукта или проекта одной из важнейших ролей является дизайн. Домен дизайна включает в себя несколько ролей, которые в разных компаниях могут отличаться друг от друга. Одной из ключевых является продуктовый дизайнер. Он является членом продуктовой команды и занимается проработкой пользовательского опыта, не занимаясь при этом «рисованием картинок», баннеров и других креативов. Продуктовый дизайнер всегда находится в тесном взаимодействии с владельцами продукта или CPO55
  CPO – Chief Product Officer – «Директор по продукту».


[Закрыть], бизнес-аналитиками и другими членами продуктовой команды.

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

Также продуктовые дизайнеры занимаются проработкой клиентских путей, формированием CJM66
  CJM – Customer journey map – карта пути клиента.


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

– – – – – – – – – – – – – – – – – – – —

Кейс: дизайнер или продуктовый дизайнер

Суть: нам неоднократно приходилось сталкиваться с очень частым кейсом: «нарисуй баннер», «сделай иконку», «сюда надо картинку придумать» и т. п., да еще и в очень короткий срок, потому что компания, оказывается, «завтра» планирует запустить какую-нибудь акцию или рекламную кампанию. Конечно же, в продуктовой команде никогда нет выделенного ресурса в виде графического дизайнера, а если такое и встречается, то это нетипичная ситуация и считай тебе повезло. Графический дизайн в компании – это обычно отдельное подразделение, ресурсы которого распределяются на все активности компании и быстро получить там специалиста, как правило, невозможно. Что происходит в таких случаях? Владелец продукта обращается к продуктовому дизайнеру и просит помочь в решении этого вопроса. Почему это плохо? Да все просто на самом деле: продуктовый дизайнер обычно занят созданием нового клиентского пути по одной или нескольким приоритетным фичам, взаимодействует с потенциальными пользователями, исследует, формирует CJM. Вторгаясь в этот процесс, ты очевидно нарушаешь его, заставляешь человека переключиться на не типичную для него работу, которую он, если сделает классно, то пожертвует основными активностями и ты проиграешь в другом месте, закрыв текущую потребность. Но это лишь вершина айсберга. Если продуктового дизайнера постоянно загружать такой работой, то он просто выгорает, как и любой другой специалист, которого заставляют работать над непрофильными задачами. Береги продуктовых дизайнеров, без них ценность твоего продукта станет намного меньше, а проверка любой гипотезы через R&D77
  R&D – Research and development – исследования и разработка.


[Закрыть] гораздо дороже.

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

– – – – – – – – – – – – – – – – – – – —

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

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

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

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

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

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

– – – – – – – – – – – – – – – – – – – —

Кейс: тестировщик или разработчик – кто первый?

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


[Закрыть] продукта и показать его конечному потребителю, чтобы проверить гипотезу и CVP, которые необходимо донести. Если собирать стартап командой, уровень которой ниже чем middle+ / senior, то шанс попасть в те самые девять из десяти погибающих стартапов становится выше, ведь правильно заложенная архитектура продукта – это залог его успешного масштабирования в дальнейшем, а если речь идет об использовании одного бэкенда для web-приложений и мобильных приложений, то ценность высококвалифицированных специалистов на ранних стадиях становится еще выше. В ситуации, когда собирается стартап, функционал тестировщика минует множество бюрократических аспектов крупных компаний, и создания большого количества артефактов от тестирования также не требуется. Это значит, что тестировщик вполне может приступать к работе только после того, как готов первый блок функциональности, который можно проверять, сверять с макетами или требованиями и заводить дефекты. Раньше, чем есть первая кодовая база, привлекать тестировщика на стартап совершенно бессмысленно, если только у вас нет лишнего бюджета или желания вовлечь тестирование в процесс пораньше.