Зарегистрироваться | Поиск |
Результаты опроса: Cтоит ли программистов огораживать консультантами от пользователей? | |||
Стоит оградить от общения с пользователями полностью! |
![]() ![]() ![]() ![]() |
18 | 14.52% |
Общение с пользователями возможно только в случае крайней необходимости. |
![]() ![]() ![]() ![]() |
38 | 30.65% |
Нет, не стоит. Пусть себе общается. Это полезно. Но бОльшая часть общения должна быть у консультанта. |
![]() ![]() ![]() ![]() |
53 | 42.74% |
Наравне должны общаться. |
![]() ![]() ![]() ![]() |
9 | 7.26% |
Консультанты вообще не нужны. |
![]() ![]() ![]() ![]() |
3 | 2.42% |
Не знаю/Затрудняюсь ответить |
![]() ![]() ![]() ![]() |
3 | 2.42% |
Голосовавшие: 124. Вы ещё не голосовали в этом опросе |
|
Опции темы |
|
![]() |
#1 |
программист
|
Цитата:
"От себя добавлю - когда меня, как программиста, поначалу пытались так огораживать, я: 1) чувствовал, себя то ли слепым, то ли роботом; 2) не понимал, кому и зачем моя работа вообще нужна (и нужна ли); 3) у меня заметно падала производительность труда" Надо искать золотую середину ![]() |
|
![]() |
#2 |
Участник
|
Все уже придумано и найдено. Все методологии внедрения написаны. Ну не должен разработчик общаться с пользователем. "У нас все выполняют свою работу". У разработчиков и так полно работы: написать код - протестировать. И программист не обязан знать функциональность (что необходимо для общения с пользователем).
Если Вам нравится общаться с пользователем - то Вам нужно идти в консультанты. |
|
![]() |
#3 |
Участник
|
|
|
![]() |
#4 |
Программатор
|
Но если программист обязан знать функциональность, то пардоньте зачем консультанты? Я - программист. Знаю достаточно из функционала, но есть нюансы, которые просто не укладываются в моей голове. Например план счетов
![]() ![]() |
|
![]() |
#5 |
Участник
|
Я тоже считаю, что богу богово, а кесарю - кесарево...
Если разработчик будет знать функционал и будет работать с пользователем напрямую, то консультант, в принципе, становится не очень нужным - легче набрать много программеров, и отправить их к клиенту внедрять ![]() Но при этом, если программист хочет роста - разбираться надо хотя бы для того, чтобы нерадивому консультанту показать где он лажу пишет, а где ему надо просто помочь с реализацией. И действительно, тонкости разработчик знать не обязан. А то с таким мышлением скоро программисты будут и бизнес консалтингом заниматься - реформировать бизнес-процессы на предприятии... Всё таки разделение труда - лучше ![]()
__________________
Бесполезно говорить: «Мы делаем все, что можем». Надо сделать то, что необходимо. |
|
![]() |
#6 |
Участник
|
|
|
![]() |
#7 |
Участник
|
Цитата:
![]() Я внимательно прочитал посты спорящих, и пришёл к выводу, что все мы правы. Только вот есть одно различие... Некоторые из нас работают в консалтинге, а некоторые - у клиента. У кого-то компания и/или проекты крупные, где много народу, а у кого-то нет. Кто-то внедряет по наитию - больше интуитивно колбасит (в силу размера проекта это позволительно), а кто-то строго по методологии... Да и стоимость проектов разная - у кого-то 80к, а у кого-то 1М. А сроки? Одни 5 месяцев, другие 2 года. Дело в том, что если ты работаешь у клиента - понятное дело, что ты и жнец, и кузнец и на дуде игрец. ПМ-консультант-проггер в одном лице. Если проект небольшой (положим 3-5 человек внеряет), то программеру тоже можно учавствовать. Но как только у Вас 8-12 человек внедряет, то тут строгая субординация важна - иначе получится неуправляемый хаос. Вот и спор идёт... Жизнь многогранна, ребята. Каждый проект - это отдельная песня, и всё под одну гребёнку за уши не притянешь. Но порядок должен быть во всём, и не важно общается программист с конечным пользователем, или нет. Лично я считаю (и голосовал), что общаться должен по минимуму (я ж в консалтинге пока, а как к клиенту уйду, буду ратовать за общение ![]()
__________________
Бесполезно говорить: «Мы делаем все, что можем». Надо сделать то, что необходимо. |
|
|
За это сообщение автора поблагодарили: Ruff (1), Spider (2). |
Теги |
взаимодействие с пользователем, внедрение, как правильно, менеджмент, разделение труда, методология |
|
|