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



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

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

    Если коротко — все ещё хуже, чем выглядело со стороны.

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

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

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

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

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

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

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

    Человеку, который нами управлял, надо было знать только одно — подкину я ему проблем на сегодня, или нет. Обязан ли он потратить на меня сегодня время. До того, как я начал говорить, у него в голове уже есть идеальная речь для меня: «еверифин гоус акордин ту план». Любое другое развитие событий для него — чистое зло.

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

    Мы начинаем что-то обсуждать, и оба понимаем — нам нужно найти способ перестать быть проблемами. Это не имеет никакого отношения к продукту или проекту. У нас есть гребаный тикет, который мы должны передвинуть. И мы его двигаем — самым простым из доступных способов. Чиним кодом, закидываем в норепро, ставим лейбл «blocked by» — да что угодно. В этот момент нам совершенно наплевать на продукт, у нас горит тикет. Или много тикетов.

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

    Все тимлиды, с которыми я работал не знают как это сделать — да и не хотят. Они работают как работают, а джиру используют, чтобы считать свои менеджерские обязанности выполненными. Ведь люди, которые оценивают тимлидов, смотрят в джиру, а не на продукт. А люди, которые смотрят на продукт — могут только генерить новые тикеты для джиры. Оценивать программистов они не могут. Но джира ведь ни на что не влияет! Я видел ужасные продукты, у которых канбан доска была в идеальном состоянии, и отличные продукты, у которых в столбце «at work» по три месяца лежали тикеты с названием «сделать проект».

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

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

    Поэтому определять плохих разработчиков взялись чистые менеджеры — не разработчики. Они напридумывали кучу систем с тикетами, графиками, всякими перфоманс ревью и вот такой шляпой. И это бы даже сработало, на каких-нибудь тупицах. Вот только даже худшие из разрабов достаточно интеллектуальны, чтобы обманывать эту систему. Ну, вы знаете как это делается. Они ведь меряют все в тикетах? Круто. Я декомпозирую «переработать интерфейс формы X» в десять задач в стиле «поправить надпись в кнопке Y». Работы столько же, тикетов больше. Тимлид надавал бы мне по роже за такие финты.

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

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

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

    Но такая команда — фантастическая удача. А обычно происходит вот что. На десять человек у тебя два, которые хотят работать. Один из них тимлид, а второй увольняется. Разработка работает плохо, и приходят менеджеры — чинить. И вот с этого момента никаких шансов уже не будет. Менеджеры построят процесс вокруг джиры, возьмутся управлять вещами, которых они совершенно не понимают. Построят найм людей, в работе которых ни черта не смыслят, начнут приглашать туда существующих разрабов, которые потешат ЧСВ, логнут это время в таймрепорте, и дадут рандомный фидбек. А потом решат, кого нанимать — тоже рандомно. Люди, которые хотят работать, будут время от времени попадать в такие команды, где или превратятся в бездельников, или не приживутся.

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

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

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



    На правах рекламы


    Многие клиенты уже оценили преимущества эпичных серверов от Вдсины.
    Это недорогие VDS с процессорами AMD EPYC, частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит реализовать практически любую идею — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Закажите и вы!

    VDSina.ru
    Серверы в Москве и Амстердаме

    Комментарии 101

      0
      Мне кажется, любое производство (кода или чего иного) всегда негладко и сопряжено с мыслями о том, «как это вообще может куда-то там двигаться, этим же невозможно управлять». Иначе все компании бы были идеальными компаниями в вакууме, а таких вообще нет. Оптимизировать эту функцию полностью невозможно, боль будет всегда, а попытки решить это одним гибким наскоком сродни написанию DSL для всего. Улучшать что-то на пару процентов тут, на пару процентов там — вот реальный выход, нет серебряных пуль.
        0
        Хотел выдать продуманную реплику, но что-то не очень выходит. Поэтому просто пара мыслей на этот счёт. Когда возникает идея в необходимости одного гибкого наскока? когда бизнес требует не два процента, а в два раза улучшить-углубить-увеличить. Реальное улучшение на два процента — это с точки зрения бизнеса всё равно что ничего не происходит. А если Вы работаете также хорошо как вчера, им кажется что дело медленно ухудшается. И кому-то, вероятно, всё же придется думать, что делать с «двумя разами». И тогда этот кто-то найдёт ТРИЗ или Голдрата, то есть не пулю в чистом виде, но что-то вроде того.
        +4
        До слез. Инфантильность высшего уровня.
        При нормально построенных процессах, статистические значения внезапно оказываются весьма и весьма верными.
          +10
          Со статистическими значениями есть нюанс. В экономической науки известен закон (или правило) Гудхарта, который гласит, что если найденная статистическая закономерность используется для управления, то она перестает выполняться (обычноне сразу, а постепенно — но тем не менее). Причина, насколько я понимаю, лежит на поверхности: люди — существа не глупые, и они изобретают способы лично для себя получить выгоду или снизить ущерб от этих самых управляющих воздествий — то есть, поведение их изменяется. В обсуждаемой тут статье, кстати, есть примеры, как это выглядит в реальности.
          Так что у «нормально построенных процессов», которые опираются именно на статистические значения перспектива — перестать со временем быть нормальными. А это означает, что руководству, чтобы не терять эффективность, по-любому придется подходить к своей работе творчески, а не шаблонно, работать с людьми, а не с процессами и т.д., и т.п.
            –3
            все таки закон гудхарта гласит что «когда экономический показатель становится целевой функцией для проведения экономической политики, прежние эмпирические закономерности, использующие данный показатель, перестают действовать.». А это — совершено не то что вы написали.
              +4
              а что он неправильно написал?
                –2
                «Использовать для управления» — это немного не «целевая функция», не находите?
              +1

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

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

                Очень правильная мысль на мой взгляд. Только дело даже не в адаптации этих процессов под конкретную окружающую среду, сколько в контроле над этими процессами. В их поддержании. Это как вырастить дерево. Прежде чем дерево вырастет, окрепнет и начнет самопроизводство, когда его можно оставить без присмотра — надо достаточно много усилий приложить ухаживая за ним. Поливать, подвязывать, следить чтобы прижилось и вредители не погубили.
                И к сожалению не так много людей, которые умеют это делать, именно так взращивать процессы. Больше тех, кто думают — а вот посажу дерево, а оно само вырастет. Практика показывает — что чаще засыхает, без постоянного контроля. А это достаточно утомительно и отнимает много сил.
                  +3
                  Полностью согласен — профессиональных менеджеров, равно как и профессиональных программистов немного. Вокруг сплошные цари менеджмента и короли разработки. :)
                +3
                Есть методики управления для достижения «предсказуемого результата».
                В разработке это было бы как в армии или церкви, каждая команда из пяти рядовых, над ними team lead (политрук) и tech lead (командир). Ну и скорости движения вперёд, раза в три меньше чем сегодня.

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

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

                  0

                  Вы политрука с командиром местами случайно не спутали?

                    0
                    Думаю что нет. Командир ведёт в правильном направлении, принимает решения о стратегии и тактике движения. В случае с програмированием, это скорее техлид.

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

                    Как мне кажется это больше тимлид.

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

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


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

                  +12
                  Адекватно определить, хорошо ли работает разраб может только разраб.

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

                    +1
                    Ну, допустим, видит он что команда не способна выполнять задачи с предсказуемым качеством. А почему? Потому что команда плохая? Или один разработчик плохой, и своей токсичностью и\или кодом саботирует команду? Или тим-лид плохо справляется? Или архитектор изначально плохую архитектуру заложил? Или с процессами в команде беда? Или с процессами беда в целом в компании?
                      0
                      На эти вопросы должен отвечать не ПМ, а тимлид, если тимлид отвечает что-то вроде «мням, не знаю, а че я то сразу» — то надо сигналить наверх и менять тимлида
                        +2

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


                        Бэкграунд разработчика может помочь в понимании происходящего, но не является обязательным. Более того — он может и помешать, ибо стимулирует закапывание в совершенно неважные для этого уровня управления детали. Фактически одна из вещей, которые специалисту (любому, не обязательно разрабу) приходится делать, если он хочет сменить сферу деятельности на менеджмент — придушить в себе специалиста. :) Это особенно тяжело, когда являешься специалистом высокого уровня, видишь косяки на уровне исполнителей, понимаешь, что сам мог бы сделать лучше/быстрее и т.п. Но регулярные влезания на уровень исполнителя самому, увы, ведут в тупик.

                        +1
                        ПМа вообще не интересуют вещи типа качества кода

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

                        А «качество кода» — это не «качество» разве? Разве его не иснтересует, насколько сложно будет поддерживать и доработатывать решение в дальнейшем?
                          +3

                          Качество исполнения задачи в понимании ПМа — реализация заданного функционала в заданные сроки. Что там внутри — его таки да, не особо интересует. А качество кода — это не цель, а всего лишь средство (одно из) для достижения конечной цели. Вот самого разработчика оно должно интересовать, тимлида — тоже, а вот ПМа — уже нет.

                        +17
                        Фил поднял любопытную тему. Насчет методологий управления разработки у меня всегда был один простой вопрос: существует ли исследование честно доказывающее их пользу?
                        Приведу пример. Существует понятие доказательной медицины. Оно предполагает, существование чётких статистически значимых доказательств эффективности. Современная доказательная медицина содержит в себе например такое понятие как двойное слепое плацебоконтролируемое исследование.
                        Собственно существуют ли аналогичные исследования эффективности для таких методологий как Аджайл, Канбан, Скрам?
                        Просто, если таких исследований нет (ну ладно, кого я обманываю, не «если», а «поскольку»), то может не стоит воспринимать рекомендации из методологий буквально как воинский устав? Может стоит относится к ним как к просто набору частных рецептов, которые могут быть найдены полезными в таких же частных ситуациях.
                          –3
                          В точку! Жаль, не могу плюс поставить.
                            0

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

                              +1

                              Так тут — типичная история. Те кто прочитал инструкции (исследования) — знают когда работают те или иные лекарства или подходы. А те, кто не прочитал, но употребляют их или предлагают другим — ССЗБ. Так и с методиками этими — люди видят очередную рекламу методики (или таблетки "от головы") и свято верят в её действенность. Потому и творится такое мракобесие. Те же Скрам и Канбан уже давно нашли нишу, где доказали свою эффективность. Но часто их притаскивают для тех задач, где они бесполезны. Отсюда и недоверие.

                                +2

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

                                  +1
                                  Все мои манагеры говорили, что Аджайл нужно уметь варить под ситуацию… манагеры и проекты были разные, а итог примерно один и тот же.
                                    0

                                    А это как с сантехниками. Каждый следующий говорит, что у предыдущего руки росли из задницы. Увы, "каждый мнит себя Солнцем или центром вселенной".

                                  0
                                  существует ли исследование честно доказывающее их пользу?
                                  Если люди не хотят работать — ничего не поможет. Доказано — нет таких методологий, которые заставят разработчика работать. Если люди хотят работать, тогда всё, что нужно делать — убирать препятствия с их пути. Это и есть про скрам.
                                    0
                                    Во истину. Вся суть и истина в этих словах. Всю блять статью можно было сократить до этих слов.
                                  +3

                                  ITT миллениалы мечтают о программной инженерии.

                                    +8
                                    Тот случай когда автор угадывается по названию статьи.
                                      +2
                                      помнится, автор как то обещал — то ли нам тут, то ли сам себе — написать полезную техническую статью.
                                      Но это не точно.
                                      +1

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

                                        +2

                                        Ну ок. Никто не умеет. А делать-то что?

                                          –1
                                          А что умеем, можем, хотим? К чему есть стремление?
                                            0

                                            Вопрос не понял. Можете развернуть?

                                              0
                                              Ваш ответ намекает на Ваши знания и умения. Мы открываем пару проектов в перспективе. Ищем людей, которые хотят и умеют работать.
                                          0

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

                                            +12

                                            Задача менеджера — гасить в себе энергию жесткого излучения, которые испускают менеджеры верхнего уровня, и защищать этим инженеров от губительной радиации, создавая им биосферу, пригодную для интеллектуальной работы. Дальше выводим так:
                                            Плохой менеджер — всепропускающий фильтр, сам не нагревается, зато команда сгорает, или вынуждена тратить усилия на индивидуальную защиту от излучения — какая уж тут работа над продуктом. Хороший менеджер — нагревается сам от внешних лучей, плюс поглощает энергию изнутри коллектива — и этим медленно сгорает за деньги и за дело. Больше ничего — джиры, скрамы итд — все это вторично или третично уже. Возьмите, если не армию, то, например, экспедицию — и выведите, каким должен быть хороший руководитель экспедиции, а какой будет плохим. Получатся чисто человеческие качества, без Джир. В айти так же. То есть ищите Человека.

                                              0

                                              Менеджеры бывают разные. И набирают их для разного.


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


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


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


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


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

                                                0
                                                И людей в команду ищите, а не мифических «разработчиков» :)
                                                0
                                                Ключевыми элементами эффективного управления является целеполагание, обратная связь и кадры. Целеполагание в разработке предполагает четкое видение контуров и функционала будущего продукта. Обратная связь — это своевременная и объективная информация о расхождениях между желаемым и текущим состоянием разрабатываемого продукта. Ну а кадры, как известно, решают все, а потому требуют к себе индивидуального подхода буквально к каждому специалисту, если он в команде.

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

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

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

                                                    +2
                                                    1. Кристальная честность в рабочих отношениях — основа эффективности.
                                                    2. Простого управления недостаточно, нужна определенная философия под
                                                    свой стиль работы.
                                                    3. Нет сближения на эмоциональном уровне — нет эмпатии и в совместной
                                                    работе. Команда профессионалов или семья? Семья, профессионалами они станут
                                                    довольно быстро и дружно
                                                      +1

                                                      Маленькие и эффективные команды я видел только в стартапах, где состав был из прямых выгодополучателей бизнеса, и скреплен чем-то общим, например это основатели, их друзья, пришедшие сразу после старта, или братья, сестры. Таких людей не надо мотивировать, они готовы работать в любое время суток и выстраивать продукт используя только github. Готовы сапортить стенды по выходным и быть сейлзом вместе с разработкой. Но наступает момент когда бизнес растет и надо брать "наемных", именно в негативном смысле. Эти люди приходят не развивать продукт или бизнес, а приходят развивать себя, чтобы через год продаться дороже в место получше, а так же просто заработать денег. Чтобы заставить их работать есть целый завод из софта и людей, который приходится строить. Чаще всего просходит, как Фил написал, и в команде из 10 работать хотят 1-2 человека. Да и быть эффективным и быстрым в большой компании в целом сложно, там квартальные планы, бюждеты, интеграция с другими продуктами, которые еще более слоупоки чем вы, и всё такое.


                                                      А выграть в лотерею, я считаю можно в 2 случаях:


                                                      • Когда вы наемный и попали на хорошего руководителя
                                                      • Когда вам удалось нанять человека, которому реально интересен продукт и его развитие
                                                        Оба события это вероятность 1/10
                                                        +1
                                                        Эти люди приходят не развивать продукт или бизнес, а приходят развивать себя, чтобы через год продаться дороже в место получше, а так же просто заработать денег.

                                                        С точки зрения наемного работника это оптимальная стратегия. Какой смысл вкладываться в развитие чужого продукта и чужого бизнеса?
                                                        Сегодня ты горишь на работе, весь выкладываешься на все 500%, относишься к делу как к своему собственному, а завтра тебе отвешивают пинка под зад, потому что в бизнесе проблемы, и платить тебе твою з/п они больше не могут (не хотят), и ты весь сгоревший идешь искать новый проект…
                                                        Ты наемный работник — твое время оплачено с 9 до 18, с перерывом на обед, все, точка.
                                                          0

                                                          Смысл в том, что ты можешь подняться из простого наемного программиста либо в ключевую позицию либо стать партнером. Но это только если ты прям хочешь именно этим заниматься и видишь перспективы у компании, иными словами сам бы делал тоже самое. Часто разработчики говорят что им не нравится их продукт и компания не понимает что делает, в таком случае да — нет смысла вкладываться. А представьте, что вы были бы в первой сотне сотрудник гугла например, тоже бы работали с 9 — 18 не вкладываясь? Кто тогда вложился сейчас зарабатывают миллионы. Поэтому я написал, что компании повезло, если они такого наняли.
                                                          В общем разные бывают ситуации, я бы не был так категоричен насчет "своего" и "чужого", некоторые люди берут чужое и делают своим.

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

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

                                                            я бы не был так категоричен насчет «своего» и «чужого», некоторые люди берут чужое и делают своим

                                                            В 90-е и начало нулевых это была распространенная тема, придти и отжать чужой бизнес :))) Шучу, конечно, я понимаю про что вы, но это все-же очень нечасто бывает. Во первых нужны совсем другие таланты, чем есть у основной массы разработчиков, во вторых в партнеры пускают обычно очень неохотно, для этого нужны какие-то ну очень большие заслуги, и с такими талантами и работоспособностью — возможно имеет смысл не прилипать к чужому, а запилить свой бизнес, в котором ты изначально владелец, а не наемник?
                                                        +1
                                                        Прочитал, как всегда занимательно и хорошо написано. Многое знакомо. Но почему у ваших тимлидов денег не больше? За вредные условия труда обычно доплачивают :)

                                                          0

                                                          -

                                                            0

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


                                                            Мол, представляете?! Эта штука может крутить пять тысяч оборотов, а из-за плохого управления 80% времени крутит только на три!

                                                              0

                                                              Ага, только перед этим он словно прокатился под капотом Тесла, увидел там багажник, и теперь правда не понимает, зачем там где у Теслы багажник, тут рычащее ДВС с 3% КПД

                                                                0

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

                                                              –3
                                                              програмирование настолько не вписываеца в привычные производственные отношения, что руководство по их управлению называеца — психбольница в руках поцыентов
                                                                0
                                                                Потому тимлидом и не может быть абы кто.
                                                                  0
                                                                  Все абсолютно в точку. Я работал в больших и малых конторах как в России, так и за границей, и все описанное в статье абсолютно точно отражает ситуацию по всей отрасли. Хороший тим-лид — это удача и редкость, в результате которых на выходе работающий продукт и довольные разрабы.

                                                                  P.S. И да, если у вас есть хороший тим-лид ни в коем случае не скупитесь, платите ему много, даже так: МНОГО.
                                                                    0
                                                                    «костыли, вместо решений»..? Зачем запятая? Ведь явно не по-русски! Если стараться быть корректным к коду, то и языку страны проживания это же относится..!
                                                                      +1
                                                                      Авторская орфография.
                                                                      Сетует на костыли, выделяет их запятой. Это статья — речь в письме.
                                                                      Просто проговорите ее про себя, как написал автор
                                                                      0
                                                                      Похоже это ответ на вопрос который меня мучит на каждой работе, «а почему меня до сих пор не уволили?»
                                                                        0
                                                                        >Я не идиот, мои идеи не крутятся вокруг ценностей бизнеса

                                                                        Зачем ты тогда нужен бизнесу?
                                                                          0

                                                                          А вся наша жизнь тоже только вокруг ценностей бизнеса крутится?

                                                                            –1
                                                                            Утрировать не нужно.
                                                                              0

                                                                              Так а вы чем занимаетесь?

                                                                                –1
                                                                                Разговариваю с идиотом?
                                                                                  0

                                                                                  Похоже, что я поговорил с троллем.


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

                                                                                    –1
                                                                                    Очень высокоуровневый подход.
                                                                                    Teamlead должен понимать как его решения отразятся на скорости поставки, на стабильности продукта, на безопасности продукта (и так далее). Это есть думать об интересах бизнеса.
                                                                                    Искренне ваш, тролль.
                                                                                      0

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

                                                                            +1
                                                                            Зачем ты тогда нужен бизнесу?


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

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

                                                                                На мой взгляд именно для этого совсем не обязательно быть инженером или программистом.

                                                                                А то потом эти «я же не технический специалист» форвардят нетехнические вещи техническим специалистам, типа списка требований — разбирайся, не я ж программист.

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

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

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


                                                                                    На дэйли они у нас вообще не появляются и там в скрам-командах у нас ПО, а в остальных тимлиды.

                                                                                      0

                                                                                      Пообщаться с заказчиком, выбить из него в более-менее внятной форме хотелки. Преобразовать эти хотелки в ТЗ. Составить табличку/Ганта/что-там-еще используется с оценкой трудозатрат, сроков, рисков, и т.п. Оценить "проблемность" заказчика, если она слишком выска — донести свое мнение до руководства. Составить смету, быть готовым защищать ее перед заказчиком. Понимать, где можно "прогнуться" по срокам, стоимости, и т.п., а где — нет. Составить договор, подписать у всех. После запуска проекта в работу информировать заказчика о ходе проекта, превращая "нет, у нас нет ресурсов за запуск этой задачи сегодня" в "да, конечно, ради вас мы подвинем недельный план загрузки нашей команды и сможем запустить вашу задачу в кратчайшие сроки, то есть послезавтра". Отслеживать внутренний статус по проекту, пытаясь понять, где всё ок, а где есть риски срыва сроков. Настучать по голове разрабу, который в обход штатных каналов связи закорешился с админом клиента и они там решили, что лучше сделать не как в ТЗ, а по-другому. Разрулить эту ситуацию (варианты могут быть сильно различны). Отбиваться от бесконечных "вчера в 17.59 мы прислали список необходимых доработок на 5 страниц, почему сегодня к 10.00 ничего не готово?". Заставить тимлида заменить верстальщика, потому что стажер, которого поставили, "потому что остальные заняты на других проектах", с этим проектом точно не справится в срок… Продолжать дальше, или картина в общем и целом понятна?

                                                                                    +1
                                                                                    я еще больше согласен с коллегами. И насчёт нефти не соглашусь. Кто-то, не помню точно, то ли Шевченко, то ли Караулов целое кино про это снял. Как управленцы — сынки больших людей один миллиардную шахту водой залил, другой весь газ из трубы растерял. Они даже были названы в произведении «стратегической угрозой для страны». А тоже ведь «не про это», вроде как, а про управление. Другая тема — госуправление. Вот ни разу не протестовал бы против, если бы приняли закон, что каждый госслужащий начиная с муниципального уровня должен год в армии, год в колхозе и год на заводе отпахать. Точно не повредило бы.
                                                                                    0
                                                                                    Тут «фишка» в том, что должен быть и «с низов» и с талантом управленца, чтобы команда функционировала правильно. Цитируя автора статьи — это лотерея.
                                                                                      0
                                                                                      где-то тут или в окрестностях вероятность «талант управленца» была оценена в 1/10, с выходцем из низов, где вероятность, конечно, намного выше, скажем 1/2, тогда вероятность такого сочетания составляет пять процентов. Прямо скажем…
                                                                                        0
                                                                                        Моя практика показывает, что так и есть: грамотный тим-лид встречается крайне редко. А что говорит ваш опыт?
                                                                                          0
                                                                                          В пяти из семи мест, где я работал, лиды (хотя они и не везде так назывались) были как минимум выше среднего уровня, в двух — просто близки ко всем мыслимым и немыслимым идеалам.
                                                                                            0
                                                                                            Ну так всё правильно. На десять толковых разрабов один потенциально талантлив в управлении. На те же десять толковых разрабов, один-два хотят в управление. Если эти подмножества коррелируют(по идее должны) — то на выходе мы получаем что в среднем большая часть тимлидов как минимум нормально справляются. Если бы множества НЕ коррелировали, или коррелировали отрицательно — тогда, по идее, толковых тимлидов было бы ещё меньше, чем пять процентов)
                                                                                    +1
                                                                                    Кликбейтный заголовок, да еще с очень спорным заялением. Маркетологи заставили? :)
                                                                                      0
                                                                                      У нас недавно завезли Скрам. Собрали значит человек 30 в конфу и сказали — ща будем делать спринт. Похрену мороз что вы друг друга не знаете и общих дел не имеете, заодно и познакомитесь. Давайте эстимейты. Поковырялись в носу, что-то выдали. Попало значит в «спринт» штук 5 разных проектов из разработки, разного рода миграции баз данных и прочих задач по саппорту до кучи. Естественно про поддержку даже не заикались, т.к. если трех разработчиков да еще с отпусками размазать на техподдержку то вообще печаль будет. А так — выглядит красиво, так и поплывем. Идет время, появляется вопрос а че это разраб в Нью-Йорке делает больше чем вся команда в Праге. А как мерили — ну ессно стори поинтами. То что проект и оценка не гомогенная — отставть нецензурщину. Ну ок, давайте ноль припишем справа. Отставить ноль справа, скоуп спринта нельзя менять как все утверждено. А спрашиваю как так получилось что переписать легаси приложение на современный стек с дремучими хранимками и без единого фронтенд разраба в команде «стоит» всего 5 стори поинтов — а хз. Посмотрели на другие твои задачи и поставили также.
                                                                                        0
                                                                                        Что-то мне кажется, что у вас и до скрама бардак в команде был. И скрам сделали бардаком. То, что на выходе получился не скрам, а бардак — уже закономерность.
                                                                                          0
                                                                                          Мне очень интересно из каких предпосылок вы сделали вывод про бардак до. У нас была команда 5 разработчиков + аналитик, прекрасно работали по Канбану еще за три года до того как компания решила быть «Аджайл». Канбан по причине того, что в зоне ответственности находтся больше 10 проектов и периодически всплывает легаси 5-10 летней давности. Только за прошедший год мы выпустили 4 новых проекта и это при параллельной поддержке ежедневной текучки. С начала этого года нам не согласовали ни одного нового разработчика в команду, видимо руководствуясь принципами — «ниче не падает — значит у них был избыток в людях» (а люди уходят). Чисто для справки, один проект по ошибке попал нам и соседней команде (менеджер накосячил). Так получилось что наши темпы оказались в 4 раза выше при том что количество вовлеченных разработчиков было одинаково.
                                                                                            0
                                                                                            Я не про команду разработки, уверен вы хорошо делаете свое дело, но то что вы написали — это форменный бардак
                                                                                              0
                                                                                              К сожалению вы абсолютно правы :( Менеджмент сфокусирован на «перестановке кроватей» и на «продаже успеха». В последнем они достигли такого мастерства, что мне порой кажется они могут продать как успех даже когда жидко обделываются. Слово «проблема» я не слышал ни разу (!) за все время работы в компании. Пока активно не мешали с этим можно было мириться, команда все-таки (была) достойная. А сейчас пошел по рукам интервью.
                                                                                        0
                                                                                        А зачем вообще пытаться «управлять программистами»?
                                                                                        По мнению автора программисты — это «нечто» не\управляемое?
                                                                                          0
                                                                                          короче все это надо что бы размазывать ответственность
                                                                                          а размазывать ответственность надо потому что никто не готов платить полную цену за труд с полной ответсвенностью
                                                                                            0
                                                                                            В Москве средняя ЗП разраба 130К, опять мало?
                                                                                              0
                                                                                              это очень рядовая зарплата очень среднего мидла. И «средняя» тут для оценки всего рынка не подходит, потому что распределение не симметричное и медиана не совпадает с матожиданием.
                                                                                                0
                                                                                                есть еще обратная сторона
                                                                                                не каждый может и хочет работать с полной самоотдачей
                                                                                                но на мой взгляд в индустрии перекосы чаще идут в минус работнику
                                                                                                наверное потому что еще живо постсоветское наследие
                                                                                                и потому что в индустрии много молодых работников с максимализмом,
                                                                                                тут нужно быть профессионалом что бы четко своевременно размежевывать
                                                                                              –1
                                                                                              вот это шок контент

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

                                                                                              а для работы с людьми, где 1 может быть равно, в зависимости от контекста, времени, фазы луны и еще 1000 и 1 фактора — двум, пяти, яблоку и даже ржавому баргузину надо тоже учиться
                                                                                                +1
                                                                                                Филипп, почему у вас все статьи такие депрессивные? :)
                                                                                                  +1

                                                                                                  Оптимизм менее кликбейтный

                                                                                                    0

                                                                                                    А чего радоваться-то?

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

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

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

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

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


                                                                                                      «Роли, артефакты, правила и события Скрама не подлежат изменению. Хотя использование отдельных элементов данного фреймворка допустимо, но полученный результат не может называться Скрамом.»
                                                                                                      То есть, если выкинута роль, это не Скрам. В данном случае одна из ключевых ролей — «Владелец продукта». Единственный, кто управляет Бэклогом. «Никто не может заставить Команду Разработки работать над другим набором требований».

                                                                                                      www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Russian.pdf
                                                                                                        0
                                                                                                        Все правильно, не собирался обсуждать эту роль, поэтому ее и опустил для простоты. Мой комментарий ни в коем случае не полный, там очень все поверхностно, только чтобы обозначить несколько серьезных проблем.
                                                                                                      0
                                                                                                      Вопрос — вы читали «Как пасти котов»?
                                                                                                        0
                                                                                                        Я пожалуй бы поспорил с выводами. Идея то как раз в том, чтобы менеджер мог работать с той командой что есть. Это сложно, но если не выходит — все дело просто в квалификации этого менеджера. Лично был свидетелем когда на запущенный проект пришел новый прожект менеджер в команду 30 человек работающую через пень-колоду как расписал автор, куча претензий пользователей к системе, но он исправил работу(при это никого особо не напрягая). Выглядело это как магия, когда люди неожиданно начали любить систему, пользователи стали благодарить и прочее. Но такое случилось лишь однажды, негативных примеров гораздо больше

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

                                                                                                        Самое читаемое