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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[domandr]

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

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


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

Так?

[domandr]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Мое мнение:

Цитата:

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

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

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

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

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

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

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

[domandr]

Цитата:

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

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

Так?

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

[mazzy]

Цитата:

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

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

Неужели результатом общения может быть ТОЛЬКО упущенная выгода (в виде ненаписанного кода)?
Могут быть другие результаты общения программиста и пользователя?

[domandr]

Цитата:

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

Неужели результатом общения может быть ТОЛЬКО упущенная выгода (в виде ненаписанного кода)?
Могут быть другие результаты общения программиста и пользователя?

Пока так приходят с ходу:
1. программист может - попросту самостоятельно подправить код и нарушить работу системы в целом или нарушить планы своих коллег по цеху. Тут ущерб на каждом предприятии свой. Хотя я его тоже могу рассчитать.
2. Если же пользователь общается к программисту на прямую - а потом программист общается с консултантом. А все решается банально консультантом настройками или беседой с пользователем. Тут опять упущенная выгода - потраченное зря время программиста.
3. и не много оффтоп результатом общения программиста и пользователя - может также быть объединение с целью создать семью, ограбить банк, сходить просто попить пива.

[Ruff]

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

Цитата:

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

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

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

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

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

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

[domandr]

Цитата:

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

[domandr]

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

Все это исключает общение пользователей и программистов.

Почему?

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

[kashperuk]

Цитата:

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

Вы точно чего-то не допонимаете, либы вы многие здесь совмещаете должности консультанта и программиста.
Программист не контактирует с пользователем никак. И он оперирует только техническими терминами (таблица, ракурс, функция, объект, форма и т.д.) -

Это как раз кодеры, хорошие, но все таки кодеры.

Не совсем вписывается сюда звание MCBMSP - DAX Developer - если посмотреть список экзаменов на выбор, видим, что из них 3 - по функционалу. То есть хорошему разрабочкику рекомендуют изучать функционал, и больше, чем на уровне таблиц и форм.

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

Выбрал 3ий пункт.
Всегда на проектах любил послушать, что есть умного сказать у пользователя.
Но когда кто-нибудь из них просил что-то сделать, перенаправлял к консультанту.
ИМХО, правильный вариант.

[domandr]

Цитата:

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

Почему?

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

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

[denm]

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

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

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

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

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

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

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

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


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

[mazzy]

Цитата:

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

Складывается впечатление, что я говорю не по теме?

У меня - да.

Цитата:

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

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

Аргументов я не видел.
Были туманные упоминания, что есть экономические, психологические и другие аргументы.
Самих аргументов не видел.

Цитата:

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

Вы просто добиваете меня одним и тем же вопросом, сами не прислушиваетесь к ответам.

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

Цитата:

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

Никаких вразумительных контраргументов я пока не услышал.

Почему вы хотите контрарументов?
Смотрите:
1. есть вопрос
2. у вас есть мнение (ответ).
3. ваше мнение достаточно интересно и практично
4. хотелось бы понять на чем основано ваше мнение

Какие "контрарументы"? Вы можете объяснить свою точку зрения или нет?


Цитирую ваши ответы:

Цитата:

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

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

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

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

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

"Весь западный (хотел сказать и российский) консалтинг так работает. Это должен знать прожект-менеджер."

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

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

"Резюме на этапе ВНЕДРЕНИЯ (ну как поставлен вопрос) привлекать программиста дешевле только под написание разработок"

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

"Есть в управленческом учете понятие "релевантных затрат(доходов)"..."

Так почему стоит ограждать программиста?

[mazzy]

Цитата:

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

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

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

[RedFox]

Цитата:

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

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

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

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

[mazzy]

Цитата:

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

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

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