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

[Ruff]

Цитата:

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

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

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

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

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

Простой пример, когда огораживание вредно:
Пусть заказчик (пользователь) захотел мега-хотелку. Консультант (который, согласно принципу разделения труда, не сильно разбирается в технических деталях функционала, который эта хотелка затрагивает) пишет подробное ТЗ, тратит на это кучу времени, и передает его программисту. А программисту достаточно было парой фраз обменяться с пользователем, чтобы понять, что либо это в принципе нереализуемо, либо от такой доработки система "ляжет". Занавес, как говорится.
Да, методология с субординацией соблюдены, порядок не нарушен, всё круто... Но время (=деньги) потеряно.

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

[domandr]

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

[domandr]

Цитата:

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

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

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

Цитата:

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

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

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

[RedFox]

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

[Ruff]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

[kashperuk]

Цитата:

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

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

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

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

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

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