Ну да. Самоокупающийся, устойчивый бизнес, преданные клиенты.

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

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

но большой риск обычно окупается экпоненциально

вот поэтому большинство и занимается всякой мелочевкой

Согласен, но имхо вопрос тут в другом: большая часть разработчиков не имеют предпринимательского духа. Им нравится решать технические задачи, ковыряться в технологиях, пробовать новые модные инструменты и т. п.

Есть даже книжка известная о том, что будет, если бразды правления фирмой и, в особенности, проектирование интерфейса отдать на откуп разработчикам. Называется "психбольница в руках пациентов". 😭

Миша, когда запись?

@lolmaus то есть смириться? )

или все-таки развиваться? )

или рассценивать сотрудника как недалекого, способного лишь гайку крутить, без возможности влиять?

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

и чтобы не возникало ситуаций: "ну, лучше я отложу эту задачу, какая-то она бессмысленная (по прошедствию времени это обычно подтверждается)"

вместо того, чтобы высказаться и привести аргументы

> Согласен, но имхо вопрос тут в другом: большая часть разработчиков не имеют предпринимательского духа. Им нравится решать технические задачи, ковыряться в технологиях, пробовать новые модные инструменты и т. п.

как вообще можно провалидировать годность инструмента, не понимая бизнес-задачи, которая решается? Будешь бросаться от одного иструмента к другому, а задачу в итоге не решишь (или решишь, но не ту)

в общем мысль такая: разделение труда в стиле "копай от сюда и до обеда" в разработке программ работает, но очень плохо

человек должен понимать, что он делает и какая цель/идея/задача

только тогда получится продукт

не гауно из палок

Когда именно запись следующего подкаста и с кем?

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