Код ревью, таски и борьба с экспертами

Выпуск №137 - The Art Of Programming

Разговор с Егором Бугаенко о менеджменте в IT

Книга ElegantObject:

Вторая часть книги ElegantObject получилась сфокусированнее и глубже первой.

Обе части основаны на статьях из блога Егора Бугаенко. Но это не копипаст. Все написано заново, другими словами и формулировками.

Егор отказался от работы с издательствами, и вместо 2х ревьеров, с которыми ему бы пришлось работать и которые бы гнули его текст, от отправил уже готовую книгу в сообщество программистов и получил 10 сильных feedback'ов. К 190 изначальным страницам добавились еще 30.

Review:

Плохо когда программист присылает за один раз большое количество изменений. Это плохой программист. Его пулреквест должен быть компактным... Иначе программист просто не профессионал. 

Тот, кто просматривает код, должен стараться этот код не принять. Хороший код ревьер - который умеет находить причины, чтобы отказать Почему? Ну, если мы хотим высокое качество, то нам необходимо постоянно говорить нет плохому качеству. Если же код ревьер, говорит да - такой ес-мэн, то это плохой специалист. Хороший ревьюер должен уметь правильно обосновывавать, правильно объяснять, почему он отказывает. И дальше уже это дело программиста и менеджера.

Дальше программист может или все исправить, или пойти к архитектору - спецу над этими двумя (программистом и ревьюером) и объяснить, что код использует например нестабильную библиотеку, но сроки поджимают, и чтобы все успеть, нужно ее использовать, и пожаловаться на ревьера, что тот не хочет принимать код... 

Теперь дело уже за решением вышестоящего менеджмента: горит - тогда берем это нестабильное решение, или не горит  тогда, иди и делай как надо.

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

Мотивация:

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

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

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

В компании Егора, за ревью, платят. Дал комментарии - заплатили, можно вместо денег и поинты(points), давать что-то что человек может копить и потом конвертировать во что-то (билет на конференцию, например, или еще что-то). Получается, что человек в любом случае получает награду - быллы, накапливает их, а вот будет ли его рекомендации приняты или нет, дальше архитекторы и менеджмент уже сами принимают решение. Ведь у них могут быть свои причины (например, решение увеличивает сроки и бизнес может пострадать). Менеджмент ведь тоже не зря что-то делает. Но ревьюер то свою работу сделал он вложился в проект и это было отмечено.

Сговор:

Например, 2 человека: один делает таску, другой ревьюит...  и они договорятся, ты делаешь типа ошибку, а я правлю, потом меняемяся, и "рубим бабло". Теоретически да, возможно. Но на практике - работает команда 10-15 человек, и все со всеми не договорятся. Это будет сразу видно. К тому же люди на таски и на ревью назначаются случайно. И, более того, программисты общаются друг с другом, только через код: нет скайпов, нет миитингов и т.п. - общение только внутри тасков и все тут же видно. 

Собрания:

У нас нет нет общих собраний - считаю, в правильных проектах должен быть один технический лидер, который принимает технические решения. И ему этому человеку, если и нужны общие митинги (meeting), то не в виде собраться в одной комнате и поговорить, а в форме вопросов и ответов от команды. 

Если ему нужно принять решение, нужно собрать информацию... то можно эту информацию собирать по разному. В одной комнате болтать или по общему чту, где большую часть времени обсуждаются отвлеченные темы. Так тоже можно и так делают 90% архитекторов во всем мире - так проще. так легче, так ленивее , так думать не надо. 

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

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

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

Таски

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

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

Документация:

Есть ложь, наглая ложь, статистика и твоя актуальная документация к проекту.

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

У нас пулл документация - вытягивается. Это максимально ленивый подход. 

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

И вот когда, кто-то столкнется с твоим классом и не поймет что там, он создаст новый тикет: "непонятно что-это такое, нет документации". Возникает новая задача, новый исполнитель, новые деньги и эту возникшая задача решается. При этом не делается ни какая красивая презентация, только необходимо - достаточный ответ, чтобы закрыть возникшую задачу(баг). Конкретному программисту нужна была документация, вот именно под него она и будет написана. Минимальный объем.

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

Если же мы используем модель - "давайте все задокументируем", мы получим документацию, которая никому ненужна. Документация должна создаваться под конкретные задачи.

Ну а как же, если программист завис на своей таске(залочился) потому что еще нет документации? И как решать вопрос с платой за документацию если она требует согласование бюджета?

Делаются зависимости. Например, ставим блокировку на задачу 13, и создается новая задача 14, в которой пишется, что нет возможности решить задачу 13 без документации. И что 13 зависит от 14й. Все. Программист свободен до тех пор пока не появится документация и занялся какой-то другой задачей. Соответственно по оплате за 13ю задачу он денег не получит, потому что она еще висит у него, ее никто не заберет, но сначала должна быть решена задача 14. Бывает что и месяцами висит.

Программист постоянно говорит - нужна тут документация, нужен юнит-тест, нужно интеграционное тестирование модуля и т.п. он не пишет это в своей 13й таске, он постоянно требует улучшения проекта до момента решения своей задачи.

И более того мы платим программистам за создание этих тасков. Пока сидел на 13 таске он еще 10 тасков создал с требованием чего-от от проекта и за все эти таски он получил деньги или поинты, он не сидел просто так, но за 13ю задачу ему пока не заплатили.

Понятно что в начале пока еще ничего не создано, очень много зависимостей.

Оплата:

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

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

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

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

Вот у тебя есть тикет и ты за него получишь (например 20$) и только тогда, когда он будет закрыт (статус closed). И ты заинтересован их закрывать - вытягивающая технология, ты сам тянешь и хочешь.

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

Многие люди спорили, говорили, что это не объективно, да без условно на одном тикете может и не объективно, но если их десятки, сотни, тысячи, то вполне очень даже. Если один закрыл 13 тикетов за месяц, а другой 48, то вполне видно чье вложение в проект объективно более сильно.

Эксперты:

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

У Егора есть несколько докладов на эту тему, и общий совет - "избавляйтесь от экспертов"! Они набирают столько знания о продукте, столько экспертизы, что заказчик не может их просто так сменить, это приведет к огромному количеству потерь и к огромным расходам по деньгам. И хорошо, если человек потом уходит мирно и не против передать после себя какую-то информацию, а в большинстве же случаев человек уходит не в пустое место, он уходит в другую команду, и там его нагружают ответственностью так, что ему становится наплевать что там было раньше. И, может быть, он хотя бы спустя рукава поможет предыдущей команде. но в основном и этого даже не происходит.

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

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

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

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

И отвечающий тоже не становится экспертом, потому что знания не остаются в нем, потому что все знания он уже выложил. 

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

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

Но, конечно, такой подход достаточно дорогой. Ведь бизнес думает, что хороший программист пишет код сразу без ошибок (bug free coding), а тут надо потратиться на эти таски по документации.

Конечно, это заблуждение, и вообще только плохой программист будет стремиться сразу делать все правильно, красиво и чисто - тратя на это лишние ресурсы, лишнее время, пытаясь вылизать код не понимая своей глобальной роли в этом бизнес процессе ... И бизнес тоже не понимает почему он должен оплачивать какие-то тикеты которые звучат, как "я не понял JavaDoc к такому-то методу..." вроде он просил вот такую фичу, или поправить что-то, а тут какой-то JavaDoc... Мы тут пытаемся дать какое-то образование заказчику, научить его  и передать ему нашу филосфию 

И то что заказчик там запостил задачу... она не стоит так дешево, 20$, она в конечном итоге в любом случае будет стоить 220$ потому что еще будет создано 10 сопутствующих тикетов, которые вокруг этой задачи будут завязаны в сеть.  Трогая что-то одно, мы тут же затрагиваем и все окружение. И сопутствующие задачи должны быть решены прежде чем мы решим основную.

Лень:

Программист должен быть ленивым. Но это не та лень - читобы ничего не делать. Лень должна быть конструктивной, чтобы ничего не делать дважды. 

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

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

Именно из-за лени рассказывать одно и то же два, три раза, снова и снова, Егора написал книгу о секретах продвижения блога. Его спрашивали, он советовал, когда понял, что это повторяется, оформил свое знание в достойную книгу. Сейчас у блога Егора Бугаенко более 100 тыс. уникальных посетителей в месяц.

Анонс:

В скором времени стоит ожидать от Егора книгу о, IT менеджменте, в которой он изложит свои взгляды и все те истории, которые он наблюдал. При этом он задумывает книгу как художественное произведение в виде новелл или даже романа с героями, их переживаниями и теми результатами, которые они получают в разных ситуациях. С нетерпением, Ждем!

Анонс2:

Менеджмент от Егора будет (надеемся) скоро воплощен в граните в его программном проекте, который можно будет арендовать для пользования в своих командах.

Анонс3:

Егор продолжает развивать свой язык программирования. Он верит в его промышленную актуальность и в скором времени собирается представить работающее приложение полностью написанное на  EOlang.