"Делегируй это" - Часть 3

– Окей, у нас есть понимание, что такое "достаточно хорошо". Попрошу сотрудника сделать и приму задачу, когда станет "достаточно хорошо", верно?

Ну..Почти.

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

Несколько критериев, которые помогут тебе понять, что результат описан прозрачно и хорошо:

1. Должен быть указан четкий срок окончания работы.

2. Результат должен быть осязаемым и измеримым. С минимумом пространства для интерпретаций.

"Сделать, чтоб было зашибись" (вы смеётесь, а я однажды получил код сервиса вот с таким комментарием) – абсолютно неизмеримый результат, плохо.

Разработать сервис для работы с товарами в магазине"

– чуть получше, но всё ещё плохо.

Разработать сервис с тремя http-хэндлерами: создание товара, редактирование товара, удаление товара, и получение товара

– лучше.

Разработать сервис с тремя http-хэндлерами: создание товара, редактирование товара, удаление товара, и получение товара. Создание и редактирование должны срабатывать за 100 мс, чтение – за 50 мс. Код должен быть покрыт юнит-тестами. Его должны окнуть на ревью в команде Y

– ещё лучше.

––

Иногда, попытавшись сформулировать результат, ты обнаружишь, что и сам не видишь его достаточно чётко.

Да чёрт его знает, какие хэндлеры нам понадобятся. Надо с продактом поговорить + поресёрчить – тогда видно будет.

И это нормально. Значит, так и записываем:

a. Сформулировать, что должен делать сервис. Для этого: поговорить с продактом, собрать требования здесь и здесь, и слепить дизайн-докb. Окнуть дизайн-док об меня, после чего мы сформулируем требования и дедлайны следующего этапа и обновим задачу

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

– А разве мы не убиваем пространство для творчества, подробно описывая результат?

Это – тонкая грань, которую важно не перешагнуть. До тех пор, пока ты вводишь ограничения, снижающие вероятность, что человек пойдет "не туда" или сделает "не то", всё окей. Хорошее решение ведь тоже нужно придумать. Отправлять людей перебирать все "плохие" – долго и дорого.

Но буквально описывать, какой код в каком файле нужно написать – это слишком.

Как можно точнее скажи, "что" должно быть сделано. Без необходимости – не говори "как". Уточняй до тех пор, пока и тебе, и исполнителю не станет абсолютно понятно, куда идти.