Давайте поговорим почему одна и та же задача может занимать сильно разное количество времени.
Тут в общем то давно все известно. Помимо «просто девелопер медленный, не справляется» есть ещё куча других разных причин, особенно если не справляется он местами временами, а не все время. Например:
- неавтоматизированные процессы
- плохая инфраструктура
- неправильные приоритеты ( вина обоих и девелопера и его менеджмента)
- плохая архитектура ( это если у него не было выбора)
Про legacy applications там ещё несколько пунктов можно добавить.
В одной команде ( даже в двух) у меня был золотой менеджмент в этом смысле. Они не просто оглашали, обсуждали все эти моменты, но и воплощали решения в жизнь.
Примеры того что было сделано:
- сократили время билда ( сложный был продукт) в разы. Прошлись по build log, убрали все inefficiencies. Убедились что у каждого девелопера unified и максимально заточенная под performance local dev environment ( tools, formatting etc)
- отточили процесс планирования спринта, выполнения задач и проч. Время митингов сократилось до минимального, tracking в Джире был близок к идеальному, там можно было все отследить и были видны реальные dependencies и статус без тормошения и отвлечения миллиона людей.
- убрали все задержки связанные с ожиданиями on shared test environments
- code reviews по большим проектам начинали с митинга со всеми заинтересованными лицами, где автор расказывал вкратце что и как. Потом людям давали время до конца дня дать фидбек и не ждали что они в этот день будут делать столько же основной работы как обычно.
Это всего несколько моментов что пришло мне в голову. Все это исходило от менеджера/архитектор, а не было инициативой правильного staff инженера на местах.
У вас был похожий опыт ? Вы согласны что от начальства тоже немало зависит ?
Меня немного напрягают все эти ФААНГовские представления о супер Staff Engineer , который «придёт и боль руками разведёт», по двум причинам:
- это нереально, без правильного начальства не получится
- создаётся культ либо волка одиночки, который все делает сам, либо staff инженера который постоянно указывает другим что делать. Это ни какая ни team work ни разу .
В этом месте тоже интересно мнение других. Возможно я просто сужу по тому в чем варюсь последние 3.5 года и там просто полный писец по всем описанным выше пунктам эффективности работы инженера. С приходом Ковида все ещё немного усложнилось, потому что sometimes it takes a village сделать какую то весьма простую задачу. Обычно это результат того что процессы автоматизации и управления инфраструктурой отдали девопсам, а у них свой начальник , планы и при этом сама инфраструктура обычно оставляет желать лучшего.
Что самое смешное в production эти девопсы ничего не деплоют ( пусть девелопер корячиться и за все отвечает) , но протестировать что то без них невозможно если в environment глюк, а это считай каждый первый случай
. Вот и сидят девелоперы в их слаке и покорно ждут когда ихний oncall соизволит починить. То есть в реалии никто не ждёт конечно - или начинает multitask, что не очень хорошо . Или сам лезет разводить самодеятельность, что тоже не всегда хорошо, точнее предмет вечных тёрок с этой командой. Миллион repetitive tasks, постоянный конфликт с тем что делают они ( их приоритетами) , etc etc.Если у вас все как я описала вверху про свою предилущую команду , пожалуйста ( я умоляю
), расскажите что за компания/команда. Можно в личку. Как я теперь поняла они нынче на вес золота и пришла пора составлять отдельный список
И главное нафига. Нафига Владу слушать 10 минут что у Анны SSRS server глючит и девопсы ее уже неделю к network guys отфутболивают.