5 причин негатива от клиента к 1С-нику и что с этим делать

0. 340 08.02.21 10:15 Сейчас в теме
На полях INFOSTART MEETUP в Казани участники обсудили, почему возникают сложности в общении между заказчиком и исполнителем на проектах 1С. Своим взглядом на проблему с гостями митапа поделился директор по счастью, совладелец группы компаний Neti Андрей Макаров.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. katenok86 246 08.02.21 16:18 Сейчас в теме
Вот насчет робота не согласна, точнее не так, если ты работаешь с мелкими задачами то все верно, в случае с проектами если вникать в "проблему" , а зачастую это банальное нытье, от непревычки пвсех пользователей 100+, ни каких нервов не хватит. Для этого на проекте есть разделение обязанностей, программист не должен слушать и вздыхать заказчку, консультант еще куда ни шло но опять же тут дело в обоснованности требований, не все так линейно кого то надо пожалеть а в каких то случаях стукнуть кулаком по столу. Не бывает таких проектов чисто из пряников, без кнута совсем ни как. Глобальные разногласия и претензии должен решать руководитель проекта или менеджер проекта.
wolfsoft; d4rkmesa; Kaspirovsky; Kuzya_brаtsk; papami; zqzq; morin; +7 Ответить
7. yermak 35 09.02.21 13:05 Сейчас в теме
(1) Программист должен посочувствовать заказчику, сказать, что это коллега-программист такой рукожоп тут все неправильно сделал. И даже если сразу видно, что задачу не получится решить - должен изобразить, что он прикладывает максимум усилия для решения этой задачи, но ее все равно не получилось решить, тем самым разделив с заказчиком бремя от своего косяка.

PS: это был сарказм
8. katenok86 246 09.02.21 13:23 Сейчас в теме
(7)У меня есть знакомый консультант который так работает, так вот заказчики от него безума только до тех пор пока не видят других специалистов, которые не охают а за это время просто решают проблему.
PS сарказм понятен
2. oldcopy 125 08.02.21 16:58 Сейчас в теме
(1) Про робота спорно, очень спорно. Многие заказчики, особенно мелкие, очень расширительно трактуют поставленные задачи, если их вовремя не остановить, то они очень скоро будут пытаться перекладывать на тебя собственные обязанности. Поэтому тут надо четко и жестко ставить ограничения. Задача была такая? Такая. Сделано? Сделано. А то что у вас там что-то не ложится и не сходится - это в ваших данных проблема, хотите - посмотрим, но за отдельный прайс.
Otec_Igor; VladimirMelnychenko; papami; zqzq; 7OH; katenok86; +6 Ответить
3. kpdozer 08.02.21 22:27 Сейчас в теме
Спасибо за статью. А как на счёт модели, когда каждый занимается своим делом и с заказчиком взаимодействуют одни специалисты, а код пишут другие?
Пока программер спокойно пишет код, ни на что не отвлекаясь, пусть эти роботы и недогерои тихо дремлют в его подсознании, а такие замечательные ит-психологи, как автор статьи, делают заказчиков ручными и няшными.
TeMochkiN; kai068; dodlez77; evgd02; Kuzya_brаtsk; user1357554; zqzq; +7 Ответить
4. Leon75 08.02.21 22:49 Сейчас в теме
Попытки вытрушивать из рядового программиста сроки выполнения нетиповых задач - показатель, что кто-то пытается его помучать. Сроки выполнения - специализация и обязанность Проджекта.
За сколько вы выполните задачу, которую раньше никогда не делали? А если вас внезапно не пускать на сервер разработки? А если не дать пароли к хранилищу? А если задача смежная с сисадминами (файлы, доступ по сети, хранилище сертификатов, доступы к СУБД), но они заняты более важными делами?
d4rkmesa; Kuzya_brаtsk; 7OH; +3 Ответить
5. katenok86 246 09.02.21 09:33 Сейчас в теме
(4)Программист должен уметь оценивать срок своей работы. А всю договорную часть должен проводить руководитель проекта или менеджер. программист должен сказать мне нужно тот и тот то
Kuzya_brаtsk; Tarlich; +2 Ответить
9. kpdozer 09.02.21 13:37 Сейчас в теме
(5) очень все неоднозначно с "должен уметь". А если не умеет, но выдает прекрасные результат - иногда быстро, иногда с опозданием, то кто его научит это делать? Может быть в оценке времени должны принять участие другие участники процесса? В противном случае должны быть утвержденные нормо-часы на работу. Как в автосервисах. Вывод: оценка времени не технический, а административный процесс. Когда я только знакомлюсь с исполнителем, то независимо от названного им срока исполнения я всегда прибавляю 30% времени на маневры.
Ta_Da; d4rkmesa; +2 Ответить
10. katenok86 246 09.02.21 13:43 Сейчас в теме
(9)Программист дает первичную оценку, руководитель добавляет риска/резерв озвучивает срок клиенту. Задача программиста не сильно выбиваться из сроков.
Kuzya_brаtsk; kpdozer; +2 Ответить
11. Leon75 09.02.21 14:23 Сейчас в теме
(10)Допустим, есть задача обьемной нетиповой интеграции. Вы ее раньше не делали. Но известно, что она REST/JSON. Интеграция с продуктом, который обслуживают другие люди, которые могут забыть сказать вам порт подключения. Уровень документации API и ее (документации) адекватности неизвестен.
Скажите прямо сейчас, через сколько будет готово. Нам срочно надо.
erp-consul; d4rkmesa; +2 Ответить
12. katenok86 246 09.02.21 14:48 Сейчас в теме
(11)А кто говорил про срочно? Нужна документация к сервису и перечень интегрируемых объектов для начапа, ну и время что бы это изучить не досконально до чтз, а на уровне необходимого для оценки. Естественно программисту время затраченое на оценку таких больших задач оплачивается, у меня на работе в счет маркетинговых затрат. А как по вашему менеджер руководитель должен оценить и назвать клиенту сумму, если он не программист и не может сказать за сколько это выполняется да и выполнимость задачи вообще не знает.

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

Далее после написания ТЗ, когда оно уходит к исполнителю программисту он по ЧТЗ, и возможно предварительного изучения должен сверится с оценкой и озвучить свой срок. в идеале он должен быть близок к оцененому ранее, если сильно разбегается и есть причина тогда руководитель принимает решение как быть в этом случае.
13. Leon75 09.02.21 15:28 Сейчас в теме
(12)не морочте голову, скажите когда будет готово.
Ta_Da; d4rkmesa; +2 Ответить
14. katenok86 246 09.02.21 15:37 Сейчас в теме
(13)Мне жаль вас если у вас такой руководитель. И вы сами и програмист и консультант и руководитель в одном лице. Это не нормально.
Не надо всех под одну гребенку объединять
16. papami 43 09.02.21 16:46 Сейчас в теме
Не надо всех под одну гребенку объединять


Так подход что должен быть программист, консультант и руководитель - это та же самая гребенка)
17. katenok86 246 09.02.21 16:47 Сейчас в теме
(16)Я этого не говорила. И с этим не согласна, по этому и писала первый комментарий.
15. papami 43 09.02.21 16:40 Сейчас в теме
(13)
Если при беглом прочтении ТЗ складывается ощущение, что оно полное:
Делаем CTRL+A ставим 12 шрифт (включая заголовки и таблицы). Количество страниц умножаем на 2.2. - это будет количество часов на разработку и тестирование.

Просто попробуйте на том, что уже сделали)

Если нет нормального ТЗ ответ дать сложно.
18. katenok86 246 09.02.21 16:54 Сейчас в теме
(15) К сожалению не со всеми заказчиками работает подход: вы вначале заплатите Нам за написание Тз/ Сами напишите нормальное ТЗ а мы потом скажем сколько разработка будет стоить. Вот и приходится оценивать по опыту, закладывать повышающий коэффициент. Если факт сильно разбегается с начальной оценкой, либо пытаться согласовать с заказчиком повышение бюджета, и в худшем случае работать в убыток. Ну либо не брать такие заказы, но тогда есть риск сидеть без работы совсем.

Все подобные комментарии основаны на позиции исполнителя, программиста. Советую пообщаться с менеджерами/руководителями и понять немного их сторону, не всегда они плохие, иногда такую постановку диктует жизнь.

PS я программист, но имею опыт первичных так сказать "продажных" походов к клиенту совместно с менеджерами руководителями проектов.
19. papami 43 09.02.21 17:08 Сейчас в теме
(18)
есть риск сидеть без работы совсем

Возможно для больших компаний это актуально.

но имею опыт

Небольшие компании так работают в обычном режиме.

Все подобные комментарии основаны на позиции исполнителя, программиста

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

P.S.: Мы прямо как будто в разных городах живем)
20. katenok86 246 09.02.21 17:14 Сейчас в теме
(19) Нет просто вы видимо работаете на тиражке/фрилансе, а я последнее время специализируюсь на крупных проектах.
21. papami 43 09.02.21 17:16 Сейчас в теме
(20)Про все нет). Но воды явно разные.
28. katenok86 246 10.02.21 09:41 Сейчас в теме
(21)Если не секрет раскажете чуть чуть про ваши "воды"
29. papami 43 10.02.21 09:49 Сейчас в теме
(28) Хорошо, только для того, чтобы на одном языке говорить, крупные проекты - это от скольки часов в трудозатратах?
31. katenok86 246 10.02.21 11:30 Сейчас в теме
33. papami 43 10.02.21 18:19 Сейчас в теме
(31)
Заходит в крупную организацию крупный франч. Продает продукт. На внедрение предлагается отдельный договор и выкатывается сумма невероятная. И теперь мне ясно откуда она берется)))
Тот клиент, который считает деньги и знает фактические сроки и процент удачных крупных проектных внедрений, начинает искать варианты. Дальше крупный франч уходит, неплохо заработав на продаже продукта, а внедрением занимается франч поменьше. Вот это пример наших вод). А так как продают коллеги хорошо, то и работы по рынку навалом. Лишь бы была квалификация соответствующая.
6. chg 09.02.21 12:58 Сейчас в теме
Любой из пунктов подходит почти к любой профессии из ИТ, особенно среди молодых специалистов, многим приходится через это проходить, набивать шишковый опыт)))
22. papami 43 09.02.21 19:14 Сейчас в теме
23. a_titeev 17 09.02.21 20:26 Сейчас в теме
Классно. Мне понравилось.
24. morin 24 09.02.21 21:39 Сейчас в теме
По личному опыту, от клиента негатив обычно исходит не "к 1С-нику", а "к франчу" и связан именно с работой франчайзи.
25. mysm 45 10.02.21 08:54 Сейчас в теме
По поводу "партизана". А что на таком проекте делает руководитель, если все сваливает на разработчика? Просто просит разработчика связываться с заказчиком? И зачем такой передаст на этом проекте?
Leon75; d4rkmesa; morin; papami; zqzq; +5 Ответить
26. zqzq 21 10.02.21 09:21 Сейчас в теме
(25) +1 и по поводу "робота" можно то же самое сказать. Задача фирмы-"прослойки" -- оградить программиста от стресса в лице неадекватных заказчиков.
Фрилансеры, да, должны страдать, но зато всю сумму себе получают.
Для фикси вообще статья не особенно актуальна)
27. katenok86 246 10.02.21 09:40 Сейчас в теме
(25)я так понимаю что это не к проектам относится, а к текучке, мелким доработкам, абонетскому обслуживанию.
30. johnnyshut23 61 10.02.21 10:59 Сейчас в теме
Почти во всем не согласен, Вы просто пытаетесь угодить всеми правдами и не правдами заказчику, будь он хоть псих. И соответственно перестроить всех вокруг под ваше восприятие мира.
Решение: Попробуйте обратиться к психологу и понять откуда в вас желание "Быть самым лучшим для всех". Долгий путь, понимаю.
d4rkmesa; +1 Ответить
32. Maxisussr 10.02.21 12:07 Сейчас в теме
(0)
Первый пункт - ИМХО самый ценный. Часто бывает, что вроде все идет хорошо, но забываешь сказать о статусе, а заказчик (внешний, внутренний - не важно) ждет. Более "качественно" выглядит, когда заказчик осведомлен на 100% (хоть может и немного накладно актуализировать результаты и думать о сроках и о критичных проблемах каждую неделю или несколько дней, но в критические моменты такая актуализация реально может помочь).

Остальное - актуально для абонентского обслуживания или небольших доработок.
Для фрилансеров, работающих "на себя", наверное , нет (они уже "умеют в психологию" - либо сами стремятся научиться).
Для разработчиков, работающих на проектах, "огражденных" менеджерами и т.п. - тоже сильно не актуально.
Если же вам приходится разрабатывать сложный функционал и при этом выслушивать тонны негатива и "подстраиваться" психологически под клиента и при этом терпеть все риски проекта на себе - то это само по себе не трагедия, просто стоит договориться об увеличении зарплаты. Либо набираться опыта и идти фрилансить (там хоть все деньги лично вам придут).
d4rkmesa; morin; +2 Ответить
34. artemusII 10.02.21 22:27 Сейчас в теме
(18) От ваших орфографии и пунктуации, а затем от осознания, что вы при этом РП, кровь из глаз пошла:)
35. katenok86 246 11.02.21 14:06 Сейчас в теме
(34)Все просто. я не РП. И даже не руководитель
36. Otec_Igor 13.02.21 09:52 Сейчас в теме
Общая причина негатива в конфликте понимания средств выполнения задачи. Заказчик, не владея предметной областью строит некую модель хоровода сферических коней в безвоздушном пространстве и очень нервничает в недоумении, когда оказыватся, что есть конфигурация и она является определенной сущностью, определяющей средства решения задачи. Вторая причина в том, что заказчик многие вещи может считать само собоой разумеющимися и поэтому их вообще не упоминает. Следствием этого задача оказыватся ущербно поставленной.
Самый простой способ превратить в помойку конфигурацию это безусловно следовать хотелкам. Задача заказчика формулировать цели. Это очень трудно для него, но надо стимулировать умственное напряжение и виртуозно допрашивать. Без этого никак.
Описанные автором причины не имеют концептуального значения - это зависящие от личности исполнителя со стороны франча прецеденты. Все прецеденты - от брешей в организации. Заказчику нужно, чтобы задача была выполнена, а не изыски общения с роботами и и артистами. Правильно, чтобы программисты вообще не общались с заказчиками, конечно если фирма не состоит из одного программиста. Нужен постановщик, который может формализовать задачу со слов заказчика и в случаях возможных инцидентов зафисировать проблему(определить есть ли она, при каких обстоятельсвах возникает и т. д.) и передать на программирование или иное решение задачи.
37. Terve!R 10.03.21 16:04 Сейчас в теме
Помню себя во всех ролях, кроме робота) Всякое бывало)
Только с опытом начинаешь ставить себя на место заказчика и понимать ситуацию.
38. user1567275 22.03.21 12:03 Сейчас в теме
Самое обидное, когда вообще не в тебе как в бухгалтере проблема, а подводит техническая часть. Работала на облачной 1С, произошел сбой почти на 2 дня. Клиент в ярости, а я ничего не могу сделать. От той фирмы ушел, теперь на другом облаке. А клиента уже не вернуть.
39. user1569935 25.03.21 08:42 Сейчас в теме
(38)Сейчас то по технической части все окей?)
41. user1573840 02.04.21 11:49 Сейчас в теме
(39)Ага, полтора года на СервисКлауд работаю. Таких проблем не было.
Оставьте свое сообщение
Вопросы с вознаграждением