Дано:
Корпоративное iOS-приложение, реализованное только под форм-фактор Apple iPad с устаревшим дизайном (особенно, если изучать гайдлайны Apple).
Заказчик = крупное российское полукоммерческое предприятие. Со стороны Заказчика участвуют 4 департамента (с одинаковым влиянием друг на друга), один из департаментов является функциональным заказчиком (ФЗ) и владельцем бюджета. Остальные отвечают за безопасность и ИТ-сопровождение.
Распределенная на 2 города команда со стороны Исполнителя, проблемы с коммуникациями отсутствуют.
Найти:
OS-приложение под iPhone с современным интерфейсом и доп. функционалом
Ограничения:
Заказчик на момент проекта никогда ранее не работал по Agile-методологиям, но их руководство на основе последних трендов повсеместно пыталось запустить использование Agile;
Договорные отношения между Заказчиком и нами были FixedPrice (оформить T&M было невозможно).
Решение:
При инициации проекта между Заказчиком и нами была достигнута договоренность, что все готовы работать в рамках Agile, но с фиксированным скоупом, который был четко ограничен рамками договора. Для удержания скоупа (по лучшим практикам agile) по каждой фичи озвучили условные эстимейты, расставили приоритеты и договорились «на берегу», что при возникновении исключений и увеличении скоупа просто обменяем часть требований на другую. В рамках существующих договоренностей и оценок также предполагалось переиспользовать существующее приложение, в котором были реализованы необходимые бизнес-процессы.
Разработка продукта происходила, как и положено, итерациями. Каждая итерация составляла 2 недели: формирование скоупа -> разработка -> тестирование -> демонстрации -> фиксирование замечаний -> формирование скоупа -> …
В итоге количество промежуточных поставок составило 18 штук, учтены были все основные пожелания стейкхолдеров и реализован весь необходимый набор требований, последняя поставка была признана релизом с обеих сторон. Приемо-сдаточные испытания (которые из-за бюрократии Заказчика и договора FixedPrice даже в рамках используемого гибкого подхода отменить невозможно) были пройдены без критичных и условно-критичных замечаний с первого раза.
Что было неизменно (для отношений Заказчик-Исполнитель):
Постоянное давление статусом Заказчика и уровнем важности его конечных целевых пользователей.
Растущие аппетиты Заказчика и «жонглирование» требований между 4 заинтересованными департаментами. Например, в ходе разработки продукта появилось требование использования библиотек корпоративной MDM-системы для сохранения конфиденциальности данных внутри приложения. Как итог: из-за внутренних противоречий Заказчика было разработано 2 сборки (с поддержкой MDM и без), первый год после внедрения в пром 99% пользователей использовали принципиально версию без MDM-системы все из-за тех же внутренних противоречий между департаментами.
Немного графиков со статистикой растущих аппетитов (цифры про трудоемкости и длительности опущены на графиках из-за NDA компании с Заказчиком):
Почему Agile не помог
В рамках каждой итерации готовились кликабельные макеты приложения, которые детально согласовывали со стейкхолдерами Заказчика (как и учит Agile). Заказчик со своей стороны собрал пилотную группу из будущих пользователей около 10 человек (в которую также входили лица, принимающие решение «наверху») для апробации будущего продукта. Согласованные макеты превращались в приложение, и каждый выпуск промежуточной законченной версии продукта позволял пилотной группе «пощупать» и дать свой фидбек. Все замечания обрабатывались, обсуждались, оценивались, после обсуждения и согласования адекватные замечания исправлялись в следующих итерациях. Все как в лучших практиках.
НО…
Как писала выше, после использования лучших практик успешно прошли приемо-сдаточные испытание, начали тиражировать приложение в промышленную эксплуатацию. Во время тиража приложение получил руководитель департамента ФЗ, начал использовать, а мы радостно и весело стали переписывать половину интерфейса приложения, так как гайдлайны Apple ничего не понимают о дизайне корпоративных приложений, и нужно было срочно сделать устаревшие формы экранов из iPad на iPhone.
Выводы или зачем нужна эта статья
Казалось бы, все просто: методологии Agile в своих принципах нацелены на минимизацию рисков путем сведения разработки к серии итераций и постоянному тесному контакту со стейкхолдерами. Не согласовали дизайн приложения и свои многочисленные макеты со всеми заинтересованными стейкхолдерами – сами виноваты, у вас было 18 поставок, чтобы спросить ключевого пользователя, что не так.
А еще одно из главных достоинств Agile – это отсутствие бюрократии. Только российская действительность и некоторые полукоммерческие предприятия, даже с внедренным у себя Agile, не готовы отказаться от бюрократии и жесткой иерархии в своих структурах, а большие начальники порой не готовы участвовать в проектной работе. Проектные команды могут сколько угодно формировать списки стейкхолдеров, проводить демонстрации и соблюдать все принципы гибких методологий, но не смогут избежать рисков того, что по итогу продукт придется переделывать. А как работать с рисками недоступности стейкхолдеров, да и в принципе как работать с рисками методологии Agile не учат. Потому что это про продукт, а не про риски при его выпуске.
Собственно, возникшую проблему после опытной эксплуатации продукта решали другими методологиями, где подробно рассматривается управления рисками. И как учит туториал Хабра: «Неуспешные кейсы тоже полезны, они помогут кому-то не наступать на грабли, на которые другие уже наступали». Не скажу, что мой кейс неуспешен, сотрудники Заказчика пользуются продуктом уже несколько лет, в рамках проекта были достигнуты почти все поставленные цели. Но мой кейс – один из примеров, когда нельзя забывать о стратегиях управления рисками в угоду пропаганде повсеместного использования Agile.
