Цитата:
Сообщение от
Ruff
domandr, в начале этой ветки с Вами было интересно дискутировать. Ваши доводы были вполне обоснованными (хотя выводы, ИМХО, сомнительными). Но вот после этого сообщения (цитирую избирательно):
складывается впечатление, что Вам катастрофически не везло с программистами
(Воспринимайте это как шутку, хотя судя по общему тону сообщения, в ней велика доля правды).
Вы знаете, я всегда думал, что программист должен знать систему изнутри и сделать решение лучше и оптимальнее. А консультант должен проанализировать функционал, переложить задачу на него и понять где этот функционал не покрывает требования.
И хоть это может показаться глупо, но всегда думал, что каждый должен заниматься своим делом. Исходя из функциональных обязанностей можно определить кто что должен делать. Иногда были случаи, когда начинающие консультанты или программеры такое предлагали, что ни в какие рамки не лезло ни по срокам, ни по объемам работ, ни по стоимости, ни по кастомизации. Но зато приятными для клиента словами. А потом клиент говорит, что тот человек предлагал сделать так красиво и ... А Вы тут мне сказки рассказываете, что нельзя добавить или что-то не использовать.
Но программер совершенно не знал функционала + гранулы в лицензии.
Поэтому 100% поддерживаю доводы domandr. Они разумны и понятны.
Цитата:
Скажу о себе. Я НЕ совмещал, и на текущий момент НЕ совмещаю должности программиста и консультанта. И на начальном этапе на встречах с пользователями действительно по большей части помалкивал и впитывал информацию. Не вижу в этом ничего криминального.
Вы когда-нибудь были на важной встрече, где пару человек тупо сидит и молчит. Через пол-часа, например у меня и моих знакомых возникает некий дискомфорт по поводу этого человека.
Цитата:
Для начального накопления знаний о предметной области это, с моей точки зрения, поэффективнее, чем слушать на тренингах про расположение галочек и кнопочек в настройках модулей.
А программера никто и не заставляет это делать. А для консультанта есть должность - младший консультант, которому дается область работ, которые не критичны для реализации бизнес-процесса.
Цитата:
Но это не помешало в дальнейшем (когда опыт уже был приобретен) тем же самым пользователям эффективно контактировать со мной и с участием консультантов, и напрямую, и на этапе внедрения, и на этапе поддержки.
Разделите этапы подготовки, внедрения, поддержки. И когда работает несколько человек на проекте, даже пара логистик-финансист, то важна субординация и документирование, а не хаотические изменение кода.
А программеры обычно не хотят что-то фиксировать на бумаге - сделали и забыли..
А потом возникает версионность, отказы работы функционала, присутствие момента синхронизации из-за лага времени по тестированию...
Цитата:
Вобщем, скажу так - если не может, или не хочет программист общаться с пользователем, то и не надо. Не заставлять же!
А если может, и это приносит плоды, то зачем отказываться - не понимаю? Только "для порядку"?
В ИТ сфере и сфере консалтинга персонал - залог успеха. Беречь его надо и давать развиваться, а не ограничивать до уровня "винтиков" или, как Вы выразились, "кирпичиков".
Персонал - 100% залог успеха, но иногда нужно, чтобы делать ограничение в полете мыслей и стандартизация процессов внедрения. И если каждый программист на нескольких проектах будет общаться со всеми заказчиками на всех этапах, то когда ему выполнять свои прямые функциональные обязанности - внести изменения в систему?
Цитата:
В чем я не прав, domandr? С удовольствием выслушаю обоснованную критику, а то как-то Ваша аргументация в последних постах стала менее убедительной (идёте от частного к общему).
В данном случае я совершенно не могу понять где здесь частное? Был общий вопрос "ограничивать общение программиста и клиента или нет". На это были приведены доводы с разных сторон. При этом были доводы различной направленности и содержания.