Проголосовал за 3й пункт.
Не удержусь и обосную свой ответ.
Имхо, у программиста есть несколько путей развития.
1. Стать мега-спецом и рюхом системы. Знать, при этом, очень много об архитектуре, о БД, об оптимизации и миграции (данных, приложений). И - не развивать свои коммуникативные навыки настолько, чтобы общаться с пользователями. Или просто не хотеть общаться с пользователями.
2. Стать программистом, который может общаться с пользователями (и, может быть, в последствии консультантом). Для этого, программисту (или ведущему программисту) можно, а часто и нужно общаться с конечными пользователями. Т.е. к тому времени, когда программист дорастает до того уровня, когда он легко и ненавязчиво может написать свой модуль в Аксе или переписать себестоимость - он может позволить себе заниматься чем-то другим, без ущерба своим обязанностям и ответственностям. И развивать какие-то дополнительные навыки и получать новый опыт.
Возможны и другие пути, но, ИМХО, они могут быть сведены к первым двум пунктам.
Оба пути заслуживают уважения и не являются легкими.
Сам, когда-то, пошел по второму пути. И слава Богу в нашей Компании - это никогда не запрещалось делать. Если человеку это интересно, и это может принести какие-то новые value Компании, команде, клиенту и самому человеку - то почему бы и нет?
Домандр, хочу сказать по поводу методологии. Методология - не панацея. Она, конечно, является кристаллизацией опыта и ошибок с целью их недопущения в будущем. Но - мы же работаем в консалтинге. А этот бизнес не может быть основан только на шаблонах. Как вы говорите, есть такое модное словечко cases.
Так вот - бывают частные случаи, которые подразумевают некоторую модификацию методологии с целью достижения наилучшего результата.
Опять же. Есть программист - должность. И есть программист - роль. Так вот, человек может выполнять на проекте несколько ролей, и это не запрещается методологией.
Очевидно, что есть оговорки к тому, что сказано выше:
- программист должен быть достаточно опытным и понимать систему на должном уровне, чтобы говорить с пользователями на одном языке
- на любом проекте необходим перекрестный контроль, для того, чтобы исключить human relative risks. ведь все мы люди и имеем свойство ошибаться
- программист сам должен хотеть заниматься тем, что не записано в его должностных обязанностях
- это не должно влиять на результативность программиста в отношении его основным обязанностей
...
- добавьте по вкусу
)))
Одно замечание - по ходу обсуждения, мне показалось, что как-то понятия подменяются. Обсуждается - может или не может программист общаться с пользователем. А в доводах что угодно - и какие консультанты редиски, и как программеры могут зафакапить что-то... и качество ФД (или ТЗ) и методология, и международный опыт...