Pull to refresh

Comments 31

UFO landed and left these words here

А если это личный проект, выросший во что-то большее? А "он сидит и безразлично портит код своими жирными пальцами"!

Надо отпустить код, как говорят в таких случаях психологи применительно к любой зависимости :) Проще всего это сделать, получив за исходный текст программы деньги.
UFO landed and left these words here

это похоже на адаптированную версию кодекса бусидо


Каждое утро думай о том, как надо умирать. Каждый вечер освежай свой ум мыслями о смерти. И пусть так будет всегда. Воспитывай свой разум. Когда твоя мысль постоянно будет вращаться около смерти, твой жизненный путь будет прям и прост. Твоя воля выполнит свой долг, твой щит превратится в стальной щит.
Возможно, ошибка 0 — мало прочитано нужных книг по менеджменту.
Советы с книгами уже какой-то страшный баян, это надо просто любить читать, а не думать.
Для нормального вхождения в тематику ведущего, а не просто «награждением» таким званием и пусть сам разбирается, достаточно пару дней с человеком пообщаться, это может быть PM или CTO. Опыт надо передавать, в том числе и такой.
И каких вы именно посоветовали бы?
Др. Деминг? Хотя уже попсой становится, но истоки и вариации знать надо.
На самом деле книги помогу только структурировать имеющийся опыт, без практики они практически бесполезны.
Для всех подходят разные в зависимости от стиля управления. Мне сильно помогла книга Лалу «Открывая организации будущего». И, наверное, крики известных бизнесменов. Периодически вижу, как специалистов делают начальниками, но они остаются специалистами. И от этого зачастую плохо всем: и подчинённым, и им самим
Ещё большая проблема, остаётся мало времени писать код :(

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

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

Согласен полностью, если есть возможность, то расти можно и нужно. Но чаще вот это вижу: «Principal. Not senior senior» https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html


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

Мне очень помогла привычка не давать оценку сразу.

Увы, но у нас руководитель не дает такой возможности. Хоть какая-то оценка должна быть сразу.
Нужно объяснить ему разницу, которая возникает при правильной и неправильной оценке, и показать как это на практике портит ему жизнь. А потом просто попросить 15 минут на оценку, если задача больше чем на два часа.
Я так подумал, поанализировал свой опыт и опыт коллег и понял, что ваши пункты с обратной стороны крайности тоже минусы, возможно более очевидные:
1) Недоменеджмент
2) Неприятие введения новых технологий/новых технических идей от других
3) Постоянное сопереживание всем, недостаточная строгость/излишняя мягкость и вежливость
4) Попытки всем угодить
5) Недооценка своих возможностей

Хоть ещё одну статью пиши по каждому из пунктов.

Кстати пункты 2 и 4 как в вашем, так и в обратном списке тесно связаны и являются противоречиями друг другу в некоторых контекстах. Но бывают ситуации, когда они возникают и одновременно.

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

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

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

Отчасти это так. Важно понимать какой уровень делегирования и какой уровень контроля нужен этому конкретному человеку. Уровень делегирования определяется только опытностью сотрудника, уровень контроля зависит от сроков, важности и т.д.
Но сам факт того, что у джуна нет опыта не значит, что его не нужно приучать думать.
По поводу плавно и контролируемо — соглашусь.
Кстати, расскажите притчу о двух тимлидах, интересно :D
Хорошая статья — толковая и добрая что-ли.

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

Разумным мне кажется разрешить всем командам закладывать 20% времени (1 из 5 спринтов, или 2 дня из 2 недель) на задачи технического долга. Если этим заниматься регулярно, то он не только копиться не будет, может даже будут и ощутимые для бизнеса результаты.

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

Это работало в старые добрые времена, когда все кодили и коммитили как хотели. А сейчас ведь есть процесс: таска -> бранча на таску -> затем пул реквест с ревью. Подмешать туда левого кода нет ни особой возможности ни желания. Все проблемы нынче обрабатываются явно.
А сейчас ведь есть процесс: таска -> бранча на таску -> затем пул реквест с ревью
да, и если тебе для того чтобы правильно запилить фичу надо сделать рефакторинг, ты берешь и рефакторишь. а не откладываешь это на потом. вот о чем речь.
Технология из пункта 2 — это микросервисы? :)
Нет, микросервисы давно уже были к тому времени и в них-то как раз я ничего плохого не вижу.
Тема злободневна и стара как этот мир-)
Интересно было бы развернуть и систематизировать имеющуюся теорию и опыт, хотябы на уровне «продвинутых чайников».
И получить на выходе 125-ю книгу «Как стать эффективным лидером»)
В целом я согласен с ошибкой #3, но вот в этом моменте вы ошибаетесь:
Когда ты проводишь с компьютером огромное количество времени и увлечен тем, что делаешь, можно вообще забыть о том, что вокруг тоже люди. Они не идеальны, но у всех есть свое позитивное намерение в отношении того, что они делают.

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

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

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

А ведь есть еще люди которые не просто умеют в ИБД, но еще и мастерски перевешивают свои косяки на других (soft skills в курилке с начальником и все такое). Есть люди, живущие в альтернативной реальности, где они являются мега-разработчиками или мега-руководителями, а все факты, указывающие на обратное, — это ложь и провокация. И да, в этой альтернативной реальности они могут иметь офигенно позитивные намерения. Если подойдете к таким персонажам с эмпатией и займетесь поиском позитива, вами не просто воспользуются. Вас будут вертеть на известно каком органе.

А токсичности быть не должно, это да. Надо уметь выявлять коллег такого сорта и очень быстро с ними прощаться. Безо всякой токсичности ;)

По всем остальным пунктам с вами согласен. Спасибо за статью!
Only those users with full accounts are able to leave comments. Log in, please.