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

3 недели назад моя продуктовая группа взялась за оценку ущерба. Подсчитали - прослезились. Периодически делаем теперь reality checks, привлекая наших клиентов и sales staff. Ну и что? Сегодня, за 3 недели до официальной сдачи, выяснилось, что народ хочет немного другого, и та гибкая функциональность, которую напихали программисты, нафиг не нужна.

PS. Из серьёзных советов из Getting Real можно найти только один главный: надо уметь делать быстрые итерации. (По этому принципу был построен мой старый бизнес, и теперь, в моей новой компании со штатом в 25 раз больше, я насаждаю тот же принцип). Но это недёшево.

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

В представленный список маразмов можно добавить еще возможность гибкой настройки и поиск максимально гибкого решения и то и другое приводит к пагубным последствиям. (как не программист)

Все остальное говорю как участник процесса со стороны программистов.

Все хорошо в меру, комбинация организационного и творческого решения проблем, лучший тому пример. Помимо разработки ИТ подразделениям нужно осваивать и новые подобласти применения продукта.

Вот она. Побежал заказывать.