Про внутреннюю кухню разработки продукта, ч.2
Про внутреннюю кухню разработки продукта, ч.2
В предыдущем посте (https://t.me/whrdata/2098) на одном маленьком примере с одной строчкой таблицы я начала разворачивать картину того почему продукты делаются не всегда качественно и как это зависит от постановки задачи.
Продолжу распутывать этот клубок
Оригинальный пост канала «Красивая аналитика» @whrdata
Передача задачи в разработку**:
* Заказчику (а обычно совершенно конкректным 1-2м человекам) всегда нужно только «так и никак иначе» и обязательно именно с перламутровыми пуговицами
* Проджект чаще всего на стороне заказчика, т.к. важно чтобы заказчик был доволен
* Дизайн и правда симпатичный
* Продакту нравится дизайн)
Ну и продактов не учат про разработку, внедрение, эксплуатацию и поддержку, их учат делать, а потом смотреть на метрики. Косты не их фокус
* Аналитик все описал как сказали заказчик и продакт ибо «жираф большой — ему видней»
* Разработчику как написали так он и сделал, потому что или он не очень опытен (в hrtech опытные идут редко), или ему все равно. а если найдется тот кто поспорил, то см пункты выше
Итого:
Все при деле, задача ушла в спринт и будет сделана, а заказчик, в моменте, доволен.
Это 1 пункт, от одного заказчика
А теперь представьте сколько появляется таких запросов за год.
Если это 1 внутренняя система внутри 1 компании, то еще как-то можно с этим справиться.
А если это рыночный продукт, у которого десятки заказчиков, то можно себе представить во что со временем превращается продукт внутри.
**Я очень надеюсь, что у моих читателей есть чувство юмора и все понимают, что конечно ни все, ни всё и не всегда так плохо
И, кажется, будет еще третий пост про последствия
