Пара тимлидовских побасёнок
Пришло время структурировать и осмыслить очередную порцию профессионального опыта. Изложу несколько ситуаций, участником или наблюдателем которых я являлся, с позиции тимлида. Каждая по своему забавна или печальна, и надеюсь, может быть поучительна, если вы узнаете какие-то мешающие лично вам моменты.
Секстет
А вы, друзья, как ни садитесь,
Всё в музыканты не годитесь
На ретро было правило менять ведущих. Кто-то вызывался добровольно чаще, кто-то не очень, из чувства долга — реже. В какой-то момент я пробовал использовать рандом. Обсуждали то, что обычно принято обсуждать на ретро — кого что достало, что пошло не так, и конечно процессы. Процессы можно было обсуждать и улучшать бесконечно. И ещё договорённости. Каждое ретро рефлексировали на свои процессы и набирали новых договорённостей.
Я наблюдал за подобным в одной компании около года, в паре команд. В других командах также обсуждалось как улучшить свои процессы, и использовались договорённости. Некоторые команды занимались этим годами. Меняли ведущих, тюнили процессы, брали договорённости. Годами.
Лучше ли стали процессы за год моих наблюдений и усилий с договорённостями в какой либо из команд? Как отразился эволюционый подход к постоянному улучшению на командах и продукте?
У продукта хватало багов и факапов. В командах была среднестатическая текучка, энтузиасты, выгоревшие и маломотивированные. Через год наблюдений в командах имелись: среднестатистическая текучка, энтузиасты, выгоревшие и маломотивироанные. У продукта по прежнему хватало факапов и багов. Я человек простой. Подумаешь — тимлид: таких тимлидов в крупной компании пальцев не хватит пересчитать. Делал как принято и не вылезал. Раз годами так делают несколько команд, наверно нужно-полезно? Или просто нравится.
На этом фоне споминаются альтернативные примеры из предыдущего опыта. Раньше приходилось, что я называю, ставить процессы. Как с нуля, формируя команду, так и внося изменения в legacy-процессы на немолодых проектах и legacy-командах. Порой встречая естественное сопротивления и инертность от старожилов, привыкшим к своему производстенному процессу, относящихся к любым изменениям по умолчанию плохо. Разные были случаи и комбинации. И на опыте нескольких компаний, я утвердился в мнении, что в среднего размера командах и продуктах процесс можно собрать с нуля за месяц-другой. Пересобрать legacy-процесс за несколько месяцев, в зависимости от сложности и размера legacy, количества сабботирующих его старожилов. И забыть до следующего полноценного масштабирования или большой перестройки. Оно будет работать. Если всё сделано правильно (учтены нужды всех участников, определены узкие места, согласованы и донесены требования к ролям и задачам) оно может работать долго, предсказуемо и есть не попросит. И большинству участников будет хорошо от того что производственный процесс знаком и предсказуем. Любой член команды сможет одинаково качественно и легко заонбордить новичка, без оговорок, у нас на эти две недели вот три новых договорённости, но и со старых ещё 33 действующих, тут «рыба лежала», а на эту карточку мы пока забили.
Мораль
Индустрия в какой-то момент помешалась на рефлексии и других психологических штучках. Помните тот момент, когда про soft skills заговорили? Вот-вот. Типа, инженеры тоже люди, им общаться больше надо, а то гикуют слишком.
Ритуалы на работе вокруг обсуждения работы стали напоминать психотерапию — долго, дорого, работает, если вы сами себя в этом убедили. Но конца у этой истории, как бы и нет, есть только желание бесконечно что-то улучшать.
А ещё вездесущая гибкая гибкость. Когда agile из прогрессивной моды перешёл в default. Мы 52, или 52/2, или у кого сколько раз в году, по пятницам, несколько часов занимаемся пересадками в своих квартетах/квинтетах/секстетах, а с понедельника пытаемся не нарушить свежеиспечённые договорённости, которые через итерацию никто не вспомнит. Потому что мы придумаем новые. Нет цели, только путь.
Эпиграф к этой истории из И. Крылова взят не для принижения профессионального уровня коллег-технарей. Но для того чтобы обратить внимание, что многие затратные, часто утомительные ритуалы не приводят к ощутимому результату, а время и силы на «пересадку» участников и бесконечный тюнинг процесса тратятся потому что заведено, в то время как есть более значимые проблемы, лежащие в инженерной плоскости.
Однажды лебедь раком щуку
Свобода, равенство, братсво.
Демократия, плоская структура, самоорганизация, бирюзовые мечты…
Я склонен полагать, что энтропия неизбежна. Хаос пускает свои метостазы в любом проекте, их можно только купировать с разным успехом. Но для подобной операции нужен хирург, представляющий себе ситуацию в целом, ответственный за состояние пациента.
На открытом код-ревью всегда найдётся кто-то, кому что-то не по вкусу. А вкус у всех разный. Соглашения наше всё — скажете вы. Конечно. Только попробуй согласуй что-то среди десятков человек с разными вкусами. Большая половина что-то после долгих обсужданий продавит. А другая останется недовольна. И так по всем вопросам, у нас же демократия. В итоге любые соглашения фиксируются долго и не охотно, и по каждому вопросу значительное количество не довольных, но подавленных большинством. В итоге все чем-то не довольны, проиграли в чём-то, но предъявить не кому. Поскольку демократия, и формальное высшее техническое руководство не при делах — не сверху же спускаются соглашения. Или вообще не интересуется такими мелочами, сами внизу разбирайтесь.
Продолжительность встречи растёт по экспоненте к количеству людей имеющих доступ к микрофону, если у них разные мнения. А чем больше людей, тем больше мнений. Разнообразие круто, говорили они. Возможность высказаться есть у каждого. Поэтому технические ретро мы проводили как можно реже, и решить какой-то глобальный вопрос удаётся обычно к тому моменту, когда эпоха ставит уже совсем другие, новые вопросы.
Наблюдал интересный словесный бокс по зуму, в два и даже три раунда (по 40 минут!), с переходом на личности. Ну не все характерами сходятся, на то нам и демократия. В присутствии формального руководителя собравшихся, и прямого руководителя боксирующих. Но, авторитет не принято использовать чтобы затыкать чью-то свободу слова, и модератор даже функции реффери выполнял очень не охотно, зачем первому среди равных вылезать на ринг? Может ему тоже был интересен поединок, пусть и ценой в десятки самых дорогих для компании человеко-часов.
Альтренативный опыт
Когда субординация более явная, то и подобное пикирование пресекается быстро и эффективно. Да и выносить на публичный ринг, в присутствии руководителя подобные склоки — обычно крайний случай. Да, есть обратная сторона: конфликты могут разрешаться в виде интриг за спиной, искажения информации в свою пользу. Но на то и ответственность руководителя, локализовывать конфликты и разрешать их. А не наблюдать петушиные бои.
И тут дело не в компетенции менеджемнта, а скорее самой корпоративной культуре терпимости и открытости. Эти ценности, которые следовало соблюдать, даже в очевидный ущерб пользе дела.
Возможно для некоторых корпоративных культур нужно иметь психологическую совместимость. У людей разные источники мотивации и склонность воспринимать разные типы авторитетов. У меня скорее вызывает сожаление факт, что в существующих параллельно в IT-компании двух культурах — корпоративной (про людей и коммуникацию) и инженерной (про технологии и собственно ключевую деятельность), ко второй можно относиться с ценизмом, а к первой нет.
Как разработчик, техлид, тимлид, я в первую очередь носитель инженерной культуры. Компания и корпорация для наёмного сотрудника вторичны, по отношению к его профессиональной честности. Увы, с годами, мне кажется, всё чаще технари позволяют забивать на это, прикрываясь интересами бизнеса, разными элементами корпоративных культур и культурок, вроде терпимости, нетоксичности. Я это чаще стал встречать среди сеньоров, архитекторов. Я понимаю, что условного джуна менеджементу легко продавить на компромисс — у него может и не быть чётких представлений о том как делать не стоит, знания практик и приемлемых альтернатив. Можете счесть возрастным брюзжанием, мой карьерный опыт субъективен. Но раньше я встречал больше здорового пофигизма к интерсам бизнеса у опытных разработчиков и способности отстоять свою позицию.
Мартышка и >9000 очков
У нас были OKR, метрики BI, метрики продукта, метрики команды, метрики QA, метрики эксплуатации, метрики, метрики… Все известные человечеству тулы для сбора метрик, и мониторинга хранилищ метрик, метрики за метриками и мониторинг системы мониторинга. Ворох систем логирования.
Нелинейное усложнение системы по мере роста неизбежно. Зоопарк тулинга для наблюдения за пациентом растёт, нагрузка и требования к мониторингу тоже растут. Но разнообразие вспомогательных инструментов при масштабе, вкупе с открытостью всего и вся и прозрачности в организации дают ряд побочных эффектов.
Отсутсвие изоляции между отделами даёт доступ к разнообразным инструментам. Со временем разработчики начинают пользоваться некоторыми системами сисадминов, QA полагаться на бизнесовые метрики, а BA и продакты коллекционируют SQL-запросы к основной БД. И это происходит выборочно, как следствие открытости, в порядке частной инициативы. Ситуативно получаются доступы, люди привыкают пользоваться той или иной системой, даже если она была создана в другом отделе для других нужд.
Сайд эффект — из-за обилия нет единого флоу получения информации. Каждый разработчик использует свою сборку этого швейцарского ножа. Где-то эта сборка при онбординге презентуется лидом новому разработчику. Но, по мере надобности, неизбежно мутирует на местах.
Лично меня напрягавший фактор этого изобилия — не очевидно куда лучше смотреть, инфляция внимания, высокая информационная нагрузка при поиске, десятки мест по которым приходится ходить в случае инцидентов.
Другой нюанс — образуются дополнительные неявные связи. Например: бизнес-аналитики жестко завязываются на схему БД в своих отчётах. Разработка в этот момент теряет возможность безболезненых миграций, нужны ещё согласования и усилия на переход. Или разработка привыкает к каким-то плюшкам рождённых в недрах эксплуатации. А эксплуатация и не в курсе, когда выводит собственный сервис из эксплуатации, получаем ступор в разработке.
Притивоположная ситуация — строгое огораживание своего инструментария отделами, взаимодействие чёрных ящиков, когда никто не эксплуатирует сервис соседа, да и не знает про него, если это не API. Устоявшиеся у каждой касты сотрудников свои инструменты.
Всё вышеизложенные примеры являются субъективным восприятием автора и утрированы для художенственного эффекта.
Решений я не предлагаю. В большинстве случаев их и нет — энтропия растёт, мир усложняется, а мозг стареет. Но было бы интересно прочитать в комментариях подтверждение или опровержение описанных случаев и ваши «басни» о наболевшем, альтернативные им решения и найденную мораль.
