Final countdown. DevOps Stage 2018. Book your ticket today.
×Закрыть

Техническое безумие, или Как сдать проект вовремя, если планы меняются каждый месяц

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

Полтора года назад часть команды 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 распределялись между 4-мя .NET developer’ами. Client-side development и верстку взяли на себя front-end developer’ы. Работали в режиме конвейера: кто первый закончил задачу, тот берет следующую в очереди.

После успешного MVP команда увеличилась до 9, а сейчас насчитывает 30 человек

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

MVP удалось завершить вовремя. В январе product owner уже провел презентацию менеджменту в Нью-Йорке. Продукт не был суперкрасивым и идеально удобным, но мог жить и выполнять задачи.

С тестового сервера в продакшн

Презентация прошла успешно. Это был переломный, но не последний момент. Дальше мы, скрестив пальцы и сцепив зубы, перенесли релиз с тестового сервера в продакшн. Февраль и март мы потратили на то, чтобы сделать систему более production-ready и готовой вынести нагрузки первых, хоть и немногочисленных пользователей. Нам предстояло саппортить первых пользователей в продакшене. Поэтому наши логи были нашими глазами, когда у клиента возникнут первые проблемы. Этот компонент мы старались тюнить по максимуму.

Особое внимание уделяли сохранению консистентности данных и конкурентной работе нескольких пользователей над одним ресурсом.

Мы понимали, что без кеширования получить хороший перформанс будет невозможно, поэтому добавили кеширование наиболее часто запрашиваемой и легко инвалидируемой информации. Увы, перевести тяжеловесные процессы на асинхронную модель выполнения получилось не сразу. Это нам аукнулось, когда появился пользователь, который превысил изначально планируемые NFR’ы в 10 (!) раз.

Первые продажи были уже в конце марта. У пользователей тут же появились запросы на новые фичи и аддоны. Всё это плюс-минус помещалось в выбранную нами картину развития продукта.

Кроме того, мы сами наблюдали, как пользователи находят узкие места, о которых мы говорили заказчику в начале — например, загрузка чрезмерного количества документов. Правда, теперь такие вещи мы успеваем быстро дорабатывать.

Уроки

Что хотелось бы сказать напоследок? Конечно, поделиться уроками, которые команда извлекла из этого проекта.

Чем проще архитектура, тем лучше
Изначально обращайте внимание на простоту ваших технических и архитектурных решений. Вам и так будет сложно с «сырыми» необкатанными технологиями, поэтому не переусердствуйте в архитектуре. Будьте готовы в один день приступить к ее значительному рефакторингу, потому что вышел новый RC вашего фреймворка, или новая, более стабильная версия уже не поддерживает концепции, на которые вы завязались. Такова цена использования новых и неопробованных технологий.

Определяйте приоритеты и фокусируйтесь на них
В таких проектах главная проблема — сроки. И если бы мы уперлись рогом в реализацию всех изначальных пожеланий заказчика, то его бы самого и подвели. Спасла жесткая приоритизация и фокус на работоспособном продукте. Для примера: только несколько недель назад, то есть больше чем через год (!) после обсуждения, мы добавили функционал, который клиент просил еще в MVP. Так что в критической ситуации всё нужно проговаривать до самых мелких мелочей.

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

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


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

LinkedIn

28 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

А мені от цікаво — за якими критеріями обирались технології замовником, якщо в них не було зовсім технарів?

А почему AWS и .NET Core ? Не проще ли было все на Azure построить ?

AWS был выбран в качестве cloud provider глобально на уровне организации клиента в рамках программы перехода в клауд. Мы оказались как раз первым проектом которому пришлось работать согласно этой новой программы.

В этой статтье есть недомолвка — Заказчик представляется прямо таким себе розовым прекрасным пони, что хоть к ране прикладывай. И время на обсуждения есть, и на урезание скоупа согласился. Прямо клиент-мечта.

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

Well done, then! Берегите такого клиента!

Любой адекватный клиент, который выбрал fix time и fix price приоритеты на MVP пойдет на флексинг скоупа — это же старо как мир. Чем этот заказчик так особенен, не понятно.

Более того — поменял бизнес-стартегию после вроде-бы устаканивания исходной, по описанию явно не мог дать нормальную обратную связь по многим аспектам бизнес-функционала проекта и своего видения. Я в своей работе встречал куда более комфортных оунеров, у которых, что называется, все схвачено и на большиство вопросов есть четкие ответы. (конечно, они были более технически/инженерно подкованы:))

в последнее время Епам начал радовать отличными статьями-историями из жизни реализованых проектов, это отличный и очень интересный вариант пиара, больше больше таких статей!
спс

Хорошая статья. В очередной раз убеждаюсь что Delivery и Project Manager по сути занимаются одним и тем же.

Можно вопрос на засыпку: сколько часов овертайм было отработано?

... и сколько оплачено по рейту > x1

Хороший вопрос, но как не удивительно, не много, пару дней, накануне демо.

Это нам аукнулось, когда появился пользователь, который превысил изначально планируемые NFR’ы в 10 (!) раз.

Дуже цікаво, можна конкретний приклад, що саме було заплановано, та як ви дізналися про перевищення конкретним користувачем запланованих NFR ? Response time ? Emotional factors ? Throughput ? На які саме метрики ви орієнтувалися ?

Кількість документів, на які планувалось давати доступ юзерам в рамках однієї компанії. Дізналися частково за допомогою метрик response time, які отримували з ALB, частково від акаунт менеджерів. Проактивно відреагувати, на жаль, не вийшло, оскільки це був перший кейс, однак досвід був повчальний, як для нас так і для клієнта, в плані сапорта такого роду юзерів.

Очень похоже по описанию на xero.com

Мені здається, xero.com побудований на Adobe Experience Manager та Java

тоесть это не работа epam, и задача по сути выполнена проще и дешевле?

Какой у них охренительный баннер на главной. Белый текст на белом — это волшебно :)

что задача, мягко говоря, нетривиальная.

cs8.pikabu.ru/...​/6/145673352818127463.jpg

Ну че скзать? Красавчики, смертельный марш прошли, правильные выводы сделали.

Очередное подтверждение, что писать код психологически комфортней, чем работать с людьми.

смотря, какой код и какие люди.
К.О.

Какой код бы ни был — это просто команды, которые только лишь исполняют инструкции программиста и в целом полностью под твоим контролем. Есть ты, есть редактор и вперёд. Психологически всегда проще просто быть 1 на 1 с компьютером, он всего лишь машина и (если железо не сломано) всегда буде делать то, что от него требуется.

А работа с людьми это песня отдельная. Заказчики есть разные, команды бывают разные, разный workflow, сам программист может быть интровертом и т.д.

В случае статьи еще повезло действительно, что заказчик оказался адекватным, количество боли коммуникации и определения задач было сведено к минимуму. Ну и менеджер справился со своей работой отлично. А ведь всё могло закончиться совсем по-другому.

В данном случае, похоже, заказчик предельно адекватный. Во всяком случае, о популярных историях вроде «изменения в функционале незначительные, ваша негибкая архитектура — ваши проблемы», «команда плохо работает, ниже наших ожиданий, так что овертаймьте за свой счёт», и прочая в рассказе ничего нет

Нужно было включаться в обсуждения, плотно контактировать с UX-дизайнерами, проговаривать идеи и совместно отбрасывать лишние.

Вы это только спустя месяц поняли? О_о

Как сдать проект вовремя, если планы меняются каждый месяц

В статье я нашёл только 2 упоминания об изменениях концепта за полгода.
Кстати, абсолютно непонятно что это были за изменения концептов: насколько они были серьёзными и как повлияли на разработку.

Изменения были на уровне стратегий развития бизнесса и конкретных продуктов, с которыми планировался выход на рынок. Для разработки это был разворот на 180 градусов.

Очень странно, что при таких изменениях не пересматриваются сроки.

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

Подписаться на комментарии