Казалось бы истина в заголовке, но я слишком часто встречал менеджеров(Project Manager/Product Owner) которые хотели схитрить и обойти это правило. Они приходят к команде разработки и говорят каждый на свой лад.
-
Ребят, надо быстро напилить фичу, сделайте ее как-нибудь, презентуем, посмотрим понравится ли клиенту и тогда уже переделаем нормально
-
Лёха, я знаю про то, что у нас нестабильно работает старый код и надо его переделать, но сейчас надо клиенту фичи показать, выбить деньги и тогда уже согласуем переделку неработающего функционала
-
Баги которые сейчас вылезают просто быстрыми фиксами закрой, а переделаем потом
Выше сказанное можно свести к одному простому: сделай быстро как нибудь, потом сделаем нормально.
От таких фраз происходит следующее:
-
Автотесты попадают под нож первыми, их не пишут или пишут для галочки
-
Ручное тестирование тоже проходит в облегченном варианте
-
Техдолг растет
Также хочу подсветить несколько моментов:
-
"Потом" может не наступить
-
Даже когда светлое будущее наступит, на переделку уйдет в 2-3 раза больше времени чем если бы мы сразу все сделали нормально
-
Также стоит учесть все то время которое потрачено на баги из-за корявых решений, на которые мы согласились
Предвещая неверное решение интуитивно, ты, как представитель команды разработки, об этом сообщаешь менеджеру, просишь дать времени сделать все правильно потому-что так выйдет дешевле клиенту, команде не придется страдать отлавливая баги и мы не рискуем парализовать проект или его часть техническим долгом. И каждый раз было так, что менеджеры кивали и делали по своему. На следующем планировании спринта нам приходит реализация новых фичей в быстром варианте, а про техдолг мы просто опять забыли.
Что дальше было?
-
На одну большую фичу пришли пользователи, нагрузки и нам пришлось потратить несколько месяцев на баги и переделку. Техдолг так и не рассосался до конца, это так и осталась страшная фича, в которую зайдет только смелый.
-
Другой проект оказалось практически невозможно развивать спустя несколько месяцев работы и его просто закрыли. Как итог - менеджер сменился.
-
Еще один проект, техдолг которого упорно не замечали, до того момента пока мы несколько спринтов подряд не начали заниматься только багами, то есть фактически он оказался парализован. Когда к тебе по 3-4 раза в день прибегает менеджер с каким-то срочным багом на проде, это просто дорога в могилу. Менеджер, кстати, и здесь сменился на нового.
А что произошло?
Я вот думаю, что были потрачены деньги на то, чтобы нанять и принять в команду новых умных программистов, платить им деньги за работу, тратить время на общение, но в итоге их часто не слушают, когда они говорят о том, что нужно переделать важный функционал. Может стоит нанимать умных людей и слушать их? Или это остатки советского , что нам нужны “ученые” которые будут молча работать? Типа “результат их работы нам нужен, а их мнение - нет.”
У меня есть догадки, в чем была лично моя ошибка. Может я не умею верно доносить мысли до людей, может просто стоило более тщательно выбирать команду и проект для работы. Думаю стоит отдавать внимание чутью и настоять на своём, постараться донести мысль до менеджера и напомнить ещё раз то, с чего мы начали:
“Нормально делай - нормально будет. “
Автор:
didalex
