Comments 13
UFO landed and left these words here
Еще неплохо бы указать, что в данном конкретном случае виноват не Саша, а вся команда, т.е. Иван. Потому что процесс в команде не построен.

Почему CI не собирает пулреквесты? Почему пулреквест можно смержить без ревью? Почему это обсуждается как косяк?


Еще неплохо бы считать не всю команду виноватой, а только Ивана. И чтоб Иван без всяких личных разговоров с Сашей выступил перед командой, открыто признал свой косяк (Потому что процесс в команде не построен), рассказала бы, какие меры будут приняты, чтоб усовершенствовать процесс разработки. То есть, руководитель, как ему и положено, взял бы всю ответственность за проблемы в команде на себя, и принял бы меры. Показав личным примером, что он готов нести ответственность за проблемы в команде и что цели компании выше его собственных амбиций, Иван мотивировал бы разработчиков брать на себя ответственность за проблемы, стараться на благо компании, стремиться достигнуть общей цели.
Акцент статьи не на разборе конкретного кейса, а на том как конструктивно передать обратную связь своему сотруднику. Иван — руководитель, считаем по умолчанию, что он им стал заслуженно и более компетентен, чем остальная команда.

"Поправь Х" — в личный чат. "Ревью обязательно" — в общий чат. Это конструктивно. А "есть время отойти на 15 минут?", да ещё без озвучивания тематики разговора — это не конструктивно. Мне каждый раз некомфортно, когда мне предлагают приватно поговорить и не говорят заранее о чем. Так себе обратная связь выходит в таком формате.

Хорошо, вот написали вы в личный чат «Поправь Х» и «Ревью обязательно» в общий, но разработчик не выполнил необходимое. Дальше что будете с ним делать?

Напомню ещё раз. Добавим в трекер статус "ревью". Потом спрошу, почему он в очередной раз игнорит правило. Дальше заберу права на коммит в мастер-ветку. Но скорее всего до этого не дойдет, мержит в мастер-ветку не он, а тот, кто мержит — не будет этого делать без галочки "ревью".


Поговорить на каком-то этапе обязательно, но скорее всего это будет не после факапа, а после обычной задачи (которая без ревью и тестов, но работает). Мол, всё круто, но давай соблюдать правила выкладки.


Не утверждаю, что лучший вариант, просто рассказал из опыта, как делал.


Поговорить после факапа тоже нормально, но я бы тему сразу обозначил.

Позволю себе уточнить и расширить.

Если есть необходимость ревью, то нужно да — добавить новый статус в трекер, внести в документацию/список правил пункт про «необходимо ревьювить код», где прописать детали. Ввести за обязательные правила работы в команде.

В дальнейшем, если разработчик нарушает правила, можно сначала «давать обратную связь», а потом наказывать. Наказывать можно только за нарушение прописанных правил. Если разработчик даже после этого игнорирует правила — расставаться.

Это не только для разработчиков справедливо. В любой команде должны быть прописанные и доведенные до ведома всех правила — это нормальный способ управления процессом.
От менеджера вышестоящее руководство обычно требует подешевле и понадёжнее. А эти правила, ревью, парное программирование съедают ресурсы, которых может не быть. Опять же, забери у Саши права на прод, а вечером в пятницу, когда что-то гикнулось, он не сможет помочь, а Вася с правами культурно отдыхает и до него не дозвониться.

Программисту это конечно всё до лампочки — не его проблемы, но для менеджера существенно.
руководство обычно требует

Тимлиду бюджет никто не выделяет, так что насчёт "подешевле" не могу сказать.


понадёжнее

Ревью — это и есть понадежнее. Если вышестоящее руководство само знает, как сделать понадежнее, то без проблем, могу просто выполнять инструкции. Но резюме на всякий случай обновлю.


Права на прод есть у меня. А давать их тому, кто систематически ломает прод — это ни к какому "по-надёжнее" отношения иметь не будет. Но как я сказал выше, до этого не доходило.

Ревью — это и есть понадежнее
Да, и дороже.
Но резюме на всякий случай обновлю.
В этом и разница. Программист, если ему втирают противоречивые требования, может и резюме обновить. А менеджеры выше должны крутиться в политике, как ужи на сковороде. Главный босс требует новую фичу, а заказчики по сданным модулям требуют доработок «по мелочи», никому нельзя отказать. Программист справедливо скажет «ну вы определитесь-то, что делать прямо сейчас», и у него больше нет проблем.

Ну так у него есть проблема — как сделать эту фичу. Если менеджер считает, что его проблема (выбрать, что приоритетнее) сложнее, он может поменяться )


Это я к тому, что незачем меряться, у кого проблемы проблемистее. "Расставить приоритеты" — это часть работы менеджера. Он именно за это деньги получает и именно это должен уметь.


К тому же ревью, это был изначальный кейс из статьи. Если нет задачи внедрить ревью, то можно не внедрять. Если менеджер знает, как добиться качества без ревью и тестов — без проблем. Если на хабре будет статья, с рассказом, как — с интересом почитаю.

Цели могут меняться. То качественно надо, то быстрее, и всё по одному проекту. Потому и права надо приходится давать даже тем, кто ломает, если это увеличивает шансы быстро починить.
В начале беседы скажите несколько слов о хороших качествах собеседника или о его работе, которую он выполнил недавно.

… похвастайтесь своими новыми фото в инстаграме, расскажите анекдот, покажите фокус.
Руководитель, толкущий воду в ступе — никудышный руководитель.


Поэтому Ивану следует обратить внимание на свою интонацию, мимику, жесты.

Что-то я запутался.
Иван это вчерашний студент, гладящий шнурки перед первым в его жизни интервью или всё же целый начальник?


Саша может сам предложить пути решения данной проблемы и это будет лучший вариант,
т.к. он сразу берет на себя ответственность за произошедшую ситуацию и ее устранение.

— Алло, дорогой! У нас прорвало канализацию, что делать, я в панике!
— Не волнуйся, дорогогая! Сейчас заеду за сантехником и всё починим!
— Так и знала, козлина, что это всё из-за тебя!


Иван должен обязательно сообщить, что верит в Сашу

А, так это деда мороза Сашей зовут?
А Ванечка, стало быть, мальчик, ждущий подарков под ёлкой?

Only those users with full accounts are able to leave comments. Log in, please.