В измерении продуктивности разработчиков хорошо то, что можно быстро выявлять плохих программистов. Я хочу рассказать вам о самом плохом программисте, которого я знаю, и о том, почему я сражался за то, чтобы его оставили в команде.
Несколько лет назад я написал в Twitter/X заметку о лучшем программисте, которого я знаю, её стоит переписать в виде поста в блоге. Мне кажется справедливым, чтобы я рассказал и о самом плохом. Его зовут Тим Маккиннон. Я хочу, чтобы мир знал, насколько он измеряемо непродуктивен.
Прим. пер.: это перевод статьи The Worst Programmer I Know Дэна Норта.
Мы работали в хорошо известной программной консалтинговой компании на Большой Банк, решившей ввести метрики личной эффективности «в целях анализа и личностного совершенствования». Система распространилась на всю организацию, а до нашей команды дошла в виде показателя реализованных сторипоинтов. Это произошло после вдумчивого обсуждения с менеджером отдела, знавшим, что нам не стоит измерять такие показатели, как строки кода и количество найденных багов, потому что люди запросто могут фальсифицировать их.
— УРА! Мы богаты! Да! Да! Да!
— Надеюсь, это стимулирует вас к нужному поведению.
— После обеда я напишу кода себе на новый минивэн!
Вместо этого мы должны были измерять количество реализованных стори, или это могли быть сторипоинты (оказалось, что это неважно), потому что они представляют ценность для бизнеса. Мы пользовались чем-то наподобие Jira: люди должны были указывать своё имя напротив стори, благодаря чему мы очень легко могли генерировать эти метрики продуктивности.
И это возвращает нас к Тиму. Оценка Тима всегда была равна нулю. Нулю! Она не была просто низкой и не стремилась вниз, а в буквальном смысле была нулевой. Неделя за неделей, итерация за итерацией Тим получал ноль очков.
Было очевидно, что Тима нужно увольнять. К такому выводу пришёл менеджер, и он попросил произвести необходимые приготовления для увольнения Тима и замены его на того, кто сможет выполнять стори.
Я без лишних слов отказался. Это даже не было трудным решением для меня, я просто сказал «нет».
На самом деле, причина нулевой оценки продуктивности Тима заключалась в том, что он никогда не записывался ни в какие стори. Вместо этого он проводил свой день, взаимодействуя с разными участниками команды. При работе с менее опытными разработчиками он терпеливо позволял им брать управление на себя, в то же время подталкивая их к правильному решению. Он не погонял и не подталкивал их, а давал им время на обучение, аккуратно готовя к моментам озарения и получения опыта, часто при помощи сократовского диалога: «Что если мы сделаем так? Как ещё это можно сделать?».
С сениорами его взаимодействие напоминало совместное творчество и спарринг: они привлекали разные взгляды на мир для решения проблемы, чтобы создать что-то более качественное, чем каждый из нас мог придумать по отдельности. Тим — потрясающий программист, и при совместной работе с ним всегда узнаёшь что-то новое.
Тим не создавал ПО; Тим создавал команду, которая создавала ПО. Вся команда в целом становилась более эффективной, более продуктивной, согласованной, идиоматичной и интересной, потому что в ней был Тим.
Я объяснил это всё менеджеру и пригласил его время от времени приходить и наблюдать за нашей работой. Каждый раз, когда он приходил, он видел, что Тим общается с кем-то новым, работающим над «своей» задачей, и вы могли быть уверены, что качество решения этой задачи будет существенно выше, а время реализации существенно ниже — да, можно делать одновременно лучше, быстрее и дешевле, для этого лишь нужна дисциплина — чем когда Тим не взаимодействовал с людьми.
В конечном итоге мы оставили Тима в команде и спокойно отказались от метрик личной продуктивности в пользу отчётности всей команды, когда нужно отслеживать пользу для бизнеса, которую мы обеспечиваем в организации как единая высокопроизводительная единица.
tl;dr
Измеряйте продуктивность любыми способами (я обеими руками за отчётность); в идеале это должен быть показатель пользы для бизнеса, выраженный в сэкономленных или заработанных деньгах, а также в сокращённых расходах. Обычно это сложно определять, поэтому вполне можно использовать и вспомогательные метрики.
Просто не пытайтесь измерять личный вклад единицы в сложной адаптивной системе, потому что сама постановка вопроса ошибочна.
Например, метрики DORA связаны с тем, как работает система работы, будь то показатели культуры Вестрама или поток технических изменений в продакшене. Они измеряют показатели двигателя, а не вклад отдельных поршней, потому что это не имеет никакого смысла.
И ещё: если у вас появится шанс поработать с Тимом Маккинноном, сделайте это.
Комментарии (84)
MiraclePtr
03.09.2023 08:18+19Знакомо. Я сейчас в команде именно такой Тим. В Jira в статистике спринта у меня тоже может быть ноль или около того стори-поинтов, но когда нужно что-то спроектировать, поревьюить, разобраться в требованиях, помочь реализовать, решить проблему, которую никто не может решить - все идут ко мне. Наш PM по-моему уже даже забил на идею спрашивать у меня на дейликах "а что ты вчера сделал?", за меня теперь говорят остальные члены команды.
uuger
03.09.2023 08:18+70Главное, чтобы остальные участники процесса разделяли вашу оценку. У меня был коллега, который считал себя интеллектуальным центром команды, занимался, в основном, критикой и "наставничеством", как он это называл, но, когда по требованию менеджмента его перевели в другую команду, скорость и качество разработки заметно возросло. Интеллектуал же остался уверен, что с ним обошлись крайне несправедливо.
Я не говорю, что вы можете быть таким же человеком, просто очень полезно иметь какой-то объективный способ оценки собственной деятельности, если обычные KPI и метрики к вам по какой-либо причине неприменимы. Иначе самооценка может подвести в самый ненужный момент.
ti_zh_vrach
03.09.2023 08:18просто очень полезно иметь какой-то объективный способ оценки собственной деятельности
Вам объективный или решающий проблему? Это не всегда одно и то же. Есть же вот:
за меня теперь говорят остальные члены команды.
uuger
03.09.2023 08:18+3за меня теперь говорят остальные члены команды
это работает до тех пор, пока команду не накроет что-то подобное эффекту Рингельмана
ti_zh_vrach
03.09.2023 08:18Это же ортогональный вопрос. Если численность команды настолько раздувают, то проблема точно не в подборе способа оценки эффективности. Или я не прав?
BugM
03.09.2023 08:18+2за меня теперь говорят остальные члены команды.
А вот это максимально странно. Обычный разработчик не очень любит говорить. У вас есть специальный человек у которого вся работа это говорить. И он почему-то не говорит.
Выглядит так что ему не на дейлики ходить надо, а выступления побольше и пореже готовить. От защит новых проектов и рефакторинга с разными архитектурными решениями, до рассказов как все хорошо поработали и почему надо выдать премию.
Politura
03.09.2023 08:18+8когда нужно что-то спроектировать, поревьюить, разобраться в требованиях, помочь реализовать, решить проблему, которую никто не может решить
Что мешает заводить тикеты в жире на эти задачи?
Ну кроме как тикеты на ревью, они не нужны, да и ревьюить должен не один человек у всех, а все, включая джуниоров.(В смысле, не вся команда каждый PR, а один-два-три ревьювера на PR, но разные люди, а не всегда один и тот-же человек).
xtended
03.09.2023 08:18У нас есть тикеты на ревью релиза. Лид с аналитиком сидят и проходятся по новому коду, сравнивая с конфой. Вроде вполне себе причина для тикета, так как нужно чтобы еще один человек время выделил, да и это может растягиваться на часы
select26
03.09.2023 08:18+4спрашивать у меня на дейликах "а что ты вчера сделал?"
Забавно: почему то обратил внимание в комментарии именно на это.
У нас на Дейли не спрашивают о вчера, а делятся планами на сегодня и завтра. Для observability и transparency внутри команды. Когда открывается новый спринт, мы все делаем короткий бриф о планах. А потом ежедневно его корректируем и делимся с членами команды . Но уровень команды высокий. Очень высокий. И менеджмента тоже.
Может быть в этом дело.
ValeryGL
03.09.2023 08:18Верно. Если на дейликах нужно рассказывать, что делал вчера - вопросы к прозрачности.
mini_nightingale
03.09.2023 08:18А если я вчера брал задачи, делал. И даже доделал все что брал.
Разве у меня не будет только один план - "брать(с доски) и делать"?
Ну или у меня проект, но текушие задачи вроде всё, просто там осталось только "посмотреть\подумать что теперь делать"(ну рефакторинг, общение с заказчиком\начальником, уточнение требований, и т.д.)?
Звучит так, будто надо всеми силами показать бурную деятельность.
Ад для чоциофобов какой-то.
select26
03.09.2023 08:18Ты же в команде работаешь.
Задачи объемные и рассчитаны на темную кооперацию. Поэтому важно чтобы все члены команды были в курсе дел.
sshikov
03.09.2023 08:18+12На самом деле это же применимо ко многим другим метрикам. Например, у нас пытаются измерять time to market, при этом измеряльщики упорото считают, что ежели я завел в Jira задачу 1 января, открыл, и отложил на год, а реализовал 31 декабря, то TTM будет год. При том что совершенно очевидна возможность появления 2 января намного более важных для бизнеса задач, которые в итоге и были сделаны в течение года, и сделаны быстро.
MountainGoat
03.09.2023 08:18+16Круче, если поставил задачу 31 декабря, реализовал 1 января, а система пишет, что на неё ушёл год.
iig
03.09.2023 08:18+14Круче, если поставил задачу 31 декабря, реализовал 1 января, а система пишет, что на неё ушёл год.
Систему делали эффективные программисты ;)
dopusteam
03.09.2023 08:18+5Нужно замерять время не от даты открытия задачи, а от даты взятия её в работу, как вариант. Такой вариант сработает?
dph
03.09.2023 08:18+10(Нечаянно поставил минус, компенсировал плюсом на другом комментарии, извини).
Если всерьез, то ttm надо считать от появления идеи у бизнеса - и до появления фичи у клиента. И уже после этого считать время отдельных стадий на пути фичи. Считать же только время разработки - бессмысленно, оно редко является существенным относительно прочих затрат.dopusteam
03.09.2023 08:18+3Я имел в виду не от начала разработки считать время, а от начала активной работы по задаче.
Т.е. когда задача попала в бэклог задач мы ничего не считаем. Как только мы вытащили её оттуда и начали, условно, аналитику делать - часики начали тикать :)
Считать от появления идеи у бизнеса (читай, от попадания в бэклог) до появления фичи - как будто отдельная метрика, ибо как выше сказали, идея может быть не особо приоритетная и делается по остаточному принципу.
plFlok
03.09.2023 08:18+1Но ведь задачу могут вытеснить более приоритетной прямо посреди разработки, а потом вообще забыть на полгода.
И с одной стороны эти полгода не должны учитываться в ttm у разработки. Но с другой стороны - должны учитываться у бизнеса, ведь "новые влетающие задачи" могут быть серьёзной проблемой ttm. Особенно если посреди новой задачи влетают ещё более приоритетные.
В результате может получиться, что ttm - месяц, но за год у нас 1 релиз.
dopusteam
03.09.2023 08:18Но ведь задачу могут вытеснить более приоритетной прямо посреди разработки, а потом вообще забыть на полгода.
Ну это же ненормальная ситуация, если такое происходит часто. Если же такое случится раз другой - ну ок, увидим это на графиках и поймём, что всякое бывает.
p07a1330
03.09.2023 08:18+4В стартапах на начальных этапах сплошь и рядом
Везде, где работал в них - ситации типа "У нас горит %feature_name%, бросай все и подключайся чинить" были ежемесячно +-
ValeryGL
03.09.2023 08:18+1ТТМ - это показатель уровня продукта и рынка, которым все равно на ваш блеклог, другие задачи, менеджмент и состав команд
dph
03.09.2023 08:18Да, считать "время разработки" вполне осмысленно (если оно составляет больше трети от общих затрат). Я только против называния этого времени time-to-market, так как ttm от разработки зависит очень, очень мало )
sshikov
03.09.2023 08:18+1Я бы сказал, что вариант зависит от того, что именно мы хотим улучшить. Упрощенно — если ttm большой, потому что у нас не хватает ресурсов, чтобы делать задачи быстрее, и мы это заранее знаем — нас тот факт, что низкоприоритетные задачи лежат в жире годами, вообще никак не удивит, и ничего нового в нем для нас нет. И стоило ли его в таком виде мерять?
dopusteam
03.09.2023 08:18Если мы и так все знаем - то это конечно хорошо)
А если нет? Или если мы думаем, что задачи едут месяц, а на деле там по полгода? Ну и в целом, если у нас не хватает ресурсов, то метрики - это доказательство нехватки ресурсов. Хотя может там копнуть глубже и другие причины вскроются.
Но, в целом, согласен - мерять что то, что не несёт для нас новой инфы или то, что мы не сможем интерпретировать/понять/исправить - не нужно
sshikov
03.09.2023 08:18Если мы и так все знаем — то это конечно хорошо)
Не, ну не все конечно… но некоторые вещи достаточно очевидны. Изнутри хотя бы.
По сути, я хотел сказать примерно вот что: что мерять производительность и качество работы человеческого коллектива никогда не было просто. Даже в случае одного человека — описанного тут Тима, мы не знаем точно, что было бы, если бы его скажем убрали. У него была своя роль, вполне допускаю, что нетипичная.
pudovMaxim
03.09.2023 08:18+1А в чем ошибка измерения TTM? Идея->Реализация->Презентация. Вот и считают время от появлении идеи, до показа клиенту. Естественно, это показатель может быть только общий на всю компанию.
Время от "взял в работу" до презентации - это другой показатель. Вот, даже статью нашел:
https://habr.com/ru/companies/ligastavok/articles/677762/sshikov
03.09.2023 08:18+2Вот и считают время от появлении идеи, до показа клиенту.
И как вы это время собираетесь усреднять по всем идеям? Есть идеи и задачи, которые дают эффект отличающийся на пару порядков. Но при этом все они в Jira были заведены, и по ним тоже кто-то считал ttm. Какой смысл в показателе, куда входит время реализации задач, отличающихся по эффекту на сколько-то там порядков? Вы можете спросить, а зачем вы заводите такую мелочь в жиру? Так я вам отвечу — а почему нет? Вам что, жалко места в базе для их хранения? А эти люди, которые стали по ним что-то мерять — они пришли потом, и нам сразу не сказали, что будут мерять вот таким способом. А когда им намекнули, что так мерять может быть глупо, ответили что ничего менять не будут, хотите чтобы у вас ttm хорошо считался — сами у себя меняйте порядки в жире. Ну то есть, это тот случай, когда KPI важнее реальных процессов.
Естественно, это показатель может быть только общий на всю компанию.
Совершенно не естественно. Я вот не вижу, откуда это вытекает, особенно в случае инфраструктурного проекта типа нашего, который на бизнес влияет очень опосредованно. Это не значит слабо — это значит, что это влияние очень сложно оценить.
Время от "взял в работу" до презентации — это другой показатель.
Возможно что и другой. Но как я вижу на своем уровне — только он и имеет смысл для разработки. Ну просто потому, что доступные ресурсы команды ограничены, при этом нагенерировать вполне здравых идей мы спокойно можем на пару лет вперед — только сделать их за разумное время невозможно. А оценить, какие из них заведомо выстрелят — тоже невозможно зачастую, нужно хотя бы MVP. Ну то есть, у нас куча задач, которые лежат в жире годами.
pudovMaxim
03.09.2023 08:18KPI важнее реальных процессов
Ну да, когда неправильно применяют инструменты, то это к беде. Если на bash писать банковскую систему, то ни к чему хорошему это не приведет. Также как и с помощью TTM измерять KPI конкретного разработчика или отдела.
Но этот показатель есть расстояние по времени от появления идеи до получения клиентом. Хотите мерить что-то иное, берёте другой показатель. Как бизнес дальше работает с этими значениями - это на совести управленцев.
Какой проект, кто его потребители(внутренний продукт или внешний) не имеет значения. Метрика означает одно.
Размер задачи имеет значение, но тут нужно уметь правильно разбивать и анализировать.
Еще раз, TTM - это такая же метрика как и средняя продолжительность жизни человека. Вот от момента рождения, до смерти. Метрика работоспособного населения (аналог времени когда задача была в работе) - это уже другая величина.
sshikov
03.09.2023 08:18Ну, тут не то чтобы измеряют KPI разработчика — непосредственно до этого не дошло. Я скорее ворчу заранее, зная что наша бюрократическая машина зачастую склонна решать задачи управления самыми простыми (и самыми глупыми) способами.
igor_suhorukov
03.09.2023 08:18+8Формальными метриками выстлана дорога в зеленый бренд... Побольше метрик и базвордов!!!
mikronavt
03.09.2023 08:18Полагаю, что среднее или медиана по всем задачам в такой ситуации может быть более подходящим показателем.
sshikov
03.09.2023 08:18А чем это лучше-то? Ведь чтобы усреднять разные задачи, у них должен быть какой-то осмысленный вес. А его нет. Ну во всяком случае — у задачи в Jira его нет. Ну то есть, я могу себе представить такое исследование, но на базе обычной информации о задачах его провести совершенно невозможно.
Ну так, в качестве примера — вот у вас есть две задачи, одна blocker, а вторая minor. Как правило, первую вообще делают ASAP, потому что без ее решения что-то не работает как надо. А вторую можно вообще не делать, и никто не заметит. Ну то есть, в жизни реально есть задачи, ttm для которых вообще никому не интересен. Но в моем конкретном примере их учитывали одинаково.
mikronavt
03.09.2023 08:18Ну, среднее - это простейший случай. Так то согласен ,что задачи имеет смысл ранжировать по приоритету, возможно по сложности или еще как-то. Либо ставить тем задачам, по которым не ведется работа, статус on hold и не учитывать время в метриках.
Вообще, грамотно настроить метрики ,чтобы они приносили пользу проекту - непростая наука. И к сожалению, зачастую эффективные менеджеры в нее не умеют, а командам приходится подстраиваться и страдать.
Breathe_the_pressure
03.09.2023 08:18+7Т.е. проблема не в метриках совсем, а в руководстве. Очень хочу посмотреть на систему оценки руководителей, выставленную для всеобщего обозрения, в отдельно взятой компании.
Часто встречался, что у них выглядит как победа, так это неоспоримая заслуга руководства, как проигрыш, так команда виновата.
bak
03.09.2023 08:18+38Если Тима нанимали на решение бизнес задач, а вместо этого он "беседует с разработчиками", "помогает в архитектуру" и "улучшает эффективность" - значит должность этого Тима надо менять на "архитектор" / "ментор" / "тим-лид" / "проджект менеджер" в зависимости от того чем занимается Тим.
Очень часто вижу ситуацию когда "сениоры" вместо разработки (то есть создание фичей) скатываются в "помогательство". По факту в большинстве случаев это не сениоры а раздолбаи - трындеть, "помогать" и предлгать всякое разное намного проще чем отвечать за что-то и делать самому. Особенно этим грешат всякие говнокодеры которые пилят архетктуру в которой никто кроме них не разберется, а потом занимаются "помогательством".
PS. Так и оказалось. Если открыть CV Тима то можно увидеть что он в большинстве мест был "Consultant" / "Agile Coach" / "Founder" / "Director", а "developer-ом" был всего в паре мест.
Vytian
03.09.2023 08:18+6Страшные вещи говорите! Так дойдет до того, что руководству придется разбираться, как работают их подчинённые, и, страшно сказать, как и почему в их епархии всё устроено. Не-не-не, Дэвид Блэйн.
А если серьезно, то стори поинты и прочий таймшиттинг имеют смысл только в функциональной деятельности. Если они начинают определять оригинальную разработку и кадровую политику, то, значит, руководитель теряет/ уже потерял контроль, или вообще связность в оргацизации разрушается и надо либо чинить, либо реорганизовывать.
bak
03.09.2023 08:18+4Суть здесь не в стори поинтах, а в том что разработчиков обычно нанимают пилить фичи. Если разработчик 100% времени занимаются чем угодно только не этим - появляется обоснованное сомнение, а точно ли это разработчик и нужен ли он команде.
dph
03.09.2023 08:18Не, если разработчика нанимают "пилить фичи", то в компании скорее всего не очень хорошо с процессами и пониманием разработки. Вот если нанимают "приносить пользу компании" - это как-то логичнее.
Обсуждение фичи с заказчиком часто (почти всегда) оказывается в разы более эффективным инженерным действием, нежели фигачить код.
Kanut
03.09.2023 08:18+7Вот только "обсуждение фичи с заказчиком" это далеко не всегда задача именно разработчика. То есть в отдельных фирмах фичи с заказчиком обсуждают одни люди, пилят другие, тестят третьи, документацию пишут четвёртые и так далее и тому подобное. И такой подход тоже вполне себе работает.
titbit
03.09.2023 08:18+12Очень часто вижу ситуацию когда "сениоры" вместо разработки (то есть создание фичей) скатываются в "помогательство".
Так это из-за "инфляции" синьоров. Во многих местах им дальше просто некуда расти в техническом смысле, вот люди и переключаются на менторство, архитектуры и т.п. И если в компании таких должностей формально нет, а по факту они есть - это повод пересмотреть организационную сетку.
vdshat
03.09.2023 08:18-9Пардон, а что значит:"Некуда расти в техническом смысле?" Он достиг просветления и постиг дао?! Все зависит только от личных горизонтов познания. Скорей все "помогатор" либо уперся в пределы своих знаний и лень дальше расти либо просто паразит по природе. Чаще всего с уходом такого персонажа ничего неменяется в команде, т.к. он ничего и не проиводил, а только изображал работу
MountainGoat
03.09.2023 08:18+11То есть, если сотрудник достиг предела своей компетенции, его надо уволить?
Fen1kz
03.09.2023 08:18+2Ну да, а то он не будет расти. Зачем нам сотрудники без роста?
И нанять за его зп 8 джунов. sova.jpg
Ivan22
03.09.2023 08:18+2так и происходит. Достиг передела - перестали повышать зп - он собрался и ушел в другое место.
Xambey97
03.09.2023 08:18+3Было дело, когда был еще крепким джуном и работал в одном НИИ за маленькую зп, к нам в департамент добавили фронтенд тех лида. Я через 10 минут общения с этим типом по своему проекту на Angular (на тот момент мой опыт фронтенда после 5 лет бека был 3 месяца) понял (а он был заявлен как профи в ангуляр), что он знает во фронтенде меньше чем я, хотя мой опыт ангуляра тогда был в пару месяцев (особенно хорошо это видно с высоты моего нынешнего опыта). Все что выдало это 'чудо' за 2.5 года, помимо пустого трепа и лобызаний перед начальством, это 2 пдф файла с картинками дизайна... Ни ревью... Ни проработки архитектуры... Многие архитекторы были им недовольны, но начальство закрывало глаза все время, пока само начальство не свалило из-за того, что поймали на сдачи проектов в подряд для отмывки... Ничего, только хождение на совещания с высшим руководством (которое его и поставило, Ха-Ха). А ведь этому человеку, платили как 10м джунам как минимум... (зп у джунов тогда были ни к черту там) Пошел наверное в какое-то другое место гнездиться. С тех пор я правда настолько нулевых 'тех лидов' не встречал, надеюсь не встречу более и желаю никому в такое не вляпаться...
Nikita_ele
03.09.2023 08:18+1Все верно. Могу предположить, что руководство компании как и автор статьи держали этого парня на более низкой должности формально, чтобы не повышать ему зарплату) А сам он мог этого не понимать, так как руководство не давало никакой обратной связи и никогда не поощряло его. Повсеместная ситуация во многих компаниях, к сожалению.
BugM
03.09.2023 08:18-2Тим у вас тимлид/архитектор/менеджер или вы готовы его перевести на соответствующую позицию? Если нет, то увольнять. Такие добровольные помогаторы обычно вредят больше чем помогают. Особенно если их не готовы переводить на соответствующие позиции и могут это обосновать.
voidMan
03.09.2023 08:18+23Почему не выставили ссылку на оригинал и не пометили как "Перевод"? Оригинальная статья тут - https://dannorth.net/2023/09/02/the-worst-programmer/
PatientZero Автор
03.09.2023 08:18+4Прошу прощения, моя оплошность. Теперь редактор не даёт менять тип публикации, указал ссылку на оригинал после ката.
Zara6502
03.09.2023 08:18+2не понял две вещи - почему менеджер вообще не в курсе что происходит в отделе и почему Тим не может сказать за себя, а его еще и увольняют тайно без разговоров?
avost
03.09.2023 08:18не понял две вещи - почему менеджер вообще не в курсе что происходит в отделе
Это же команда консалтинга. Менеджеру исходного отдела не обязательно знать что происходит в нанятой сторонней команде. Это делегировано лиду команды от лица которого идёт повествование. Это разумно. Но менеджер таки хочет быть в курсе, поэтому и ввёл метрики. Это неразумно, но так бывает - мы живём не в мире эльфов.
почему Тим не может сказать за себя, а его еще и увольняют тайно без разговоров?
Почему без разговоров? Менеджер отдела пришёл сначала обсудить непонятную для него ситуацию с непосредственным лидом Тима. Прийти СНАЧАЛА к Тиму, а ПОТОМ к его лиду было бы верхом глупости.
Zara6502
03.09.2023 08:18+1Почему без разговоров? Менеджер отдела пришёл сначала обсудить непонятную для него ситуацию с непосредственным лидом Тима. Прийти СНАЧАЛА к Тиму, а ПОТОМ к его лиду было бы верхом глупости.
нет, написано что он пришел его увольнять, то есть он принял решение на основании цифр а не их разбора. То что лид смог его отстоять тут скорее странность. Я вижу ситуацию так, приходит менеджер к лиду и спрашивает почему у такого-то плохие показатели. а решение принимает по результату разговора.
Менеджеру исходного отдела не обязательно знать что происходит в нанятой сторонней команде
Тогда зачем менеджеру знать об отдельном члене команды, логично оценивать ее эффективность в целом. Что они и сделали позднее.
avost
03.09.2023 08:18нет, написано что он пришел его увольнять, то есть он принял решение на основании цифр а не их разбора.
Там так же написано, что команда (или её лид) согласилась использовать эти метрики после вдумчивого обсуждения почему их прежние метрики были вообще какой-то дичью.
Тогда зачем менеджеру знать об отдельном члене команды
Потому, что он платит деньги и не понимает за что. По согласованным с командой метрикам у чувака всё по нулям - зачем ему платить?
Zara6502
03.09.2023 08:18+3команда (или её лид) согласилась
речь же не про команду, а про то, что человек принял решение об увольнении сотрудника до того, как будет разобрана ситуация.
У меня в трудовой три вкладыша, 25 лет работы в разных местах и я только однажды встретил идиота, который о качестве работы человека судил по количеству галочек в сервис деске. Но даже он не заводил разговора об увольнении, а пришел ко мне с вопросами.
Потому, что он платит деньги и не понимает за что
Я уже написал об этом в самом начале. Так является ли это проблемой работников? Он свои косяки в работе перекладывает на плечи нанятых людей. Вообще нонсенс когда работник еще и должен доказывать что не зря получает зарплату и самое печальное, что сами работники считают это нормальным.
Простой пример, вам нужно сделать забор на даче, вы платите бригаде по договоренности Х рублей и вам его ставят. Если вам сделают только половину забора или сделают вместо забора сарай, то вы об этом узнаете.
В контексте ИТ отчеты должны писать единицы, ответственные за управление, а не конечные исполнители. Многие не знают, но в менеджменте персоналом задача мониторинга исполнения работы лежит на руководителе. Написание отчета это вообще отдельный скилл и он явно не входит в обучение айтишника (так как я был начальником техподдержки и мы сопровождали SD, то читать отчеты инженеров было всегда забавно и тут либо они пишут так что в этом нет смысла, но быстро, а могут писать более менее складно и вдумчиво, но убивая кучу времени на это). Скажем я служебку пишу минуты три, а большинство вязнет еще на этапе оформления шапки, но, внезапно, я этому обучался год в универе - нас учили писать документы. И я учился на экономиста, а не на айтишника. Да сейчас даже юристы друг с другом обмениваются "рыбой" и сами никакие документы толком оформить не в состоянии.
По согласованным с командой метрикам у чувака всё по нулям - зачем ему платить?
Как бы вам объяснить. У адекватного владельца бизнеса равно как у его наёмных руководителей первая задача - это не экономия средств. Всё же они тут бизнес запустили и первая задача - заработать денег. И когда менеджер пришёл увольнять сотрудника знали ли он, что увольнение Тима навредит бизнесу? Нет, не знал. То есть повторю еще раз, он не выполнял свои обязанности и свои косяки переложил на плечи других. Ну уволил бы он Тима, через пару месяцев показатели бы упали вниз, а так как он дурак, то никакой связи с Тимом он бы не увидел. Это же "эффективный" менеджер. Он бы опять переложил ответственность на команду. И так по всей цепочке вверх - нифига они не знают, но увольнять бегут аж волосы назад. Они же потом график нарисуют и наверх напишут какие они молодцы, получат свою премию и буду попивая бренди всем рассказывать какие они эффективные.
avost
03.09.2023 08:18речь же не про команду, а про то, что человек принял решение об увольнении сотрудника до того, как будет разобрана ситуация.
Да, нет, речь именно про команду, которая после ВДУМЧИВОГО обсуждения согласилась на данные условия. Условия не были выполнены, нужно принимать меры. Что не так?
Сотрудника он не уволил, а спросил лида - чё за фигня творится. Правильно спросил - команда подписалась под то, что не выполняет.Я уже написал об этом в самом начале. Так является ли это проблемой работников? Он свои косяки в работе перекладывает на плечи нанятых людей.
Да, является. Если работник не выполняет договорённостей, это проблема работника.
Вообще нонсенс когда работник еще и должен доказывать что не зря получает зарплату
Вы ещё скажите, что это нонсенс, когда работник должен работать. Ну, а чё - я же пришёл на работу, а ты начальник, сам и доказывай себе, что не зря мне платишь. Так что ли?
У адекватного владельца бизнеса равно как у его наёмных руководителей первая задача - это не экономия средств. Всё же они тут бизнес запустили и первая задача - заработать денег.
Когда денег зарабатывается меньше, чем тратится - это проблема. Странно, что вы, как экономист этого не понимаете.
И когда менеджер пришёл увольнять сотрудника знали ли он, что увольнение Тима навредит бизнесу?
Это далеко не факт. Мы знаем об этом только из рассказа друга этого Тима.
То есть повторю еще раз, он не выполнял свои обязанности и свои косяки переложил на плечи других.
Ничего подобного. Он увидел халявщика и пошёл с ним разбираться. Это халявщик переложил свои обязанности и обязательства на которые сам подписался на тимлида.
И так по всей цепочке вверх - нифига они не знают
Откуда ж им знать, если самое низшее звено халявит и нарушает договорённости, а его непосредственный начальник его покрывает. Вы правда считаете, что топ-менеджер должен сидеть и смотреть, как Тим гладит кого-то по головке и от этого поглаживаемому якобы становится легче? Да, чушь собачья!
буду попивая бренди всем рассказывать какие они эффективные.
если благодаря их работе им хватает на бренди, то что же здесь неэффективного?
Zara6502
03.09.2023 08:18+1Да, нет, речь именно про команду, которая после ВДУМЧИВОГО обсуждения согласилась на данные условия
То есть люди, которые не являются профессиональными управленцами, приняли какое-то там решение, что с профессионального управленца автоматом снимает ответственность? Каждый должен заниматься своим делом, ну и повторюсь - если запустили новую оценочную систему, то сначала разговор, а потом увольнение.
Условия не были выполнены, нужно принимать меры. Что не так?
Ну если управленец дебил (а мы уже поняли что он именно такой), то конечно, нужно всех увольнять.
Сотрудника он не уволил, а спросил лида - чё за фигня творится
Так, стоп. Я дико не люблю когда перевирают. Вот вам цитата из текста:
"Было очевидно, что Тима нужно увольнять. К такому выводу пришёл менеджер, и он попросил произвести необходимые приготовления для увольнения Тима и замены его на того, кто сможет выполнять стори.
Я без лишних слов отказался"
То есть менеджер разбираться не хотел и Тиму повезло, что автор оказался таким принципиальным человеком. Был лизоблюд приспособленец - и Тим пошел бы гулять на улицу.
команда подписалась под то, что не выполняет
Это не так работает. Оценка эффективности работы - это прерогатива владельца бизнеса или того, кого он нанял за этим следить. Если кто-то внедряет какую-то фигню, а потом вам не платит или увольняет по принципу - ты сам подписался, то бегите из того места без всякого сожаления.
Как я написал выше - команда может состоять зи хороших программистов, но в управлении персоналом или оценках эффективности работы они вообще могут не разбираться, это не их профессия.
Да, является. Если работник не выполняет договорённостей, это проблема работника
Ох, я бы вам не доверил управление коллективом. Работник суть существо хаотичное и бестолковое, придерживайтесь этой парадигмы. Именно поэтому у работника есть руководитель. Это не просто мужик с более высокой зарплатой - это, внезапно, тот, кто руководит. Один работник когда сломал метлу сидит и грустит, второй идёт за новой метлой, а третий - устранит саму причину поломок или снизит их число. А задача руководителя чтобы бизнес работал, а не чтобы потом увольнять всех тыкая пальцем в подписанные бумажки, когда и время упущено и прибыль и качество команды на нуле.
Вы ещё скажите, что это нонсенс, когда работник должен работать. Ну, а чё - я же пришёл на работу, а ты начальник, сам и доказывай себе, что не зря мне платишь. Так что ли?
Доказательство одно - работа выполнена. Если руководитель не в состоянии определить выполнена она или нет, то я даже не знаю что еще можно сделать в такой ситуации. Опять пример с забором на даче - вам показывают забор, а вы такой - докажи что забор есть. Если ваш начальник не видит результат вашей работы, то чем ему помогут ваши отчеты? Он же все равно не поймет ничего и не сможет определить фейковый отчет или нет, так как и работа и отчет сделаны вами, а он в этом не разбирается. Ну давайте сделает отчёт на отчёт - смысл не изменится.
Когда денег зарабатывается меньше, чем тратится - это проблема. Странно, что вы, как экономист этого не понимаете
Я, как экономист, как раз понимаю в чем ошибка ваших рассуждений, но сможете ли вы понять? Когда вы зарабатываете меньше, чем тратите, то это не причина, а следствие, как говорят - поздно пить боржоми. Вы когда нанимаете команду, то вы делаете это не просто по желанию, а на основании расчётов. Себестоимость, спрос, объем рынка, реклама и т.п. Это всё делает не команда программистов, а владельцы или их наемные управленцы и экономисты. Соответственно им же и отвечать. Кто определил что в команду программистов нужно 5 человек, 7, 8, 20? Это был конкретный человек, не программисты появились из неоткуда и самонанялись. Вот кто принимал решение что им нужна команда из Х человек для решения задачи Y, тот и несёт ответственность. Следить за ходом выполнения? Да сколько угодно, в это же суть менеджера. Но как мы видим, он вообще не в теме.
Я абсолютно согласен что подавляющее большинство НЕДОуправленцев первым делом кидаются сокращать штат. Это просто, новый график "эффективности" и "экономии", премия себе любимому. Но так делают дураки. Если задача решается с помощью 10 человек, то можно ли её решить 9-ю? А через пару месяцев встанет вопрос - а зачем нам 9? А через год останется 5. И бизнес думает что решение было верным. Но так далеко не всегда. У вас растёт текучесть кадров, потому что мало кому нравятся переработки. А если вы планируете переработки компенсировать премиями, то не ясно - почему вместо премии нельзя нанять еще людей. Люди не железные - больничные, семьи, просто смерть - обстоятельства не спрашивают чего вы там напланировали. Но вы можете дублировать важные части проекта имея двух специалистов например.
Оптимизация расходов это вообще другой разговор.
Это далеко не факт. Мы знаем об этом только из рассказа друга этого Тима
В контексте разговора это состоявшийся факт. Давайте будем обсуждать его, а не все гипотетические ситуации на Земле.
Ничего подобного. Он увидел халявщика и пошёл с ним разбираться
Нет. Он увидел в системе отсутствие буковок и циферок и почему-то решил, что именно это что-то определяет. Поэтому я и говорю, что после внедрения системы нужно следить за её работой и её качеством оценки. И он не пошел разбираться, он тупо сказал автору произвести увольнние.
Откуда ж им знать, если самое низшее звено халявит и нарушает договорённости
Ну автор же нам написал что никто не халявит. После установки программы по оценке эффективности может пройти много времени прежде чем она даст релевантные данные.
а его непосредственный начальник его покрывает
Хм, если критерий эффективности не совпадает с вашим, то все вокруг преступники? А вы уверены что ваши критерии отражают суть вещей?
Вы правда считаете, что топ-менеджер должен сидеть и смотреть
Во-первых, в статье нет топ-менеджеров. Во-вторых, если топ не имеет никого под собой чтобы заниматься этим, то да, это его работа, иначе бизнесу хана.
как Тим гладит кого-то по головке и от этого поглаживаемому якобы становится легче?
На самом деле такая же история была еще в 90-е, вот не помню где именно, то ли в HP то ли в IBM. Менеджер увидел как работники постоянно торчат на этаже у кофе автомата и автомат убрали, за пару месяцев упала производительность труда, наняли фирму для анализа ситуации и выяснили, что программисты у кофе автомата болтали каждый о своей проблеме и помогали друг другу найти решение. Но я вижу явную разницу между тем какая была реакция в этой статье и в моей интерпретации старой истории - шли поиски причин, никто никого просто так не увольнял.
если благодаря их работе им хватает на бренди, то что же здесь неэффективного?
Вы эффективность менеджера оцениваете размером его дохода? Ну такие эффективные сейчас у нас чиновники, что просто смешно, с доходом у них полный порядок, значит я могу расслабиться и не париться по поводу грязи на улице и разбитому асфальту.
Pavel1114
03.09.2023 08:18+1нет, написано что он пришел его увольнять, то есть он принял решение на основании цифр а не их разбора
возможно автор в угоду драматизму немного преувеличивает - такое бывает когда пишешь success story со своим участием
GospodinKolhoznik
03.09.2023 08:18+1А зачем ему быть в курсе что происходит в отделе? К черту детали - у него есть отличные KPI метрики, на основании которых он принимает эффективные менеджерские решения. New wave - black box management style!
Это была ирония))
Zara6502
03.09.2023 08:18+9Никогда не понимал системы отчетности, человек нанят на работу и ему эту работу должны обеспечивать, то есть над ним стоит человек который знает какую он работу должен выполнить и в каком объеме, а еще и контролировать его работу, то есть отчет как таковой это результат работы зафиксированный вышестоящим руководителем. Иначе написание отчетов становится отдельным видом работы с неизвестным сроком исполнения, длительностью и качеством. То есть у меня нет задачи делать работу, у меня задача сделать хороший отчет.
А еще, хорошо что в статье об этом указано, забавно, когда качеством называют строки кода или устранение багов. Автоматически становится ясно что нудно писать код так, чтобы строк было много, и чтобы регулярно были баги.
sim31r
03.09.2023 08:18Автоматически становится ясно что нудно писать код так, чтобы строк было много, и чтобы регулярно были баги.
К качеству кода могут быть отдельные требования. И разработчик что исправляет баги может быть отдельный.
У нас вот на одном из проектов было так, если баги по нашей вине, исправляет компания за свой счет. Если баги по вине заказчика, не прописал условия в ТЗ или бизнес модель изменилась, то заказчик оплачивает доработку. Программисты все равно получали зарплату, но за доработки могли получить премию. За исправление багов только обычная зарплата.
panzerfaust
03.09.2023 08:18+6Работал я с таким Тимом однажды. Кодить ему не хотелось вообще. Но это полбеды. Взыграла у него тяга к педагогике. Дай, говорит, найму целую пачку джунов да буду их менторить на максималках, а сам ничего делать не буду. Сплошное делегирование, доверие, взращивание ответственности и т.д. В итоге нанял трех джунов, позволил им устроить на проекте лютый трэш, а через 5 месяцев ушел в закат со словами "Моя миссия здесь завершена".
Полгода спустя джунов уволили, самый жесткий ущерб от говнокодинга и говноархитектуры пофиксали. До сих пор тепло вспоминаю селект с 14 джойнами, который был написан одним из джунов и одобрен Тимом. После рефакторинга, к слову, 2 джойна осталось.
А от Тима не осталось ни строчки кода, ни статейки в доках, ни даже PDF с "видением". Был сотрудник, не было - не понятно.
nmrulin
03.09.2023 08:18+1Борьбе за метрики напоминает борьбу за коэффициент KDA в некоторых играх. С тем же печальным результатом.
khe404
03.09.2023 08:18+1Люди размышляют о том как оценить работу и эффективность. Как и в сообществе зверей слабых заклевывают, сильные получают лучший кусок.
Но, если посмотреть на картину глобально, то окажется что одним из основных стимулов заставивших человека добраться до вершины пищевой цепочки является слабость новорожденного, который, в отличии от новорожденных других видов вообще не способен к самостоятельному существованию. Даже голова не держится и нужно ее осторожно придерживать. Кто там еще на вершине? Вирусы? Грибы? Что нас от них отличает?
Избавляясь от слабых мы в какой то мере стратегически убиваем перспективу. Кто сказал, что вот этот неэффективный сегодня специалист не станет ключевой причиной развития?
А зачем вообще поддерживать старых, больных, немощных? Нужно всех измерить, сравнить с критерием и наступит счастье…Приведенные рассуждения сильно утрированы, чтобы показать насколько опасен выбранный путь. Измерили, уволили всех плохих и стало лучше. Нет, хорошо будет только тогда, когда получится создать гармонично развивающуюся группу. Когда люди не конкурируют за, но поддерживают друг друга, и это несколько другой уровень развития.
Только в человеческом обществе поддерживают старых и больных и это характеризует отличный духовный уровень развития. Вот ежели бы вопрос ставился не о том как измерить неэффективных сотрудников, а как помочь неэффективному стать лучше…
Вот тут где-то зарыта собака. Но мы думаем о КПИ...
Nikita_ele
03.09.2023 08:18+1В хороших современных компаниях происходит так, как вы пишите. Практика уже давно показала, что эффективность работников растет, когда они находятся в психологически благоприятной атмосфере. К сожалению, у нас такой подход только начинает развиваться. Сфера ИТ развивается быстрее, а в некоторых отраслях процент таких компаний пока стремится к нулю. Надеемся на светлое будущее.
BugM
03.09.2023 08:18То есть тех кто плохо работается нельзя увольнять? Или я вас неверно понял? А как тогда мотивировать работать хорошо? Допустим премия человеку не нужна, ему и зарплаты хватает.
Nikita_ele
03.09.2023 08:18между увольнять и не увольнять еще много разных категорий... не надо ко всему применять бинарную логику)
BugM
03.09.2023 08:18Поговорить это понятно. Лишить стандартной выдающейся примерно всем премии тоже понятно. Предположим это не сработало. Что дальше?
Плохо это именно об этом. Человек перекладывает джейсоны в три раза медленнее соседей с той же зарплатой и в три раза медленнее чем это все кому положено оценили. На разговоры что стоило бы работать получше не реагирует, на лишении премии не реагирует. Следующий рычаг это уволить. Ч других не знаю.
Nikita_ele
03.09.2023 08:18Если других вариантов не остается, то увольнять конечно) Что касается случая из статьи - там сотрудник выполнял функции, предусмотренные не его должностью, а должностью повыше, хотя формально оставался на своей. Соответственно, к нему эти показатели применять было не корректно. Об этом знал его непосредственный начальник (который по этой причине и решил его не увольнять), но не знал руководитель повыше, который смотрел только на цифры. Бардак в общем)
А что касается большинства современных условий труда, то там и до "поговорить" очень редко доходит. Обычно все заканчивается взаимными претензиями и неприязнью.
Zara6502
03.09.2023 08:18Например "эффективный" менеджер, разваливший коллектив на одном их моих мест работы был абсолютно уверен и не скрывал и открыто об этом говорил, что техник, обслуживающий 32 аудитории - проекторы, интерактивные доски, сеть, файлы, софт и т.п. в общем самый обычный эникей - пьющий чашку чая - это дармоед укравший денег у работодателя.
троих уволил, теперь инженеры выполняют функции техников, без доплаты конечно. двое инженеров ушли, еще одна в декрет, один умер (бывает), начальник наверное получил премию за сэкономленные ставки.
а сегодня с одной из оставленных мной работ позвонили и сказали такую фразу - вы должны приехать и показать новому админу как там всё устроено. а я там не работаю уже ТРИ месяца, уже по вацапу рассказывал всякое предыдущему админу который пришел после меня и всё там поломал. Мне платить не хотели и не хотят. Идут лесом теперь.
Zara6502
03.09.2023 08:18Человек перекладывает джейсоны в три раза медленнее соседей с той же зарплатой и в три раза медленнее чем это все кому положено оценили
у меня сразу вопрос к тому кто его нанял изначально.
пример мой, личный, я админ win/lin, пришел на завод, четверых коллег сократили/уволили, я один остался на 350 ПК разбросанные по 4 корпусам, сеть - 4 независимых сегмента, одноранговая. За 5 лет моей работы: (всё сделал в первый год, потом просто пользовался тем что сделано)
сервер Hyper-v, 5 виртуалок, почта, squid
1C
куча всяких серверов с hasp (несовместимых версионно)
внутрянка на оптику и DSL, заменено 4 бухты кабеля, убрано два десятка soho свичей и заменено на управляемые HP
ладно, всё писать долго. В общем посадили меня делать какую-то хитрую таблицу Excel, долго объяснял что мне это давать не нужно, Excel не мой инструмент, я кроме таблички и автосуммы там ничего делать не умею. Но вечное "тыжпрограммист" в их пустых бошках не победить. Сел, делаю, через час примерно заходят забрать промежуточные результаты, у меня условно готов 1%. У них истерика, мол должен был сделать 20%, мол есть вон Света, она уже 30% сделала. Я предложил всё и отдать Свете и не парить мне мозги.
Табличку у меня забрали и больше не лезли, уволить не захотели.
Это вопрос к тому, что ваши джейсоны точно сел делать профи в этом деле или как всегда наняли за копейки студентов наивно полагая что это делать умеют все и одинаково бюыстро? Так это фейл того кто нанимал. Понятно что уволите, но я бы уволил вместе с ним и того кто его принял.
BugM
03.09.2023 08:18Да обычный мидл, на обычной зарплате мидла, с обычного рынка мидлов, после обычного собеседования и обычного испытательного срока. И специализация обычная, веб и он есть веб. Откуда вы всю эту дичь взяли?
Zara6502
03.09.2023 08:18Откуда вы всю эту дичь взяли?
А что вас не устраивает? Вы хотите какой-то стандарт разбора джейсонов по секундомеру? Вам именно это нужно? Может это ввести как критерий при отборе кандидатов? Что значит "обычный"? Я за все годы работы ВСЕГДА устраиваясь системным администратором еще НИ РАЗУ не делал однотипную работу, если не считать базовые инструменты вроде пинга, телнета и трейсроута, но кто-то так же мог бы сказать - да обычное системное администрирование. Может и ваш мидл 10 лет проработал и ни разу никаких джейсонов в глаза не видел (как я например).
PS: а вы скорость набора текста на клавиатуре проверяете? просто я печатаю смотря на клавиатуру и довольно медленно, а потом поднимаю глаза и перечитываю написанное. Вообще ни разу не пригождался быстрый набор на клавиатуре, я думаю и генерирую код медленнее чем печатаю, так что никогда это не было проблемой. А тут оказывается стандарты скорости какие-то появились.
А как тогда мотивировать работать хорошо? Допустим премия человеку не нужна, ему и зарплаты хватает
Не всем же быть трудоголиками. Выставите критерии качества и если человек не соответствует - увольняйте, но вообще эти критерии должны быть в самом начале еще до трудоустройства, собственно мой пример именно об этом.
khe404
03.09.2023 08:18Вы меня поняли не совсем верно. Нельзя это неправильное слово, можно.
Но будет ли это наилучшим решением?
Почему ваш гипотетический человек не стремится работать лучше? Может ему что-то мешает? А может работа которую в этой команде делают не нужна ему/никому?Пожалуй, в этом не должен разбираться работодатель и лидер маленького коллектива, но тогда кто?
Вы подобрали на улице котенка, он вам понравился, он бегал и сломал лапку, теперь этот котенок инвалид. Нужно ли его кормить, кто должен его кормить? Так же и сотрудник устраивал вас когда-то, а сегодня он вас раздражает. Почему?
Да потому что он не вписывается в какие-то рамки которые ничего не имеют общего с успехом. Что такое успех? Какие цели у успешных компаний? Заработать много денег? Нет, у действительно успешных компаний цель сделать жизнь в мире лучше и удобнее (Хотя может это такой ПР шаг).
Как пример социальной ответственности мне кажется лучше всего подходят тюрьмы в Норвегии. Социальный институт призванный исправить неправильное поведение индивида. Не наказать человека, но перевоспитать. Не знаю насколько у них там все получается, но звучит правильно. Если человек заболел его нужно полечить, а не добить.
BugM
03.09.2023 08:18Я всегда думал что на работу устраивается профессионал, а не котенок. Речь допустим о типичном мидле.
Задачи те за которые ему деньги платят. Бизнес в курсе задач, считает их нужными и все такое. Задачи это не всегда интересное построение звездолета. А иногда и реализация очередной условной формы 32-бис. Это форма нужна бизнесу.
Обычные разговоры о том что надо работать лучше, как я писал чуть выше, допустим не помогли.
Успех бизнеса и рядовой работник уровня мидла это вещи из разных вселенных. Нет смысла и думать об этом. Ну если кому-то так легче работается, пускай. Практически это не имеет смысла.
khe404
03.09.2023 08:18+1Отчасти невозможно с Вами не согласиться. Однако, у каждой медальки есть две стороны.
О котенке я говорю не в профессиональном смысле, но в смысле ответственности руководителя за каждого подопечного, даже за суперпрофи. Если вы микроскопом забьете гвоздь то в профессиональном смысле точнейший инструмент испортится И его нужно будет заменить, но нужно будет заменить и следующий микроскоп и т.д. И такое поведение руководства встречается сплошь и рядом...
Если вдруг человек никогда не был профессионально годен, то почему он прошел испытательный срок? А если все было нормально, то что изменилось? Может быть тут проблема вовсе не в этом человеке?
Успех управления-- это выравнивание векторов усилий каждого сотрудника компании в одном направлении. Успех бизнеса это правильно поставленная задача призванная сделать жизнь лучше и успех управления.
Далеко не факт что задачи поставленные "Бизнесом" вообще кому-то нужны. Как показывает статистика прогорания стартапов, вообще не факт что нужны, а многие задачи спущенные вниз даже вредны. И очень может быть что правильный анализ этого вопроса позволил бы более эффективно выбирать направление деятельности а не гробить микроскопы и мучить котят.
Ну и увещевания человеку — работай лучше. Я пробовал так со своими детьми. Дети учитесь лучше! Не работает. Чтобы человек лучше работал нужны условия при которых этот человек будет работать лучше и для каждого такие условия свои. Но в основном нужно показать человеку что в вашем понимании хорошая работа.
BugM
03.09.2023 08:18Вы превращаете бизнес в какую-то богадельню. Руководитель отвечает за подчиненного только как руководитель. Ну там чтобы разработчики чайники не чинили и чтобы у них понятные профильные задачи были в достаточном количестве. Ну и защищает если кого из разработки хотят обидеть без повода или по незначительному поводу. На этом все. Дальше может стоит просто поработать? Вместо рассуждений о защите.
Есть исключение когда правда хочется помочь и это можно сделать. У человека что-то плохое иногда случается и ему нужно полгода не работать. Тут хороший руководитель придумает как это обеспечить. Выслушав человека и признав повод серьезным. И место подержать можно и вакансию можно не открывать. Зарплаты при этом конечно же не будет. Можно формально минималку оставить, чтобы вакансия не появилась.
Далеко не факт что задачи поставленные "Бизнесом" вообще кому-то нужны
Нужность задач определяется просто: Разработчику за реализацию этих задач бизнеса платят деньги. Он эти задачи реализует. Бизнес не лезет в технические решения, разработчик не лезет в бизнес решения. Вроде все правильно?
Если бизнес задачи оказались ненужными бизнесу за это отвечают другие люди. Не разработка. Если задачи были реализованы плохо, то за это отвечает разработка. Есть куча потенциальных проблем на стыке постановки-реализации, тут все вместе работают и все отвечают.
Чтобы человек лучше работал нужны условия при которых этот человек будет работать лучше и для каждого такие условия свои.
Зарплата на карточку приходит вовремя, ноут выдали хороший, монитор большой, стол и стул есть. И даже кофе с печеньками есть. Разве еще что-то надо?
Но в основном нужно показать человеку что в вашем понимании хорошая работа.
Есть тикет. В нем описана задача для разработчика. Результат выполнения или очевиден или будет дополнительно расписан и рассказан. Сроки иногда есть, иногда нет или почти нет. По разному бывает.
Хорошо - тикет сделан за разумное время, багов нет или почти нет, тесты есть и они адекватные, код прошел код ревью, тестирование довольно, девопсы довольны, клиент получил то что и ожидал. Вроде все очевидно?
anna_the_racoon
03.09.2023 08:18-1Очень добрая и светлая статья. На проектах порой очень не хватает такого Тима))
Ivan76
Очень добро написано, понравилось!