Про внутреннюю кухню разработки продукта, ч.2

Про внутреннюю кухню разработки продукта, ч.2

В предыдущем посте на одном маленьком примере с одной строчкой таблицы я начала разворачивать картину того почему продукты делаются не всегда качественно и как это зависит от постановки задачи.

Продолжу распутывать этот клубок

Оригинальный пост канала "Красивая аналитика" @whrdata

Передача задачи в разработку**: * Заказчику (а обычно совершенно конкректным 1-2м человекам) всегда нужно только "так и никак иначе" и обязательно именно с перламутровыми пуговицами * Проджект чаще всего на стороне заказчика, т.к. важно чтобы заказчик был доволен * Дизайн и правда симпатичный * Продакту нравится дизайн) Ну и продактов не учат про разработку, внедрение, эксплуатацию и поддержку, их учат делать, а потом смотреть на метрики. Косты не их фокус * Аналитик все описал как сказали заказчик и продакт ибо "жираф большой - ему видней" * Разработчику как написали так он и сделал, потому что или он не очень опытен (в hrtech опытные идут редко), или ему все равно. а если найдется тот кто поспорил, то см пункты выше

Итого: Все при деле, задача ушла в спринт и будет сделана, а заказчик, в моменте, доволен.

Это 1 пункт, от одного заказчика А теперь представьте сколько появляется таких запросов за год. Если это 1 внутренняя система внутри 1 компании, то еще как-то можно с этим справиться. А если это рыночный продукт, у которого десятки заказчиков, то можно себе представить во что со временем превращается продукт внутри.

**Я очень надеюсь, что у моих читателей есть чувство юмора и все понимают, что конечно ни все, ни всё и не всегда так плохо

И, кажется, будет еще третий пост про последствия