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

08.02.21

Саморазвитие

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

 

 

 

 

Я человек странный, где-то на пересечении психологии и ИТ. Последние восемь лет среди прочего я анализирую, как работают 1С-ники.

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

 

 

Мы поговорим о том, почему у человека, несмотря на его опыт и желание все сделать хорошо, могут не складываться отношения с клиентами.

Чаще всего проблемы возникают из-за этих вот «людей». Эти субличности постоянно сидят у нас внутри, стараются вылезти и все портят. Давайте обсудим, что с этим делать.

 

Первая негативная модель поведения – это Партизан

Когда я работал фрилансером и только начал анализировать себя, коллег по цеху, я понял, что среди фрилансеров воздушно-капельным или воздушно-клавиатурным путем передается некая зараза, которая заставляет тебя куда-нибудь уехать и «схорониться» там, как только ты взял заказ. Не брать телефоны, не отвечать по скайпу, пока не доделаешь задачу. И только после этого выйти на связь.

Я недоумевал – откуда такое желание? А оно возникает по простой причине: еще с детства с родителями и в школе редко получалось так, что нас поддерживают и хвалят за неидеально решенную задачу. Нас не подбадривают, не говорят, что нужно пытаться – нас ругают. Поэтому мы не любим признаваться, что что-то неидеально, мы не хотим рассказывать, что что-то не так. А в жизни всегда все неидеально. Мы стандартно стараемся не давать информации в принципе.

 

 

Один из моих сотрудников однажды взял задачу и должен был сдать ее через неделю. В предпоследний день перед сдачей работы заказчик пишет «Ну что там по задаче? Должны были уже что-то прислать». А сотрудник молчит: час, два, день. В пятницу с утра мне сообщают, что сотрудник пропал. Я связываюсь с пропавшим, спрашиваю, в чем дело, нужно ответить заказчику на письмо. Сотрудник отвечает, что «запрограммировался» и сейчас ответит. Прошел час, ответа заказчик так и не получил. Звоню снова, спрашиваю, что происходит. Через полчаса история повторяется. В итоге сотрудник все-таки ответил заказчику, что в процессе работы над задачей «возникли сложности».

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

Проблема, связанная с нежеланием говорить, приводит к тому, что заказчик начинает нам не доверять. Когда он спрашивает «Ну че там?» – это не значит, что ему правда интересно, че там. Это значит, что он уже напрягся, ему кажется, что он теряет контроль. В момент, когда он к нам обращается, он уже на взводе. А когда ему еще и не отвечают, возникает ощущение полной потери контроля.

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

Что с этим делать?

  • Первый вариант – сходить к психологу и узнать, почему мы боимся быть неидеальными, но это долго.

  • Можно еще сказать «Я же мужик» и отвечать на все письма – это тоже хорошо.

  • Но самое идеальное, что можно сделать, – это самому заранее сообщать о статусе работы, до того, как клиент спросил. Чтобы заказчик чувствовал, что ситуация под контролем: он знает, как продвигается работа. Я рекомендую договариваться с клиентом о том, через какой период времени вы будете ему сообщать о том, что происходит. Желательно раз в два дня или раз в неделю – в зависимости от объема задачи, но лучше делать это как можно чаще или даже демонстрировать, показывать результаты работы. Если у вас наладится стандартный период выдачи обратной связи с показом, заказчик успокоится, и все станет хорошо. Если мы, конечно, совсем там все не продолбаем.

 

Вторая негативная модель – НедоГерой

У меня был интересный случай с сотрудником, которого спросили: «Когда ты сделаешь работу?». Сотрудник обещает сделать к вечеру. Ну отлично. Наступает вечер, и он сообщает, что задача не выполнена, возникли сложности. Окей, каковы новые сроки? Он отвечает, что задачу выполнит завтра до трех.

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

 

 

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

Что с этим делать?

  • Первое и самое простое, что я всем рекомендую – когда оцениваете задачу и риски, специально спрашивайте себя, что может пойти не так. Отлично для этого подходит технология PERT, которая по-русски называется «по трем точкам», когда анализируется оптимистическая оценка, потом реалистическая, если что-то пойдет не так, а потом пессимистическая – если все будет плохо. В технологии PERT есть формула, по которой рассчитывается нормальная оценка с учетом рисков. Берем задачу, дробим ее на части, каждую часть оцениваем по этим трем параметрам, и PERT нам рассчитывает примерно вероятностную оценку. Если мы специально задумаемся, что может пойти не так, это нам потом поможет.

  • Сверку с оценкой PERT и переоценку нужно проводить постоянно. Заложите себе это хотя бы раз в неделю, если задача на месяц, или раз в день, если задача на четыре дня. Проверьте, идете ли вы согласно своей оценке по плану. Если вы видите, что что-то не так – сообщите об этом заказчику и сами перепланируйте. Этот пункт как раз хорошо сочетается с предыдущим «Партизаном».

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

Или если вы такой же экспериментатор как я, то можете делать следующим образом. В начале моей карьеры я работал в конечном крупном клиенте в Казани. Я был единственным разработчиком на всю компанию, и ко мне все подходили с проблемами. Но каждый сотрудник при этом не хотел задумываться, что он у меня не единственный, и что кроме него ко мне приходят и другие его коллеги. Поэтому когда кто-то приходит с чем-то срочным, то я говорил, чтобы он со своей проблемой от меня не отходил, иначе на его место придет другой. «Стой и защищай свою задачу!». Заодно он видел, что я работаю и слышал мои комментарии и вопросов о моей открытости и вовлеченности в принципе не возникало. Это, кстати, был единственный раз, когда бухгалтеры из-за меня почти подрались. Я этим гордился, потому что девушки из-за меня никогда не дрались, тем более, на работе.

 

Следующая роль – Пожарник

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

 

 

Почему такое произошло? Мне всегда казалось, что я более-менее адекватный, но в такую ситуацию попал. Дело в том, что мы не хотим видеть проблем в принципе. Но ошибка – это проблема. Она показывает нас с неидеальной стороны, и мы не хотим этого замечать. У психологов есть такой прикол. Когда мы куда-то спешим, например, на важную встречу, и не можем найти ключи, хотя они где-то рядом лежат, встаньте, успокойтесь и закройте глаза. Потом откройте глаза и увидите ключи. Потому что если мы куда-то не хотим идти или торопимся, мы, правда, можем чего-то не видеть в упор.

Но что с этим делать? Ведь у клиента возникает естественное желание не работать с нами и не платить.

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

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

  • Следующий момент – если есть ошибка, надо все перепроверить и сделать выводы на будущее. Как я могу сделать так, чтобы дальше такой ошибки не было? Я в гугле вел табличку, где отмечал, какие ошибки нашел, и что я могу сделать в будущем на этапе разработки и проектирования, чтобы эту ошибку больше не повторять. Это выводы, которые сделали меня лучше.

 

Четвертая модель поведения – Робот

 

 

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

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

Бывает такое, когда звонишь в службу поддержи, объясняешь проблему, а тебя просят включить-выключить компьютер, задают простые дурацкие вопросы. Вы чувствуете, что вам не хотят помочь, а просто идут по листочку.

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

Эта штукенция сидит почти во всех нас. Почему она возникает?

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

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

Что же рекомендуется делать?

  • Первое – самое простое, что можно сделать, даже не развивая навыки глубокой эмпатии – если у клиента какая-то боль, сказать «Да, это реально неприятно». Одной этой фразой можно снять большую часть негатива у клиента. Научитесь говорить ее, когда клиент приходит с какой-то проблемой. Вы должны понимать, что, когда клиент к вам приходит – он сначала хочет выговориться, поэтому его стоит выслушать и сказать фразу про «неприятно».

  • После этого его нужно спросить, как вы можете помочь: не оправдываться, почему так произошло, и спорить, кто виноват, а просто спросить: «Как я могу помочь?»

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

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

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

 

И последняя модель поведения – это Госслужащий

Мы все были в Сбербанках и Почтах России, где живут не самые довольные люди на земле, которые не очень по-доброму к нам обращаются. Это тоже есть во всех из нас.

У меня был очень раздражительный заказчик, который всем не доверял, давил и бесился из-за каждой мелочи. И когда я подключил к нему нормального сотрудника, у них ничего не срослось, потому что сотрудник был обычным, а заказчик любил на профессионализм подавить. А после этого так случилось, что к этому раздражительному заказчику подключился такой же раздражительный сотрудник. И у них была баталия, когда заказчик злился, спрашивал «Че у вас тут за фигня?!» , ему отвечали «Да потому что у вас вот здесь проблемы, а еще вы ТЗ плохо написали!» В результате у них получилась отличная команда – примерно через неделю заказчик сказал, что это вообще классный и крутой сотрудник. Ведь он привык ощущать себя крутым и видеть у других проблемы, а тут попался такой же сотрудник – значит, он такой же крутой! У них был симбиоз, все было замечательно.

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

 

 

Почему люди хотят быть такими раздражительными?

  • Первый вариант – это как раз люди-недогерои, которые хотят брать на себя все больше и больше. Но при этом они уже начали сознавать, что этот путь не ведет к нормальной работе. Им в какой-то момент надо наконец перестать брать задачи и сказать «Нет», но они не могут этого сделать, потому что им в детстве, может, кто-то сказал, что они крутые, потому что столько задач берут на себя. Такой тип людей сможет сказать «Нет» только в крайнем раздражении, только через злость. Они все берут, берут на себя, и только раздражение позволяет им отказаться.

  • Второй вариант – есть такое поверье, особенно в больших компаниях, у конечных клиентов, что если человек раздражен и на всех тявкает, то, скорее всего, он очень занят и крут, много чего знает и делает. В такой обстановке люди учатся на всех огрызаться. И реально долго могут таким образом работать. Я знал такого сотрудника, когда работал в одной госкомпании. Он от силы работал полчаса в день, и он так «жил» года два. Просто на всех раздражался, и люди к нему не шли, потому что думали, что он загружен.

Что с этим делать?

  • Бывает что, то, что вы делаете, не ведет вас к вашим целям. И это раздражает. Если у вас сейчас цель в жизни – открыть свою кофейню, а вы разработчик 1С, и к вам идут с задачами, то возможно ощущения будут не самые радостные от новых задач. Есть два варианта решения. Первое – подумайте, какая ваша цель, возможно, стоит сменить работу. Я знаю такие кейсы, когда люди раздражались-раздражались, потом понимали, что вообще не хотят этим заниматься. Второе – увидеть каким образом то, что вы делаете, ведет вас к цели. Самое простое - обозначьте свои цели, поймите, как это связано с деньгами, и соизмеряйте с деньгами, которые вы зарабатываете. Когда вы так делаете, становится чуть-чуть проще. Лучше всего, когда ваша деятельность ведет вас к вашей цели. Например, вы хотите быть крутым архитектором, делать классные проекты, и сейчас набираете опыт для этого. Это самое замечательное. Но если совсем все плохо – считайте в деньгах.

  • Если у вас проблема в том, что вы не можете отказать, учитесь говорить «Нет». Я бы рекомендовал начать с самых простых вещей. Например, позвонят с предложением оформить кредит – скажите «Нет!». И так по чуть-чуть. Через какое-то время научитесь говорить «Нет» в сложных случаях спокойно. Если вы с этим раздражением справитесь, люди начнут к вам приходить с более довольным лицом. У меня был интересный случай. Сотрудник был крутым разработчиком, но раздражался на любые задачи. Я этого не сильно замечал. Но однажды я попросил консультанта сходить и передать новую задачу этому разрабу. Консультант скуксился и ответил, что сходил бы к кому угодно, кроме этого разработчика. Человек настолько не хотел связываться с неприятным коллегой, что эмоционально страдал. Учитесь быть приятными для людей.

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

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Kazan.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Радио "Аналитик", 15 выпуск 2 сезона. "Путь аналитика" с Ильёй Никитиным. Переход от технической поддержки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

вчера в 09:10    166    0    Radio_Analyst    0    

3

Радио "Аналитик", 14 выпуск 2 сезона. "Путь аналитика" с Натальей Лосевой. Переход от разработки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

04.03.2024    326    0    Radio_Analyst    0    

5

Измерение и развитие потенциала сотрудников

Обучение и наставничество Бесплатно (free)

Тема измерения и развития потенциала сотрудников является ведущей последние два года в компании Proaction. Елена Дуюн, руководитель направления «Развитие корпоративной культуры», поделится с нами откровением, которое возникло в процессе исследовательского проекта на платформе Proaction. Елена расскажет о текущей кадровой ситуации, о видах потенциала сотрудников, о том, как оценивать этот потенциал и как мотивировать персонал на саморазвитие.

01.03.2024    336    0    DuyunElena    0    

3

Радио "Аналитик", 13 выпуск 2 сезона. "Путь аналитика" с Анастасией Лощиловой. От финансового директора на заводе до функционального архитектора

Обучение и наставничество Бесплатно (free)

Что отличает аналитика от самурая? Аналитик не прокладывает путь, пока не поставит цель. В серии “Путь аналитика” поговорим, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

20.02.2024    476    0    Radio_Analyst    0    

1

Презентация продукта как искусство

Презентации и публичные выступления Бесплатно (free)

Никакой продажник не продаст ВАШ продукт лучше ВАС. Но презентация продукта – это не только наука, но и искусство. О том, как сделать выступление запоминающимся, насколько важны базовые ораторские навыки, сторителлинг и инструментарий для наглядного погружения в детали, расскажем в статье.

12.02.2024    913    0    comol    4    

17

Личный бренд в IT: а оно вообще надо?

Личная эффективность Бесплатно (free)

Персональный личный бренд повышает вашу стоимость на рынке труда – чем больше потенциальные работодатели знают о ваших достижениях, тем больше они готовы вам платить. Но что делать на старте, когда вы решили прокачать своё имя в отрасли? Какие инструменты и подходы для этого необходимо использовать? О том, как прокачать свой бренд, принося пользу компании, пойдет речь в статье.

01.02.2024    827    0    mitinskiy    2    

7

Зачем программисту книжки читать

Личная эффективность Бесплатно (free)

Нам с детства постоянно твердят, что книга – лучший друг, книга – лучший подарок, книга – вообще лучшая вещь в мире. Да, это действительно так. Книги явно и значительно влияют на нашу работу, карьеру и жизнь. О том, как правильно читать книгу, как книга вообще влияет на человека, и главное: зачем вообще читать эти книги программисту, сисадмину, аналитику, расскажем в статье.

31.01.2024    2773    0    a_a_burlakov    25    

46

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

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

15.01.2024    1648    0    KChebykina    0    

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

PS: это был сарказм
8. katenok86 246 09.02.21 13:23 Сейчас в теме
(7)У меня есть знакомый консультант который так работает, так вот заказчики от него безума только до тех пор пока не видят других специалистов, которые не охают а за это время просто решают проблему.
PS сарказм понятен
2. oldcopy 173 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 55 09.02.21 16:46 Сейчас в теме
Не надо всех под одну гребенку объединять


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

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

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

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

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

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

но имею опыт

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

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

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

P.S.: Мы прямо как будто в разных городах живем)
20. katenok86 246 09.02.21 17:14 Сейчас в теме
(19) Нет просто вы видимо работаете на тиражке/фрилансе, а я последнее время специализируюсь на крупных проектах.
21. papami 55 09.02.21 17:16 Сейчас в теме
(20)Про все нет). Но воды явно разные.
28. katenok86 246 10.02.21 09:41 Сейчас в теме
(21)Если не секрет раскажете чуть чуть про ваши "воды"
29. papami 55 10.02.21 09:49 Сейчас в теме
(28) Хорошо, только для того, чтобы на одном языке говорить, крупные проекты - это от скольки часов в трудозатратах?
31. katenok86 246 10.02.21 11:30 Сейчас в теме
33. papami 55 10.02.21 18:19 Сейчас в теме
(31)
Заходит в крупную организацию крупный франч. Продает продукт. На внедрение предлагается отдельный договор и выкатывается сумма невероятная. И теперь мне ясно откуда она берется)))
Тот клиент, который считает деньги и знает фактические сроки и процент удачных крупных проектных внедрений, начинает искать варианты. Дальше крупный франч уходит, неплохо заработав на продаже продукта, а внедрением занимается франч поменьше. Вот это пример наших вод). А так как продают коллеги хорошо, то и работы по рынку навалом. Лишь бы была квалификация соответствующая.
6. chg 09.02.21 12:58 Сейчас в теме
Любой из пунктов подходит почти к любой профессии из ИТ, особенно среди молодых специалистов, многим приходится через это проходить, набивать шишковый опыт)))
22. papami 55 09.02.21 19:14 Сейчас в теме
23. a_titeev 31 09.02.21 20:26 Сейчас в теме
Классно. Мне понравилось.
24. morin 57 09.02.21 21:39 Сейчас в теме
По личному опыту, от клиента негатив обычно исходит не "к 1С-нику", а "к франчу" и связан именно с работой франчайзи.
25. mysm 83 10.02.21 08:54 Сейчас в теме
По поводу "партизана". А что на таком проекте делает руководитель, если все сваливает на разработчика? Просто просит разработчика связываться с заказчиком? И зачем такой передаст на этом проекте?
Leon75; d4rkmesa; morin; papami; zqzq; +5 Ответить
26. zqzq 23 10.02.21 09:21 Сейчас в теме
(25) +1 и по поводу "робота" можно то же самое сказать. Задача фирмы-"прослойки" -- оградить программиста от стресса в лице неадекватных заказчиков.
Фрилансеры, да, должны страдать, но зато всю сумму себе получают.
Для фикси вообще статья не особенно актуальна)
27. katenok86 246 10.02.21 09:40 Сейчас в теме
(25)я так понимаю что это не к проектам относится, а к текучке, мелким доработкам, абонетскому обслуживанию.
30. johnnyshut23 71 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. TerveRus 10.03.21 16:04 Сейчас в теме
Помню себя во всех ролях, кроме робота) Всякое бывало)
Только с опытом начинаешь ставить себя на место заказчика и понимать ситуацию.
38. user1567275 22.03.21 12:03 Сейчас в теме
Самое обидное, когда вообще не в тебе как в бухгалтере проблема, а подводит техническая часть. Работала на облачной 1С, произошел сбой почти на 2 дня. Клиент в ярости, а я ничего не могу сделать. От той фирмы ушел, теперь на другом облаке. А клиента уже не вернуть.
39. user1569935 25.03.21 08:42 Сейчас в теме
(38)Сейчас то по технической части все окей?)
40. пользователь 31.03.21 04:17
Сообщение было скрыто модератором.
...
41. user1573840 02.04.21 11:49 Сейчас в теме
(39)Ага, полтора года на СервисКлауд работаю. Таких проблем не было.
42. JohnGalt 57 20.01.22 12:21 Сейчас в теме
Надо написать статью про модели поведения заказчика :)
Стану на сторону исполнителей задач, неоднократно приходилось выстраивать похожие модели поведения, поскольку опыта не хватало взглянуть с другой стороны или сверху на ситуацию. В процессе развития в любом направлении нельзя и нету смысла пытаться охватить все со всех сторон. Пытаться ограничить себя и других в выполнении задач/работ/проектов - логично, особенно когда требования и пожелания размыты. И даже когда они кажутся предельно четкими на определенном этапе, на следующем этапе все может поменяться. Никто не застрахован от доп.расходов, которые появляются в процессе развития, после прохождения этапов и дальнейшего планирования. Просто есть исполнители на разных этапах своего развития, которые происходит у каждого индивидуально, хотя и можно объединить ключевые этапы.

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

Заказчик, пытаясь решить свою задачу, может мало того что ничем не помочь исполнителю, так еще и навредить своим видением, пониманием и толкованием. Один из примеров, с которым я сталкивался довольно часто, это закупки/продажи, в общем работа с остатками. Людям довольно сложно бывает объяснить, зачем нужно заполнять отдельные документы для прихода и списания, а не просто открыть таблицу остатков и ее корректировать напрямую. Самый частый вопрос: почему все так сложно? Зачем так усложнять? И приходится начинать от самых базовых моментов...
Оставьте свое сообщение