В долгосрочных проектах необходимо постоянное информирование заказчика (или вашего босса) не только о том, как проходит решение задач, но и о том как обстоят дела с решением багов. А точнее, необходимо иметь чёткое согласие о балансе между этими двумя компонентами. Если этим правилом пренебрегать, то возникает явление которое я называю “различием фокуса внимания”, и случается вот такая жопа:
Вы сидите и занимаетесь проектом уже не первый месяц, даже не первый год. У вас в плане NNNN задач и NNNN багов. План расписан на несколько месяцев вперёд, по релизам или по итерациям, не важно. Суть в том, что вы имеете широкий фокус внимания, охватывающий весь этот объём. Вы смотрите на него, как смотрели бы на водопад или огонь в камине: работа идёт по плану, задачи выполняются, баги решаются, команда работает в рамках регламента.
И тут вашему боссу звонит на мобильник какой-нибудь VIP-партнёр. И говорит: “слушай, что у тебя там парни совсем оборзели, мы уже три недели ждём решения баги про бла-бла-бла!” И бросает трубку.
Босс подрывается с места и бежит к вам (ну, или форвардит письмо, не стесняясь в выражениях) и задаёт один риторический и абсолютно бесполезный вопрос:
– Когда будет исправлена эта бага?
На самом деле ему не нужен никакой ответ, кроме как “уже исправлена”. Всё остальное будет встречено истерикой. Предположим, что вы заглянули в баг-трекер и отвечаете:
– Эээ.. ну как же. Вот она в плане стоит на такой-то релиз.
– Какой к чёрту план, вы сферические уроды в вакууме, никакой клиент-ориентированности! Это же вип-партнёр!
– Эээ.. ну вот же, у нас ещё 500 багов от других вип-партнёров? Решаем по плану.
– Но ведь они столько не ждут, а эта ждёт три недели!
– Эээ.. как же так, вот другие баги ждут по два месяца.
– Вас тут 100500 программистов, решайте сейчас же!
Хорошо, если ситуация на этом будет исчерпана. Ну потратите вы пару дней, решите эту багу, примените патч партнёру, он успокоится. Но может сложиться так, что дальше начнётся забавный идиотизм:
– Так, теперь я вижу что вы ни..уя не клиент-ориентированы. Отныне приказываю: решайте баги в течение трёх дней с момента поступления.
Разработчики, как люди в целом дисциплинированные и логичные, тут же откроют баг-трекер и отфильтруют задачи в пределах последних трёх дней. А у вас там ещё за два месяца баги висят, помните? Сами догадаетесь что с ними произойдёт? Верно. Они не будут решены никогда.
В дальнейшем, если доводить ситуацию до абсурда, ваша команда полностью перестроится на решение багов, и на задачи будет отводиться в лучшем случае 10-15% рабочего времени. Как это скажется на успехах проекта – очевидно.
Мораль: вы как менеджер или тимлид – имеете широкий фокус внимания, охватывающий весь проект. Это свойственно техническим менеджерам и разработчикам, потому что им надо держать в голове всю архитектуру проекта или все требования ТЗ. Ваш босс, заказчик, или сейлз – имеют узкий фокус внимания, потому что в основном решают оперативные задачи (требующие быстрой реакции), а не стратегические (требующие длительного размышления).
Поэтому босс в такой стрессовой ситуации (после того звонка VIP-партнёра) никогда не задумается о том, что бага не решается по каким-то объективным причинам – потому что она стоит в очереди, потому что имеет средний приоритет, потому что бизнес компании не сбалансирован и нет ресурсов на решение проблем вовремя. Гораздо проще и быстрее в голову приходит понятная и удобная причина – “виноваты разработчики”.
Для того, чтобы избежать описанной ситуации, всегда держите босса в курсе объёмов работ и производительности команды. Избегайте любых попыток скрыть баги, вынести их в отдельный баг-трекер, назвать их “повседневной текучкой” и игнорировать любым подобным образом. Ваши задачи и баги должны “иметь равные права”, быть сосредоточены в одном и том же трекере, и выполняться в одном и том же плане работ.