«Казалось бы, истина в заголовке, но я слишком часто встречал менеджеров, которые хотели схитрить и обойти это правило. Они приходят к команде разработки и говорят каждый на свой лад.
"Ребят, надо быстро напилить фичу, сделайте ее как-нибудь, презентуем, посмотрим, понравится ли клиенту, и тогда уже переделаем нормально". "Баги, которые сейчас вылезают, просто быстрыми фиксами закрой, а переделаем потом".
Вышесказанное можно свести к одному простому: "сделай как-нибудь, потом сделаем нормально".
От таких фраз происходит следующее.
— Автотесты попадают под нож первыми, их не пишут или пишут для галочки.
— Ручное тестирование тоже проходит в облегченном варианте.
— Техдолг растет.
Также хочу подсветить несколько моментов.
— «Потом» может не наступить.
— Когда светлое будущее наступит, на переделку уйдет в 2-3 раза больше времени, чем если бы мы сразу все сделали нормально.
— Также стоит учесть все то время, которое потрачено на баги из-за корявых решений, на которые мы согласились.
Предвещая неверное решение интуитивно, ты, как представитель команды разработки, сообщаешь об этом менеджеру, просишь дать время сделать все правильно. Так выйдет дешевле клиенту, команде не придется страдать, отлавливая баги, и мы не рискуем парализовать проект или его часть техническим долгом. И каждый раз менеджеры кивают и делают по-своему. На следующем планировании спринта нам приходит реализация новых фичей в быстром варианте, а про техдолг мы просто забываете.
Что было дальше?
На одну большую фичу пришли пользователи, нагрузки, и нам пришлось потратить несколько месяцев на баги и переделку. Техдолг не рассосался до конца, это так и осталась страшная фича, в которую зайдет только смелый.
Другой проект оказалось практически невозможно развивать спустя несколько месяцев работы, и его просто закрыли. Как итог — менеджер сменился.
Еще один проект, техдолг которого упорно не замечали, фактически оказался парализован до того момента, пока мы несколько спринтов подряд не начали заниматься только багами. Когда к тебе по 3-4 раза в день прибегает менеджер с каким-то срочным багом на проде — это просто дорога в могилу. Менеджер, кстати, и здесь сменился на нового.
А что произошло?
Были потрачены деньги на то, чтобы нанять новых умных программистов, платить им деньги за работу, тратить время на общение, но в итоге их просто не слушают. Может, стоит нанимать умных людей и слушать их? Или, может, это остатки советского мышления, что нам нужны "ученые", которые будут работать молча? Типа "результат их работы нам нужен, а их мнение — нет".
У меня есть догадки, в чем была лично моя ошибка. Наверное, я не умею верно доносить мысли до людей, или стоило более тщательно выбирать команду и проект для работы. Думаю, стоило следовать за интуицией и стоять на своем, постараться донести мысль до менеджера и напомнить еще раз то, с чего мы начали: "Нормально делай — нормально будет"».
