Сколько-то лет назад считалось, что разработчик — это человек, который знает о продукте чуть ли не больше всех. Потому что он его оцифровывает. В текущих реалиях и больших компаниях это стало просто невозможно. Да и не нужно. Число факторов, которые влияют на бизнес и продукт столь велико, что в одного человека их не впихнуть, а задач становится всё больше. При этом ключевая задача разработчика не меняется. Мир становится сложнее, а задача его моделировать остаётся.
Я видела проекты, которые избавляются от узкого горлышка в лице техлида, убирают стадию технического моделирования продукта и превращают разработчика в оператора станка, печатающего код. Появляются многочисленные прослойки продуктовых и проджект-менеджеров, продуктовых аналитиков и других специалистов, которые придумывают готовые решения и спускают их исполнителям. Это работает, приносит результаты. Но если параллельно поставить две команды: одну, где тесно интегрированы продукт и техническая модель, и вторую, которая делает решения по ТЗ, — первая покажет себя эффективнее, релиз фич будет быстрее при меньшем количестве вовлечённых людей. Как этого добиться — попробуем разобраться в статье.
Софья Новожилова
Пишу код, запускаю продукты
Когда сломалась коммуникация
Классическая ситуация: компания разрабатывает b2b-продукт, приходит клиент с запросом на доработку, менеджеры формулируют решение, разработчики оценивают сроки и делают задачи. Потом оказывается, что сроки горят, переговоры не заканчиваются, а клиенту нужно было вообще не то, что принесли в разработку.
В результате клиент недоволен уровнем поддержки продукта, ведь все оговоренные сроки прошли. Менеджер недоволен разработчиком, который делает задачу по-своему или слишком долго. Разработчик недоволен менеджером, который не смог нормально сформулировать задачу и принести проблему, а не плохое решение.
Я буду использовать должность «менеджер», чтобы обозначить человека, отвечающего за продукт и приносящего заказ на фичу в разработку. В разных компаниях такие люди могут называться проджект-менеджерами, продакт-менеджерами, продакт-аналитиками, просто аналитиками или как-то ещё. Как правило, у них есть прямой контакт с клиентами, с бизнесом и они знают вектор развития продукта.
Разрывы в коммуникации между ответственными за продукт и разработчиками очень часто возникают из-за отсутствия постоянного контакта этих двух команд. Одни считают, что раз у них есть знание того, как хочет клиент или как развивается продукт, они могут предлагать уже готовые решения самостоятельно. А другие не задаются вопросом, ЗАЧЕМ мы это делаем именно так.
Разные точки обзора на продукт
Продуктовый менеджер смотрит на продукт «из стратосферы», видит, как тот взаимодействует со всей планетой, глубоко разбирается в предметной области: продажах, бухгалтерии или производстве. Он знает, что именно помогает продукту приносить деньги.
Разработчик смотрит на продукт «от ядра». Видит сервера, объёмы и нагрузку баз данных, знает всё про микросервисы и монолиты, как эффективно вычитать и склеить данные из разных источников. Эти знания очень нужны продукту, но далеко не всегда понятно, сколько конкретная оптимизация алгоритма принесёт денег или как повлияет на продажи.
В некоторых ситуациях у разработчика и менеджера конфликтующие интересы. Возможно, что стремительное увеличение числа пользователей в продукте будет полезно для имиджа компании или напрямую увеличит прибыль, ведь каждый новый клиент вносит плату за подписку на услуги. Менеджер в восторге от предстоящего расширения. Со стороны разработчика ситуация не так радужна. Ведь сильное увеличение трафика поменяет поведение системы и принесёт массу новых технических проблем. Такому развитию событий разработчик совсем не рад.
Коммуникации в IT-сфере
В IT-сфере менеджер, как правило, хорошо погружен в технические детали, он такой же технический специалист. Поэтому разработчику проще объяснить ему внутренние ограничения системы или неочевидные возможности.
В IT-проектах возникает следующий диалог:
Менеджер: «У нас проблемы в компоненте Х. И мы придумали офигенное решение, надо делать».
Разработчик: «Оно, конечно, классное, но плохо вписывается в текущую архитектуру. Я могу быстро сделать вот это, это и это, и проблема будет в 99% случаев решена».
Часто предлагаемый «снизу» вариант устраивает обе стороны. Важный фактор, повлиявший на успех, — разработчик понимает реальную проблему.
➡️ Что делать разработчику? Разобраться в причинах.
➡️ Что делать менеджеру? Искать и приносить проблемы, а не готовые решения.
|
Пример. Компания разрабатывает корпоративный портал, клиент хочет кастомизировать свой интерфейс, самостоятельно генерируя запросы к БД. Для очередного запроса нужен идентификатор пользовательской сессии. Он неявно вычисляется и передаётся фронтендом портала, и клиенту негде его взять для нового запроса. Менеджер обещает клиенту узнать и рассказать логику формирования этой сущности. При общении с разработчиком оказывается, что строку идентификатора формирует довольно сложный легаси-код, и объяснить его клиенту было не самой хорошей идеей, а переписать — недели рефакторинга. Ситуацию спасает вопрос «Зачем?», заданный разработчиком. Оказывается, что клиенту этот идентификатор нужен лишь потому, что API БД считает его обязательным. Если убрать на стороне сервиса строгую проверку и обработать несколько несложных кейсов, задача будет решена за несколько дней. |
Коммуникации не в IT-сфере
В нетехнических продуктах разработчик и менеджер имеют разную степень погружения в предметную область продукта. Для примера возьмём курьерское приложение или такси. Менеджер не знает, что под капотом, может не понимать, где заканчивается мобильное приложение и начинается бэкенд. Разработчик же не понимает всех нюансов пользовательского опыта. Он плохо представляет рабочий день таксиста или курьера, и какие трудности тот испытывает.
➡️ Что делать разработчику? Поставить себя на место пользователя.
➡️ Что делать менеджеру? Приносить истории, показать, в каких условиях используется продукт.
|
Пример. Компания делает кредитный продукт. Оператор в магазине предлагает покупателю оформить покупку через сервис рассрочки. Если клиент соглашается, оператор создаёт в системе заявку, выясняет у пользователя какие-то данные, ждёт, пока пройдёт скоринг и проверка надёжности потенциального заёмщика. Время идёт, лоадер на экране крутится. Все ждут. Копится очередь. В мире разработчика всё идёт по плану. Ведь серверу нужно опросить множество источников, прежде чем вынести решение. Потому и крутится лоадер — идёт работа. Мотивации сделать что-то лучше, когда и других задач хватает, особо нет. |
Почему менеджер не идёт к разработчику
Наиболее частое заблуждение со стороны менеджеров, с которым я сталкивалась: у разработчика и так полно задач, не нужно отвлекать его размышлениями о продукте.
Чтобы понять, откуда возникает это мнение, достаточно посмотреть на типичный список задач разработчика.
Баги. Ошибки в коде, ошибки в реализации поведения и прочий груз уже запущенных фич.
Техдолг. Ненаписанные тесты, ненастроенные системы релизов, документации, которые бы и жизнь самих разработчиков сделали лучше, да всё некогда.
Постоянно растущий продукт. Невозможно заложить на старте все варианты увеличения нагрузки и неограниченное масштабирование. Это нормально соизмерять затраченное на решение усилие и текущий размер бизнеса. Изменение инфраструктуры под растущий продукт — это постоянный органичный процесс.
Новые фичи. Маленькие и большие. Некоторые из них требуют подготовки кода и предварительных рефакторингов.
Весь этот список скрывает за собой не одну и не две задачи, а постоянно растущий поток. И задачи из всех групп нужно успевать брать в работу.
Как грамотно отвлекать разработчика
У разработки полно текущих задач. Из-за этого кажется, что если заставить разработчиков регулярно общаться с продуктовыми менеджерами, следить за планами и развитием продукта, то несчастных просто разорвёт на части. Но это не так.
Если техлид будет знать планы развития бизнеса на несколько шагов вперёд, он сможет заложить их выполение в текущие модели. Большинство задач для новых фич органично встраиваются в текущие. Да, они добавляют какое-то количество человеко-часов к решению уже поставленной задачи. Но как минимум экономится время на восстановление контекста, как максимум — время на полное изменение решения в будущем.
➡️ Что делать разработчику? Заглядывать на несколько шагов вперёд, следить за планами по развитию продукта.
➡️ Что делать менеджеру? Делиться крупными планами и идеями, витающими в воздухе.
|
Пример. Когда люди имеют перед глазами свой бонусный счёт, это искушает их совершить покупку и потратить баллы скорее. А если написать, когда и сколько бонусов сгорит, это ещё больше подстёгивает к покупке. Звучит хорошо и просто. Но технически эта задача вызывает массу вопросов. В каком виде хранить бонусы? Что если изначально завели простой счётчик на общую сумму, и программа физически не знает, когда этот бонус сгорит? Если к новым бонусам начать добавлять даты их начисления, политики их сгорания, то что делать со старыми? Простая задача растягивается на недели, потому что код был не готов. Поэтому полезно как можно раньше начинать делиться планами по развитию. Это не означает, что следует заложить в код все фичи на год вперёд, но хороший специалист оставит лазейки, которые в будущем расширит и использует. |
Когда разработка моделирует продукт
Есть такой подход к организации разработки, при котором одним из ключевых этапов является моделирование предметной области. Называется он Domain Driven Design. Если описывать кратко и упрощённо, то перед стартом проекта рекомендуется собрать инженеров и бизнес-экспертов и начинать писать код, только когда эти две группы научатся понимать друг друга.
Задача этого этапа — выработать единый язык: обозначить все термины и ключевые сущности, описать связи между ними, зафиксировать основные ограничения. Это называется определить Core Domain. После того, как обе стороны синхронизировали видение, приступают к реализации решения. В процессе развития продукта модель регулярно синхронизируют, за счёт этого инженеры и эксперты-менеджеры постоянно контактируют.
Преимущества для команды
Процесс построения общей модели подразумевает, что разработчики и менеджеры будут постоянно обмениваться практическими кейсами. А практические кейсы — это обратная связь и понимание, зачем команда делает ту или иную задачу. В долгосрочной перспективе время на обсуждение рядовых фич сокращается, потому что все члены команды начинают говорить на одном языке и понимать друг друга с полуслова.
Сложности для разработки
Навыки обобщения и моделирования задач бизнеса — практические. Они приходят с опытом, тут не получится пройти курс и стать «тем самым человеком». Требуется много практики, и будет полезно расширять кругозор и поработать с продуктами в разных отраслях или найти наставника, анализировать его решения и учиться. Важно не только читать чужой код или примеры из книг и статей, но и реализовывать их в реальных проектах. Потому что чужие модели всегда приходится адаптировать, и это тоже навык.
Сложности для менеджера
Сторонники концепции часто называют модель дистиллированным знанием. Даже интуитивно словосочетание подразумевает, что процесс выделения основных объектов бизнес-процесса (продукта) и чёткое описание связей между ними — долгий и трудоёмкий, его нужно построить и поддерживать.
Что делать, если разработка не хочет вникать в продукт
Не всем разработчикам интересны продукты для людей, не всякий разработчик хочет погружаться в продуктовую область. И это нормально. Не стоит никого заставлять.
Есть разработчики, которые кайфуют от технологий, а есть те, кто получает удовольствие от осознания, что другие люди используют результат их работы. И те и другие — классные специалисты, но приносят пользу в разных частях продукта. Первые не захотят вникать в детали пользовательского опыта, а вторые начнут скучать и терять мотивацию без обратной связи. Это стоит учитывать и менеджеру, и техлиду, и самому разработчику.
Можно посмотреть на вопрос заинтересованности в другом ключе: кому-то не хочется мыслить глобально, а нравится решать задачи, которые ставят извне. Таким людям комфортно иметь небольшой контекст и зону ответственности. В таких условиях они прекрасно трудятся, обеспечивая стабильную работу продукта.
Но скорость технического развития продукта обеспечивают вовлечённые в бизнес и моделирующие его сотрудники. Им приходится не только учиться разработке, но и тренироваться в моделировании процессов реального мира.
Даже если разработчику интересно делать пользовательские продукты — не факт, что текущий продукт его зажигает. Если ответственный менеджер не горит проектом, не нацелен на результат, то исполнитель это чувствует, и его мотивация падает.
➡️ Что делать менеджеру? Продавайте продукт коллегам так же, как и клиентам.
➡️ Что делать разработчику? Если вам интересно делать продукты для людей, изучайте предметную область. Если нет — фиксируйте это при найме.
Сила в синтезе
Разработчик — человек погруженный в технику, он часто не рассматривает продукт как рядовой потребитель. Но при этом даёт полное техническое сопровождение. Он делает цифровую модель продукта. Поэтому, если он не представляет последний со всех сторон, модель может получиться ущербной, и продукт будет развиваться медленнее.
Продуктовый менеджер видит продукт более широко. Он имеет максимум данных о том, как продукт должен взаимодействовать с миром, и как мир взаимодействует с продуктом. Если делиться этой картинкой с разработкой и добавлять новые факторы, итоговая техническая модель будет быстрее реагировать на изменения потребностей пользователей.
Тот факт, что у разработчиков часто ограничен ресурс — кажется, что они вечно злы и задают неудобные вопросы — мотивирует других членов команды готовиться к встречам. Если они заранее прорабатывают потенциальные вопросы «Зачем?» и «Почему?», общение получается более коротким и эффективным. В итоге люди с разным мышлением и взглядом на продукт общаются и развивают друг друга.
Как построить общение командам разработки и продукта
Общение с командой разработки
Уважайте время на разработку. Договаривайтесь о встречах заранее и не раскидывайте их хаотично по дням недели. Чтобы погрузиться в задачу, разработчику нужно время на восстановление контекста. Каждый раз, когда его зовут на встречу или приходят с вопросом, этот контекст разрушается.
Давайте повестку и готовьте вопросы. Разработка привыкла иметь дело с понятным входом и выходом. Постарайтесь предоставить ей эти данные: что есть сейчас и какую проблему необходимо решить. Не приносите готовое решение. Дайте коллеге возможность придумать выходы из ситуации и почувствовать, что его решения важны.
Делитесь обратной связью. Покажите, как конкретное решение повлияло на бизнес или пользователя, показывайте отзывы или иллюстрируйте боли.
Организуйте регулярные встречи про планы и итоги. Например, раз в месяц. Будьте готовы объяснить какие-то показатели просто и наглядно. Ваша цель — сделать так, чтобы исполнители поняли, какую роль они играют в общем прогрессе или провале.
Общение с командой продукта
Не игнорируйте менеджера. Встречи с продуктовыми менеджерами полезны, они помогают сориентироваться, куда бежим и зачем бежим, расставить приоритеты или понять, за что будут премию давать. Чтение дайджестов и отчётов тоже полезно, хоть и не заменяет реальное общение, где можно вопросами докопаться до сути проблемы.
Отказывайте. Джим Кэмп в книге «Нет. Лучшая стратегия ведения переговоров» писал, что отказ от первого предложенного решения стимулирует другую сторону объяснять реальные потребности. В моей практике это срабатывало не раз, помогало докопаться до истины, остудить разыгравшуюся фантазию или чрезмерный энтузиазм, вернуть обсуждение в конструктивное русло. Главное — не перегибать палку.
Не усложняйте. Старайтесь технические детали объяснять простым языком. Полезно иметь некоторый уровень абстракций между физическим миром и программным кодом, который бы понимала и разработка, и человек от продукта.
Самое важное, на мой взгляд, — помнить, что все мы участники одной команды, которые работают на общую цель.
Ближайшие курсы по программированию:
Бесплатные курсы и открытые занятия: