Все неуспешные проекты похожи: как мы не соблюдали базовые принципы Agilе и к чему это привело

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

Почему так происходит?

Основная причина в том, что заказчик не хочет учиться гибкости, а подрядчик не хочет учить заказчика. Ведь учиться означает меняться, а учить означает управлять изменениями. Ну, как в мемчике:

«Кто хочет перемен/измениться/возглавить перемены?»

К чему приводит нарушение базовых Agile-принципов?

Давайте разберем каждый из 12 принципов Agile-манифеста и примерные сценарии нарушения этих принципов.

Принцип №1

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

Нарушений этого принципа может быть множество:

1. Поставляемый софт не удовлетворяет потребности заказчика — основная причина в том, что нет частого и основанного на данных фидбека. Если вы не идете вперед путем эмпиризма, если не проводите частые и быстрые эксперименты, на которых основываете решения, очень быстро вы зайдете в этот тупик.
2. Софт поставляется нерегулярно — почти всегда это проблема легаси-кода, технического долга и рисков. Заказчик пушит контрактора двигаться быстрее. Фичи, фичи, фичи… Нет времени объяснять. Контрактор не объясняет заказчику, что если игнорировать техническое состояние проекта и не уделять время архитектуре, юнит-тестам, обновлению систем, невозможно будет поддерживать темпы поставки бесконечно. Они будут падать, пока не зайдут в полнейший тупик.
3. Скорость поставки софта низкая — смотрите пункт 2. Кроме того, проблема может быть в том, что комания-разработчик все делает вручную: тестирует, деплоит, мониторит, обновляет данные базы. Автоматизация — ключ к быстрой поставке в долгосрочной перспективе.
4. Софт не несет ценности заказчику. Это самый частый фейл в ценности — неправильное понимание ценности контрактором. Заказчик объясняет, что хочет с точки зрения бизнеса. Контрактор утилитарно исполняет пожелания не вдумываясь в то, как лучше их исполнить. В результате то, что заказчик мог бы делать легко и приятно, делается сложно и муторно. Вроде цель достигнута, но имплементация оставляет желать лучшего.

История из моей жизни

Стартует один из проектов, на котором я работаю проектным менеджером. Приходит ко мне заказчик и говорит: «У меня есть база данных — сотни тысяч компаний с 25 параметрами для каждой. Я хочу создать визуальный интерфейс, для того чтобы сортировать эти компании по тому, как мне удобно, и выгружать сортировки в Excel».

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

Иду к клиенту. Говорю, так работать не будет, давайте сделаем предварительную выборку прямо в базе. Они для того и придуманы, чтобы быстро оперировать сотнями тысяч записей. Давайте отберем сразу то, что нам нужно и потом уже выведем на экран для последующей обработки.

Ответ заказчика: нет. Я — бизнесмен, ты — дурак. Делай, как я говорю.

«Мне надо все видеть, всю картину на одном экране. Я плачу деньги, идите и делайте», — говорит он. Тогда я еще не мог отказать клиенту так, как могу сейчас. Пошли делать.

Через месяц выкатили клиенту первую версию. Клиент посмотрел. Ответ его был нецензурным. Страница грузилась около 10 минут. Выбрать какую-то часть компаний на странице физически не представлялось возможным. Клиент начал пытаться за меня решить проблему скорости: «Пойдите купите сервер помощнее, мне надо, чтобы быстро работало». Я пытался клиенту объяснить, что сервер помощнее не поможет. У него отрисовывается таблица из 40 000 позиций в браузере на одной странице, без пагинации порядковой нумерации страниц, которая в основном размещается вверху либо внизу страниц сайта. Его ноутбук это не тянет.

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

Мораль: контрактор не должен идти на поводу у клиента, если не хочет проект полный боли и страданий.

Принцип №2

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

Этот принцип вырос из желания клиента (не бизнес-аналитиков, которые представляют клиента), а из желания людей, реально управляющих бизнесом — они хотят быстро реагировать на изменения окружающей среды. Вырос этот вопрос из проблем вотерфольной модели, которая все чаще дает сбои в комплексной среде мобильной разработки, где важна скорость (time to delivery) и гибкость, о чем, собственно, весь Agile.

Вот как выглядит каскадная модель разработки софта:

Каскадная модель разработки софта / Иллюстрация Евгения Мусиенко

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

• софт уже неактуален;
• конкуренты успели быстрее;
• софт не решает проблему;
• вообще непонятно, что это такое, я заказывал другое;
• не хватает многих фич, без которых софт бесполезен;
• все нужно переделать;
Онлайн-курс "Створення текстів" від Skvot.
Великий практичний курс для розвитку скілів письма та створення історій, які хочеться перечитувати Результат курсу — портфоліо з 9 робіт та готовність братися за тексти будь-яких форматів.
Детальніше про курс
• …

Чем же Agile помогает на примере озвученного принципа?

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

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

Моя любимая иллюстрация Хенрика Книберга коуч, игровой разработчик и автор книг «Scrum и XP: заметки с передовой», «Scrum и Kanban: выжимаем максимум», «Lean from the Trenches», а также в вирусных видеороликов Agile Product Owners in a Nutshell и Spotify Engineering Culture как раз о том, каким именно путем мы можем быть неправы чаще. Не делайте сразу Феррари, начните со скейтборда:

Иллюстрация Хенрика Книберга

История из моей жизни

Делаем новую суперкрутую фичу для мессенджера. Хотим победить в стране, далекой от демократии, с очень жесткой цензурой, запустив фичу по обходу всех блокировок. Фича сложная, никто такого не делал, на StackOverflow не скачаешь похожее, и вебинар тоже посмотреть сложно. Работает или нет — кто его знает, как проверить. Надо ехать в ту страну и нарушать закон, пытаясь использовать что-то большее, чем 10 публично доступных сайтов.

Ну, короче, бизнес-идея понятна, погнали! Продумали методы, какими будем обходить, выбрали самый простой в исполнении, приступили к работе. Запланировались на три месяца. Работаем. Где-то ко второму месяцу выходит пост от Telegram — одного из наших основных конкурентов — полностью соответствующий духу Дурова. Ребята пишут: попробовали обойти блокировки в странах с цензурой, применили 10 методов. Нифига не сработало за исключением длиннющего списка прокси-серверов и тупого перебора этих самых прокси. Ну, что-то вроде того, что работало (может и сейчас работает) в России и с чем ребята из Роскомнадзора так и не смогли толком справиться.

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

Запилили. Запустились, продержались один день, скачивания росли как на дрожжах. Ну и практически сразу нас заблочили.

Мораль: если вы пилите софт, но ситуация на рынке изменилась, не надо держаться за каждую фичу как за детище, «кровиночку», которую надо защищать любой ценой. Переприоретизировали, записали lessons learned и перешли к более приоритетным фичам, а эту поставили на полку, раз не работает, или переделали требования так, чтоб работало.

Принцип №3

Работающий продукт следует выпускать как можно чаще — с периодичностью от пары недель до пары месяцев.

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

История из моей жизни

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

Задача была крайне сложная. Оценили работу в три месяца для двух бэкенд-девелоперов. Делали ее 1,5 года.

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

Делали задачу на отдельной ветке. Когда сделали и попытались интегрировать — поняли, что за это время внесли множество изменений в проект и при добавлении кода кластеризации мы получаем столько проблем, что только видимые нам чинить около полугода. Это был полный провал. И это мы узнали не за один день. Встреча со спонсором проекта, где обсуждали результаты этой задачи, дал мне больше опыта проектного управления, чем полгода работы на небольшом проекте. И матов там было много.

Задачу положили на полку, скорее всего, так там и лежит.

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

Принцип №4

На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

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

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

История из моей жизни

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

Начинаем выяснять требования. Требования нам объясняет сам депутат. Готовим SoW statement of work — техническое задание, начинаем работать. Показываем клиенту скетчи дизайна — вроде нормально. Через три недели показываем готовый дизайн — вроде пока все хорошо. Еще через месяц я заканчиваю разработку и сайт готов. Показываем клиенту — все не то. Надо поменять прямо реально все.

Начинаем выяснять, оказывается, что жена посмотрела и с ее точки зрения сайт не отражает всю ту элитность, которой прямо пронизана эта клиника. Боль, которую испытал PM (да и все прочие) на встрече, где клиент объясняет, что 1,5 месяца работы в fixed-bid-проекте нужно выкинуть и переделать, просто не передать словами.

Мораль: если бы мы начали с какого-то Proof of Concept и сделали сначала просто работающий прототипчик без раздела новостей, без раздела галереи, просто главная и одна страница услуги, например, потом показали, мы бы получили ту же самую обратную связь на полтора месяца раньше и не пришли бы к ситуации, когда полтора месяца работы было потрачено впустую.

Про остальные восемь Agile-принципов читайте скоро на Highload.

Читайте также: В Древнем Египте нервно посмеялись бы: почему по Scrum разрабатывают софт, но не строят ракеты и даже автомобили