Комментарии 103
При нормально построенных процессах, статистические значения внезапно оказываются весьма и весьма верными.
Так что у «нормально построенных процессов», которые опираются именно на статистические значения перспектива — перестать со временем быть нормальными. А это означает, что руководству, чтобы не терять эффективность, по-любому придется подходить к своей работе творчески, а не шаблонно, работать с людьми, а не с процессами и т.д., и т.п.
Фокус в том человеке, который эти самые процессы сумел во-первых нормально построить, и во-вторых поддерживать, отражая в них изменения окружающего мира. Таких людей мало, и именно по этой причине компаний/проектов с нормально построенными процессами тоже мало — без этих людей, чисто механически, эти процессы не воспроизводятся в соседней компании/проекте. Просто потому, что там другой окружающий мир и нет никого, кто в состоянии адекватно адаптировать под это процессы.
Фокус в том человеке, который эти самые процессы сумел во-первых нормально построить, и во-вторых поддерживать, отражая в них изменения окружающего мира. Таких людей мало, и именно по этой причине компаний/проектов с нормально построенными процессами тоже мало — без этих людей, чисто механически, эти процессы не воспроизводятся в соседней компании/проекте. Просто потому, что там другой окружающий мир и нет никого, кто в состоянии адекватно адаптировать под это процессы.
Очень правильная мысль на мой взгляд. Только дело даже не в адаптации этих процессов под конкретную окружающую среду, сколько в контроле над этими процессами. В их поддержании. Это как вырастить дерево. Прежде чем дерево вырастет, окрепнет и начнет самопроизводство, когда его можно оставить без присмотра — надо достаточно много усилий приложить ухаживая за ним. Поливать, подвязывать, следить чтобы прижилось и вредители не погубили.
И к сожалению не так много людей, которые умеют это делать, именно так взращивать процессы. Больше тех, кто думают — а вот посажу дерево, а оно само вырастет. Практика показывает — что чаще засыхает, без постоянного контроля. А это достаточно утомительно и отнимает много сил.
В разработке это было бы как в армии или церкви, каждая команда из пяти рядовых, над ними team lead (политрук) и tech lead (командир). Ну и скорости движения вперёд, раза в три меньше чем сегодня.
Так что получается что даже хреновая аджайльная команда выходит дешевле чем предсказуемая. А с командами где всё отлично, то согласен, лотерея. Но и не последняя заслуга менеджера, как это не странно звучит.
Если повезло и менеджер правильный, т.е. не босс, а лидер, то разрабы это ценят. Который грудью защищает команду от бреда из внешнего мира и при этом не туп. И чем лучше разраб, тем выше он это ценит и будет держатся за команду. Так что в такой команде синергия между инь и янь разработки.
Вы политрука с командиром местами случайно не спутали?
Политрук поддерживает моральный дух и т.п., ну и смотрит за командиром, чтобы в иделогически правильном направленни вёл бойцов.
Как мне кажется это больше тимлид.
В каждой конкретной команде это может быть поразному, но в целом думаю что как-то так. Проблема в том что большинство компаний оптимизирует и имеют либо только техлида, который заодно исполняет функции тимлида. Либо только тимлида, который и техлид.
А вот на мой взгляд, это беда, когда стратегию определяет тех.лид. Технологии важны, но не до такой степени.
А вот совмещение ролей, в целом, не самая большая проблема. Это роли, а не должности, не страшно, если один человек выполняет сразу несколько — по крайней мере пока он их разделяет у себя в голове и отдаёт себе отчёт в происходящем.
Адекватно определить, хорошо ли работает разраб может только разраб.
Это так на уровне тимлида, но зачем при этом в статье куча ереси про управление в целом — непонятно. Уже ПМа вообще не интересуют вещи типа качества кода (разве только факультативно), его интересует одно — способна команда выполнять задачи с предсказуемо хорошим качеством в нужные сроки или нет. И для этой оценки, вообще говоря, не нужно обладать квалификацией разработчика.
Вот ответы в каждой конкретной ситуации на вопросы "почему так" и "что делать, чтобы изменить ситуацию в лучшую сторону" как раз и входят в профессиональную компетенцию менеджера (в том числе понимание, какие из них относятся к прямому управлению программистами и относятся к компетенции тимлида, а где надо решать самому). Но для этого не нужно уметь самому писать код или даже заглядывать в него.
Бэкграунд разработчика может помочь в понимании происходящего, но не является обязательным. Более того — он может и помешать, ибо стимулирует закапывание в совершенно неважные для этого уровня управления детали. Фактически одна из вещей, которые специалисту (любому, не обязательно разрабу) приходится делать, если он хочет сменить сферу деятельности на менеджмент — придушить в себе специалиста. :) Это особенно тяжело, когда являешься специалистом высокого уровня, видишь косяки на уровне исполнителей, понимаешь, что сам мог бы сделать лучше/быстрее и т.п. Но регулярные влезания на уровень исполнителя самому, увы, ведут в тупик.
ПМа вообще не интересуют вещи типа качества кода
его интересует одно — способна команда выполнять задачи с предсказуемо хорошим качеством
А «качество кода» — это не «качество» разве? Разве его не иснтересует, насколько сложно будет поддерживать и доработатывать решение в дальнейшем?
Качество исполнения задачи в понимании ПМа — реализация заданного функционала в заданные сроки. Что там внутри — его таки да, не особо интересует. А качество кода — это не цель, а всего лишь средство (одно из) для достижения конечной цели. Вот самого разработчика оно должно интересовать, тимлида — тоже, а вот ПМа — уже нет.
Приведу пример. Существует понятие доказательной медицины. Оно предполагает, существование чётких статистически значимых доказательств эффективности. Современная доказательная медицина содержит в себе например такое понятие как двойное слепое плацебоконтролируемое исследование.
Собственно существуют ли аналогичные исследования эффективности для таких методологий как Аджайл, Канбан, Скрам?
Просто, если таких исследований нет (ну ладно, кого я обманываю, не «если», а «поскольку»), то может не стоит воспринимать рекомендации из методологий буквально как воинский устав? Может стоит относится к ним как к просто набору частных рецептов, которые могут быть найдены полезными в таких же частных ситуациях.
Не воспринимать буквально — отличная идея да. Но тогда ведь придется самим думать, и если облажаешься — не на что сослаться будет. А так — все делают по аджайлу, и ты делаешь. И никакого с тебя спроса
Так тут — типичная история. Те кто прочитал инструкции (исследования) — знают когда работают те или иные лекарства или подходы. А те, кто не прочитал, но употребляют их или предлагают другим — ССЗБ. Так и с методиками этими — люди видят очередную рекламу методики (или таблетки "от головы") и свято верят в её действенность. Потому и творится такое мракобесие. Те же Скрам и Канбан уже давно нашли нишу, где доказали свою эффективность. Но часто их притаскивают для тех задач, где они бесполезны. Отсюда и недоверие.
Немного в сторону, но емнип, Скрам — частный случай Аджайла. А Аджайл в целом — не устав и не протокол, а набор рекоммендаций и инструментов. Суть как раз в том, что определенные инструменты и рекоммендации работают для определенных команд. Не стоит натягивать процессы и риуталы как ужа на ежа, если они не работают. Например, ретроспективы для команды асинезаторов — не самая удачная идея — все равно было говно и будет говно.
В Скрам гайде написано: если вы не соблюдаете описанные здесь правила, то у вас не Скрам.
Поэтому, если вы считаете, что команда ассенизаторов работает по Скраму, но исключили ретроспективу — то все, у вас уже не Скрам, а некая самоизобретенная скрамоподобная техника.
существует ли исследование честно доказывающее их пользу?Если люди не хотят работать — ничего не поможет. Доказано — нет таких методологий, которые заставят разработчика работать. Если люди хотят работать, тогда всё, что нужно делать — убирать препятствия с их пути. Это и есть про скрам.
ITT миллениалы мечтают о программной инженерии.
По-моему жира — это просто коллективная записная книжка, чтоб не забыть, что мы делаем и что покажем через две недели.
Ну ок. Никто не умеет. А делать-то что?
Примерно все тоже самое относится ко всем прочим индустриям. Если человек никогда не работал на заводе, то он будет херовым управленцем завода. Если человек никогда не занимался спортом, то из него выйдет херовый тренер.
И если у человека нет таланта к управлению, или у него слишком высокое ЧСВ, то он опять же чисто по человеческим качествам будет херовым управленцем, даже если он из своей индустрии.
Поэтому неэффективные менеджеры есть везде, также как есть и эффективные, которые даже если пришли не из индустрии, то ставят ещё прослойку-менеджера из индустрии.
Подставьте вместо "индустрия" любой вид деятельности и все останется правдой.
Задача менеджера — гасить в себе энергию жесткого излучения, которые испускают менеджеры верхнего уровня, и защищать этим инженеров от губительной радиации, создавая им биосферу, пригодную для интеллектуальной работы. Дальше выводим так:
Плохой менеджер — всепропускающий фильтр, сам не нагревается, зато команда сгорает, или вынуждена тратить усилия на индивидуальную защиту от излучения — какая уж тут работа над продуктом. Хороший менеджер — нагревается сам от внешних лучей, плюс поглощает энергию изнутри коллектива — и этим медленно сгорает за деньги и за дело. Больше ничего — джиры, скрамы итд — все это вторично или третично уже. Возьмите, если не армию, то, например, экспедицию — и выведите, каким должен быть хороший руководитель экспедиции, а какой будет плохим. Получатся чисто человеческие качества, без Джир. В айти так же. То есть ищите Человека.
Менеджеры бывают разные. И набирают их для разного.
Одни нужны для того, чтобы карточки в джире передвигать (просто потому, что передвигания стало настолько много, что требуется целая позиция под это).
Другие нужны для того, чтобы регулярно собирать информацию о состоянии дел и кратко излагать ее руководству и комманде.
Есть еще те, кто должен из разрозненных векторов устремлений толковых тех. лидов и инженеров формировать один. Ну чтобы толковые специалисты не нейтрализовали друг-друга.
Кроме того, бывают всякие человеческие потребности. Кто-то запил, у кого-то сезонное обострение, у кого-то с женой скандал, кто-то не хочет разговаривать с коллегой. Похвалить, вдохновить, ободрить, пожурить, припугнуть, уволить. Сюда же пожалуй можно включить то, что gleb_l упомянул.
Ну и пунктик, который очень часто забывают. Людям нужно развиваться. Навыки, карьера. Зачастую нужен ментор или просто тот, кто укажет направление.
В теории это довольно простые вещи. Но вот на практике для своего эффективного воплощения они требуют соблюдения ряда условий. Необходимым условием является наличие развитого и тренированного ума у руководителя. Причем совершенно не важно, на чем был прокачан этот ум, важно чтобы это не был ум ботана с гипертрофировано развитым одним участком мозга и атрофированной остальной частью. Достаточным же условием является требование познания себя. В первую очередь развитие навыка быть всегда честным перед самим собой. Потому что с комплексами и стереотипами (тараканами в голове) управление людьми превращается в полет на самолете с неисправными датчиками, гарантированно ведущим к аварии с жертвами.
С этой точки зрения описанное в статье использование различных методик и инструментов свидетельствует о банальной ситуации дураков во власти, которая лечится исключительно хирургическими способами.
Руководить — это значит не мешать хорошим людям работать", — сказал академик Петр Капица. И я с ним согласен. Задача руководителя — найти и взростить "хороших" людей, — это тех, кто хочет работать. Создать для них питательную среду и дать индивидуальную для каждого — мотивацию. А для этого надо быть не просто руководителем, но ещё и лидером. В целом согласен со статьей.
2. Простого управления недостаточно, нужна определенная философия под
свой стиль работы.
3. Нет сближения на эмоциональном уровне — нет эмпатии и в совместной
работе. Команда профессионалов или семья? Семья, профессионалами они станут
довольно быстро и дружно
Маленькие и эффективные команды я видел только в стартапах, где состав был из прямых выгодополучателей бизнеса, и скреплен чем-то общим, например это основатели, их друзья, пришедшие сразу после старта, или братья, сестры. Таких людей не надо мотивировать, они готовы работать в любое время суток и выстраивать продукт используя только github. Готовы сапортить стенды по выходным и быть сейлзом вместе с разработкой. Но наступает момент когда бизнес растет и надо брать "наемных", именно в негативном смысле. Эти люди приходят не развивать продукт или бизнес, а приходят развивать себя, чтобы через год продаться дороже в место получше, а так же просто заработать денег. Чтобы заставить их работать есть целый завод из софта и людей, который приходится строить. Чаще всего просходит, как Фил написал, и в команде из 10 работать хотят 1-2 человека. Да и быть эффективным и быстрым в большой компании в целом сложно, там квартальные планы, бюждеты, интеграция с другими продуктами, которые еще более слоупоки чем вы, и всё такое.
А выграть в лотерею, я считаю можно в 2 случаях:
- Когда вы наемный и попали на хорошего руководителя
- Когда вам удалось нанять человека, которому реально интересен продукт и его развитие
Оба события это вероятность 1/10
Эти люди приходят не развивать продукт или бизнес, а приходят развивать себя, чтобы через год продаться дороже в место получше, а так же просто заработать денег.
С точки зрения наемного работника это оптимальная стратегия. Какой смысл вкладываться в развитие чужого продукта и чужого бизнеса?
Сегодня ты горишь на работе, весь выкладываешься на все 500%, относишься к делу как к своему собственному, а завтра тебе отвешивают пинка под зад, потому что в бизнесе проблемы, и платить тебе твою з/п они больше не могут (не хотят), и ты весь сгоревший идешь искать новый проект…
Ты наемный работник — твое время оплачено с 9 до 18, с перерывом на обед, все, точка.
Смысл в том, что ты можешь подняться из простого наемного программиста либо в ключевую позицию либо стать партнером. Но это только если ты прям хочешь именно этим заниматься и видишь перспективы у компании, иными словами сам бы делал тоже самое. Часто разработчики говорят что им не нравится их продукт и компания не понимает что делает, в таком случае да — нет смысла вкладываться. А представьте, что вы были бы в первой сотне сотрудник гугла например, тоже бы работали с 9 — 18 не вкладываясь? Кто тогда вложился сейчас зарабатывают миллионы. Поэтому я написал, что компании повезло, если они такого наняли.
В общем разные бывают ситуации, я бы не был так категоричен насчет "своего" и "чужого", некоторые люди берут чужое и делают своим.
Я не буду говорить за всех, конечно, но вот лично я вкладываюсь в какой-то проект больше оговоренного в контракте только когда мне он сам по себе интересен, какие там у него бизнес перспективы — я в этом мало что смыслю, да и для такой оценки надо обладать куда как большим количеством информации, чем обладает обычный разработчик.
я бы не был так категоричен насчет «своего» и «чужого», некоторые люди берут чужое и делают своим
В 90-е и начало нулевых это была распространенная тема, придти и отжать чужой бизнес :))) Шучу, конечно, я понимаю про что вы, но это все-же очень нечасто бывает. Во первых нужны совсем другие таланты, чем есть у основной массы разработчиков, во вторых в партнеры пускают обычно очень неохотно, для этого нужны какие-то ну очень большие заслуги, и с такими талантами и работоспособностью — возможно имеет смысл не прилипать к чужому, а запилить свой бизнес, в котором ты изначально владелец, а не наемник?
-
Словно человек прокатился под капотом автомобиля и хочет теперь поделиться какой бардак там происходит. А те, кто считает, что они чем то там управляют натягивая тросик, глубоко заблуждаются.
Мол, представляете?! Эта штука может крутить пять тысяч оборотов, а из-за плохого управления 80% времени крутит только на три!
P.S. И да, если у вас есть хороший тим-лид ни в коем случае не скупитесь, платите ему много, даже так: МНОГО.
Зачем ты тогда нужен бизнесу?
А вся наша жизнь тоже только вокруг ценностей бизнеса крутится?
Так а вы чем занимаетесь?
Похоже, что я поговорил с троллем.
На самом деле ведь ценность бизнеса это делать людям хорошо, удовлетворяя их потребности и решая их проблемы, а за это получая положенное вознаграждение, которое можно тратить на расширение, чтобы делать еще большему числу людей хорошо. Но часто под ценностями бизнеса понимается сиюминутная выгода, которую нужно максимизировать любой ценой.
Зачем ты тогда нужен бизнесу?
Предполагаю — для того, чтобы выполнять свою роль в производстве тех ценностей, которые бизнес предоставляет своим потребителям. И это, вообще говоря — другие ценности, а не то, что считают ценностями своего бизнеса его владельцы (и уж тем более — не то, что называется «ценностями бизнеса» пиарщиками).
Так вот, для производства ценностей для потребителя бизнесу нужны наемные работники, которые этим производством занимаются. В том числе — и программисты. И ценности этих наемных работников — это не ценности бизнеса, как бы ни пытался убедить их dв обратном внутрикорпоративный пиар. Ценности наемных работников — это получаемая ими компенсация, условия труда (интересные задачи — это тоже часть условий труда) и возможности повышения своей ценности на рынке труда. Ну, а приоритеты пусть каждый расставит для себя сам.
В Японии не зря будущие управленцы чуть ли не у каждого станка должны постоять. А то потом эти «я же не технический специалист» форвардят нетехнические вещи техническим специалистам, типа списка требований — разбирайся, не я ж программист. Ну а я ведь и не прошу код за меня писать, а требования на логичность проверить — язык программирования знать не надо.
Просто по очереди объявлять кто следующий говорит на дэйли, балластом присутствовать на всех митингах и спрашивать каждые 5 минут будет ли сегодня билд?
Пообщаться с заказчиком, выбить из него в более-менее внятной форме хотелки. Преобразовать эти хотелки в ТЗ. Составить табличку/Ганта/что-там-еще используется с оценкой трудозатрат, сроков, рисков, и т.п. Оценить "проблемность" заказчика, если она слишком выска — донести свое мнение до руководства. Составить смету, быть готовым защищать ее перед заказчиком. Понимать, где можно "прогнуться" по срокам, стоимости, и т.п., а где — нет. Составить договор, подписать у всех. После запуска проекта в работу информировать заказчика о ходе проекта, превращая "нет, у нас нет ресурсов за запуск этой задачи сегодня" в "да, конечно, ради вас мы подвинем недельный план загрузки нашей команды и сможем запустить вашу задачу в кратчайшие сроки, то есть послезавтра". Отслеживать внутренний статус по проекту, пытаясь понять, где всё ок, а где есть риски срыва сроков. Настучать по голове разрабу, который в обход штатных каналов связи закорешился с админом клиента и они там решили, что лучше сделать не как в ТЗ, а по-другому. Разрулить эту ситуацию (варианты могут быть сильно различны). Отбиваться от бесконечных "вчера в 17.59 мы прислали список необходимых доработок на 5 страниц, почему сегодня к 10.00 ничего не готово?". Заставить тимлида заменить верстальщика, потому что стажер, которого поставили, "потому что остальные заняты на других проектах", с этим проектом точно не справится в срок… Продолжать дальше, или картина в общем и целом понятна?
По мнению автора программисты — это «нечто» не\управляемое?
а размазывать ответственность надо потому что никто не готов платить полную цену за труд с полной ответсвенностью
не каждый может и хочет работать с полной самоотдачей
но на мой взгляд в индустрии перекосы чаще идут в минус работнику
наверное потому что еще живо постсоветское наследие
и потому что в индустрии много молодых работников с максимализмом,
тут нужно быть профессионалом что бы четко своевременно размежевывать
оказывается для работы с кодом, где более-менее всегда 1 = 1 надо учиться (при этом многие разработчики любят подчеркнуть, что это бесконечный процесс)
а для работы с людьми, где 1 может быть равно, в зависимости от контекста, времени, фазы луны и еще 1000 и 1 фактора — двум, пяти, яблоку и даже ржавому баргузину надо тоже учиться
При этом на Хабре рассуждать про управление достаточно неуместно, т.к. участники обсуждения слишком разные, чтобы донести свою мысль (а уж чтобы еще и мысль понравилась (из-за голосований), так вообще непонятно зачем).
Если совсем поверхностно, то уже существуют методологии, которые решают проблему сложности нахождения технических менеджеров. Например, не к ночи упомянутый Скрам. Там нет понятий менеджер, пм, тимлид и техлид. Есть плоская команда и скрам мастер. Скрам мастер — это скорее помошник-психолог (без ИТ образования), чем менеджер или технарь, т.к. она только организовывает процессы и разрешает личностные конфликты. Вместо техлидов возможны гильдии и коучи гильдий — при этом они не менеджеры и не техлиды.
При этом при типичном внедрении Скрама почему-то остаются менеджеры и техлиды. И Скрам не работает (или работает), хотя его даже не пробовали.
И понятно, что это не панацея, и нужно смотреть на конкретную компанию, чтобы понять как улучшить там процессы. Другое дело, что у кого-то не хватает знаний, где-то менеджеры боятся ухудшить текущую ситуацию, где-то что-то еще, но это не значит, что все случайно, и системного подхода не существует.
Есть плоская команда и скрам мастер
«Роли, артефакты, правила и события Скрама не подлежат изменению. Хотя использование отдельных элементов данного фреймворка допустимо, но полученный результат не может называться Скрамом.»
То есть, если выкинута роль, это не Скрам. В данном случае одна из ключевых ролей — «Владелец продукта». Единственный, кто управляет Бэклогом. «Никто не может заставить Команду Разработки работать над другим набором требований».
www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Russian.pdf
Ну вот прям секрет Полишинеля открыли: разработчиков в индустрии не хватало и не хватает. Закономерный вопрос: откуда управленцы в достаточном количестве возьмутся то? Типа, их меньше надо? Ну так и срок обучения, тоже побольше будет. Всю цепочку подготовки кадров со школьной скамьи пересобирать нужно, чтобы ситуацию поменять. Государство наше этим заниматься не хочет. Ничего, бизнес занялся… поживем-увидим
Никто не умеет управлять программистами — и все придумывают костыли, вместо решений