Как задавать технические вопросы
Примерно лет 5 тому назад, работал я системным администратором и решил переквалифицироваться, полностью уйдя в разработку. С этой целью записался на обучение, которое проходило в формате менторства. Выдается задание, общение в текстовом чате с преподавателем. И вот там, перед самым первым заданием, кидали ссылку на статью о том, в каком формате нужно задавать вопросы своему ментору, чтобы обучение проходило максимально эффективно. О некоторых пунктах этой статьи как раз и пойдёт речь.
Сейчас существует множество информационных технологий, и знать всё обо всём просто невозможно, поэтому рассматриваемый навык имеет актуальность для многих айтишников. По одной формулировке вопроса в профильном чате, посвященному конкретной технологии, уже можно сделать некоторые выводы:
- уровень компетенции данного специалиста
- вероятность того что человек сможет решить свою проблему
Чем лучше человек соблюдает границы в своем запросе, тем выше его шансы получить помощь.
Перед тем как спрашивать.
Перед тем как обращаться с вопросом, нужно попробовать сформулировать на него ответ или несколько ответов самому. Для этого требуется поискать через google, почитать документацию, профильные группы/форумы, устроить эксперименты на своем компьютере с фиксацией результатов, сделать предполагаемые наброски решения, очень четко описать контекст в котором происходит исполнение программы(версии приложений, операционных систем, протоколов). Желательно, чтобы на вопрос можно было просто ответить “да/нет”, минимально нагружая отвечающего.
Спрашивающий как раз и будет оценен по объему проделанной домашней работы, когда он отразит, что именно нашел, изучил, какие сделал выводы по своей проблеме. Если объем затраченных усилий равен примерно нулю - то и вопрос может быть очень легко проигнорирован. Сама суть этих пунктов направлена на то, чтобы человек, предельно ясно сформулировав, увидел ответ или его проблески самостоятельно, и только потом уже начинал искать помощь. Качественно сформулированный запрос может оказать влияние на некоторые аспекты в документации технологии, ваш код могут взять как пример для демонстрации какого-то эффекта.
Примеры.
“Всем привет! Я новичок и хочу попробовать изучить X. Кто-нибудь даст инструкцию как это сделать?”
“Привет. Планирую научиться X. Оценил доступные ресурсы и хочу изучать их в следующем порядке: https://ссылка1, https://ссылка2, https://ссылка3. Скажите, пожалуйста, данный план адекватен? Или информация по ссылкам уже устарела и неактуальна?”
“Добрый день. Вчера запускал Y и че-то всё сломалось совсем. Хз чё делать. Тут кто шарит в Y? “
“Добрый день. Недавно поставили Y и есть проблемы в его работе. Конфигурацию сервера можно увидеть здесь https://ссылка1, конфиг клиента здесь https://ссылка2, пример запускаемого кода можно увидеть здесь https://ссылка3. Лог файл с ошибкой здесь https://ссылка4 . Работает все на операционной системе FreeBSD версия 10. Варианты решений вижу такие:
1) Попробовать поставить Y более старой версии 0.9
2) Попробовать сменить Y на Z, говорят он более стабилен
3) Заменить FreeBSD на другую опер. систему
Скажите, пожалуйста, сталкивался ли кто-то с похожей проблемой? Что-то пробовали из моих вариантов?“
Правильный выбор адресата вопроса
Бывает так что человек не стал вникать в правила данной группы и задаёт вопрос совершенно не по теме, копирует свой вопрос в кучу групп со схожей тематикой и одновременно пишет персональные письма админам канала. Или сразу пишет главным разработчикам технологии, не попробовав найти ответ у обычных пользователей. Такие действия только повышают шансы на полный игнор.
Грамотность и вежливость.
Текст с большим количеством опечаток и ошибок наводит на мысли, что автор столь же небрежен в решении своей проблемы и не уважает людей читающих его вопрос. Если вопрос задаётся не на родном языке, и уровень владения иностранным низкий, то лучше заранее это обозначить и извиниться за возможные неточности в формулировках.
Ни в коем случае нельзя использовать Caps Lock и кучи восклицательных знаков, такое расценивается как грубость. Нытьё о проблеме и разные пометки типа “Очень срочно!” не приветствуются в той же мере.
Лишняя информация в вопросе.
Некоторые разработчики присылают целые простыни кода, которые ещё и не работают, в надежде что кто-то будет разбираться с этим. Необходимо создать минимальный пример, демонстрирующий суть задачи или ошибку, без кучи дополнительный информации, которая только создает шум.
Описание фактов, а не догадок.
Для получения помощи важно описать именно факты в их хронологическом порядке, а не свои интерпретации, которые могут быть бесконечно далеки от истины.
Обратная связь с сообществом.
Если в какой-то группе или форуме дали совет который помог, то желательно написать в ту же тему, что предоставленные рекомендации помогли и проблема теперь решена.
Полную статью можно посмотреть здесь:
Оригинал стать на английском(2014 год)
Перевод на русский(старая версия 2002 год)