Я работаю с клиентами (продажи/консультации клиентов) в компании-разработчике программного обеспечения, и иногда в нашем приложении появляется что-то, что сломано/не работает.
Когда это происходит, я оповещаю группу поддержки Dev & Tech (через тикет или по электронной почте — тикет назначается технической поддержке), и меня часто спрашивают: «Вы проверили X?» Где X — одна из 4 частей программного обеспечения, связанных с запуском нашего приложения. Я отвечаю нет, иногда добавляя, что не знаю как или у меня нет доступа.
Я не разработчик, и в большинстве случаев изучение этих серверных или обрабатывающих серверных программ для меня утомительно и требует много времени.
В коллективе уже установлено, что эти пункты не входят в мою зону ответственности. Похоже, что, поскольку я сообщаю о проблеме, разработчик ожидает, что я тоже займусь расследованием.
Однако недавно разработчики сделали вывод, что я должен получить доступ к этим программам и изучить их, чтобы я мог самостоятельно исследовать эти проблемы. Я получил множество «приглашений» по электронной почте, указывающих, что моему адресу электронной почты предоставлен доступ к этим программам.
Как я могу тактично отказаться изучать/использовать эти программы, не разыгрывая карту «это не моя работа»?
Вы не отказываетесь.
Вы сообщаете о своих опасениях своему руководителю, так как именно ваш руководитель (а не вы как физическое лицо) определяет объем вашей работы и требуемый доступ к системам, а не команда разработчиков. Если ваш менеджер говорит, что вы должны заниматься этим или иметь доступ к этим системам и инструментам, тогда вы работаете с командами разработки и эксплуатации, чтобы получить соответствующее обучение и доступ для выполнения той работы, которая входит в ваши обязанности. Если ваш руководитель говорит, что эта работа выходит за рамки вашей работы, он должен довести это до сведения команды разработчиков и их руководителя.
Если, поговорив со своим менеджером, вы по-прежнему чувствуете, что ожидания вашего менеджера в отношении работы, которую вы выполняете, не совпадают с вашими ожиданиями в отношении работы, которую вы выполняете, вы можете уйти со своей должности и найти новую работу, которая более интересна. в соответствии с тем, что вы ожидаете.
Чтобы продолжить редактирование вопроса.
Если уже было решено, что это не входит в ваши обязанности, вы должны сообщить своему менеджеру, что команда разработчиков (все еще) делает эти запросы. Ваш менеджер должен следить за тем, чтобы ваше время и усилия тратились на выполнение порученной вам работы. Это их битва, а не ваша.
Однако, как сам разработчик, я бы (и ожидал, что мой менеджер) отверг бы идею о том, что это выходит за рамки вашей работы. Я нахожу подозрительным (и небезопасным) то, что вся команда разработчиков будет иметь доступ к производственным системам и данным. Поскольку похоже, что ваша работа заключается в оказании поддержки на местах, я ожидаю, что эти люди имеют по крайней мере доступ для чтения к конфигурации системы и данным и могут включить их в отчет о проблеме, чтобы мне было намного быстрее воспроизвести и спроектировать решение.
По-прежнему кажется, что это проблема, которую необходимо обсудить с руководством, чтобы убедиться, что все понимают роль всех остальных. Похоже, компания не такая уж большая, так что это не должно быть слишком сложно для всех.
Чтобы еще раз дополнить некоторые из ваших комментариев, похоже, что у процесса вашей компании есть серьезные проблемы.
Если вы отправляете запросы в службу технической поддержки, я бы не ожидал, что команда разработчиков вообще будет вовлечена. Возможно, команде технической поддержки может понадобиться какая-то информация от вас, но я ожидаю, что команда технической поддержки либо исправит проблему, либо передаст ее команде разработчиков, если потребуется их помощь. Я ожидаю, что команда разработчиков взаимодействует с командой технической поддержки, а не с вами для понимания проблем, привлекая вас только в случае необходимости.
Опять же, мои исходные пункты остаются в силе: не вмешивайтесь сами. Поговорите со своим менеджером и попросите его поработать с менеджерами.
Вам нужно обсудить это с вашим боссом. Может быть, ожидается, что представитель по связям с клиентами сможет решать простые проблемы, и только проблемы, требующие программирования, должны передаваться разработчикам. Если это так, вы ни в коем случае не можете отказаться от использования программного обеспечения. Поэтому спросите его или ее, что именно ожидается от кого-то в вашем положении в отношении этих программных пакетов и клиентской поддержки. это не отказ от выполнения задачи, а просто просьба разъяснить, как это соотносится с другими вашими обязанностями и приоритетами.
Также может случиться так, что разработчики не хотят выполнять работу по поддержке, поэтому пытаются переложить ее на вас, когда они должны это делать. Только ваш босс может решить, что правильно.
Как я могу тактично отказаться изучать/использовать эти программы, не разыгрывая карту «это не моя работа»?
Мне все еще было бы интересно услышать, как это сказать в тот момент, когда меня подталкивает команда разработчиков.
В качестве ответа «в данный момент» вы можете сказать: «Изучение этих программ потребовало бы больших затрат моего времени, но об этом стоит подумать. Я спрошу мнение вице -президента о моих приоритетах и вернусь к ты."
Это технический стартап, поэтому я, 1 техническая поддержка, 1 техническая поддержка с частичной занятостью / разработчик с частичной занятостью, 2 выделенных разработчика и вице-президент. Обычно я сообщаю, а не занимаю пропускную способность Tech, поскольку могу использовать систему продажи билетов. Но, может быть, мне стоит просто написать в технический отдел?
Насколько я понимаю, сотрудники стартапов должны научиться многим ролям за пределами своей зоны комфорта, и это может быть хорошей возможностью для вас. Если проблемы ваших клиентов решает кто-то другой, они обойдут вас (сотрудника по связям с клиентами) и будут работать с этим человеком. НО, поскольку вы единственный продавец, тратить все свое время на новые продажи может быть важнее, чем развивать отношения с существующими. Решение о том, что важнее, звучит как «не твоя работа».
support
или даже key user
роль. Действуйте так же, как и с любым другим входящим приглашением на роль.Пара фактических моментов:
Приглашения на рабочие роли и обязанности случаются, они могут не обязательно исходить от вашего руководителя, хотя решение принимаете вы и ваш руководитель.
Ожидания вашего карьерного роста определяют вашу готовность принять/отклонить приглашение.
Этот процесс должен сопровождать ваш менеджер (в идеале с самого начала), потому что одна из его обязанностей — следить за вашей карьерой и управлять ресурсами команды («Можно ли выделить для этого этого члена команды?»)
Потенциальное принятие роли должно сопровождаться ожидаемым процентом вашего времени, т.е. ожидается, что вы посвятите 20% своего времени этой новой ответственности. И также должен быть план выхода из какого-то настоящего, чтобы было место для этого.
Обновление из того, что я прочитал в комментариях на этой странице. Вы должны создать tix и назначить их группе технической поддержки, которая затем назначит / расследует по мере необходимости. Иногда разработчики забывают, что они лингвисты, переводящие один язык на другой.
Более серьезной проблемой, похоже, является нарушение связи, учитывая, насколько вы малы, но разработчики не обучены управлению, не позволяйте им управлять вами.
Оригинальный ответ: Вы не делаете.
Вы можете переместить электронные письма в отдельную папку и оставить их там, и это, вероятно, конец проблемы. Разработчики не дают вам задачи, вы даете им задачи.
Я бы не стал нагнетать обстановку - уже установлено, что это не входит в вашу компетенцию.
Если разработчики начинают с вопроса «Вы исследовали», вы можете либо указать на электронное письмо, в котором описаны ваши задачи, либо ответить «нет», либо предложить их менеджеру разработать простой клиент REST, который можно использовать для доступа к конкретным задачам. данные, необходимые для отладки проблемы.
Не пытайтесь изучить какой-то случайный программный компонент. Если разработчики не выполняют свою работу, сообщите об их опоздании своему/их менеджеру.
Возможно, есть проблема со связью. Иногда удивительно сложно отследить «ошибку», когда ее нельзя воспроизвести в среде разработки, а упомянутые инструменты могут предоставить разработчикам необходимую информацию для решения проблемы. Часто билет настолько загадочен, что даже не знаешь, с чего начать. Эти инструменты также можно использовать в качестве средства проверки работоспособности, чтобы убедиться, что конфигурации находятся в пределах параметров. Иногда «ошибки» — это «мы никогда не собирались делать это». К сожалению, понятное пользователю сообщение об ошибке может быть не сгенерировано. Опять же, если разработчик не понимает намерения конечного пользователя, их может быть трудно понять. Возможно, разработчикам и клиентам нужно сказать, что вы всего лишь продавец, «эксперт». Технология сразу поступает в продажу для установки, настройки и поддержки. Этот «эксперт» не обязательно должен быть высококвалифицированным, но должен быть готов и способен научиться определять желания клиента (не всегда легко), распространенные проблемы и решения, а также быть в состоянии пройти основные этапы диагностики. Если бы я был разработчиком, то причиной, по которой я мог бы попросить вас попробовать другие инструменты, была бы помощь в сборе данных, чтобы можно было диагностировать проблему и разработать наилучшее решение. Если вы можете дать разработчику лучший вариант, помогая ему выполнять свою работу, он воспользуется этим. причина, по которой я мог бы попросить вас попробовать другие инструменты, заключается в том, чтобы помочь в сборе данных, чтобы можно было диагностировать проблему и найти лучшее решение. Если вы можете дать разработчику лучший вариант, помогая ему выполнять свою работу, он воспользуется этим. причина, по которой я мог бы попросить вас попробовать другие инструменты, заключается в том, чтобы помочь в сборе данных, чтобы можно было диагностировать проблему и найти лучшее решение. Если вы можете дать разработчику лучший вариант, помогая ему выполнять свою работу, он воспользуется этим.
Есть причина, по которой ваша компания не имеет разработчиков в качестве первой линии поддержки клиентов. Причина в том, что разработчики обычно работают над достижением конкретных целей в установленные сроки. Если бы разработчикам приходилось останавливаться, чтобы решать все проблемы клиентов, ваша компания никогда бы не выпускала никаких обновлений (включая исправления критических ошибок).
Ваша работа, с другой стороны, на самом деле не начинается до тех пор, пока не зазвонит телефон или вы не получите служебные билеты.
Поэтому было бы разумно, если бы вы изучили любые инструменты, которые помогут вам выполнять свою работу, то есть поддерживать клиентов И создавать безопасное пространство для разработчиков, чтобы они могли выполнять свою работу с минимальными перерывами. Это на самом деле делает вас ценным членом команды. Если вы хотите поднять шум из-за необходимости учиться чему-то новому, в конечном итоге ваш работодатель без проблем заменит вас кем-то, кто более открыт для обучения.
Вы работаете в технологической компании. Разработчики не могут сказать руководству, что они не хотят заниматься изучением новых технологий, которые помогают компании в целом, и вы тоже не можете.
Уэсли Лонг
СНСД
Уэсли Лонг
Томас Оуэнс
Губка Боб
Майкл Кей