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/
не понял две вещи - почему менеджер вообще не в курсе что происходит в отделе и почему Тим не может сказать за себя, а его еще и увольняют тайно без разговоров?
не понял две вещи - почему менеджер вообще не в курсе что происходит в отделе
Это же команда консалтинга. Менеджеру исходного отдела не обязательно знать что происходит в нанятой сторонней команде. Это делегировано лиду команды от лица которого идёт повествование. Это разумно. Но менеджер таки хочет быть в курсе, поэтому и ввёл метрики. Это неразумно, но так бывает - мы живём не в мире эльфов.
почему Тим не может сказать за себя, а его еще и увольняют тайно без разговоров?
Почему без разговоров? Менеджер отдела пришёл сначала обсудить непонятную для него ситуацию с непосредственным лидом Тима. Прийти СНАЧАЛА к Тиму, а ПОТОМ к его лиду было бы верхом глупости.
Почему без разговоров? Менеджер отдела пришёл сначала обсудить непонятную для него ситуацию с непосредственным лидом Тима. Прийти СНАЧАЛА к Тиму, а ПОТОМ к его лиду было бы верхом глупости.
нет, написано что он пришел его увольнять, то есть он принял решение на основании цифр а не их разбора. То что лид смог его отстоять тут скорее странность. Я вижу ситуацию так, приходит менеджер к лиду и спрашивает почему у такого-то плохие показатели. а решение принимает по результату разговора.
Менеджеру исходного отдела не обязательно знать что происходит в нанятой сторонней команде
Тогда зачем менеджеру знать об отдельном члене команды, логично оценивать ее эффективность в целом. Что они и сделали позднее.
нет, написано что он пришел его увольнять, то есть он принял решение на основании цифр а не их разбора.
Там так же написано, что команда (или её лид) согласилась использовать эти метрики после вдумчивого обсуждения почему их прежние метрики были вообще какой-то дичью.
Тогда зачем менеджеру знать об отдельном члене команды
Потому, что он платит деньги и не понимает за что. По согласованным с командой метрикам у чувака всё по нулям - зачем ему платить?
команда (или её лид) согласилась
речь же не про команду, а про то, что человек принял решение об увольнении сотрудника до того, как будет разобрана ситуация.
У меня в трудовой три вкладыша, 25 лет работы в разных местах и я только однажды встретил идиота, который о качестве работы человека судил по количеству галочек в сервис деске. Но даже он не заводил разговора об увольнении, а пришел ко мне с вопросами.
Потому, что он платит деньги и не понимает за что
Я уже написал об этом в самом начале. Так является ли это проблемой работников? Он свои косяки в работе перекладывает на плечи нанятых людей. Вообще нонсенс когда работник еще и должен доказывать что не зря получает зарплату и самое печальное, что сами работники считают это нормальным.
Простой пример, вам нужно сделать забор на даче, вы платите бригаде по договоренности Х рублей и вам его ставят. Если вам сделают только половину забора или сделают вместо забора сарай, то вы об этом узнаете.
В контексте ИТ отчеты должны писать единицы, ответственные за управление, а не конечные исполнители. Многие не знают, но в менеджменте персоналом задача мониторинга исполнения работы лежит на руководителе. Написание отчета это вообще отдельный скилл и он явно не входит в обучение айтишника (так как я был начальником техподдержки и мы сопровождали SD, то читать отчеты инженеров было всегда забавно и тут либо они пишут так что в этом нет смысла, но быстро, а могут писать более менее складно и вдумчиво, но убивая кучу времени на это). Скажем я служебку пишу минуты три, а большинство вязнет еще на этапе оформления шапки, но, внезапно, я этому обучался год в универе - нас учили писать документы. И я учился на экономиста, а не на айтишника. Да сейчас даже юристы друг с другом обмениваются "рыбой" и сами никакие документы толком оформить не в состоянии.
По согласованным с командой метрикам у чувака всё по нулям - зачем ему платить?
Как бы вам объяснить. У адекватного владельца бизнеса равно как у его наёмных руководителей первая задача - это не экономия средств. Всё же они тут бизнес запустили и первая задача - заработать денег. И когда менеджер пришёл увольнять сотрудника знали ли он, что увольнение Тима навредит бизнесу? Нет, не знал. То есть повторю еще раз, он не выполнял свои обязанности и свои косяки переложил на плечи других. Ну уволил бы он Тима, через пару месяцев показатели бы упали вниз, а так как он дурак, то никакой связи с Тимом он бы не увидел. Это же "эффективный" менеджер. Он бы опять переложил ответственность на команду. И так по всей цепочке вверх - нифига они не знают, но увольнять бегут аж волосы назад. Они же потом график нарисуют и наверх напишут какие они молодцы, получат свою премию и буду попивая бренди всем рассказывать какие они эффективные.
речь же не про команду, а про то, что человек принял решение об увольнении сотрудника до того, как будет разобрана ситуация.
Да, нет, речь именно про команду, которая после ВДУМЧИВОГО обсуждения согласилась на данные условия. Условия не были выполнены, нужно принимать меры. Что не так?
Сотрудника он не уволил, а спросил лида - чё за фигня творится. Правильно спросил - команда подписалась под то, что не выполняет.
Я уже написал об этом в самом начале. Так является ли это проблемой работников? Он свои косяки в работе перекладывает на плечи нанятых людей.
Да, является. Если работник не выполняет договорённостей, это проблема работника.
Вообще нонсенс когда работник еще и должен доказывать что не зря получает зарплату
Вы ещё скажите, что это нонсенс, когда работник должен работать. Ну, а чё - я же пришёл на работу, а ты начальник, сам и доказывай себе, что не зря мне платишь. Так что ли?
У адекватного владельца бизнеса равно как у его наёмных руководителей первая задача - это не экономия средств. Всё же они тут бизнес запустили и первая задача - заработать денег.
Когда денег зарабатывается меньше, чем тратится - это проблема. Странно, что вы, как экономист этого не понимаете.
И когда менеджер пришёл увольнять сотрудника знали ли он, что увольнение Тима навредит бизнесу?
Это далеко не факт. Мы знаем об этом только из рассказа друга этого Тима.
То есть повторю еще раз, он не выполнял свои обязанности и свои косяки переложил на плечи других.
Ничего подобного. Он увидел халявщика и пошёл с ним разбираться. Это халявщик переложил свои обязанности и обязательства на которые сам подписался на тимлида.
И так по всей цепочке вверх - нифига они не знают
Откуда ж им знать, если самое низшее звено халявит и нарушает договорённости, а его непосредственный начальник его покрывает. Вы правда считаете, что топ-менеджер должен сидеть и смотреть, как Тим гладит кого-то по головке и от этого поглаживаемому якобы становится легче? Да, чушь собачья!
буду попивая бренди всем рассказывать какие они эффективные.
если благодаря их работе им хватает на бренди, то что же здесь неэффективного?
Да, нет, речь именно про команду, которая после ВДУМЧИВОГО обсуждения согласилась на данные условия
То есть люди, которые не являются профессиональными управленцами, приняли какое-то там решение, что с профессионального управленца автоматом снимает ответственность? Каждый должен заниматься своим делом, ну и повторюсь - если запустили новую оценочную систему, то сначала разговор, а потом увольнение.
Условия не были выполнены, нужно принимать меры. Что не так?
Ну если управленец дебил (а мы уже поняли что он именно такой), то конечно, нужно всех увольнять.
Сотрудника он не уволил, а спросил лида - чё за фигня творится
Так, стоп. Я дико не люблю когда перевирают. Вот вам цитата из текста:
"Было очевидно, что Тима нужно увольнять. К такому выводу пришёл менеджер, и он попросил произвести необходимые приготовления для увольнения Тима и замены его на того, кто сможет выполнять стори.
Я без лишних слов отказался"
То есть менеджер разбираться не хотел и Тиму повезло, что автор оказался таким принципиальным человеком. Был лизоблюд приспособленец - и Тим пошел бы гулять на улицу.
команда подписалась под то, что не выполняет
Это не так работает. Оценка эффективности работы - это прерогатива владельца бизнеса или того, кого он нанял за этим следить. Если кто-то внедряет какую-то фигню, а потом вам не платит или увольняет по принципу - ты сам подписался, то бегите из того места без всякого сожаления.
Как я написал выше - команда может состоять зи хороших программистов, но в управлении персоналом или оценках эффективности работы они вообще могут не разбираться, это не их профессия.
Да, является. Если работник не выполняет договорённостей, это проблема работника
Ох, я бы вам не доверил управление коллективом. Работник суть существо хаотичное и бестолковое, придерживайтесь этой парадигмы. Именно поэтому у работника есть руководитель. Это не просто мужик с более высокой зарплатой - это, внезапно, тот, кто руководит. Один работник когда сломал метлу сидит и грустит, второй идёт за новой метлой, а третий - устранит саму причину поломок или снизит их число. А задача руководителя чтобы бизнес работал, а не чтобы потом увольнять всех тыкая пальцем в подписанные бумажки, когда и время упущено и прибыль и качество команды на нуле.
Вы ещё скажите, что это нонсенс, когда работник должен работать. Ну, а чё - я же пришёл на работу, а ты начальник, сам и доказывай себе, что не зря мне платишь. Так что ли?
Доказательство одно - работа выполнена. Если руководитель не в состоянии определить выполнена она или нет, то я даже не знаю что еще можно сделать в такой ситуации. Опять пример с забором на даче - вам показывают забор, а вы такой - докажи что забор есть. Если ваш начальник не видит результат вашей работы, то чем ему помогут ваши отчеты? Он же все равно не поймет ничего и не сможет определить фейковый отчет или нет, так как и работа и отчет сделаны вами, а он в этом не разбирается. Ну давайте сделает отчёт на отчёт - смысл не изменится.
Когда денег зарабатывается меньше, чем тратится - это проблема. Странно, что вы, как экономист этого не понимаете
Я, как экономист, как раз понимаю в чем ошибка ваших рассуждений, но сможете ли вы понять? Когда вы зарабатываете меньше, чем тратите, то это не причина, а следствие, как говорят - поздно пить боржоми. Вы когда нанимаете команду, то вы делаете это не просто по желанию, а на основании расчётов. Себестоимость, спрос, объем рынка, реклама и т.п. Это всё делает не команда программистов, а владельцы или их наемные управленцы и экономисты. Соответственно им же и отвечать. Кто определил что в команду программистов нужно 5 человек, 7, 8, 20? Это был конкретный человек, не программисты появились из неоткуда и самонанялись. Вот кто принимал решение что им нужна команда из Х человек для решения задачи Y, тот и несёт ответственность. Следить за ходом выполнения? Да сколько угодно, в это же суть менеджера. Но как мы видим, он вообще не в теме.
Я абсолютно согласен что подавляющее большинство НЕДОуправленцев первым делом кидаются сокращать штат. Это просто, новый график "эффективности" и "экономии", премия себе любимому. Но так делают дураки. Если задача решается с помощью 10 человек, то можно ли её решить 9-ю? А через пару месяцев встанет вопрос - а зачем нам 9? А через год останется 5. И бизнес думает что решение было верным. Но так далеко не всегда. У вас растёт текучесть кадров, потому что мало кому нравятся переработки. А если вы планируете переработки компенсировать премиями, то не ясно - почему вместо премии нельзя нанять еще людей. Люди не железные - больничные, семьи, просто смерть - обстоятельства не спрашивают чего вы там напланировали. Но вы можете дублировать важные части проекта имея двух специалистов например.
Оптимизация расходов это вообще другой разговор.
Это далеко не факт. Мы знаем об этом только из рассказа друга этого Тима
В контексте разговора это состоявшийся факт. Давайте будем обсуждать его, а не все гипотетические ситуации на Земле.
Ничего подобного. Он увидел халявщика и пошёл с ним разбираться
Нет. Он увидел в системе отсутствие буковок и циферок и почему-то решил, что именно это что-то определяет. Поэтому я и говорю, что после внедрения системы нужно следить за её работой и её качеством оценки. И он не пошел разбираться, он тупо сказал автору произвести увольнние.
Откуда ж им знать, если самое низшее звено халявит и нарушает договорённости
Ну автор же нам написал что никто не халявит. После установки программы по оценке эффективности может пройти много времени прежде чем она даст релевантные данные.
а его непосредственный начальник его покрывает
Хм, если критерий эффективности не совпадает с вашим, то все вокруг преступники? А вы уверены что ваши критерии отражают суть вещей?
Вы правда считаете, что топ-менеджер должен сидеть и смотреть
Во-первых, в статье нет топ-менеджеров. Во-вторых, если топ не имеет никого под собой чтобы заниматься этим, то да, это его работа, иначе бизнесу хана.
как Тим гладит кого-то по головке и от этого поглаживаемому якобы становится легче?
На самом деле такая же история была еще в 90-е, вот не помню где именно, то ли в HP то ли в IBM. Менеджер увидел как работники постоянно торчат на этаже у кофе автомата и автомат убрали, за пару месяцев упала производительность труда, наняли фирму для анализа ситуации и выяснили, что программисты у кофе автомата болтали каждый о своей проблеме и помогали друг другу найти решение. Но я вижу явную разницу между тем какая была реакция в этой статье и в моей интерпретации старой истории - шли поиски причин, никто никого просто так не увольнял.
если благодаря их работе им хватает на бренди, то что же здесь неэффективного?
Вы эффективность менеджера оцениваете размером его дохода? Ну такие эффективные сейчас у нас чиновники, что просто смешно, с доходом у них полный порядок, значит я могу расслабиться и не париться по поводу грязи на улице и разбитому асфальту.
нет, написано что он пришел его увольнять, то есть он принял решение на основании цифр а не их разбора
возможно автор в угоду драматизму немного преувеличивает - такое бывает когда пишешь success story со своим участием
А зачем ему быть в курсе что происходит в отделе? К черту детали - у него есть отличные KPI метрики, на основании которых он принимает эффективные менеджерские решения. New wave - black box management style!
Это была ирония))
Никогда не понимал системы отчетности, человек нанят на работу и ему эту работу должны обеспечивать, то есть над ним стоит человек который знает какую он работу должен выполнить и в каком объеме, а еще и контролировать его работу, то есть отчет как таковой это результат работы зафиксированный вышестоящим руководителем. Иначе написание отчетов становится отдельным видом работы с неизвестным сроком исполнения, длительностью и качеством. То есть у меня нет задачи делать работу, у меня задача сделать хороший отчет.
А еще, хорошо что в статье об этом указано, забавно, когда качеством называют строки кода или устранение багов. Автоматически становится ясно что нудно писать код так, чтобы строк было много, и чтобы регулярно были баги.
Автоматически становится ясно что нудно писать код так, чтобы строк было много, и чтобы регулярно были баги.
К качеству кода могут быть отдельные требования. И разработчик что исправляет баги может быть отдельный.
У нас вот на одном из проектов было так, если баги по нашей вине, исправляет компания за свой счет. Если баги по вине заказчика, не прописал условия в ТЗ или бизнес модель изменилась, то заказчик оплачивает доработку. Программисты все равно получали зарплату, но за доработки могли получить премию. За исправление багов только обычная зарплата.
Работал я с таким Тимом однажды. Кодить ему не хотелось вообще. Но это полбеды. Взыграла у него тяга к педагогике. Дай, говорит, найму целую пачку джунов да буду их менторить на максималках, а сам ничего делать не буду. Сплошное делегирование, доверие, взращивание ответственности и т.д. В итоге нанял трех джунов, позволил им устроить на проекте лютый трэш, а через 5 месяцев ушел в закат со словами "Моя миссия здесь завершена".
Полгода спустя джунов уволили, самый жесткий ущерб от говнокодинга и говноархитектуры пофиксали. До сих пор тепло вспоминаю селект с 14 джойнами, который был написан одним из джунов и одобрен Тимом. После рефакторинга, к слову, 2 джойна осталось.
А от Тима не осталось ни строчки кода, ни статейки в доках, ни даже PDF с "видением". Был сотрудник, не было - не понятно.
Борьбе за метрики напоминает борьбу за коэффициент KDA в некоторых играх. С тем же печальным результатом.
Люди размышляют о том как оценить работу и эффективность. Как и в сообществе зверей слабых заклевывают, сильные получают лучший кусок.
Но, если посмотреть на картину глобально, то окажется что одним из основных стимулов заставивших человека добраться до вершины пищевой цепочки является слабость новорожденного, который, в отличии от новорожденных других видов вообще не способен к самостоятельному существованию. Даже голова не держится и нужно ее осторожно придерживать. Кто там еще на вершине? Вирусы? Грибы? Что нас от них отличает?
Избавляясь от слабых мы в какой то мере стратегически убиваем перспективу. Кто сказал, что вот этот неэффективный сегодня специалист не станет ключевой причиной развития?
А зачем вообще поддерживать старых, больных, немощных? Нужно всех измерить, сравнить с критерием и наступит счастье…
Приведенные рассуждения сильно утрированы, чтобы показать насколько опасен выбранный путь. Измерили, уволили всех плохих и стало лучше. Нет, хорошо будет только тогда, когда получится создать гармонично развивающуюся группу. Когда люди не конкурируют за, но поддерживают друг друга, и это несколько другой уровень развития.
Только в человеческом обществе поддерживают старых и больных и это характеризует отличный духовный уровень развития. Вот ежели бы вопрос ставился не о том как измерить неэффективных сотрудников, а как помочь неэффективному стать лучше…
Вот тут где-то зарыта собака. Но мы думаем о КПИ...
В хороших современных компаниях происходит так, как вы пишите. Практика уже давно показала, что эффективность работников растет, когда они находятся в психологически благоприятной атмосфере. К сожалению, у нас такой подход только начинает развиваться. Сфера ИТ развивается быстрее, а в некоторых отраслях процент таких компаний пока стремится к нулю. Надеемся на светлое будущее.
То есть тех кто плохо работается нельзя увольнять? Или я вас неверно понял? А как тогда мотивировать работать хорошо? Допустим премия человеку не нужна, ему и зарплаты хватает.
между увольнять и не увольнять еще много разных категорий... не надо ко всему применять бинарную логику)
Поговорить это понятно. Лишить стандартной выдающейся примерно всем премии тоже понятно. Предположим это не сработало. Что дальше?
Плохо это именно об этом. Человек перекладывает джейсоны в три раза медленнее соседей с той же зарплатой и в три раза медленнее чем это все кому положено оценили. На разговоры что стоило бы работать получше не реагирует, на лишении премии не реагирует. Следующий рычаг это уволить. Ч других не знаю.
Если других вариантов не остается, то увольнять конечно) Что касается случая из статьи - там сотрудник выполнял функции, предусмотренные не его должностью, а должностью повыше, хотя формально оставался на своей. Соответственно, к нему эти показатели применять было не корректно. Об этом знал его непосредственный начальник (который по этой причине и решил его не увольнять), но не знал руководитель повыше, который смотрел только на цифры. Бардак в общем)
А что касается большинства современных условий труда, то там и до "поговорить" очень редко доходит. Обычно все заканчивается взаимными претензиями и неприязнью.
Например "эффективный" менеджер, разваливший коллектив на одном их моих мест работы был абсолютно уверен и не скрывал и открыто об этом говорил, что техник, обслуживающий 32 аудитории - проекторы, интерактивные доски, сеть, файлы, софт и т.п. в общем самый обычный эникей - пьющий чашку чая - это дармоед укравший денег у работодателя.
троих уволил, теперь инженеры выполняют функции техников, без доплаты конечно. двое инженеров ушли, еще одна в декрет, один умер (бывает), начальник наверное получил премию за сэкономленные ставки.
а сегодня с одной из оставленных мной работ позвонили и сказали такую фразу - вы должны приехать и показать новому админу как там всё устроено. а я там не работаю уже ТРИ месяца, уже по вацапу рассказывал всякое предыдущему админу который пришел после меня и всё там поломал. Мне платить не хотели и не хотят. Идут лесом теперь.
Человек перекладывает джейсоны в три раза медленнее соседей с той же зарплатой и в три раза медленнее чем это все кому положено оценили
у меня сразу вопрос к тому кто его нанял изначально.
пример мой, личный, я админ win/lin, пришел на завод, четверых коллег сократили/уволили, я один остался на 350 ПК разбросанные по 4 корпусам, сеть - 4 независимых сегмента, одноранговая. За 5 лет моей работы: (всё сделал в первый год, потом просто пользовался тем что сделано)
сервер Hyper-v, 5 виртуалок, почта, squid
1C
куча всяких серверов с hasp (несовместимых версионно)
внутрянка на оптику и DSL, заменено 4 бухты кабеля, убрано два десятка soho свичей и заменено на управляемые HP
ладно, всё писать долго. В общем посадили меня делать какую-то хитрую таблицу Excel, долго объяснял что мне это давать не нужно, Excel не мой инструмент, я кроме таблички и автосуммы там ничего делать не умею. Но вечное "тыжпрограммист" в их пустых бошках не победить. Сел, делаю, через час примерно заходят забрать промежуточные результаты, у меня условно готов 1%. У них истерика, мол должен был сделать 20%, мол есть вон Света, она уже 30% сделала. Я предложил всё и отдать Свете и не парить мне мозги.
Табличку у меня забрали и больше не лезли, уволить не захотели.
Это вопрос к тому, что ваши джейсоны точно сел делать профи в этом деле или как всегда наняли за копейки студентов наивно полагая что это делать умеют все и одинаково бюыстро? Так это фейл того кто нанимал. Понятно что уволите, но я бы уволил вместе с ним и того кто его принял.
Да обычный мидл, на обычной зарплате мидла, с обычного рынка мидлов, после обычного собеседования и обычного испытательного срока. И специализация обычная, веб и он есть веб. Откуда вы всю эту дичь взяли?
Откуда вы всю эту дичь взяли?
А что вас не устраивает? Вы хотите какой-то стандарт разбора джейсонов по секундомеру? Вам именно это нужно? Может это ввести как критерий при отборе кандидатов? Что значит "обычный"? Я за все годы работы ВСЕГДА устраиваясь системным администратором еще НИ РАЗУ не делал однотипную работу, если не считать базовые инструменты вроде пинга, телнета и трейсроута, но кто-то так же мог бы сказать - да обычное системное администрирование. Может и ваш мидл 10 лет проработал и ни разу никаких джейсонов в глаза не видел (как я например).
PS: а вы скорость набора текста на клавиатуре проверяете? просто я печатаю смотря на клавиатуру и довольно медленно, а потом поднимаю глаза и перечитываю написанное. Вообще ни разу не пригождался быстрый набор на клавиатуре, я думаю и генерирую код медленнее чем печатаю, так что никогда это не было проблемой. А тут оказывается стандарты скорости какие-то появились.
А как тогда мотивировать работать хорошо? Допустим премия человеку не нужна, ему и зарплаты хватает
Не всем же быть трудоголиками. Выставите критерии качества и если человек не соответствует - увольняйте, но вообще эти критерии должны быть в самом начале еще до трудоустройства, собственно мой пример именно об этом.
Как побольше времени проведете в администрировании тоже придете к выводу что везде все одинаково в среднем. Особенно задачи вашего мидла. Все прям совсем сложное и необычное уходит сеньорам. У них голова большая, пусть думают.
Ну да именно средняя скорость разработки фичей. Когда видишь даже десяток разработчиков становится хорошо понятен типичный средний срок решения типичной задачи. Отклонения в разы хорошо видны. Сроки меряем в неделях. Никто к часам/дням не придирается.
В должностной инструкции естественно написано «работай хорошо, плохо не работай». Это же документ для hr и кадров. Чтобы в судах удобнее было.
Как побольше времени проведете в администрировании тоже придете к выводу что везде все одинаково в среднем
Уже поздно, после 25 лет работы ушёл в свободное плавание по совсем другому профилю.
В должностной инструкции естественно написано «работай хорошо, плохо не работай». Это же документ для hr и кадров. Чтобы в судах удобнее было
Так почему вас что-то тогда удивляет с таким отношением? Вы хотите побольше поэксплуатировать, а они хотят поменьше работать, у вас другого и не получится в такой ситуации. Это порочный круг.
Всегда есть пачка документов на всякий случай. У всех. Увольнять иногда надо. Иногда работник посудиться хочет. Жизнь такая.
Это все не нужно пока все хорошо ну иди хотя бы нормально. У вас же тоже есть заначка на всякий случай? Вот у бизнеса в нее входят всякие документы.
У вас же тоже есть заначка на всякий случай?
вы сейчас о чем?
Вот у бизнеса в нее входят всякие документы
Если судить по тому что сказали вы, то это не "документы на всякий пожарный" - это скорее откровенная полукриминальная схема, поэтому и был мой комментарий.
Иногда работник посудиться хочет
Процент тех кто доводит дело до суда исчезающе мал на фоне того, чем занимаются работодатели НЕ прибегая к суду. Если бы работники за спиной имели сильные профсоюзы и адекватные суды, то жизнь была бы веселее.
Вы о чем. Всё полностью легально и правильно. Ну не будет работодатель писать такие документы с которыми фиг уволить кого потом. И пользоваться ими без чего-то крайнего не будет. Вероятнее всего у вашего точно такие же есть, вы и не догадывались б их существовании. И вероятно их никогда использовать не будут. Вы же нормально работаете?
У сильных профсоюзов есть проблемы. Местами большие проблемы. Дороги в Нью-Йорке видели? Это профсоюзы. Франция где регулярно уехать никуда нельзя? Это тоже профсоюзы. И тому подобное. Все не так однозначно.
вы и не догадывались б их существовании
пардон, но вы меня сейчас назвали идиотом? должностную я читаю ДО трудоустройства и сразу объясняю что не буду ничего делать вне её рамок без оплаты.
Вы же нормально работаете?
Я хорошо работаю, что не мешает работодателям с двух последних работ нарушать мои права, собственно я и увольнялся из-за этого.
Все не так однозначно
Перекладываете с больной головы на здоровую. Дороги плохие не потому что профсоюзы, если что. Там всё банально, не хотят платить за работу, а те не работают пока не договорятся, не вижу в этом вины работников.
Меня наверно бигтех испортил. Там подписываешь прям сантиметры бумаги. Многие не читают вообще. Внимательно не читает наверно почти никто.
Ну вот и хорошо. Все нормально разбегались без судов и всяких странных бумаг. Все сработало как и планировалось. Без крайних случаев.
Ну как сказать. Есть люди желающие работать за эти же деньги. Но текущих не желающих работать уволить и нанять желающих работать вместо них профсоюз не дает. Платить выше рынка нет смысла. Потому что за что? На мой вкус это испорченный профсоюзами рынок труда. Спрос-предложение не работают, работа не делается.
Но текущих не желающих работать уволить и нанять желающих работать вместо них профсоюз не дает.
Подозреваю, что под "не желающих работать" вы понимаете "не хотят делать всё что мы скажем и за бесплатно"? Или "не хотят жить на работе, но за деньги"?
Ну так я не вижу тут проблемы со стороны работника. Человек хочет мало работать и получать много, что является таким же адекватным желанием как и у работодателя, которые хотят чтобы вы много работали, но платить вам как можно меньше. Правда находится где-то посередине.
У меня на первом месте семья, и на втором и на третьем и на 55-м, потом идут мои хобби, мои взгляды на жизнь и как её прожить. Работа находится где-то на 279 месте. Меня абсолютно не волнуют проблемы бизнесов, корпоративности и т.п. (а должны?) И я вам скажу больше - работодателя не волную ни я, ни моя семья. Не прихожу на работу, умер там, наймут другого. Откуда у меня взяться чему-то, что заставило бы меня приблизить корпорацию и ввести её в круг моих жизненных интересов? Вы (и многие молодые и не очень айтишники) ошибочно путаете "социальный пакет" западных компаний с какой-то там заинтересованностью лично в вас. Это работает до того момента пока вы можете что-то, как работник, предложить бизнесу, так как они на вас зарабатывают, если они не могут на вас заработать, то вы окажетесь на улице - благотворительностью они не занимаются (во всяком случае не так как многие думают).
Отсюда всё просто, если компания готовит любую почву чтобы избавляться от работников - она пытается играть нечестно, отсюда непонятно, почему у вас вызывает удивление, когда работники пытаются играть нечестно? Каждый действует в своих интересах. Но у вас риторика направлена на то, что работники плохие, а вы вынуждены защищаться. Это мило конечно, учитывая сколько возможностей у компании решать такие вопросы.
Под нежеланием работать я понимаю нежелание выполнять работу которую люди с улицы за те же деньги с радостью выполнят.
Желание получать за тоже самое в два раза больше такого же работника на улице и работать в два раза меньше является неразумным и ломает рынок.
Под нежеланием работать я понимаю нежелание выполнять работу которую люди с улицы за те же деньги с радостью выполнят
За 25 лет я этот принцип у руководителей встречаю регулярно, но если он где-то и работает, то скорее в каких-то специфичных областях, я, сходу, просто не представляю позиции, где у вас очередь из работников (может азиаты на стройке?).
Как правило после увольнения мне "новенький" звонит только через 3-5 месяцев и всегда с фразы "мне дали ваш телефон вы работали там-то и у меня есть вопросы". И всегда этот новенький офигевает от количества обязанностей и сбегает еще на испытательном сроке, а потом нанимают двоих-троих на те же задачи. Почему? Потому что я этими задачами обрастал 5 лет, а зарплата или не менялась или менялась не сильно.
Смена работника всегда обходится дороже, чем его удержание.
Вообще рынок труда куда более сегментированный и нелинейный. Например в ИТ как минимум три группы специалистов и подход к ним разный. Топ специалистов и рядового эникея сравнивать будет неуместно, но как бы странно не звучало, найти эникея сложнее, во всяком случае толкового.
Желание получать за тоже самое в два раза больше такого же работника на улице и работать в два раза меньше является неразумным и ломает рынок
Не совсем понятно о ком вы говорите. Если это хороший специалист, то на улице их скорее всего ноль, а если это текучка с низкими требованиями, то на "улице" у вас не более чем лотерея, потому что любой более-менее научившийся захочет больше, а вы не платите, вам это не нужно. То есть толковые учатся и уходят, а бестолковые сидят и делают то что делали год назад, но тогда не ясно почему у вас к ним претензии, на "улице" такие же или хуже. У вашего бизнеса есть время нанимать кого попало и тратить время на выяснение их скилла?
В общем я пока совсем не понимаю вас и ваш подход.
Затраты на онбординг конечно же учитываются при принятии решений.
С другой стороны учитывается и бас фактор. Если ваш бизнес заметно страдает при увольнении кого-то рядового то пора срочно вкладываться чтобы этот человек перестал быть таким уж незаменимым. Ну мало ли он сам решит уволиться по личным причинам? Это решаемый вопрос.
Я говорю про обычных рабочих из своих примеров. Дорожные рабочие в Нью-Йорке чтобы далеко не ходить. Учить ну недели хватит наверно? Пусть даже пара месяцев на курсах водителя катка. Странно если у них будет зарплата или условия труда заметно лучше чем у любых других рабочих.
Странно если у них будет зарплата или условия труда заметно лучше чем у любых других рабочих.
Это жуткая модель. Вы спокойно на это смотрите ровно до той поры пока это не коснётся вас лично.
Я живу в этой же модели. Это нормальный рынок. Если есть желающие делать твою работу дешевле - их и берут вместо тебя. Если желающих поработать не наблюдается, а они нужны - повышается зарплата до тех пор пока желающие поработать не найдутся.
Государство при этом устанавливает какие-то общие правила и не лезет в детали. Пример: при увольнении по желанию работодателя после испытательно срока и без каких-либо причин которые работодатель готов озвучить работнику платится минимум 2 зарплаты. Это пример хорошего правила. И работника защищаем и бизнес вести не мешаем.
Это нормальный рынок. Если есть желающие делать твою работу дешевле - их и берут вместо тебя
Пардон, но у меня высшее экономическое и нет ничего нормального в таком поведении. Любая литература по управлению персоналом весьма категорична по поводу "текучести кадров" и смены персонала и везде это принято считать неправильной моделью и совсем не из-за заботы о работниках.
Для бизнеса такая модель губительна, если вы владелец и к вам попал такой менеджер - гоните его в шею. Вообще концепция экономии денег путём увольнения персонала сама по себе идиотская для капиталистического рынка, это все равно что выкинуть в реку лопату потому что лопата дорогая - а копать яму теперь вы чем собираетесь? руками? ну вот самодуры так и поступают.
лояльный дорогой сотрудник средней квалификации выгоднее всегда.
а еще современные боги менеджмента дико не любят семейных женщин с детьми, объясняя это тем, что дети болеют, дети то да дети сё, и с треском проваливаются с наймом персонала, когда тянутся к "молодым и энергичным". Объясняют это они как правило тем, что молодого проще уволить и это правда, но проблема в том, что молодого тяжело посадить на крючок, потому что у молодого планы на жизнь могут менять по 7 раз на дню. У молодого то любовь, то гигантские планы за границей, то он устал и хочет пол года полежать на диване. Семейные же этим не страдают в массе своей, у них на первом месте счета на оплату и им куда менее интересны пения гимна корпорации чем премия или ДМС для всей семьи.
А вы предлагаете платить бабки тупому HR который вам на стол складывает такие же идиотские графики и таблички, по которым Вася, который 7 лет "пашет у станка" дофига получает, аж на 2000 рублей выше рынка, и вообще вчера молодой парнишка принес резюме, где он планку выставил на 10000 ниже чем Вася. Вы Васю начинаете кошмарить, Вася плюёт и уходит и на его место приходит Федя, который как чистый лист открыт новым свершениям. Начальник тут же рисует красивую табличку об экономии 10000 рублей в месяц, получает премию в 50000. Всё шЫкарно. Только Вася трудится теперь у конкурентов, а Федя за неделю запорол 4 фрезы, каждая по 80000 рублей и ОТК не принимает его детали, которых он нарезал еще на 1 млн рублей. (пример практически из жизни по факту работы на заводе)
Так что самое важное это не следить за тем какие там цены на рынке и избавляться от тех кто хочет лишнюю тысячу на новый год, а создавать крепкий и сплоченный коллектив, и только такой коллектив способен бизнес вытаскивать из задниц, в которые его погружают эффективные. Нет коллектива - нет бизнеса.
А если у вас джуны текут рекой, то наверное вам проще пользоваться услугами аутсорсеров и вообще не париться с кадрами.
Ну и замечание касательно "цен по рынку". Нет никаких констант. И если честно я до сих пор не понимаю откуда ценники выставляются "по рынку". Смотришь на зарплаты девочек из колл-центров и понять не можешь - а нафига я столько лет учился, потом столько лет опыта набирался. Да вообще до абсурда доходит на том же заводе все вакансии уборщиц были заняты сотрудниками завода, потому что как инженер-конструктор она получала 14500, а как уборщица - 25000. Я когда пришел работать туда, благо доступ к 1С был, посмотрел на зарплаты в бухгалтерии - любой рядовой бухгалтер - 25000, а инженер-конструктор который как раз деньги и зарабатывает для завода 14500, видимо "зарплата по рынку". Ну вот конструкторы на другие заводы и расползались, а в бухгалтерии в год по 8 человек новых менялись, потому что сейчас бухгалтер это по сути оператор ПК, который вбивает первичку и ни за что не отвечает, вся работа по договору на 1С интеграторе. Рукалицо.
По айтишникам такая же фигня, позиции "системный администратор" от 20000 до бесконечности, причем скорее всего за 20000 вам нужно делать вообще всё, включая ip телефонию, видеонаблюдение, пожарку, сигнализацию, эцп, 1С и т.п. Ну да, рынок кишит теми кто готов за 20000 к вам прийти, но выглядит это обычно вот так:
Это пример хорошего правила
что хорошего в том чтобы человека вышвырнуть на улицу?
Вы же смените работу ради 2х зарплаты? Да и ради 1.5х смените. Так почему вы считаете что работодатель ради соответсвующего уменьшения зарплате не сменит сотрудников? Речь именно о рядовых сотрудниках. Которые по определению должны быть несложно заменяемыми. Просто для безопасности бизнеса.
Рынок зарплат есть. Не знаю как вы столько лет работаете и не заметили. Он местами может быть странным. Бывает.
Речь не идет о копейках. Вопросики появляются на больших числах.
Хорошо то что не увольнять в сколь либо большом бизнесе не получается. И нужен адекватный механизм от государства чтобы можно было увольнять людей. Механизм гарантирующий пару зарплат - хороший. Он и увольнять позволяет и работника защищает.
Ну а в целом это работает так - должностная инструкция, в ней прописан основной фронт работ которые закреплены и когда человек идёт к вам на работу ПЕРВОЕ что вы должны ему показать - это именно эта должностная инструкция. По сути это и есть условие трудового контракта, вы обязуетесь обеспечивать работой, а человек её выполнять. Но у "эффективных" любой работник суть обезьяна бесправная, что скажут - пусть то и делает и плевать джейсоны разбирать или туалеты чистить. И если вы хотите дать новую работу, то первое что вы должны сделать - поговорить об этом с будущим исполнителем. Вполне возможно, что ему это будет не нужно или не интересно. Когда я работал в банке (федеральном) у нас параллельно развивался и линукс и винда на серверах, но когда после слияния двух банков линукс практически убрали, то треть коллектива просто ушли. Да, им предлагали заниматься администрированием винды, но им это было неинтересно. И надо сказать, что руководство это сделало не с пятницы на понедельник, как могло бы показаться, а это был план на год. Перевод инфраструктуры и смена кадров. Для бизнеса всё прошло прозрачно, для людей - комфортно, увольнялись по собственному с премией когда находили новое место. Но да, это 2009 год, кризисы еще не набрали обороты, я увольнялся два года спустя уже совсем по-другому, так как руководство сменилось.
PS: по мытьё туалетов кому-то может показаться смешным, но в универе откуда я ушёл год назад "эффективный" всерьёз рассматривал вопрос сокращения услуг по клинингу и вменить в обязанности сотрудникам мытьё служебного туалета посменно. Отдел состоял из инженеров айтишников и техников.
Вы меня поняли не совсем верно. Нельзя это неправильное слово, можно.
Но будет ли это наилучшим решением?
Почему ваш гипотетический человек не стремится работать лучше? Может ему что-то мешает? А может работа которую в этой команде делают не нужна ему/никому?
Пожалуй, в этом не должен разбираться работодатель и лидер маленького коллектива, но тогда кто?
Вы подобрали на улице котенка, он вам понравился, он бегал и сломал лапку, теперь этот котенок инвалид. Нужно ли его кормить, кто должен его кормить? Так же и сотрудник устраивал вас когда-то, а сегодня он вас раздражает. Почему?
Да потому что он не вписывается в какие-то рамки которые ничего не имеют общего с успехом. Что такое успех? Какие цели у успешных компаний? Заработать много денег? Нет, у действительно успешных компаний цель сделать жизнь в мире лучше и удобнее (Хотя может это такой ПР шаг).
Как пример социальной ответственности мне кажется лучше всего подходят тюрьмы в Норвегии. Социальный институт призванный исправить неправильное поведение индивида. Не наказать человека, но перевоспитать. Не знаю насколько у них там все получается, но звучит правильно. Если человек заболел его нужно полечить, а не добить.
Я всегда думал что на работу устраивается профессионал, а не котенок. Речь допустим о типичном мидле.
Задачи те за которые ему деньги платят. Бизнес в курсе задач, считает их нужными и все такое. Задачи это не всегда интересное построение звездолета. А иногда и реализация очередной условной формы 32-бис. Это форма нужна бизнесу.
Обычные разговоры о том что надо работать лучше, как я писал чуть выше, допустим не помогли.
Успех бизнеса и рядовой работник уровня мидла это вещи из разных вселенных. Нет смысла и думать об этом. Ну если кому-то так легче работается, пускай. Практически это не имеет смысла.
Отчасти невозможно с Вами не согласиться. Однако, у каждой медальки есть две стороны.
О котенке я говорю не в профессиональном смысле, но в смысле ответственности руководителя за каждого подопечного, даже за суперпрофи. Если вы микроскопом забьете гвоздь то в профессиональном смысле точнейший инструмент испортится И его нужно будет заменить, но нужно будет заменить и следующий микроскоп и т.д. И такое поведение руководства встречается сплошь и рядом...
Если вдруг человек никогда не был профессионально годен, то почему он прошел испытательный срок? А если все было нормально, то что изменилось? Может быть тут проблема вовсе не в этом человеке?
Успех управления-- это выравнивание векторов усилий каждого сотрудника компании в одном направлении. Успех бизнеса это правильно поставленная задача призванная сделать жизнь лучше и успех управления.
Далеко не факт что задачи поставленные "Бизнесом" вообще кому-то нужны. Как показывает статистика прогорания стартапов, вообще не факт что нужны, а многие задачи спущенные вниз даже вредны. И очень может быть что правильный анализ этого вопроса позволил бы более эффективно выбирать направление деятельности а не гробить микроскопы и мучить котят.
Ну и увещевания человеку — работай лучше. Я пробовал так со своими детьми. Дети учитесь лучше! Не работает. Чтобы человек лучше работал нужны условия при которых этот человек будет работать лучше и для каждого такие условия свои. Но в основном нужно показать человеку что в вашем понимании хорошая работа.
Вы превращаете бизнес в какую-то богадельню. Руководитель отвечает за подчиненного только как руководитель. Ну там чтобы разработчики чайники не чинили и чтобы у них понятные профильные задачи были в достаточном количестве. Ну и защищает если кого из разработки хотят обидеть без повода или по незначительному поводу. На этом все. Дальше может стоит просто поработать? Вместо рассуждений о защите.
Есть исключение когда правда хочется помочь и это можно сделать. У человека что-то плохое иногда случается и ему нужно полгода не работать. Тут хороший руководитель придумает как это обеспечить. Выслушав человека и признав повод серьезным. И место подержать можно и вакансию можно не открывать. Зарплаты при этом конечно же не будет. Можно формально минималку оставить, чтобы вакансия не появилась.
Далеко не факт что задачи поставленные "Бизнесом" вообще кому-то нужны
Нужность задач определяется просто: Разработчику за реализацию этих задач бизнеса платят деньги. Он эти задачи реализует. Бизнес не лезет в технические решения, разработчик не лезет в бизнес решения. Вроде все правильно?
Если бизнес задачи оказались ненужными бизнесу за это отвечают другие люди. Не разработка. Если задачи были реализованы плохо, то за это отвечает разработка. Есть куча потенциальных проблем на стыке постановки-реализации, тут все вместе работают и все отвечают.
Чтобы человек лучше работал нужны условия при которых этот человек будет работать лучше и для каждого такие условия свои.
Зарплата на карточку приходит вовремя, ноут выдали хороший, монитор большой, стол и стул есть. И даже кофе с печеньками есть. Разве еще что-то надо?
Но в основном нужно показать человеку что в вашем понимании хорошая работа.
Есть тикет. В нем описана задача для разработчика. Результат выполнения или очевиден или будет дополнительно расписан и рассказан. Сроки иногда есть, иногда нет или почти нет. По разному бывает.
Хорошо - тикет сделан за разумное время, багов нет или почти нет, тесты есть и они адекватные, код прошел код ревью, тестирование довольно, девопсы довольны, клиент получил то что и ожидал. Вроде все очевидно?
Я во многом с Вами согласен и даже не хочу спорить. Просто диапазон возможных превращений бизнеса достаточно широк от "Рабовладения" до "Богадельни" есть масса точек достижения комфортного равновесия.
Оптимальный набор команды это широко известная и достаточно изученная тема. Теория, да и практика гласит что в любой команде есть набор ролей которые распределятся между людьми. При этом есть набор темпераментов которым свойственны некоторые алгоритмы поведения. Несоответствие темперамента и роли приведет к ухудшению общих результатов команды. Если вы наберете команду лидеров то они будут плохо уживаться друг с другом, если вы наберете команду исполнителей то не будет инициативы, если вы наберете команду из перфекционистов они завязнут в деталях, а если в команде будут одни шейперы, то любой проект погибнет из за размера технического долга и недоделок. Есть профессионально бесполезные роли, однако их вклад в общее дело при этом может быть значительным. (Похоже этот случай описан в статье)
Если оценивать всех исключительно по скорости и количеству исполнения тикетов то приходим к безынициативной и бесперспективной команде от которой нечего ждать.
Оптимальная команда это набор людей разных темпераментов работающих сообща для достижения общей цели.
Немалую роль в достижениях команды несет лидер, он должен защитить вот этот странный коллектив из себя, исполнителей, перфекционистов и раздолбаев от нападок извне и распределить задачи свойственные темпераменту каждого. Если он не справляется, то сотрудники теряют мотивацию и команда рушится и работает плохо.
Если он при любом удобном случае переформатирует команду то роли тоже начинают меняться и команда работает хуже чем вариант с устоявшимися ролями.
Когда лидер по своей сути лидером не является является ему технически выгодно сваливать провалы проекта на исполнителей вместо того чтобы биться с равными за своих "котят" и искоренять причину проблемы. Судя по всему в статье как раз зачатки подобного и имеют место быть. Лидер видит что есть человек который повышает качество работы команды, хотя сам тикеты не очень решает…
Иногда временные рамки существования команды не позволят решить проблем и тогда нужно искать административные рычаги. Но доля подобных проблем должна быть исчезающе мала, что будет свидетельствовать о здоровье коллектива.
А зарплата на карточку, и рабочее место с кофе и печеньками это же базовые потребности, не будет их люди сами убегут… Вы себе не представляете какое счастье работать в коллективе целеустремленных единомышленников. Как в рекламе щуплый такой тренер выходит и говорит двум качкам — "Ребята, может поработаем", качки ему отвечают "ТРЕНЕР СКАЗАД НАДО, ЗНАЧИТ НАДО".
Вы продаете софт скилы. Я в курсе что они есть и что их значение ненулевое. Продали.
Но при полном провале хард скилов, да-да то самое перекладывание джейсонов вовремя и с нормальным качеством, софт скилы теряют всякий смысл. Мы тут работаем, а не люди хорошие. На команду это тоже влияет плохо. Люди видят что работать необязательно, можно просто быть хорошим человеком. И зачем работать? Хорошим человеком быть проще.
Очень добрая и светлая статья. На проектах порой очень не хватает такого Тима))
В некотором роде товарищ выполняет функцию смазки механизма. Здесь тоже можно иметь метрики – скорость вхождения новичков, текучка и проч.
В моем понимании это часть работы РМ все таки, а не худшего программиста.
Самый плохой программист, которого я знаю