Типичные проблемы, снижающие качество Backend-разработки
Качество разработки это своего рода вечная тема. Ей посвящено множество книг, треки профильных конференций, а также вполне научные работы, описывающие методики автоматизированного контроля качества. В Byndyusoft, например, качество разработки проектов контролируется при помощи ревью по специально сформированному под проект чеклисту, закрытие части пунктов которого проверяет машинерия, встроенная в CI/CD. И, увы, иногда по итогам ревью происходят неприятные открытия, обнаруживается, что процент закрытия чеклиста относительно низкий в сравнении с другими проектами, причем как в целом по чеклисту, так и по отдельным его измерениям. И это несмотря на готовые инфраструктурные кубики, шаблоны сервисов и целой коллекции экспонатов в музее решений. Проанализировав подобные ситуации, мы поняли, что предпосылки их возникновения имели место на ранних стадиях развития проектов и ниже я постараюсь их описать.
Затянувшийся MVP
We had 2 bags of grass, 75 pellets of mescaline, 5 sheets of high-powered blotter acid, a saltshaker half-full of cocaine, a whole galaxy of multi-colored uppers, downers, screamers, laughers…
Fear and Loathing in Las Vegas
Разработка почти любого проекта начинается с реализации MVP, это то самое время, когда все весело и бесшабашно, тестируются самые невероятные гипотезы, а технологические решения принимаются в основном исходя из минимизации Time to Market. Однако это веселое время не может продолжаться вечно, бизнеc-процессы усложняются, реализующая их архитектура тоже, появляется все больше пользователей и, как следствие, растет цена ошибки. А теперь представим себе ситуацию, когда MVP немного поодзатянулся. В экстремальном варианте это выглядит так: проект уже пару лет в проде, оброс фичами, у него сотни и даже тысячи пользователей, серьезная нагрузка, etc., а технологические решения все еще принимаются такие, словно это MVP, длящийся пару месяцев. Цена ошибки на таком проекте высока как никогда.
К чему это приводит? К тому, что вся тяжесть работы с проектом ложится на плечи разработчиков, и им становится все сложнее с каждой новой фичей. В итоге проблемы растут как снежный ком, и проект либо технически деградирует, либо разработчики выгорают от непосильного труда, либо все это сразу. Еще того и гляди уволится кто-нибудь.
Изменить сложившуюся ситуацию довольно сложно, ибо заказчик привык платить меньше, а получать больше за счет того, что разработчики работают на износ и вкладываются в проект личным временем. Поэтому лучше в нее вообще не попадать. На случай, если избежать этой ситуации не удалось, существует ряд рекомендаций.
- Формирование roadmap’а продукта (не проекта, а именно продукта) и четких, основанных на метриках, критериев того, что очередной этап пройден (см. Аналитика IT-продукта). Регулярные встречи команды и заказчика для корректировки roadmap’а и анализа текущего положения на нем позволят выработать общее понимание того, что происходит.
- Осознанная фиксация командой на каждом этапе развития продукта некоторого уровня качества, следование ему и доведение до заказчика информации о возможных последствиях и рисках. При этом их купирование за счет личных жертв разработчиков приведет к откату во взаимоотношениях с заказчиком, в этом вопросе нужно быть последовательным.
- Корректировка оценок работ таким образом, чтобы они отражали все, что реально необходимо сделать для закрытия задачи. Тут нужно учитывать как особенности конкретного проекта, так и общие правила, по которым ведется разработка.
Незаменимые разработчики
You make the mistake, Eric, of considering yourself necessary. The graveyards are filled with men who thought they could not be replaced.
The Guns of Avalon
Началу разработки предшествует этап предварительного проектирования, на котором во многом определяется дальнейшая судьба проекта, а именно формулируются бизнес-цели продукта, прорисовывается его roadmap, архитектура, формируется скоуп работ, etc. По завершении этого этапа начинается активная фаза разработки, команда приступает к реализации MVP. И если в рамках предварительного проектирования не было допущено серьезных ошибок, то для проекта и его команды начинается непростое, но очень интересное время, когда задуманное воплощаться в реальность.
Однако все, что имеет начало, имеет и конец, и рано или поздно возникает необходимость передачи проекта либо другим разработчикам либо вообще на поддержку. Причины могут быть различными, от ротации команды до завершения активной фазы разработки, но итог один: проект передается кому-то другому. Теперь представим что будет, если необходимость передачи проекта не была учтена при формировании скоупа работ? Скорее всего у такого проекта нет документации, состояние протекающих внутри него процессов трудно или почти невозможно отслеживать, и новенький в команде не сможет точно сказать все ли работает как задуманно.
К чему это приводит? К тому, что bus-фактор стремится к единице, разработчики становятся “незаменимыми”, они уже не могут переключиться на другой проект или даже просто передать часть своих задач кому-то еще, например, службе поддержки.
Отныне это их “крест”, который придется в той или иной степени нести долго и если ничего с этим не делать, то у разработчиков могут в итоге сдать нервы. Когда уж тут следить за качеством и актуальностью принимаемых технологических решений, если все силы уходят на разрешение постоянно возникающих мелких проблем, которые нельзя никому делегировать?
В такую ситуацию может попасть любая команда, начинающая что-то новое и “горячее”, ведь всегда есть соблазн как можно быстрее начать разработку и выкатить MVP. Не застрять в ней навечно и, в конечном итоге, успешно передать проект поможет достижение следующих целей:
- как минимум один человек за пределами команды должен разбираться в бизнес-процессах продукта на любом этапе его развития;
- как минимум один человек за пределами команды должен в любой момент понимать, работает ли система;
- служба поддержки должна иметь возможность диагностировать проблемы и решать часть из них без привлечения разработчиков.
Эти цели должны дополнить Impact Mapping, проведенный на этапе предварительного проектирования. Как их достигать и стоит ли достигать их все зависит от особенностей конкретного проекта. Однако, о них как минимум нельзя забывать.
Вместо заключения
Описанные ситуации — довольно распространенное явление, и от них не застрахован никто. Но, как говорится, кто предупрежден, тот вооружен, и изложенные рекомендации могут стать тем самым оружием в руках команды, которое поможет ей преодолеть возникшие на пути трудности.
