×

В ночь с пятницы на воскресенье, или Затертые изменения

[Об авторе: Владимир Железняк — 17 лет в отрасли, много всякого повидал, был многократно уволен, взлетал и падал.]

Тема вызвала большое бурление в фейсбуке, так что считаю нужным разобрать более детально. У этой истории есть важное свойство — каждый моментально формирует свой единственно-правильный ответ. Плохо, что эти ответы не совпадают :) :

Один синьор любил работать в тишине и часто задерживался на работе. Как-то в пятницу вечером он глубоко погрузился в код, разогнался и, абсолютно незаметно для себя, отрефакторил полпроекта. Покрыл тестами, закоммитился, запушился и ушел домой спать. Я вообще не знаю, выходил ли он из офиса в ночь с пт на вс.
Второй синьор пришел в понедельник с утра пораньше и обнаружил, что мердж его почти готовой и долгожданной фичи теперь из-за рефакторинга из банальной задачи превратился в огромного монстра. Ситуацию усугубило очередное письмо «сколько можно ждать! давай немедленно!» от заказчика. Второй взял и, никого не дожидаясь, решил проблему — откатил коммиты Первого и влил свои.
В середине дня на работу пришел Первый. Увидел. Осознал. Пришел в ярость. Пошел бить морду.

История

Ниже будут комменты читателей, и здесь однозначно виноват:

Менеджер:

  • Не прав менеджер в данной ситуации. Это фейл исключительно менеджера.
  • На 90% проблема менеджера.
  • Факт, что пипл от скуки начинает рефакторить в пятницу вечером, говорит о плохом манажэменте.
  • Виноват начальник.
  • Всю вину несет начальник.
  • ПМ-у двойка.

Первый:

  • Синьор-помидор сделал инициативу, никого не предупредив, не получив разрешения, вышел за рамки своих заданий и начал рефакторинг области пересечения, то он на 100% виноват. Тут даже не о чём говорить.
  • Тот, кто перелопатил, сделал это через зад.
  • Первый террорист какой-то. Такие вещи планируют за полгода вперед, несколько раз отодвигая от послерелиза до послерелиза.
  • Виноват первый синьор.
  • Че первый синьор без ревью рефакторинг пушил?
  • Первый программист — не командный игрок.

Второй:

  • Второму гит сказал — мердж затрёт чьи-то изменения — и он сознательно сказал ок — затирай, лишь бы свою фичу выставить, и никто бы недо...вал.
  • Второй явно уже тайно думал, что первый мудак раз вместо бранча свой маневр с откатом запушил в основную ветку и никому ничего не сказал.
  • Хто перший закомітався, того і тапки. Другий мав замерждитись.
  • Если так уже случилось, и второй сеньор получил лично такое письмо, то логичнее было бы подождать менеджера и спокойно обсудить ситуацию.

Неправильный процесс:

  • И все бы было хорошо, если бы они знали git не на уровне push/pull.
  • В компании должен быть налажен процесс рефакторинга. Если кто-то хочет сделать рефакторинг, то он за N дней уведомляет сотрудников таких-то ролей, получает от такой-то роли подтверждение и потом делает.
  • Проблема не в людях, а в структуре. И я бы со структурой разбирался.
  • Нефиг в психологию лезть, с процессами разбирайтесь.
  • Процесс херовый.
  • Над этими двумя должен быть один старший программист, который дает ответ, что делать в таких ситуациях.
  • На Западе корпорации имеют четкую полувоенную структуру со всеми вьітекающими.
  • Купить первому девелоперу хорошие изолирующие наушники, чтобы он работал в одно время с остальной командой, а не партизанил ночью.

Все вместе:

  • Все трое отличились.
  • Тут много прекрасного: и залитый в основной бранч «ре-фак-торинг» (третий слог должен быть английскими буквами), и подход «выкатим фичу, потому что заказчик просит», и еще пара вещей по мелочи.
  • Все трое живут в вьідуманном маня-мирке.
  • Виноваты первый программист и менеджер в пропорции 60 на 40.
  • Усіх розстріляти :).
  • Со стороны «первого синьора» это была демонстрация тотального неуважения к своим коллегам, независимо от того, какой объём работы он там покрыл. С другой стороны, «второй синьор» тоже включил д’Артаньяна и без попыток связаться с коллегой, под звук сливного бачка, спустил его наработки в сточную канаву. Вообще, если такая ситуация произошла, то имеет место элементарное неуважение в коллективе, значит виноват менеджер.

Нужно больше контекста и вообще:

  • Не надо забывать, что мы видим ситуацию со стороны одного из участников (у двух других будут свои истории и своя правда).
  • Ситуация выдуманная.
  • Ситуация вполне реальная и знакомая.
  • Это просто какая-то феерия глупости.
  • Во-первых, почему рефакторинг пушится в основную ветвь? Во-вторых, почему отрефакторенный код не прошел ревью?

Что меня удивило

  • Умение быстро находить виновного. Только несколько человек задали вопросы, ведущие к уточнению ситуации «а на какой стадии проект-то?», «какие практики были оговорены?», «кто вообще за что отвечает?».
  • Большинство сфокусировалось на поиске виноватого, и только несколько человек, включая Ignat Alexeyenko, Dmitriy Rossokhovatskiy, Dmytro Lepeshkov, Artem Serdyuk, больше говорили о решении. Т.е. был фокус на «кто виноват», а не на «как предотвратить в будущем».

Что можно было сделать?

Разбирать будем по таймлайну, в том порядке, в котором события происходили. Дальше текст будет очень похож на программу. Или на скрипт для автоматизированного тестирования.

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

Это соответствует здравому смыслу. Но не во всем он есть, и не везде он нужен.

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

1. Пятница вечер, все ещё на работе. Первый еще не разогнался

Первый

Что может сделать Первый? Если он планирует что-то мощно рефакторить, то хорошо бы об этом сказать. Сказать-то хорошо бы было, но:

  • Первый может вообще не планировал рефакторить, тем более мощно. Он просто писал код для своей фичи. Если кто-то всегда наперед знает, к чему приведет написание его кода — то это новое слово в оценке сроков.
  • Первый чувствует себя самым крутым на проекте. Это может быть более оправдано в ситуации «я на проекте уже год, и я сеньор, а второй — миддл и всего пару недель тут, а менеджер — вообще без технического опыта». Оправдание слабое, и часто является обратной стороной от «я знаю здесь всё, я отвечаю за этот проект, и мне лучше писать код, а не тратить время на говорильню».

Первый мог вынести свою фичу в отдельную ветку с самого начала. Давайте посмотрим, в каких случаях это сомнительно. Именно сомнительно, но занятый кодом человек может не подумать в эту сторону:

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

Примечание: очень хочется сказать, что накосячил именно Первый и именно тут. Все могут ошибаться, главное — что произойдет дальше.

Второй

Второй мог сказать «я тут заканчиваю фичу, планирую в пн отдать». Может, даже сказал, но это не помогло:

  • например, Второй мог сказать это только Менеджеру, а Первый не слышал;
  • Второй мог сказать это Первому между делом, например, на стендапе, а Первый мог пропустить мимо ушей. Тем более, что на этом этапе никто из них не ожидал конфликта кода;
  • Первый мог придерживаться принципа «кто первый встал — того и тапки. Я изменения внес, тесты прошли — дальше не моя проблема». Сомнительный принцип, но я такое видел от мегаэкспертов. У людей, которые на голову превосходят окружающих в технической квалификации, такое бывает.

PM

PM может спросить у засидевшегося Первого перед уходом «а что ты сейчас делаешь и какие планы?»

  • если Первый уже понимает, к чему дело идет, то он может сказать «я собираюсь мощно отрефакторить». Ситуация завершается банальным «ну ок, только в главную ветку не вмердживай — у нас там выкатка важной фичи в пн. Как будем мерджить — в пн и обсудим»;
  • если Первый еще не понимает, во что это выльется — то вопрос ничего не меняет.

Вообще, довольно необычный вопрос для пятницы вечера. Наверное, встречается в реальной жизни у нас не чаще, чем принцип «менеджер уходит с работы последним и приходит первым».

2. Пятница вечер, все ещё на работе. Первый уже погрузился в код

Этого пункта могло и вообще не быть. По моему опыту, любители посидеть допоздна разгоняются только тогда, когда никого не остается в радиусе пяти метров. Оно понятно, меньше шансов, что прервут.

Первый

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

Второй / PM

Мог заметить, что Первый что-то быстро пишет, и спросить «а что это ты тут делаешь?»

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

Мне кажется, что вопрос «а что это ты делаешь?» в состоянии потока могут простить либо большому начальнику, либо большому авторитету. Все остальные — просто получат по ушам.

Кроме того, если не было предварительной договоренности, то на выходных обычно ничего не происходит, так что вопрос звучит глупо.

3. Ночь с пятницы на воскресенье, на работе только Первый

Вот так сядешь попрограммировать на 15 минут в 10 вечера, а потом обнаруживаешь себя в час ночи, чинящим ошибки на продакшене... © Yuriy Silvestrov

Первый

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

В таком состоянии от человека нельзя ожидать каких-либо осознанных действий за пределами узкой задачи. Высокая концентрация внимания на одной задаче не оставляет внимания для чего-либо еще.

Второй / PM

Можно опять-таки позвонить Первому или хотя бы проверить логи сервера. Глупо звучит, правда?

4. Воскресенье, Первый уползает с работы

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

  • написать в общий чат «я всё переделал и пошел спать». Я думаю, что на эмоции и действия Второго это никак не повлияет;
  • таки выпилить изменения в отдельную ветку. Несколько команд гита — и всё работает. Да, это правильное решение, кроме:
    • может тупо не быть сил или времени. Кто всегда все дела доводит до конца — отпишитесь в комментах; :)
    • человек искренне считает, что его изменения однозначно полезны, и пусть ими все начнут пользоваться как можно раньше. Тем более, что в понедельник с утра он будет на работе и всем всё расскажет.

5. Понедельник, на работу приходит Второй

Первый спит, PM еще не пришел, Второй видит большие изменения, которые нафиг порушили его работу. Ну и письмо от заказчика «срочно нужно» тоже видит. Можно предположить, какой вихрь мыслей пролетает у него в голове: «тут теперь дофига работы», «мог бы и сказать», «что я теперь делать буду», «вот козёл», «я же обещал заказчику!», «понедельник — день тяжелый». И всё завершается мыслью «я должен зарелизиться сейчас! Эмоции и разборки — потом».

Как зарелизиться побыстрее? Выкатить чужие непроверенные изменения на прод под свою ответственность? Нет! Нужно вернуть в состояние «как было».

Что мог сделать Второй именно на этом этапе:

  • Зарелизиться. В конце концов, в git бэкап есть и откатить не сложно. Говорят, где-то в заповедниках еще встречаются команды без version control, но даже они имеют практики архивации кода на грампластинки.
  • Подождать прихода менеджера. В конце концов, сроки больше в его зоне ответственности, он определяет приоритеты — пусть он и разбирается. Это вполне нормальное решение в командах с жесткой иерархией и совершенно дикое для команд, где есть инициатива. И если это ожидание привело бы к срыву деплоя — прилетело бы всем. Просить о повышении зарплаты и об отпуске в обозримом будущем станет куда сложнее.
  • Позвонить менеджеру и переложить решение на него. Менеджер оказывается в ситуации Первого, только он еще и не может заочно оценить масштаб переписанного. Что может сделать Менеджер:
    • сказать «откатывай и релизься». Это выведет Второго из последующего конфликта и упростит дальнейшие разборки;
    • сказать «подожди меня и Первого». Это приводит к конфликту с Заказчиком, что тоже может быть вполне ок — от ситуации зависит.

6. Понедельник, на работу приходит ПМ

Второй

  • можно сказать Менеджеру;
  • можно не сказать и продолжить кодить, ибо некогда языком молоть, релиз важнее. Спорно, конечно.

PM

Уже рассмотрели в предыдущем разделе, только разбираться в масштабе разрушений проще. Конечно, если PM технически грамотный и хорошо понимает написанное.

7. Понедельник, на работу приходит Первый

Первый

Прежде чем перейти к возможным действиям, давайте посмотрим на состояние Первого:

  • отдохнул ли он на выходных? Нет, он выложился по полной. Усталый человек действует на автопилоте и более нервно, чем обычно;
  • он может чувствовать гордость за «я без просьбы менеджера овертаймил» и за «я классно переписал застарелый говнокод». За это обычно хвалят;
  • он может чувствовать страх — ведь изменения не были согласованы, это нарушение дисциплины и командной работы. Да и если он видит хоть какие-то недостатки в написанном коде, то и другие тоже могут увидеть. А профессионал очень редко скажет на свой код, что он идеален — всегда видно, как сделать лучше;
  • он может тревожиться — ведь меня будут оценивать, а после этого либо похвалят, либо обругают. Люди часто боятся внешней оценки, это нормально для нас;
  • он может чувствовать вину — ведь на работу пришел позже обычного. Конечно, планировал прийти пораньше или хотя бы со всеми, но... После таких выходных на работу вовремя обычно не приходят, хотя и стараются;
  • он может чувствовать отвращение — ведь после очень напряженных выходных впрягаться в понедельник с утра ой как не хочется. Это организм намекает, что либо отдых сейчас, либо хроническая болячка годам к 35-40;
  • если есть хоть чуть-чуть страха, вины и тревоги, то обязаны включиться механизмы самозащиты, и в голове будут крутиться фразы «я молодец, я это таки сделал», «я всё сделал правильно», «да кто они такие, чтобы меня оценивать», «сейчас я им всё объясню», «если они не оценят моих достижений — свалю нафиг, давно пора». Если самоуспокоения не хватило — то включится гнев.

Итак, Первый пришел на работу и видит, что в главной ветке его изменения откатили. Что он может сделать:

  • воспринять это спокойно. Ага, его кто-то оценил и оценил плохо. И это новость для уже накрученного человека. Мало кто способен в такой ситуации воспринять это спокойно;
    • Важное примечание: негативно оценили здесь не Первого, и не его навыки, а его действия. Но воспринимается это именно как атака на личность. Накрученному человеку сложно различить «ты плохой», «ты плохой специалист» и «ты плохо поступил в этот раз». Эти три совершенно разные ситуации обычно сливаются в самое жесткое «ты плохой».
    • Есть методики быстрого самоуспокоения, но ими сложно начать пользоваться. Повторять «я спокоен» помогает отнюдь не всем. Мультик в тему.
  • молча обидеться и вместо работы полезть по развлекательным и работодательным сайтам. Это нормальная человеческая реакция, если обидчик воспринимается сильнее;
  • пойти чинить разборки. Обычно люди так поступают, если обидчик выглядит сравнимым по силе. Не физической, конечно.

Второй

В каком эмоциональном состоянии Второй?

  • он может быть глубоко сконцентрирован на деплое. Состояние потока, обработка окружающего мира идет с низким приоритетом;
  • он может гордиться — он принял решение и таки успеет сделать деплой;
  • он может злорадствовать — это если Первый ему чем-то насолил раньше, а теперь подвернулась возможность восстановить справедливость;
    • Злорадство — положительная эмоция, пусть и социально-неодобряемая. Т.е. ты радуешься и чувствуешь свою вину за это. Если есть вина — то идет и самооправдание.
    • Понятая по-разному справедливость, месть, злорадство — в жизни айтишников таки встречаются. Такие случаи как бомжи — о них не принято помнить и о них не принято говорить, а они есть.
  • он может переживать — насколько правильным было его решение;
  • он может нервничать — проактивность очень любят в переводных статьях, а со школы вбивают «я начальник — ты дурак»;
  • он может чувствовать вину — если релиз в понедельник, и релиз срывается, то на «всё ли я сделал для релиза?» ответ «нет, можно было на выходных выйти»;
  • если есть хоть чуть-чуть страха, вины и тревоги, то включаться механизмы самозащиты «я всё сделал правильно», «они уроды», «уволюсь», «пусть только попробуют мне что-то предъявить», «плохой заказчик, дурной проект, идиот менеджер, самоубийца-коллега».

Что Второй может сделать?

  • Если уже спешить для деплоя не надо — можно поднять тему самому. При правильных словах конфликт бы решился за пять минут. Сравните две фразы, по сути — одно и то же сказано, а восприятие меняется.
    • «ты перехреначил проект, из-за твоих шаловливых ручек мы не могли зарелизиться. Я откатил все кривые правки, сегодня после обеда расскажешь, что ты хотел сделать — может, таки и пустим в общую ветку»;
    • «сегодня я начал мерджить правки для релиза и это оказалось сложно из-за изменений в основной ветке. По требованию заказчика, сегодня фича должна выйти на сервер, так что временно я откатил эти изменения. Ближе к вечеру давай обсудим, ок?»
  • Если спешить еще нужно — то действия остаются прежними: писать код, и пофиг на эмоции Первого.

PM

В каком состоянии менеджер? А мы не знаем. Может, он на выходных встретил девушку своей мечты и прообщался с ней полдня. А может, тёща помыла новый MacBook Pro c Доместосом, а потом объяснила, что за своими вещами нужно уметь следить самому. А может, у него произошли оба этих события одно за другим, и в голове у него некоторая каша.

Что может сделать менеджер?

  • самоустраниться «вы взрослые люди, разберитесь сами» или «обсудим на ретро». Если это рациональная оценка, что эти двое справятся сами к выгоде проекта, тогда ок. Если они не справятся — запросто уволятся оба;
  • сказать «успокойся». Обычно это самый простой способ сорвать чужую крышу. А если сказать «успокойся, ты не прав, сейчас я тебе поясню, как правильно» — то можно даже в челюстно-лицевом отделении побывать;
  • заняться вопросом именно кода;
    • с технической стороны здесь нечего обсуждать. git рулит;
    • с организационной — и Первый и Второй заняты самонакручиванием. Даже если они не уволятся сейчас, они сделают большой шаг к увольнению — это будет ниже КПД и на них меньше можно будет положиться.
  • фасилитировать разговор и помочь коллегам научиться самостоятельно такое разруливать. Наверное, идеальное решение, если есть время, авторитет и нужные навыки;
  • что таки нужно сделать:
    • вслух подчеркнуть заслуги: Первый работал на выходных и сделал нужное дело. Второй — таки запустил релиз;
    • признать их право на эмоции. Тут очень много чего есть сказать, только много букв будет;
    • концентрироваться не на поиске «кто виноват», а на «что делать прямо сейчас?»

Процесс

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

Никакие две поломки не должны вести к срыву миссии. Никакие три поломки не должны вести к гибели экипажа. © из космонавтики

А вот тут уже задача менеджера. Что можно сделать:

  • запретить работать на выходных. Это сделает мотивацию предсказуемой. Ужасно предсказуемой;
  • ввести жесткую систему отчетности с автоматическим отслеживанием возможных конфликтов. Пусть сдохнут от бюрократии;
  • таки использовать GitFlow с самого начала. В отличие от предыдущих двух идей — эта стоящая. Впрочем, у этих же людей мог возникнуть конфликт, например, про «у меня мышка на выходных сломалась, я взял твою», «я взял твой монитор», «нам на проекте давно было пора ввести единый стандарт кода, поэтому я везде заменил пробелы на табы и выровнял switch»;
  • уметь работать с чужими эмоциями.

Мысли вместо вывода

  1. Искать виноватого проще, чем предотвращать ситуацию в будущем.
  2. Несколько мелких ошибок легко суммируются до серьезного конфликта. Ну действительно, можно ли всерьез обвинять человека, который решил сам добровольно поовертаймить? А человека, который решил выполнить обещанный деплой? А менеджера, который на выходных не долбал сотрудников вопросами?
  3. Мог ли каждый из участников вытянуть ситуацию? Мог. Более того, каждый день вытягивают. Только когда вытянули — это не заметно, а когда все провалили — вот тут уже ой.
  4. Получился длинный разбор короткой истории. Можно и еще длиннее сделать. А можно взять вот эту выжимку — там из каждого абзаца можно такую статью написать :)

PS: Планирую статью по сложным ситуациям в жизни айтишника.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




58 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Вполне допускаю, что проблема реалистичная, но для меня лично звучит как ситуация из прошлого столетия. И удивляет наличия PM в этой дискуссии (может это конечно такой специальный трюк автора чтобы привлечь к обсуждению широкие слои)
Pull request решают такие конфликты легко help.github.com/…​cles/about-pull-requests
У нас если комманда 2+ человека то необходимо получить 2👍 чтобы изменения зашли в мастер. Если над проектом работает пара то достаточно 👍 от коллеги в данном случае второго синьера. И не нужно городить все эти сложные коммуникации.

вы уже нашли, как гарантировать вдумчивый анализ вместо рефлекторного клика по «Aproove»?

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

то есть, в первую очередь — тщательный отбор персонала, основанный на общих ценностях. Верно?
А то у меня претензия не к пулл-реквестам как механизму(тоже используем), а только к категоричности заявления, будто механизм или процесс легко исправить корявую коммуникацию.

Абсолютно верно

тщательный отбор персонала, основанный на общих ценностях
Касательно категоричности заявления скажу, что описанная ситуация и решения вызвали некое удивление :)

Не «гарантировать» но «помочь» и «дать базу для» а именно хорошая гранулированность изменений как один из принципов процесса никаких «сверх-мега-супер-кода-дроп за последние 2 недели моей работы!» (к) (тм)

ЗЫ: опять таки палки об разных концах но минимальные тесты также помогают.

ЗЫ: опять таки палки об разных концах и вдумчивый отстрел самых умных которых делают не анализ конкретного изменения а анализ собственных мыслей по поводу кода вообще также крайне полезен и настоятельно рекомендуем.

Какие то детские проблемы. Достаточно сделать нормальный воркфлоу для гитары.

У меня практический вопрос: после этой истории что конкретно было сделано, чтобы такие коллизии больше не повторялись? Через месяц после случившегося можно было быть уверенным хотя бы на 95%, что подобное снова не произойдет ни с теми же самыми персонажами, ни с другими?

Обсудили втроем, и таки перешли на более нормальную работу с гитом. Нет, не гитфлоу, его в 2008 еще не было в нынешнем виде, но на что-то подобное.
На таких примерах хорошо учиться и таки строить процесс.

Ніасіліл, бо філософія.

А если серьёзно, то есть огромный пласт работы, которую нужно делать когда никто не зайопывает и ни одна сволочь ГАРАНТИРОВАННО не потребует отчитаться ни о чём. Объясняю почему: чтобы этот пласт вообще мог начать сдвигаться с места, нужно в голове держать всё дело таким, каким оно будет уже сделано. И поскольку память у людей ассоциативна, всё это — синглтоны. Хватить «просто спросить» что угодно от по предыдущей версии — и система памяти уже откатывается по цепочке. Мало того, чем более неожиданное это «спросить», и чем более оно срочно — тем более чётко запоминается (приоретизируется) путь отката. Аж до тех пор, пока этот путь не окажется в горячем резерве и будет срабатывать автоматом уже безх стимула с целью поддерживать актуальным ответ.

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

Мозг невозможно перекроить, просто потому что так удобнее для учёта. Он биологически так устроен: шаблоны и ассоциативная память. Там нет места резервным копиям, версиям, метрикам и ускорителям показухи. Если вам это нужно — наймите отдельного человека, который вам будет это имитировать (не прикасаясь к реальному процессу).
___________
Я не говорю, что работа в команде не нужна или общение не нужно. Но оно нужно процентов 20 от работы, и служит как раз таки для разрушения лишних шаблонов памяти, так сказать Garbage collector. Однако точность этого биологического механизма оставляет желать лучшего — незаконченная работа в памяти — это приоритет № 1 для УНИЧТОЖЕНИЯ, и после его прохода приходится немало времени тратить на восстановление. Почему так: в дикой природе (откуда нервная система родом) шаблоны выживания должны быть исключительно быстрыми и короткими, стимул — действие. И только шаблоны исследования сложные — однако они призваны быть максимально настроены на стимулы отсева, ибо цена за пропуск этих стимулов — жизнь.

Что происходит в реальной корпоративной среде: тупой менеджер воспользовался стимулом — ага, подействовало! Нажал снова — ага, снова подействовало! А что при этом «эффективность» достигнута разурушением оплачиваемой нагрузки — а зачем знать, если есть кнут и пряник? Если же они не действуют (вернее, когда результат прошлых действий попал в отчёты с артиклем «жопа») — это называют «выгоранием».

Так вот, в абсолютном большинстве случаев это «выгорание» — виртальное. Это правильная работа мозга. И самые лучшие работники — это те самые «выгоревшие», если вам они нужны — просто заберите их из говняного проекта, и посмотрите на их реальную эффективность.
Людей с реальным выгоранием (не зависящим от логики) я встречал только у людей следующих категорий:
— шизофреники;
— применявшие медикаментозные препараты для нервной системы с побочными, притом годами;
— алкоголики;
— наркоманы;
— маразматики (при нормальном образе жизни это наступает в 85+ лет)

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

PS. Стрессоустойчивых тоже не существует. Наиболее стрессоустойчивым является тупое, наглое, орущее быдло. Но даже они подвержены стрессу, как только вы воспользуетесь правильными стимулами.

Если совсем кратко: Что безвредно — то и бесполезно. Любой работающий механизм можно применить как в пользу, так и во вред. Методом научного тыка — будет вред, причём каждый тык.

Честно говоря, на первый взгляд, ситуация из серии «выгнать всех нафик». И тут я понимаю народ, который стал активно искать виноватых.
С другой стороны всякое бывает и, видя больше деталей, понимаешь, что все не так просто. Ссылочка в тему www.ted.com/..._be_suspicious_of_stories
1. Менеджер — не совсем менеджер и, скорее всего, не воспринимался командой таковым
2. Заказчик общается с каждым разработчиком напрямую
3. Какие отношение между двумя разработчиками были до инцидента — не известно

Тут все активно советуют GitFlow, с чем я категорически согласен, но это не решение корневой проблемы.
Гораздо важнее «атмосфера в команде». То есть, во-первых, все члены команды должны уважать друг друга. Каждый должен иметь возможность без проблем подойти/позвонить другому члену команды, обсудить волнующий его вопрос и прочее. Тоже самое касается взаимодействия член команды — менеджер.
Во-вторых, каждый член команды должен знать, что делает другой член команды. Для этого, собственно, и нужны ежедневные стендапы. Чтобы у Васи в мозгу могло пронестись «Йолки, Пете в понедельник фичу выкатывать, а не усложню ли я ему жизнь? Надо обсудить с Петей и менеджером приоритеты».

Ага. Именно.

видя больше деталей, понимаешь, что все не так просто
тогда я еще добавлю год. Это было незадолго до кризиса, так что примерно начало 2008. Git Flow тогда был эээээ несколько неразвит.

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

ну то есть знать «как сделать по уму чтоб никто не ушёл обиженым» — это тоже полезно, но всё равно не гарантирует 100% защиту от факапа. если брать за точку отсчёта понедельник, когда уже «аааааа! релиз, ничего не работает, мы все умрём», и вопрос «что делать?» — я бы однозначно ревертил то, что не работает или мешает выкатить релиз.

много букав для элементарной ситуации.
это всё напоминает i3.ytimg.com/...RpwGu8yNTNI/hqdefault.jpg

У нас вроде бы нашли баланс с помощью «бюрократии»:

1) Все изменения происходят через codereview board, нужно одобрение 2+ людей для коммита. Оформление codereview происходит по сложным правилам для расследования возможных факапов.
2) Т.к. пост на codereview борде геморройный, то хочется внести по-больше изменений сразу, чтобы уменьшить количество геморроя.
3) Т.к. люди занятые, то большое количество изменений никто смотреть и вникать не будет, пост не наберёт больше двух ship it’ов и никогда не будет закоммичен.
4) Предыдущий пункт заставляет делать атомарные изменения, которые не являются фундаментальной переделкой всего и вся (рефакторингом). Одно изменение за раз.
5) Маленькие и логически законченые изменения в общий код позволяют другим людям внести изменения в свой код, обычно пару правок, что не является большой потерей времени. Плюс они видели код на ревью борде и могли откомментировать, если что не так.
6) Страх перед сизифовым трудом заставляет не держать свой код долго незакоммиченным, и наоборот ускоряет отправку его на codereview с учётом всех ньюансов перечисленных в предыдущих пунктах.
7) Обычно работа ведётся в dev branch, и периодически после тестирования переносится на продакшен в виде большой длинной серии патчей и одним большим коммитом ответственным лицом.

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

Хорошая схема. И конфликт действительно не возник бы из-за изменений — мог быть какой-то другой повод. Нельзя предотвратить все конфликты, можно научиться работать с ними.

Это одна из стандартных реализаций флоу. Но у нее тоже есть нюансы.
Например, иногда нужно что-то сделать «вот прямо сейчас». И когда такое происходит несколько раз — назначается ответственный разработчик, у которого есть права на merge в dev без апрувов.
Это может быть тимлид, один из самых ответственных синьйор девов, СТО, etc.

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

Например, иногда нужно что-то сделать «вот прямо сейчас».
Со сделать здесь и сейчас все просящие идут лесом. Я вот тоже думал, что так нельзя, но оказывается можно и даже нужно.
И когда такое происходит несколько раз — назначается ответственный разработчик, у которого есть права на merge в dev без апрувов.
У нас нельзя закоммитить код, без кодеревью, джиры и code inspection. Физически нельзя. Всё проверяется в автоматическом режиме. Бекдоров нет. Также у нас есть такое понятие как desktop build — все ELF бинарники помечены «красной краской», в общем если надо ну очень срочно, то либо кастомер довольствуется десктоп билдом (собранным из рабочей копии репозитория), либо ждёт официального билда, либо официального билда после тестирования. По времени это 1) здесь и сейчас, 2) в течении пары дней, 3) в течении пары недель. Я был удивлён, но большинство заказчиков готовы ждать пункта 3), даже если надо здесь и сейчас.
Это может быть тимлид, один из самых ответственных синьйор девов, СТО, etc.
Если хоть кто-то из них так сделает, то его ждут неприятности. Процесс превыше всего, ибо компания несёт финансовую ответственность за каждый переданный заказчику бинарник. Разработчики вообще не имеют права давать заказчику ничего кроме десктопного билда. Т.е. для того чтобы так сделать нужен сговор большого количества людей. В любом случае автоматический аудит вскроет такое на следующий день. Уже было пару случаев, но скорее по халатности, были указаны неверные кодеревью при коммите или код в кодеревью несовпал с кодом в репозитории, или джира указана неверно (чаще всего).

Любой другой подход с трудом можно назвать «организацией» и тем более «работой».
В покойном майндспиде был практически такой же подход, правда, осложнялся тем что регулярно приходил какой нибудь, прости, господи, Хуавей и говорил «у нас тем есть ваш MR17 и ничего в нем не меняйте, только добавьте нам маленькую фичу из MR28» (MRXX — это номера релизов, были 4 раза в год если мне склероз не изменяет), но это уже совсем другая история

Ну, значит мне повезло. лет 8 в Майндспиде, год с хвостиком в Глобале, вот уже почти полтора в Люксофте — никто и вообразить не может прямой коммит в VCS без ревью

Кто виноват — не знаю.
Что делать — настраивать процесс, чтобы не было случайных и неучтенных коммитов и т.п.
1. Jira — создается задача.
2а. Для SVN — SVN Review Board. Отправляется патч с изменениями на ревью другим разработчикам.
Комит с номером задачи из Jira и тикета из SVN Review Board, емеил ревьювера.
2б. Для Git — Bitbucket Stash
Пулл риквест на ревью другим разработчикам, зеленый билд в TeamCity, пройденные тесты, получение апрува на коммит.
Комит с номером задачи из Jira, емеил ревьювера.
3. Настройка окружения чтобы коммиты автоматически проверялись. Какое то требование не выполнилось — отбой.
Какие то шаги могут отличаться, но думаю в целом идея понятна.

Послушайте, вы что, правда серьезно обсуждаете что не так в конторе, где каждый хрен с горы, простите, 23 летний синьор может закоммитить в мастер без ревью и тестирования? Где никто явно и понятия не имеет что такое бранчи и зачем они нужны? Вопросы, который возникает у меня после чтения этой душещипательной психологической истории это почему эта контора до сих пор не разорилась, кто все эти странные люди которые в ней работают и почему их до сих пор не выбросили из профессии с позором и волчьим билетом? Все остальное на этом фоне это сродни обсуждению степени нездоровости атмосферы в горящем борделе во время наводнения.

Выбросить из профессии с позором и волчьим билетом — через черные списки HR, я полагаю? )

Понятно, что с нынешним мутным потоком барменов и юристов желающих вайти в айти и такие найдут свою работу, но я бы на собеседовании спросил про то, какую методологию работы с VCS использует претендент

прикольно, не знал что есть целые методологии по работе с VCS, думал все кончается двумя подходами — мастер наше все, или на любой чендж — бранч

Есть. Модный (и не любимый лично мной) Git Flow например. Хотя, конечно, его можно и описать как

на любой чендж — бранч
 — и за это справедливо критикуемый. В любом случае, может быть много разных подходов к работе с версиями кода, но подход «любой может закоммитить в мастер без ревью, желательно в пятницу перед релизом» — это за гранью.
Я согласен, что в svn или, не к ночи будь помянут, perforce мердж был тем еще удовольствием, но, вроде, 2017 год на дворе.

о прикольно, теперь буду знать что у нас на работе GitFlow ))

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

Умение быстро находить виновного.
ну, нет же. не «находить», а «назначать». и даже не виновного(разве «вина» — это не про умысел?), а скорее, «наиболее ответственного».

Сорри за поверхностный взгляд, но зачем нужен ПМ в такой команде? Проблему испорченного телефона он не решит, как этот пример показывает. Может быть лучше научить этих двоих общаться и сообщать команде, что происходит?

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

Еще добавлю, что проекту было пара месяцев от силы. Время каких-то кривоватых демок для инвесторов, не более того.

Одна точка контакта для клиента. Иначе ПМом пришлось бы стать самому заказчику.

Да нет именно «испорченный телефон как принцип назначения наиболее ответственного который всё равно сам ничего не может» а происходит это всё вот это от изначального неумения ни общаться как внутре так и вовне так и от изначально неумения строить процессы как внутре так и вовне. Не более того.

Всё остальное чистейшая классика «а все несчастные (семьи/команды/проекты) несчастны по-своему». (к) (тм)

ЗЫ: вот красивейший свежайший пример часть команды знала об орг. проблемах из-за которых она не пойдёт на заранее назначенный митинг на котором она «фактически вторая важная часть» и не только не пошла но и не предупредила об этом никак от слова вообще причём абсолютизируя пример как иллюстрацию никто из части команды даже на прямой вопрос «чуваки тут все ждут вы вообще идёте?» в мессенжере не ответил...

ЗЫ: кстати «часть команды» чисто технически «не наши» от слова вообще и подобные «провалы в коммуникации» за ними замечены были изначально и неоднократно доложены «куда следует» на что получено общестандартное «ну это нормально» ну нормально так нормально...

ЗЫ: с «назначенными менеджерами для точки контакта клиента» обычная «смешная история» когда а) оказывается что на проекте менеджеров 7 (семь) разного плана вот прямо проектную документацию в «джире» открываешь а там 7 (семь) менеджеров и 1 (один) «какой-нибудь программист» и основная «точка контакта клиента» такого менеджера написать программисту «тут клиент что-то пишет посмотри пожалуйста поговори ответь и вообще».

А что, есть, вообще, какая-то проблема, которую нельзя объяснить через «неумение строить процессы как внутре так и вовне и не более того»? Или, может быть введение идеи «одна точка контакта» не является построением процесса?

Отличная статья, спасибо.

В порядке дискуссии:

Искать виноватого проще, чем предотвращать ситуацию в будущем.
Кмк для многих «поиск виноватого» — неотъемлемая часть «предотвращения ситуации в будущем». «Виноватый» тут не самое лучшее слово, конечно — больше бы подошло «тот, на ком проблема проявилась». Кроме того, никто же не говорит что «раз виноват ХХХ — то надо его голову насадить перед входом в офис или поставить на его макбук Вин98 и заставить работать в ней». Даже не обязательно ему вообще что-то говорить, на самом-то деле. А вот попристальнее глянуть на его (а может и на своё) поведение и возможно предупредить еще целый ворох схожих проблем и конфликтов — точно не помешает.

Вообще за (много) лет довелось поработать и в коллективах, в которых основным вариантом был поиск виноватых, и с теми, в которых «надо решить проблему, а не искать виноватых». Оба крайних подхода одинаково легко абузятся, с одинаково пагубными последствиями. Как по мне самый здоровый и комфортный вариант — когда есть баланс.

Спасибо за отзыв.
С моего опыта, как только начинают поиск виноватого, все начинают защищаться. И после этого каждый коммент и идея тщательно проверяются на «а не атака ли это на меня?»

все начинают защищаться
Это кстати какая-то психологическая фишка явной ориентированности на необщение и неколлаборацию на любое что-либо люди сперва «все начинают защищаться» и уже только потом имея некоторый опыт обращения с таким и с такими и понимая о чём речь удаётся это обойти и достичь нормального просто вообще сотрудничества и какой-либо «обратной связи» и даже вообще пользы от них. Чесслово 100% чувство что работаешь с детским садом и пытаешь заставить «сьесть кашу за папу и за маму» кстати с большим интересом почитал бы практики по этому вопросу особенно практикующих психологов не обязательно с ориентацией на программистов.

Потрясающий разбор, спасибо. Неоднократно бывал в роли первого, но поскольку у нас приняты ревью, то код вливается только после командного одобрения. Кроме того, в случае сложных мержей, когда две плохо совместимые фичи должны быть залиты, предпочтение отдается следующему алгоритму: сначала сливается одна фича (та, что срочнее). После этого автор другой фичи мержит основную ветку в свою (не наоборот!), так как мерж может занять действительно много времени, а за это время другими людьми могут быть написаны и смержены маленькие таски. После мержа основной ветки в свою, автор второй фичи пробует смержить свою ветку в основную. Если за этот период времени никто ничего не заливал в основную ветку, то мерж происходит моментально, в противном случае нужно еще раз разрешать конфликты, но уже относительно быстро и безболезненно.

Спасибо. Интересное решение, на нынешнем проекте мы тоже что-то такое используем.

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

Пришел дед лайн и все стало непросто))

В этом случае code freeze не стоит устраивать в понедельник. В пятницу — можно, но с условием, что дата code freeze вырублена в камне и ни в коем случае не переносится.

Обалденное правило — давайте исключим релизы в 40% рабочих дней. Может, заодно и требования менять запретим? )

Имеются в виду еженедельные (и реже) релизы. Если релизы чаще — то требование снимается.

Может, заодно и требования менять запретим? )
В пятницу и понедельник? Абсолютно +100500 разве что за понедельник ещё можно ОК но это только потому что я начинаю в воскресенье кстати удобно очень.

написано конечно много. Но зачем это все? Очевидные ведь вещи.

Зима каждый год — очевидно же! Но ЖКХ не готов)))

Я тоже так думал. Однако большой спектр мнений к оригинальному посту заставил писать лонгрид.

Огромное спасибо за статью.
Очень полезный материал, чтобы подтянуть skill понимания эмоций и мотивов других людей.

Спасибо :)
Код у нас почти все смотреть умеют, а вот эмоции и мотивы — хорошо когда свои понять получается.

По моему нескромному мнению это общая проблема роста индустрии кода стало меньше а вот «эмоций и мотивов» наоборот.

Підписатись на коментарі