Но в реальной жизни всё сложнее. Во время разработки появляются новые вводные, задача может потребовать дополнительного изучения да и вообще, всегда найдётся миллион причин, почему всё может пойти не так
Поэтому важно, чтобы команда и, главное, руководство заранее знали, что что-то идёт не по плану. Тогда ещё можно принять решение и что-то изменить, пока не поздно
Если вы понимаете, что не успеваете, не молчите. Напишите об этом как можно раньше. Не стоит дожидаться синка и оправдываться. Почти всегда можно найти решение, как ускорить процесс заранее
Если вы не можете точно оценить задачу, выделите отдельную на исследование, ограничьте её, например, 4 часами. После этого уже можно дать более точную оценку основной задачи
А если задачу всё-таки нужно успеть в срок за счёт качества кода, то сразу после релиза поставьте задачу на рефакторинг
👔 Менеджер всегда прав!
А если не прав — см. пункт выше
Все мы знаем главное правило бизнеса: "Клиент всегда прав". Так вот, пока вы работаете в команде, вашим клиентом является ваш руководитель, будь то тимлид, менеджер или продакт
И прежде чем накидывать дизлайки, скажу: я и сам могу привести миллион примеров, когда менеджер был не прав
Но если вы будете постоянно спорить, оспаривать решения или конфликтовать, вас рано или поздно заменят на того, кто не будет. Вместо конфликта: разберитесь, почему было принято то или иное решение, и обсудите это конструктивно, аккуратно донесите свою точку зрения
Пара примеров из практики:
Однажды разработчик сделал анимацию и отправил видео в командный чат. Анимацию утвердили, и он собрал билд. В билде всё выглядело иначе. Вместо того чтобы проверить сборку, настройки или коммиты, начались споры. То, что можно было решить за 15 минут, вылилось в час обсуждений с участием всей команды. В итоге задача "подорожала" с 15 минут до 4 часов командного времени. И, неудивительно, после этого с разработчиком никто не захотел больше работать
А вот пример от моего друга и активного подписчика канала
(обращение к нему: если решишь закидать меня камнями, то лучше сделай это, пожалуйста, в каком-нибудь выживаче 😅)
Разработчика назначили на проект, где код был в удручающем состоянии. В какой-то момент он пришёл к тимлиду и резко высказался по поводу качества кода. Это задело лида, информация дошла до менеджера и разработчика сняли с проекта
Был ли прав тимлид, допустив такой код? — Нет
Был ли прав разработчик, что пришёл с претензией в такой форме? — Тоже нет
Потому что, как бы это ни звучало: менеджер всегда прав!
Кстати, именно после этого случая я ввёл у себя простое правило:
Любой член команды может придти ко мне и в любой, хоть самой резкой форме, высказать своё мнение о коде или команде
Этот пост получился очень длинным, а изложить удалось лишь малую часть той информации, что я хотел донести. Скажу честно, информации так много, что я даже задумался написать книгу по этой теме. Ну а, если вам было полезно или просто интересно, то поддержите пост реакцией ❤️