После публикации интервью Асхата Уразбаева «Scrum: революция в проектном менеджменте. Следуйте смыслу, а не плану» у участников Сообщества Executive.ru возникли вопросы о сущности гибкой методологии. Я хочу рассказать о несложном кейсе из практики компании ScrumTrek, после которого, надеюсь, многое прояснится.
Этот проект был выполнен где-то год назад. Он длился примерно восемь месяцев. Мы реализовывали его для заказчика из банковского сектора. В этом банке назрела потребность переделать одну из своих подсистем, отвечавших за взаимодействие с клиентами.
Информационная система, которой пользовался банк, не отражала его потребности. Она была сделана некоторое время назад и предполагала, что клиенты банка – физические лица – будут выполнять те или иные операции самостоятельно, без обращения к операционисту. Если клиент не мог выполнить операции и обращался к сотруднику банка, это рассматривалось как отрицательный результат. Банк хотел исправить ситуацию, снизить нагрузку на штат и сократить некоторое количество рабочих мест. Наверное, с точки зрения управления людьми эта цель была не очень… экологичная, но от подобной ситуации уйти невозможно: автоматизация деятельности очень часто приводит к сокращению рабочих мест.
Проект был оценен и должен был быть выполнен в течение 9 месяцев. Оценка проводилась привычным для банка методом и планировалось делать проект по каскадной модели.
Практика банка показывала, что проекты очень часто затягиваются и затягиваются достаточно сильно, иногда и в два раза от первоначальной оценки. Руководство было недовольно этим фактом, поэтому решило попробовать реализовать этот проект с использованием Scrum, и нас привлекли для помощи с организацией Agile-процесса.
Мы собрали команду всех необходимых для реализации проекта специалистов из сотрудников банка. Размер команды был в рамках требований Scrum. Всех людей пересадили в один офис, рядом друг с другом. Прежде они никогда не работали в такой тесной коммуникации. Только один участник проекта работал в удаленном доступе, но у него был небольшой фронт работы. Этот сотрудник тем не менее участвовал во всех рабочих встречах.
Роль нашей компании состояла во внешнем консультировании. Мы помогли команде выполнить все необходимые процедуры, обучили их Scrum, помогли провести стартовать производственный процесс и несколько месяцев сопровождали работу команды.
Нулевой спринт был посвящен формулировке базовых знаний по проекту.
Команда, как это обычно бывает, прошла все стадии роста. В начале команда не очень понимала, как именно предстоит работать. Постепенно команда входила в роль, и на третьем-четвертом спринте вступила в этап шторма, то есть начала создавать и преодолевать конфликтные ситуации – это тоже было ожидаемо. Поскольку команде удалось преодолеть противоречия, к четвертому спринту она подготовила продуктивную среду и готовое описание функционала.
Поскольку команда двигалась в соответствии со Story mapping, она старалась как можно быстрее реализовать функционал для конечного пользователя, хотя бы и в минимальном объеме. Начиная с четвертого спринта продукт с ограниченным функционалом был выведен в прод, и здесь начинается самое интересное: команда начала получать обратную связь от пользователей.
В нашем случае заказчик и пользователь – не одно и то же. Заказчик – подразделение банка, которое может поделиться своим видением проекта, а пользователь – клиент банка, у пользователя может быть свое видение, предугадать которое очень трудно. Поэтому те кусочки функционала, которые были готовы на четвертом спринте, команда решила показать именно конечному пользователю.
Этого конечного пользователя команда решила найти в лице самих сотрудников банка. Им отправили письмо примерно такого содержания: «Коллеги, мы разрабатываем такую-то систему, мы пытаемся сделать ее максимально удобной и правильной. С сегодняшнего дня вы переводитесь на обслуживание этой системы, и если вы видите какие-то проблемы или хотите улучшить наш продукт – вот вам все координаты для обратной связи». В ответ на это письмо пошли сигналы обратной связи. Мы начали вносить изменения в журнал продукта, в котором фиксировались заявки на разработку новых функций. Таким образом продукт пришел в движение.
В итоге через девять месяцев мы получили весь функционал, который был нужен заказчику, и который был заложен в проект. Но функционал этот был реализован с учетом требований конечного пользователя, вот в чем особенность.
Мы могли строго следовать ТЗ, которое получили от заказчика, и выдать ему в срок точно то, что он заказывал (так обычно и реализуются проекты, построенные по каскадной модели разработки). Однако это был бы совершенно иной продукт. После того, как он был бы принят в эксплуатацию, его пришлось бы дорабатывать в соответствии с требованиями конечного пользователя. Так обычно и происходит: доработка превращается в самостоятельный проект, который требует ресурсов.
Мы же включили требования конечного пользователя на раннем этапе разработки. При этом, приступая к проекту, мы эти требования еще не представляли. В этом и есть пример применения гибких методологий управления производственными процессами: как можно раньше показать реальному пользователю продукт и наладить цикл обратной связи, чтобы постоянно корректировать продукт к потребностям конечных пользователей.
Очень важно – на каком этапе в проект вносятся изменения. Если изменение влияет только на какую-то презентационную часть, например, на веб-приложение, это одна ситуация. В данном случае объем доработок может быть не очень велик.
Совершенно иное дело, если изменение функционала влияет на архитектуру. В этом случае стоимость внесения изменений очень велика.
Разница между Scrum и Waterfall в том, что Scrum позволяет эти изменения вносить на раннем этапе. Смысл именно в этом. Понятно, что возможности гибких методологий не исчерпываются исключительно теми приемами, о которых я рассказал.
Увы, но там была "задачка" на 15-20 разработчиков. И я еще раз хочу отметить, если неверная гипотеза продукта, то вас не спасет платформа, даже наоборот, выбирая и осваивая платформу вы легко можете упустить окно рыночных возможностей и вообще не выйти в прод. Для примера, есть хорошая BPM платформа Pega и дофига продуктов, которые на ней были сделаны и нифига не решали проблем.
У меня есть ощущение, что мы исчерпали возможности общения в комментариях и чтобы лучше понять друг друга нужно переходить к устному общению. Если жизнь нас сведет на каком нибудь мероприятии (а тут шанс высок), предлагаю там продолжить дискуссию.