Как правильно оценить сроки проекта и не провалиться

May 30 2023

У нас был проект, конечный заказчик которого — государственная организация. Это здорово, но в работе для государства важно соблюдать 2 вещи: сроки и соответствие требованиям ТЗ.

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

Зри в код, прежде чем говорить срок
Ошибочные задачи
Отсутствие инструментов и отчетов
Срыв командной работы
Честно предупреждаем о провале
Пришли к успеху, но не совсем
Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дальше мы совершили чудо.

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

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

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

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

Выводы

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

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

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

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

Автор статьи
Кирилл Гришанин
Последние 10 лет руковожу командой аналитиков, дизайнеров и разработчиков

Подпишитесь на блог WB—Tech

Никакого спама, только анонсы новых статей

    Последние статьи

    Миграция внутренних пользователей Jira в новую директорию с сохранением данных об активности

    Рассказали, как осуществили перенос пользовательских данных из Jira (Internal Directory) в директорию Microsoft Active Directory.

    Как эффективно хранить и актуализировать корпоративные данные средствами low/no-code

    Рассказали, как организовали поток HR-данных, чтобы оргструктура и бонусно-бухгалтерские расчеты всегда были актуальны.

    Мало кода, больше результативности: платформы low-code и no-code

    О low-code и no-code платформах, примерах использования и разбор нужно ли быть программистом.

    ИП Гришанин Кирилл Олегович
    ИНН 774313842609

    Коворкинг Starthub

    Б. Новодмитровская ул., 36, стр. 12, вход 6,
    Москва, Россия, 127015

    Коворкинг Wework

    Ahad Ha'am 54,Tel Aviv-Yafo,Израиль

    © 2023 WB—Tech. Мы разрабатываем уникальные решения для компаний из России, США и Европы.