Комментарии 318
Новые сотрудники дешевле, чем старые. Стажёры на испытательном сроке вообще работают практически бесплатно. Джуниоров кормят обещаниями. В первые годы они плохо понимают суть аферы и не умеют отстаивать свои права. Так что в идеале можно просто увольнять стажёров после испытательного срока и нанимать новых, что полностью совпадает с дегуманизирующими принципами тейлоризма (о нём см. ниже).
От джунов и стажеров обычно толку довольно мало, им обычно нужна нянька, которая за ними присматривает и следит что-бы дети ничего не сломали и не убились сами. Такая схема работает разве что для какого-то совсем уж говнокодинга, где на качество кода всем плевать в принципе - разработка какого-либо дерьма, типа игр-однодневок, бесконечно копирующих успешные прототипы с целью показать пользователю десяток рекламок и быть удаленными с телефона навсегда.
+++ В боле-менее серьезный проектах срок вкатывания сотрудника - от 3х месяцев, на сложных - может и полгода пройти, когда от сотрудника будет толк (и если он за это время ничего не поломает)
В более менее серьезных проектах срок вхождения сотрудника меньше недели.
В более менее серьезных проектах есть система автоматизации тестирования в которой всегда надо что-то доработать и это безопасно доверить новичку.
В более менее серьезных проектах всегда есть документация ознакомившись с которой новичок может сразу править не сложные дефекты, а компания не бояться что он что-то сломает так как автоматизация из пункта выше.
В более менее серьезных проектах есть качественный бэклог где отдельно помечены задачи для новичков, которые с одной стороны быстро повысят осведомленность в проекте, а с другой не критичны с точки зрения скорости исполнения. И новичок ничего не сломает потому что пункт 1.
И существует такой проект только в мире волшебных единорогов, которые пьют исключительно утреннюю росу и срут радугой.
Может быть где-то и есть. Я таких не видел. Потому что это очччень дорого - у вас должен быть костяк архитекторов-проектировщиков-сеньор-(и частично)мидл разработчиков, которые
1) собственно и декомпозируют проект до тех кусков, которые можно отдать новичкам (а это обычно сложнее чем "сделать всё самому")
2) сами не увольняются, иначе на их место "новенькие" будут вкатываться еще дольше
Ну или этот тот самый конвейер
типа игр-однодневок, бесконечно копирующих успешные прототипы с целью показать пользователю десяток рекламо
Может быть где-то и есть. Я таких не видел. Потому что это очччень дорого - у вас должен быть костяк архитекторов-проектировщиков-сеньор-(и частично)мидл разработчиков, которые
Это не дороже, а может даже дешевле, чем ляпать что-то не думая на перед, без нормальной многоуровневой системы с тестами и продуманной архитектуры. Минимум регрессий, минимальное время вхождения в проект, расширяемость, масштабируемость. В в среднесрочной и долгосрочной перспективе просто огромная экономия денег.
собственно и декомпозируют проект до тех кусков, которые можно отдать новичкам
Это не так, если есть поставленный процесс. Если проект декомпозируется до задач каждая из которых не более 3-5 дней, а в идеале менее, все идет очень легко.
Ну или этот тот самый конвейер
Это беспилотные автомобили.
Минимум регрессий, минимальное время вхождения в проект, расширяемость, масштабируемость.
И отсутствие каких либо специфических внутренних вещей. Ну да, великолепно работает если надо crud'ы клепать.
В в среднесрочной и долгосрочной перспективе просто огромная экономия денег.
Проблема только в том, что большинство проектов не рождаются в условиях, в которых есть возможность думать о среднесрочной или долгосрочной перспективе. Проект рождается, чтобы срубить бабла здесь и сейчас.
Иногда что-то выстреливает так сильно, что остаётся с нами надолго, после чего начинает обрастать мясом, в виде архитектуры, тестовой инфраструктуры и документации. Но, к сожалению, тут уже начинают на пятки наступать конкуренты, которые тупо копируют вашу идею. В итоге приходится балансировать между хаосом и порядком первые несколько лет.
И вот уже потом, если ваше решение выжило, вот только тогда обычно разработка замедляется и есть возможность начать приводить дело в порядок. Проблема тут в том, что массово народ начинают нанимать где-то после фазы "выстрелило".
Знаете, раздражает "срубить бабла здесь и сейчас". Ну правда раздражает. Вот как вы себе это представляете? Давайте представим себе ситуацию. У вас делают процессоры в Тайване. Нужно оборудование (всякое разное). Ищут тех кто может сделать. Появляется когорта тех, кто понимает что преобразование фурье - это просто поворот в функциональном пространстве от одной системы отсчета в систему отсчета где система координат это комплексные экспоненты. И вот они думают что все это лучше сделать на каком нибудь Visual Basic или MS Excel. И получается продукт который стоит сотни миллионов долларов и его покупают ведущие производители и т.п. Это называется "бабла срубить"? Ясно что потом выясняется что надо было делать все иначе , хотя бы чтобы памяти элементарно хватало на боксе да и ваще чтоб все было красиво. Но это же все - потом, потом. А сейчас надо делать микросхемы. Короче мысль которую я пытаюсь донести - все, что есть это то как оно должно быть. Но нельзя относиться к тем, кто "забронзовел" как к тем кто был предками в знаменитом фильме "Легенда о Нарайяме"
Это называется "бабла срубить"?
Ну, а разве нет? Делали в спешке, делали как умели, чтобы сделать "здесь и сейчас", ибо бабло пропадает, некогда думать над тем, как сделать нормально.
Это обычное дело, да я никого и не осуждаю. Компании живут чтобы зарабатывать денег. Мне это может нравиться, может не нравиться, но это объективная реальность, т.е. считай норма.
Компании живут в этой реальности и срубить бабла нормальное желание. Просто это оставляет отпечаток на том, как проекты существуют и почему мир розовых пони, где новичка можно за месяц погрузить в проект - это если и существующий сценарий, то очень редкий
Помнится, Брукс в качестве большого проекта рассматривал OS/360 с трудоёмкостью создания в миллион, что ли, человеко-месяцев (там только перерасход сотрудников составил 1000 дополнительно привлечённых человек). Успехов вам декомпозировать 20 миллионов человеко-дней на задачи по 3-5 дней.
Брукс подбирал и подтасовывал примеры под свои выводы.
Хотя он сам же и описал очень просто способ реализации "серебряной пули", но так как это шло в разрез с его первоначальными предположениями и основной идеей книги, то об этом говорят вскользь или вообще не вспоминают в контексте "мифического человекомесяца".
Хотя он сам же и описал очень просто способ реализации "серебряной пули"
Какой же? или я забыл, или не понял.
Использование библиотек со свободными лицензиями.
В его время этого действительно не было, но сейчас переиспользовать Free Software может каждый. Это и есть та серебряная пуля, которая значительно (более чем на порядок) сокращает трудозатраты при создании любого программного решения.
Не каждый может использовать и не в любом проекте, а всего лишь в типичном случае.
Если сократить трудозатраты на порядок (что вполне возможно, причём не только за счёт опенсорса), ничего принципиально в выводах Брукса не поменяется.
Брукс вообще работал в IBM, и у них была очень значительная собственная инструментальная оснастка, для их целей не сильно уступающая всему сообществу free software, а в некоторых моментах и превосходящая.
Если вы решаете типовые задачи, то всё с опенсоурсом хорошо. А Брукс руководил большими заказными проектами, куда на наши деньги портировать библиотеку с гитхаба и то будет не так просто (подогнать под железо и системный софт, документировать, сертифицировать по классу безопасности и т.д., а потом всё это ещё держать в синхронности с основной веткой).
Есть сейчас проекты по миллиону человеко-месяцев? Есть. Собственно, в этом и вывод.
ничего принципиально в выводах Брукса не поменяется
Как раз меняется принципиально.
Он писал про ситуацию, которая была на тот момент (разработка силами одной команды всего стека ПО). В настоящее время все изменилось принципиально, и разработать ПО феноменальной сложности можно чуть ли не в одиночку за счет переиспользования готовых программных модулей.
Как раз про это Брукс и писал (что можно сократить трудоемкость разработки за счет готовых библиотек). Вот он только сделал не верное предложение, что никто бесплатно не будет разработывать программные модули бесплатно. Но время показало что это не так.
Просто изменилась метрика сложности. Некоторые сложные задачи того времени стали простыми для настоящего дня. Но это не значит, что задачу феноменальной сложности можно решить в одиночку. Это значит, что подходы к решению некоторых задач упростились, но возникли новые сложные задачи.
Условно говоря, если для 1970 года АБС в машине – это было круто, то сейчас уже целый автопилот надо запрограммировать для достижения такого же уровня продвинутости на общем фоне. Что ни фига не легко.
А, например, моделирование ядерного взрыва ни тогда не имело общедоступных библиотек, ни сейчас не имеет. Так как секретность и всё такое.
Брукс писал об управлении людьми, а люди не изменились.
Не спорю, что люди остались такими же, и в том случае, если сейчас нанять коллектив для разработки большого приложения, то мы получим ровно такие же проблемы, о которых писал Брукс.
Я говорю совершенно про другой момент, что сейчас не нужно писать с нуля (как во времена Бруска), операционную систему и библиотеку для тензорных вычислений, что бы уже на их основе запрограммировать целый автопилот, а достаточно взять уже готовые модули и сосредоточится только на реализации нужного приложения.
Как бы АБС -- это тоже такой автопилот, только узкоспециализированный: нажимая педаль тормоза водитель ставит этому автопилоту задачу замедлить или остановить машину, а он делает это наиболее эффективным и безопасным способом из имеющихся. Разница с современными автопилотами, если смотреть с точки зрения пользователя, только в масштабах: теперь перед ним ставится вся задача по доставки кожаного мешка из пункта А в пункт Б, а не только по правильному и безопасному торможению.
Вот он только сделал не верное предложение, что никто бесплатно не будет разработывать программные модули бесплатно. Но время показало что это не так.
Брукс писал про свою работу над OS/360 в первой половине 60х (релиз в 1966). Возможно, такого рода заявление было политически неверно.
Про снижение стоимости стоимости разработки за счет использования модулей кажется он писал значительно позже во втором издании книги или в отдельном эссе.
Открытое ПО тогда было обычным делом. Столлмен ведь не сам его придумал, а лишь хотел возродить традиции.
Но OS/360 писалась с нуля и никаких готовых наработок не было, и пользоваться Бруксу было нечем.
А для OS/360 IBM, кстати, потом поддерживала форумы для свободного обмена программами, в числе которых были даже компиляторы и прочие сложное вещи.
Смысл в том, что для реализации такого проекта должна быть выстроена система типа домино. Заходит новая доминошка, и далее всё валится по предсказуемой траектории. Это мечта любого оперативного руководителя. Однако содержание такой системы требует содержания и тех доминошек, которые не нужны здесь и сейчас, но ресурсы на них уходят. И вот СОБСТВЕННИКИ довольно быстро начинают задавать вопрос, а на фиг они нужны СЕЙЧАС , если выгоды пока не видно?
Для вас порог вхождения — это когда новичок начнёт выполнять рафинированные задачи с пометкой "для новичков". Для меня — это когда новичок сможет браться за любую задачу. Собственно, для этого его и наняли.
В более менее серьезных проектах есть система автоматизации тестирования в которой всегда надо что-то доработать и это безопасно доверить новичку.
В которой если что-то сломать, то это замедлит или даже парализует работу всего отдела. А код для автоматизации тестирования, в отличие от кода продукта, никто не удосужился покрыть тестами.
В более менее серьезных проектах всегда есть документация ознакомившись с которой новичок может сразу править не сложные дефекты, а компания не бояться что он что-то сломает так как автоматизация из пункта выше.
Документация в виде сотни в разной степени устаревших документов, разбросанных по разным порталам. А тесты покрывают далеко не 100% кода. Ну и это C++, тут есть UB, которые тестами в принципе не покрываются в общем случае.
В более менее серьезных проектах есть качественный бэклог где отдельно помечены задачи для новичков, которые с одной стороны быстро повысят осведомленность в проекте, а с другой не критичны с точки зрения скорости исполнения. И новичок ничего не сломает потому что пункт 1.
Да, но этих задач не много, и в процессе их решения человек только очень поверхностно ознакомится с общей структурой кода парочки репозиториев (из нескольких десятков, поддерживаемых командой).
P.S. А вы как будто рассказываете о проекте, в котором ещё нет серьёзного легаси, но уже есть большие бюджеты и приоритеты на долгосрочное планирование. Какой-то исчезающе редкий и не показательный сценарий ИМХО.
Ну и это C++, тут есть UB, которые тестами в принципе не покрываются в общем случае.
Дык статические анализаторы кода давно придуманы. Они потенциальное UB подсвечивают ещё до компиляции.
Именно что потенциальное, у них у всех есть огромное количество ложноположительных и ложноотрицательных срабатываний. И честно, вообще не видел статических анализаторов, учитывающих взаимодействие кода в разных TU.
Вот сочетанием статического и динамического анализа можно большинство UB отлавливать (но всё ещё не все).
Впрочем, суть моего комментария была вообще не в этом, про UB это так, небольшое примечание.
В более менее серьезных проектах срок вхождения сотрудника меньше недели.
)))))) Идите к нам в devops, вот вы удивитесь, насколько сложными бывает инфраструктура и вот это вот все. Полгода в лучшем случае, при условии что у тебя есть хорошая база и опыт работы с данным стеком
Полгода в лучшем случае, при условии что у тебя есть хорошая база и опыт работы с данным стеком
Не соглашусь с вами. Конечно проект может быть сложный, но если есть "хорошая база и опыт работы с данным стеком", то имхо ваша оценка сильно завышена. Пара месяцев от силы.
Да но это на базовом уровне. Обычно где то полгода. Чтобы начать реально в проекте шарить. А не тупить по неделе над задачей, которую можно за полдня закрыть.
Полностью поддерживаю, у нас это в среднем 9! месяцев, при том что есть и автоматизация и документация и автотесты.
Оно понятно, всегда и везде есть масса низкоприоритетных задач, которые никто не хочет делать, но на одних таких задачах проект не сделаешь, кто-то должен решать серьезные задачи. И на серьезных проектах, новичок, даже с хорошим уровнем, серьезные задачи начинает решать хорошо если через полгода. С описанной в статье текучкой не всякий столько продержится.
Документация есть обычно, это да.. только толку от нее так-же обычно никакого, она устарела и сильно не бьется с реальностью, иногда от нее больше вреда чем пользы.
Это какой-то идеализированный случай. Очень часто какие-то "задачи для новичков" после более глубокого в них погружения, оказываются каким-то хтоническим пиз..ом, который не всякий шарящий в проекте синьор сможет решить, а тесты ловят далеко не все косяки, поэтому за новичком в любом случае лучше пристально присматривать по началу что-бы он не сломал что-либо важное.
Ну то есть есть пул задач специально для новичков. Это на самом деле классно. Но то, что новичок сможет взяться за эти задачи из специального пула за неделю, не значит, что он полноценно вкатился. Вкатится он тогда, когда сможет взять любую задачу своего уровня вне этого пула.
Про документацию было особенно смешно, в свете преклонения перед эджайлом. Бэклог - это всего лишь удобная хрень, спрятавшись за которую можно не нести ответственность - главно е чтобы словеячки были позаковыристее и понепоятнее. Например все быстро забыли, что backlog - "просёр" по сути. Это задолженность, которая просрочена. Но значение этого слова было забыто и теперь оно означает.... собсвенно ничего оно не означает. "Мы записали в бэклог" - занавес. Всё это дерьмо никогда не приживется в России - жаль только что для того, чтобы это понять - опять понадобится много лет и куча сломанных жизней серьезных специалистов, которые могли вывести страну на совершенно другой уровень!
Судя по тому, как преподносят этот самый agile потенциальные наниматели, формально не отменяет, а по факту не оставляет на него времени. Как, кстати, и на автотесты. Мне с автотестами доводилось работать только на двух местах работы, во всех остальных случаях мне говорили: "Да, конечно делай, если это не увеличит время выполнения задачи." Ну или за свой счёт. И зачем оно мне тогда? Пусть лучше потом такой работодатель оплачивает исправление ошибок, если ему так больше нравится.
А в чём принципиальная разница с тем же водопадом в этом контексте? Ну то есть в водопаде всегда говорят что можно неограниченное количество времени тратить на документацию и тесты? :)
Я ничего не писал про бесконечное количество времени, я писал про то, что работодатели и заказчики не хотят оплачивать время, которое тратится на тесты. Ну и на документацию тоже. Хотя последние несколько лет я работаю почти исключительно над парсерами торговых площадок и там тесты как-то не очень получается применять. Ну или можно считать, что сама площадка является таким тестом.
я писал про то, что работодатели и заказчики не хотят оплачивать время, которое тратится на тесты. Ну и на документацию тоже.
А в водопаде они всегда хотят это время оплачивать?
Впервые вижу название такой компании и тем более в ней не работал, поэтому ничего про то, что там оплачивают, а что нет, сказать не могу. Я уж больше 10 лет работаю на фрилансе с несколькими заходами в офис и за всё это время никто не жаждал оплачивать тестирование или даже нанимать тестеров.
"Водопад" или "каскадная модель" это модель разработки которая грубо говоря является противоположностью agile.
Водопад — это не название компании, а методология разработки.
В любом случае, проблема решается искусственным завышением сроков. Говорим заказчику, что программировать тут месяц, а по факту 2 недели программирование + 2 недели тесты.
Впервые такое вижу. Видимо, к тому моменту, когда начали распространяться все эти модные названия, я уже ушёл и корпоративной разработки.
Вполне возможно. Но тогда он никак не назывался. А потом маркетологи начали придумывать красивые названия для завлечения менеджеров. По так получается из моих наблюдений.
Ну и да, на написание тестов и документации время выделяли. В отличии от всего, что мне попадалось под разными названиями позднее.
Самый популярный подход — это пиши код, б
Кажется, пришли те самые работодатели и заказчики, которые не хотят оплачивать тесты, и сильно обиделись.
"Да, конечно делай, если это не увеличит время выполнения задачи."… И зачем оно мне тогда?
Видимо вы еще руку не набили на написание тестов. Я вот даже не знаю как код начать писать если нет теста. Я не говорю, что TDD это маст хэв, по мне это просто механический навык, как печать вслепую, как шорткаты.
Не исключено. Но если никто из работодателей и заказчиков не хочет оплачивать работу по написанию тестов, то делать её бесплатно как-то не очень тянет. В моей практике был только один случай, когда тесты писались, писались подробно, на каждую функцию. И это был единственный случай, когда эта работа оплачивалась, причём, не втихую, когда она неявно включается в работу по задаче, а вполне официально. Это уже естественный отбор: если хвост виду не требуется или даже явно мешает, он просто "отваливается". Так и здесь. В большинстве случаев мой код работает без ошибок, потому мне и тесты не нужны, тем более, что проекты в последние коды достаточно маленькие. Но это уже специфика работы.
Хотел бы, чтобы можно было тесты использовать, но либо нет потребности из-за малых размеров проектов, либо заказчик не готов оплачивать дополнительную работу. А каждому что-то доказывать... Был опыт убеждения начальства и даже положительный, но при моём психотипе это всегда тяжёлая работа.
Вы говорите о том, что написание тестов — это дополнинельная работа, которая требует инвестиций. Я тоже так раньше думал, но теперь считаю, что тесты уменьшают время разработки, да еще и повышают качество продукта.
И я с вами абсолютно согласен, что это ответственность работодателя инвестировать в культуру тестирования. И это не время на написание тестов, а обучение, встраивание в процесс доставки, в оценку качества продукта, анализ и т.д.
Объяснить и внедрить это, действительно требует коллосальных усилий, особенно если работодатель не понимает или не видит смысла.
Для маленьких проектов посмотрите в сторону Outside In тестов. Т.е. пишите только очень высокоуревнивые тесты, они быстро пишутся и покрывают очень большую площать кода.
Последние лет 5 я пишу только такие тесты и мне кажется, что их достаточно. Вот пример тестов которые пишу:
def when_user_created_welcome_message_sent(client):
client.post("/users", { "name": "Vadim", "age": 18 })
user = User.objects.get({name: "Vadim"})
assert Email.objects.filter({type: "welcome", user_id: user.id}).exists()Суть Outside In тестов, то вы ничего не мокаете и просто дергаете API и потом проверяете то, что должно произойти, т.е поведение системы.
Получается, что тут не важно как все реализовано, какие методы вызывались. Просто проверяете: если я отправил вот такой JSON на такой URL, то мне пришел ответ 200 и данные которые я ожидаю.
Собственно, такие тесты я и делал. Только вот уже лет 5 я занимаюсь почти исключительно парсерами, а там нет API, да и парсер тестируется об сайт, для которого написан. А если речь о сайте, то надо сделать инфраструктуру и так далее. Вот как у меня есть куча заготовок для парсеров, так и здесь должны быть заготовки. Но чтобы они появились, работодатели и заказчики должны быть готовы платить за такую работу. Сейчас мне тестирование не актуально, но если я вылезаю за пределы уютного болотца парсинга, оказывается, что никто платить не хочет, а просто так тренироваться мне тоже не очень интересно, поскольку навык в обозримом будущем негде будет применить. Но если доберусь до тех своих проектов, на которые никак не могу найти время и силы, попробую воспользоваться Вашим советом, тем более, что там как раз должен быть API, поскольку часть действий будет выполняться автономным оборудованием.
Еще как... Основной принцип - главное доработка и ее внедрение. Док "можно потом". В России "можно потом" превращается либо в "необязательно" либо в формальность, по кот потом концов не сыщешь (легче по-новой все сделать - точн быстрее будет).
И второй момент тупое разбитие нормальной работы на кучу мелкой и глупой - прямой путь в кривую работу. Вспоминаем анегдот про выкапывающего ямки и следом за ним закапывающего. Просто сажающий деревья заболел. Вот типичный agile!
Если компания не нанимает постоянно новичков, то там "отдельно помеченных задач" нет, а их надо будет кому-то позаводить и отметить к найму новичка. А уж где настолько полная документация, что по ней реально можно вкатится за неделю - я вообще не представляю. Зато не раз видел ситуацию "о, ты новенький, давай нас расспрашивай и всё это записывай, так у нас наконец-то и появится документация".
Зато не раз видел ситуацию "о, ты новенький, давай нас расспрашивай и всё это записывай, так у нас наконец-то и появится документация".
Как это ни странно, это оптимальный подход.
Опытный сотрудник легко напишет документацию для других опытных, но не для новичка.
Как это ни странно, это оптимальный подход.
Не совсем так. Оптимальный (для качества документации) - это "вот тут у нас документация есть, работай по ней, а как станет непонятно или расходится с реальностью - проси нас править до тех пор, пока не станет понятно".
Потому что если писать будет новичок - то в его тексте может запросто не быть чего-то, про важно, нужно редко и только опытные про эту 'небольшую деталь' помнят.
Это все верно только, если компания производит процесс, а не продукт.
Кажется что количество минусов связано с тем, что такой подход
сильно похож на рекурсию.
Т.е..
1) Чтобы сделать в более менее серьёзном проекте архитектуру такого вида, который позволит что-то доработать новичку требует весьма опытного и сильно умного архитектора, который этот функционал заложит, зная что он необходим в том числе для избавления от одного опытного и умного сотрудника
2) Найти достаточно серьёзный проект, по которому можно прочитать Всю документацию за две недели, да ещё и Понять её - задачка с двумя звёздочками и явно не для джуниоров
3) Для ведения настолько качественного бэклога, который позволит разделить задачи любого джуниора на влияющие на работу и не влияющие, да ещё и отсечёт амбициозных джуниоров, не имеющих нужных компетенций- его (бэклога) ведение стоит отвлекать отдельно достаточно квалифицированных сотрудников - с большим опытом и недюжим умом, см. п.1
Всё это не нужно, если клепается очередная "система платежей/бронирования" по лучшим принципам шаманизма.
Организация людей в таких проектах построена на беспорядочной "борьбе всех против всех": т.е. у кодеров соревнование, кто больше строчек закодит, у тестописателей — кто больше кода покроет, у тестировщиков — кто больше багов и "багов" зарепортит, у кодеревьюршиков — кто больше кода "завернёт", у менеджемнта — "поток тикетов/тасков".
Такая система вообще не требует проектирования как такового: это почти как обучающаяся нейросеть. От высшего менеджмента требуется только подручивать "макропараметры" — обычно через кадровые решения.
В более менее серьезных проектах срок вхождения сотрудника меньше недели.
Вот ведь, а у нас полгода считается минимальным сроком. Менеджмент, наверное, глупый.
Документация ... удачи в чтении :)
Особенно в живом проекте. Ну факты типа спецификации входящего сообщения - можно, но и в коде можно посмотреть. Описание логики работы метода - сомнительно. Описание почему сделали так - вообще никогда. А это самое важное, так как все "грабли" тут
В более менее серьезных проектах срок вхождения сотрудника меньше недели.
Вы оцениваете «срок вхождения» как срок, после которого человек начнет делать что-то полезное. У меня в команде это вообще пару дней, как раз на «новичковых» задачах, но это бессмысленный показатель.
Куда важнее когда сможет полноценно решать любые задачи проекта. В контексте статьи, если уволить старого и заменить новым, то задачи старого новый через неделю решать не сможет. В серьезных проектах это как раз 3-6 месяцев до того чтобы «в принципе мог», и иногда годы чтобы «мог так же быстро».
Программирование - это мир в котором что-то однажды сделанное можно бесконечно переиспользовать. Мир, в котором (в идеале) программист каждый раз пишет что-то совершенно новое, чего ни он ни кто-либо другой в мире никогда не делал (а иначе надо просто взять уже готовое решение).
И вот, допустим, есть компания, которая творит что-то совершенно новое и невиданное. И там у нее куча задачек для новичков с подробной инструкцией как их делать? И эти задачи еще не автоматизировали?
Или вы про другие кампании, которые делают бесполезную однотипную работу, не умеют ее автоматизировать и потому нанимают джунов работать по инструкции?
Мне кажется, вы путаете понятия "время вхождения" и "время через которое сотруднику можно поручить первую задачу".
Первую несложную задачу, действительно можно дать уже через неделю, а то и раньше. Но нас же в контексте оценки выгодности текучки интересуют совсем не это, а то, через какое время новый сотрудник сможет стать полноценной заменой выбывшего. И по моему опыту работы в проектах с хорошей документацией с автотестами и тд, этот срок от трёх месяцев до полугода: просто из-за того, что нужно освоить большой объем информации и научиться ориентироваться во всей кодовой базе проекта. Без этого, увы, говорить о полноценной замене невозможно.
Учитывая то, что тут говорят про опытных специалистов, у джунов-новичков вообще год может "вливание" в работу длиться.
Сколько тут понаписали... Однако, есть полно компаний, в которых джунов используют именно так. И это не только GC в геймдеве, круд, формошлёпство. Операционку так не сделать, но более 90% бизнеса и не нуждается в хорошем подходе. А так-то и отдельные сервисы так пилить можно, типа яндекс-такси, когда карты делает отдельная команда.
Сообразительного мидла ставим менторить, говорим "ну поздравляю! Ты дорос до тимлида! Учись управлять!". Ну и выписываем увеличение ЗП аж на 15%
И вот он чувствует себя важным, подсказывает стажерам, помогает влиться. Но обходится дешевле. А через годик-другой можно его выпнуть и повторить действия с одним из нынешних стажёров.
Объясните зачем менторы программистам? Я упорно не понимаю эту деятельность.
За джунами и стажёрами кто-то должен как минимум следить. В идеале ещё и немного обучать.
Понятно что совсем за ручку водить не требуется обычно.
Ну вот пришёл к вам стажёр в компанию, после универа. Зелёный, без опыта командной работы и реальных проектов.
И вас просят ввести его в курс дела, подсказать по необходимости по продукту, архитектуре, решениям.
Вот вы и ментор программиста. Ачивка получена.
по моему как раз наоборот. и сам сталкивался и друзья многие подтверждают. Условно я пришел в компанию год назад на 100к. за год мне дали индексацию на 10% итого 110. а тип с улицы, пришедший на соседнее место просит сразу 130-150. Итого компании выгоднее сохранять старичков, т.к. они опытнее и закрывают задачи быстрее и лучше за каждый вложенный рублик.
Условно выгодно, пока старичок сам не пойдёт собеситься и не вернётся с оффером 2х и просьбой поднять на столько же
по больному бьете. Я недавно увольнялся
HR провели аж 3 раунда выходного интервью.
Обещали мне запись в трудовую, добавить подчиненных, дать еще больше работы (я итак за 2,5 должности там справлялся).
А вот денег не пообещали ни рубля.
Я и понимал конечно, что тягаться с моим оффером им не выгорит, даже если сильно захотят. И соглашаться на контр скорее всего не собирался, ибо "уходя уходи".
Но осадочек остался.
Чего-то не понял: они не хотели отпускать, но з/п поднимать не предложили? А наоборот еще больше работы, ответственности, ты только останься - и так 3 раза? Это же бессмыслица какая-то...
да именно так. компания провела индексацию буквально за пару дней до моего оффера, и прибавила аж 17%, что порадовало. но оффер был еще жирнее. Винить их особо не в чем, может и могли в обход процедур докинуть, но не стали ничего менять.
да я и сам им сказал, что на мою сумму можно нанять тех же 2,5 землекопов, и они вывезут работу (тем более у меня за 100% выполнено, + подробные инструкции есть + мое большое уважение тимлиду и моя доступность по телефону)
Это, кстати, довольно частый косяк нанимающих менеджеров и эйчаров, нанимать на среднюю до-тимлидскую позицию чувака с 10 годами опыта (и с соответствующей красивой зарплатой), там, где хватило бы 2-3 лет, а потом видя что типу скучно - предлагать ему вообще непрофильные проекты, горизонтальное расширение вширь и прочие не-денежные бонусы.
Это, кстати, довольно частый косяк нанимающих менеджеров и эйчаров, нанимать на среднюю до-тимлидскую позицию чувака с 10 годами опыта (и с соответствующей красивой зарплатой), там, где хватило бы 2-3 лет, а потом видя что типу скучно - предлагать ему вообще непрофильные проекты, горизонтальное расширение вширь и прочие не-денежные бонусы.
Чувствую себя этим чуваком. Опыта не 10 лет, а всего 7, но блин. Нанимался на работу, где всё выглядело в целом интересным. Оно таковым и было, но потом я въехал в фишку и понимаю, что с моей работой может справиться любой миддл, под минимальным присмотром.
В итоге бОльшую часть работу я скинул на своего миддла и джуна в подчинении, а сам занимаюсь... ну чем-то непрофильным. Де факто я уже больше DevOps и немножко системный Аналитик, чем разработчик. В принципе, я и не так уж чтобы против.
https://www.youtube.com/watch?v=0h2_QZ3bMEk
https://www.youtube.com/watch?v=ePFJFistdl0
"Добрым словом и пистолетом вы можете добиться гораздо большего, чем одним только добрым словом.“ (c)Аль Капоне
"Think different" (c)Apple
"Иногда возникает необходимость расставлять точки на их места." (c)
"Всему свое время, и время всякой вещи под небом
Время рождаться, и время умирать
Время насаждать, и время вырывать посаженное
Время убивать, и время врачевать
Время разрушать, и время строить
Время плакать, и время смеяться
Время сетовать, и время плясать
Время разбрасывать камни, и время собирать камни
Время обнимать, и время уклоняться от объятий
Время искать, и время терять
Время сберегать, и время бросать
Время раздирать, и время сшивать
Время молчать, и время говорить
Время любить, и время ненавидеть
Время войне, и время миру" (c)Ветхий завет
3 раунда выходного интервью
О, я знаю! Там были задачки с литкода. А потом такие: "Мы вам перезвоним....". А потом: "Вы не можете быть уволены. Ваш скилл недостаточен для этого. Вы можете попробовать ещё раз через год. Работать с нами - честь. Благодарим за сотрудничество!".
Так, да? :)
А по-моему большинство действительно больших бинзнесов (например, банк) представляют себе тихое болото
Это давно уже не так (по крайней мере в России). Банки сильно конкурируют между собой не только процентными ставками (иначе у Сбера давно не осталось бы ни одного клиента хаха), но и time to market.
Болота все ещё встречаются, но эти болота всеми силами в госбанках пытаются расшевелить, а в коммерческих так вообще никто не останавливается.
Тут зависит от фазы развития бизнеса. Верные надобны, когда бизнес стабилен. А вот когда наступает время перемен, расширение на новые рынки, или изменение внешних обстоятельств, вот тогда и возникает проблема - набрали верных, а требуют как с умных.
действительно, такое отношение формируется у неопытных управленцев, которые вследствие этого либо банкротятся, либо умнеют и понимают, что "старый конь борозды не испортит" и вообще, если команда сложилась, то она работает хорошо, а новому человеку нужно и вписаться и обучиться
как правило, в этом и причина низкого качества кода - сначала бизнес торопится зарабатывать на демо-версии своего стартапа, погоняя кнутами "некогда думать, работать надо!", а потом это дерьмо мамонта становится таким легаси, который и не отрефакторить - легче переписать.
впрочем, подход "сделаем всё как можно круче" тоже, бывает, проваливается, потому что приходит момент, когда "круто" - это ещё и медленно и вообще в данном случае было неверным выбором, а дальше, см.выше, оно уже легаси...
да и легаси переписать тоже та ещё задачка, особенно если нет/мало людей, кто это всё писал, и понимает, что этот вот костыль - очень нужный костыль, и почему он работает
Обычно и легаси не беда, когда архитектура хорошо продуманна и все сделано из сравнительно небольших модулей, обложенных тестами, которые впоследствии рефачить легко, и благодаря тестам не страшно. А вот самая жесть начинается когда архитектуру разрабатывали по принципу -- "херак, херак, и в продакшен", либо, что еще хуже, когда ее разрабатывал любитель сделать из простого что-то суперсложное. Не так давно работал на таком проекте - куча велосипедов, даже ORM свое, что-бы простую DTO намутить надо десяток xml написать с неочевидной структурой, после чего запустить сборку проекта, которая более получаса делается, не на самой дохлой машине, и молиться что-бы ничего в процессе не сбойнуло..
В реальности еще и новые сотрудники дороже, чем старые. Есть исследование, что на одной и той же позиции, свеженанятый человек получает больше, чем тот, кто уже давно работает
Всё именно так как вы повествуете. Даже для грамотных и опытных спецов погружение в проект занимает длительное время. Но при всём при этом:
Такая схема работает разве что для какого-то совсем уж говнокодинга, где на качество кода всем плевать в принципе - разработка какого-либо дерьма
обратили внимание, что многие некогда легковесные, быстрые проекты превратились в неповоротливых монстров иногда с кучей багов, которые мало кто чухается фиксить? Временами здесь же проскакивают статьи, как проект отдали на разработку Индию или ЮВА, а потом диву давались.
Я работал на проекте, который изначально делали в Германии.. Уж не знаю что больше повлияло, национальные особенности или просто так звезды сложились, но в моем личном рейтинге - это был самый адовый ужас, который я видел когда-либо в проектах.
Очень замудренная архитектура с массой велосипедов на квадратных колесах, одни только DTO, генерируемые из xml со своим синтаксисом, чего только стоят. Что-бы просто написать какой-либо рестконтроллер надо было сначала накидать дто для самопального ORM, в xml, потом запустить сборку, которая на вполне мощном ноутбуке работала больше получаса, потом найти эти созданные dto где-то в недрах проекта, написать еще пяток разных сервисных классов, еще там что-то собрать пару раз.. в общем вся эта бодяга растягивалась на целый день.. И за годы доработок все это разрослось в такой кусок чудовищно воняющего кода..
это был самый адовый ужас, который я видел когда-либо в проектах.
Кто хоть раз в жизни смотрел на SAP и его потроха, тот такому не удивляется. Танк Maus и пушка Dora - это все из одной оперы.
Извините, очень захотелось задать вопрос :) А вот этот продукт который изначально немецкий - я рискну предположить что он в какой то момент был исключительно успешен на рынке. Это так?
Смотря что подразумевать под успешностью - этот продукт работает в инфраструктуре одного крупного российского ритейла, как я понимаю (всех подробностей не знаю) изначально он разрабатывался под заказ в Германии, потом заказчик видимо решил что разработка там обходится как-то дороговато, и дальше его дорабатывали уже в России силами своего IT подразделения. Но основная жесть пошла оттуда, из гнезда тевтонского IT, тут уже бедолаги программеры юзали то что было заложено там.
К сожалению код не могу показать, по понятным причинам, он не опенсорс, придется поверить мне на слово - я мало где видел такую жесть с такими неудобными велосипедами. Даже древние версии хибера, на xml (а там велики были в духе того гибернейта) и то как-то казались поудобнее. Идея, видимо, была в том, что разраб пишет в декларативном стиле что ему нужно, после чего сборка создает скелет модуля, который надо заполнить кодом. В реальности же, сборка всего этого добра оказывается очень хрупкой, с массой магии и жизнь разрабам только усложняет, потому что вместо простого написания дто с расстановкой аннотаций тебе приходится довольно долго сочинять xml-ки с мудреной структурой, после чего долго ждать сборки, которая часто не отрабатывает как надо, после чего бороться с глюками и проблемами велосипедов, причем каждое исправление требует опять-же длительной пересборки.
В общем я видел много кривых проектов, но тот в моем личном рейтинге говнопроектов стоит на первом месте, с таким облегчением я еще ни откуда не уходил как с того проекта.
Вот как раз насмотрелся на это самое ресурсное отношение, люди прямо на глазах менялись и превращались в комки нервов. Ресурсное отношение к людям умственного труда это ещё куда более жестокая вещь, чем физически стоять у станка в три смены. Психика буквально за месяцы улетает. И плевать эти менеджеры хотели на то, что люди просто сгорят и дальше вообще не смогут работать, причём некоторые потом совсем уйдут из айти.
И кстати, эти самые рокстары обычно те самые люди, которые пытаются противостоять такому отношению, они не терпят его к себе, показывают пример для других коллег.
И все нормальное отношение к специалистам держится как мне кажется, на конкуренции, потому что некоторые более мудрые менеджеры как раз используют это как преимущество. Но зачастую потом все равно они уходят и в компании настает вот такой звериный оскал.
Не знаю, но мне кажется, что если в обществе появится наконец безусловный базовый доход, то вся эта грызня сильно уменьшится и общая эффективность труда только вырастет, потому что люди сильно меньше будут бояться голосовать ногами.
Американского не знаю. В регионах РФ хватит и тысяч 25 рублей. В столицах, наверное тысяч 40. Эта сумма гарантирует, что ты сможешь снять себе хоть какое-то жильё и что-то пожрать на протяжении месяца.
безусловный базовый доход Распространяется на всех детей?
если да то что остановит геометрический рост
по факту рано или поздно придем к ББД, так как текущие тенденции автоматизации всего и вся к этому очень сильно подталкивают
В СССР по факту и был ББД, просто он там был реализован не в виде раздачи денег населению, а в виде гарантируемого Конституцией права на труд. Т.е. человек мог быть спокоен что в любом случае без работы он не останется, и любая работа даст ему достаточный для существования доход. В общем увольнения тоже никто особо не боялся, но и как-то особого роста эффективности труда не наблюдалось, уже в те времена все критиковали "уравниловку", когда за интенсивный труд платили столько же как и за простое просиживание штанов в течении рабочего дня, и у людей просто не было стимула особо напрягаться. Работодатель до последнего держал у себя даже совершенно бесполезных "работников", потому что это была государственная политика - у всех должна была быть работа, а это значит на всех предприятиях должно быть достаточное количество рабочих мест.
С другой стороны простая прямая раздача денег этих проблем не имеет, зато она имеет массу других проблем, видных по бедным районам США, где живут потомственные безработные, никогда в жизни не работавшие и не собирающиеся этого делать. По сути социальные паразиты, люди-глисты. Из такой среды даже талантливым людям сложно вырваться, и как по мне само ее существование очень плохо влияет на все общество. Зачем как-то напрягаться, заниматься саморазвитием, учиться, если рядом вот пример людей, которые живут не напрягаясь, ничем себя не утруждают и нормально себе живут, не бедствуют, и тебе что-бы влиться в их ряды тоже не надо никак напрягаться.
Право на труд это не тоже самое, что право какую никакую спокойную жизнь в тот момент, когда нет работы.
Ну банально, хоть какая то работа это все равно стресс, и она забирает кучу свободного времени.
Насчёт рантье и инфляции, ну так в Европе и сейчас полно людей на пособии, а ценник на жилье и так не особо то маленький, но это скорее потому что туда очень много желающих приехать. То есть это просто от того, что жилья меньше, чем желающих.
Это не проблема базового дохода как такового. Если жилья будет хватать, то оно не будет стоить слишком много. Ну вот еда нынче в конце концов, довольно дешёвая и люди с голоду в развитых странах не особенно то умирают.
Да даже гаджетов более менее на всех хватает, просто жилье штука побольше и посложнее.
Тут все дело в том, что спокойная жизнь это не про прогресс и развитие, это стагнация в лучшем случае, а чаще деградация. Надо ли оно обществу и человечеству в целом - вот вопрос. В истории уже достаточно примеров жизни разных обществ, в которых люди комфортно и спокойно существовали, пока к ним не приходили пассионарные соседи, у которых спокойной жизни и года не было, после чего спокойная (а чаще всего и просто, без прилагательных) жизнь заканчивалась.
ИМХО ББД в виде раздачи денег это зло маскирующееся под добро, оно уничтожает стимул развиваться для всего общества в целом, советская система имела свои минусы, но в этом плане была разумнее - никто не умирает от голода, но при этом все должны работать.
А я думаю, что это как раз переводит стимулы развития из просто заработать денег в самореализацию, ну потому что у людей полно мотивации выпендриваться перед друг другом различными нематериальными успехами. Ну или материальными, но значительными. Все эти стимулы в полной мере останутся.
Ну, скажем, выпендриться проще напялив на себя клоунский прикид типа как у негров в гетто, чем учить лет пять условный матан, и потом сушить мозги на какой-либо сложной инженерной должности. Человек такое существо, что всегда выбирает более легкий путь. В более жестких условиях жизни, "матан" стимулирует тем, что доход в итоге будет больше, условия работы лучше, и работа более уважаемая, чем у простого рабочего. А со спокойной жизнью - нахрена оно надо? Проще реально выпендриваться с одеждой, или научиться бубнить что-либо рифмованное под музычку, конечно, это тоже развитие, но науку и технику это уже не двигает никак.
Похоже, вы неявно исходите из того, что другие люди что-то должны, вам, обществу или стране. Ну не работает он, ходит в спущенных штанах, бубнит под нос и имеет полмиллиона подписчиков на тиктоке, ну и фиг бы с ним. Вы можете его игнорировать, не одобрять, словесно осуждать или тыкать пальцем и обидно смеяться, но требовать от него подтянуть штаны не можете, потому что не ваше дело. Зато можете написать в должностной инструкции правила ношения штанов и прочий деловой этикет. Не будем обсуждать перегибы с толерантностью :)
Я исхожу из того, что общество это управляемый объект и его можно направить как по пути прогресса, так и деградации. Внедрение ББД это путь к деградации, с массой "свободных" (видимо от любых обязанностей) личностей со спущенными штанами, которых в том числе и вам придется кормить своими налогами, ну если вы не захотите к таким как он присоединиться и все еще будете заниматься какой-либо полезной для общества деятельностью.
И, кстати - это вы а не я приравнял блоггеров к бездельникам, я такого нигде не говорил.
Ну классика же, еще с Римской империи. Но я слышал красивую легенду, что в демократических странах можно организовать партию, чтобы отстаивать свои идеи и интересы, и если она станет популярной. то изменить законы. Но пока законы не приняты, никто ничего требовать не может, максимум воспитывать детей в соответствующем ключе и фильтровать круг общения.
А про полезность для общества говорить не стоит, это часто табуированная тема. Из-за неё всякие неловкие вопросы возникают, типа почему труд шоумена и полицейского оплачивается лучше врачебного :)
А вы статью на которую ссылаетесь в самом начале читали дальше заголовка? Потому как Рик из статьи является классическим brilliant jerk, которых приличные компании еще на стадии собеседования отсеивают, и совершенно правильно делают.
Интересный момент про jerks, которые brilliant и не очень. Так как высказать свое мнение публично им величие не позволяет, они стараются гадить по-мелочи. Ну к примеру на Хабре они могут зайти и в карму нагадить. Вроде и мелочь, но приятно.
Поэтому, к реальным проектам, их ни в коем случае допускать нельзя. Отсев на этапе собеседования критичен вне зависимости от уровня гениальности. Человек гадящий по мелочи опасен для проекта.
Топать вы прочитали две статьи по линкам, состоящие из огромного количества аргументов и доводов, проигнорировали тот факт что в статьях нет ни одного момента пересекающегося с доводами в статье на Хабре, и хотите еще доводов? Это интересный подход.
Вот врать и искать бревно в чужом глазу, одновременно озадачиваясь минусами - это, действительно, интересный подход
Я не озадачиваюсь минусами, мне до них нет никакого дела. Я как раз привел минусы без какого-либо объяснения как отличный пример поведения которое на реальном проекте будет опасным и скорее всего будет выглядеть как тихий, или не очень тихий, саботаж работ.
В статье по первой ссылке это менеджер, который появился только в самом конце, хотя, появись он в самом начале - возможно, Рику и не пришлось бы работать два года сверхурочно и он бы не дошёл до такого состояния
Появись менеджер имеющий опыт с brilliant jerk в самом начале, проблем безусловно не было бы, так как в проекте не было бы Рика. Люди со звездной болезнью не переносят быть часть коллектива, и если их просят это сделать они предпочитают уйти. Что в итоге благо для проекта.
А в статье по второй ссылке решили просто не озадачивать менеджеров этим вопросом и работать только с ничем не выделяющиеся людьми.
Во второй статье менеджеры решили что здоровый климат в команде важнее наличия в ней "звезды" которая не хочет играть по общим правилам и требует своих собственных правил в ущерб команде и проекту. При этом разработка ПО это командная работа, где звезда по большому счету и не нужна, а нужны общие цели и задачи над которыми коллектив дружно работает. Так же не стоит забывать о том, что есть куча звезд в разработке которые не ведут себя как brilliant jerk, являются выделяющимися людьми, очень ценны для проекта и любимы менеджерами.
И заметьте, здесь гораздо больше информации, чем в Вашей пафосной писанине.
Пафосная? В каком месте? Что пафосного в утверждении, что brilliant jerk надо отсеивать еще на стадии собеседования либо увольнять после, если они таки просочились как-то?
Я наблюдал brilliant jerk дважды, в обоих случаях их уход из команды повысил предсказуемость разработки и моральный настрой команды, а так же сократил сроки. Сейчас, при намеке на brilliant jerk поведение на собеседовании я просто не нанимаю человека и все.
Это работает и в обратную сторону. С опытом к "культуре" и "дружным коллективам" относишься проще и спокойной меняешь компанию если перестал развиваться. Здоровый эгоизм необходим для личного развития..
Тейлоризм никуда и не девался, работая весь XX век уже в офисах. Есть на эту тему хорошая книга Joan Greenbaum "Windows on Workplace"
А пруфы гипотезы будут?
Новые сотрудники дешевле, чем старые.
С этого момента поподробнее, как с 2019 по 2022й новые были дешевле старых?
Один мой друг™ как раз в этот период своими глазами наблюдал следующий жизненный цикл:
Некий Иванов устраивается джуном в компанию за 80-100к. Наваливать на него как на мидла начинают уже месяца через три. Через год повышают в мидлы и дают 180-200к. Ещё через год повышают в сеньоры за 230-250к. К этому моменту он уже изрядно загнан режимом работы, разочарован отношением менеджмента к команде и проекту. Он уже не хочет этого повышения, но ему обещают, что с новым грейдом у него будет возможность влиять на ситуацию, всё изменить, улучшить, что многие проблемы были из-за недостатков прямо сейчас увольняющегося прошлого сеньора. Ещё через год он приходит к руководству с оффером на 500к, его называют предателем и шантажистом, говорят валить на все четыре стороны, он пишет заявление. В тот же же день его коллегу Петрова с мидлового грейда и 200к повышают до сеньора с 250к и садят на место Иванова. На освободившееся место Петрова нанимают джуна Сидора за 100к. Итого: проект годами агонизирует, но менеджменту это не мешает получать премии за экономию фонда оплаты труда, ведь у них три разработчика "делают" работу за рыночную зарплату одного.
Это частный случай. Вообще не видел подобного в масштабе индустрии. Все держались со всех сил за своих инженеров...
Ну, бизнесу это выгодно. Хотя бы в краткосрочной перспективе. Вот и все становится на свои места. Каждый должен заботиться о своей заднице
Если чел за 3 года дорос до 500к, ну чтож, наверное, лучше его отпустить с миром. Он либо гений, и тогда пусть там себе меняет мир и пускает ракеты, либо гений самопродажи - тогда пусть кого-нибудь ещё дурит, либо в компании всё сломалось с зп - надо сделать паузу и решить проблему (а то и закрыться - 500к всем платить никаких денег не хватит, может, ну его, вложиться в ларёк с шаурмой и жить себе?)
вложиться в ларёк с шаурмой и жить себе
Вы так говорите, как будто это что-то плохое. :)
Вроде мы тут все программисты, должны уметь оперировать абстракциями, но досадно много комментаторов вцепились в числа. Они ориентировочные. Какой-то джун за 50к работает, какой-то "сеньор" взрослел шесть лет, а не три. Важен описанный принцип организации конвейера по имитации эффективным менеджментом™ бурной деятельности. На него прекрасно ложится описанное в статье, опытные на таком конвейере не нужны, они только мешают.
Это зависит от того что вы делаете. Для того чтобы "клепать crud'ы" такой конвейр подходит хорошо. Если вы пишите софт под какую узкоспециализированную нишу, то уже не особо. Если ниша ещё и что-то из раздела медицины или АЭС, то вообще не работает на мой взгляд.
В этой схеме должен быть какой-то костяк своих айтименеджеров\техлидов, консельери)), которые этот баланс поддерживает и скорее всего в этой компании доход не зависит от IT напрямую - если так, то не удивительно т.к. IT это всегда статья расходов и возможность показать экономию.
Некий Иванов с джуна за 80-100, за три года дорос до оффера за 500? Возможно чел реально гений. Хотя судя по тому как там джуны становятся мидлами, а мидлы сеньорами ("в тот же день его колллегу повышают с мидла до сеньора") там все гении.
В целом, это отражает общее для современного бизнеса ресурсное отношение к людям как к бездушным заменяемым работникам, «трудовому ресурсу», а не индивидуальностям. Отсюда и типичная схема: получить максимум пользы от человека и заменить его новым. Про бывших сотрудников никто никогда не вспоминает, сколько бы пользы они не принесли компании в прошлом.
Полагаю, что сейчас уже более актуально: Отсюда и типичная схема: ... и заменить его новым роботом (RPA). Эдакий тейлоризм (тоже 21-го века) через RPA. В целом - всей "тотальной" автоматизации, просто на примере RPA это более показательно: робот делает ровно те же операции, что вчера делала его живая жертва предшественница.
Ленин про тейлоризм «... соединяет в себе утонченное зверство буржуазной эксплуатации и ряд богатейших научных завоеваний ...".
Из статьи следует, что самые лучшие разработчики, которые выделяются из серой массы — чуть ли не главная угроза для компании.
Из статьи следует что bus-factor это главная угроза для компании. А не разработчики как таковые.
Сова, натянутая на глобус. Слишком умных не увольняют. Увольняют тех, кто "тянет одеяло на себя", "ставит себя выше других", "отделяется от коллектива", тупо "хочет больше денег". Если ты настолько умён, чтобы тебя за всё перечисленное не уволили - тебя и не уволят. Знаю кадров, которые на официальной работе занимаются "левыми" приработками, потому что основную работу они делают за четверть своего рабочего времени и к тому же они достаточно умны, чтобы им не навалили работы ещё больше.
А так-то - да, тейлоризм процветает и в наше время, но "на галеры" ведь силком не гонят.
Мне кажется что это все очень индивидуально и если на сотруднике держится существенная часть проекта то в хорошей компании, разумеется к нему будет лояльное отношение, тут главное чтобы этот сотрудник не был агрессивным придурком который постоянно критикует своих коллег и может работать в команде
А чего бы не увольнять если этих айтишников развелось как собак нерезанных? В США могут уволить и тут же предложить оффер с уполовиненной зепкой. Типа делаем одолжение, не надо 5 этапный собес с литкодом проходить. Понятно что с а-ля product owner такие финты могут боком выйти, но обычного, сколь угодно опытного кодерка так заменить нынче вообще ни разу не проблема.
Это у них генетическая память 1937 года. Расстрелять (довести до бана) всех чьё мнение идёт вразрез с их убеждениями!
За пренебрежительно-оскорбительный тон, вестимо: "этих айтишников развелось как собак нерезанных", "кодерка", который еще и якобы сколь угодно опытный, а ни в какое сравнение с а-ля product owner не идет.
Есть один момент: "рок-стары" часто бывают переоцененными. Я не встречал человека, который один во всей компании постоянно знает правильный ответ на все вопросы. Да, есть люди с огромным опытом, но опыт частично устаревает (и где-то может пойти во вред из-за этого).
Поэтому если "звезда" создаёт сложную атмосферу в коллективе, рано или поздно издержки этого начинают превышать навыки "звезды".
Что такое невероятное знает и умеет "звезда" - кобол?, в какой таблице какого ГОСТа искать параметр?, почему здесь используется именно эта смазка? - всё это можно исследовать и найти ответы, возможно, даже лучшие, чем даст "звезда".
Звезда вполне может возникнуть и существовать за счето того, что остальные сотрудники просто не желают вникать в тему. Оно им просто не надо, поскольку есть звезда, которая все знает, и которая, если что, все расскажет и покажет. Впрочем, тааие звезды обычно или гаснут, или уходят сами.
" не боиться увольнения" поэтому отстаивает своё мнение и говорит правду, а не пытается вылизать до блеска.... можно было дальше и не писать))))
IMHO в статье перекручены и факты и выводы.
Умный сотрудник не обязательно должен ставить палки в колеса менеджерам, и тянуть одеяло на себя. Пришло требование - выполнил. Можно его частично обсудить, но это можно делать и безконфликтно.
Я не особо одобряю текучку, но если проект в застое, то что там делать людям с амбициями? Текучка в этом случае вполне норм - приходит новичок, для него непочатый край нового. За год осваивается, за два узнает все, а проект все там же, руководство не планирует повышения, потому что собственно а зачем? Руководству не нужны более умные сотрудники, чем есть сейчас, и денег на них не планирует тратить больше. Это тоже нужно понимать.
Тут один важный фактор забыт, который делает всю систему нелогичной. И он почти раскрыт вот этой фразой
хотя по факту именно он — последний носитель того прежнего, истинного духа компании, который будет безвозвратно утрачен после его ухода
Раскрою же до конца. Культура и дух компании диктуются ее этапом в жизненном цикле. Оптимальный дух задается ползунком performance - safety. К примеру, есть у нас В2В стартап, продающий что-то вроде очередной CRM или системы сквозной аналитики.
На первом этапе нет клиентов вообще, есть лишь несколько амбициозных фаундеров и что-то вроде понятийного соглашение с потенциальным якорным клиентом, который заплатит за решение своей проблемы + вложится в первый год разработки, если увидит потенциал. Основной риск - не решить его проблему, и не стартовать вообще. Понятно, что ползунок целиком находится в performance, и никого не волнует ни поддерживаемость, ни безопасность, ни количество багов. Надо сделать обещанное любой ценой и точка.
На втором этапе продукт уже есть, но теперь надо научиться работать с многими клиентами. Хардкод из этапа 1 начинает натирать. Технический лидер должен начать своим примером прививать любовь к тестам, выкатывать все через CI, паттернов придерживаться. Лидеру первого этапа это все может быть тупо скучным. Когда привык решать проблемы одним модифицирующим SQL запросом к прод базе, то как-то писать тесты, миграции, и решать ту же проблему неделю невесело. Соотвественно, дух первого этапа уже не то, что не нужен, а вреден. Не не сделать теперь риск, а увалить текущий бизнес.
На следующем этапе уже появляются интеграторы, допил инхаус на стороне клиента. Тут уже и педанта-технаря второго этапа мало. Надо процессы строить, коммуникации, документацию, стандартизацию. Снова таки, нужны новые лидеры, и, снова таки, лидеры прошлых этапов будут якорем тянуть назад.
Очевидно, что ползунок неустанно ползет от перформанса к безопасности. И КПД каждого отдельно кодера может упасть и в 100 раз. Но бизнесу это уже неважно.
Ну и да, тут ещё важный момент. Лидер предыдущего этапа всегда знает систему лучше, и решает проблемы быстрее, чем лидер следующего этапа. Поэтому, логично, что неруководящий технический персонал намного проще проникается к нему уважением (наш парень, говорит на понятном нам языке понятными парадигмами, только круче нас в нашем же ремесле - как такого не уважать).
И тут вполне может быть, что увольнение это прямо безальтернативный сценарий, чтобы двигаться дальше системе вцелом. Компании с избытком маржи могут ещё что-то вроде non -executive director практиковать, чтобы человек был рядом и пришёл потушить пожар раз в год, но это уже тактика. Все равно, человек уволен, по сути.
Это описываете ситуацию, когда изначально у вас было из рук вон плохо в плане масштабируемости, интеграции с другими сервисами и безопасностью. Потому что у вас изначально заявлена генетическая программа:
и никого не волнует ни поддерживаемость, ни безопасность, ни количество багов.
Эта программа очень явно намекает на то что у вас отрадясь не водилось высококлассных спецов. Прям совсем-совсем.
И когда настало время волноваться: или вы меняетесь, или вас заменят другими; у вас стал выбор нанимать куда более высококлассного специалиста, а лучше команду, либо оставаться такими как есть, но без клиентов. Потому что высококласный специалист/команда может/могут писать поддерживаемый, тестируемый, масштабируемый и безопасный код без захаркоженных переменных и велосипедов. При этом с высокой эффективностью. До которой прошлой команде надо длительное время на адаптацию. И то не факт, что все нормально смогут её пройти. А клиентам ждать этого всего времени нет.
Как понял, в статье описан совершенно иной случай, приведённому вами. Когда из компании выдавливают специалиста такого уровня, который понимает, что архитектуру изначально надо делать гибкую и масштабируемую, код писать с тестами, выкладывать на сервер с помощью сборочного конвейера, а никак не руками. Но он помнит и понимает изначально для каких целей задумывался проект, какие идеалы двигали командой разработки, что за смысл всех объединял и к чему хотели прийти. Мало того что он помнит, он их отстаивает и по возможности продвигает.
Заменяют его не всегда более компетентым, зато более покладистым и спокойным нежели был до этого. Который не будет идти против мнения руководства (часто нанятого) и особо приближенных, тем более посягать на власть менеджеров. Не всякий менеджер готов поделиться тем абсолютом, которым он владеет на работе. У многих из них в реальной не связанной с работой жизни властных полномочий нет никаких вообще.
Я, конечно, понимаю, что риск набраться минусов за этот комментарий крайне велик, однако мне хочется попробовать осветить вопрос с противоположной стороны баррикад. Рассчитываю на снисхождение. :)
Вышеопубликованные комментарии к статье, что очевидно и ожидаемо для Хабра, "программистские" - комментарии тех, чья профессия относительно востребована сейчас и в недавней ретроспективе и, несмотря на небезоблачность IT-карьеры в среднем и необязательно прямо такого успешного успеха в частности, чья профессия почти гарантирует занятость и даже более того, почти гарантирует занятость с окладами выше среднего. Тем не менее, принципы управления более-менее одинаковы как для производителей IT-продуктов, так и для вообще любых предприятий. Люди в IT-руководстве - такие же люди как и все, могут делать однотипные ошибки раз за разом и даже необязательно терять свою работу или вообще свой бизнес из-за этих ошибок, равно как могут придерживаться далеких от комфортного гуманизма принципов управления - я не одобряю и не оправдываю их, это просто безэмоциональный факт. А в чуть других сферах деятельности, где платежеспособный спрос на соискателей ниже, а самих соискателей на вакансию больше, дела для работников могут обстоять даже хуже, поскольку самодурству руководства остается больше пространства для маневра. Пример Амазона, приведенный в статье, в целом на отлично подходит.
"Слишком умный" сотрудник - это может быть ошибкой менеджмента (ошибкой оценки значимости сотрудника, ошибка оценки рисков для конторы, ошибка оценки рисков для самого менеджера, который может стать не нужен, что угодно еще такого плана), а может быть реальной проблемой, когда на одном человеке завязано критично много, а в его лояльности уверенности нет - и это безотносительно объективного проявления лояльности - безропотного согласия на повышенную нагрузку. Тем не менее повторюсь, в среднем контора с таким "слишком умным" сотрудником загоняет себя в ловушку зависимости от сотрудника. Поэтому избавиться от него - стратегически адекватное решение. Давайте отвлечемся от эмоций, потому что эмоционально мы, наверняка, будем на стороне такого "слишком умного", а некоторым из нас (не) повезло побывать в его шкуре. Мне, например, повезло - увольнение меня, когда-то такого же "незаменимого", дало мне столь необходимый пинок в свое время. А кому-то даже сегодня, спустя годы, все еще обидно за давнюю несправедливость. Оставим пока это и посмотрим с другой стороны: менеджменту, не конкретным эффективным менеджерам™, а безличным среднестатистическим управленцам, вполне лояльно работающим на свою контору, нужна предсказуемость результатов, выполнимость планов, и не нужны прецеденты, когда все валится из-за кого-то, кто вне штатного расписания стал ключевым сотрудником. То есть это не зависть, не ненависть, не какие-то личные мотивы - личные мотивы, конечно, могут быть, но невелика цена такому управленцу. Мне не нравятся рассуждения о том, что ключевой сотрудник затмевает авторитет руководства и подобное - если в каком-то частном случае это так то, повторюсь, невелика цена такому руководству. Нормально увольнение "слишком умного" - это просто устранение слабого звена в структуре конторы, а слабое оно своей значимостью для всей цепи., слабое в том, что вся цепь по сути держится на нем.
Можно ли сделать какой-то вывод? Ну, мир несправедлив, если оценивать справедливость со своей субъективной точки зрения. Хотя стоп, мы не об этом. Выводов не будет. Если руководство сделало рабочий процесс зависимым от "слишком умного" сотрудника, то это ошибка руководства, но исправить такую ошибку обычно уже невозможно, соответственно - увольнение. Уволить посредством несуразной нагрузки и неадекватно малой финансовой (да и эмоциональной) отдачи - один из негуманных, но реальных способов. Не одобряю, но это просто факт. Просто загнать лошадь, которая пристрелит себя сама. В общем, если вы "слишком умный", ищите себе новую - лучшую, более сложную и более оплачиваемую работу уже сейчас, пока вас не загнали до полного выгорания.
Доброшу только один тезис: увольнение "незаменимого" - не единственный способ избавиться от зависимости. Дублёр + настроенные процессы выглядят более устойчивой конструкцией.
Дублер - опасно. "Слишком умный" может почувствовать неладное. :) А вот настроенные процессы - это то, чего как будто не было совсем или было чисто номинально, потому что при настроенных процессах таких перекосов обычно не возникает вообще, а реально хороший сотрудник может заслуженно двигаться по карьерной лестнице и переходить к более сложной работе, где он эффективнее и для конторы, и для своего должностного оклада. Ну а если контора невелика и дальше расти физически некуда, то вполне возможно расстаться хорошими друзьями - нечастые примеры такого, думаю, многие из завсегдатаев Хабра смогут найти.
"Дублёр" подразумевает под собой наличие человека с несильно худшими скиллами. Да ещё и чтобы у него было время этим самым дублёрством заниматься. То есть в целом даже если и возможно, то достаточно дорого.
Нормальная организация и процессы такие проблемы в общем-то решают. Но во первых эти самые нормальные процессы я видел в фирмах относительно редко. А во вторых когда всё в этом плане организованно, то "рок-звёздам" часто становятся скучновато. Именно потому что рутина и она раскидана на всех.
"эффективные менеджеры" обычно неспособны оценить реальные возможности ни слишком умного ни дублера. То будет считать что дублер легко со всем справится ( а это не так), то наоборот, что там работа простая, можно легко заменить вообще кем угодно, главное заплатить достаточно. То будет считать что "умный программер" вообще незаменим.
В общем все проблемы "слишком умного" - это на самом деле проблема не очень менеджера. У умного менеджера слишком умные программисты - это его личные достижения и плюсы, что на его проекте работают такие люди, и могут отлично решать любые задачи.
вероятно ответ на поставленный статьей вопрос совсем простой - потому что хороших программистов min на два порядка больше чем хороших менеджеров, во всяком случае примерно такое соотношение видел по жизни за супер долгое время работы, вообще только единицы хороших менеджеров встречал на всех уровнях
Нормально увольнение "слишком умного" — это просто устранение слабого звена в структуре конторы, а слабое оно своей значимостью для всей цепи., слабое в том, что вся цепь по сути держится на нем.
Но вы только что уволили конкурентное преимущество компании. Она могла быстрее и за меньшие деньги делать работу. Теперь она стала предсказуемым середнячком и огребет больше проблем с конкурентами. Где же тут выигрыш в стратегии?
Возникновение незаменимого - это всегда ошибка менеджмента. Чаще всего эта ошибка осознанная и объясняемая жадностью, ведь нанять и развивать трëх дорогих спецов в три раза дороже, чем позволить одному тащить всë на себе.
По моему опыту - из того что видел на различных проектах, это следствие раздолбайства менеджмента. Им тупо неинтересно правильно организовывать процессы, ведь оно и само там как-то все крутится, ну подумаешь там, наш незаменимый Вася, орел комнатный, время от времени с горящей жопой в свои выходные что-то чинит в проде, мы же не жадные, мы Васю поощрим, деньжат ему подкинем, и вообще мы его уважаем и пылинки с него сдуваем. Главное, что благодаря Васе, нам не нужно сушить мозги всякой хренью типа организации кодревью, гитфлоу, CI/CD и прочими жуткими словами..
Потом, правда, Вася выгорает, посылает всех ко всем чертям и уезжает в лес сношать бобров медитировать, а бизнес весь разваливается, потому что оказывается, кроме Васи никто не в курсе как что работает и каким образом это чинить, но то такое..
Тем не менее повторюсь, в среднем контора с таким "слишком умным" сотрудником загоняет себя в ловушку зависимости от сотрудника. Поэтому избавиться от него - стратегически адекватное решение.
Стратегически адекватное решение – диверсифицировать бизнес, чтобы возможный провал одного проекта (а риск этого всегда есть, независимо от кадровой политики) не тянул за собой глобальных проблем. А не избавляться от генераторов прибавочной стоимости.
Если вы, как собственник, хотите надёжности и устойчивости любого процесса, вам надо класть деньги в банк под процент, а не заниматься таким рискованным делом, как реальное производство.
Поэтому, если для руководителя проекта потеря умного сотрудника и провал проекта – это ужасный крах, то для топ-менеджера – всего лишь одна не очень удачная коммерческая операция в ряду многих. А если у компании хорошие юристы, то, может быть, и вполне удачная.
Я с Вами полность согласен, вы очень точно подметили один не успоримый факт, а именно:
Тем не менее повторюсь, в среднем контора с таким "слишком умным" сотрудником загоняет себя в ловушку зависимости от сотрудника. Поэтому избавиться от него - стратегически адекватное решение.
Но вы как-то не упомянули и об обратной стороне: ок, да, контора действительно в опасности. Но ребята-управленцы, камон, но как вы такое допустили то? Как вы позволили такому случиться, если весь ваш бизнес или какая-то его значимая часть, стала зависеть от знаний единственного сотрудника? Тем более, что навярняка, этот сотрудник стал таким значимым, не за день, и не за два. Скорее всего это годы его работы.
Ну, и ответим же сами на этот вопрос: да блин, он стал незаменимым потому что вы тупо экономили на фоте. Да, вы не наняли еще других ребят, чтобы этот белолага не тащил все в одно лицо. Вы не распределяли работу так, чтобы бедолага не был единственным исполнителем по вашим задачам. Вас годами все это устаривало и вы были довольны - ведь бедолага был для вас единственной точкой входа для решения любого вопроса. А когда все перестало устраивать? Правильно, когда бедолага понял - эээ, почему зарплата одна, а тяну я все за четверых или более? Давайте денюжки, жмоты! И вот тут управленцы такие - чеееего? Каких денег паря, иди на рынок, мы тебя прям сейчас заменим Васька-Петькой за рубль за пучок. А почему так они говорят - потому что понятия не имеют, каким трудом и потом бедолага стал незаменимый. Вот эти управленцы думают, что да подумаешь - был Иван, станет Федор. Только все они упускают один момент - конечно Федор станет Иваном, но! А за какое время? За год, два или три? А гарантия результата точно есть? Ребятки-управленцы не задаются таким вопросом, т.к. бедолага для них - просто временный сервис, который за столько то денег оказывает им услуги. Ну ок, уйдет Иван, будет другой сервис. Такая у них парадигма.
Ну что ж, коли так все, то как говориться, удачи, т.к. однозначно этим горе-управленцам она еще обязательно пригодиться.
Но вы как-то не упомянули и об обратной стороне: ок, да, контора действительно в опасности. Но ребята-управленцы, камон, но как вы такое допустили то?
Так виноваты именно управленцы. Хотя, наверное, некоторые управленцы в такой ситуации могут воображать, что поймали Б-га за бороду, ведь у них за одну ставку работает человек, делающий почти вообще всю работу, не заикаясь ни о выходных, ни о премиях, ни об уходе. Ну, до какого-то момента, который почему-то кажется наступившим внезапно.
Ну что ж, коли так все, то как говориться, удачи, т.к. однозначно этим горе-управленцам она еще обязательно пригодиться.
Именно. И мой камент был именно об управленцах - о том, что это их вина, что такая ситуация сложилась, и что стратегически эта ситуация плохая для бизнеса, хотя сиюминутно кажется, что это просто невероятная удача.
Все намного проще.
Пока МЫ стартап - нам нужны "звезды" которые затащат и пусть они токсичат как хотят.
А когда МЫ стали ЕДИНОРОГАМИ, нам нужны просто исполнители влажных фантазий менеджеров.
Все зависит от того кто МЫ!
А еще есть такое выражение.
Если вы самый умный человек в комнате, то вы не в той комнате, где должны находиться
Из собственного опыта работы на фирме в Германии. В первую очередь увольняли менеджеров среднего звена и никогда опытных разработчиков.
вечно гонят на Амазон, у меня в Ирландии друг работает в AWS, уже лет 5, у него никакой текучки нет, 1 из 8 за 5 лет ушёл. Всем работа нравится. Если менеджер нормальный, то 10-15% рост зарплаты каждый год плюс бонус в конце года, где-то 10-12% от годовой з/п.
Amazon это не только AWS. Это ещё и складские рабочие и водители, которые работают в, скажем так, не слишком хороших условиях, по не слишком хорошим графикам и за не слишком хорошую зарплату.
Ну во-первых, статья была об айти специалистах и амазон упоминался тоже в контексте айтишников. Во-вторых, в любой другой компании, складские рабочие, доставщики и тд не получают миллионы, не работают с 9 до 5, с понедельника по пятницу и не сидят в кожаных креслах в личном кабинете. Такой несправедливый или, наоборот, справедливый мир.
Amazon в статье упоминается не в контексте айтишников, а в контексте складских рабочих. Перечитайте пожалуйста статью ещё раз, посмотрите ссылки и картинки. Там везде warehouse workers.
Складские рабочие, доставщики и т.д. действительно зачастую работают в условиях хуже чем условный ИТР. Но Amazon (и другие компании) в стремлении к эффективности из-за того, что даже минимальный процентный прирост этой самой эффективности создаёт существенный дополнительный доход из-за мультипликатора, связанного с объёмом продаж, устанавливает требования к рабочему процессу, которые заставляют людей работать на износ. Бесспорно, можно вспомнить хоть детский труд, хоть 16-часовые смены на заводах на заре индустриализации, но вроде бы была тенденция к смягчению условий труда, а теперь получается что "всё было зря". И всё это на фоне борьбы с профсоюзами, взятками за сокрытие увечий и т.д.
Слушайте, на последних курсах университета, я работал 2 через 2 по 12 часов. При чем с переработками и без праздников. То есть, иногда, я приходил в 12 ночи домой, а в 8 утра мне надо было быть уже на рабочем месте. И это было законно в России. И это была одна большая известная компания. И за 20 тыс рублей в месяц при стоимости однушки в 17 тыс рублей в месяц. В сша на складе амазона платят 36 - 46 тыс(27-40 тыс в зависимости от штата после налогов) долларов в месяц при стоимости однушки 800-900 долларов в месяц. И это с мед страховкой, официальным отпуском и тд. Плюс, обычно склады амазона в глуши и если бы не амазон, то работы там вообще бы не было. Плюс, это не рабство, никто никого не держит. Даже если там условия не очень, пойти поработать на год - два, чтобы скопить на учёбу можно пока молодой.
И опять же, на остальных аналогичных работах условия не лучше, просто журналист, который напишет об амазоне получит огласку, а политик, давящий на амазон получит поддержку населения, а журналиста или политика, давящего на "рога и копыта", эксплуатирующих полулегальных мигрантов, даже никто не заметит....
Про складских рабочих тут был пост, и причина роста эксплуатации работников — автоматизация, как это ни странно.
Ожидание фантастов: автоматизация будет облегчать труд работников, работник будет плевать в потолок и получать зарпату за то, что его работу будут делать роботы.
Реальность: за просто так никто работнику деньги платить не будет, работник не плюёт в потолок, а выполяет задачи, которые на данном этапе автоматизировать затруднительно.
Раньше складской работник выполнял как простые рутинные, так и сложные задачи, причём большую часть времени занимала рутина. Сейчас работника избавили от рутины, но заменили её сложными задачами. Работник просто не успевает отдыхать.
The irony is that his employment that offers relatively good health benefits is also taking a toll on his body. When Walter first started, his managers expected him to pick 290 items an hour off of the shelves robots carried to his station — nearly five items every minute. But, over the course of three years, Amazon leaders ended up pushing that goal more than 20 percent higher, to 360 items an hour, or six items a minute, he said.
В AWS тоже требовали писать 2900 строк кода в час, а потом стали требовать 3600?
У моего друга никогда такого не просили. Тут скорее зависит от менеджера, есть сумасшедшие, но вам никто не мешает перевестись в другую команду, проект и тд.
Точно знаю, что в Амазоне разрабатывали систему оценки продуктивности программистов, которая как раз подобного рода метрики собирает. Там что-то, похожеп на сколько времени в каком софте проводит, сколько маус мувов делает, что и когда коммитит, и так далее.
К сожалению, не владею информацией, внедрили ли.
А про справедливость или несправедливость -- я в целом не очень близок к "левым" идеям справедливости, но хочу заметить что Amazon это совершенно классическая корпорация зла постиндустриальной цивилизации из киберпанковских романов. Уклоняется от уплаты налогов, безжалостно эксплуатирует население, лоббирует свои законы на уровне города, штата и федеральном уровне, и т.д. Не хватает только якудза, которые расчленяют провинившихся плазменными струнами, но в современном мире вполне достаточно юристов и "сочувствующих" госслужащих.
В Америке у любой компании , скапитализацией в сколько-то миллиардов есть лобби, да и не только в США.
В принципе, вы описали схему работы любого бизнеса: эксплуатация работников, уход от налогов и лоббирование своих интересов на каком-то уровне. И это абсолютно нормально. Условный вы лоббируете свои интересы по жизни(отдаете ребенка не абы куда, а в хорошую школу, пытаясь договориться и тд., эксплуатируете других людей(платите копейки за уборку или ремонт квартиры низкооплачивамым работникам) и пытаятесь уйти от налогов, декларация свой доход в России под 4 или 13% вместо других стран, где они от 20%... так что не совсем понятно, почему вам можно, а другим нет...
Amazon это совершенно классическая корпорация зла
Безос оказался сам "амазонофицирован" женой. Теперь она может взять какого-нибудь молодого джуна вместо старого сеньора.
Пусть пойдут и поработают тогда в Волмарте, Таргете и миллионе других мест. Никто их насильно туда не тащит.
Нормального квалифицированного опытного сотрудника никто просто так выгонять не стремится. Чтобы такое написать, нужно ну уж совсем не понимать, как функционируют компании. В той статье, на которую имеется ссылка в начале, описан совершенно другой случай - токсичная примадонна. И, как верно сказано в той же статье, а также в ее продолжении, именно проблемы в менеджменте привели к тому, что вся эта ситуация зашла так далеко.
И, конечно, если автор видит менеджмент как кучку посредственностей, только и занимающихся тем, чтобы "спускать вниз очередное дурацкое распоряжение", то он (автор) просто еще немного не готов для анализа таких ситуаций. (Впрочем, после тезиса о том, что "текучка кадров выгодна компании" все стало ясно, и дальше читать не имело смысла).
существуют компании, которым текучка выгодна. Просто обобщил зря. Ну и на самом деле, людей бы пожалеть, цикличность какую-нибудь сделать, типа неделю на складе, пару недель на более спокойной работе...
выгонять - не стремятся. Но многие компании не стремятся и удерживать такого сотрудника. Парадокс, но менеджменту психологически проще расстаться с текущим сотрудником, который просит прибавку ( мысль менеджера "я сейчас плачу X, а теперь должен платить X+Y за ту же работу?" ) и нанять нового сотрудника за Z денег, где Z > X+Y , потому что "нам нужен сотрудник, а рынок труда предлагает только за Z или больше". На Хабре было несколько статей на эту тему.
У нас ребят и девушек набирали, которые еще учатся в институтах, за год дали мидлов.
И скажу вам они как говорит руководство "перфомят", без проблем и недовольств перерабатывают, получают еще больше опыта.
Качество кода хорошее, ревью проходят.
Некоторые "старички" опытные уходят, так как не готовы "перфомить"...
Дальше будет еще больше молодежи в ИТ и конкурировать придется очень серьезно.
Дальше будет еще больше молодежи в ИТ и конкурировать придется очень серьезно.
Не будет. Посмотрите на возрастно-половую пирамиду.
Да все наверное были такими юношами с горящими глазами...
Есть такая экономическая модель у некоторых галер. Иметь небольшой костяк сениоров - нянек, и набирать много джунов. Платить им мало, но опыта давать много. Первые два-три года это работает. А потом человек набирается опыта и уходит. Такой бизнес есть, он приносит прибыль и как говорится в добрый путь! Но работает это не везде и не всегда. А только в определенных нишах.
Добавлю. Это не работает на продуктах. Но иногда работает на аутсорсе
В целом, это отражает общее для современного бизнеса ресурсное отношение к людям как к бездушным заменяемым работникам,
А в не современном обществе было лучше? Я всецело за защиту прав работников, но здесь должен быть какой то баланс. А то в некоторых странах защита прав работников приводит к тому, что вывоз мусора прекращается, поезда ходят как придётся и прочим прелестям политики левого толка.
Заголовок не сходится с текстом статьи. «Опытных» и «умных» как раз не увольняют. Увольняют «дорогих». Тех, кто дорого обходится менеджменту, как в деньгах, так и в ресурсах. С кем «тяжело» договариваться. И об этом как раз в самой статье описывается. Странно выбран заголовок.
Если брать шире, то корень проблем часто зависит от того, какая обстановка внутри проекта, в котором находятся менеджмент и работники, у которых возникает конфликт между. Потому что часто бывает так, что менеджмент не понимает проблем работников, не понимает потому, что не находится на их уровне. Для них также виденье проекта может сильно отличаться от не только от виденья проекта работниками, но и от реального положения дел в целом. И из-за этой дезинформации может идти ошибочное представление о действиях работников. Примером может быть недавняя история с компанией Mytona, один из уволенных сотрудников записал открытое письмо и выложил на youtube.
Ещё есть примеры микроменеджмента. Когда менеджер, как низко квалифицированный специалист в некоторой области, находясь на высоком уровне в иерархии компании, пытается давать указания, как правильно делать тем, кто лучше него знает, как правильно делать. И когда указания менеджера игнорируются, в лучших побуждениях, он считает, что это «саботаж» и нужно увольнять тех, кто не прислушивается к нему. Это тоже проблема
Если бы не законодательные ограничения, то практически любой бизнес предлагал бы сотрудникам работать по 8, 10, 12 часов в день без выходных и отпусков
То-то Форд без всяких коммунистических революций уменьшил на своих предприятиях рабочий день до 8 часов без снижения зарплаты, и это привело к росту эффективности производства.
А в случае интеллектуального труда так вообще, увеличение продолжительности рабочего дня приводит не только к снижению удельной производительности труда, но и к снижению общей производительности. Программист, работающий 6-8 часов в день, будет делать больше, чем программист, работающий по 10-12 часов в день.
Заголовок статьи не совсем совпадает с содержанием. Опытный сотрудник не будет вести себя как "безумный гений" и настраивать против себя менеджмент.
Так же опытный сотрудник уже проходил( и возможно не раз) через стадии роста компании и может оценить, что от него ожидается в перспективе и принять решение будет ли он перестраиваться вместе с компанией или уволится и пойдет в другой стартап.
На хабре есть цикл статей Питера Тиля, там есть секретные мысли. Как например: "за каждым успешным бизнесом есть секрет". Контора существует по другой причине, не той что кажется вам или посторонним с улицы. Например, японские корпорации щелкнули по носу и лишили доступа к ресурсам и рынкам. И в 90-ые японцы перестали быть поставщиком запредельных технологий.
Вы сами переоценивате свою важность. Бизнес это про извлечение прибыли. И если завтра, например в вашей конторе, станут нужны агрономы, а не айтишники, то вы пойдете на улицу. То есть бизнесу не хочется, как вам кажется, иметь крутое подразделение из выдающихся айтишников просто самих по себе. Это ресурс, который нужно эксплуатировать. Рано или поздно наступает момент, когда звезды становятся не нужны. Звезды пишут скелет продукта и идут делать новый продукт. А развивают, те кто на Западе часто называется "техподдежка", посредственности которые саппортят легаси.
Мы с приятелям однажды рассуждали как всё держится на нас. Ушли. На следующий год контора продала в ТРИ раза больше продукции, просто изменился рынок.
Ресурсный подход работает в Магните, на складе тоже работает и больше особо нигде. Постоянная текучка это не дело, много ресурсов тратится на обучение. Медленная смена специалистов ещё может быть при реально высоких нагрузках. С другой стороны "эффективные" менеджеры проблема не хуже чем bus-factor. Застой тоже проблема, сложнее зазвездиться если есть прогресс. Знаю некоторые серые структуры, кстати довольно прогрессивные. Если там кто-то создаёт проблемы как звезда, то команду могут разделить. Проблем хватит на всех если честно.
В статье имеется противоречие:
Слишком эффективный мешает никчемному/не компетентному менеджменту
Компания нацелена на получение прибыли
Так может стоит что то делать с менеджментом?
Пожалуйста, продублируйте свою статью на Инфостарт. Прям очень актуально для 1С-ников, особенно работающих во франчайзинге.
«Рок-звезда» унижает окружающих самим фактом своего существования, а менеджеров ставит на место, метко комментируя результаты их глупых инициатив, тимбилдингов и планёрок. Он ведь сам не боится увольнения, потому что его с руками оторвёт любая компания конкурентов.
Ну и кому она нужна "звезда" эта? Его задача - писать код, а не метко комментировать результаты "глупых" инициатив и уж тем более ставить руководство на место. Если он хочет продвигать свои "гениальные" инициативы, тогда надо пытаться переходить на должность управленца или нормально объяснять, а если не получается, то не надо тянуть одеяло на себя. Если человек опытный и коммуникабельный, его вряд ли погонят за его "ум" (нормальное руководство так не сделает). А есть такие (как вы метко подметили "звезды"), которые общаться не умеют, но умеют кодить и думают, что они невероятно во всём гениальные, а по факту, в силу своей твердолобости, постоянно перечат начальству, спорят не по делу и, в силу отсутствия желания стать коммуникабельнее, теряют связь с реальностью руководством. А там и до увольнения остаётся не далеко. Кто их должен уважать, если они не уважают никого?
Еще играя в киберпанк понял что корпораты - зло. Я не за социализм, но за "капитализм с человеческим лицом". А так мем придумал:
Когда вас с другом уволили из вашей конторы (вас уволили за то что вы не укладываетесь в дедлайны и постоянно ленитесь):
Капитализм с человеческим лицом рано или поздно мутирует в то, что он должен мутировать - монополистический капитализм сверхэксплуатации, со всем этим вашим киберпанком. Ещё и с империализмом сверху, ему будет недостаточно вашего пота, они придут за вашей кровью и внутренностями. Погодите, погодите, кажется уже пришли...
Я часто вижу статьи с точки зрения работника, но редко вижу статьи со стороны управленцев. Поэтому отвечу тут. Есть несколько важных моментов, которые надо понимать.
Руководитель, вопреки мнению подчиненных, работает немного не так, как они думают. У любого руководителя есть зона ответственности, которую ему надо покрывать, а также "материал" для покрытия - это сотрудники или работники. Соответственно, руководитель работает с этим материалом, следит за его распределением, видит картину целиком, смотрит на связи и видит какие-то риски. Это просто надо понимать, что материал работы принципиально иной.
Также руководитель имеет свои цели - куда направить работу в зоне своей ответственности, а также с помощью какого материала (людей) двигаться к этим целям.
И вот здесь и есть точка разлома со старожилами. Так как я уволил их довольно много и не собираюсь останавливаться, то давайте расскажу, как это выглядит с моей стороны.
Если вкратце, то у многих старожилов есть проблема - они "бронзовеют". То есть с течением времени начинают:
себя отождествлять с компанией (я это и есть компания, я тут дольше генерального)
думать, что они знают как делать работу лучше других, так как у них больше опыта, так как они раньше уже все сделали
И вот тут как раз проблема, так как старожил думает, что он знает куда двигаться лучше других, так как весь предыдущий опыт ему подсказывает, что он все делал всегда правильно. Но не учитывает, что обстоятельства вокруг поменялись. У бизнеса появились новые задачи, команда трансформируется под эти задачи, но старожил живет своими старыми победами, он считает, что он все и так сделал уже хорошо все вокруг, что менять не нужно, что это ломает его любимое детище, которое он выращивал годами. Бинго! Это тот момент, когда с человеком пора расставаться.
Потому что, как только команда начинает трансформироваться под другие цели, то старожил начинает сопротивляться изменениям, он-то думает, что лучше было так, как он всегда делал. Нанимаются новые люди, они все делают по-другому и старожил начинает быть токсичным. А так как скорее всего это "опытный и таланливый" сотрудник, то токсичен он тоже талантливо. И это опять то время, когда пора расставаться.
И да, уход это может быть проблема для уходящего, но никогда не бывает трагедией для компании. Я не перестаю твердить своим подчиненным и всем вокруг - уйдет каждый, но остальные это не заметят. При уходе порвутся какие-то связи и процессы, но они очень быстро срастутся назад. Через две недели уже мало кто о вас вспомнит, через месяц все будет стабильно, как и прежде. Через три года даже имени не вспомнят.
Вопреки мнению автора, корпоративная культура - это не монолит, который не изменяется. Фактически корпоративная культура - ее создают те, кто сейчас работают, плюс какой-то слой корпоративных историй в прошлом. Культура непостоянна, но довольно стабильна, так как текущие работники нанимают близких по культуре. Но каждый новый работник привносит что-то свое. Также бывают агенты изменений, которые меняют культуру более радикально, но они бывают нечасто.
Поэтому, уважаемые коллеги руководители, меняйте старых забронзовевших подчиненных. Сначала это страшно, кажется, что все развалится в один миг, но это не так. Будет трудно сначала, но спустя пару недель все пройдет. Придут новые, зачастую не менее опытные и талантливые, и вы получите новый толчок в развитии, а не кандалы на ногах.
А может и нет. Бывает и так, что после смены "старых забронзовевших подчиненных" бизнес разваливается, и спусти 2-3 недели уже про него никто не вспоминает. Причем так происходит намного чаще, чем "толчок в развитии". А старожил спокойно в это время с усмешкой наблюдает за очередным на его памяти деэфективным манагером, спокойно работая на другом месте.
Давайте поверну в другую сторону. Старые забронзовевшие подчиненные довели бизнес до такого состояния, что он перестал быть устойчивым. После того, как от них наконец избавились, спасать в бизнесе стало нечего. А старожил "в это время с усмешкой" пошел разваливать следующего работодателя.
И кстати, зачем вообще наблюдать за своим старым работодателем? Это перевернутая страница, не за чем ей голову забивать.
И кстати, зачем вообще наблюдать за своим старым работодателем?
Во-первых, мне не безразлична судьба людей, с которыми я годами работал плечом к плечу и пуд соли съел. Во-вторых, мои проекты - моё детище, я вкладывал в них всего себя, мне не безразлична их судьба. В-третьих, эти проекты - это моё портфолио, их как можно более длительное благополучие мне выгодно. Наконец, бывшие боссы часто звонят с просьбами о помощи.
Да я и сам иногда общаюсь со старыми коллегами, проблем нет. Выше просто описывался другой случай, и он явно не ваш.
Бывает и так, что после смены "старых забронзовевших подчиненных" бизнес разваливается, и спусти 2-3 недели уже про него никто не вспоминает. Причем так происходит намного чаще, чем "толчок в развитии". А старожил спокойно в это время с усмешкой наблюдает за очередным на его памяти
деэфективным манагером
"зачем вообще наблюдать за своим старым работодателем"
Чтобы учиться на своих ошибках и понимать последствия своих действий. Если после вашего ухода контора выстрелила и все там стали миллионерами - то может нужно в своем восприятии мира что-то поправить.
Работая с людьми, как с материалом ты и относишься к ним, как к материалу и сразу предполагаешь, что диалог невозможен.
Да и нет такого "знаю, как будет лучше".
Люди ещё пару веков назад "знали, что кровопускание снимает головную боль", а сейчас люди знают, что это опасно и не поможет. С другой стороны есть заболевания крови, сосудов, которые приводят к головным болям.
Нет такого термина при поиске решения, "знаю" особенно в бизнесе.
Всегда вместо знаю идёт какой-то ресерч проблемы, всегда все ищут компромисс чтобы удовлетворить то, что важно.
Да и люди могут быть токсичными по сотне причин начиная от банального здоровья заканчивая проблемами в семье.
Конечно, это проблема человека, если он чрезмерно токсичный и не пытается решить проблему, но возможно, он ведёт себя так потому что вы его не слушаете и даже не пытаетесь услышать?
Работая с людьми, как с материалом ты и относишься к ним, как к материалу и сразу предполагаешь, что диалог невозможен.
У каждого работника есть "материал", с которым он работает. Плотник - с деревом, программист - с кодом, руководитель - с людьми. В чем здесь претензия?
Нет такого термина при поиске решения, "знаю" особенно в бизнесе.
Если у руководителя нет понимания будущего, куда он движет свою компанию, то получается судно без ветрил. Это может быть нечеткое и неясное понимание, которое дорабатывается в процессе движения, но цель всегда есть.
Руководитель всегда транслирует вовне свое видение будущего.
Даже если нужно какое-то исследование, то за принятие конечно решения всегда отвечает руководитель. Это не вопрос авторитарности или демократичности в стиле управления. Это просто осознание того, что от вашего решения зависит, какую зарплату ваши подчиненные принесут домой.
Да и люди могут быть токсичными по сотне причин начиная от банального здоровья заканчивая проблемами в семье.
Почему работодатель должен за это платить?
А Вы как относитесь к рассмотрения себя самого в качестве "материала"?
"хоть горшком назови, только в печь не ставь"
Вообще без проблем. Кто-то выше меня также формирует свою оргструктуру, где мне отведено весомое место. Кто-то работает с материалом для построения организации.
Ну, надеюсь, что Вас при очередном каком-нибудь формировании не сочтут забронзовевшим и на весомое место не поместят другого сотрудника :)
Здесь немного лучше копнуть в сторону почему вообще сотрудники бронзовеют. У сотрудника могут быть разные стратегии жизненного цикла работы в компании:
Прийти к новому работодателю с пониманием целей, зачем он устраивается. Например, SAP консультант на проект. Проработал год хорошо, получил опыта, ушел спокойно.
Прийти к новому работодателю, обжиться, в комфорте работать, как можно дольше. Это зачастую связано с тем, что смена работы для сотрудника это стресс и он боится уходить.
Последний случай может распадаться на несколько. Часть имеет конструктивное продолжение, а часть деструктивное. Пример конструктивного длительного трудоустройства - расширение обязанностей внутри работодателя, либо периодические горизонтальные перемещения.
Но есть и деструктивные сценарии - забронзоветь. Зачастую в этом варианте, работник или руководитель цементируют свою позицию. Например, удаляют внутренних конкурентов, либо нанимают себе слабых подчиненных. Люди становятся токсичными (раньше было лучше и проч).
И соответственно, задача руководителя такие ситуации знать, выявлять и на них реагировать. Вплоть до увольнения.
При этом у такого процесса всегда есть внешние признаки. Так как уволить человека довольно сложно. В качестве признаков можно выделить самое простое - негативная обратная связь, неповышение, плохие годовые оценки, лишение премий и прочего. Если до этого доходит, то что-то происходит не так и работнику неплохо бы посмотреть вокруг и понять.
Если же вы переживаете за меня, то прошу не переживайте, у меня пока все хорошо.
Я думаю, что никто не бронзовеет, это просто термин который придуман теми кто увольняет чтоб им можно было спокойно спать по ночам. А по сути это просто грубость - взять уважаемого человека и обвинить его в том что он забронзовел даже если сидит в бейсменте как мышь и молчит как партизан и тупо молча работает.
Речь не о тех, кто просто работает. Речь именно о тех, кто думает, что раньше было лучше, а вот сейчас все как-то не так, и поэтому боится принимать решения и двигаться вперед вместе с компанией.
Я в целом считаю, что в любой команде должен быть здоровый микс из звезд и нормальных обычных работников. Если все будут звездами, то они очень быстро получают опыт и разбегаются. Более того, я таких всячески удерживаю.
просто термин который придуман теми кто увольняет чтоб им можно было спокойно спать по ночам
Не драматизируйте. Уволили - это не конец света, это новый импульс для человека. Меня на заре карьеры тоже увольняли. Неприятно, но следующая компания была на порядок лучше, поэтому по большому счету я даже рад, что меня тогда уволили.
И да, если вы хотите стать руководителем, то многие барьеры придется преодолеть. Ничего личного, только бизнес.
Тут дело не в драмах а в элементарной вежливости и профессионализме руководителя - вот и все. Можно уволить как в фильме Bulldurham - в принципе я такой подход считаю нормальным, часто можно двигаться дальше (не каждый это может, скажу однако, видел реально плачущих разрабочиков 50-60 лет у которых личные обстоятельства просто взяли их за горло да и фильм на эту тему снят даже Falling Down) . Но говорить людям что они забронзовели - это элементарная грубость и непрофессионализм, вот и все.
А , нет не все - раньше действительно было лучше - это факт. Это просто биологический факт. В эпоху Виндоус 95 и нетскейпа программистом мог на работу устроится кто угодно . Лично был свидетелем как человеку без опыта Стэнфорд предложил 75 баксов в час за позицию на PHP. Сейчас временя реально поменялись и рынок стал намного жестче.
Мы с вами сейчас переписываемся вне рамок профессиональной деятельности, поэтому я могу отклоняться от рабочей этики в довольно широких пределах. Очевидно, что в реальных трудовых отношениях у меня другая модель поведения. Поэтому давайте опустим из разговора слова о вежливости, (не)профессионализме и элементарной грубости.
Если по существу, то я не смотрел фильма и не знаю, как там увольняют. В российских реалиях, если сотрудник устроен полностью официально и на белую зарплату, уволить его довольно проблематично и такое увольнение готовится долго и скрупулезно вместе с отделом кадров:
дается неоднократная обратная связь
ставятся четкие цели и детальная проверка выполнения
выставляются оценки работы сотрудника
иногда практикуется совместно выполнение задач (shadowing)
Поверьте, нормальный HR вас на полном ходу остановит, если будете пытаться делать как в американских фильмах. Это грозит трудинспекцией и прочими прелестями, от которых надо бежать, как черт от ладана.
Да, всегда поражался глядя их кино, как там человек может придти на работу, а его вещички аккуратно сложенны в коробке на входе и охранник говорит ему что - прости чувак, тебя уволили и велено не пускать. В России такой номер прокатит только если ты работаешь по черному, что уже не так уж часто встречается, даже не в IT.
Ну я не в США, а в Германии. У нас достаточно жёсткий ТК. При этом я тоже могу придти на работу а мои вещички аккуратно сложенны в коробке на входе и охранник говорит что — прости чувак, тебя уволили и велено не пускать.
Просто фирме придётся выплатить мне компенсацию, равную минимум зарплате за срок положенный на увольнение по ТК.
В такой системе есть некоторый смысл - ничто так не мотивирует выполнять работу на 110%, как страх потерять работу и средства к существованию.
С другой стороны, такая система ограничивает в инициативе. Сотрудник не замотивирован на свое личное мнение, так как есть риск, что когда ты его выскажешь, то очень быстро потеряешь работу.
В такой системе есть некоторый смысл — ничто так не мотивирует выполнять работу на 110%, как страх потерять работу и средства к существованию.
Или наоборот тратит время не на работу, а на то чтобы всегда в наличии был "запасной вариант" на случай если вдруг уволят.
Так же это мотивирует на то чтобы делать себя "незаменимым". Причём далеко не всегда именно полезным для фирмы образом.
А ещё это мотивирует на вещи вроде создания профсоюзов. И так далее и тому подобное.
А еще это создает благоприятную почву для вседозволенности со стороны всевозможного менеджмента. Над людьми можно изгаляться как хочешь ,потому что они боятся потерять работу.
Поверьте, нормальный HR вас на полном ходу остановит, если будете пытаться делать как в американских фильмах.
Да, я слышал об этом когда пытался создать офшорный стартап в России - мне тоже говорили что уволить в России не так просто .
В США большинство штатов at - will - employment могут уволить в любое время по любой причине (кроме дискриминационных) - и в принципе это не страшно в большинстве нормальных случаев поскольку сразу можно найти работу. Персонально мне на нервы действует только когда руководство пытается представить дело так, будто это не их плановая политика а мол вина сотрудника.
Понимаю, что американские фильмы не всем интересны но не могу удержаться чтобы не посоветовать культовый фильм про разработчиков Office Spaces :) Там тема данной статьи показана просто шедеврально в стиле комедии.
Спаведливо, согласен
При уходе порвутся какие-то связи и процессы, но они очень быстро срастутся назад. Через две недели уже мало кто о вас вспомнит, через месяц все будет стабильно, как и прежде. Через три года даже имени не вспомнят.
Прошло уже больше года с тех пор как я уволился. Мой старый работодатель до сих пор регулярно платит моему новому за моё время потому-что со мной ушли 11 лет опыта работы в той конкретно компании и 20 лет стажа в этой сфере.
Так что по разному бывает.
Да я и не претендую на единственно верное знание, наоборот, показываю другие грани происходящего. Здесь каждый работодатель строит свою стратегию исходя из рисков и расходов.
Ваш случай - это один из вариантов стратегии. Мне он лично не нравится, так как рано или поздно Иван Иванович и Иван Никифорович могут поссориться, но не я же принимаю решение.
У бизнеса появились новые задачи, команда трансформируется под эти задачи, но старожил живет своими старыми победами, он считает, что он все и так сделал уже хорошо
Вообще, мне казалось, что объяснять изменения, причины изменений и их необходимость как раз и входит в обязанности менеджера. А из вашего текста следует, что старожил таки остался в своем мнении, что старая стратегия поведения эффективнее. Причем вы сами пишете, что он эффективен во всем, даже в токсичности, но гоните от себя мысль, что он также может быть эффективнее и в управлении — тут почему-то вы даете фору себе самому.
но гоните от себя мысль, что он также может быть эффективнее и в управлении — тут почему-то вы даете фору себе самому
Тогда бы он занимал руководящее место. По условиям задачи он старожил и работает дольше своего руководителя.
Вообще, мне казалось, что объяснять изменения, причины изменений и их необходимость как раз и входит в обязанности менеджера.
Конечно обычно так и делается. Но в данном случае у нас идеальный старожил, который и так эффективен и талантлив и должен понимать, что и зачем происходит.
Тогда я еще раз обращу ваше внимание на 2 противоположности в определении старожила: он одновременно "достаточно менеджер", чтобы понимать все изменения (и даже угадывать их без вербальных объяснений, по косвенным признакам). И одновременно "недостаточно менеджер", чтобы его стратегия была эффективнее. В информационных системах участки с такими противоположностями обычно и порождают проблемы, т.к. в реальности можно занять лишь одну точку. Подозреваю, что в сфере управления людьми это также выдаст проблемы.
В сфере управления людьми, к сожалению, сложно определять какие-либо алгоритмы и точные прогнозы, так как люди довольно уникальны и их мотивы и реакции также. При этом с течением времени эти реакции могут видоизменяться в широких пределах. Например, выгорание или резкое изменение внешних условий среды.
Поэтому мы можем смотреть на сферического старожила в вакууме, но он никогда не будет отражать всей полноты картины в реальности.
В этом и заключается искусство руководства - эмпирические знания о разных людях и умение направлять их в нужном направлении. А также отвечать за свои решения.
Это до поры до времени. Есть у нас методы и на Костю Сапрыкина :)
Поддерживаю, увольнять надо, для их же блага: мир посмотреть - себя показать. Сам бронзовел. Теперь переходя на новую работу стал замечать следы патины на местах осёдлости таких вот сотрудников. Как правило это жуткий набор незадокументированных костылей, рабочих решений, которые устарели. И чем реже менялся персонал, тем меньше документации было. Так-что бронзовеющих нужно заставлять писать "мемуары" перед увольнением.
Рок-звезда» унижает окружающих самим фактом своего существования,
Разделяй и властвуй, да? Опять цены на сеньоров пытаетесь сбить? (шутка с долей правды)
Звучит очень лицемерно, звучит, как повод издеваться над людьми, которые чуть умнее тебя. Не одобряю любые виды унижений.
Умный сотрудник полезнее всегда. С умными очень просто общаться и этот человек сразу тебя понимает без лишних слов. Тогда, как кому-либо другому нужно целую тираду сочинить чтобы объяснить свою мысль. (привет первое место работы)
Но есть один большой нюанс во всей этой ситуации. Когда кто-то называет человека умным, он как бы интуитивно подразумевает, что это человек умён во всём.
Но это не так. Скажи мне написать код на Rust и первые 3 месяца я буду писать, как джун с опытом, но как джун.
Ты увидел, как человек умеет что-то чего ты не умеешь или он умеет это лучше тебя и сделал логическую ошибку, что он умнее во всём.
Сумбурный итог:
Часто умный человек это узкоспециализированный специалист(или фуллстак), которого днём с огнём не сыщешь.
А уж нужен вам умный человек или нет. Решает ваша харизма и умение общаться с людьми. Я бы сказал многое в жизни решает только харизма.
Если вам такой человек не нужен увольняйте смело, сейчас рынку, они, как раз и нужны.
Мне жена подсказала такую мысль и как раз делала работу за десятерых и была такой рокзвездой, только не в IT, а в отделе персонала (дикая бюрократия):
Отношение к старожилам зависит от способа получения прибыли в компании и наихудший случай как раз наблюдается в гоcкомпаниях, которые в основном работают на отмыве денег (например, перекредитация под будущие гособоронзаказы). В этом случае увольнение старожил - это способ раздутия штата и увеличения Фонда Оплаты Труда (ФОТ), а, следовательно, и зп начальника. Раньше один старожил делал всю работу (вполне себе по должностной инструкции и имеет много личных контактов и на работе и с контрагентами). Начальник его выгоняет/выживает, работа встаёт или дико тормозиться (потому что другие сотрудники не имеют того набора личных контактов). Дальше начальник такого подразделения бежит к руководству, что это старожил всё "развалил" и на восстановление процессов надо ещё 2-3-5 сотрудников (как наглость позволяет). О поднятии ЗП старожилу речь никогда не будет идти, т.к. это не приносил личной выгоды его начальнику.
В общем так выглядит ещё одна "причина" увольнения ценного сотрудника. Такая ситуация может быть и в карманных IT-компаниях.
Возможно для кого-то это открытие, но это уже давно не секрет и есть два типа руководителей: сильные и слабые руководителя.
Слабые руководителя боятся конкуренции со стороны сотрудников, поэтому они конечно же боятся конкуренции со стороны своих сотрудников и берут в команду заранее слабых сотрудников, поэтому эффективность работы таких команд всегда будет хуже, чем более сильных команд. Если слабый руководитель занимает позицию тимлида, то у него 30-60% времени будет уходить на операционку, а не практику, поэтому ему будет сложно профессионально расти как сеньору или мидлу.
А если это менеджмент уровень, то у него 100% времени будет уходить на операционку и он не будет практиковаться.
Но слабый руководитель не понимает одного. Не все хотят быть руководителями и я видел очень хороших тимлидов, которые становились просто сеньорами, так как хотели заниматься практикой, а не теорией.
Поэтому сильный руководитель развивает своих хардскилы именно в управлении и развитии командой, а не практике, поэтому сильный руководитель нанимает сеньора и делаем для него такую атмосферу работу, чтобы этот профессионал развивался и делился опытом и знаниями с менее опытными коллегами.
Итого:
Тимлид, а тем более руководитель менеджмент уровня, в большой степени менеджер, а не практик и его задача создать сбалансированную команду из синьоров, которые будут делиться опытом и знаниям, мидлов, которые будут выполнять работу и джунов, которые будут развиваться.
Руководитель может не обладать сеньорскими знаниями по всем предметным областям, так как его харды - развитие команды, а не "работа руками", но при этом руководитель должен обладать мидловскими знаниями по всем областям, в которых работает его команда, чтобы как минимум поддерживать джунов.
"Почему увольняют самых опытных? Потому что они слишком умные"
Безотносительно к тому , верно ли это утверждение или нет важно отметить что чисто по субъективным причинам те кто производят увольнение вполне могут так делать. Просто потому, что раз это обсуждается и вообще раз так думают многие, то исходя из этого руковдоство вполне может поверить в то что это жесткая но правильная стратегия и поступать именно так.
Даже если опытный сотрудник будет вести себя тише воды ниже травы, не высовываться честно выполнять работу и ходить на цырлах - без разницы. В некоторых компаниях он все равно приговорен и ничего с этим не поделаешь.
Хотя лично мне гораздо неприятнее то, что когда я был молодым - тогда вокруг меня увольняли всех - от рядовых до директоров а меня держали. И не стеснялись мне говорить что я суперстар. Прям так на полном серьезе и уверяли. И те кого увольняли были старше меня. Помню поперся однажды на встречу однокурсников и меня спросили - а как у вас там в Америке отношения на работе? Тебя никто не трогает. И я не моргнув глазом сказал - честно сказать я не могу этого понять но мне кажется что все те, кто со мной рискнет поспорить почему то быстро теряют работу. И меня это пугает. С тех пор прошло 20 лет. Итог - за последние 13 лет я 8 раз был уволен. Это несмотря на то что я адаптировался по полной - выучил все по самому последнему писку, молчу как рыба и т.п. Сути дела это не меняет.
Это соответствует общему цивилизационному тренду - человечество ищет как и что передать роботам, тренируется пока на живых людях. Эти живые, страдающие люди, комок нервов и выгорания пока имеют некоторый запас времени для адаптации. Менеджерам тоже хана, кстати, они будут не нужныю. Зачем это всё новому типу - "творцу", который будет с фабрикой роботов разговаривать через чат джипити условно. Как железный человек из комикса. Обе стороны пострадают и трансформируются, возможно в ноль. Слава богу, или скорее, хорошо для эволюции, эти две стороны не смогут договориться и жить мирно загнивать. Вернее, договориться на текущих условиях не смогут, но к чему-то же этот диспут приведёт, к какому-то другому устройству. Якобы останутся лишние люди, но человечество в тренде старения и сокращения, недоразвитые страны тоже к этому присоединяться. Да и солнце скоро погаснет, надо уже манатки собирать и в путь.
Мне кажется что на данном этапе джипити это скорее "фича не баг" если говорить с точки зрения поиска работы :) В том смысле что сейчас пока еще можно получить сертификат по OpenAI сделать какой нибудь проект в Open AI Gym и в принципе можно найти неплохую работу в области ИИ. Так сказать вовремя перейти в быстрорастущую отрасль.
Критикуешь - предлагай, предлагаешь - осуществляй, осуществил - неси ответственность.
А болтать, что менеджер плохой, при этом боясь расширения полномочий, много ума не надо.
Критикуешь - предлагай
Это не всегда уместно. Бывает что-то предположительно, а то и очевидно плохое, критика чего, будучи адекватно аргументирована, уместна и в целом полезна для избежания/устранения плохого. Предложить что-то лучшее взамен - вообще отдельный вопрос, с [аргументированной] критикой плохого не связанный и, возможно, радикально выходящий за пределы компетентности критикующего. Так что нет, не нужно этой подмены понятий.
предлагаешь - осуществляй
Необязательно. Инженеры проектируют, строители строят, экспуатанты обслуживают. Заставить инженеров строить? Глупо. Нет, каждый должен заниматься своим делом.
осуществил - неси ответственность
В пределах зоны ответственности. Не больше. Но и не меньше, конечно.
А болтать, что менеджер плохой, при этом боясь расширения полномочий, много ума не надо.
У менеджера круг задач довольно сильно отличается от такового у разработчика программного обеспечения, от чего даже хороший менеджер может иногда казаться полным идиотом или последней скотиной, а плохой менеджер - не только казаться, но и быть. Тем не менее, писать код без менеджера в среднем хуже, чем с ним. Можно сколько угодно приводить примеры фриланса - хорошие примеры, годные, однако бизнес крупнее одного самозанятого требует наличия служб, поддерживающих рабочий процесс и продажу результатов работы, за счет чего, обычно, обустраиваются рабочие места включая мыло и туалетную бумагу, а еще за счет чего платится зарплата. Просто потому, что разделение труда эффективнее. Кто-то пишет код, кто-то продает написанное, кто-то моет унитазы, кто-то поддерживает эту структуру, кто-то ставит и решает глобальные, стратегические задачи развития. Может ли разработчик софта аргументированно критиковать менеджера за ошибки в структуре предприятия? Вполне. Обязан ли и может ли в принципе разработчик софта предлагать пути исправления ошибок? Необязательно.
А можно, всё-таки, объяснить, что делает менеджер (как бы можно было бы сказать, управляющий)?
А можно, всё-таки, объяснить, что делает менеджер (как бы можно было бы сказать, управляющий)?
В широком смысле слова обеспечивает вас рабочим местом, обеспечивает вас работой, и продает результаты вашей работы так, чтобы можно было выплатить вам зарплату. То есть арендует офис, покупает туда мебель и оргтехнику, ищет заказы на разработку или чем там еще занимается контора, а в случае среднего и крупного бизнеса - поддерживает эффективную структуру и межструктурное взаимодействие отделов, филиалов, подразделений и тому подобное. То есть все, кроме разработки ПО, на которую нанимают вас - вы при этом не обязаны задумываться, откуда у вас стол, кресло, компьютер и, главное, деньги на зарплату.
Это госгении всю сферу жкх по таким принципам пытаются выстроить, кажется. Что типа если че не так - велкам, собирайте 100500 соседских подписей, шлите письма в Спортлото, вот вам самоуправление на местах. Чем критиковать их мегауслуги - делайте!!!111
// Кстати, вся статья очень забавно ложится на устроенную в стране "вертикаль власти"))
Довольно грустно читать комментарии. Ощущение зеркала для целой индустрии. И не только...
Почему же мало говорится о причинах? Почему наваливается много работы? (Точнее, наваливают.) Почему новичкам приходится долго входить?
Да, всегда есть опасность "забронзоветь". Человек, долго находящийся в определённой позиции, неизбежно закостеневает. Но существует такое понятие как ротация кадров, когда люди меняются местами (ротация=вращение). Это означает, что время от времени, нужно менять сферу приложения сил. А для этого надо, чтобы имелись эти самые различные области приложения сил. Нельзя допускать, чтобы кто-то занимался всем сразу. И, уж, тем более, нельзя допускать, чтобы кто-то занимался этим в режиме 7/24. Хотя этот режим и является повсеместным явлением и, даже, приносит свои положительные результаты, но положительность этих результатов весьма относительна, и, наверное, работу можно организовать как-то иначе. Я бы с огромным интересом прочитал про то, почему именно приходится работать в режиме 7/24. Ведь это возможно только при условии, если постоянно поступают какие-то вводные. А почему они поступают? Если есть какой-то пул задач, до дождитесь окончания их выполнения! (В конце-концов, есть ещё и ответственность за ранее принятые решения!) Что-то сломалось? Нужно писать много кода? И, что, так происходит годами? Мне всегда казалось, что с годами можно накопить набор библиотек, полностью обобщающих предметную область. Написание таких библиотек — это сахар для упитанного разработчика, находящегося в самом расцвете сил. Вот и посадите за это дело "звезду". В принципе, никто не мешает "звезду" и уволить, но это должно происходить только со стороны звезды, когда "звезда" дошла до самого верха возможной компетентности, а не в каких-либо конфликтных обстоятельствах. Между прочим, написание такой обобщающей библиотеки — это хорошее приложение сил и для "джунов": им всё-равно приходится разбираться в накопленном коде, но они делают принципиально новый код, на новых принципах, новый код не идёт в "продакшн", в "продакшене" делается код только по старым лекалам и старыми силами (силами "миддлов" и "сеньёров"). Эти два потока — текущая и будущая разработки — никак не могут пересекаться! Это и есть подлинная диалектика, когда в компании есть рабочий костяк, заточенный на "текучку", внутри которого есть высококвалифицированные и ведомые "миддлы" и ведущие "сеньёры", а есть и специальный отдел, где имеются самые молодые и самые опытные, и где ведутся, по сути, научные разработки. В таком мире есть место всем, всегда есть куда расти, идёт постоянная динамика, а ротация кадров позволяет каждому почувствовать себя в любой позиции и на любом направлении деятельности. Ведь, что самое печальное в долгом пребывании на одном и том же месте? Это профессиональная деформация, когда своя область работы диктует свой язык и формирует определённое мышление. А это разрушает коммуникацию. И тогда любая контора превращается в Вавилонское столпотворение.
И ещё. Весьма характерно, что никто из комментирующих не привёл ни одного практического примера реальной разработки продукта, что называется от и до. (были, конечно, отдельные попытки) Ведь, самое интересное — проследить траекторию проекта и наглядно увидеть роли всех действующих лиц. Наверняка окажется, что на каком-то этапе управленческая логика разошлась с логикой разработки целевого продукта (то есть — произошла подмена целей). Но это надо пример(ы) изучать. А на примеры у нас как-то руки поговорить не доходит. :-(
Какой то токсичный рокстар у Вас получается.
Нормального рокстар, отлично вписавшегося в дух компании, умного и опытного, нормальная компания будет стараться продвигать в мененджеры, архитекторы, техлиды, R&D, CTO наконец, в зависимости от его талантов и предпочтений. Ведь это напрямую мапиться на доход компании.
Тем не менее, в Штатах вполне себе работает бизнес-модель с рок-звёздами и менеджерами в 1 флаконе. Я был там с изучением опыта в крупной нефтяной компании. Подразделение, где молодой менеджер с 2-3 годами опыта успешно руководит работой узкоквалифицированных профильных специалистов с 30-летним стажем и получающим ЗП в разы больше него самого - вполне нормальная практика. Просто нужно именно управлять (ресурсами и с пониманием, что человек ресурс особенный, но тоже ресурс), а не пытаться властвовать, как у нас. И если засунуть свои менеджерские амбиции в топку главного своего подгорателя и там их сжечь (что для нашей национальной специфики управления явно задача из сложнейших), то выяснится, что модель-то, в принципе, очень даже рабочая. И она заметно эффективнее, чем управлять плёткой отфильтрованными от экспертов нубами и болванами.
Есть и менеджеры "Рок-Звезды"! Менеджеры, как и управляемые ими, могут быть классифицированы по той же схеме. Возможно у вас как раз такой случай.
Если к примеру стоит задача наи...освоить средства путем отличным от того, который принимается опытным сотрудником, то может случиться что и случается.
Доход компании не всегда зависит от производимого ей продукта, может и от декларируемого зависеть.
Поэтому "Кадры и решают все". Желаю всем хорошей компании.
В процитированной статье про менеджеров есть рецепт, что нужно делать с "рок-свёздами", а именно "создать вокруг команду, которая сможет эффективно функционировать в случае его ухода"
Это прежде всего необходимо и даже не для того, чтобы "смягчить ущерб" в случае ухода. А для того, чтобы команда, наконец-то подменяла звезду, помогала ему.
Пусть ту работу, которую он один делает за день - делают пять человек пять дней, но они должны её делать. Ошибка менеджера будет лишь тогда, когда он наблюдает рок-звезду и радуется, что экономит на персонале, продолжая нагружать того работой.
Рок-звёздам тоже нужно отдыхать, и одной из важнейших целей, которую должен достигнуть менеджер - это создать подмену ему, не важно, сколько человек на это потребуется. Это позволит отпустить рок-звезду в отпуск, не дать ему "выгореть". Позволить заняться ещё одним проектом или просто расти дальше, достигать новых высот.
Помимо возможности увольнения существует так называемый "фактор автобуса", который тоже никто не отменяет!
То есть, увольнение рок-звезды - это показатель бессилия менеджера, который слаб, настолько, что серьёзные проекты не потянет.
А может ему действительно не нужны серьёзные проекты, потому что его зарплата от этого особо не вырастет, а работы они ему добавят по самое не хочу.
Наверное, опытный и авторитетный специалист в подчинении не нравится менеджерам. Ведь они сами таким авторитетом не обладают.
Руководитель отвечает за стратегию управления, а авторитетный специалист за реализацию этой стратегии. Пока руководитель не лезет в реализацию, а специалист в стратегию все отлично работает и все на своих местах. Можно же другую статью написать про руководителей, которые лезут к специалистам со своим советами и представлением как нужно решать их задачи. Пока все решают свои задачи - все в порядке.
... менеджеров ставит на место, метко комментируя результаты их глупых инициатив, тимбилдингов и планёрок
Это уже проявление конфликта. Хорошо бы как-то различать конструктивную обратную связь. Если руководитель имеет глупые инициативы, то самое время обратить внимание на это HR специалистам (только профессионалам, а не как обычно решающим только два вопроса: найма и увольнения) как выстроить коммуникацию таким образом что бы опытный сотрудник приносил пользу компании: возможно организовать консультации с руководителем, помогать в решении управленческих вопросов или выделить его структуру в отдельный отдел или даже может быть в самостоятельную компанию.
... разбиение задач на маленькие части, которые может выполнить кто угодно.
В целом все эти истории выглядят примерно одинаково и суть их в каком-то переделе зоны ответственности. Компания как формирование стоит каких-то фантиков акций и стоимость их растет или падает. Исполнители вносят свой вклад, но имеют фиксированную оплату. А нет ли каких-то вариантов демократии где исполнители одновременно являются и инвесторами компании - владельцами акций. В таком случае ситуация с внезапным управленцем со стороны исключена. Полный владелец компании человек начинавший дело, а все последующие это процентные владельцы бизнеса. Мне кажется что-то в этой идее есть интересное...
Руководитель отвечает за стратегию управления, а авторитетный специалист за реализацию этой стратегии. Пока руководитель не лезет в реализацию, а специалист в стратегию все отлично работает и все на своих местах.
На бумаге это так и выглядит. Но, скажите пожалуйста, в чём именно заключается стратегия управления? И какова цель управления? Извлечение прибыли или программная реализация конечного продукта? По идее (как это представляется с моей крайне ограниченной точки зрения), профессиональный разработчик должен знать как и в каком виде должны реализовываться определённые проекты. У него должны быть готовые ответы и про структуру команды, и про строки, и должна быть в голове модель рисков (что будет, если урезать команду или сдвинуть сроки). Ибо профессионал владеет архитектурой. Выбор архитектуры определяет всё остальное. И если руководитель навязывает свою волю вопреки выбранной архитектура, то это проблема руководителя. Но разве стратегия не является производной от выбранной архитектуры? Вот и не понятно, что входит в эту самую стратегию. Можете ли Вы развернуто описать стратегию?
И какова цель управления?
Глобально - повышение финансовых результатов. Локально зависит от контекста, но все равно работает, пусть опосредовано, на глобальную цель.
Ибо профессионал владеет архитектурой. Выбор архитектуры определяет всё остальное. И если руководитель навязывает свою волю вопреки выбранной архитектура, то это проблема руководителя.
Архитектура - не самоцель. Руководителю глобально безразлична архитектура, потому что задача руководителя найти покупателя на то, что вы пишете. Поэтому у руководителя могут быть свои соображения, с непосредственно разработкой не связанные - руководителю нужно продать товар, выплатить вам зарплату за разработку товара, и оставить контору с прибылью.
В реально жизни, конечно, оно все далеко не бинарное, но разработчик и управленец решают разные задачи. Разработчик пишет, управленец низшего звена поддерживает жизнедеятельность разработчика, а топ-управленец продает написанное, чтобы было чем заплатить всем, включая в первую очередь разработчика. В мелких конторах это все на виду, потому что несколько человек сидят в одной комнате и делают пусть не совсем одно и то же, но хотя бы очевидные для каждого вещи. В конторах крупнее разделение труда глубже - так эффективнее.
опытный и авторитетный специалист в подчинении не нравится менеджерам
его с руками оторвёт любая компания конкурентовВзаимоисключающие параграфы? Или второе — это правило, а первое — исключение из него? Тогда о чём статья? О том, что бывают начальники-идиоты? Так ещё Пётр I указ издавал — "Подчиненный перед лицом начальствующим должен иметь вид лихой и придурковатый, дабы разумением своим не смущать начальство". В чём «научная новизна», так сказать? И зачем вообще уделять внимание исключениям?
Если же правило — это первое, то тогда вторая цитата попросту неверна и «рок-звезде» есть чего бояться.
Эгоцентричному менеджеруВся суть статьи, как и предполагалось. Всё остальное — банальная передвижка кроватей из одного пошлого анекдота. Так не надо работать у эгоцентричных менеджеров.
при капитализме ориентирована на получение максимальной прибыли, а не на то, чтобы делать хорошие делаВ огороде бузина, а в Киеве дядька. Чтобы фирме существовать, достаточно выходить в ноль. Прибыль для этого совершенно не нужна. Максимизация прибыли — это следствие того самого эгоцентризма, а вовсе не капитализма.
При мифическом же социализме (который мифичен именно потому, что для его достижения люди должны разом массово избавиться от эгоцентризма) этот самый эгоцентризм просто найдёт другую ФОРМУ для своей реализации. И называется эта форма «госкапитализм», который и имеет место быть во всех якобы коммунистических странах.
Так что кто-то совершает банальную логическую ошибку, путая причину со следствием. Если эгоцентризм приводит к капитализму и не может привести к социализму, это не значит, что капитализм будет приводить к эгоцентризму, а страна альтруистов не смогла бы быть капиталистической.
ЗЫ.
Что касается менеджеров вообще, то совершенно непонятно, почему их величают начальниками. По-мойму, это такие же работники, но выполняющие организационную работу, то есть другую работу, вот и всё. Более того, раз за разом можно наблюдать именно то, что описывается в статье, — как реальная власть переходит к профильным для данной фирмы специалистам — инженерам, программистам, технологам и т. д., в результате чего так называемый начальник вынужден слушать своих «подчинённых» и делать то, что они говорят. Так кто здесь власть?! Мы — здесь власть!!! (с) Мы — профильные специалисты — власть! А возвеличивание конкретно управленцев в ранг «начальника», их более высокий социальный статус, более высокие зарплаты — это совершенно порочная и извращённая практика, которая (в частности) и приводит к описываемому в статье явлению. Это всё пережитки пещерного, средневекового мышления — когда на верху социальной лестницы король-самодур, а учёные и инженеры у него в подчинении, когда если ты к 40 годам не перешёл в управленцы/бизнесмены, а продолжаешь инженерить «на дядю», то ты, типа, неудачник (даже само вот это понятие «на дядю» — средневековое). Пора бы в 21-ом веке от подобного архаизма уже избавляться. Нет никаких подчинённых специалистов, нет никакой работы «на дядю», даже если формально рабочий процесс так организован — есть только работа на благо науки, образования и человечества. А статусностью должен обладать профессионализм в своей области деятельности, а вовсе не переход в совершенно другую область (да ещё и явно менее научную) с целью занять якобы более статусное место в древней иерархии стаи бабуинов.
Проблема профильных специалистов в том, что они узкопрофильные, не обладают и не могут обладать общей картиной и поэтому не могут принимать общих решений. Но это не делает их «подчинёнными» и людьми второго сорта, ибо по-другому быть просто не может. Скорее наоборот — узкие, глубокие знания дорогого стоят. И только лишь поэтому требуется штат управленцев, всего лишь только поэтому! Это управленцы — придаток к профильным специалистам, а вовсе не наоборот. И именно IT-шники положат конец их «начальственному» паразитированию на инженерах — когда будет создана полностью автоматизированная система принятия решений, в которую будут стекаться данные ото всех узкопрофильных спецов. Эта система будет неподверженна эгоцентризму, самодурству, субъективизму и прочим человеческим порокам, а вся каста паразитов-«начальников» и «эффективных менеджеров» будет выкинута на мороз.
В общем, надо как можно лучше учить свою матчасть, и позиционировать себя именно так, а не пресмыкаться за зарплату. Только не надо путать это со звёздной болезнью, которая есть перегиб палки в другую сторону, и самодуром будете уже вы.
Так ещё Пётр I указ издавал — "Подчиненный перед лицом начальствующим должен иметь вид лихой и придурковатый, дабы разумением своим не смущать начальство".
Да ну.
"Более того, раз за разом можно наблюдать именно то, что описывается в статье, — как реальная власть переходит к профильным для данной фирмы специалистам — инженерам, программистам, технологам и т. д. "
Мне часто приходилось работать именно в таких организациях и лично мне это не нравилось. Никто ни за что не отвечал и в результате получалась своего рода тюремная культура "понятий". Менеджер уже не начальник и многие сотрудники становятся объектом чужих манипуляций. Поэтому я всегда предпочитаю чтобы надо мной был какой нибудь начальник который бы слушал только меня :)
Мне часто приходилось работать именно в таких организацияхНет, то, что вы описали, — это не такая организация. В процитированном вами отрывке описана самая обычная организация — именно с начальником, который за всё отвечает. Тем не менее, он вынужден делать то, что ему говорят подчинённые, т. к. реальная власть у тех, у кого знания. И именно этого вы и хотите, судя по вашему последнему предложению — чтобы вы были серым кардиналом, а ответственность лежала на другом. Но это явно как-то неправильно…
Никто ни за что не отвечал и в результате получалась своего рода тюремная культура «понятий». Менеджер уже не начальник и многие сотрудники становятся объектом чужих манипуляцийТак я же не предлагал вообще упразднить управление коллективом и превратить всё в анархию — я лишь предложил сделать это управление полностью автоматизированным, т. е. убрать из него человеческий фактор. Но эта система, конечно, будет слушать не только вас.
"убрать из него человеческий фактор. "
А как же манифест Agile ? : "Through this work we have come to value: Individuals and interactions over processes and tools. " :) И для кого все эти трейнинги по Emotiolanal Intelligence для членов команды? Ни для кого? На всякий случай? :)
Нет, по факту я вижу что именно это и происходит на первый взгляд. Но когда смотришь более внимательно - это не совсем так. Культуры компаний часто сегментированы и это очень похоже на тюремную культуру. Есть пацаны и есть паханы. Есть бродяги. Ну и так далее. Декларации на уровне того что у нас все демократично и решает "команда" по принципу scrum poker или retrospective или что то в этом роде - по факту является манипуляцией вот и все.
таким образом просто списывается долг перед сотрудником, так как дураку ясно что никто его не собирается погашать. я бы на месте оставшихся сотрудников задумался надо ли мне продолжать работу в такой компании...
давайте уволим Костю Кинчева из Алисы, а то он на себя все перетянул))) просто подумайте над этим)
с этим Риком (рок-звездой) просто не хотят делиться, пусть как хотят это обосновывают, но суть именно в этом. все премии манагерам, Рику - шиш с маслом.
Могу написать пособие для разработчика какие бывают менеджеры и как выжить его с работы ) вообщем-то искренне не понимаю зачем нужны чисто- менеджеры при современных доступных технологиях
Вот знаете, я как раз хочу быть чистым разработчиком, мозгов хватает, равно как и опыта. Но тем не менее, 80% времени занимают менеджерские задачи - потому что никто из разработчиков не хочет ими заниматься. От слова совсем.
Типичная проблема: сейчас у разработчика нет железа, на котором он может работать. Что будет делать разработчик? Ну менеджеры ведь не нужны, правильно? Железо ведь само собой появляется. И спека на него сама собой пишется, и на вопросы закуперов ответы тоже откуда-то сами собой возникают.
Как же достала, блин, эта вера в технологии... Джира есть, confluence - ура, работаем! А то, что в Jira надо задачи кому-то ставить, и убеждать людей, чтобы они в Confluence статьи про свои технологии писали - про это как-то не думает никто. Оно все как-то само делается, да.
Вот знаете, я как раз хочу быть чистым разработчиком, мозгов хватает,
равно как и опыта. Но тем не менее, 80% времени занимают менеджерские
задачи - потому что никто из разработчиков не хочет ими заниматься. От
слова совсем.
для этого давно придумали позицию - тимлид, вот он такими вещами и занимается 80% времени, а оставшиеся 20% программирует ))
Мне кажется статья очень поверхностно описывает суть явления "рок-звезды" в ИТ организации. С позиции не организации, где эта "звезда" может оказаться одним из 10000 записей в зарплатной ведомости, именно этого человека в роли эсперта.
Даже в такой отрасли, как командный спорт, потеря звезды может не являться проблемой для результатов команды и организации. Есть куча примеров, когда потеря звезды пошла на пользу, равно как и обратных. Есть примеры достижения спротивного успеха вообще без звезд (но редко, а часто на коротких турнирах). Но там звезды нужны, и работа с ними, в том числе расставание является частью процессов управления командой. Но даже в таком, казалось бы ориентированном на звезд бизнесе, звездой может оказаться тренер (интересно, кого-то смушает, что он уже не может бить по мячу?) или даже менеджер (что правда почти не интересно фанатам). Но если копнуть еще чуть-чуть, то окажется, что успешность клубов определяется не столько спортивными достижениями, а прибылью. Спортсмены вообще тотальные лузерв, если мерять не отдельными матчами, а турнирами. Победитель один, остальные проиграли и статистика очень сильно против каждого :)
Но вот быть прибыльным многие годы, наращивать фпнатскую базу и спонсорские контракты - эта невидимая и основная часть работы клуба. И она определяет общий его потенциал, так как в конечном итоге система превратит количество в качественный, пусть даже и единичный результат.
Тоже самое в ИТ. Только хуже. Разработка такая же маленькая, не, намного меньшая часть общих процессов компании. И локальная звездочка этого процесса - реально очень малая величина на фоне всего неба :)
Про остальное - тейлоризация: вы попробуйте реализовать на практике :)
Новые сотрудники дешевле, чем старые. Стажёры на испытательном сроке вообще работают практически бесплатно. Джуниоров кормят обещаниями. В первые годы они плохо понимают суть аферы и не умеют отстаивать свои права. Так что в идеале можно просто увольнять стажёров после испытательного срока и нанимать новых, что полностью совпадает с дегуманизирующими принципами тейлоризма (о нём см. ниже).
На моей практике все ровно наоборот. Работал в компании 3 года - получал в райное сотки (начинал с 35к), приходящие джуны (только с завода) со старта 75к получали (через полгода больше сотки). Часто бывает такое, что начальство преподносит переиндексацию как повышение ЗП и не особо понимающий разраб сидит на одной ЗП 3 года (да я лох), однако новые джуны приходят уже на рыночную ЗП.
Этому еще способствует то, что спрашивать у людей об их зарплате считается неприличным (что работодатель изо всех сил поддерживает), часто человек даже сам не понимает насколько он отстал от рынка по своим доходам. В общем надо просто держать нос по ветру и постоянно мониторить рынок труда, что-бы понимать в каком месте ты сейчас находишься, и не получилось как у вас что работаешь миддлом (в особо запущенных случаях синьором) с зарплатой джуна.
Ничего не меняется в этом мире.
Действительно - "Подчиненный перед лицом начальствующим должен иметь вид лихой и придурковатый, дабы разумением своим не смущать начальство"
Неоднократно видела в компании, когда опытные эксперты в компании не могут выполнять это правило, то они "вымываются" из компании. В компании все ниже и ниже компетенции у специалистов, но зато они "удобнее" в управлении.
Думаю, что ещё имеет место "ошибка выжившего". Я не встречал статей в духе "мы уволили нашего ключевого разработчика, и бизнес умер", или хотя бы "мы уволили нашего ключевого разработчика, и темп роста компании упал в 2 раза".
На ум приходит лишь одна история, когда компания осознала проблему и была вынуждена вернуть ключевого сотрудника. Это Apple.
Как только в вашей организации появляются центры проектного менеджмента, дирекции по цифровой трансформации и прочие "высокоуровневые" организаторы - бегите срочно из такой организации!
Вообще не понятно как было сформировано мнение автора, как будто не работал в компании ни разу. На таких людях обычно молятся, если он молча перерабатывает, берет кучу задач и вытаскивает команду. Если это не токсик(хотя это можно и простить за заслуги перед отечеством) то такой человек на вес золота.
Отдельный бред про стажёров и джунов. Если бы было всё так радужно, рынок завалился бы джуновскими вакансиями, но увы джуны бьются за место. На одну вакансию по 1000 откликов.
Вы общем статья только для развода холивара
лично я сама люблю менять место работы, если в конторе не занимаются тренингами и обучением персонала - эмоциональное выгорание привет
Так люблю вот эти все истории про суперменов, Бетменов и хакеров, которые за 30 секунд взламывают Пентагон.
А в реале читаешь новости: чемпиона мира по боям без правил, завалили два гопника в подъезде.
Во первых, я суперзвезд не видел. Видел чувак, которые 10 лет просидели в одной конторе, стояли у истоков той кучи гуано, созданием которой они руководили, и которая реально рухнет без них, потому что единственные знают, как эта куча работает и знают хаки, как их быстро чинить.
Видео сумасшедших, которые прибегают, орут, всё это хер ня надо переделать, за две недели фигачат мегатонны кода, который по итогу не работает, они кричат, вы не поняли моего гения и исчезают.
В реальном мире верить в суперменов тупо. Верить нужно в слаженные команды.
Все так. А специалисту-то что делать, когда он понимает, что его вот-вот сольют? Бодаться с менеджметом, молодым и проактивным? Сие есть занятие глупое.
А специалисту-то что делать, когда он понимает, что его вот-вот сольют?
Неполный список вариантов:
интересоваться вакансиями по своей или близкой специальности, ходить на собеседования
подумывать о собственном бизнесе, если таковое в принципе привлекает хотя бы гипотетически
подумывать о выходе на пенсию или о длительном отпуске
потому что типичный "отрицательный отбор" в тренде везде и повсеместно. потому что палевно быть на вторых ролях в схеме "я и мой брат дебил". потому что "мiр во зле", но это уже "совсем другая история", а кто не знает истории, обречён танцевать на граблях подобного //* как его там..*/ эффективного менеджмента - "тейлоризма", ибо глупость широким фронтом всегда стремится в идиократию
Почему увольняют самых опытных? Потому что они слишком умные. Тейлоризм 21-го века