Перевод статьи Майка Орама “It’s okay to ask questions”.
Я обучал много разработчиков и тех, кто только хотел таковым стать. Одна из вещей, которые я повторяю в классах вновь и вновь, это то, что задавать вопросы — нормально! По моему опыту, многие разработчики-новички или джуниоры избегают спрашивать что-либо у своих товарищей. Однако я считаю, что любой разработчик в любой команде должен чувствовать, что спрашивать – это безопасно, удобно и вообще поощряется!
Я думаю, люди стараются не задавать вопросов по одной из следующих причин…
Причина №1
Самая распространенная причина – нежелание, чтобы коллеги считали их менее умелыми и знающими. «Может, если я буду задавать слишком много вопросов, люди могут подумать, что я не знаю, что я делаю». Мой вопрос следующий: можно ли вообще задать слишком много вопросов? Я в любой ситуации предпочел бы, чтобы мои ученики спрашивали обо всем, что им нужно, и таким образом быстрее учились и верно ухватывали суть. При таких раскладах никому не придется проводить целые часы, раздраженно исправляя неверный код с багами, или даже рисковать деплоить баги.
Причина №2
Другая часто встречающаяся причина не задавать вопросов это желание разобраться с проблемой самому. Это совершенно закономерно, поскольку каждый должен иметь возможность решить задачу самостоятельно. Это прекрасный способ обучения. К тому же, когда вы находите решение самостоятельно, у вас возникает приятное ощущение достижения, а в этом нельзя отказать ни единому разработчику.
Однако никто и не должен слишком долго застревать в решении проблемы. Это приводит к разочарованию, падению морального духа и утрате мотивации. Следует помнить и о такой вещи, как «кодовая слепота», – проблеме, касающейся не только джуниоров.
Что значит «слишком долго»?
Но где находится грань? «Слишком долго» разбираться с проблемой прежде чем обратиться за помощью — это сколько? Я считаю, что на этот вопрос нет единого ответа. Все проблемы разные, поэтому и время на их решение тоже всегда будет разным. Но в целом я советую своим ученикам, прежде чем обращаться за помощью, отводить себе 20 минут начиная с того момента, когда они совершенно запутались.
Это не значит «потратьте 20 минут на проблему прежде чем сдаться». Это значит, что вы должны проводить над решением проблемы столько времени, сколько вам нужно, но только пока у вас наблюдается прогресс. Когда у вас совершенно исчерпаны идеи и приходится гуглить вопросы типа «как сделать…», дайте себе 20 минут на попутку найти решение, а затем обращайтесь за помощью.
Один из способов решения этой проблемы — использование методологии Agile и средств оценки задач. В подобные моменты точки оценки становятся жизненно необходимыми. После оценки ваших историй и заданий у каждого члена команды должно остаться грубое представление о том, сколько времени что-либо должно занимать. Поэтому наблюдение за протяженностью задач коллег поможет предотвратить застревание людей на слишком долгое время. Если у вас есть scrum master, это может быть важной частью его роли.
Но в конечном счете поощрение хорошей культуры постановки вопросов и сотрудничества с коллегами является здоровым и полезным для компании, команды и каждого человека. Это создает лучшие отношения и в долгосрочной перспективе повышает производительность. Как и парное программирование, это необходимая часть развития вашей команды и вашего собственного совершенствования.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]