Худший вопрос, который вы можете задать разработчику

Вот он, прямо перед вами — худший вопрос, который вы, как менеджер по разработке программного обеспечения, можете задать разработчику: «Когда вы закончите?»

Вот и все. Худший вопрос. Не закрывайте страницу прямо сейчас, потому что вопрос, который вам действительно стоит задать, находится в конце (Ха!).

Что не так с этим вопросом? Разве менеджерам не нужно знать, когда что-то будет сделано? Как еще они могут узнать, если не спросить?

Представьте себя этим разработчиком (предположим, вы работаете в какой-то Agile-среде, а единица работы — это История, но все равно это плохой вопрос независимо от модели разработки, в которой вы работаете). Вчера вы прочитали новую Историю, и во время выступления какой-то менеджер спрашивает: «Когда это будет сделано?» Вы знаете, что вам еще нужно написать кучу кода. Вы знаете, что код должен вызывать User API, для которого у вас есть документация, но который вы никогда не использовали. Вы знаете, что Боб переписывает часть системы конфигурации в своей Истории, и вам придется объединить ее с вашей. Вы знаете, что в тестовой среде в последнее время возникли проблемы, и Джейн, ваша потрясающая QE, все еще пытается выяснить, является ли это причиной случайного сбоя тестов API. Вы знаете, что для достижения  состояния законечнно, вам нужно, чтобы Сэнди, старший разработчик в вашей команде, проверил код вашего pull request — а Сэнди, как известно, очень занята.

Зная все это, что вы скажете? Может быть вы предположите лучший сценарий для каждой из десятка вещей, которые должны произойти, чтобы закончить эту Историю? Или вы предположите, что что-то пойдет не так, даже если не знаете, что это такое, и не можете сказать, когда вас спросили? Что произойдет, если вы просто скажете «возможно, около трех дней работы», но затем обнаружите, что документация по User API на самом деле ужасно устарела, и все ваши письма с мольбами, сообщения в Slack и телефонные звонки к единственному оставшемуся разработчику остались без ответа? Как вы объясните всю эту путаницу, сложность и неопределенность в своем ответе?

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

Проблема с «Когда вы закончите?» в том предположении, что разработка программного обеспечения — это что-то вроде производства — предсказуемый набор шагов, каждый из которых занимает известное время. Вы разрабатываете код, пишете код, тестируете код, развертываете код — и все готово.

К сожалению, разработка программного обеспечения — это не набор предсказуемых шагов. Это запутанная сеть возможных путей решения с ответвлениями, петлями, тупиками и даже шагами, о необходимости которых вы не подозреваете, пока не столкнетесь с ними. Вот почему разработка программного обеспечения больше похожа на процесс научных открытий или изобретений, чем на производство. Сколько времени потребуется, чтобы открыть Теорию Всего? Может, в следующем году, а может, никогда, кто знает? Как и научное открытие, разработка программного обеспечения непредсказуема, запутана, полна препятствий и непредвиденных проблем, альтернативных путей, тупиков и плохих идей, которые когда-то казались работоспособными.

Правдивый ответ на вопрос “Когда вы закончите?” — “Сложно сказать».

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

Если вы менеджер и просите лучший (быстрый) срок после первого вопроса «Когда вы закончите?», то вам следует пересмотреть свой жизненный выбор.

Получение оценок и то, что вам нужно спросить на самом деле

Менеджеры — те, кто все еще читает — вероятно, закатывают управленческие глаза, как обычно и делают менеджеры. В своих управленческих головах они думают, что это я, мистер Наивный Автор Блога, не понимаю реальности. «У проектов есть сроки, и руководство компании должно понимать, как проект в них укладывается», — сказали бы они.

Я согласен, но определение оценок завершения и отслеживание работы команды в соответствии с установленными сроками — это ваша работа как менеджера. Не уклоняйтесь от своего долга и не перекладывайте ответственность на своих подчиненных, заставляя их следовать определенной оценки времени для выполнения сложного набора задач. Хотя я не могу решить все ваши управленческие проблемы за вас, вот две альтернативы вопросу «Когда вы закончите?».

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

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

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

Готовы? Откройте свои управленческие блокноты и запишите это: «Что осталось сделать?».

Вот в чем вопрос. Это так просто, и каждый грамотный разработчик легко и радостно ответит вам.

На этот вопрос наш пресловутый разработчик сказал бы: «Ну, вчера я завершил большую часть скелетного кода. Мне все еще нужно понять работу пользователей, чтобы получить информацию о профиле, а затем интегрировать новый код конфигурации, который пишет Боб, который все еще находится в разработке. Мне нужно поработать с Джейн, чтобы убедиться, что тесты API, которые я пишу, не страдают от этой нестабильной тестовой проблемы, и попросить Сэнди все проверить, а затем продвинуть все в QA».

Это должно сказать вам, как менеджеру, все, что вам нужно знать. Да, нужно немного подумать, чтобы превратить эту информацию во время. Вы должны учитывать этот пUser API, доступность Сэнди и, возможно, некоторые вещи, о которых разработчик даже не думает. Это требует усилий и понимания, но оставляет ответственность за преобразование сложности в простую оценку времени на вас.

Опять же, дело не в том, что приблизительная оценка времени разработки программного обеспечения невозможна. Дело в том, что в этих оценках есть огромная неопределенность. Ответственность за эту неопределенность, знание того, как сообщить о ней, знание того, как застраховаться от нее, и принятие на себя ответственности, когда оценка «неверна», ложатся на вас. Как менеджер, вы должны знать, в каких комнатах вы можете сказать: «Это нужно сделать к следующей пятнице», а в каких — нет. Оценки — это заряженное оружие, и вы, как менеджер, несете важную ответственность за то, чтобы обращаться с ними с максимальной осторожностью.

Конечно, если у вас нет технического или контекстного понимания, чтобы перевести более длинное «Что осталось делать?» в короткое «Когда это будет сделано?», то не следует задавать этот вопрос. Прекратите спрашивать и попросите кого-нибудь квалифицированного вмешаться. Может быть, управлять менеджерами вам больше подходит?

Первая стратегия (относительная оценка, процент выполнения и т.п.) дает вам общую картину на уровне проекта, которая обычно требуется руководству. Вторая («Что осталось делать?») дает вам детальную информацию на уровне Истории, которая обычно имеет ценность, когда ключевые истории или функции необходимы другой команде или к крайнему сроку завершения спринта. Вместе они дают вам два инструмента, которые могут заменить «Когда вы закончите?».

Менеджеры, которые дочитали до этого места — у вас есть надежда. Несмотря на шутки, вы критично относитесь к разработке программного обеспечения. Не позволяйте плохим вопросам портить ваши отношения с командами разработчиков. Не задавайте вопросов без ответа, чтобы перекладывать вину на беспомощных разработчиков. Сказать своему руководству: «Ну, он сказал мне, что сделает это к пятнице. Это не моя вина!» это не лидерство. Это поиск козла отпущения.

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

Источник