Про пм-ов.

А давайте не будем думать? Давайте будем ничего не делать?

Спросим у исполнителей сроки, сравним их со статистикой (можно даже machine learning какой-то прикрутить!), честно занесём в жиру, а потом будем этих же исполнителей пинать при несоблюдении сроков ("Ну вы же сами эти сроки обозначили! Исполняйте или получите штраф!")

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

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

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

Выпьем не чокаясь!

Чатик с обсуждениями: t.me/ctorecordschat

Вопрос №1.

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

Происходит следующая цепочка действий: разработчики исправляют баг, pullrequest проходит абы как, мержат, собирают, сборка собралась, QA проверяют что конкретно этот баг исправлен, ставят галочку, сборку отдают на объект и в результате оказывается, что исправлением сломали что-то еще. Тимлид садится за консоль, достаёт огнетушитель и всю ночь тушит пожар.

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

Раньше мы были подписаны на code collaborator и там была полезная фича «подписываться на изменения в каких-то определенных проектах» и когда кто-то правил часть кода, которую ты хорошо знаешь, - приходило оповещение и автоматически ты становился ревьювером - как настроишь. Сейчас пользуемся битбакетом, а там с интерфейсом pull request нет того удобства, как в code collaborator.

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

Подскажите, пожалуйста, как контролировать качество проводимых code review? Как улучшать качество проводимых code review?

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

Увы, code review не может стать никогда гарантом отсутствия ошибок, хотя с ним конечно улучшается качество кода, находятся «глупые» ошибки (опечатки) в реализации и повышается степень совместного владения кодом. Гарантией отсутствия ошибок занимаются тестировщики, которые на каждый подобный выкат должны поинтересоваться, какой функционала «потрогали», провести смоук-тест основной фикса и всего затронутого функционала. Отличное подспорье при этом автотесты «чёрных» и «белых» ящиков. Чтобы разработчики совсем уж не расслаблялись, в чатиках во время обсуждения этой проблемы рекомендовали ввести метрику kpi «возврат кода из тестирования» 😉

Кстати, тестировщики после пропущенного подобного бага сами просто обязаны организоваться и провести свою собственную ретроспективу на тему «а как же мы так облажались-то?» Они (тестировщики) очень смышлёные и их нельзя не дооценивать!

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

В книге Катрин Пассиг и Йоханнес Яндер «Программирование без дураков» подробно расписывают процесс поиска ошибки: в основном он состоит из попыток наобум что-нибудь изменить и попробовать, не заработает ли сейчас. В голове программиста при этом крутится нечто вроде: «Результат какой-то слишком маленький, сложная штука это исчисление процентов. Может, стоит всё-таки в конце умножить на сто? Да, так лучше. Ура, рабочий день закончился!»

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

Когда в продакшн сыпятся аффектированные ошибки (то есть в одном месте исправили, а в другом вылезло что-то новое), то скорее всего что-то не так с основной архитектурой. И пока не устранишь корень проблем, – они будут сыпаться и не всегда их отловят на code review или дажа на тестировании. Попросите сеньоров посмотреть на место внимательней. Когда такой баг пришёл, можно заткнуть его костылём, но нужно выбить у руководства время на то, чтобы после релиза сесть и спокойно докопаться до истины.

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

На эту тему есть отличная переводная статья «Code review по-человечески» Мишеля Линча: https://habrahabr.ru/post/340550/ и https://habrahabr.ru/post/342244/ (вот тут можно прочитать оригинал на английском: https://mtlynch.io/human-code-reviews-1/ и https://mtlynch.io/human-code-reviews-2/). Там как раз пишут про то, на что хорошо бы обращать внимание при code review.

Немного скажу про инструментарий bitbucket. Atlassian давно уже запустил возможность создавать плагины, встраиваемые в облачную часть Bitbucket, расширяющие его интерфейс и добавляющие новые возможности. Если раньше владельцы репозитариев были ограничены вебхуками и REST API, то теперь появилась возможность допиливать «под себя» и для других разработчиков непосредственно облачный интерфейс. Запилить свой плагин, следящий за определёнными кусочками кода, уже обычная программерская задачка. Также можно также воспользоваться готовыми плагинами: https://marketplace.atlassian.com/search?product=bitbucket

Реализовать в своё плагине обычный вочдог, который следит, какие куски кода изменились и были подано на code review, уже стало просто. Это может сделать любой (вообще любой) разработчик.

Также хочу обратить внимание на самих разработчиков, – очень удобно их разбивать на пары старший-младший, когда от старшего опыт постепенно перетекает младшему. Один пишет тесты, другой код. Один разрабатывает архитектуру, другой реализацию. Один пишет, другой проводит code review. И постоянно при это меняются. Не всегда эта методика оправдана, но для повышения качества её удобно вводить хотя бы временно!

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

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

Также существуют системы постоянно контроля качества кода. Почитать можно здесь https://ru.wikipedia.org/wiki/SonarQube и https://habrahabr.ru/company/pvs-studio/blog/315422/ Это уже ближе к code review автоматизированному.

Вопрос №2. Коллеги хотел бы спросить вашего мнения. Что на ваш взгляд главная мотивация для разработчиков: деньги или интересность задач?

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

Ответ на вопрос №2

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

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

Не будет работать на семейных, - им тупо нужны деньги. Не до понтов.

С другой стороны - просто бабло не стимулирует инициативности. Тут как правило скатываются в ремесленничество. Соответственно накапливается технический долг и проект через какое-то время отстаёт по технологиям

Так что обычный состав команды - баланс между молодыми, желающими понтов/новых технологий и опытными проводниками, уже протоптавшими свои тропинки на полях граблей.

Компенсируют молодые свои увлечения новыми технологиями тем, что они энерджайзеры. Сваливай смело на них годовой объём работы, - продуют за месяц.

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

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

Есть ещё один аспект этой темы - съесть вместе семь пудов соли: невероятно слаживает команду. Со слаженной командой можно брать сложные проекты. С неслаженный огромной риск все просрать, так как эта команда заходит на грабельные поля и протаптывает свои собственные тропинки. В этом случае надо молиться, чтобы тропинки были протоптаны раньше, чем закончатся деньги)

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

Привет всем!

Я тут постепенно скатываюсь в удобный для всех формат публикаций в этом канале. Уже попробовал обстоятельный ответ на выходных. попробовал быстрый ответ в дискуссии. Неожиданно нашёлся канал цто медузы, в котором он просто пишет, чем занимаешься каждый день. С удовольствием подписался на него сам https://t.me/ctodaily и попробую также писать что-то любопытное из ежедневной работы.

Всем удачного рабочего дня :)

Вопрос №2. Мат - боль лида или инструмент?

Мой ответ:

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

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

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

Это кажется неочевидным, но попробуйте! Чувствуете, как манит эта высота?

Комментарий к вопросу №2:

Эмм... Мат шпаргалка, когда не хватает чего-то, чтобы изменить ситуацию...

Ну камон. Мат - всего лишь выразительное средство. Уместность или нет определяется коллективом и тем, насколько близко они общаются. И пока юристы с бухгалтерией, общаясь на своём птичем языке две недели не могут решить вопрос, у нас достаточно крикнуть что-то в стиле «Коля, ну что за хуйня?!» и через полчаса вопрос решён.

Мой ответ:
На счёт бухов и птичьего языка, - Тебе не повезло. Не пришлось работать с бухами и юриками, которые реально профи, - они реально быстро всё делают. Очень удобный инструмент!

А Коле я обычно пишу немного короче: "Коль?"
Этого вкупе с моим авторитетом хватает более чем.

Или могу просто послать ему сообщение "?". Очень быстро всё решается.

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

Про тимлида и его команды

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

Первая команда, - техническая. Отвечает на вопрос "как делать". Она подчиняется тимлиду и в зависимости от его навыков более или менее подконтрольна. Если тимлид хорош, - результатов будет больше, отношения будут лучше и карма будет расти. Тимлид может быть каким угодно, - африканским диктатором, добрым доктором айболитом или ещё кем-то. Он может замкнуть команду на себя и устроить внутри неё свои собственные порядки и законы. Может даже объявить, что "2+2=5" и сотрудники, если хотят работать в этой команде, вынуждены будут согласится.

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

Тимлид - двуликий Янус, которым в одной команде является руководителем, а в другой - подчинённым. Чтобы понимать саму сущность происходящего в этих двух командах попробуйте сами для себя ответить на вопросы:

* Что будет, если в технической команде один из ключевых сотрудников перестаёт работать (неважно по какой причине)? Но при этом требует уважения.
* Что будет, если в технической команде все сотрудники перестают работать? Но при этом требуют уважения.
* Что будет, если в менеджерской команде один из ключевых коллег нашего тимлида перестаёт работать? Но при этом требует уважения.
* Что будет, если в менеджерской команде все сотрудники кроме тимлида перестают работать? Но при этом требуют уважения.

Вопрос №3. Что будет, если тимлид ведёт себя как м_дак, но при этом требует уважения?

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

Дело в том, что «ведёт себя как мудак» - это значит, что он не смог договорится с кем-то. По тупости или по невежеству.

Но если для него все закончится хорошо и он останется в профессии, значит его модель поведения успешна

А если плохо, - значит «вон из профессии». Естественный отбор.

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

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

Если свалился из балансировки, значит модель неудачная. Бегом в другую компанию пробовать дальше.

Некоторые сдаются.

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

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

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

Какая мораль? Работай в явно приносящих прибыль проектах. Меньше гемора, больше денег. Правда есть нюанс: нужно ебашить. Днём, ночью, когда угодно и сколько угодно. Никакого баланс work/life.

Не все к этому готовы.

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

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

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

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

Pokerface из рабочей переписки

- Коллеги! В вашем API для GET-запросов ответ возвращается в кодировке "WINDOWS-1251", а для POST-запросов в "UTF-8". Так и задумано?
- Да. сейчас именно так работает. Не исключен вариант того, что в будущем все будет приведено к какому-то одному определенному формату. И если будут такие изменения - мы предварительно проинформируем об этом в ЛК.
- Ооооооооооооооооооооооооок.

@slovozaslovo в чатике https://t.me/teamleadconf приводит очень удачную на мой взгляд градацию разработчиков:

* junior developer - должен уметь хорошо выполнять поставленные задачи.

* middle developer - может быть самостоятельным и автономным в рамках своей компетенции,

* senior developer - должен уметь организовывать работу кого-то еще в дополнение к самомтоятельности

* team lead - должен делать то же самое, но на команду других.

Коллеги поделились багом по заказам с курьерской доставкой по Москве

Последовательность действий #1:
Делаем заказ в 10:00 на доставку со склада XXX по адресу YYY (внутри МКАД) к 15:00мск. Время доставки - 58 минут.

Последовательность действий #2:
Делаем заказ в 3:00 на доставку со склада XXX по адресу YYY (внутри МКАД) к 15:00мск. Время доставки - 2 часа 58 минут.

Пишите в комментариях https://t.me/ctorecordschat ваши версии, в чём может быть ошибка :) Сразу предупреждаю, ответ ржачен!

Шторм

Знаете, как это бывает? Интернет вдруг пропадает... Чертыхаешься... ищешь телефон провайдера.. Звонишь... а там трубку ни кто не берёт... Или занято всё-время.

Или ещё бывает сайт вдруг пропал. Что-то у хостера случилось. Пытаешься им дозвониться... Или задать вопросы в чатике... А они куда-то все пропали... Молчат.

И в это время на глаза налезает тёмная пелена. Хочется убивать от злости и на ручки от отчаяния.

Все знают, как это бывает. Но некоторые из нас бывают и на другой стороне проиходящего. В это время ВСЁ рушится... Даже кофеварка и та взрывается - не до звонков тупых абонентов! Знаем мы, что у них ничего не работает! Знаем! Не до них! Нужно чинить.

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

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

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

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

Эти люди переживут с вашей командой шторм и будут самыми лояльными клиентами! Они практически станут частью команды!

Всем счастья!