Я хотел стать Product Owner. Список обязанностей при этом и без того был приличный: руководитель направления, архитектор, владелец системы. Казалось бы, куда ещё? Но меня всё сильнее интересовали решения, которые принимались до того, как задача попадала в разработку.
В предыдущей истории я рассказывал, как мы приводили в порядок Битрикс24 и автоматизировали внутренние процессы. Я уже отвечал за техническое развитие системы, её стабильность, интеграции и команду. Теперь хотелось участвовать в выборе самого направления: что строим, кому это нужно и от чего готовы отказаться.
Так началась моя попытка стать владельцем продукта. Одну небольшую деталь я тогда недооценил: новую роль можно взять, а вот старые от этого автоматически не освобождаются.
Владелец системы и владелец продукта
В моей тогдашней работе владельца системы основное внимание уходило на её техническую жизнь. Как развивать архитектуру, не потерять стабильность, справиться с долгом, выстроить работу с подрядчиками. Влияния на продукт хватало, поэтому границу между ролями было легко не заметить.
Но когда начинаешь разбирать приоритеты вместе с бизнесом, меняется разговор. Технически интересная задача может неделями лежать в очереди, потому что сейчас важнее скучная доработка. А красиво описанную функцию иногда вообще не стоит делать. Нужно разобраться, какую проблему она решает и что случится, если оставить всё как есть.
Вот это мне и хотелось попробовать. Не ограничиваться обсуждением реализации, а отвечать за выбор, на который команда потратит следующие дни или недели.
Бизнес перестал быть гостем
Первые шаги с Agile у нас уже были. Мы планировали работу, разбирались с приоритетами, делали разработку прозрачнее. Но мне всё меньше нравилась привычная цепочка: бизнес где-то сформулировал желание, аналитик превратил его в постановку, разработчик получил готовый текст.
В конце этой цепочки иногда задают вопрос, который стоило обсудить в самом начале. Можно ли решить проблему проще? А точно ли пользователю нужен именно такой сценарий? Возвращать постановку по всей цепочке обратно — отдельное удовольствие.
Команда начала собираться иначе. В ней были разработчики, системные аналитики и представители бизнеса. Причём бизнесу требовалось участвовать в работе постоянно. Редкого визита с вопросом «ну как у вас дела?» было мало.
Это давало возможность обсудить задачу, пока решение ещё можно поменять без сожаления о потраченном времени. Разработчик слышал причину запроса и мог предложить другой вариант. Аналитик уточнял противоречия. Человек со стороны бизнеса тут же объяснял, какое ограничение действительно важно, а какое просто перешло в требования по привычке.
Первые месяцы, конечно, не выглядели картинкой из книги про продуктовые команды. Мы учились хотя бы одинаково понимать слова. Но иногда короткого разговора уже хватало, чтобы не делать несколько дней работы. После такого присутствие бизнеса в команде обосновывать гораздо легче.
Как собеседовать человека другой профессии
С наймом системных аналитиков у меня получился отдельный учебный курс. Разработчиков я к тому времени собеседовал много: мог уточнить ответ, углубиться в тему, почувствовать, где заканчивается опыт и начинается пересказ прочитанного. С аналитиками такой уверенности сначала не было.
Список вопросов про UML, BPMN, API и виды требований собрать несложно. Гораздо труднее по ответам понять, как человек будет работать рядом с нами.
Мне было интересно, что он сделает с просьбой «нужна кнопка вот здесь». Начнёт описывать кнопку или выяснит, зачем её хотят? Как разберётся в незнакомой предметной области? Что предпримет, если два подразделения требуют от системы противоположного?
Отдельный вопрос — как после всех разговоров останется договорённость, которую одинаково понимают бизнес и разработчики. Потому что хорошая встреча ещё не гарантирует хорошей постановки. Из переговорной можно выйти довольными, а реализовывать потом три разных решения.
Я снова столкнулся с тем, что уже замечал на собеседованиях программистов: знание инструментов помогает работать, но не описывает всю работу. На этот раз пришлось учиться замечать разницу в чужой профессии.
Бывший стажёр уже давно не стажёр
В новой команде появились знакомые из прежних этапов моей карьеры. Александр когда-то пришёл ко мне стажёром в Первом Бите. Потом мы разошлись по своим дорогам, а спустя годы снова оказались рядом.
Только прежнее распределение ролей осталось в прошлом. Передо мной был самостоятельный разработчик: со своим опытом, решениями и мнением, которое вовсе не обязано совпадать с моим. Я помнил, как он начинал, а работать теперь нужно было с человеком, которым он стал.
Потом появился Андрей, с которым мы когда-то работали в Аэро. Другая компания, другие проекты, другой период жизни — и вот мы снова в одной команде.
От таких встреч возникает странное чувство времени. Пока меняешь проекты, не особенно замечаешь, сколько лет прошло. А потом рядом оказываются люди сразу из нескольких твоих профессиональных жизней. Для автора «Баек старого программиста» полезное напоминание: слово «старого» уже начинает чем-то подтверждаться.
Руки тянутся к архитектуре
Одной из самых трудных привычек оказалось желание оставаться главным программистом. Кто-то предлагает решение, а у меня уже готово своё. Я знаю систему, помню ограничения и могу довольно подробно объяснить, как сделал бы сам.
Если каждый раз пользоваться этим преимуществом, команда быстро привыкает ждать ответа. Формально у неё Product Owner, а по факту — старший разработчик, через которого нужно провести любое заметное решение.
Приходилось придерживать себя и спрашивать: почему выбрали этот вариант, что ещё рассматривали, какие риски видят? Иногда выяснялось, что люди уже подумали о том, что я собирался им торжественно сообщить. Иногда находилось слабое место, которое действительно стоило обсудить.
Самый полезный для меня момент наступал, когда решение оставалось не таким, как выбрал бы я. Оно было обоснованным, команда понимала последствия — значит, могла его принять. С техническим прошлым это непросто: возможность вмешаться легко перепутать с необходимостью.
У каждого есть хорошая причина
С приоритетами вышло похожее разочарование в собственной всесильности. Кажется, Product Owner управляет списком задач и наконец может навести порядок. А потом обнаруживаешь, что у всех участников есть разумные аргументы.
Бизнесу нужно быстрее запустить изменение. Разработчики хотят сначала убрать долг, который мешает этим изменениям. Пользователям неудобен текущий сценарий. Руководству нужен срок. Всё вместе не помещается в возможности команды.
Выбрать приоритет означало объяснить остальным, почему их работа откладывается. И дальше помнить об этом выборе, когда появится следующая срочная просьба. Сказать «не сейчас» оказалось легче, чем выдержать собственное решение.
Мне нравилось видеть всю эту картину. Я понимал бизнес, знал людей и технические ограничения, мог быстро связать одно с другим. Некоторое время казалось, что из меня получается очень удобная конструкция для компании.
Два стула никуда не уехали. Пока
А потом я посмотрел на обычный рабочий день. Обсуждение развития продукта, планирование, архитектурный вопрос, собеседование. Между ними нужно помочь аналитику, поговорить с разработчиком, разобраться с проблемой на боевой системе. Подумать о продукте спокойно можно вечером. Если к вечеру ещё есть чем думать.
Я оставался руководителем направления, архитектором и владельцем системы. Сверху добавилась роль Product Owner со своими разговорами, приоритетами и ответственностью. Все прежние люди по-прежнему могли прийти ко мне с прежними вопросами.
Дело было даже не всегда в длинном рабочем дне. Сильнее утомляло переключение. Только погрузился в архитектуру — нужно вернуться к бизнес-приоритетам. После непростого разговора с человеком уже ждёт техническая проблема. Ни одна из этих задач не выглядит лишней, но внимание у них общее. Моё.
На короткой дистанции это действительно работало. Контекста у меня было много, решения принимались быстро. Именно поэтому трудно было заметить, что удобство такой схемы оплачивается ресурсом одного человека.
Об этом опыте я не жалею. Он дал мне другой взгляд на продукт, знакомство с работой аналитиков и команду, где бизнес можно было спросить напрямую. Но заодно показал: интерес к новой роли ещё не означает, что под неё появились силы и место.
Я хотел стать Product Owner и начал им становиться. Только со старого стула так и не встал. Какое-то время удавалось устроиться на обоих, а потом оказалось, что к концу дня батарейка садится всё раньше — и за ночь уже не успевает зарядиться.
