Что бывает, если разработчик не знает планов клиента

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

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

Речь шла о системе визуализации данных, которую клиент самостоятельно делал, взяв за основу бесплатную BI-платформу Superset от Airbnb.

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

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

Исходный код Superset был ужасен. «Да какой разработчик похвалит чужой код?» - спросите вы. Так-то оно так. Но то, что мы увидели в Superset поражало даже наше изнурённое заказной разработкой воображение: фарш из React, jQuery, кусков чистого JavaScript и HTML – чего там только не было! И при этом почти всё отвратительного качества с точки зрения code style.

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

После увиденного в исходном коде платформы нам бы включить благоразумие, объяснить клиенту, что «мы так не договаривались» и пересмотреть хотя бы сроки, а хорошо бы и бюджет. Но мы с упорством продолжили самоистязания.

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

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

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

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

Так мы потеряли очень толкового разработчика. Олег, если читаешь эти строки, знай: мы тебя помним, зла не держим за такой «выход», захочешь вернуться – приходи, у нас полно интересных проектов с хорошим кодом.

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

Тут ещё можно сказать про работу с токсичными клиентами или проектами. Помимо чисто денежных потерь, она может нести ещё и кадровые проблемы. Универсальный совет есть: не ввязываться в такие истории. Но он очень общий. А жизнь куда сложнее. Иногда бывает просто «надо». И когда такое случается, будьте особенно чуткими к настроению команды.

С горем пополам мы реализовали нужную функциональность и починили то, что развалилось по ходу проекта. Но не успела высохнуть краска на акте выполненных работ, как клиент попросил добавить ещё несколько функций.

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

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

Ожидаемо, перестало работать почти всё из того, что мы ранее сделали и починили.

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

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

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

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

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

Оказалось, что парой новых функций дело не ограничится и в планах создать чуть ли не аналог BI-продукту от Oracle, а потом ещё и продавать его. Более того, похоже, что несколько внедрений уже и состоялось на тот момент.

Это был шок. Мы поняли, что весь проект изначально управлялся неправильно, как с нашей стороны, так и со стороны клиента. Только потому, что мы не знали планов, мы неадекватно делали вообще всё: от оценки задач до сдачи их в релиз.

Помимо вышеописанных проблем, стоит разобрать ещё одну, которая тоже явилась следствием нашего незнания планов клиента: отсутствие документирования по проекту.

И в самом деле: «Ну какие документы, если нужно только пару функций добавить? Добавим, отдадим и вернёмся к другим проектам». Так можно. Но только не в тех случаях, когда продукт планируется долго развивать, поддерживать и продавать. Если планы именно такие – нужно с первого дня документировать проект.

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

Да, были постановки задач, и по ним удалось восстановить, кто прав. Но наличие документации, конечно, позволило бы сделать это быстрее и с меньшими ресурсными затратами.

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

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

Эта статья написана разработчиком, о проектных проблемах и, кажется, что адресована также разработчикам. Но нет. В первую очередь это обращение к тем, кто заказывает разработку.

Обязательно делитесь с разработчиками своими планами на создаваемый продукт. Даже, если это мечты, и многое из них сейчас реализовывать не планируется, всё равно расскажите о них команде разработки.

Мы не знаем ни одной причины, по которой хранение тайны вокруг проекта имело бы смысл.

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

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