🫣 Тёмная сторона делегирования
Бывает, зашел в MR на код-ревью и становится понятно, что проще будет вообще не мержить, чем потом поддерживать это говно. Хорошо хоть, если проблемы всплывают в этот момент, а не когда видишь неожиданно красочные баги на проде 🤯
И как вообще доверять команде, если результат не совпадает с ожиданиями? Постоянно контролировать и нервничать, что всё идёт не так? А если ты лид перфекционист, то вообще пиздец. Может доходить до того, что появляется желание забрать задачу и переделать всё самому, а не пытаться объяснить что нужно переписать.
О тёмной стороне делегирования я задумался, когда читал настольную книгу тимлида. Невозможно увеличивать свою продуктивность через большую автономность команды, если появляется желание микроменеджить. Пусть набивают шишки. Пусть растут самостоятельно.
В будущем, когда вы столкнетесь с багами как пользователь какого-то продукта, вспомните: это не разработчики рукожопые мудаки. Это их мудрый лид даёт им качать скиллы. 👹
· 20.02.2025
Лид может придумать сценарии тестов, чтобы QA реализовали их, глядишь до прода баги не дойдут и микроменеджить не придется. )
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 20.02.2025
Не везде есть QA, к сожалению)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 20.02.2025
Тогда тесты напишут разработчики. )
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 20.02.2025
Ага, но покроют не все тесты, потому что смотрят на задачу не как на черную коробку 😂
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 20.02.2025
Ну вот для этого им и надо подсказать сценарии. :) Как вариант, вначале ставить задачу на проработку требований и описание тест сценариев и только потом ставить задачу на разработку.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён