Есть старая история о том, как NASA пыталось разработать ручку, которой астронавты могли бы пользоваться в космосе. Было сложно заставить чернила течь вверх, и подобные ручки продолжали отказывать. Америка потратила миллионы долларов, пытаясь придумать космическую ручку, пока кто-то не понял, как русские решили эту проблему – они использовали карандаши. Это, конечно, байка, но ее по-прежнему можно услышать в софтверном мире. Как и все хорошие байки, она иллюстрирует распространенную ошибку – решение не той проблемы. NASA нужно было ломать голову не над тем, как сделать ручку, которая пишет в невесомости. Проблема заключалась в том, как писать в космосе.

По сути, методология «Спросите своего разработчика» – это предоставление полномочий. Люди в любой сфере деятельности стремятся соответствовать ожиданиям в их отношении. Методология «Спросите своего разработчика» предполагает высокие ожидания в отношении разработчиков, причем это касается не объема написанного кода, а использования изобретательности и созидательной энергии для решения величайших проблем мира. Разработчики могут соответствовать подобным ожиданиям только в случае предоставления им полномочий и широких возможностей. Самое главное – делиться с ними проблемами, а не решениями.

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