Control freak

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

В субботу читала лекцию об управлении потоковой разработкой перед шестикурсниками ЛИТМО. Было странно. И от напряжённого внимания после утвердительного ответа на вопрос «будет ли что-то из этого на экзамене?». И от необходимости постоянно делать скидку на полное отсутствие практического опыта у слушателей. Что им глубинные проблемы взаимодействия разработки и тестирования, если они никогда не занимались ни первым, ни вторым. Что им сложности общения с заказчиками, если у них не было ни одного. Доходило до смешного. Я пыталась объяснить, почему выбрала конкретный способ работы с системой контроля версий, и чувствовала, что теряю аудиторию, и переживала, что говорю запутанно о простых вещах. Оказалось, что об RCS им рассказали всего лишь на предыдущей лекции. Теоретики…

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

Уже традиционно для моих выступлений, я начала с описания непрерывного потока входящих задач, его количественных характеристик (много, много) и качественных особенностей (пересмотр приоритетов, изменение требований). Мне было важно показать, в каких условиях возникает потребность в потоковой разработке, чтобы затем сосредоточиться на том, как же в таких условиях нужно работать. Однако прозвучавший вопрос показал, что, возможно, я слишком сильно сгустила краски. Звучал он примерно так: почему руководство не решает проблему с таким непомерным количеством задач? О наивности веры в барина, который приедет и рассудит, ещё Некрасов писал, но вот нет же, до сих пор актуально. Я ответила просто: проблема не в количестве задач, ведь каждая кому-то и для чего-то нужна; проблема в нашей (возможной) неспособности этот поток требований адекватно обрабатывать. Однако позже я задумалась, в какой момент я бы ожидала вмешательства или помощи от руководства? Если оставить в стороне очевидные роли заказчика и контролёра, остаётся, мне кажется, только позиция реферера, судьи, к которому можно обратиться при возникновении конфликта интересов между проектами или командами.

Иногда руководитель берёт на себя обязанности и другого рода, скажем, координаторство или проработку архитектуры системы. Одна это скорее совместительство, не так ли?

Второй вопрос был намного ближе к практике. Я рассказала, что использую заведённые баги как один из критериев оценки качества разработки, имея в виду, что чем ближе к поверхности найденная ошибка (скажем, заголовок страницы не соответствует постановке), тем меньше верстальщик уделял внимание мелочам. Каждый имеет право на ошибку, и чем сложнее она в обнаружении, тем, если можно так сказать, простительнее. После этого меня спросили, не считаю ли я, что важнее отсутствие ошибок в основном функционале, и не стоит ли легче относиться к мелким недочётам. По-видимому, произошла некая путаница понятий. Да, в процессе работы над задачей начинать следует с наиболее головоломной её части, тем более что чаще всего на это уйдёт и большая часть отведённого времени. Однако если проект не запускается из-за одной пропущенной запятой – он всё равно не запускается. При этом на поиск таких мелочей тратится ценный ресурс – тестировщиков, которым лучше было бы сосредоточиться на сложных сценариях и проверках.

Но это всё детали… Надеюсь, я дала студентам информацию к размышлению, как и они мне – своими вопросами.