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

[RedFox]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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


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

[Ruff]

Цитата:

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

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

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

Цитата:

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

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

Странно, я всегда считал, что у консультанта должны быть железные нервы. Отвечаю на вопрос - был неоднократно. И сам был в роли "тупо молчащего", и других в такой роли наблюдал. Дискомфорта не было, ибо четко знал, что эти люди здесь не случайно оказались.

Цитата:

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

А программеры обычно не хотят что-то фиксировать...

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

Цитата:

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

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

Опять преувеличиваете. Не справляется с обязанностями - по рукам ему! И не пущать ни на какие встречи и разговоры. Это даже не обсуждается...

Цитата:

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

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

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

Резюме: Грамотный руководитель должен видеть потенциальные способности своих подчиненных, и развивать их с пользой для компании. Все это очень индивидуально. Поэтому команда не должна быть чрезмерно раздутой.
Вот домандр говорил, что не рассматривает случай "2 в одном". То есть универсалы - это полезно и востребованно. А почему бы не вырастить универсала из программиста? На этом можно здорово сэкономить

[RedFox]

Цитата:

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

Полностью согласен. ......

Странно, я всегда считал, что у консультанта должны быть железные нервы.

Согласен, но я как найомный сотрудник, работал консультантом по внедрению. А как МП (не по основному месту работы) - приходилось обсуждать и слушать, внимательно изучать.. И когда приходил человек, который только слушал и ничего не говорил - для меня воспринималось, как то не очень хорошо.
Я конечно понимаю, что это чисто субъективная моя частность, но .. обсуждая иногда вопросы с Заказчиками, чтобы "разрядить обстановку" можно случайно задать вопросы, на который они дадут ответ и не поймут толком зачем это мне. Пару раз я получал "рассказы по этому поводу о потраченном времени клиента на ненужные объяснения".
Повторяю, что я лишь только анализирую свой частный опыт и ничего более

Цитата:

Отвечаю на вопрос - был неоднократно. И сам был в роли "тупо молчащего", и других в такой роли наблюдал. Дискомфорта не было, ибо четко знал, что эти люди здесь не случайно оказались.

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

Начинал я как консультант по логистике, потому финансы, программирование, розница, внешнее ПМ-во. Потом пришлось уйти, потому что в родной конторе мне ПМ-во не светило, о чем мне прямо и заявили ("Ты как универсал-технарь для нас лучше"). Почему универсал - не знаю, но я хочу развиваться...

[RedFox]

...продолжение...

Цитата:

Давайте тогда не доверять сложную работу лицам русской национальности, потому что они все поголовно - пьяницы и тунеядцы .
Опять преувеличиваете. Не справляется с обязанностями - по рукам ему! И не пущать ни на какие встречи и разговоры. Это даже не обсуждается...

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

Зря Вы так про людей? Не надо мешать личности, национальности и роли. Помните? "Люди разные нужны, люди разные важны!"
Да и у каждой национальности есть свои Гитлеры, Гамлеты и Иуды.

Вы совершенно правы. Были попытки расширить область писания. Даже сам Мazzy пытался это сделать (хотя вижу, что за эту запись могу получить сильно по рукам) немного выше.

Цитата:

Резюме: Грамотный руководитель должен видеть потенциальные способности своих подчиненных, и развивать их с пользой для компании. Все это очень индивидуально. Поэтому команда не должна быть чрезмерно раздутой.
Вот домандр говорил, что не рассматривает случай "2 в одном". То есть универсалы - это полезно и востребованно. А почему бы не вырастить универсала из программиста? На этом можно здорово сэкономить

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

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

[Starling]

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

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

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

[longson]

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

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

[RedFox]

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

Цитата:

Сообщение от 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 была дивная табличка - какие роли на проекте можно совмещать, а какие - низзя... Так вот, роль программиста там считается несовместимой ни с чем. И неспроста, видимо

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