Фронт раньше бэка – это вообще законно? 🤔
История о том, как делать не нужно – а именно выкатывать фронт раньше бэка. И что делать, если это неизбежно
Немного контекста
Работал с продуктом одного банка, где было четкое разделение фронтенд и бэкенд-команд. Я был во фронтенд-команде. По идее аналитики обеих сторон связывают эти части, т.к. высок риск рассинхрона
Однако был один нюанс – бэкенд-команды не было. Ну как, сам бэк с сервисами есть, но его не развивают. Максимум, на что мы могли рассчитывать – один фантомный разраб со стороны банка
Что произошло? 🔥
В работе была огромная фича на весь квартал – новый продукт на фронте со своим отображением. А это новый JSON на 100+ полей со сложными структурами – без бэка не обойтись
Однако бэк делать не торопились, поэтому я писал моки (примеры JSON) на основе дизайна и отдавал своим разработчикам, чтобы им было с чем работать
Подходит конец квартала, в преддверии премии внутренние сотрудники активизировались – появился обещанный бэк-разработчик и сделал свою работу за две недели. Результат: JSON приходит с null полями и ошибками, фронт сломан. На проде 🌾
Исправляли все это еще месяц, пришлось плотно поработать с бэк-разрабом – хотя это нужно было делать до релиза
Можно ли было избежать? 🤔
Спустя время, проанализировал ситуацию, я понял, что нет. Мы не могли предусмотреть, что:
🔴 Команды бэка нет вовсе
🔴 Человек, который в итоге дорабатывал бэк, изначально не должен был этим заниматься
Виной всему политика компании и желание сэкономить на человеческих ресурсах – ничего бы не случилось, если бы разработчика выделили раньше
Но всегда можно свести риск к минимуму
Со своей стороны мы сделали все что смогли (и вам советую):
🟢 Сами разработали моки, работали с ними и их же скидывали бэк-разрабу для понимания итогового результата
🟢 Написали ТЗ для этого разработчика (хотя не должны были)
🟢 Были всегда на связи, отвечали на все вопросы и были открыты к предложениям
🟢 Постоянно подсвечивали разные проблемы и риски заказчику
—————
В таких непредсказуемых ситуациях самое главное – работать честно и на совесть. Отнестись с пониманием и постараться помочь. Тот бэк-разраб тоже стал жертвой ситуации, и винить его было бы глупостью
Поэтому если мы сделали, что могли, но в итоге случился фейл, то знайте – наша вина в этом минимальна. Не стоит зацикливаться – сделали выводы, получили уроки и потом вспоминаем об этом с улыбкой (как и делает моя команда) 😁
⬇ А вы сталкивались с похожими ситуациями? Делитесь в комментариях
————
P.S. Данный пост отправляю на конкурс «Продолжи мысль» от @systems_education в номинацию «Полевой опыт»
#истории_системный_анализ
#продолжи_мысль_SE
История о том, как делать не нужно – а именно выкатывать фронт раньше бэка. И что делать, если это неизбежно
Немного контекста
Работал с продуктом одного банка, где было четкое разделение фронтенд и бэкенд-команд. Я был во фронтенд-команде. По идее аналитики обеих сторон связывают эти части, т.к. высок риск рассинхрона
Однако был один нюанс – бэкенд-команды не было. Ну как, сам бэк с сервисами есть, но его не развивают. Максимум, на что мы могли рассчитывать – один фантомный разраб со стороны банка
Что произошло? 🔥
В работе была огромная фича на весь квартал – новый продукт на фронте со своим отображением. А это новый JSON на 100+ полей со сложными структурами – без бэка не обойтись
Однако бэк делать не торопились, поэтому я писал моки (примеры JSON) на основе дизайна и отдавал своим разработчикам, чтобы им было с чем работать
Подходит конец квартала, в преддверии премии внутренние сотрудники активизировались – появился обещанный бэк-разработчик и сделал свою работу за две недели. Результат: JSON приходит с null полями и ошибками, фронт сломан. На проде 🌾
Исправляли все это еще месяц, пришлось плотно поработать с бэк-разрабом – хотя это нужно было делать до релиза
Можно ли было избежать? 🤔
Спустя время, проанализировал ситуацию, я понял, что нет. Мы не могли предусмотреть, что:
🔴 Команды бэка нет вовсе
🔴 Человек, который в итоге дорабатывал бэк, изначально не должен был этим заниматься
Виной всему политика компании и желание сэкономить на человеческих ресурсах – ничего бы не случилось, если бы разработчика выделили раньше
Но всегда можно свести риск к минимуму
Со своей стороны мы сделали все что смогли (и вам советую):
🟢 Сами разработали моки, работали с ними и их же скидывали бэк-разрабу для понимания итогового результата
🟢 Написали ТЗ для этого разработчика (хотя не должны были)
🟢 Были всегда на связи, отвечали на все вопросы и были открыты к предложениям
🟢 Постоянно подсвечивали разные проблемы и риски заказчику
—————
В таких непредсказуемых ситуациях самое главное – работать честно и на совесть. Отнестись с пониманием и постараться помочь. Тот бэк-разраб тоже стал жертвой ситуации, и винить его было бы глупостью
Поэтому если мы сделали, что могли, но в итоге случился фейл, то знайте – наша вина в этом минимальна. Не стоит зацикливаться – сделали выводы, получили уроки и потом вспоминаем об этом с улыбкой (как и делает моя команда) 😁
По моему мнению, такого процесса быть не должно – бэк нужно готовить раньше фронта или идти параллельно, но не наоборот. Однако IT-мир жесток
⬇ А вы сталкивались с похожими ситуациями? Делитесь в комментариях
————
P.S. Данный пост отправляю на конкурс «Продолжи мысль» от @systems_education в номинацию «Полевой опыт»
#истории_системный_анализ
#продолжи_мысль_SE