Комментарии 8
А по-моему всё проще. Если разработчики могут eat your own dogfood (пусть даже и через proxy), то проект будет жить (если его интенсивно не закапывать). Если разработчики не могут видеть результаты своей работы, проект будет делать то, что написано в проектной документации максимально энтропийным методом.
Вот представьте себе, например, разработчиков, которые пишут git. Они им пользуются каждый день и очень, очень хорошо понимают что там происходит. Зачем, как, что там за WTF'ы и какие из проблем являются теоретически не решаемыми, а какие можно попытаться решить.
А теперь сравните их с разработчиками автоматизированной системы управления качеством сотрудников бухгалтерии отеля. И сколько из них имеет отели под рукой? А сколько из них имеет представление о существовании там бухгалтерии?
А сейчас я работаю в точности как описано в статье, «на фабрике», пишу код по ТЗ, спускаемым сверху, пользователей не вижу (от меня до них с десяток разных уровней), и, если честно, то что получается мне не нравится совершенно — унылая какашка с древним и глючным интерфейсом. А что там под капотом твориться — это дичь и набор всех известных антипаттернов.
С пользователями общаться это хорошо, так программисты постигают смысл своего кода. Единственный момент, что руководством и прочими окружающими такой вариант взаимодействия воспринимается ближе к обслуживанию программы, а не развитию, и соответственно оплачивается поменьше.
Но вот именно в плане погруженности в проект, вариант с прямым общением выигрывает, лучше понимаешь что и зачем ты делаешь.
>пользователи разные, бывают довольно проблемные, токсичные.
Так это половина смыслов и есть, если не больше. Если из трех составляющих причин провалов - руководитель, программист, пользователь - исключить одну - руководителя, то причин остается две. Ну а если программист умный (бывает и наоборот, я за то, что дураков везде хватает), то причина остается ровна одна.
Вспомнилась "притча" об увеличении на порядок стоимости устранения ошибки на каждом следующем этапе процесса.
Руководить людьми/производством это тяжелый квалифицированный труд, результат (и оценка качества) которого отложен во времени. И за это время веделяют себе зарплаты, опционы, служебные квартиры/транспорт. А когда выясняется, что затраты на управленческое звено не пропорциональны качеству управления рядовые сотрудники должны компенсировать это переработками, костылями в коде, да и просто работой не по опыту/квалификации (вспомнил Боинг).
Разработчики не могут исправить ошибки управленцев