Что делать, если клиент пришел с проектом перед Новым годом
– рассказывает Ринат Шамшутдинов, руководитель mobile

Контекст:
Дело было несколько лет назад. Под самый конец года к нам обратился клиент – 21 января он планировал показать MVP-версию мобильного приложения инвесторам. В конце декабря он понял, что предыдущий подрядчик, кажется, не успевает. И пришёл к нам с кодом для оценки – сможем сделать или нет.

Вёрстка была прекрасная,
Всё остальное было ужасное пустое.
(Если бы Сапгир был айтишником)

Я тогда был разработчиком. Вот проверяю полученный код, проверяю, проверяю и понимаю – интеграции никакой нет, бизнес-логика не заложена. У нас есть вёрстка :) Словно предыдущий подрядчик показывал клиенту «прогресс», на самом деле демонстрируя лишь вёрстку. Получается, экран как бы есть – кнопки нажимаются, но «под капотом» ничего не происходит 🥲

Ну что? Погнали!)

Итак, при каких условиях на такой проект можно соглашаться
1. Заказчик принимает риск. В таких условиях непонятно, сколько точно по времени займёт доработка. Вёрстка-то она статичная, а вот прикрутить динамические компоненты, логику при подключении к серверу – это совсем другое дело. То есть мы сказали, что мы согласны попробовать и постараемся успеть. НО подготовили заказчика к тому, что может возникнуть форс-мажор. Он доверился нам.
1.2. Заказчик не требует оценку по фиксе.

2. У вас есть PM и достаточно специалистов, которые готовы вписаться в такую авантюру. На тот момент PM’а с нами не оказалось, но в лодке было:
▪️ трое разботчиков: накидали архитектуру (решили делать с нуля, так было проще), поделили между собой бизнес-фичи, оттолкнулись от основных сценариев для презентации 21 января;
▪️ руководитель mobile: поддерживал нас в процессе и сделал интеграцию с AWS для загрузки файлов;
▪️ заказчик: докручивал backend на Битриксе.

Мы, разработчики, восприняли всё это как челлендж, который интересно выполнить. С 3 января мы работали full-time 5/2. Через две недели готова была версия для тестирования. Если команда не готова к такому, откажитесь от проекта.

3. Уровень разработчиков позволяет им работать по Scrum. Даже если они не задумываются об этом. Мы каждый день обновляли статусы фич, следили за диаграммой Ганта, чтобы точно успеть протестировать и исправить баги. Нам дали задачу – сделать мобильное приложение. Мы пошли и сделали – составили список задач, спланировали их выполнение и распределили. В общем, чистый Scrum) Взяли ответственность на себя и самоорганизовались)

4. Интересно дальнейшее сотрудничество. Хотя мы честно симпатизировали заказчику, по-человечески хотели ему помочь, но всё-таки альтруизм в рабочих отношениях может привести к ненужному никому выгоранию. Важен деловой подход и оценка перспектив. В нашем случае ситуация была win-win: мы не сомневались, что сотрудничество продолжится.

5. С самого начала с заказчиком – контакт. Невозможно одолеть такой проект, если вы не будете единым механизмом. Тут мы разговаривали на одном языке, нам не нужно было объяснять приоритет фич для MVP, почему мы начали с нуля и т.д. Это сохраняло силы и время.

P.S. Презентация прошла хорошо. После мы в спокойном темпе доработали проект и успешно его завершили🤘