Зри в код, прежде чем говорить срок

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

В качестве объяснения скажу, что заказчик был надежный, подвоха мы не ждали, да и срок был назван, по нашему мнению, с запасом. Однако это нас не спасло.

Ошибочные задачи

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

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

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

Отсутствие инструментов и отчётов

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

Ситуация осложнялась тем, что у проекта не было средств автоматического тестирования, документации кода, и даже описания базы данных (одна только структура которой занимала 5 Мб). Сложно представить, как и зачем предыдущая команда специалистов работала над системой два года.

Срыв командной работы

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

Казалось, кризис миновал, но одна деталь осталась без внимания: после смены ответственного исполнителя со стороны заказчика нам выслали доработанные требования и изменения ТЗ, которые показались несущественными.

И мы-таки заново собрали команду! Ребята стали продвигаться по документу, но видимых результатов это не давало, разбираться в существующей системе было долго. Кроме того, выяснилось, что незначительные изменения в ТЗ вылились в огромный объём работ.

Честно предупреждаем о провале

Спустя две недели задача была выполнена примерно на 10%. Нужно ли говорить, насколько это пугало заказчика? Ничего не оставалось, как открыто предупредить его, что на ближайшем показе системы показывать будет нечего.

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

На что мы ответили:

1. Первоначальные и уточненные требования значительно различаются.
2. Через 3 недели работа будет сделана.
   

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

Пришли к успеху, но не совсем

Назначенный показ был успешен: мы совершили значительный прорыв и реализовали первый и самый сложный алгоритм.

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

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

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

Для него нашлось готовое решение, но сервис, с которым нужно было интегрировать систему не соответствовал спецификации зашифрованного XML, поэтому решение было неприменимо.

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

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

Оставались сутки.

В 6 часов утра следующего дня (за 3 часа до показа) мы сообщили руководителю проекта о готовности к сдаче и отправились спать. В обед пришло письмо от генерального заказчика об успешной сдаче проекта.

30 декабря, за час до закрытия банков, мы заработали первый миллион.

Выводы

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

1. Никогда нельзя оценивать работу и браться за неё в спешке, даже если это предлагает постоянный, надёжный клиент. Его ошибка или неорганизованность рано или поздно ляжет на плечи исполнителя.
2. С огромной опаской надо брать системы без документации, не имея представления о качестве кода. Количество сюрпризов на пути может быть каким угодно.
   
3. Комбинация ошибок необоснованной оценки сроков и работы с проектом без документации, систем автоматического тестирования может оказаться фатальной для всех участников процесса.
   
4. Важно сразу понять, насколько заказчик владеет ситуацией. Если он не разбирается в проекте, не владеет необходимой информацией — это дополнительные риски, которые исполнителю придётся брать на себя.
   

Резюмируя: мы классные и молодцы, но не делайте так никогда — будете еще большими молодцами.

Чтобы убедиться, что вы всё делаете правильно, запишитесь на бесплатную консультацию. За 10 лет мы запустили 40 сложных программных продуктов для частных инвесторов, крупных бизнесов и государственных организаций, поможем и вам!