Обязательства с высокими требованиями

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

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

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

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

Так что же делать?

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

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

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

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

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

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