Техническое безумие, или Как сдать проект вовремя, если планы меняются каждый месяц
Есть проекты, которые ни шатко ни валко реализуются годами, а есть такие, которые заставляют биться лбом о технологии и нервной системой о дедлайны. Наш относится ко вторым, о нем и хочу вам рассказать.
Полтора года назад часть команды EPAM взялась за новый продукт. Заказчик — из финансово-инвестиционной сферы. Достаточно далек от технической стороны разработки, но, как и у многих крупных клиентов, четкие пожелания к результату были.
Задача: разработать портал, который работает с финотчетностью крупных частных компаний, преимущественно выросших из стартапов. Сервис обрабатывает загруженные документы, выводит статистику, показатели работы и прогнозы эффективности компаний. Упорядоченные данные безопасно и конфиденциально улетают инвесторам. А сами инвесторы могут подписывать документы и проводить ряд других манипуляций.
Так это должно было выглядеть. Еще на старте мы поняли, что задача, мягко говоря, нетривиальная. Но то, что засада ждет нас на каждом шагу, выяснилось позже.
Каким будет продукт, предстояло решить нам
Работа над проектом началась в июне 2016 года. Заказчик показал свои идеи, иллюстрации и ориентировочный workflow. На первый взгляд всё было логично. Дьявол же прятался в деталях. Мы задавали массу вопросов: «Что должна делать эта фича? А вот эта? Как система отреагирует, если превысить лимит загрузки документов?». Ответов не было. Для клиента это был первый продукт и новый рынок частных компаний. Каким он будет, предстояло решить нам.
На первичные обсуждения ушел месяц. А в июле заказчик полностью поменял концепцию и принял новую стратегию выхода на рынок. Сроки, тем не менее, остались прежними — до конца года продуктовая команда должна была выдать MVP.
После такого финта мы поняли, что тихо проектировать архитектуру в сторонке и готовить инфраструктуру не получится, иначе разработка провалится.
Нужно было включаться в обсуждения, плотно контактировать с UX-дизайнерами, проговаривать идеи и совместно отбрасывать лишние.
Это помогло. В августе бизнес вернулся с новой идеей, но мы на 80% уже понимали процессы внутри компании-заказчика.
Параллельно команда работала над технологиями. И это было True Technical Madness. Платформа — одно из первых решений на .NET Core и AWS для заказчика. Он хотел построить его на базе новейших технологий: Angular 2.0, .NET Core 2.0, Amazon Cloud, Docker. Летом 2016 года часть из них действительно были новейшими и совершенно сырыми. Большинство — пререлизы и бета-версии — компилировалось плохо, вылезали незадокументированные результаты. А на стороне заказчика не было ни одного технаря. Поэтому нам самим пришлось «подружить» Amazon Cloud с .NET, который к тому же запускался на Linux-машинах. У кого ни спрашивали — почти никто не работал с большинством сервисов, которые мы учились использовать. И используем сейчас.
Выбросить все несрочное
К сентябрю выстроили архитектуру процессов, расставили приоритеты в разработке фич. А в октябре команда отправилась в Нью-Йорк представлять планы по разработке. Мы надеялись, что заказчик, увидев объем работ, перенесет релиз на весну 2017 года.
Надежды с грохотом разбились об американский берег. Для клиента проект был пилотным, и отчитаться за него надо было код из носу до конца года. Мы никак не успевали. Оставался один вариант:
Раз время стало критичнее функционала, значит, долой лишний функционал.
«Давайте упрощать первую версию портала и оставлять только ключевые инструменты», — предложили мы. Без вариантов.
Это было похоже на сброс мешков с песком с воздушного шара. Мы брали буквально каждую функцию из списка пожеланий и дотошно обсуждали ее с заказчиком. Нужно было определиться, без чего портал точно не заработает, а что, нужное «для красоты», подождет еще месяц-другой. Для клиента этот процесс был, скажем так, непростым. Но так мы выбросили из корзины всё несрочное. Например, вместо нескольких способов загрузки документа сделали один, фичу по перемещению документов выбросили вообще. «Приклейку» watermark сделали только для PDF-файла — просто чтобы обозначить, что эта функциональность в конечном приложении будет. Благодаря этому желанный MVP получил шанс на набор высоты.
Что делает сторонняя команда?
На этом приключения не кончились. Новое решение нужно было интегрировать с другими продуктами заказчика. А именно — портал с авторизацией, общей для всех сервисов, и систему, отвечающую за базу данных конечных пользователей. Этим занималась сторонняя команда. Хоть мы и знали о ней, но изначальное общение с теми разработчиками было на стороне клиента — и то, больше в плоскости бизнеса, чем технической. Каждый смотрел сквозь свои очки. В итоге поплыла реализация.
Мы впервые лично встретились со сторонней командой в Нью-Йорке спустя три месяца параллельных разработок. И оказалось, что все это время мы топали по разным дорогам.
Развилка случилась как раз тогда, когда заказчик несколько раз поменял концепт, а ребята из сторонней команды выпали из инфопотока.
Интеграция с нашим решением получила жирный знак вопроса. Хорошо, что хоть тогда у нас появилась возможность вести прямые переговоры и синхронизировать разработку.
Все дискуссии и обсуждения из области бизнеса мы перевели исключительно в техническую плоскость и перешли на общение контрактами. Четко формулировали требования исходя из мокапов для нашего приложения: «Для этого скрина нам нужен от вас сервис, который принимает АВС и отдает XYZ, а для этого — все то же самое, только чтобы работал, как google autocomplete search». На это ушло еще три недели офлайн-обсуждений, но ребята оперативно выдали нам то, что мы от них ожидали.
Собственно разработка и роль delivery manager
По возвращении в Украину мы, наконец, погрузились в собственно разработку. В статьях часто рассказывают про code style и лучшие практики, но когда до релиза два месяца, как-то не до этого.
В команде нас было шестеро. Каждый работал над своими заданиями. Задачи по infrastructure & server-side development распределялись между
После успешного MVP команда увеличилась до 9, а сейчас насчитывает 30 человек
Главная задача, которая стояла перед разработчиками, — решение должно работать и быть готовым к запуску в срок. Поэтому работа delivery manager на проекте была критичной. Во-первых, нужно было минимизировать количество блокеров, которые постоянно возникали. Это как внутренние зависимости между фичами и функционалом, который мы делали, так и зависимости от внешних команд заказчика и их партнеров. Важно было быстро разобраться, что конкретно нас останавливает или замедляет, и донести это максимально эффективно и быстро необходимому человеку. И во-вторых, постоянно направлять разработку.
MVP удалось завершить вовремя. В январе product owner уже провел презентацию менеджменту в Нью-Йорке. Продукт не был суперкрасивым и идеально удобным, но мог жить и выполнять задачи.
С тестового сервера в продакшн
Презентация прошла успешно. Это был переломный, но не последний момент. Дальше мы, скрестив пальцы и сцепив зубы, перенесли релиз с тестового сервера в продакшн. Февраль и март мы потратили на то, чтобы сделать систему более production-ready и готовой вынести нагрузки первых, хоть и немногочисленных пользователей. Нам предстояло саппортить первых пользователей в продакшене. Поэтому наши логи были нашими глазами, когда у клиента возникнут первые проблемы. Этот компонент мы старались тюнить по максимуму.
Особое внимание уделяли сохранению консистентности данных и конкурентной работе нескольких пользователей над одним ресурсом.
Мы понимали, что без кеширования получить хороший перформанс будет невозможно, поэтому добавили кеширование наиболее часто запрашиваемой и легко инвалидируемой информации. Увы, перевести тяжеловесные процессы на асинхронную модель выполнения получилось не сразу. Это нам аукнулось, когда появился пользователь, который превысил изначально планируемые NFR’ы в 10 (!) раз.
Первые продажи были уже в конце марта. У пользователей тут же появились запросы на новые фичи и аддоны. Всё это плюс-минус помещалось в выбранную нами картину развития продукта.
Кроме того, мы сами наблюдали, как пользователи находят узкие места, о которых мы говорили заказчику в начале — например, загрузка чрезмерного количества документов. Правда, теперь такие вещи мы успеваем быстро дорабатывать.
Уроки
Что хотелось бы сказать напоследок? Конечно, поделиться уроками, которые команда извлекла из этого проекта.
Чем проще архитектура, тем лучше
Изначально обращайте внимание на простоту ваших технических и архитектурных решений. Вам и так будет сложно с «сырыми» необкатанными технологиями, поэтому не переусердствуйте в архитектуре. Будьте готовы в один день приступить к ее значительному рефакторингу, потому что вышел новый RC вашего фреймворка, или новая, более стабильная версия уже не поддерживает концепции, на которые вы завязались. Такова цена использования новых и неопробованных технологий.
Определяйте приоритеты и фокусируйтесь на них
В таких проектах главная проблема — сроки. И если бы мы уперлись рогом в реализацию всех изначальных пожеланий заказчика, то его бы самого и подвели. Спасла жесткая приоритизация и фокус на работоспособном продукте. Для примера: только несколько недель назад, то есть больше чем через год (!) после обсуждения, мы добавили функционал, который клиент просил еще в MVP. Так что в критической ситуации всё нужно проговаривать до самых мелких мелочей.
Учитывайте специфику работы с нетехническими заказчиками
Клиент мыслит совершенно иными категориями. Сложнее всего завоевать его доверие и показать, что сам веришь в идею, которую предлагаешь. Наш рецепт? Проработать идею до деталей, четко видеть, как ее реализовать. Понимать, что именно в данный момент важно для заказчика, и показывать, что понимаете. А для этого — банально, но многие это упускают — переводить «технарское» на его язык. Особенно, когда нужно аргументировать то или иное техническое решение.
Проявляйте инициативу
И еще. Максимум инициативы — со стороны всей команды. По нашему опыту, если умыть руки и ждать в стороне, пока выкатят очередной концепт продукта, в итоге придется сделать двойную, а то и тройную работу. Лучше внедряться в коммуникацию на ранней стадии и выходить на принятие решений бок о бок с топ-менеджерами заказчика.
Именно эти уроки сыграли большую роль в том, что наш проект вообще состоялся. Для команды он стал примером того, как правильные бизнес-решения и четкий контроль delivery могут вывести даже из изначально безвыходной ситуации. Надеюсь, этот кейс поможет и вам не спасовать перед трудностями. Ведь с ними — только интереснее.
