HRTech: Команда мечты

Материал входит в серию статей о build vs buy в HRTech.

Независимо от того, выбирает компания build или buy, команда реализации остаётся одним из ключевых факторов успеха любой HRTech-инициативы. Более того, зрелость tech-команды нередко становится одним из важных критериев при выборе самого подхода к HR-трансформации.

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

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

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

Не говоря уже о классических проектных рисках, которые похожи на чеховское ружьё: о них все знают, к ним готовятся, но в итоге они всё равно выстреливают.

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

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

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

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

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

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

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

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

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

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

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

Вынося роль Product Owner за скобки, попробую описать актуальную ролевую модель типовой команды.

В современных реалиях ядро команды разработки пользовательского приложения — а именно из таких решений в значительной степени и состоит HRTech — невозможно без трёх ролей:

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

Если не рассматривать low-code-разработку, то необходимость frontend- и backend-разработчиков очевидна уже на этапе работы над MVP. С дизайном это не всегда кажется столь же очевидным — но, на мой взгляд, зря.

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

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

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

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

DevOps. Независимо от способа использования инфраструктуры, вам довольно рано понадобится DevOps. Даже внутри облачной среды кто-то должен развернуть и поддерживать ваши окружения: разработку, тестирование, demo, pre-prod, production и другие. Их набор может отличаться в зависимости от зрелости продукта и принятых правил разработки, но очень быстро становится понятно: одной среды недостаточно.

Это неизбежно. Вам нужно где-то показывать продукт пользователям, пока команда продолжает работу. Нужно где-то проверять изменения до выхода в production. Нужны бэкапы, мониторинг, логи, доступы, процессы поставки и восстановления. Это отдельный мир.

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

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

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

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

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

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

Я бы выделил три спорные для себя роли в команде:

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

Project Manager / Delivery Manager / Scrum Master. Здесь я объединяю роли, отвечающие за организацию работы внутри команды и за поставку результата. Чем сложнее внешняя среда — процессы, согласования, зависимости, ожидания менеджмента, — тем больше у этой роли реальной работы и тем выше ценность выделенного человека.

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

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

Tech Lead. У появления роли Tech Lead обычно есть несколько предпосылок. Первая — слабая техническая экспертиза у отдельных участников команды на фоне отсутствия сильного экспертного сообщества в ресурсном пуле. Тогда этот дефицит компенсируют выделением отдельного эксперта внутри команды. Вторая — ситуация, когда senior-разработчик перерастает свою текущую позицию, и для того чтобы удержать его внутри компании, под него фактически создают новую роль.

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

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

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

И, наверное, самый плохой сценарий — когда из отличного senior-разработчика получается слабый Tech Lead. В этом случае команда теряет сильного разработчика, но при этом не получает полноценного лидера.

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

С одной стороны, вместе с UX/UI-дизайнером это одни из главных помощников Product Owner в развитии продукта. Часто его единомышленники. Без их участия при работе над большим продуктом очень быстро перестаёт хватать времени: просто в сутках уже недостаточно 24 часов. Особенно если в компании действует производственный framework, который жёстко регламентирует состав и объём документации, разрабатываемой командой.

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

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

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

Из таких ролей я бы отметил Data Engineer. Как только продукт начинает всерьёз опираться на данные — особенно если появляются несколько источников, витрины, таблицы, подготовка данных для аналитики, автоматизации, — довольно быстро возникает потребность в человеке, который отвечает именно за этот слой.

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

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

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

И ещё одну роль я намеренно оставил напоследок. Потому что именно в ней чаще всего и сходятся все противоречия HRTech-продукта: интересы бизнеса и пользователей, ограничения команды, сложность решений, давление сроков и неопределённость приоритетов. Это роль Product Owner.

Product Owner — это не просто человек, который ведёт backlog, собирает требования, синхронизирует команду со стейкхолдерами и проводит demo. В нормальной продуктовой логике это роль интегральной ответственности: за вектор развития продукта, за приоритеты, за целостность решений и за то, чтобы продукт в итоге решал реальные задачи, а не просто демонстрировал активность.

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

Иногда Product Owner красиво называют mini-CIO. То есть человеком, который должен видеть всю картину, удерживать направление развития, увязывать интересы бизнеса и технологий и отвечать за результат. Но правда обычно в том, что в этой конструкции по-настоящему работает только приставка mini. Ответственность есть, а полномочия урезаны. От PO ждут взрослой позиции, но дают ему детский набор инструментов.

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

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

Именно поэтому в такой момент так легко превратиться в секретаря коллективной воли — и так потом трудно вовремя остановиться. Хороший Product Owner действительно должен уметь собирать интересы разных сторон, слышать аргументы, понимать ограничения и фасилитировать сложные обсуждения. Но этим его работа не заканчивается. Дальше он должен переработать всё это в продуктовую логику, принять решение и в некоторых случаях стать для своих стейкхолдеров даже не посредником, а ментором — человеком, который помогает увидеть, что полезно не только локально, но и для продукта в целом.

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

Product Owner не должен быть самоуверенным. Но он обязан быть уверенным в своих силах и в решениях, которые принимает с учётом всей сложности контекста. Делай что должен — и будь что будет. Лучше сделать много хорошего и где-то ошибиться, чем не сделать ничего из-за страха ошибки.

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

Именно поэтому сильный Product Owner нужен в любой модели. В build он не даёт продукту расползтись в бесконечный набор локальных доработок. В buy — не даёт внедрению превратиться в пассивное подчинение ограничениям коробки или в хаотичную адаптацию всего под всех. В любом случае нужен человек, который не просто координирует ожидания, а удерживает целое. Потому что в HRTech выбор между build и buy важен — но ещё важнее, есть ли у продукта тот, кто действительно готов за него отвечать.