Клиентский проект · приняли существующий продукт
Getizy: мы были вторым подрядчиком.
Приложения для iOS и Android уже существовали, а компания, которая их написала, ушла с проекта. Мы приняли код, разобрались с тем, что в нём сломано, и дальше выпускали новые функции в оба магазина.
- Клиент
- Getizy
- Формат работы
- Приняли существующий продукт
- Платформы
- iOS и Android
- Релизы
- App Store и Google Play
Два сценария приложения в том виде, в каком оно выходило: заказ и оплата. Эти экраны придумали и написали не мы. Мы заставили их работать, а потом стали дополнять.
Исходная ситуация
Живой продукт, о котором больше некому рассказать.
У Getizy было приложение на iOS, приложение на Android и пользователи на обеих платформах. Не было только компании, которая всё это написала, — а вместе с ней ушли и причины, по которым код выглядит именно так.
Ничего необычного в этом нет. Работающая программа — это запись принятых решений, и большая часть этой записи хранится в головах тех, кто их принимал, а не в репозитории. Владельцу остаётся продукт, который работает, список того, что в нём не так, и ни одного способа понять, какие части можно трогать безопасно.
Главное ограничение: переписывать нельзя.
Переписать с нуля — это месяцы, за которые те, кто уже пользуется приложением, не получают ничего. И это отказ от единственного, в чём старый код действительно силён: он прав в сотне мелких случаев, которые никто не записал. Поэтому задача звучала так: заставить работать чужие решения и не переставать выпускать версии, пока мы это делаем.
Что мы сделали
Сначала стабильность, потом новые функции.
Четыре этапа, именно в этом порядке. Если добавлять функции, пока старые ошибки открыты, список ошибок просто становится длиннее.
Сначала прочитать, потом трогать.
Первой работой было не исправление, а чтение: мы читали код, запускали оба приложения на настоящем бэкенде и записывали, как на самом деле выходит новая версия. Пока вы не можете сами собрать, подписать и отправить приложение в магазин, вы ничего не приняли — вы взяли его на время.
Разобрать унаследованные ошибки.
Все известные ошибки собрали в один список и расставили по тому, во что они обходятся пользователю, а не по тому, как выглядят в коде. Сначала падения и всё, что мешает оплате. Косметический долг — в конце, а часть его так и не тронули: в чужом коде полно вещей некрасивых, но правильных.
Сделать выпуск версии скучным.
Сертификаты, ключи подписи, учётные записи в магазинах и сама сборка перешли под наш контроль раньше, чем мы пообещали хоть одну новую функцию. Чтобы релиз перестал быть событием.
И только потом — новые функции.
Когда приложение стало можно выпустить в любой момент, а список ошибок стал коротким, мы начали добавлять новое. Новые функции уходили в оба магазина в том же ритме, что и исправления, достаточно мелкими версиями, чтобы неудачную можно было быстро заменить.
Код читал тот же человек, который потом выпускал из него версии.
Принять чужой проект
Можем сделать с нуля, а можем принять то, что уже написано.
Разработка встала, подрядчик ушёл, ошибок в приложении выходит больше, чем новых функций. Начать с существующего кода — для нас обычный сценарий.
Начинается это с платного разбора кода.
Цену такой работы мы называем по коду, а не по демонстрации экрана. Первое, что мы продаём, — разбор кода, оплачиваемый отдельно: пакет Product Decision Sprint, 2 500 € и 5 рабочих дней. В продакшен ничего не выкладывается; сумма полностью засчитывается в счёт разработки, если она начинается в течение 30 дней.
На что смотрим
- Можем ли мы собрать, подписать и выпустить приложение со своих машин, без участия тех, кто работал до нас.
- Как код ведёт себя при сбоях: ошибки, повторные попытки, платежи, прошедшие наполовину.
- Какие зависимости заброшены и какие версии ОС вот-вот перестанут их терпеть.
- Где лежат данные, кто может их читать и что на самом деле придётся сделать по запросу в рамках GDPR.
- Сколько кода закрыто тестами и проходят ли эти тесты сейчас.
- Части, которые пока лучше не трогать, — и что нужно, чтобы их стало можно трогать.
Что вы получаете до того, как назовём цену разработки
- Что сломано — обычными словами, с описанием риска по каждому пункту, а не с ярлыком критичности.
- Что придётся починить прежде, чем поверх этого можно строить новое.
- Что мы сознательно оставим как есть и почему.
- Где переписать один кусок дешевле, чем чинить его, — это тоже входит в разбор.
Дальше смета собирается в том же порядке
Сначала стабилизация, потом новые функции — и то и другое по фиксированной цене. Вторая часть оценивается по тому, что нашёл разбор, а не по догадке, сделанной до того, как кто-то открыл репозиторий. Если разбор покажет, что за такой код нам браться не стоит, мы скажем это прямо — честный ответ вы всё равно получите.
Как есть
Что с проектом сейчас.
Getizy выходил в App Store и Google Play. Сейчас сервис недоступен публично.
Эта фраза останется на странице. Отвечать мы можем за разработку: приняли продукт, написанный другими, сделали его стабильным и продолжали выпускать версии. Что было с бизнесом дальше — рассказывать не нам.
Цифр на этой странице тоже нет. Мы отвечали за разработку, а не за бизнес: установки, выручка и рост — не наши данные, и публиковать их не нам.
Что сделали бы иначе.
Забирать процесс выпуска релизов в первый же день.
Мы чинили реальные ошибки раньше, чем смогли выпустить версию своими силами. Теперь подписи, сертификаты и доступы к магазинам — первое, что мы просим, когда принимаем чужой проект, ещё до списка ошибок. Пока это не решено, исправления сделаны, но до людей не дошли.
Считать чтение кода отдельной работой.
Тот код мы изучали за счёт часов, заложенных в разработку. Прочитать чужой продукт как следует — это несколько дней, поэтому теперь это отдельная оплачиваемая работа до сметы. И цифра в смете опирается на то, что в репозитории есть на самом деле.
Начать с нуля или принять то, что уже есть.
И то и другое у нас обычное дело. Новый проект получает объём и цену до того, как написана первая строка. Работа с существующим кодом начинается с платного разбора, смета на разработку идёт после него.
Одна короткая форма, ответ в течение одного рабочего дня. Если задача не для нас, скажем прямо.