Иногда мне кажется, что шутки о том, что руководство внедряет Agile, чтобы успеть больше при меньших затратах, не так уж и далеки от истины. Я редко видел, чтобы команды разработчиков понимали Agile как что-то большее, чем просто набор церемоний, чаще всего ассоциируемых со Scrum.
Проекты связаны с ограничениями. Три фундаментальных из них это сроки, стоимость и содержание.
Немного подробнее про "треугольник компромиссов"
Связку этих ограничений — сроков, стоимости и содержания — называют треугольником компромиссов. Где-то его даже называют инструментом. Я бы предложил относиться к нему как к иллюстрации зависимости между этими тремя ограничениями.
Представьте, что вы можете тянуть за углы треугольника, но изменение одного угла неизбежно влечет за собой изменения в остальных двух. Если мы хотим сделать больше работы (содержание) за меньшее время (сроки), это, скорее всего, приведет к увеличению стоимости. Если мы стремимся сократить стоимость, то либо сроки увеличатся, либо объем работы придется уменьшить. Это постоянная борьба и балансировка, с которой сталкиваются все команды и менеджеры проектов.
Проект, у которого есть шанс на успех, начинается с фиксации одного ограничения, например, бюджета. Затем, исходя из бюджета, рассчитывается и фиксируется срок, и, в случае необходимости, корректируется объем функционала.
Бизнес часто готов докинуть ресурсов, людей в команду, чтобы сократить сроки. Только сделать это бывает очень сложно и не всегда возможно. В лучшем случае срок останется прежним, а может и увеличится.
Экономия на качестве – это тоже не про Agile. Обычно, говоря о качестве, многие понимают баги или дефекты. Но есть техническое качество, которое выражается в том, насколько продуктивно команда сможет работать над задачами в будущем. Чем хуже внутреннее качество, тем больше времени команда тратит на добавление нового функционала. Если техническое качество высокое, то на короткой дистанции можно взять у продукта в “долг”. Главное помнить, что это в будущем будет стоить бизнесу сокращением производительности команды. А ещё, вернуть технический долг потом будет дороже, чем сделать без "долга" сразу. Технический долг можно воспринимать как кредит в банке: возвращать придётся больше, чем взял. Поэтому важно понимать зачем это делается и откуда потом этот “долг” будет “оплачен” (рекомендую почитать статью о том, что технический долг, это не только проблема команды разработки). Если этим подходом пользоваться бездумно, то ситуация будет не лучше, чем когда люди берут кредиты, чтобы покрыть кредиты, которые были взяты, чтобы покрыть кредиты. В конце продукт будет ждать техническое банкротство.
Тем не менее, компании стремятся к оптимизации. Они хотят больше функционала и быстрее. Поэтому кто-то отправляет сотрудников на курсы и тренинги, а при наличии средств нанимает коуча из консалтинговой компании. В то же время, действительно продвинутая внешняя консалтинговая организация не гарантирует результат, а обещает двигаться итеративно. С возможностью завершить сотрудничество оплатив последний этап. По сути, вы покупаете время без гарантии результата. Они понимают, что продают стандартизированный процесс, который без изменения мышления ключевых руководителей, команды, ценностей компании и бизнеса не принесет ожидаемых результатов. Они расскажут, как все круто и легко, но не упомянут, что это не главное. Точнее упомянут, чтобы потом сказать, "Ну мы же говорили, вы сами виноваты!"
Но свою работу они сделают: введут короткие спринты, установят регулярные стендапы, на которых каждый строго рассказывает, что сделал, что планирует сделать и с какими проблемами столкнулся. Запланируют даты демонстраций, ревью спринтов, рефайнмент бэклога и другие модные артефакты. Однако, менеджмент вряд ли прислушается к рекомендациям консультантов меняться самим. Ведь проблема не в них, а в команде. Верно? Конечно, будет наведена некоторая прозрачность в процессах, что тоже неплохо. Но в целом, руководство не останется недовольным результатами команды, и, не видя других вариантов, будут вынуждены мириться с существующим положением вещей. Как только они наиграются в Agile и ослабят контроль над процессом, в команде появится "Agile собственного приготовления".
Так где же та магия "делать больше за меньше"? Её нет. Можно управлять содержанием работ. Но бизнес не согласится. Потому что, когда уже заранее кто-то продумал как делать и спустил это в команду разработки в виде набора спецификаций с декомпозицией на user stories, всякое управление содержанием воспринимается как просто отказ от выполнения тех или иных элементов бэклога.
Бизнесу кажется, что ему нужно всё. На самом деле это не так, но ему кажется что нужно.
В продукте была разработана небольшая функция выбора региона. Она прошла через разработку автоматических тестов, было приемочное тестирование. Выпустили и были довольны. Однако, когда проанализировали телеметрию, выяснилось, что за год функцию выбора региона использовали только тестировщики. Пользователям она была не нужна, хотя изначально функция считалась необходимой для выпуска самой первой версии продукта.
При таком подходе разработчикам предоставляется свобода выбора, но только в рамках деталей реализации. Например, они могут решить, сделать ли простое всплывающее окно с текстом об ошибки или добавить к нему дополнительные свистелки и что-нибудь еще. Затем, следуя принципам Agile, команда совместно приходит к выводу, что достаточно будет стандартного сообщения. Создается впечатление, что решение принято всеми вместе – вот он, Agile в действии! Однако, Владелец Продукта изначально склонялся к более простому варианту, который потребует меньше времени. Но поскольку коуч настаивает на Agile, была предложена "гибкость", чтобы он не мешал работать.
Если же команда разработки предлагала вариант автоматической обработки ошибки вместо сообщения, Владелец Продукта начинал согласование изменений со своим руководством и другими заинтересованными сторонами. И поскольку Agile-коуч требовал не определять заранее требования, а обсуждать их с командой, он просто не делился заранее подписанными и прибитыми к стенке гвоздями требованиями.
Когда в компании произошли организационные изменения, поддержанные CEO, которые предоставили команде и владельцу продукта реальное право решать как будет выполнена та или иная задача, процессы стали более гибкими, и работа наладилась. Это позволило владельцу продукта полностью реализовать свой потенциал в новых условиях, где структура и подходы компании стали способствовать более эффективной работе.
Бизнес будет хотеть видеть реализацию как можно быстрее. Но если кто-то влиятельный держит содержание жёстким, разработчики более или менее поддерживают качество на приемлемом уровне и не увеличивают технический долг, то страдают именно сроки (вместе со стоимостью). Работа идёт своим чередом, разработчики прилагают усилия, но не успевают.
Ну не придумали, как поменять этот треугольник компромиссов и создать какую-то червоточину, чтобы обойти эти ограничения.
Начнём с того, что, как мы обсудили ранее, очень сложно что-то менять, если у представителей бизнеса мышление в формате водопада. Оно интуитивно проще, понятнее, привычнее. Иногда по-другому и не сделаешь, например, когда приходится аутсорсить разработку (на самом деле это не всегда так, но допустим). Но если есть возможность, то скорректировать содержание можно, не отказываясь от функционала, а пересматривая идеи и подходы к решению. Одну и ту же проблему можно решить множеством способов. Когда разработчики вовлечены в обсуждение решения проблемы и понимают, какую пользу они хотят принести пользователю, шансы на нахождение неожиданного и эффективного решения возрастают. Таким образом, проблема будет решена, и сроки будут сэкономлены.
Программисты (хорошие программисты) по своей сути ленивы и, если найдут простое решение проблемы, будут только рады его предложить.
Продавцам было необходимо видеть в CRM контактные данные потенциальных клиентов, которые можно было найти во внешней системе. Команде разработчиков была поставлена задача доработать CRM для синхронизации данных из этой системы. Однако, после общения с продавцами и понимания их реальных потребностей, команда решила отказаться от первоначально предложенного плана и разработала расширение для Google Chrome. Это расширение позволяло автоматически отображать необходимые данные прямо в формах CRM без манипуляции с данными, упрощая процесс и сокращая время на разработку в несколько раз.
Итак, чтобы внедрение Agile/Scrum не превратилось в водопад с частыми итерациями, необходимо вовлечь команду в решение проблем бизнеса. Следует исключить из должностной инструкции владельца продукта пункт о необходимости согласования требований с заинтересованными сторонами и предоставить ему полномочия для самостоятельного согласования этих требований на основе диалога с командой. Для бизнеса, не так важно, как будет решена та или иная проблема. Бизнес существует благодаря решению проблем, которые либо приносят доход, либо сокращают расходы. Задача – решить проблему максимально экономично, чтобы решение приносило значительно больше денег, чем зарплата команды и прочие расходы на ее содержание. Желательно, в несколько раз.
Если требования согласовываются до того, как команда разработки о них узнает, то это точно не Agile. В этом нет ничего плохого; важно просто правильно относиться к данной ситуации и не создавать неверные ожидания. Короткие итерации сами по себе не делают команду Agile. Если требования определены заранее, не удивляйтесь, что один спринт уходит на проработку фичи, затем три спринта – на разработку, после чего следует фаза стабилизации и тестирования. И, конечно же, даже в эти рамки не удается попадать.
