Comments 112
Очень добро написано, понравилось!
Главное, чтобы остальные участники процесса разделяли вашу оценку. У меня был коллега, который считал себя интеллектуальным центром команды, занимался, в основном, критикой и "наставничеством", как он это называл, но, когда по требованию менеджмента его перевели в другую команду, скорость и качество разработки заметно возросло. Интеллектуал же остался уверен, что с ним обошлись крайне несправедливо.
Я не говорю, что вы можете быть таким же человеком, просто очень полезно иметь какой-то объективный способ оценки собственной деятельности, если обычные KPI и метрики к вам по какой-либо причине неприменимы. Иначе самооценка может подвести в самый ненужный момент.
просто очень полезно иметь какой-то объективный способ оценки собственной деятельности
Вам объективный или решающий проблему? Это не всегда одно и то же. Есть же вот:
за меня теперь говорят остальные члены команды.
за меня теперь говорят остальные члены команды
это работает до тех пор, пока команду не накроет что-то подобное эффекту Рингельмана
О, у нас такой был! Он ещё выглядел как гуру, борода, длинные волосы, высокомерный взгляд. Диспуты устраивал на тему number/string. Правда, продукт пилил медленнее захудалого миддла
А что, если он как садовник поливал семячко, которое долго не всходило, дало маленький росток, потом садовника убрали и растение выросло и расцвело) Сложно так оценивать, команда может подняться в какой-то определённой момент, но до этого могло происходить не бесполезное обучение и рост, чтобы к этому прийти.
за меня теперь говорят остальные члены команды.
А вот это максимально странно. Обычный разработчик не очень любит говорить. У вас есть специальный человек у которого вся работа это говорить. И он почему-то не говорит.
Выглядит так что ему не на дейлики ходить надо, а выступления побольше и пореже готовить. От защит новых проектов и рефакторинга с разными архитектурными решениями, до рассказов как все хорошо поработали и почему надо выдать премию.
когда нужно что-то спроектировать, поревьюить, разобраться в требованиях, помочь реализовать, решить проблему, которую никто не может решить
Что мешает заводить тикеты в жире на эти задачи?
Ну кроме как тикеты на ревью, они не нужны, да и ревьюить должен не один человек у всех, а все, включая джуниоров.(В смысле, не вся команда каждый PR, а один-два-три ревьювера на PR, но разные люди, а не всегда один и тот-же человек).
спрашивать у меня на дейликах "а что ты вчера сделал?"
Забавно: почему то обратил внимание в комментарии именно на это.
У нас на Дейли не спрашивают о вчера, а делятся планами на сегодня и завтра. Для observability и transparency внутри команды. Когда открывается новый спринт, мы все делаем короткий бриф о планах. А потом ежедневно его корректируем и делимся с членами команды . Но уровень команды высокий. Очень высокий. И менеджмента тоже.
Может быть в этом дело.
Верно. Если на дейликах нужно рассказывать, что делал вчера - вопросы к прозрачности.
Как вы узнали, что уровень команды "очень высокий"?
А если я вчера брал задачи, делал. И даже доделал все что брал.
Разве у меня не будет только один план - "брать(с доски) и делать"?
Ну или у меня проект, но текушие задачи вроде всё, просто там осталось только "посмотреть\подумать что теперь делать"(ну рефакторинг, общение с заказчиком\начальником, уточнение требований, и т.д.)?
Звучит так, будто надо всеми силами показать бурную деятельность.
Ад для чоциофобов какой-то.
На самом деле это же применимо ко многим другим метрикам. Например, у нас пытаются измерять time to market, при этом измеряльщики упорото считают, что ежели я завел в Jira задачу 1 января, открыл, и отложил на год, а реализовал 31 декабря, то TTM будет год. При том что совершенно очевидна возможность появления 2 января намного более важных для бизнеса задач, которые в итоге и были сделаны в течение года, и сделаны быстро.
Круче, если поставил задачу 31 декабря, реализовал 1 января, а система пишет, что на неё ушёл год.
Нужно замерять время не от даты открытия задачи, а от даты взятия её в работу, как вариант. Такой вариант сработает?
(Нечаянно поставил минус, компенсировал плюсом на другом комментарии, извини).
Если всерьез, то ttm надо считать от появления идеи у бизнеса - и до появления фичи у клиента. И уже после этого считать время отдельных стадий на пути фичи. Считать же только время разработки - бессмысленно, оно редко является существенным относительно прочих затрат.
Я имел в виду не от начала разработки считать время, а от начала активной работы по задаче.
Т.е. когда задача попала в бэклог задач мы ничего не считаем. Как только мы вытащили её оттуда и начали, условно, аналитику делать - часики начали тикать :)
Считать от появления идеи у бизнеса (читай, от попадания в бэклог) до появления фичи - как будто отдельная метрика, ибо как выше сказали, идея может быть не особо приоритетная и делается по остаточному принципу.
Но ведь задачу могут вытеснить более приоритетной прямо посреди разработки, а потом вообще забыть на полгода.
И с одной стороны эти полгода не должны учитываться в ttm у разработки. Но с другой стороны - должны учитываться у бизнеса, ведь "новые влетающие задачи" могут быть серьёзной проблемой ttm. Особенно если посреди новой задачи влетают ещё более приоритетные.
В результате может получиться, что ttm - месяц, но за год у нас 1 релиз.
Но ведь задачу могут вытеснить более приоритетной прямо посреди разработки, а потом вообще забыть на полгода.
Ну это же ненормальная ситуация, если такое происходит часто. Если же такое случится раз другой - ну ок, увидим это на графиках и поймём, что всякое бывает.
ТТМ - это показатель уровня продукта и рынка, которым все равно на ваш блеклог, другие задачи, менеджмент и состав команд
Так а разве задача, если ее вытеснили, не должна при этом улететь в статус беклог или в on-hold? Для которого метрика по которой ttm считается не будет инкрементироваться
Да, считать "время разработки" вполне осмысленно (если оно составляет больше трети от общих затрат). Я только против называния этого времени time-to-market, так как ttm от разработки зависит очень, очень мало )
Я бы сказал, что вариант зависит от того, что именно мы хотим улучшить. Упрощенно — если ttm большой, потому что у нас не хватает ресурсов, чтобы делать задачи быстрее, и мы это заранее знаем — нас тот факт, что низкоприоритетные задачи лежат в жире годами, вообще никак не удивит, и ничего нового в нем для нас нет. И стоило ли его в таком виде мерять?
Если мы и так все знаем - то это конечно хорошо)
А если нет? Или если мы думаем, что задачи едут месяц, а на деле там по полгода? Ну и в целом, если у нас не хватает ресурсов, то метрики - это доказательство нехватки ресурсов. Хотя может там копнуть глубже и другие причины вскроются.
Но, в целом, согласен - мерять что то, что не несёт для нас новой инфы или то, что мы не сможем интерпретировать/понять/исправить - не нужно
Если мы и так все знаем — то это конечно хорошо)
Не, ну не все конечно… но некоторые вещи достаточно очевидны. Изнутри хотя бы.
По сути, я хотел сказать примерно вот что: что мерять производительность и качество работы человеческого коллектива никогда не было просто. Даже в случае одного человека — описанного тут Тима, мы не знаем точно, что было бы, если бы его скажем убрали. У него была своя роль, вполне допускаю, что нетипичная.
А в чем ошибка измерения TTM? Идея->Реализация->Презентация. Вот и считают время от появлении идеи, до показа клиенту. Естественно, это показатель может быть только общий на всю компанию.
Время от "взял в работу" до презентации - это другой показатель. Вот, даже статью нашел:
https://habr.com/ru/companies/ligastavok/articles/677762/
Вот и считают время от появлении идеи, до показа клиенту.
И как вы это время собираетесь усреднять по всем идеям? Есть идеи и задачи, которые дают эффект отличающийся на пару порядков. Но при этом все они в Jira были заведены, и по ним тоже кто-то считал ttm. Какой смысл в показателе, куда входит время реализации задач, отличающихся по эффекту на сколько-то там порядков? Вы можете спросить, а зачем вы заводите такую мелочь в жиру? Так я вам отвечу — а почему нет? Вам что, жалко места в базе для их хранения? А эти люди, которые стали по ним что-то мерять — они пришли потом, и нам сразу не сказали, что будут мерять вот таким способом. А когда им намекнули, что так мерять может быть глупо, ответили что ничего менять не будут, хотите чтобы у вас ttm хорошо считался — сами у себя меняйте порядки в жире. Ну то есть, это тот случай, когда KPI важнее реальных процессов.
Естественно, это показатель может быть только общий на всю компанию.
Совершенно не естественно. Я вот не вижу, откуда это вытекает, особенно в случае инфраструктурного проекта типа нашего, который на бизнес влияет очень опосредованно. Это не значит слабо — это значит, что это влияние очень сложно оценить.
Время от "взял в работу" до презентации — это другой показатель.
Возможно что и другой. Но как я вижу на своем уровне — только он и имеет смысл для разработки. Ну просто потому, что доступные ресурсы команды ограничены, при этом нагенерировать вполне здравых идей мы спокойно можем на пару лет вперед — только сделать их за разумное время невозможно. А оценить, какие из них заведомо выстрелят — тоже невозможно зачастую, нужно хотя бы MVP. Ну то есть, у нас куча задач, которые лежат в жире годами.
KPI важнее реальных процессов
Ну да, когда неправильно применяют инструменты, то это к беде. Если на bash писать банковскую систему, то ни к чему хорошему это не приведет. Также как и с помощью TTM измерять KPI конкретного разработчика или отдела.
Но этот показатель есть расстояние по времени от появления идеи до получения клиентом. Хотите мерить что-то иное, берёте другой показатель. Как бизнес дальше работает с этими значениями - это на совести управленцев.
Какой проект, кто его потребители(внутренний продукт или внешний) не имеет значения. Метрика означает одно.
Размер задачи имеет значение, но тут нужно уметь правильно разбивать и анализировать.
Еще раз, TTM - это такая же метрика как и средняя продолжительность жизни человека. Вот от момента рождения, до смерти. Метрика работоспособного населения (аналог времени когда задача была в работе) - это уже другая величина.
Формальными метриками выстлана дорога в зеленый бренд... Побольше метрик и базвордов!!!
Полагаю, что среднее или медиана по всем задачам в такой ситуации может быть более подходящим показателем.
А чем это лучше-то? Ведь чтобы усреднять разные задачи, у них должен быть какой-то осмысленный вес. А его нет. Ну во всяком случае — у задачи в Jira его нет. Ну то есть, я могу себе представить такое исследование, но на базе обычной информации о задачах его провести совершенно невозможно.
Ну так, в качестве примера — вот у вас есть две задачи, одна blocker, а вторая minor. Как правило, первую вообще делают ASAP, потому что без ее решения что-то не работает как надо. А вторую можно вообще не делать, и никто не заметит. Ну то есть, в жизни реально есть задачи, ttm для которых вообще никому не интересен. Но в моем конкретном примере их учитывали одинаково.
Ну, среднее - это простейший случай. Так то согласен ,что задачи имеет смысл ранжировать по приоритету, возможно по сложности или еще как-то. Либо ставить тем задачам, по которым не ведется работа, статус on hold и не учитывать время в метриках.
Вообще, грамотно настроить метрики ,чтобы они приносили пользу проекту - непростая наука. И к сожалению, зачастую эффективные менеджеры в нее не умеют, а командам приходится подстраиваться и страдать.
Т.е. проблема не в метриках совсем, а в руководстве. Очень хочу посмотреть на систему оценки руководителей, выставленную для всеобщего обозрения, в отдельно взятой компании.
Часто встречался, что у них выглядит как победа, так это неоспоримая заслуга руководства, как проигрыш, так команда виновата.
Если Тима нанимали на решение бизнес задач, а вместо этого он "беседует с разработчиками", "помогает в архитектуру" и "улучшает эффективность" - значит должность этого Тима надо менять на "архитектор" / "ментор" / "тим-лид" / "проджект менеджер" в зависимости от того чем занимается Тим.
Очень часто вижу ситуацию когда "сениоры" вместо разработки (то есть создание фичей) скатываются в "помогательство". По факту в большинстве случаев это не сениоры а раздолбаи - трындеть, "помогать" и предлгать всякое разное намного проще чем отвечать за что-то и делать самому. Особенно этим грешат всякие говнокодеры которые пилят архетктуру в которой никто кроме них не разберется, а потом занимаются "помогательством".
PS. Так и оказалось. Если открыть CV Тима то можно увидеть что он в большинстве мест был "Consultant" / "Agile Coach" / "Founder" / "Director", а "developer-ом" был всего в паре мест.
Страшные вещи говорите! Так дойдет до того, что руководству придется разбираться, как работают их подчинённые, и, страшно сказать, как и почему в их епархии всё устроено. Не-не-не, Дэвид Блэйн.
А если серьезно, то стори поинты и прочий таймшиттинг имеют смысл только в функциональной деятельности. Если они начинают определять оригинальную разработку и кадровую политику, то, значит, руководитель теряет/ уже потерял контроль, или вообще связность в оргацизации разрушается и надо либо чинить, либо реорганизовывать.
Суть здесь не в стори поинтах, а в том что разработчиков обычно нанимают пилить фичи. Если разработчик 100% времени занимаются чем угодно только не этим - появляется обоснованное сомнение, а точно ли это разработчик и нужен ли он команде.
Не, если разработчика нанимают "пилить фичи", то в компании скорее всего не очень хорошо с процессами и пониманием разработки. Вот если нанимают "приносить пользу компании" - это как-то логичнее.
Обсуждение фичи с заказчиком часто (почти всегда) оказывается в разы более эффективным инженерным действием, нежели фигачить код.
значит должность этого Тима надо менять на "ххх" / "ххх" / "тим-лид" / "ххх"
Хмм?..
Очень часто вижу ситуацию когда "сениоры" вместо разработки (то есть создание фичей) скатываются в "помогательство".
Так это из-за "инфляции" синьоров. Во многих местах им дальше просто некуда расти в техническом смысле, вот люди и переключаются на менторство, архитектуры и т.п. И если в компании таких должностей формально нет, а по факту они есть - это повод пересмотреть организационную сетку.
Пардон, а что значит:"Некуда расти в техническом смысле?" Он достиг просветления и постиг дао?! Все зависит только от личных горизонтов познания. Скорей все "помогатор" либо уперся в пределы своих знаний и лень дальше расти либо просто паразит по природе. Чаще всего с уходом такого персонажа ничего неменяется в команде, т.к. он ничего и не проиводил, а только изображал работу
То есть, если сотрудник достиг предела своей компетенции, его надо уволить?
Ну да, а то он не будет расти. Зачем нам сотрудники без роста?
И нанять за его зп 8 джунов. sova.jpg
так и происходит. Достиг передела - перестали повышать зп - он собрался и ушел в другое место.
В первую очередь нужно разобраться в чем причина "остановки". Причины бывают, довольно, разные. Но если при достижении предела сотрудник не хочет дальше двигаться, то можно рассматривать и увольнение.
Например, на одном из проектов у нас один из лидов "решил", что основная его задача - это менторство, что было маловато для лида и остальные задачи, явно, хромали. Пришлось с ним распрощаться на данном проекте. И ничего экстраординарного здесь нет. Если человек не соответствует свой должности, то зачем его держать?
Так соответствует или не соответствует? Речь о том, что человек не хочет дальше двигаться, потому что он соответствует своей должности.
Я считаю, что предела совершенству нет на любом месте и в любом направлении.
А фраза "Речь о том, что человек не хочет дальше двигаться, потому что он соответствует своей должности." как-то звучит, как раз, субъективно. Т.е. есть вполне формальные критерии оценки еффективности сотрудника и если он не выполняет должестные обязанности есть повод к увольнению или переводу на другое место.
Было дело, когда был еще крепким джуном и работал в одном НИИ за маленькую зп, к нам в департамент добавили фронтенд тех лида. Я через 10 минут общения с этим типом по своему проекту на Angular (на тот момент мой опыт фронтенда после 5 лет бека был 3 месяца) понял (а он был заявлен как профи в ангуляр), что он знает во фронтенде меньше чем я, хотя мой опыт ангуляра тогда был в пару месяцев (особенно хорошо это видно с высоты моего нынешнего опыта). Все что выдало это 'чудо' за 2.5 года, помимо пустого трепа и лобызаний перед начальством, это 2 пдф файла с картинками дизайна... Ни ревью... Ни проработки архитектуры... Многие архитекторы были им недовольны, но начальство закрывало глаза все время, пока само начальство не свалило из-за того, что поймали на сдачи проектов в подряд для отмывки... Ничего, только хождение на совещания с высшим руководством (которое его и поставило, Ха-Ха). А ведь этому человеку, платили как 10м джунам как минимум... (зп у джунов тогда были ни к черту там) Пошел наверное в какое-то другое место гнездиться. С тех пор я правда настолько нулевых 'тех лидов' не встречал, надеюсь не встречу более и желаю никому в такое не вляпаться...
Все верно. Могу предположить, что руководство компании как и автор статьи держали этого парня на более низкой должности формально, чтобы не повышать ему зарплату) А сам он мог этого не понимать, так как руководство не давало никакой обратной связи и никогда не поощряло его. Повсеместная ситуация во многих компаниях, к сожалению.
Тим у вас тимлид/архитектор/менеджер или вы готовы его перевести на соответствующую позицию? Если нет, то увольнять. Такие добровольные помогаторы обычно вредят больше чем помогают. Особенно если их не готовы переводить на соответствующие позиции и могут это обосновать.
Почему не выставили ссылку на оригинал и не пометили как "Перевод"? Оригинальная статья тут - https://dannorth.net/2023/09/02/the-worst-programmer/
не понял две вещи - почему менеджер вообще не в курсе что происходит в отделе
Это же команда консалтинга. Менеджеру исходного отдела не обязательно знать что происходит в нанятой сторонней команде. Это делегировано лиду команды от лица которого идёт повествование. Это разумно. Но менеджер таки хочет быть в курсе, поэтому и ввёл метрики. Это неразумно, но так бывает - мы живём не в мире эльфов.
почему Тим не может сказать за себя, а его еще и увольняют тайно без разговоров?
Почему без разговоров? Менеджер отдела пришёл сначала обсудить непонятную для него ситуацию с непосредственным лидом Тима. Прийти СНАЧАЛА к Тиму, а ПОТОМ к его лиду было бы верхом глупости.
нет, написано что он пришел его увольнять, то есть он принял решение на основании цифр а не их разбора.
Там так же написано, что команда (или её лид) согласилась использовать эти метрики после вдумчивого обсуждения почему их прежние метрики были вообще какой-то дичью.
Тогда зачем менеджеру знать об отдельном члене команды
Потому, что он платит деньги и не понимает за что. По согласованным с командой метрикам у чувака всё по нулям - зачем ему платить?
речь же не про команду, а про то, что человек принял решение об увольнении сотрудника до того, как будет разобрана ситуация.
Да, нет, речь именно про команду, которая после ВДУМЧИВОГО обсуждения согласилась на данные условия. Условия не были выполнены, нужно принимать меры. Что не так?
Сотрудника он не уволил, а спросил лида - чё за фигня творится. Правильно спросил - команда подписалась под то, что не выполняет.
Я уже написал об этом в самом начале. Так является ли это проблемой работников? Он свои косяки в работе перекладывает на плечи нанятых людей.
Да, является. Если работник не выполняет договорённостей, это проблема работника.
Вообще нонсенс когда работник еще и должен доказывать что не зря получает зарплату
Вы ещё скажите, что это нонсенс, когда работник должен работать. Ну, а чё - я же пришёл на работу, а ты начальник, сам и доказывай себе, что не зря мне платишь. Так что ли?
У адекватного владельца бизнеса равно как у его наёмных руководителей первая задача - это не экономия средств. Всё же они тут бизнес запустили и первая задача - заработать денег.
Когда денег зарабатывается меньше, чем тратится - это проблема. Странно, что вы, как экономист этого не понимаете.
И когда менеджер пришёл увольнять сотрудника знали ли он, что увольнение Тима навредит бизнесу?
Это далеко не факт. Мы знаем об этом только из рассказа друга этого Тима.
То есть повторю еще раз, он не выполнял свои обязанности и свои косяки переложил на плечи других.
Ничего подобного. Он увидел халявщика и пошёл с ним разбираться. Это халявщик переложил свои обязанности и обязательства на которые сам подписался на тимлида.
И так по всей цепочке вверх - нифига они не знают
Откуда ж им знать, если самое низшее звено халявит и нарушает договорённости, а его непосредственный начальник его покрывает. Вы правда считаете, что топ-менеджер должен сидеть и смотреть, как Тим гладит кого-то по головке и от этого поглаживаемому якобы становится легче? Да, чушь собачья!
буду попивая бренди всем рассказывать какие они эффективные.
если благодаря их работе им хватает на бренди, то что же здесь неэффективного?
нет, написано что он пришел его увольнять, то есть он принял решение на основании цифр а не их разбора
возможно автор в угоду драматизму немного преувеличивает - такое бывает когда пишешь success story со своим участием
А зачем ему быть в курсе что происходит в отделе? К черту детали - у него есть отличные KPI метрики, на основании которых он принимает эффективные менеджерские решения. New wave - black box management style!
Это была ирония))
Автоматически становится ясно что нудно писать код так, чтобы строк было много, и чтобы регулярно были баги.
К качеству кода могут быть отдельные требования. И разработчик что исправляет баги может быть отдельный.
У нас вот на одном из проектов было так, если баги по нашей вине, исправляет компания за свой счет. Если баги по вине заказчика, не прописал условия в ТЗ или бизнес модель изменилась, то заказчик оплачивает доработку. Программисты все равно получали зарплату, но за доработки могли получить премию. За исправление багов только обычная зарплата.
Работал я с таким Тимом однажды. Кодить ему не хотелось вообще. Но это полбеды. Взыграла у него тяга к педагогике. Дай, говорит, найму целую пачку джунов да буду их менторить на максималках, а сам ничего делать не буду. Сплошное делегирование, доверие, взращивание ответственности и т.д. В итоге нанял трех джунов, позволил им устроить на проекте лютый трэш, а через 5 месяцев ушел в закат со словами "Моя миссия здесь завершена".
Полгода спустя джунов уволили, самый жесткий ущерб от говнокодинга и говноархитектуры пофиксали. До сих пор тепло вспоминаю селект с 14 джойнами, который был написан одним из джунов и одобрен Тимом. После рефакторинга, к слову, 2 джойна осталось.
А от Тима не осталось ни строчки кода, ни статейки в доках, ни даже PDF с "видением". Был сотрудник, не было - не понятно.
Борьбе за метрики напоминает борьбу за коэффициент KDA в некоторых играх. С тем же печальным результатом.
Люди размышляют о том как оценить работу и эффективность. Как и в сообществе зверей слабых заклевывают, сильные получают лучший кусок.
Но, если посмотреть на картину глобально, то окажется что одним из основных стимулов заставивших человека добраться до вершины пищевой цепочки является слабость новорожденного, который, в отличии от новорожденных других видов вообще не способен к самостоятельному существованию. Даже голова не держится и нужно ее осторожно придерживать. Кто там еще на вершине? Вирусы? Грибы? Что нас от них отличает?
Избавляясь от слабых мы в какой то мере стратегически убиваем перспективу. Кто сказал, что вот этот неэффективный сегодня специалист не станет ключевой причиной развития?
А зачем вообще поддерживать старых, больных, немощных? Нужно всех измерить, сравнить с критерием и наступит счастье…
Приведенные рассуждения сильно утрированы, чтобы показать насколько опасен выбранный путь. Измерили, уволили всех плохих и стало лучше. Нет, хорошо будет только тогда, когда получится создать гармонично развивающуюся группу. Когда люди не конкурируют за, но поддерживают друг друга, и это несколько другой уровень развития.
Только в человеческом обществе поддерживают старых и больных и это характеризует отличный духовный уровень развития. Вот ежели бы вопрос ставился не о том как измерить неэффективных сотрудников, а как помочь неэффективному стать лучше…
Вот тут где-то зарыта собака. Но мы думаем о КПИ...
В хороших современных компаниях происходит так, как вы пишите. Практика уже давно показала, что эффективность работников растет, когда они находятся в психологически благоприятной атмосфере. К сожалению, у нас такой подход только начинает развиваться. Сфера ИТ развивается быстрее, а в некоторых отраслях процент таких компаний пока стремится к нулю. Надеемся на светлое будущее.
То есть тех кто плохо работается нельзя увольнять? Или я вас неверно понял? А как тогда мотивировать работать хорошо? Допустим премия человеку не нужна, ему и зарплаты хватает.
между увольнять и не увольнять еще много разных категорий... не надо ко всему применять бинарную логику)
Поговорить это понятно. Лишить стандартной выдающейся примерно всем премии тоже понятно. Предположим это не сработало. Что дальше?
Плохо это именно об этом. Человек перекладывает джейсоны в три раза медленнее соседей с той же зарплатой и в три раза медленнее чем это все кому положено оценили. На разговоры что стоило бы работать получше не реагирует, на лишении премии не реагирует. Следующий рычаг это уволить. Ч других не знаю.
Если других вариантов не остается, то увольнять конечно) Что касается случая из статьи - там сотрудник выполнял функции, предусмотренные не его должностью, а должностью повыше, хотя формально оставался на своей. Соответственно, к нему эти показатели применять было не корректно. Об этом знал его непосредственный начальник (который по этой причине и решил его не увольнять), но не знал руководитель повыше, который смотрел только на цифры. Бардак в общем)
А что касается большинства современных условий труда, то там и до "поговорить" очень редко доходит. Обычно все заканчивается взаимными претензиями и неприязнью.
Да обычный мидл, на обычной зарплате мидла, с обычного рынка мидлов, после обычного собеседования и обычного испытательного срока. И специализация обычная, веб и он есть веб. Откуда вы всю эту дичь взяли?
Как побольше времени проведете в администрировании тоже придете к выводу что везде все одинаково в среднем. Особенно задачи вашего мидла. Все прям совсем сложное и необычное уходит сеньорам. У них голова большая, пусть думают.
Ну да именно средняя скорость разработки фичей. Когда видишь даже десяток разработчиков становится хорошо понятен типичный средний срок решения типичной задачи. Отклонения в разы хорошо видны. Сроки меряем в неделях. Никто к часам/дням не придирается.
В должностной инструкции естественно написано «работай хорошо, плохо не работай». Это же документ для hr и кадров. Чтобы в судах удобнее было.
Всегда есть пачка документов на всякий случай. У всех. Увольнять иногда надо. Иногда работник посудиться хочет. Жизнь такая.
Это все не нужно пока все хорошо ну иди хотя бы нормально. У вас же тоже есть заначка на всякий случай? Вот у бизнеса в нее входят всякие документы.
Вы о чем. Всё полностью легально и правильно. Ну не будет работодатель писать такие документы с которыми фиг уволить кого потом. И пользоваться ими без чего-то крайнего не будет. Вероятнее всего у вашего точно такие же есть, вы и не догадывались б их существовании. И вероятно их никогда использовать не будут. Вы же нормально работаете?
У сильных профсоюзов есть проблемы. Местами большие проблемы. Дороги в Нью-Йорке видели? Это профсоюзы. Франция где регулярно уехать никуда нельзя? Это тоже профсоюзы. И тому подобное. Все не так однозначно.
Меня наверно бигтех испортил. Там подписываешь прям сантиметры бумаги. Многие не читают вообще. Внимательно не читает наверно почти никто.
Ну вот и хорошо. Все нормально разбегались без судов и всяких странных бумаг. Все сработало как и планировалось. Без крайних случаев.
Ну как сказать. Есть люди желающие работать за эти же деньги. Но текущих не желающих работать уволить и нанять желающих работать вместо них профсоюз не дает. Платить выше рынка нет смысла. Потому что за что? На мой вкус это испорченный профсоюзами рынок труда. Спрос-предложение не работают, работа не делается.
Под нежеланием работать я понимаю нежелание выполнять работу которую люди с улицы за те же деньги с радостью выполнят.
Желание получать за тоже самое в два раза больше такого же работника на улице и работать в два раза меньше является неразумным и ломает рынок.
Затраты на онбординг конечно же учитываются при принятии решений.
С другой стороны учитывается и бас фактор. Если ваш бизнес заметно страдает при увольнении кого-то рядового то пора срочно вкладываться чтобы этот человек перестал быть таким уж незаменимым. Ну мало ли он сам решит уволиться по личным причинам? Это решаемый вопрос.
Я говорю про обычных рабочих из своих примеров. Дорожные рабочие в Нью-Йорке чтобы далеко не ходить. Учить ну недели хватит наверно? Пусть даже пара месяцев на курсах водителя катка. Странно если у них будет зарплата или условия труда заметно лучше чем у любых других рабочих.
Я живу в этой же модели. Это нормальный рынок. Если есть желающие делать твою работу дешевле - их и берут вместо тебя. Если желающих поработать не наблюдается, а они нужны - повышается зарплата до тех пор пока желающие поработать не найдутся.
Государство при этом устанавливает какие-то общие правила и не лезет в детали. Пример: при увольнении по желанию работодателя после испытательно срока и без каких-либо причин которые работодатель готов озвучить работнику платится минимум 2 зарплаты. Это пример хорошего правила. И работника защищаем и бизнес вести не мешаем.
Вы же смените работу ради 2х зарплаты? Да и ради 1.5х смените. Так почему вы считаете что работодатель ради соответсвующего уменьшения зарплате не сменит сотрудников? Речь именно о рядовых сотрудниках. Которые по определению должны быть несложно заменяемыми. Просто для безопасности бизнеса.
Рынок зарплат есть. Не знаю как вы столько лет работаете и не заметили. Он местами может быть странным. Бывает.
Речь не идет о копейках. Вопросики появляются на больших числах.
Хорошо то что не увольнять в сколь либо большом бизнесе не получается. И нужен адекватный механизм от государства чтобы можно было увольнять людей. Механизм гарантирующий пару зарплат - хороший. Он и увольнять позволяет и работника защищает.
Вы меня поняли не совсем верно. Нельзя это неправильное слово, можно.
Но будет ли это наилучшим решением?
Почему ваш гипотетический человек не стремится работать лучше? Может ему что-то мешает? А может работа которую в этой команде делают не нужна ему/никому?
Пожалуй, в этом не должен разбираться работодатель и лидер маленького коллектива, но тогда кто?
Вы подобрали на улице котенка, он вам понравился, он бегал и сломал лапку, теперь этот котенок инвалид. Нужно ли его кормить, кто должен его кормить? Так же и сотрудник устраивал вас когда-то, а сегодня он вас раздражает. Почему?
Да потому что он не вписывается в какие-то рамки которые ничего не имеют общего с успехом. Что такое успех? Какие цели у успешных компаний? Заработать много денег? Нет, у действительно успешных компаний цель сделать жизнь в мире лучше и удобнее (Хотя может это такой ПР шаг).
Как пример социальной ответственности мне кажется лучше всего подходят тюрьмы в Норвегии. Социальный институт призванный исправить неправильное поведение индивида. Не наказать человека, но перевоспитать. Не знаю насколько у них там все получается, но звучит правильно. Если человек заболел его нужно полечить, а не добить.
Я всегда думал что на работу устраивается профессионал, а не котенок. Речь допустим о типичном мидле.
Задачи те за которые ему деньги платят. Бизнес в курсе задач, считает их нужными и все такое. Задачи это не всегда интересное построение звездолета. А иногда и реализация очередной условной формы 32-бис. Это форма нужна бизнесу.
Обычные разговоры о том что надо работать лучше, как я писал чуть выше, допустим не помогли.
Успех бизнеса и рядовой работник уровня мидла это вещи из разных вселенных. Нет смысла и думать об этом. Ну если кому-то так легче работается, пускай. Практически это не имеет смысла.
Отчасти невозможно с Вами не согласиться. Однако, у каждой медальки есть две стороны.
О котенке я говорю не в профессиональном смысле, но в смысле ответственности руководителя за каждого подопечного, даже за суперпрофи. Если вы микроскопом забьете гвоздь то в профессиональном смысле точнейший инструмент испортится И его нужно будет заменить, но нужно будет заменить и следующий микроскоп и т.д. И такое поведение руководства встречается сплошь и рядом...
Если вдруг человек никогда не был профессионально годен, то почему он прошел испытательный срок? А если все было нормально, то что изменилось? Может быть тут проблема вовсе не в этом человеке?
Успех управления-- это выравнивание векторов усилий каждого сотрудника компании в одном направлении. Успех бизнеса это правильно поставленная задача призванная сделать жизнь лучше и успех управления.
Далеко не факт что задачи поставленные "Бизнесом" вообще кому-то нужны. Как показывает статистика прогорания стартапов, вообще не факт что нужны, а многие задачи спущенные вниз даже вредны. И очень может быть что правильный анализ этого вопроса позволил бы более эффективно выбирать направление деятельности а не гробить микроскопы и мучить котят.
Ну и увещевания человеку — работай лучше. Я пробовал так со своими детьми. Дети учитесь лучше! Не работает. Чтобы человек лучше работал нужны условия при которых этот человек будет работать лучше и для каждого такие условия свои. Но в основном нужно показать человеку что в вашем понимании хорошая работа.
Вы превращаете бизнес в какую-то богадельню. Руководитель отвечает за подчиненного только как руководитель. Ну там чтобы разработчики чайники не чинили и чтобы у них понятные профильные задачи были в достаточном количестве. Ну и защищает если кого из разработки хотят обидеть без повода или по незначительному поводу. На этом все. Дальше может стоит просто поработать? Вместо рассуждений о защите.
Есть исключение когда правда хочется помочь и это можно сделать. У человека что-то плохое иногда случается и ему нужно полгода не работать. Тут хороший руководитель придумает как это обеспечить. Выслушав человека и признав повод серьезным. И место подержать можно и вакансию можно не открывать. Зарплаты при этом конечно же не будет. Можно формально минималку оставить, чтобы вакансия не появилась.
Далеко не факт что задачи поставленные "Бизнесом" вообще кому-то нужны
Нужность задач определяется просто: Разработчику за реализацию этих задач бизнеса платят деньги. Он эти задачи реализует. Бизнес не лезет в технические решения, разработчик не лезет в бизнес решения. Вроде все правильно?
Если бизнес задачи оказались ненужными бизнесу за это отвечают другие люди. Не разработка. Если задачи были реализованы плохо, то за это отвечает разработка. Есть куча потенциальных проблем на стыке постановки-реализации, тут все вместе работают и все отвечают.
Чтобы человек лучше работал нужны условия при которых этот человек будет работать лучше и для каждого такие условия свои.
Зарплата на карточку приходит вовремя, ноут выдали хороший, монитор большой, стол и стул есть. И даже кофе с печеньками есть. Разве еще что-то надо?
Но в основном нужно показать человеку что в вашем понимании хорошая работа.
Есть тикет. В нем описана задача для разработчика. Результат выполнения или очевиден или будет дополнительно расписан и рассказан. Сроки иногда есть, иногда нет или почти нет. По разному бывает.
Хорошо - тикет сделан за разумное время, багов нет или почти нет, тесты есть и они адекватные, код прошел код ревью, тестирование довольно, девопсы довольны, клиент получил то что и ожидал. Вроде все очевидно?
Я во многом с Вами согласен и даже не хочу спорить. Просто диапазон возможных превращений бизнеса достаточно широк от "Рабовладения" до "Богадельни" есть масса точек достижения комфортного равновесия.
Оптимальный набор команды это широко известная и достаточно изученная тема. Теория, да и практика гласит что в любой команде есть набор ролей которые распределятся между людьми. При этом есть набор темпераментов которым свойственны некоторые алгоритмы поведения. Несоответствие темперамента и роли приведет к ухудшению общих результатов команды. Если вы наберете команду лидеров то они будут плохо уживаться друг с другом, если вы наберете команду исполнителей то не будет инициативы, если вы наберете команду из перфекционистов они завязнут в деталях, а если в команде будут одни шейперы, то любой проект погибнет из за размера технического долга и недоделок. Есть профессионально бесполезные роли, однако их вклад в общее дело при этом может быть значительным. (Похоже этот случай описан в статье)
Если оценивать всех исключительно по скорости и количеству исполнения тикетов то приходим к безынициативной и бесперспективной команде от которой нечего ждать.
Оптимальная команда это набор людей разных темпераментов работающих сообща для достижения общей цели.
Немалую роль в достижениях команды несет лидер, он должен защитить вот этот странный коллектив из себя, исполнителей, перфекционистов и раздолбаев от нападок извне и распределить задачи свойственные темпераменту каждого. Если он не справляется, то сотрудники теряют мотивацию и команда рушится и работает плохо.
Если он при любом удобном случае переформатирует команду то роли тоже начинают меняться и команда работает хуже чем вариант с устоявшимися ролями.
Когда лидер по своей сути лидером не является является ему технически выгодно сваливать провалы проекта на исполнителей вместо того чтобы биться с равными за своих "котят" и искоренять причину проблемы. Судя по всему в статье как раз зачатки подобного и имеют место быть. Лидер видит что есть человек который повышает качество работы команды, хотя сам тикеты не очень решает…
Иногда временные рамки существования команды не позволят решить проблем и тогда нужно искать административные рычаги. Но доля подобных проблем должна быть исчезающе мала, что будет свидетельствовать о здоровье коллектива.
А зарплата на карточку, и рабочее место с кофе и печеньками это же базовые потребности, не будет их люди сами убегут… Вы себе не представляете какое счастье работать в коллективе целеустремленных единомышленников. Как в рекламе щуплый такой тренер выходит и говорит двум качкам — "Ребята, может поработаем", качки ему отвечают "ТРЕНЕР СКАЗАД НАДО, ЗНАЧИТ НАДО".
Вы продаете софт скилы. Я в курсе что они есть и что их значение ненулевое. Продали.
Но при полном провале хард скилов, да-да то самое перекладывание джейсонов вовремя и с нормальным качеством, софт скилы теряют всякий смысл. Мы тут работаем, а не люди хорошие. На команду это тоже влияет плохо. Люди видят что работать необязательно, можно просто быть хорошим человеком. И зачем работать? Хорошим человеком быть проще.
Очень добрая и светлая статья. На проектах порой очень не хватает такого Тима))
В некотором роде товарищ выполняет функцию смазки механизма. Здесь тоже можно иметь метрики – скорость вхождения новичков, текучка и проч.
В моем понимании это часть работы РМ все таки, а не худшего программиста.
Самый плохой программист, которого я знаю