Кейс для разбора

Описание кейса для группового разбора:

Работаю менеджером проектов и системным аналитиком в небольшой компании, занимающейся разработкой ПО на заказ (аутсорс). В октябре 2020 стартовал очередной проект – мобильное приложение для людей, небезразличных к экологии. Основным инвестором проекта, по словам заказчика, выступает государство. Модель контракта: time & material (оплата за по факту потраченное время).

Как выяснилось, серверную часть (back-end) уже более полугода разрабатывает программист заказчика. Дизайн разрабатывает также команда клиента. Управление продуктом и требованиями осуществляется тоже на стороне клиента. От нас же требовалось разработать само мобильное приложение, и обеспечить его тестирование. Заказчик сообщил о сроках – 10 декабря 2020, как о конечной дате сдачи проекта (от этого зависело дальнейшее финансирование).

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

– Через 2.5 недели разработчик поставил всех перед фактом, что он прекращает работу, в связи с тем, что получил визу в другую страну, и ему в кратчайшие сроки необходимо переехать туда на работу. Пришлось срочно искать замену. (начало ноября 2020)

– Замена была найдена в течение недели: наняли опытного программиста, который ранее уже работал в компании. Он сразу же приступил к работе (11 ноября 2020). И обнаружил проблемы с кодом, унаследованным от прошлого разработчика (так называемый “технический долг”). Помимо этого, бли выявлены пробемы с дизайном – он оказался не на 100% готов/пригодным к разработке (отсутствие необходимых размеров для разных экранов устройств, и т.п.). Данные проблемы имели эффект “снежного кома”: постепенно накапливались, и далее снижали производительность приложения, увеличивали количество потенциальных дефектов при тестировании. Заказчику компенсирвоали порядка 30 часов издержек на замену разработчика.

– Клиенту было сообщено о проблемах кода (наш риск) и дизайна (риск со стороны заказчика). Ввиду скорого дедлайна (через 1 месяц), заказчик отказался останавливаться в прогрессе и заниматься решением накопленных проблем. Дизайн, по их словам, был чуть ли не идеальным, а на указанные проблемы отвечали, мол, если проблема не влияет на утверждение приложения в магазине (AppStore, Play Store), то она низкоприоритетная, и сейчас на это время тратить не будем. (средина ноября 2020).

– Буквально через несколько дней после описанных событий разработчик заболел COVID-19. Он готов был продолжать работы, но, при этом, его производительность упала почти в два раза. Это замедлило темпы разработки. (вторая половина ноября 2020).

– Пришлось искать еще одного разработчика в помощь. Его предоставили партнеры. С момента старта работ, за неделю, он смог сделать задач всего на 7 часов. Причина была в личных проблемах (заболел кот, требовалась операция). В итоге, привлечение второго разработчика, нас практически не ускорило. (конец ноября 2020).

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

– В итоге, к 10 декабря приложение было лишь ограниченно готовым. Заказчик встречался с инвестором, общая обратная связь по приложению на встрече была хорошей, но, инвестор поставил условие – выпустить минимально жизнеспособную версию, и получить первую обратную связь от пользователей. Это было озвучено как условие дальнейшего финансирования.

– Заказчик принял решение остановить проект. Бюджет проекта не был превышен, но, ввиду описанных проблем, проект не соответствовал ожиданиям клиента. Заказчик настаивает на том, что команда должна завершить MVP за свой счет. При этом, отказывается оплачивать последний выставленный счет.

– Разобравшись с претензиями, компания предложила пересмотреть счет, дополнительно компенсируя 20 часов за болезнь нового разработчика. Клиент на это предложение никак не отреагировал.

– Переговоры зашли в тупик. Компания общается с юристами по поводу передачи претензий по неоплаченному счету в суд.

У клиента (по контракту) изначально был доступ к исходному коду проекта.