Видно что статью писал разработчик со своего масштаба задачи. Все всегда идет от задач конкретного бизнеса, ведь это бизнес платит деньги разработке, а не разработка сама себе. Обычно на крупном, серьезном проекте/продукте есть большая бизнес-задача, которая декомпозируется на команду или команды, таким образом получается много разного типа задач, которые подвязаны к одной бизнес задаче. И обычно, чисто технических задач, типа: написать код, провести код-ревью, не больше 20% , остальные 80% - это не чисто технические задачи, и разработчик(типа автора) не будет их выполнять т.к. если его попросить за все это отвечать он на 2ой день уволиться. Этого не понимают многие разрабы т.к. смотрят со своей колокольни. Плюс ко всему автор сделал явные ошибки:
1)Не можете осуществить декомпозицию крупных технических задач.
Еще как может. Обычно этого не могут разработчики т.к. не понимают всей логики решения.
Не можете адекватно расставить приоритеты задачам.
Приоритеты расставляет Бизнес, владелец продукта, разработчик о приоритетах обычно ничего не знает. ну и тд.
Так же хороший архитектор не обязан знать всех языков программирования, но не всякий разработчик является хорошим архитектором. Так что архитектуру разработчикам я бы не стал доверять полностью.
Видно что статью писал разработчик со своего масштаба задачи.
Все всегда идет от задач конкретного бизнеса, ведь это бизнес платит деньги разработке, а не разработка сама себе.
Обычно на крупном, серьезном проекте/продукте есть большая бизнес-задача, которая декомпозируется на команду или команды, таким образом получается много разного типа задач, которые подвязаны к одной бизнес задаче.
И обычно, чисто технических задач, типа: написать код, провести код-ревью, не больше 20% , остальные 80% - это не чисто технические задачи, и разработчик(типа автора) не будет их выполнять т.к. если его попросить за все это отвечать он на 2ой день уволиться.
Этого не понимают многие разрабы т.к. смотрят со своей колокольни.
Плюс ко всему автор сделал явные ошибки:
1)Не можете осуществить декомпозицию крупных технических задач.
Еще как может. Обычно этого не могут разработчики т.к. не понимают всей логики решения.
Не можете адекватно расставить приоритеты задачам.
Приоритеты расставляет Бизнес, владелец продукта, разработчик о приоритетах обычно ничего не знает. ну и тд.
Так же хороший архитектор не обязан знать всех языков программирования, но не всякий разработчик является хорошим архитектором. Так что архитектуру разработчикам я бы не стал доверять полностью.