Как одно бизнес-требование чуть не сорвало интеграцию двух больших компаний. Рассказываю, что нас спасло

[Vera-K]

А при таком подходе клиенту не приходится слишком часто погружаться в поставленную задачу? Или на то и расчет?

[arkady_landpro]

Да, все верно. Местами процессы именно на это и направлены, чтобы потом не было ощущения что он видит это в первый раз и начинает предлагать как сделать получше “Поиграйтие со шрифтами/цветом/логикой и еще чем-нибудь только поиграйте”

[gordienkodmitry3773]

Охереть не встатать, то есть всем этим "тру программистам" что бы вставить возможность смены адреса доставки нужно пол года? и 10, ДЕСЯТЬ, то есть это минимум 15 человек (1.5 тела на команду) искали как это исправить, вы сами себя слышите? И это еще не говоря о том, что вся эта куча народа, со своими табутасками не смогла провести мысленный эксперимент а точно ли это не понадобиться и эта функция не нужна

[arkady_landpro]

Со стороны и правда выглядит курьезно, но тут все сильно же зависит от размера продукта и того на какие сервисы аффектит данное изменение. Чем больше продукт, тем тяжелее вносить архитектурные правки.

Плюс уточню, речь не о смене адреса доставки, а именно о сдаче заказа в рандомный пункт.

[zuekliza]

Вынуждена встать на сторону автора. Чем "жирнее" система, тем тяжелее вносить правки. У нас из последних проектов - казалось бы тупое изменение вида продукта в одном из типов заказов (не яблоки поштучно за n-рублей, а, как пример - носки с бесплатной доставкой и с другого склада). Я б сказала, что ящик пандоры открыли... Аффектнуло 4 системы, за которые отвечают 4 разных команды. И вопрос не только в самих системах, ещё и привет законодательным изменениям.

[arkady_landpro]

Вот здесь было плюс минус тоже самое произошло.

[udovenka]

А где статусную модель подглядели?

[arkady_landpro]

Даже уже и не вспомню, потому как видел много разных вариантов и везде по чуть-чуть брал того что решало именно нашу задачу.

[horn313]

Как вы продумываете отклонение на этапе бизнес-требований? Продукта ведь еще нет

[arkady_landpro]

Здесь сильно помогает написание юзкейсов, причем что важно каждый шаг юзкейса нужно максимально упрощать. Например: проверка двух условий, это два шага, а не один как часто делают.

Так вот в таком формате мы описываем основной сценарий, а потом уже идешь по нему и на каждом шаге задаешься вопросом, а что может пойти не так. Таким образом получается выявить большую часть возможных отклонений.

Ну и это работает как для системных требований, так и для бизнес требований.

[cyber_siberian]

Спасибо, интересный кейс, а главное жизненный в разрезе корпоратов)) Вот только вопрос возник — как и где вы подбираете проджектов в команду? Выглядит так, что человек должен быть минимум с опытом разработки, чтобы органично встроиться в ваши процессы

[arkady_landpro]

Работаем с рекрутинговым агентством, они как-то с этим справляются. Детали подсказать не смогу, так как это их процесс.

А что касается опыта разработки, если вы говорите о том что он должен иметь опыт написания кода, нет. А вот системное мышление, вот без этого у нас не зедерживаются.