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

Я проанализировал данные на SQL, не выявил очевидных недостатков и предположил, что проблема в коде. Пошел смотреть  и действительно нашел, на первый взгляд, недостаток. Написал ТЗ на исправление.

Однако когда мы начали разбирать это с командой, пришёл продакт и объяснил: решение было построено именно так намеренно, и на это есть логичное обоснование - хотя технически это выглядело как баг.

Я вернулся к данным и, что делаю нечасто, начал сопоставлять их вручную на уровне каждого отдельного продукта. Оказалось, что для части продуктов средневзвешенных цен просто не существует - отсюда и пустые значения.

Вопрос, который остался открытым - как понять, что это единственная причина, а не одна из нескольких? Пока однозначного ответа у меня нет - разбираюсь дальше.

Но именно этот случай в очередной раз подтвердил для меня главный принцип:

без понимания бизнес-контекста код решает не ту задачу.

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

Важно разбираться какие бизнес-процессы стоят за этими данными, без этого никуда.

Бывает, что решение выглядит логически корректным с точки зрения данных и систем. Но вот приходит продакт и объясняет, что оно изначально строилось из бизнес-логики. И то, что я принимаю за ошибку, на деле оказывается фичей.

Отсюда вывод - ни одно решение не работает «само по себе»

Я могу легко написать SQL или Python-код для исправления бага, но это не приведет к нужному результату если я не разобрался в бизнес-смыслах.

#системныйаналитик #бизнесанализ #данные #sql #аналитика #продуктоваяразработка #it