Do It Tomorrow. Обязательства | 2021-01-05

Прочитал широко известную в узких кругах книгу — Do It Tomorrow by Mark Forster (русское издание). Я уже был знаком с основными идеями, но не пожалел, что прочитал всю книгу. Нашел там что-то интересное конкретно для меня.

Форстер утверждает, что работа не возникает сама по себе. Все задачи возникают из-за обязательств (commitments), которые мы на себя берем. Если вы берете на себя обязательство «квартира должна быть чистой», то регулярно возникают задачи «вынести мусор», «пропылесосить ковры», «протереть пыль». Если вы принимаете решение «жить в грязи», то ничего делать не надо.

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

Я уже долгое время ищу хорошие практики, как сочeтать разработку новых штук с большим количеством поддержки. Моя команда поддерживает большое хранилище данных и хочется, например, улучшать мониторинг за качеством данных. Задачи по поддержке возникают регулярно — кто-то хочет подключить новый источник данных или нужно помочь отдебажить сложный запрос.

Я долгое время считал, что нужно делать в первую очередь «важное», то есть разработку новых фичей. А поддержку осуществлять в оставшееся время или когда совсем припечёт. В итоге у нас большой список задач в трекере, а новые фичи не доведены до ума и генерируют еще больше работ по поддержке. Эта куча давит на тебя и кажется, что ты никогда её не разгребешь.

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

В общем, я пришел к выводу, что нужно делить весь поток входящих задач на два: «обязательства» и «хотелки». Всё что приходит из существующих обязательств — лучше делать в пределах одного-двух дней. А хотелки могут лежать до более свободных времен. Так сразу стало понятнее, справляемся ли мы с нагрузкой или надо еще нанимать людей.