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

[domandr]

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

Цитата:

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

... Консультант (который, согласно принципу разделения труда, не сильно разбирается в технических деталях функционала...

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

Цитата:

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

... пишет подробное ТЗ, тратит на это кучу времени, и передает его программисту...

обычно написание ТЗ занимает 5-10% от всей реализации. Грамотный консультант довольно быстро пишет ТЗ. Никто не мешает консультанту на момент принятия решения написать программу, посоветоваться с другими консультантами (а может уже такое есть - зачем придумывать новое), с ПРОГРАММИСТОМ (обсудить возможный алгоритм). Причет программист не контактирует с пользователем никак. И он оперирует только техническими терминами (таблица, ракурс, функция, объект, форма и т.д.) - консультант должен его понимать (если не понимает, то он не консультант - он стажер, и написать ТЗ ему обязательно нужно - пусть он даже потратит на это неделю - потом он будет делать это быстрее, и будет разговаривать с программистом на одном языке).

Цитата:

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

...либо от такой доработки система "ляжет". Занавес, как говорится.
Да, методология с субординацией соблюдены, порядок не нарушен, всё круто...
...

Поверьте никогда такая схема не давала сбоя. Весь мир так работает. Если такое случится - вся ответсвенность на консультанте - у меня бы он не задержался, выпинал бы без рекомендаций.
Да и завалить нужно суметь. или сильно постараться. Вы, Ruff, явно забываете про тестирование - причем, тестовые данные готовит для разработчика опять же консультант. Первоначальное тестирование должно проводится разработчиком, затем консультантом - поставшим задачу. а затем (3 очередь) доходит до пользователя - который дает отмашку все ок. А если уж завалили - то в работу подключится сисадмин.

Программисты - очень важный кирпичик в консалтинге, не должны они выполнять то что делать должны консультаны или прожект-менеджер. У них обычно все время раписано на месяц вперед - и если задач на проекте нет, их с легкостью переводят на другой проект или продают в аутсорсинг. А там как уж получится толи будет Логистика, либо Финансы, либо Зарплата. (функционал будет возможно другой - и он с ним не сталкивался - что не уменьшает нисколько стоимости и уважения данного программиста - по ТЗ он через час начнет уже оперировать техническими элементами. Но разговаривать с пользователем не получится (и о чем с ним ему разговаривать - да ему просто не позволят этого сделать).
Еще хочу уточнить - что написание ТЗ - не впустую потраченное время - оно пригодится для последующих поколений (для других консультантов, программистов - которые возбмут ТЗ с последней редакцией - и все поймут что хотели сделать). Это уже нигде не обсуждаемо - программить без ТЗ - это плохой тон, и руководителя данного проекта, допустившего это надо призерать.
И на последок:
Знакомый из Германии рассказывал, что там людей консультантов и программистов легко различить с первого взгляда. Консультант презентабельный - костюм, галстук и др. Программист, сисадмин - в свитерах (у них нет дресскода - это обслуживающий технический персонал - они общаются только с консультантами ( и то это уже скоро станет редкостью - обычно ТЗ уже пишут на прямую в Индию в оффшор).

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

[MironovI]

Цитата:

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

Звучит как будто консультант - это начальник программиста.

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

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

[oip]

Цитата:

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

Суть.. в том что с для клиента должен быть выделен некий итерфейс - непротиворечивый - и это консультант.. а то никакой политики партии понимаешь не будет...

А консультантов-то несколько бывает...

Цитата:

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

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

Смогу, если посчитаю это в корне неправильным. Прецеденты были.

Цитата:

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

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

Да в общем это и не совсем "консультант" называется... Вернее мне кажется теплое с мягким путаем.

[mazzy]

Цитата:

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

Максимальный эффект дает именно связка "консультант - программист". А это подразумевает не примитивный конвейер "Пользователь - Консультант - ТЗ - Программист", а командную работу (совместные мозговые штурмы, обмен знаниями и т.п.).

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

Цитата:

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

Ребята, а че все я вас учу

Учите?! Ну, у вас и самомнение.

[Ruff]

Цитата:

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

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

Видимо именно так и рождалось чудо-юдо под названием "российская локализация Аксапты". Оперирование техническими терминами приводит к забыванию (непониманию) предметной области, ИМХО. Это же не драйвер устройства написать, здесь люди на первом месте. Аналогия - качественно выучить иностранный язык можно только общаясь с его носителем, каким бы грамотным ни был преподаватель.

Цитата:

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

Поверьте никогда такая схема не давала сбоя. Весь мир так работает.

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

Цитата:

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

Да и завалить нужно суметь. или сильно постараться. Вы, Ruff, явно забываете про тестирование - причем, тестовые данные готовит для разработчика опять же консультант.

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

Цитата:

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

Это уже нигде не обсуждаемо - программить без ТЗ - это плохой тон, и руководителя данного проекта, допустившего это надо призерать.

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

Цитата:

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

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

ОК, признаюсь - я в консалтинге недавно, и сужу с колокольни 3х-летнего опыта работы на стороне клиента (программистом). Там сам бог велел "ходить в народ". Преимущественно это касалось поддержки, но и по вновь возникающим задачам контактировал с пользователями довольно часто.

P.S. Кстати насчет костюмов и свитеров... Однажды мне кто-то из наших пользователей признался, что они попросту боятся общаться с внешними консультантами именно из-за их "важности" и презентабельности (то есть для некоторых людей слово "консультант" воспринимается почти как "ревизор"). И поэтому человек просто начинал путаться в собственных мыслях, подбирая "умные" слова (такие же как у консультанта)... Вобщем-то, смех, но показательно!

P.P.S. Как резюме - я не против "правильных", отработанных схем взаимодействия в команде внедрения. Но с Вашей, domandr, категоричностью ("в корне неверно") не согласен. Правила для того и существуют, чтобы иногда от них отступать

[domandr]

Цитата:

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

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

Все проекты делаются командой - полностью За. Но основная ноша на прожект-менеджере, архитекторе, консультантах.

Цитата:

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

Учите?! Ну, у вас и самомнение.

Ок, рассказываю. Причем придумал это не я.И не надо так скептически к этому относиться. Весь западный (хотел сказать и российский) консалтинг так работает. Это должен знать прожект-менеджер. А Вы, многоуважаемый mazzy, знаете? Такой у меня юмор. И мы похоже уже переходим на личности. Не я первый начал

[RedFox]

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

[KiselevSA]

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

[Владимир Ю.]

Полностью поддерживаю участника domandr.
Я проголосовал за ответ "Полностью оградить", потому что считаю, что общение программиста с пользователем не желательным и даже вредным. Под пользователем, я подразумеваю, человека, который выполняет определенные действия в системе. Такой человек не должен общаться с программистом и тем более ставить ему задачи по изменению функционала. Он не видит общей кртины и не знает, как работает система в целом. Я проработал в консалтинге и на внутреннем проекте. Желание пользователей могу свести к фразе из фильма "Бумбараш" - Эй, художник, нарисуй мне "Кунгуру". По этому такую поставновку задачи от пользователя считаю неприемлимой. В данной формулировке вопроса, как он вынесен на форуме.
Считаю целесообразным общения Разработчика системы и Заказчика системы. Т.к. эти люди много знают о системе с обоих сторон. В этом диалоге участие Консультанта тоже необходимо и свзяка троих даст наиболее большой эффект.
По этому в опросе произошла путаница понятий.
Описанный взгляд только с моей колокольни

[Deep Dreamer]

Цитата:

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

и другим...
Посмотрим что вы будете говорить когда такие супер-спецы "3 в 1" начнут вас теснить с тепленьких насиженных мест...

Не вытеснят, не переживай - консалтинговых контор много

Я внимательно прочитал посты спорящих, и пришёл к выводу, что все мы правы.
Только вот есть одно различие... Некоторые из нас работают в консалтинге, а некоторые - у клиента. У кого-то компания и/или проекты крупные, где много народу, а у кого-то нет. Кто-то внедряет по наитию - больше интуитивно колбасит (в силу размера проекта это позволительно), а кто-то строго по методологии... Да и стоимость проектов разная - у кого-то 80к, а у кого-то 1М. А сроки? Одни 5 месяцев, другие 2 года.

Дело в том, что если ты работаешь у клиента - понятное дело, что ты и жнец, и кузнец и на дуде игрец. ПМ-консультант-проггер в одном лице. Если проект небольшой (положим 3-5 человек внеряет), то программеру тоже можно учавствовать.
Но как только у Вас 8-12 человек внедряет, то тут строгая субординация важна - иначе получится неуправляемый хаос.
Вот и спор идёт...
Жизнь многогранна, ребята. Каждый проект - это отдельная песня, и всё под одну гребёнку за уши не притянешь. Но порядок должен быть во всём, и не важно общается программист с конечным пользователем, или нет.

Лично я считаю (и голосовал), что общаться должен по минимуму (я ж в консалтинге пока, а как к клиенту уйду, буду ратовать за общение)

[fed]

Хотел тиснуть в эту тему все что я думаю по поводу Сертифицированных Проектных Менеджеров с Проверенной Годами Безошибочной Западной Методологией, но потом вспоминил что все эти мысли уже написали без меня: Joel on Software -Биг Маки против "обнаженного шеф-повара"

[Spider]

Проголосовал за "полное ограждение".
Честно говоря, для меня было открытием, что так много AX/NAV-программистов желают общаться с клиентом. Но пришел Deep Dreamer и расставил все по полочкам. Действительно, все зависит от размеров проекта и то, где мы работаем (консалтинг или клиент).

[Prof]

Мне кажется что тут действительно существенно перепуталось теплое и мягкое
Консультант, программист - это не люди а роли. Роль программиста не подразумевает общения с пользователем вообще, поэтому такой вопрос даже не стоит. Если один и тот же человек совмещает обе роли, тогда он должен общаться, это его обязанность.
Если же квалификация его как программиста существенно выше квалификации как консультанта, иными словами говоря, консультант он слабенький или вообще никакой, до пользователя его допускать нельзя. Т.е. роль консультанта еще нужно "заслужить", нельзя просто самого себя на нее определить.
То же касается совмещения ролей ПМ-консультант и т.д.

[komar]

Цитата:

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

Тема выделена отсюда Требуется программистка на X++



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

Если развить тму дальше...стоит ли ограждать поставщика системы партнерами? Получается целая сеть экранов, ограждающая систему от изменения пользователем. Например, пользователь выловил нечто, подобное "утечкам памяти". Пошел процесс:
- консультант
- менеджер проекта
- программист
- менеджер проекта
- служба поддержки
- (возможны несколько итераций между менеджером, консультантом и програмистом и службой поддержки. Особенно хорошо, если есть 2 службы поддержки - у партнера и поставщика - в таком случае дальше процесс скорее всего уже не пойдет)
- кто-то там, кто собирает жалобы, от которых не смогла отмахнуться служба поддержки
- Менеджер, Который Составляет План развития системы на грядущее
- Менеджер программистов
- Постановщик
- Программист
- Тестировщик
- Опять программист
- Еще программист
- (собрали наконец-то версию)
- Еще несколько программистов
- (натянули локальную функциональность)
- служба раздачи дисков партнерам
- (много раз консультанты, программисты и менеджеры партнера, натягивающие кастомизации на версию)
- пользователь
(и полезли глюки, и процесс с самого начала)

Схема немножко упрощенная конечно...

[RedFox]

Цитата:

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

Схема немножко упрощенная конечно...

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

[komar]

Цитата:

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

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

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

[sukhanchik]

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

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

[mazzy]

Цитата:

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

Если развить тму дальше...стоит ли ограждать поставщика системы партнерами?....

Цитата:

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

Да? Речь ведь шла о доработке, которая идет через поставщика системы (большая такая компания) - Вы уверены, что...

Так. Мысль понятная, но ОФФТОПИК дикий.
komar, пожалуйста угомонись. Если интересно, открывай новые ветки.

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

[mazzy]

Цитата:

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

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

Согласен.

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

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

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

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

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

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

[domandr]

Цитата:

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

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

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

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

Цитата:

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

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

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

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