Отступать от своих правил — нелогично и довольно больно. Как мы решили не работать по спринтам на одном проекте

Это было, может и не прекрасное, но вполне неплохое летнее утро, когда наша менеджер проектов Настя узнала о новом заказчике:

– К нам приходят ребята из SubU, сервиса подписок. Им надо допилить приложение – для iOS и Andriod. Там, в принципе, не так много – мы с ними уже работали как субподрядчик, а теперь они к нам напрямую пришли закончить начатое. Осталось так, доделать: код отрефакторить, функционал допилить.

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

Забегая вперед, отметим важную штуку. Описанное ниже – вполне себе кейс, но не совсем история успеха. Скорее это история о том, как компания переживала (и пережила) кризис роста – когда запросы клиентов превышают доступные ресурсы.

SubU – прикольный стартап, который развивают четыре энтузиаста: Илья, Алексей, Алина и Станислав. Суть сервиса – это маркетплейс подписок. В него можно добавлять все свои подписки, управлять ими и, что ценно, контролировать все расходы.

Мы занимались основным продуктом SubU для клиентов – мобильным приложением, где можно делать все описанное выше. Клиент нам был уже знаком, раньше мы работали с ним через другую компанию – делали то самое приложение, но не успели его закончить. Спустя время SubU постучались к нам уже напрямую, и мы подхватили работу.

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

Отбрифовали → поставили задачу команде → сделали → согласовали и параллельно отбрифовали по следующему этапу → приступили к следующему этапу.

Хороший план, надежный, как швейцарские часы, причем без иронии. В первой нашей статье мы подробно рассказывали про эту схему работы в теории, а во второй – показали ее на примере.

И – вот хочется же что-то сказать в свое оправдание – формально тут тоже планировалась работа в спринтах. Точнее, в спринте – он был один. Всего-то добить 20 задач – и в релиз.

Вот реально, виделось, что работы не так много:

Ну ок: отбрифовали заказчика, оценили работы, побежали делать.

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

А почему?

Старик Мерфи был крайне депрессивен, но тысячу раз прав: если какая-то гадость может случиться – она случается. Причем «гадость» – это не обязательно что-то концептуально плохое. Просто непредвиденное. Хотя отчасти лукавим – как минимум первый пункт из списка был очень даже прогнозируемым:

— Хватались за все сразу. Обычная логика работы выглядит так: запланировали n задач в спринт → сделали их, минимально отвлекаясь на другие → выделили время на тестирование → протестировали, доработали → сдали → взяли следующий пул задач. Хорошая ведь логика – и для работы удобная, и клиенту понятная. А тут мы делали кучу задач параллельно, потом так же кучей их тестировали, а пока переходили к другим – дорабатывали предыдущие. Разработчики смотрели в мониторы со сдержанным скепсисом и периодически переодевались в тестировщиков – иначе было просто не вытянуть.

— Выполнение задач походило на битву Геракла с Гидрой. В смысле – одну голову отрубаешь, а на ее место вырастают три новых. Прямое следствие предыдущего пункта и все того же отсутствия нормальной логики спринтов. Чем хуже планируются задачи – в чем и призваны помогать спринты – тем больше выскакивает неожиданного. Понятно, что в итоге их список конечен, но это сейчас мы можем спокойно об этом говорить: «Пффф, ну подумаешь, хаос меньше поддавался дрессировке». В процессе работы со спокойствием было не очень.

— Уже в процессе работы поняли, что нужно менять архитектуру. Чем больше мы работали с клиентом, тем больше убеждались, что изначально выбранная архитектура при выполнении всех его требований сделала бы из приложения фанерный каркас, надежно подпертый костылями. Ну, не совсем так плохо – сгустили все же краски. Но новая архитектура откровенно просилась в проект. К тому же мы понимали, что да, потратим время сейчас, но будет гораздо проще потом поддерживать и развивать приложение. Да и работать оно на новой архитектуре будет пошустрее, что ценно для пользователей.

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

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

— Тупо случился завал. Не из-за SubU. Просто как раз в июле-сентябре активизировались многие заказчики, и на нас навалилась гора работы.

С трудом и болью, честно говоря.

— Договаривались с клиентом. С причинами на нашей стороне, вроде завала и недочетов планирования, мы более-менее справлялись. Да, зачастую их вытягивали на личном героизме участников проекта, но все же – справлялись. В значительной степени для увеличения сроков были объективные и притом независящие от нас причины. В частности, прилетающие дополнительные задачи. Для примера:

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

— Илья фильтровал задачи. Илья был нашим основным контактным лицом, почти все задачи мы получали от него – он собирал их со всей своей команды, агрегировал, фильтровал и уже в причесанном виде отдавал нам. Если бы не он, нас бы, скорее всего, завалило так, что впору вызывать МЧС. Благодаря усилиям, его и Насти, поток задач был хотя и объемным, но все же контролируемым.

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

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

Но все же в итоге у этой сказки – счастливый конец

Мы не запороли ни приложение, ни бюджет, ни отношения с клиентом.

В 20-х числах октября приложение вышло на AppStore и Google Play, за неделю прошли этап стабилизации и в основном пофиксили баги, попавшие в прод. Подключили аналитику, пошли подписчики. Приложение у нас на поддержке – например, мы еще добавили к нему уведомления через OneSignal.

А сейчас мы делаем для SubU приложение уже под западный рынок. И на этот раз – в строгой логике спринтов!