Что, если я не прав относительно того, как нужно выстраивать процессы в команде и разрабатывать продукты? Я уже получил обратную связь о том, что мы (разработка + аналитика) заняты не тем, потому что нужно производить не инструменты и платформы, а производить конечный продукт.

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

Да еще и от более опытных коллег получаю комментарии, что, мол, в реальной жизни все работает не по книжным законам, а по законам реальности. Что, если я не прав, и все эти мои штудии лишены смысла, так как оторваны от объективной реальности?

Исходя из того, что Научные теории недоказуемы, но опровергаемы, получается, что это действительно так :( Даже мой ограниченный опыт показывает, что проекты, разрабатываемые по “книжным” правилам, не взлетают, а вот дендрофекальные конструкции живут и приносят приличную прибыль.

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

Если я буду всю жизнь работать над проектами первого типа, то что я буду есть? А если над проектами второго типа, то как сохранять мотивацию и проф.пригодность? Как можно совмещать работу двух типов?

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

Начать применять на всех уровнях разрабатываемых рабочих продуктов принципы вроде Make it work, make it right, make it fast? Ну, то есть, всегда начинать с костыльных MVP и прототипов, придавая им “правильную” форму и структуру по мере появления новых требований? Но опять же практика показывает, что до улучшений структуры руки редко доходят, так что и это, похоже, неподходящее решение.

Ушел думать дальше…