Александр Фёдоров
В целом для плана перехода от "как есть" (неработающее текущее приложение) к "как надо" (целевое состояние приложения) я бы выделил:
1. Понять "как надо" - собрать список требований в виде пользовательских историй
2. Переложить требования в какой-никакой проект приложения (клиентский интерфейс, модель данных, интеграция с учётной системой)
3. Оценить "как есть" - что готово из проекта, какие есть проблемы
4. Оценить решаемость проблем вообще и человеко-часы на их устранение
5. Параллельно описать видение проекта "как надо" если делать с нуля - с выбором знакомых и подходящих технологий, указать из проектного опыта сколько времени необходимо на эти блоки
6. Принять решение о выборе более дешёвого (но рабочего) варианта
6.а) Если решаемость проблем неизвестна, очертить объём ресурсов / времени, при превышении которого проблема признаётся нерешаемой (текущими силами в обозначенные сроки), часть "как есть" выкидывается и блок пишется с нуля.
Если пофантазировать про описанный кейс, я бы посмотрел на такие пункты:
1. Описать клиентский интерфейс (по минимуму - карточки и переходы между ними), обозначить что уже работает и к чему есть замечания
2. Описать объектную модель для хранения промежуточных данных и процедуры обработки этих данных (обновление доступных справочников, хранение заказов, предпочтения и т.п.)
3. Описать интеграцию с системой обработки заказов (отправка заказа, получение подтверждения)
Предположу, что первые 2 пункта были рабочими, хоть и устаревшими с точки зрения дизайна и, возможно, с точки зрения CJM.
Но вот пункт 3. был нерабочим или не стабильно рабочим.
Соответственно, поставил бы дедлайн по доведению до ума текущей интеграции (с выполнением операций по хеппи вей и отдельно с нагрузочным тестированием). Если, скажем, через пару месяцев она не заработала как надо, признать невозможность / неспособность к её доработке и перейти на разработку стабильного решения с нуля.
И не жалеть выбросить то, во что вложено уже много, но оно всё равно не работает.
При этом другие блоки можно независимо дорабатывать (хотя по описанию кейса весь предыдущий дизайн без сожаления выбросили, да и маршрут пользователя почти полностью перекроили - здесь было не жалко...).
Пошерстил тесты по скорости полнодуплексных протоколов, веб-сокеты сейчас один из самых быстрых.
Но эффект от веб-сокетов по сравнению с сеансовыми rest-запросами будет заметен только при активном обмене данными между клиентом и сервером. Здесь такого нет.
Оформление заказа из мобильного приложения - это однократный сеанс связи: отправил запрос - получил ответ. И здесь веб-сокеты дают минимальный выигрыш в скорости, т.к. соединение всё равно надо установить.
При этом висящие открытые соединения по сути устраивают ddos-атаку на сервер и излишне расходуют батарейку не давая мобильному приложению уходить в фон.
И всё равно остаётся непонятным: зачем пытаться выиграть 50-100 миллисекунд при отправке заказа, если клиент всё равно несколько секунд будет ждать подтверждения от кассы?
Можно и не читать, конечно. Кто ж заставляет.
Но проверка гипотезы на фокус-группах - вполне рабочий инструмент. И в статье есть упоминание, что такую фокус-группу запускали, и на двух кофейнях она работала.
Плюс запрос от клиентов тоже был, это уже не личное мнение разработчика.
Не соглашусь. Не просто выбор кофе из готового, а конструктор своего напитка - это посложнее задача.
Я бы как клиент таким приложением с удовольствием пользовался бы - не спеша посмотрел бы что с чем можно смешать, что добавить. И не ждать в очереди - это прям огромный плюс.
С точки зрения производства, как мне видится, процессы не меняются - клиент может заказать свой кастомный кофе и на кассе, только его вся очередь будет ждать, пока он будет выбирать, а оператор вносить заказ. Так что тут приложение и для производства было бы полезно - ускоряло бы процесс приёма заказа без усложнения его исполнения (и так есть опция сложных заказов).
А нужен был анализ системы, которую принимали на доработку. Сначала составить какой-никакой список требований и CJM (пусть он для кофейного приложения и будет тривиальным), потом посмотреть как это сейчас реализуется, где затыки и ошибки, сколько их стоит исправить, а потом сколько сделать с нуля хорошо. И принять решение.
Если техлид предлагает написать приложение с нуля из-за "фатального недостатка" предыдущего - тут, конечно, профнепригодность.
А вот если он аргументированного говорит, что на доработку здесь, здесь и здесь нужно суммарно 500 человеко-часов, а с нуля написать - 300, то коммерчески, технически и как угодно ещё получается выгоднее написать своё.
В кейсе, похоже, пропустили момент сравнительного анализа и приняли решение "жалко выбрасывать", что в итоге привело к неработоспособности приложения, отрицательному клиентскому опыту и провалу проекта.
Очень удивительный архитектурный выбор - делать интеграцию по заказам на веб-сокетах (веб-сокеты не для быстрой передачи данных, а для возможности сообщений со стороны сервера не только в ответ на запрос, а в любой момент).
Здесь же чисто сеансовая работа: отправил заказ - получил подтверждение, если не получил подтверждения - перезапросил через 10 секунд, если не получил: "извините, не получилось отправить заказ, будем рады видеть вас лично".
Прям статья про разработческий фейл
Статья для переписи ботов с целью их блокировки :)
В целом, технически решаемо практически всё, вопрос только в сроках и ресурсах (конвертеры можно написать, нестабильные системы постоянно пинговать, обложить страховочными копиями и регулярно перезапускать и т.п., для устаревших компонент разворачивать песочницу и т.д.).
Поэтому более точная формулировка "нерешаемости": "нерешаемая в обозначенные сроки при выделенном бюджете".
И очень часто версия 2.0 выпускается с полным переписыванием проблемного блока приложения.