Вежливо отказывайтесь от изучения нового программного обеспечения

Я работаю с клиентами (продажи/консультации клиентов) в компании-разработчике программного обеспечения, и иногда в нашем приложении появляется что-то, что сломано/не работает.

Когда это происходит, я оповещаю группу поддержки Dev & Tech (через тикет или по электронной почте — тикет назначается технической поддержке), и меня часто спрашивают: «Вы проверили X?» Где X — одна из 4 частей программного обеспечения, связанных с запуском нашего приложения. Я отвечаю нет, иногда добавляя, что не знаю как или у меня нет доступа.

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

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

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

Как я могу тактично отказаться изучать/использовать эти программы, не разыгрывая карту «это не моя работа»?

В какой запутанной операции вы работаете, когда разработчики обрабатывают запросы в службу поддержки первого уровня? Мне кажется, в вашей организации не хватает огромной части. А именно: отдел поддержки. Не разыгрывайте карту «Это не моя работа», потому что любой компетентный разработчик разыграет ее прямо перед вами с «Нарисуйте 4» прямо за ней.
Моя роль заключается в продажах/консультациях клиентов, а не в поддержке. Очевидно, название должности означает что-то другое за пределами нашей компании. Есть группа техподдержки. Это работа, когда я сообщаю о проблеме, я назначаю ее команде технической поддержки , но разработчики все равно заставляют меня отвечать на их вопросы.
Опять же, почему разработчики вообще вовлечены в это? Служба поддержки должна этим заниматься. Вы должны работать с техниками, а не с разработчиками. У вас есть большая организационная проблема.
Я согласен с @WesleyLong - если вы отправляете запросы в службу технической поддержки, это звучит правильно, основываясь на том, что вы нам сказали. Однако я не уверен, почему команда разработчиков участвует. Команда технической поддержки должна проверять ваши отчеты и либо устранять проблемы, либо направлять информацию в команду разработчиков для любых проблем, требующих проектирования и разработки.
Что вы подразумеваете под изучением/использованием этих программ ? Часто случается так, что сообщение об ошибке не является ошибкой, это просто то, как работает система. Является ли частью вашей работы знание того, как работает система (на более высоком уровне)?
Многое зависит от размера компании. Одним из преимуществ небольшой компании-разработчика программного обеспечения является то, что разработчики могут напрямую общаться с пользователями: это творит чудеса, помогая им понять, что им нужно. Но если вы разработчик, который хочет сделать жизнь своих пользователей лучше, нет ничего более разочаровывающего, чем пользователь, который сообщает о проблеме, но затем не сообщает подробностей о том, что именно он сделал и как именно это не удалось.

Ответы (7)

Вы не отказываетесь.

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

Если, поговорив со своим менеджером, вы по-прежнему чувствуете, что ожидания вашего менеджера в отношении работы, которую вы выполняете, не совпадают с вашими ожиданиями в отношении работы, которую вы выполняете, вы можете уйти со своей должности и найти новую работу, которая более интересна. в соответствии с тем, что вы ожидаете.


Чтобы продолжить редактирование вопроса.

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

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

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


Чтобы еще раз дополнить некоторые из ваших комментариев, похоже, что у процесса вашей компании есть серьезные проблемы.

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

Опять же, мои исходные пункты остаются в силе: не вмешивайтесь сами. Поговорите со своим менеджером и попросите его поработать с менеджерами.

Это обстоятельный ответ, я обязательно подниму его перед своим менеджером, но мне все равно было бы интересно услышать, как это сформулировать в тот момент, когда меня подталкивает команда разработчиков. Может быть, моя должность не аналогична моим должностным обязанностям? Также есть отдел технической поддержки, который исследует проблемы — моя работа заключается в продаже программного обеспечения и управлении внедрением программного обеспечения на сайте клиента.
@SNSAD Возможно, есть проблема с процессом. Мне любопытно, почему вы предупреждаете команду разработчиков, а не отдел технической поддержки, когда сталкиваетесь с проблемой. Я не уверен, насколько велика ваша компания, но, возможно, разные команды не знают вас и вашу роль. Как разработчик, я ожидаю, что отчет об ошибке будет содержать то, о чем просит команда разработчиков. Если вы не можете этого обеспечить, вы должны привлечь людей, которые могут. Возможно, это разговор с вашим менеджером.
Это технический стартап, поэтому я, 1 техническая поддержка, 1 техническая поддержка с частичной занятостью / разработчик с частичной занятостью, 2 выделенных разработчика и вице-президент. Обычно я сообщаю, а не занимаю пропускную способность Tech, поскольку могу использовать систему продажи билетов. Но, может быть, мне стоит просто написать в технический отдел?
используйте систему тикетов, вместо этого назначьте ее техподдержке
@SNSAD Я бы порекомендовал поговорить с вашим боссом, но рабочий процесс звучит неправильно. Это похоже на то, чем должна заниматься служба технической поддержки. Вы не занимали бы их полосу пропускания. То, что вы делаете, определенно нехорошо для разработчика (им трудно или невозможно понять проблему, если вы не предоставите им информацию, которую они запрашивают, и у них, вероятно, есть более важная работа, тем более что они, вероятно, более дорогие). для компании).
@ThomasOwens, вы можете быть удивлены, сколько зарабатывают продавцы
@bharal Продавцы также получают доход, заключая сделки. Если это не контрактная разработка, создание продукта требует первоначальных затрат. Плата за разработку — это инвестиция. Стоимость разработчика должна идти на проектирование и разработку, а не на техническую поддержку, если разработчику явно не поручена техническая поддержка.
Я принимаю это за общую тщательность и ответ, чтобы поговорить с моим боссом. Очевидно, что из-за путаницы с ролями и процессами в моей компании это часть более крупной проблемы процесса в моей конкретной начинающей компании.
Если вы работаете где-либо в индустрии программного обеспечения, «отказ изучать новые технологии» в значительной степени эквивалентен «будете навсегда безработным в ближайшем будущем». Это ваш выбор, конечно. Лично я много лет назад потерял счет всем системам и пакетам, о которых я узнал, а позже почти полностью забыл, но это больше похоже на 50 или 100, чем на 10 или 20. Если это число кажется «слишком трудоемким или трудоемким», может быть, вы работаете в сфере продаж не в той отрасли.
@SNSAD Я обычно сообщаю, а не занимаю пропускную способность Tech - неудивительно, что разработчики хотят, чтобы вы сортировали! Вам следует обращаться в службу технической поддержки, а НЕ к разработчикам; это слой, который переводит нетехническую обратную связь в конкретный код (или решает ее самостоятельно и экономит время разработчиков).
@SNSAD В таком маленьком технологическом стартапе нет ничего необычного в том, чтобы ожидать, что все будут технически ориентированы и будут иметь довольно глубокий уровень операционных знаний о том, что продается, включая любые вспомогательные инструменты. Если вы столкнетесь с ошибками в продукте в ходе своей работы, вы сэкономите время, энергию и разочарование всех участников, поскольку сможете предоставлять более качественные отчеты об ошибках. Это также, в свою очередь, сделает ваше взаимодействие с клиентами более плавным, поскольку вы поможете им решить проблемы с реализацией.
@ThomasOwens Я не согласен. Хорошие разработчики отличаются тем, что они заботятся о пользователях. Как они могут сделать хороший дизайн и разработку, если их не интересуют проблемы, с которыми сталкиваются пользователи? В те дни, когда между мной и пользователями сидела группа технической поддержки, я всегда старался посещать группу технической поддержки несколько раз в неделю, чтобы узнать, какие проблемы возникают.
@MichaelKay Я не понимаю, как вы пришли к выводу, что я когда-либо даже намекал, что разработчики не должны интересоваться проблемами, с которыми сталкиваются их пользователи. Разработчики должны проявлять интерес к проблемам, с которыми сталкиваются пользователи как из-за программного обеспечения, которое они создают, так и из-за отсутствия соответствующих инструментов. Но им также необходимо сбалансировать свое время и сосредоточиться на своих обязанностях. Каждый должен сосредоточиться на своих обязанностях, но понимать обязанности и проблемы, с которыми сталкиваются все различные группы заинтересованных сторон.

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

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

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

Как я могу тактично отказаться изучать/использовать эти программы, не разыгрывая карту «это не моя работа»?


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

В качестве ответа «в данный момент» вы можете сказать: «Изучение этих программ потребовало бы больших затрат моего времени, но об этом стоит подумать. Я спрошу мнение вице -президента о моих приоритетах и ​​вернусь к ты."

Это технический стартап, поэтому я, 1 техническая поддержка, 1 техническая поддержка с частичной занятостью / разработчик с частичной занятостью, 2 выделенных разработчика и вице-президент. Обычно я сообщаю, а не занимаю пропускную способность Tech, поскольку могу использовать систему продажи билетов. Но, может быть, мне стоит просто написать в технический отдел?

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

Вас пригласили в своего рода supportили даже key userроль. Действуйте так же, как и с любым другим входящим приглашением на роль.

Пара фактических моментов:

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

  • Ожидания вашего карьерного роста определяют вашу готовность принять/отклонить приглашение.

  • Этот процесс должен сопровождать ваш менеджер (в идеале с самого начала), потому что одна из его обязанностей — следить за вашей карьерой и управлять ресурсами команды («Можно ли выделить для этого этого члена команды?»)

  • Потенциальное принятие роли должно сопровождаться ожидаемым процентом вашего времени, т.е. ожидается, что вы посвятите 20% своего времени этой новой ответственности. И также должен быть план выхода из какого-то настоящего, чтобы было место для этого.

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

Более серьезной проблемой, похоже, является нарушение связи, учитывая, насколько вы малы, но разработчики не обучены управлению, не позволяйте им управлять вами.

Оригинальный ответ: Вы не делаете.

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

Я бы не стал нагнетать обстановку - уже установлено, что это не входит в вашу компетенцию.

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

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

Разработчики не должны заниматься поддержкой первого уровня. Если их об этом просят, то проблема в менеджменте, а не в разработчиках.
@WesleyLong Мы не знаем, на что согласились разработчики, кажется вполне разумным для стартапа, что они также выполнят работу по поддержке.

Возможно, есть проблема со связью. Иногда удивительно сложно отследить «ошибку», когда ее нельзя воспроизвести в среде разработки, а упомянутые инструменты могут предоставить разработчикам необходимую информацию для решения проблемы. Часто билет настолько загадочен, что даже не знаешь, с чего начать. Эти инструменты также можно использовать в качестве средства проверки работоспособности, чтобы убедиться, что конфигурации находятся в пределах параметров. Иногда «ошибки» — это «мы никогда не собирались делать это». К сожалению, понятное пользователю сообщение об ошибке может быть не сгенерировано. Опять же, если разработчик не понимает намерения конечного пользователя, их может быть трудно понять. Возможно, разработчикам и клиентам нужно сказать, что вы всего лишь продавец, «эксперт». Технология сразу поступает в продажу для установки, настройки и поддержки. Этот «эксперт» не обязательно должен быть высококвалифицированным, но должен быть готов и способен научиться определять желания клиента (не всегда легко), распространенные проблемы и решения, а также быть в состоянии пройти основные этапы диагностики. Если бы я был разработчиком, то причиной, по которой я мог бы попросить вас попробовать другие инструменты, была бы помощь в сборе данных, чтобы можно было диагностировать проблему и разработать наилучшее решение. Если вы можете дать разработчику лучший вариант, помогая ему выполнять свою работу, он воспользуется этим. причина, по которой я мог бы попросить вас попробовать другие инструменты, заключается в том, чтобы помочь в сборе данных, чтобы можно было диагностировать проблему и найти лучшее решение. Если вы можете дать разработчику лучший вариант, помогая ему выполнять свою работу, он воспользуется этим. причина, по которой я мог бы попросить вас попробовать другие инструменты, заключается в том, чтобы помочь в сборе данных, чтобы можно было диагностировать проблему и найти лучшее решение. Если вы можете дать разработчику лучший вариант, помогая ему выполнять свою работу, он воспользуется этим.

этот пост довольно сложно читать (стена текста), не могли бы вы отредактировать его, чтобы он выглядел лучше?

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

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

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

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

мы не знаем, в чем заключается работа оперативников, и предположение, что их работа начинается, когда звонит телефон или приходит сервисный билет, обесценивает вашу точку зрения.
То, что ожидается от связного с клиентом, будет варьироваться от компании к компании. Разработчики не имеют автоматического права на то, чтобы их не прерывали для поддержки производства. Это ужасное отношение и крайне непрофессионально с вашей стороны.
Моя работа заключается в продаже программного обеспечения и управлении внедрением программного обеспечения на сайте клиента. Также есть группа технической поддержки для решения клиентских проблем после внедрения. Что происходит, так это то, что я замечаю ошибки/перебои в работе, пока делаю свою работу, и, поскольку я сообщаю об этом, похоже, ожидается, что я проведу расследование. Может быть, вместо того, чтобы сообщать об этом, мне следует дать отчет техподдержке?
Работа ориентирована на клиента, если это связь. Если есть другие сотрудники службы технической поддержки, то OP должен работать с этими людьми, прежде чем привлекать разработчиков. Хороший подход к разработке состоит в том, чтобы убедиться, что в приложении достаточно журналов — опять же, чтобы позволить НЕ-разработчикам решать проблемы. Разработчиков очень раздражает, когда другие сотрудники, работающие с клиентами, придерживаются подхода, согласно которому они не хотят заниматься расследованием проблем самостоятельно.
@XavierJ это может быть «действительно раздражающим», когда люди просят разработчиков выполнять скучную техническую работу, но разработчики выполняют техническую работу. То, что легко для разработчика — создание sql, использование unix — невероятно сложно для неспециалистов.