Если вы «усыновили» проект-катастрофу

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

Сегодня мы поговорим о бремени чужих «косяков», о том, как нужно завоевывать доверие клиента, в силу негативного бэкграунда разочаровавшегося в IT, а также почему важно не отказываться от таких предложений. Никакой воды, только личный опыт и наши собственные инсайты. Итак, с чем вы скорее всего столкнетесь, решив подбросить чужой проект до финишной прямой…

+100500 ошибок, доставшихся «в наследство» от предыдущей команды разработчиков

Идеальный сценарий (и на этом стоит, пожалуй, настаивать) — это постепенная передача проекта от предыдущей команды новым разработчикам. По крайней мере это поможет как можно быстрее вникнуть в суть проблемы. А проблема(ы) обязательно будем(у)т.

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

Самая действенная формула для решения этой проблемы оказалась до банальности простой: «терпение и труд все перетрут». Однако, многое также зависело от нашего проектного менеджера (ПМ), который смог разгрести все завалы, оставленные предшественниками. Не последнюю роль в этом сыграла правильная расстановка приоритетов. Кстати, о них…

Много задач — нет приоритизации

Самой большой сложностью, с который мы столкнулись в описанном выше случае, была проблема планирования и приоритизации задач. С одной стороны, show must go on: продукт требовал дальнейшей непрерывной разработки, с другой — мы постоянно обнаруживали много разных ошибок, и их нужно было срочно исправлять.

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

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

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

Долгое время новые задачи были у нас в большем приоритете. Затем система Клиент-Исполнитель немного усложнилась: у заказчика появился новый пользователь, и нужно было добавить в разрабатываемое нами ПО дополнительный, персонализированный функционал. То есть потребности нового «игрока» также стали приоритетом.

Но мы не растерялись и провели очередную приоритизацию, выделив группу П1, куда вошло около 10 задач первого приоритета. К сожалению, между ними очень редко удавалось выстроить градацию важности, максимум обозначались две задачи. Мы использовали разные методы приоритизации, что-то помогало, что-то не очень. В целом перед нами всегда маячило несколько задач категории П1, из которых было практически невозможно выбрать, что делать в первую очередь, поэтому постоянные асапы сохранились. В результате сложилась такая ситуация, когда ты приходишь на работу с конкретным планом, а тебя уже ждет несколько новых писем с пометкой «Срочно!», которые меняют все. «Так не пойдет», — подумал наш ПМ и решил изменить методологию разработки.

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

В конце концов, наш ПМ принял решение перейти на методологию канбан. Так как задачи начали идти в потоке, напряжение в коллективе немного спало. Асапы, хотфичи, горячие фиксы прилетали, как и прежде, но в канбане этим было проще управлять. Мы выстроили хороший процесс, нашли те лимиты, которая команда использует на той или иной стадии разработки. И в целом трудились над проектом долго и счастливо. И закончили его в один день :)

Ладно, конечно, все было не так гладко. Честно говоря, тот усыновленный проект действительно был настоящей катастрофой: столько ошибок, подводных камней и непредвиденных обстоятельств (чего только недобросовестные подрядчики стоят, но об этом как-нибудь в другой раз) — такого и конкуренту не пожелаешь. Но оглядываясь назад с вершины приобретенного опыта, мы ни на секунду не жалеем, что ввязались в эту авантюру.

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