Cтоит ли программистов огораживать консультантами от пользователей?

[domandr]

Цитата:

Сообщение от mazzy

Разве? А разве это не проблемы пользователя/заказчика, который остался с такой реализацией про которую не смог рассказать консультант?

Вынуждаете отвечать вопросом на вопрос.
А чем пользователь думал когда подписывал проектную документацию?
А как пройдет этап тестирования (пользователем), если будет кривая реализация?
А как пройдет этап обучения пользователя, если будет кривая реализация?
А как пользователь подпишет АКТ выполненных работ, если будет кривая реализация?
И самый главный вопрос:
И чем программист поможет на этом этапе общением с пользователем (если про это не смог узнать консультант, который во всем этом варится. Неужели вторым (очередным) собеседованием с пользователем, после чего он все услышенное записывает и анализирует что ему передал консультант.)?

[Ruff]

domandr, в начале этой ветки с Вами было интересно дискутировать. Ваши доводы были вполне обоснованными (хотя выводы, ИМХО, сомнительными). Но вот после этого сообщения (цитирую избирательно):

Цитата:

Сообщение от domandr

...
1. Он говорить с клиентом не может, так как он программист,
...
еще больше напугает.
...
психологически действует на человека-клиента
...
1 из них сидит и молчит
...
До программиста, ему не будет дела, он ведь только молчит
...
вы говорите с ним на не понятном языке

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

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

Вобщем, скажу так - если не может, или не хочет программист общаться с пользователем, то и не надо. Не заставлять же! А если может, и это приносит плоды, то зачем отказываться - не понимаю? Только "для порядку"?
В ИТ сфере и сфере консалтинга персонал - залог успеха. Беречь его надо и давать развиваться, а не ограничивать до уровня "винтиков" или, как Вы выразились, "кирпичиков".

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

[domandr]

Цитата:

Сообщение от Ruff

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

Не собираюсь критиковать никого. Давайте попробуем подойти фундаментально:
Психология:
Есть люди-ERPшники;
Есть представители клиента;
Важно найти золотое сечение - чтобы контакт (читай проект и сопровождение) был успешным!

Экономика организации
Цель - получить оптимальную прибыль с учетом дефицитных ресурсов (пусть будет персонал и время);

Менеджмент
Есть методология внедрения ERP
Которая помогает решить данные задачи.

Пока можно накидать так - возможно развитие этого...

[RedFox]

Цитата:

Сообщение от Ruff

domandr, в начале этой ветки с Вами было интересно дискутировать. Ваши доводы были вполне обоснованными (хотя выводы, ИМХО, сомнительными). Но вот после этого сообщения (цитирую избирательно):

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

Вы знаете, я всегда думал, что программист должен знать систему изнутри и сделать решение лучше и оптимальнее. А консультант должен проанализировать функционал, переложить задачу на него и понять где этот функционал не покрывает требования.

И хоть это может показаться глупо, но всегда думал, что каждый должен заниматься своим делом. Исходя из функциональных обязанностей можно определить кто что должен делать. Иногда были случаи, когда начинающие консультанты или программеры такое предлагали, что ни в какие рамки не лезло ни по срокам, ни по объемам работ, ни по стоимости, ни по кастомизации. Но зато приятными для клиента словами. А потом клиент говорит, что тот человек предлагал сделать так красиво и ... А Вы тут мне сказки рассказываете, что нельзя добавить или что-то не использовать.
Но программер совершенно не знал функционала + гранулы в лицензии.
Поэтому 100% поддерживаю доводы domandr. Они разумны и понятны.

Цитата:

Скажу о себе. Я НЕ совмещал, и на текущий момент НЕ совмещаю должности программиста и консультанта. И на начальном этапе на встречах с пользователями действительно по большей части помалкивал и впитывал информацию. Не вижу в этом ничего криминального.

Вы когда-нибудь были на важной встрече, где пару человек тупо сидит и молчит. Через пол-часа, например у меня и моих знакомых возникает некий дискомфорт по поводу этого человека.

Цитата:

Для начального накопления знаний о предметной области это, с моей точки зрения, поэффективнее, чем слушать на тренингах про расположение галочек и кнопочек в настройках модулей.

А программера никто и не заставляет это делать. А для консультанта есть должность - младший консультант, которому дается область работ, которые не критичны для реализации бизнес-процесса.

Цитата:

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

Разделите этапы подготовки, внедрения, поддержки. И когда работает несколько человек на проекте, даже пара логистик-финансист, то важна субординация и документирование, а не хаотические изменение кода.
А программеры обычно не хотят что-то фиксировать на бумаге - сделали и забыли..
А потом возникает версионность, отказы работы функционала, присутствие момента синхронизации из-за лага времени по тестированию...

Цитата:

Вобщем, скажу так - если не может, или не хочет программист общаться с пользователем, то и не надо. Не заставлять же! А если может, и это приносит плоды, то зачем отказываться - не понимаю? Только "для порядку"?
В ИТ сфере и сфере консалтинга персонал - залог успеха. Беречь его надо и давать развиваться, а не ограничивать до уровня "винтиков" или, как Вы выразились, "кирпичиков".

Персонал - 100% залог успеха, но иногда нужно, чтобы делать ограничение в полете мыслей и стандартизация процессов внедрения. И если каждый программист на нескольких проектах будет общаться со всеми заказчиками на всех этапах, то когда ему выполнять свои прямые функциональные обязанности - внести изменения в систему?

Цитата:

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

В данном случае я совершенно не могу понять где здесь частное? Был общий вопрос "ограничивать общение программиста и клиента или нет". На это были приведены доводы с разных сторон. При этом были доводы различной направленности и содержания.

[RedFox]

Цитата:

Сообщение от domandr

Представим такую картину - этап внедрения. Систему рядовые пользователи не видели. Только слухи, опасения, кто-то интересуется. Происходит обследование предприятие, изучение его бизнес-процессов, сбор печатных форм и др.
Что здесь будет делать программист? Он увеличивает здесь затраты по проекту?

1. Этап обследования. Со стороны заказчика было принято решение о внедрении. Систему видели единицы. Консультанты собирают информацию для предварительной настройки системы, написании функциональных требований к системе, анализу покрытия, согласованию объемов, сроков и планов работ и т.д. (данные вещи у каждой организации более-менее одинаковы, но используются разные термины. Поэтому чтобы не уходили в частности и не цеплялись к словам - останавливаюсь).
Тут приходит программист и начинает разговаривать с клиентом. О чем? Зачем? Кто будет оплачивать это время? И каков результат его работы?
Со стороны клиента моя бы реакция была бы "ну очень веселой". И это не мои придуманные доводы, а реальность.
А теперь увеличьте пропорционально кол-ву проектов?

Могут сказать, что "а как-же развитие". Конечно 100% НУЖНО развиваться, но не таким же образом и иногда за счет клиента.

Цитата:

Сообщение от domandr

Достаточно одного или нескольких консультантов. Пользы на этом этапе от программиста ну никакой:
1. Он говорить с клиентом не может, так как он программист,
2. Пользователь толком программисту ничего рассказать не может - он системы не видел, еще не знает что от нее ждать, он напуган, разговорить его программист точно не сможет - а еще больше напугает.

И получаем заранее враждебно-настроенного клиента (-ов), который иногда понять не может зачем ему задают те или иные вопросы. И иногда в таком контексте, что он даже ответить не может, потому что не знает корректного ответа. И иногда начиает рисовать заново програамеру все и описывать на листочке. + складывается мнение дополнительное мнение, что компания не может консультировать.

Цитата:

Сообщение от domandr

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

2. Этап анализ - работа с ПМ, другими консультантами, программистами и прочим персоналом компании. Тут программист может учится сколько хочет и задавать любые вопросы.

Цитата:

Сообщение от domandr

А почему программист из ТЗ не поймет что от него хотят, или ему не сможет рассказать консультант? (если не может рассказать консультант - то это проблемы консультанта - и как вообще он работает консультантом - если не может излагать-передавать свои (чужие) мысли на бумаге и устно?)

После обсуждения формируется дополнительный список вопросов, которые консультант может задать позже у Клиента и перенести в следующую версию спецификации (для это и используется версионность в разработке)

Цитата:

Сообщение от domandr

Все эти отмазки - что-то забыл клиент рассказать консультанту и вдруг программист понял что консультанту что-то забыли рассказать - кажутся глупостью - это опять же низкоквалифицированный консультант - который не разобрался с задачей детально.

Резюме на этапе ВНЕДРЕНИЯ (ну как поставлен вопрос) привлекать программиста дешевле только под написание разработок. а то ведь он должен присутсвовать на обследовании (т.е. 3-й лишний какой-то получается и своим делом не занимается (не пишет программ, и толком общаться с клиентом не получается и увеличивает число беседующих на +1 человека, а ведь ему за это время нужно платить зарплату, да и психологически действует на человека-клиента гнетуще когда с ним беседуют несколько людей (или 1 из них сидит и молчит)). Промолчу про людей, которые совмещают должности (консультанта и программиста).

Этап внедрения.

Цитата:

Сообщение от domandr

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

Достаточно содержательный ответ по этапу внедрения и реакциях клиентов.

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


Итог - каждый должен делать свою работу. Никто не запрещает учиться, но на это нужно время и место. Программисту без знания бизнес-процессов и понимания бизнес-логики нечего делать у Клиента.
А вот исправление "ошибки кодирования" в системе - уточняй сколько хочешь по месту ошибки, только в рамках разумного

[denm]

Проголосовал за 3й пункт.

Не удержусь и обосную свой ответ.

Имхо, у программиста есть несколько путей развития.
1. Стать мега-спецом и рюхом системы. Знать, при этом, очень много об архитектуре, о БД, об оптимизации и миграции (данных, приложений). И - не развивать свои коммуникативные навыки настолько, чтобы общаться с пользователями. Или просто не хотеть общаться с пользователями.

2. Стать программистом, который может общаться с пользователями (и, может быть, в последствии консультантом). Для этого, программисту (или ведущему программисту) можно, а часто и нужно общаться с конечными пользователями. Т.е. к тому времени, когда программист дорастает до того уровня, когда он легко и ненавязчиво может написать свой модуль в Аксе или переписать себестоимость - он может позволить себе заниматься чем-то другим, без ущерба своим обязанностям и ответственностям. И развивать какие-то дополнительные навыки и получать новый опыт.

Возможны и другие пути, но, ИМХО, они могут быть сведены к первым двум пунктам.

Оба пути заслуживают уважения и не являются легкими.
Сам, когда-то, пошел по второму пути. И слава Богу в нашей Компании - это никогда не запрещалось делать. Если человеку это интересно, и это может принести какие-то новые value Компании, команде, клиенту и самому человеку - то почему бы и нет?

Домандр, хочу сказать по поводу методологии. Методология - не панацея. Она, конечно, является кристаллизацией опыта и ошибок с целью их недопущения в будущем. Но - мы же работаем в консалтинге. А этот бизнес не может быть основан только на шаблонах. Как вы говорите, есть такое модное словечко cases. Так вот - бывают частные случаи, которые подразумевают некоторую модификацию методологии с целью достижения наилучшего результата.
Опять же. Есть программист - должность. И есть программист - роль. Так вот, человек может выполнять на проекте несколько ролей, и это не запрещается методологией.

Очевидно, что есть оговорки к тому, что сказано выше:
- программист должен быть достаточно опытным и понимать систему на должном уровне, чтобы говорить с пользователями на одном языке
- на любом проекте необходим перекрестный контроль, для того, чтобы исключить human relative risks. ведь все мы люди и имеем свойство ошибаться
- программист сам должен хотеть заниматься тем, что не записано в его должностных обязанностях
- это не должно влиять на результативность программиста в отношении его основным обязанностей
...
- добавьте по вкусу)))


Одно замечание - по ходу обсуждения, мне показалось, что как-то понятия подменяются. Обсуждается - может или не может программист общаться с пользователем. А в доводах что угодно - и какие консультанты редиски, и как программеры могут зафакапить что-то... и качество ФД (или ТЗ) и методология, и международный опыт...

[mazzy]

Цитата:

Сообщение от denm

Одно замечание - по ходу обсуждения, мне показалось, что как-то понятия подменяются. Обсуждается - может или не может программист общаться с пользователем. А в доводах что угодно - и какие консультанты редиски, и как программеры могут зафакапить что-то... и качество ФД (или ТЗ) и методология, и международный опыт...

Ап-солютно согласен.

[Starling]

Вообще под словом «общаться» можно подразумевать все что угодно. Как я для себя понимаю обсуждаемый вопрос, то речь идет о сборе требований к функциональности системы программистом.
Мое мнение такое: в ходе общения с клиентом программист может выявить такие подводные камни, которые может пропустить консультант. Однако принимать решение о том, как система будет работать должен тендем консультант-программист. При чем консультанту тут отведена более активная роль.

Обещать клиенту программист также ни чего не должен без согласования с консультантом.
И консультант, не согласовав с программистом возможность реализации требования в системе, лучше также ничего не обещать клиенту.

З.Ы.: мне не понятен следующий момент, почему, когда речь заходит о том, что программист не должен общаться с клиентом, некоторые участники дискуссии, решают что отсюда автоматически следующее - программист не должен знать БП. Как по мне то это одна из задач консультанта объяснить программисту для чего нужна модификация.

[RedFox]

Привет.
Рад, что присоединился к обсуджению.

Цитата:

Сообщение от Starling

З.Ы.: мне не понятен следующий момент, почему, когда речь заходит о том, что программист не должен общаться с клиентом, некоторые участники дискуссии, решают что отсюда автоматически следующее - программист не должен знать БП. Как по мне то это одна из задач консультанта объяснить программисту для чего нужна модификация.

Я бы уточнил бы - знать не весь БП, а его часть. Например при импорте товаров в страну (не в систему данных) иногда програаммера совершенно не нужно знать как производится растаможка, если он делает перемещение товаров между складами в зависимости партионности или лотов (приведено как пример)

[longson]

C Starling согласен. Программисту необходимо общаться с пользователями с определённой степенью для того, чтобы понять смысл своей работы, что иногда не может полностью объяснить консультант. Но это не означает что программист получает задание у пользователей - так что общение ни как не приводит к тому, что система будет нецелостной.

Поэтому я считаю что необходимо организовать общение программистов с будущими пользователями системы для того, чтобы программисты лучше понимали технические задания, которые потом пишут для них консультанты, а НЕ для того, чтобы программисты из этих собеседований получали технические задания у конечных пользователей.

[Starling]

Привет

Цитата:

Сообщение от longson

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

Ну я не считаю, что программист должен общаться с пользователями, я считаю если он все таки будет общаться, то "+" в этом больше чем "-".
Хотя с другой стороны консультант (если он профессионал) должен выполнить эту работу быстрее и более качественно.
Итого: я не вижу ничего страшного, если программист будет собирать требования к системе от пользователей. Но более полезным для проекта будет, если консультанты будут общаться с пользователями, а программисты выполнять модификации.

Цитата:

Сообщение от RedFox

Я бы уточнил бы - знать не весь БП, а его часть.

Согласен. Хотя чем лучше программист понимает БП, тем более качественные он делает модификации.

[komar]

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

[Волчара]

Цитата:

Сообщение от komar

На самом деле на вопрос правильного ответа нет. Все зависит от конкретных людей. Но если хочется обобщений - то следует разделить на несколько - стоит ли отгораживать на каком этапе?

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

[blokva]

Проголосовал за "Нет не стоит...", но мое ИМХО посередине между эти мунктом и предыдущим... Я бы свое мнение сформулировал так:
Пока ТЗ не написано и не утверждено, программисту запрещено общение с пользователем.
После того как ТЗ запущено в производство, пусть общаются, НО любое отступление от ТЗ согласовывается с консультантом.

Почему так? Потому, что есть классная мысль кем-то высказанная (не помню), что ...пользователю надо дать не то, что он хочет, а то что ему надо... а реализовать это - есть прямая задача консультанта. Но когда есь ТЗ т.е. на 80% ясно, что надо дать пользователю, то тут уже можно позволить программисту общаться с пользователем для некоторых уточненй тсз.
По поводу кто и что должен знать, то мое ИМХО говорит, что знания всех участников команды, должны перекрывать друг-друга и чем меньше размер команды (о чем уже некоторые говорили) тем сильнее должно быть перекрытие вплоть до "3 в 1" (с).

[Raven Melancholic]

В основном, все мнения идут от лица сотрудников внедренческих фирм. Если интересно, то могу высказать взгляд с другой стороны. Я сам работаю на стороне заказчика. У нас, правда, уже не этап внедрения, а сопровождения и развития. Сам процесс происходит таким образом:
1) Обсуждение с консльтантом нашего партнера новых задач, определение что используем из стандартного функционала, а что дорабатываем. То есть обсуждаем ЗАЧЕМ И ЧТО делаем.
2) Обсуждение с программистом нашего партнера КАКИМ ОБРАЗОМ делаем доработки. Причем, обсуждение идет далеко не только в терминах разработки (на мой взгляд, если программист будет знать бизнес-задачу, то сработает эффективнее.
3) Консультнт и программист у себя уже все обсуждают и партнер выставляет коммерческое предложение.
Результаты такого подхода вполне устраивают нас в отношении сочетания реализованных возможностей и затрат на их достижение. Так что, вопроса, вынесенного в тему у нас даже не возниакет. В итоге, проголосовал за пункт равноправного общения.

[RVS]

IMHO, стараемся придумать то, что давно уже придумано.

Стандартные этапы процесса разработки:

1. формализация бизнес-требований
2. разработка архитектуры решения
3. оценка временнЫх затрат
4. разработка
5. тестирование
6. передача в эксплуатацию

Поправьте, если что забыл из существенного.

Программист (если он "чиста программист") должен принимать участие в п. 2-4 (или 2-5).

Эти пункты не предполагают непосредственного общения с пользователем / заказчиком etc.

Другое дело, что такие "чиста программисты" в области EPR крайне редки, все больше что-то смешанное...

А вообще - еще MS Solution Framework была дивная табличка - какие роли на проекте можно совмещать, а какие - низзя... Так вот, роль программиста там считается несовместимой ни с чем. И неспроста, видимо

Голосую за "в случае крайней необходимости". Исходя из собственного опыта исключительно