____
4 года в компании, и это уже третья попытка внедрит какие-то умные (нет) способы, чтобы разработка была более предсказуемой))
В этом нет ничего плохого, когда эти способы вводятся грамотно и грамотными людьми.
В 99% случаев - это подход, из разряда, мы не ПО делаем, а могилы копаем. За две недели нужно 10 могил выкопать, если получится меньше - это плохо, нужно наоборот. Факт, что разработка ПО очень непредсказуемая, обычно опускают.
У нас наняли некого "архитектора решении". Человек ни разу не писал код, но говорит разработчикам, как его нужно писать. Ааххзаха бля...
Например, одна из целей этого "архитектора решения" в том, чтобы таски переходили в статус "Готово", если они на проде. На вопрос о том, что делать, если таска на проде, но она не готова, по причине тысячи причин которые есть в это сложной сфере, ответ очень простой: "так быть не может/так не бывает".
Появляются десятки лишних статусов, которые никому не нужны. Есть куча правил, по которым мы должны этими статусами жонглировать. На вопросы "Зачем это?" отвечают, что вот руководство смотрит отчеты, и в отчетах нужно чтобы циферки были красивые. Мол, вот, смотрите, у нас задачи в статусе "разработка" стали находится меньше. Только вот, причина этому - статус "разработка" раздроблен еще на 5 статусов 🤡
Это только малая часть цирка. У нас есть куча бесполезных созвонов, синхронизации, отметок в тасках и т.д.
В приоритете теперь не результат, а красивый отчет, что результат скоро будет. В итоге предыдущие "архитекторы решений" уволены, процессы не налажены, а даже наоборот, деньги компании слиты на зарплаты этих специалистов, ждем следующую итерацию.
____
🔷 Если хотите поделиться жидким кейсом (своим / на работе/ по опыту) — велкоме сюда
🔷 Первый выпуск про фиксацию требований
Продолжаем проводить время с семьей и чиллить 🌟
➡️➡️➡️➡️
#жидкийкейс_os | @OpenSource_ux