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

[sukhanchik]

Голосовал за "Нет, не стоит. Пусть себе общается ...".
Согласен с рядом доводов предыдущих участников.
Мое мнение - разработчику на начальном этапе полезно послушать хотелку пользователя. Т.е. именно - послушать. Чтобы знать:
а) исходя из чего строить код, чтобы потом он работал при "доработках".
б) о чем думал консультант при написании ФД/ТЗ - т.е. как это планируется использовать.

Мое мнение поймут те, кто сидит на клиенте или работает для не более 5 внешних клиентов.
Я соглашусь с domandr - если работа ведется одновременно для большего числа внешних клиентов (и соотв приложений). Т.е. разработчик работает одновременно в этих приложениях
Но я тем не менее - хотел бы все равно отметить что на начальном этапе разработчик либо должен сам понимать насколько с его кодом (формой) удобно работать пользователю - и что пользователю не хватает в интерфейсе, либо он должен это услышать сам.
Естественно - после этого - все услышанное будет переварено между сисархитектором, ведущим программистом, консультантом.
Естественно, что некоторая информация от пользователя будет чужа и непонятна разработчику.
Как только ПМ/ведущий разработчик/сисархитектор убеждаются - что чел в состоянии самостоятельно написать нормальный интерфейс (ТЗ ТЗой - но всего не опишешь за приемлемое время - помним о правиле 20 на 80) - то разработчик может уже не общаться - ТЗ вполне будет достаточно

[mazzy]

Цитата:

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

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

Согласен.

Я не понимаю почему вдруг пошло противопоставление "работа на клиенте", "работа для большого числа внешних клиентов". И в том, и в другом случае с получившимся кодом будут работать люди - пользователи.

Причем подразумевается, что на одном клиенте программист может пообщаться с пользователем (код получается более качественный), а при работе с несколькими не может (типа правила такие, но за код никто не отвечает. "К гульфику претензии есть?")

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

Мне кажется, что разговор уходит в сторону. На вопрос "Cтоит ли программистов огораживать консультантами от пользователей?" получаем ответ "а по другому работать невозможно". Как это невозможно, если "на клиентах" так работают? Если имеется в виду, что "невозможно на крупных проектах из-за организации труда", то может сменить организацию труда?

Насколько я понимаю, вопрос распадается на несколько:
1. Приводит ли общение программиста с пользователями к снижению общих затрат на внедрение? Насколько и при каких условиях?
2. Можно ли организовать работу программиста таким образом, чтобы не исключать общение программиста с пользователями?

Причем, второй вопрос зависит из первого.

[domandr]

Цитата:

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

Насколько я понимаю, вопрос распадается на несколько:
1. Приводит ли общение программиста с пользователями к снижению общих затрат на внедрение? Насколько и при каких условиях?

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

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

Цитата:

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

2. Можно ли организовать работу программиста таким образом, чтобы не исключать общение программиста с пользователями?

Причем, второй вопрос зависит из первого.

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

[mazzy]

Цитата:

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

...Что здесь будет делать программист?...

Понятия не имею.
Как ваш вопрос связан с темой: "Cтоит ли программистов огораживать консультантами от пользователей?"

Цитата:

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

А почему программист из ТЗ не поймет что от него хотят, или ему не сможет рассказать консултант.

А это как раз по теме этой ветки.
А вы как считаете, почему?

Цитата:

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

если не может рассказать консультант - то это проблемы консултанта

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

Цитата:

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

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

Предположим, что вы правы.
Предплолжим, что пользователю нет дела до программиста.

И как это ваше рассуждение влияет на тему ветки: Cтоит ли программистов огораживать консультантами от пользователей? Если "пользователю нет дела", то и ограждать не нужно. Не так ли?

[domandr]

Цитата:

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

Предположим, что вы правы.
Предплолжим, что пользователю нет дела до программиста.

И как это ваше рассуждение влияет на тему ветки: Cтоит ли программистов огораживать консультантами от пользователей? Если "пользователю нет дела", то и ограждать не нужно. Не так ли?

Я говорил про этап внедрения. Есть еще этап сопровождения. (в тех 2-х вопросах Вы его не упомянули) Здесь общаться программисту с пользователем тоже не нужно - первоначально анализирует ситуацию опять же консультант.

[mazzy]

Цитата:

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

Я говорил про этап внедрения. Есть еще этап сопровождения. (в тех 2-х вопросах Вы его не упомянули) Здесь общаться программисту с пользователем тоже не нужно - первоначально анализирует ситуацию опять же консультант.

А в этом случае чьи проблемы, если "консультант не смог рассказать"?

Хорошо уточню вопрос.

Насколько я понимаю, вопрос распадается на несколько:
1. Приводит ли общение программиста с пользователями к снижению общих затрат на владение? Насколько и при каких условиях?
2. Можно ли организовать работу программиста таким образом, чтобы не исключать общение программиста с пользователями?


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

Так?

[domandr]

Цитата:

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

Насколько я понимаю, вопрос распадается на несколько:
1. Приводит ли общение программиста с пользователями к снижению общих затрат на владение? Насколько и при каких условиях?
2. Можно ли организовать работу программиста таким образом, чтобы не исключать общение программиста с пользователями?

Так?

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

[domandr]

Цитата:

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

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

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

[mazzy]

Цитата:

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

Вынуждаете отвечать вопросом на вопрос.

Зачем отвечать вопросом на вопрос?

Цитата:

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

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

Не знаю зачем вы об этом спрашиваете.
И как ваши вопросы относятся к теме "Cтоит ли программистов огораживать консультантами от пользователей?"

Цитата:

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

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

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

Мое мнение:

Цитата:

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

Я считаю, что не стоит программистов огораживать консультантами от пользователей.

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

Насколько я понимаю, вы считаете, что общение программиста с пользователем ни к чему конструктивному не приведет ни при каких условиях. Так?
Вы считаете, что программисту ВСЮ существенную информацию "передал консультант". Так? А если не передал? Смог узнать, но не передал.

Я еще раз хочу обратить ваше внимание на исходную формулировку темы.
"Cтоит ли программистов огораживать консультантами от пользователей?"

Вы же сейчас ведете себя как настоящий консультант и обсуждаете вопрос
"Нужно ли проводить второе обследование с программистом"

Пожалуйста, ощутите разницу.

[Ruff]

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

Цитата:

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

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

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

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

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

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

[domandr]

Цитата:

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

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

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

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

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

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

[mazzy]

Цитата:

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

Важно найти золотое сечение...
Пока можно накидать так - возможно развитие этого...

Погодите накидывать.

Чтобы найти золотое сечение "Cтоит ли программистов огораживать консультантами от пользователей?"
Поначалу вы четко говорили, что "огородить и не пущать ни в коем случае".
У вас спрашивают "почему?".
Как огораживание программистов поможет найти золотое сечение?

[domandr]

Цитата:

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

Погодите накидывать.

Чтобы найти золотое сечение "Cтоит ли программистов огораживать консультантами от пользователей?"
Поначалу вы четко говорили, что "огородить и не пущать ни в коем случае".
У вас спрашивают "почему?".

Теперь вы говорите про поиск "сечения"... Как бы вы ответили на исходный вопрос сейчас?

Золотое сечение людей-пользователей и людей-ерпшников. Я остаюсь на первоначальной позиции. Кроме того при построении методологии участвует модное ныне словечко "реинжениринг бизнес-процессов" и плюс управление качеством. Все это исключает общение пользователей и программистов.

[RedFox]

Цитата:

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

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

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

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

[mazzy]

Цитата:

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

При этом были доводы различной направленности и содержания.

Можно ли попросить привести цитаты доводов?

[Ruff]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[RedFox]

Цитата:

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

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

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

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

Цитата:

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

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

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

[RedFox]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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


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