Как задавать лучшие вопросы младшему разработчику программного обеспечения

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

Помню, всего пару месяцев назад, когда я устраивался на новую работу, у меня были те же тревоги, что и при устройстве на первую работу:

Я задаю слишком много вопросов?

омг, мои товарищи по команде раздражаются?

Это глупый вопрос?

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

Фотография Бенджамина Чайлда на Unsplash

Преамбула

Моей первой работой после окончания колледжа со степенью бакалавра компьютерных систем была должность администратора ИТ-поддержки в корпоративной организации среднего размера. На этой работе мне дали чужой стол с оговоркой:

О, просто перемести немного вещи, но будь осторожен, они могут скоро вернуться".

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

Я продержался два месяца (но ушел с замечательным другом!).

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

Дайте мне знать, когда будете готовы отправить повторно.

Я дал им знать через 4 недели - что это, вероятно, не подходит для меня.

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

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

Инженерная поддержка

Добро пожаловать в службу поддержки, лучшая чертова организация в компании

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

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

^ Работа над Билеты

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

На самом деле, я помню, как подумал про себя:

В школе я научился делать самые разные вещи, от создания собственного ядра ОС с нуля до написания программ, поддерживающих параллелизм и ПОКА; урок, который я использовал больше всего на этом концерте, — это мой урок философии.

Логические ошибки. Представление информации. Заказ помещения. Мои не технические специалисты были бы в восторге!

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

Фотография Келли Сиккема на Unsplash

Эскалация

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

Иногда - были бы билеты, тогда как CSR вы бежите на пределе своих возможностей. Либо в том, что вы знаете о проблеме, либо в ваших способностях устранять неполадки и решать проблему. В этот момент нам нужно эскалировать заявку UP инженеру технической поддержки (TSE).

https://media.giphy.com/media/l2SqbG9QAz1Z314Uo/giphy.gif

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

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

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

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

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

Тем не менее, набор хороших заметок по эскалации -- те, в которых:

• TSE не нужно было возвращаться к вам с дополнительными вопросами,

• есть сводка того, что было опробовано,

• содержит все необходимое для продолжения работы по билету;

Это все равно, что отправить отполированный шар для боулинга по только что натертой дорожке. Вы можете видеть, что TSE принимает и обрабатывает его и (в зависимости от проблемы) быстро продвигается к решению. Забастовка!

Фото автор Элла Кристенсон на Unsplash

Если вы написали хорошие примечания по эскалации, запросы решались быстрее.

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

Фото автора Камилла Баттани на Unsplash

Вопросы, как эскалации?

Перенесемся на пару лет вперед, и я перешел от службы поддержки к разработке в качестве инженера по облачной инфраструктуре. Теперь я был маленькой рыбкой в ​​огромном океане, и мне нужно было задать много вопросов. Эта потребность в информации в сочетании с большим количеством беспокойства и синдромом самозванца была не хорошей комбинацией. В то время как мои товарищи по команде так поддерживали и всегда были рядом, чтобы ответить на вопросы, я начал задаваться вопросом:

Хм, а что, если бы я начал думать о вопросах как об эскалации? Будет ли это иметь значение.

Ответ да.

Я заметил, что когда я начал применять те же принципы, произошло следующее:

1. На мои вопросы ответят быстрее.

1. Мои вопросы будут подчеркивать ресурсы и делиться пониманием с остальной частью команды.

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

1. \

Итак, вот:

Фото Zan на Unsplash

5 советов, как лучше задавать вопросы юниорам

(Халява) 0. Представьте, что вы задаете свой вопрос самому себе.

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

Какие вопросы они будут задавать?

Это дает достаточно информации?

Что, если они спросят о X?

Должен ли я уточнить Y?

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

1. Постановка задачи — один лайнер

В чем проблема?

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

2. Контекст — желаемое конечное состояние

Почему это проблема? Что ты пытаешься сделать? Каково ваше желаемое конечное состояние?

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

3. Предпринятые шаги — уточняющий вопрос

Что вы уже пробовали и исследовали?

Эта часть вопроса чрезвычайно полезна для очень многих сторон

• Для людей, читающих ваш вопрос, это может служить списком вещей, которые не следует рекомендовать / проверять, потому что вы уже сделали это - экономя время. Это также показывает, что вы как задавший вопрос потратили время на уточнение своего вопроса.

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

• Для спрашивающего это может помочь вам чувствовать себя более уверенно в обоснованности вашего вопроса, потому что вы видите, что приложили усилия для исследования, исследования и решения самостоятельно.

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

4. Следующие шаги – возможные решения

Какие следующие шаги вы предпримете или что исследуете?

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

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

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

А иногда даже они могут даже не знать, с чего начать, но это утверждение может зажечь их мыслительный процесс!

5. Запрошена помощь - средства для помощи

Какая помощь вам нужна? Когда ты доступен?

Большинство товарищей по команде хотят помочь вам. Тем не менее, они также заняты своей собственной работой. Иногда они могут видеть ваш вопрос (и знать ответ!), но задача или звонок в данный момент могут отбить у них желание связаться с вами.

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

Пример хорошего вопроса

Этот вопрос взят из вопроса, который мне нужно было задать на прошлой неделе!

1. Эй, кто-нибудь знает, как уменьшить срок хранения для Prometheus-Server?

1. Заполнился диск на Prometheus-Server и он не может отправлять метрики в Grafana

1. Мы пытались внести изменения в диаграммы руля, но они не прижились.

1. Я, вероятно, собираюсь попробовать сделать kubectl edit в кластере в реальном времени, но не уверен, что это лучший способ.

1. Я доступен для совещаний, если кто-то свободен, но также подходит для встречи Google через 1 час.

Вывод

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

В качестве более адаптированного примера CS:

1. Есть ли у кого-нибудь хорошее привлекательное событие для повышения продаж стартапа до уровня предприятия?

1. У меня много клиентов-стартапов, которым нужно получать дополнительный доход для моего портфолио.

1. Я уже использовал рекламу преимуществ нескольких продуктов, но она не прижилась

1. Я думаю об изменении правил NIST в следующем году.

1. Я свободен после 2 сегодня, если кто-то свободен в ролевой игре

Я надеюсь, что этот пост поможет вам задать вопросы, и если есть другие моменты, которые вы бы добавили, пожалуйста, оставьте мне комментарий :)

У этой истории также есть сопутствующее видео здесь:

https://www.youtube.com/watch?v=hlkwSgy8ujw

Впервые опубликовано здесь