Например, ему понравился какой-то наш проект, технология или подходы к работе.
Вопрос: а как вы отличаете, что человеку понравился Ваш проект от того, что человек говорит, что понравился проект, чтобы расположить к себе интервьювера?
Одна из картинок, которая уже показывает, почему автор говорит именно про такое распределение зарплат.
А потому, например, я бы ожидал заголовка "особенности найма в российском IT" или "неявные причины разных зарплат в IT", но не "Тримодальное распределение зарплат".
С другой стороны, статья довольно любопытная, и, в целом, довольно хорошая, хоть и немного сумбурная.
Дают процент выше всех остальных, учат за свой счет на дилерских курсах...
А что это значит? Какой получается оклад за стандартный рабочий месяц, где в неделю работают 40 часов, если без хитрых подходов в виде МРОТ+премия и так далее?
Причем позицию Лида тебе не предлагают по большему счету, в основном ты идешь на понижение грейда работать сеньором
Это логично. Тим лид - это одна из самых сложных позиций в АйТи с точки зрения трудоустройства, так как:
Немало крупных компаний предпочитают повышать своих нежели брать со стороны, так как такой человек уже знает внутреннюю кухню фирмы.
К сожалению, крайне часто приходят тимлиды, которые стали таковыми из мидлов, которые долго работали в команде, откуда другие люди уходили на более высокие оклады (почему же их повыслили? см. предыдущий пункт). А далее их технический уровень еще снизился по понятным причинам.
По сравнению с чистыми управленцами, у тимлидов, зачастую, нет понятия бюджета, так что они не могут сразу претендовать на должность выше (другими словами - запросто будут собеседовать на позицию тимлида, а вот тимлида редко будут сразу собеседовать на позицию менеджера).
Зачастую тимлид претендует на более высокий оклад в фирме, где он работает, а потому становится намного сложнее сменить должность, что усугубляет пункты 2 и 3.
Ряд рекрутеров считает, что нанять мидла/синьора на позицию тимлида дешевле, чем нанять бывшего тимлида, ибо см. пункт "4".
Все пункты выше - не более, чем предвзятость, но она очень сильно усложняет смену работы для таких позиций.
Ну а если офис есть - чобы и не сгонять туда людей, ведь вОвЛЕчеННосТь ВыШЕ
По сути, это так, хотя мне самому этот факт очень не нравится. Если разные группы людей, и у них разная продуктивность, в зависимости от работы в офисе или дома.
Условно говоря, я думаю, можно выделить типажи в стиле:
Человек с большим стажем, но не особо горит работой. При случае будет готов отвлечься и отдохнуть, но без фанатизма.
Опытный сотрудник с идеальным контролем времени. Такой эффективен и дома, и в офисе, но дома способен сделать еще более качественную атмосферу.
Человек со стилем работы "с 9 до 17". При любом удобном случае постарается делать что-то помимо работы.
Классический экстраверт и душа компании. Умеет очень хорошо налаживать отношения в коллективе и между командами. Хорошо понимает язык тела, обладает высоким уровнем эмпатии.
Другие типажи (чтобы не строить комментарий на чем то, что будет похоже на ложную дихотомию).
Если так получилось, что в коллективе преобладают типажи, которые не очень эффективны дома, то компания вводит такую политику. Я еще подозреваю, что те, которые очень круты на удаленке, стоят дороже, потому что они могут работать и на иностранного заказчика.
в 25 лет требуется 2-3 года опыта, где его брать вопрос остаётся открытым
Возможно, люди основывают свои ожидания на не самых репрезентативных выборках. Например, я начал работать в 18 лет (я был на третьем курсе), так что к 25 годам у меня уже был определенный опыт (с перерывами).
Собственно, если в команде есть парочка таких же, то и ожидания будут под них, а не под рынок, как мне кажется.
В моем случае - https://github.com/Citi/gradle-helm-plugin . Создатель проекта перестал его поддерживать, а потому самая последняя версия ссылалась на уязвимые библиотеки.
Мне говорят “можем только 450, нам тут налогов за тебя надо заплатить еще”?
Я думаю, что постепенно будет как в западных странах: сообщать будут gross, а люди сами будут считать налог (он же будет разный - чем выше ставка, тем выгоднее следить за вычетами).
Ну а фирма знает, сколько заплатит за год, а потому может посчитать эффективную ставку (например, будет 15.63%), так что каждый месяц будут отчислять именно эту долю от дохода (а не 13%). Если пришла премия, то пересчитают на лету. Если у человека есть дополнительные вычеты или доходы, то в конце года это сам человек покажет в декларации.
Я работал в небольших компаниях. Да, там такое возможно, но не более того. Условно 100+ человек - и это почти исключено.
Увы, это не так, если говорить про крупные фирмы. Любой проект начинается с теории, можно ли вообще такое сделать, а здесь необходим специалист.
Ваш комментарий совершенно очевидно говорит о том, что для вас проект начинается с ТЗ, хотя в реальности уме предшествует куча шагов.
Как Вы будете определять бюджет без понимания того, что требуется сделать, а также опознавания того, что можно сделать?
Я принимаю участие практически во всех этапах, которые указал.
Возможно, Вы не видите себя со стороны. Вы говорите, что Вы принимаете участие в этапах, которые Вы перечислил, не более чем.
Чесно говоря, мнение отдельного разработчика про самодура начальника вообще не релевантно.
И это частный случай для вашей компании, опять-таки. Далее Вы опять приводите примеры частных случаев того, как заведено у Вас. И да, вполне возможно, что есть и другие фирмы, в которых есть подобный же подход.
Вот только Ваш частный случай уже мало релевантен в компаниях, которые разрабатывают продукт для себя (или которые предоставляют сервис), так как их успех очень чувствителен к уровню разработчиков, которых нельзя вот так просто игнорировать.
Насколько я понимаю, у Вас в компании такого нет (судя по Вашим словам), а потому метод "я начальник - ты дурак" прекрасно работает.
Если взять реалии той же Британии (как частный случай), то выпускнику университета запросто будут платить £120.000 в год, плюс увеличьте эту сумму вдвое (чтобы учесть налоги и прочие косвенные затраты). Из-за высокой стоимости специалистов, компаниям становится очень дорого менять сотрудников. Как следствие из этого, армейский метод просто приводит к тому, что фирме не получается нанять людей, а далее она освобождает рынок.
Если Вы ошиблись и наняли не того человека, которого хотели (потому что Вы не сделали свою культуру более явной), то Вы потеряете около полугода, так как громадное число контрактов требуют уведомление об увольнении за три месяца, так что сначала Вы будете ждать не того человека, потом, поняв, что сотрудника требуется менять, Вы потеряете несколько месяцев на собеседования и еще три месяца на ожидание.
Подобная же проблема сейчас и в России (разве что в мягком виде): очень легко нанять стажеров, а потому к ним можно относиться и по-хамски, и с помощью армейского метода, тогда как квалифицированных специалистов нанимать долго и дорого.
А потому, вывод, если фирме нужны серьезные специалисты, то крайне рекомендуется следовать советам из статьи. Если же достаточно недорогих студентов, то действительно, управленцу не будет никакого смысла как-то там заморачиваться.
Потому что я точно знаю, что там разработчики не участвуют :)
Повторюсь - это в вашем частном случае.
Вы не видите картины, которую видит начальник, и поэтому не знаете, почему он принимает те, или иные решения
И Вы пока не смогли этого вообще доказать.
ОК, опишите этапы разработки в продуктовой компании :)
Вы же понимаете, что это зависит от компании и от её культуры? Для мелкого проекта и небольшой фирмы будут "ТЗ --> реализация --> доработка", для крупной фирмы и внутреннего проекта будет иной подход. В целом, в большинстве случаев, парадигма будет или в стиле водопада, или в стиле гибкой разработки, или в некоем гибриде, но так останется только на бумаге для инвесторов, так как реалии будут разными.
Но в чем смысл вопроса, если корректно получится показать только частный случай?
Я точно знаю, что вижу на порядок больше, чем рядовой разраб, и точно меньше, чем к примеру delivery director.
Но Вы пока не можете доказать или показать это, собственно, это только Ваши слова. На данном этапе Вы пока не можете даже обосновать, почему у Вас возникли сложности с регламентом поведения людей на переговорах, так что пока рано говорить о более серьезных вопросах.
но повторюсь разработчиков там нет.
Если разработчиков там нет, то это просто полностью отменяет Ваш аргумент под статьей, которая рассматривает разработку.
В чем смысл тогда был давать его?
Все просто.
Нет, не просто. На данном этапе:
Вы признались, что разработчики не принимают участия в тех процессах, на которые Вы жалуетесь, что приводит к следствию, что Ваш изначальный комментарий не относится к разработке в частности, а потому он не релевантнен со статьей.
Вы несколько раз повторили, что Вы никто не спрашивает вообще мнения разработчиков (откуда, правда, оно появилось, если их там нет).
Вы делаете вид, что занимаете высокий пост и много знаете о чем-то, но Вы даже не смогли составить регламент для переговоров.
Вы сначала жаловались на проблемы, а потом начали их отрицать. Вы сначала жаловались на разработчиков, а потом сказали, что они не принимают участия в вашей деятельности. Вы сначала говорите, что люди действуют некорректно, но сами Вы попытались перейти на хамство.
А потому, абсолютно непонятно, как Вы решали проблемы, которые Вы изложили, и почему метод автора Вы считаете некорректным (и какой тогда более корректный?).
Дело в том, что если эти этапы не видны разработчику, то "суслик это этого никуда не пропал".
Почему Вы так считаете? Пока что это Ваше предположение, которое будет, возможно, правдивым, когда в проекте только стажеры.
И что более важно, начальник то, в отличии от разработчика в курсе и принимает участие и это влияет на то, что он делает.
Я не понял этой фразы. Из неё следует, что разработчик не влияет на то, что он делает, ну то есть у Вас будто бы ChatGPT вместо специалиста.
Можете рассмотреть другой, но там этапов будет не меньше, я вас могу уверить :)
Нет, Вы ошибаетесь еще раз. Это Ваш частный случай для разработки на заказ (то есть Вы сразу игнорируете условный фриланс и аутсорс), а это частный случай разработки в целом, тогда как основная масса продуктов выпускается именно своими разработчиками для компании.
Не обижайтесь, но я думаю, те кто видят и телегу, и лошадь, и дорогу иметь большее право судить об этом, чем те, кто видят пол-лошади
Я правильно понимаю, что Вы считаете, что Вы единственный, которые всё это видит? Это уже близко к хамству, если честно.
Я вам указал этапы, как вы сами можете видеть, что разработчик не может иметь эксперного мнения в большинстве из них
Нет. Вы указали очень редкий случай разработки, а также Вы указали те этапы, которые Вы видите, которые Вы понимаете, и указали их так, как Вам удобно, не более чем. А далее, на основе крайне субъективного и недоказанного мнения, Вы сделали вывод о том, что сотрудник А знает меньше, чем сотрудник Б (так как Вы причисляете себя к сотруднику Б).
Лично я пока вижу совсем другое. Ниже будет моё субъективное мнение как руководителя, но я покажу ход рассуждений, которым я пользуюсь.
Вы занимаетесь определенной задачей (как я понимаю, вы продаете проект заказчику). Как часть этой задачи, Вы организовываете совещания. Вы не являетесь формальным экспертом в проекте, а потому довольно часто Вам приходится приглашать специалистов, чтобы они дали свою оценку.
Специалисты не общаются с клиентами так часто, как Вы. Как следствие, они могут действовать неэффективно с вашей субъективной точки зрения. Более того, Вы в принципе считаете, что разработчики не влияют на процесс, не понимают картину в целом и так далее.
На основе этого, вы вводите армейский стиль управления "я начальник - ты дурак", что неявно подтверждается вашими выводами выше.
Вместо этого, если бы Вы следовали рекомендациям @botyaslonim, Вам пришлось бы сделать вот такую вещь:
Определить, что конкретно Вам необходимо от специалистов на созвонах. Определить внутренние правила и регламенты.
На основе этого частного случая Вы могли бы выбрать более общую политику компании, которая была бы в стиле "мы действуем как единый коллектив, индивидуальные мнения (особенно аргументированные) запрещены при общении с заказчиком, приоритет компании на продажах, а не в стремлении к идеалу".
Ну а далее Вы просто-напросто могли бы требовать от сотрудников или согласия с политикой компании, или смены работы. И у Вас вообще не было бы никаких споров и жалоб, просто те люди, которые не согласны с такой политикой, выбирали бы другую фирму. Вам это стоит сделать всего лишь один раз, а далее этот вопрос бы ушёл бы практически полностью.
Почему Вы так не сделали? Что мешает Вам сделать регламент и политику, которая бы распространялась на коллектив?
Отвечу на этот момент. Это очень частый случай и вот почему :)
Нет, Вы не правы в контексте этой статьи (и сайта), так как очень малая доля именно сотрудников в IT имеют к этому отношение. И это очень важно: мы говорим не про мир в целом, мы не берем в расчет другие отрасли, мы именно говорим об IT и о разработке. Вот даже цитата из статьи:
Во-вторых, оценка многих руководителей на рынке труда стала трагично расходиться с их реальными достижениями. В IT в этом отчасти виновата стартап-культура, та самая культура, благодаря которой мы в IT добились огромного развития и выпуска невероятного количества самых разных продуктов.
Мы не рассматриваем все профессии мире в целом, мы именно говорим об этой теме. Более того, даже если условный бухгалтер работает в АйТи компании, это не делает его резко частью АйТи, по аналогию, если программист работает в банке, это не делает человек экономистом/банкиром.
Более того, давайте рассмотрим вот этот пункт:
Проект, к примеру по написанию ПО на заказ делится на приблизительные этапы:
Это не просто пример, это частный случай определенной разработки на заказ (от которой, в целом, отказываются: основная масса разработчиков работают или в компании напрямую, или через аутсорс, когда общение идет именно между специалистами двух фирм, но даже аутсорс очень плохо работает для хоть сколько-нибудь серьезных проектов).
Как следствие, вот эта фраза становится тоже интересной:
Поэтому ... скажем так, мнение людей, которые занимают позиция разработчика очень "ценно" :)
так как Вы говорите, что, в Вашем очень частном случае людей абсолютно не интересует мнение разработчика. И да, действительно, такое тоже бывает, вот только, в большинстве своем, квалифицированные специалисты не будут работать там, где не получается применять свою квалификацию, так как там просто платят мало (а кто будет платить за ненужную квалификацию?).
Далее Вы опять ошибаетесь:
И это важный момент. разработка в ИТ - эта лишь малая часть.
Вы перепутали и ставите телегу впереди лошади. Разработка в АйТи - это основное. В зависимости от того, что могут сделать специалисты, Вы будете делать тендер, от этого будет зависеть цена и прочие вещи, если же отсутствуют определенные нерыночные/коррупционные отношения.
Собственно, получается, что эта статья не покрывает Ваш частный случай, не более чем.
Нет, этот аргумент не прокатит, как как Ваша позиция строится именно на том обобщении. Более того, вот эта фраза не является корректным обоснованием:
И я вам скажу, позиций/должностей, которые имеют такую ситуацию до фига
, так как речь идет не о числе позиций/должностей, а о том, насколько частые в разработке/АйТи Ваш случай. Например, какая доля разработчиков Яндекс, ТАТА или Голдман Сакс вообще присутствуют на таких встречах? Ответ - очень малая доля пересекается с внешним заказчиком в таком режиме, как у Вас.
А потому, Ваш аргумент схож с "вот я работаю юристом и хожу в суды постоянно, а разработчики не понимают процессуальных тонкостей", ибо это редкое событие. А следовательно, корректным ответом будет "раз для других людей это редкость, то разумнее провести инструктаж, а если эта ситуация повторяется, то можно сделать документ/обучалку для сотрудников".
И вот это самый главный вывод, так как если мы подходим к формализации хотя бы части процессов, то мы и начинаем вводить культуру в коллективе. То есть это будет не продавец-самодур, который требует жесткого подчинения, а именно часть культуры компании, где будет определены роли в публичных продажах.
Как следствие, Ваша жалоба уйдет целиком, да еще и не только для Вас конкретно, но и для всей фирмы сразу.
Суть в том, что вы путаете внутренние встречи, где в целом такого нет, но и полноценными встречами их сложно назвать, с внешними
О том и речь. За мои 15 лет опыта, такие встречи были ровно два раза. В первом случае была маленькая фирма, говорил директор (а не тимлид, конечно же), он же все проинструктировал, раздал роли (мы все делали вид, что работаем только над одним проектом и так далее).
Во втором случае было очень неформальное общение, подготовки было мало, но народ понимал важность встречи.
Но, что самое важное: в случае громадного числа разработчиков, такие встречи очень редки, а потому нельзя использовать их вообще как пример, так как от организатора таких встреч требуется жестко проговаривать, кто и что говорит, а также репетировать, если планируется много обманывать (хотя лично я постараюсь уйти из такого коллектива).
Просто обычно разработчики на другие почти не ходят, но это как в известном фильме "про суслика" ... поэтому тут вопрос бэкграунда и понимания, что кто-то "не видит суслика, а он есть", а кто-то видит по 10 раз в день
Нет, я здесь просто Ваш пример не засчитаю вообще, так как он радикально редкий (это во-первых), а также потому, что Вы уже начали себе противоречить: ведь если специалист А (продажи) не знает про суслика, то разумно предположить, что и специалист Б не знает про суслика (технические вопросы), но Вы опустили эту часть. Более того, если специалист А уже знает о подводных камнях (переговоры), то ожидается, что он расскажет о деталях заранее, а не будет просто накручивать себе цену.
А потому, вот этот абзац пока просто является еще одним свидетельством пользы статьи:
Ну или банальное правило на совещании не открывать рот, если на нем присутствует твой руководитель, кроме случая когда он сам попросит прокоментировать конкретный вопрос. Дискриминация? Да нет, нормальный паттерн.
Ну ибо он имеет только тогда смысл, когда присутствуют внешние заказчики, когда управленец ведет разговор о деталях, в которых он не разбирается, за спиной специалистов, но от тех требуется беспрекословного согласия и так далее, что, по сути, и является армейским методом управления "я начальник - ты дурак".
Поэтому давайте счанала определимся, вы что имеете (какую встречу) в виду
Я же написал не вообще "не открывать рот", а не открывать рот пока не скажут.
Кстати, это отличный пример, почему эта статья очень корректная и правильная.
Как так получилось, что подчиненный "открывает рот" (с точки зрения управленца)?
У меня пока следующие варианты:
Низкая квалификация в команде, а потому люди просто не умеют слушать других. Как следствие, и управленец, и подчиненный делают очевидные ошибки: один не понимает ритуалов так, как их понимает управленец, а другой не понимает, что до подчиненных необходимо всегда доносить требования и ожидания.
Подчиненный играет против компании (другими словами - саботаж), но управленец, почему-то, пока это игнорирует.
Управленец занимается саботажем (намеренно вводит людей в заблуждение), а подчиненный думает, что тот слегка заблуждается.
Тема недостаточно проработана с точки зрения организатора (нет целей, нет человека, который бы собрал цели, не собраны ограничения, не подготовлена необходимая бюрократия и так далее), но об этом все молчат (недостаток опыта или запрет на критику).
Все всё уже решили, но почему-то требуется формальная галочка от специалиста, но самого специалиста вовремя не спросили, так как все понимают, что специалист возразит (это отличается от саботажа выше, так как саботаж был бы намеренным, здесь же, скорее, люди занимались темой, которая за рамками их полномочий). Как следствие, согласие просят дать быстро-быстро, не особо раздумывая.
Это очень редкая формальная встреча (например, суд), но управленец забыл проинструктировать подчиненного, который недостаточно опытен, чтобы знать делали самому (другими словами - это настолько редкий случай, что он не имеет отношения к большинству людей).
Возможно я, конечно же, что-то забыл, но, чаще всего, встречаются именно пункты из перечня выше.
Другими словами, если поиграть в рекурсивную игру "зачем это требуется", то ответом, скорее всего, будет ошибка в руководстве, которая не была решена только потому, что руководству нельзя докладывать об их ошибках.
Возможно, это следствие какой-нибудь ошибки в дизайне приложения, в стиле «мы используем ‘select * from …’, а поля присваиваем по индексу ради производительности».
Не думаю, что эти if'ы лишние, так как, ну как мне кажется, values должно прийти извне, ну или иначе лучше сразу использовать значение из первого элемента.
В Stream могут быть nullы, но Optional прячет это.
Почему jacoco считает их покрытыми - большой вопрос :)
Нет, с этим всё просто. В коде a.b() мы проверяем, что b() было вызвано (то есть будет физический вызов функции), а в коде a::b мы проверяем, что мы получили указатель на функцию. И Jacoco честно говорит, что указатель был получен.
final var values = List.of(50, 100, 150);
if(values.isEmpty()) {
return
}
final var firstElement = valies.get(0);
if(firstElement == null) {
return;
}
final var topCity = TopCitiesCount.findByValue(firstElement);
if(topCity == null) {
return;
}
final var location = topCity.getTopCityLocation();
if(location == null) {
return
}
final var currentCondition = location.getCurrentConditionByLocation();
if(currentCondition == null) {
return;
}
eventService.sendEvent(currentCondition);
Это очень многословно, но, что самое интересно, на анализе покрытия тестами большинство условий будет подсвечено желтым, так как Вы проверяете только одну часть условия, но не вторую. Например, нет проверки того, что нам хоть когда-то не надо отправлять событие.
Более того, вот этот код покажет 100% покрытия если просто его вызвать:
Тогда как мой код выше будет весь "красным". И это важный момент, который я хотел подсветить: .ifPresent(eventService::sendEvent) отмечается как "вызванный" вне зависимости того, вызывали ли Вы sendEvent или нет, так как здесь мы просто передаем ссылку на функцию (а она передается всегда).
Если честно, я не знаю, как исправлять эту ситуацию в Java, так как это приведет к диссертации в каждом классе (по объему). В Kotlin, например, код был бы таким:
val values = listOf(50, 100, 150);
val condition = values
.firstOrNull()
?.findByValue()
?.topCityLocation
?.currentConditionByLocation
if(condition != null) {
eventService.sendEvent(condition)
}
Судя по этому рейтингу, Cobol находится на одном уровне с Kotlin (который используется едва ли не в большинстве всех Android приложений, который является рекомендованным по-умолчанию для Gradle, и который входит (вместе с Java) в список языков, которые используются в документации Spring.
Собственно, есть подозрение, что этот рейтинг очень плохо отражает реальность...
Вопрос: а как вы отличаете, что человеку понравился Ваш проект от того, что человек говорит, что понравился проект, чтобы расположить к себе интервьювера?
У меня есть хоть какие-то статьи на хабре, но я поддержу @alelam.
Когда мы говорим про х-модальное распределение зарплат, ожидается, что будет показана определенная статистика, выкладки, погрешность и так далее.
Например, в этой статье человек описывает такой рынок в Нидерладах - в статье очень мало отступлений, ссылок на ютуб и пр., но зато есть цифры, есть ссылки на источники данных и так далее хоть в каком-то виде.
Одна из картинок, которая уже показывает, почему автор говорит именно про такое распределение зарплат.
А потому, например, я бы ожидал заголовка "особенности найма в российском IT" или "неявные причины разных зарплат в IT", но не "Тримодальное распределение зарплат".
С другой стороны, статья довольно любопытная, и, в целом, довольно хорошая, хоть и немного сумбурная.
А что это значит? Какой получается оклад за стандартный рабочий месяц, где в неделю работают 40 часов, если без хитрых подходов в виде МРОТ+премия и так далее?
Это логично. Тим лид - это одна из самых сложных позиций в АйТи с точки зрения трудоустройства, так как:
Немало крупных компаний предпочитают повышать своих нежели брать со стороны, так как такой человек уже знает внутреннюю кухню фирмы.
К сожалению, крайне часто приходят тимлиды, которые стали таковыми из мидлов, которые долго работали в команде, откуда другие люди уходили на более высокие оклады (почему же их повыслили? см. предыдущий пункт). А далее их технический уровень еще снизился по понятным причинам.
По сравнению с чистыми управленцами, у тимлидов, зачастую, нет понятия бюджета, так что они не могут сразу претендовать на должность выше (другими словами - запросто будут собеседовать на позицию тимлида, а вот тимлида редко будут сразу собеседовать на позицию менеджера).
Зачастую тимлид претендует на более высокий оклад в фирме, где он работает, а потому становится намного сложнее сменить должность, что усугубляет пункты 2 и 3.
Ряд рекрутеров считает, что нанять мидла/синьора на позицию тимлида дешевле, чем нанять бывшего тимлида, ибо см. пункт "4".
Все пункты выше - не более, чем предвзятость, но она очень сильно усложняет смену работы для таких позиций.
По сути, это так, хотя мне самому этот факт очень не нравится. Если разные группы людей, и у них разная продуктивность, в зависимости от работы в офисе или дома.
Условно говоря, я думаю, можно выделить типажи в стиле:
Человек с большим стажем, но не особо горит работой. При случае будет готов отвлечься и отдохнуть, но без фанатизма.
Опытный сотрудник с идеальным контролем времени. Такой эффективен и дома, и в офисе, но дома способен сделать еще более качественную атмосферу.
Человек со стилем работы "с 9 до 17". При любом удобном случае постарается делать что-то помимо работы.
Классический экстраверт и душа компании. Умеет очень хорошо налаживать отношения в коллективе и между командами. Хорошо понимает язык тела, обладает высоким уровнем эмпатии.
Другие типажи (чтобы не строить комментарий на чем то, что будет похоже на ложную дихотомию).
Если так получилось, что в коллективе преобладают типажи, которые не очень эффективны дома, то компания вводит такую политику. Я еще подозреваю, что те, которые очень круты на удаленке, стоят дороже, потому что они могут работать и на иностранного заказчика.
Возможно, люди основывают свои ожидания на не самых репрезентативных выборках. Например, я начал работать в 18 лет (я был на третьем курсе), так что к 25 годам у меня уже был определенный опыт (с перерывами).
Собственно, если в команде есть парочка таких же, то и ожидания будут под них, а не под рынок, как мне кажется.
В моем случае - https://github.com/Citi/gradle-helm-plugin . Создатель проекта перестал его поддерживать, а потому самая последняя версия ссылалась на уязвимые библиотеки.
Я думаю, что постепенно будет как в западных странах: сообщать будут gross, а люди сами будут считать налог (он же будет разный - чем выше ставка, тем выгоднее следить за вычетами).
Ну а фирма знает, сколько заплатит за год, а потому может посчитать эффективную ставку (например, будет 15.63%), так что каждый месяц будут отчислять именно эту долю от дохода (а не 13%). Если пришла премия, то пересчитают на лету. Если у человека есть дополнительные вычеты или доходы, то в конце года это сам человек покажет в декларации.
Увы, это не так, если говорить про крупные фирмы. Любой проект начинается с теории, можно ли вообще такое сделать, а здесь необходим специалист.
Как Вы будете определять бюджет без понимания того, что требуется сделать, а также опознавания того, что можно сделать?
Возможно, Вы не видите себя со стороны. Вы говорите, что Вы принимаете участие в этапах, которые Вы перечислил, не более чем.
И это частный случай для вашей компании, опять-таки. Далее Вы опять приводите примеры частных случаев того, как заведено у Вас. И да, вполне возможно, что есть и другие фирмы, в которых есть подобный же подход.
Вот только Ваш частный случай уже мало релевантен в компаниях, которые разрабатывают продукт для себя (или которые предоставляют сервис), так как их успех очень чувствителен к уровню разработчиков, которых нельзя вот так просто игнорировать.
Насколько я понимаю, у Вас в компании такого нет (судя по Вашим словам), а потому метод "я начальник - ты дурак" прекрасно работает.
Если взять реалии той же Британии (как частный случай), то выпускнику университета запросто будут платить £120.000 в год, плюс увеличьте эту сумму вдвое (чтобы учесть налоги и прочие косвенные затраты). Из-за высокой стоимости специалистов, компаниям становится очень дорого менять сотрудников. Как следствие из этого, армейский метод просто приводит к тому, что фирме не получается нанять людей, а далее она освобождает рынок.
Если Вы ошиблись и наняли не того человека, которого хотели (потому что Вы не сделали свою культуру более явной), то Вы потеряете около полугода, так как громадное число контрактов требуют уведомление об увольнении за три месяца, так что сначала Вы будете ждать не того человека, потом, поняв, что сотрудника требуется менять, Вы потеряете несколько месяцев на собеседования и еще три месяца на ожидание.
Подобная же проблема сейчас и в России (разве что в мягком виде): очень легко нанять стажеров, а потому к ним можно относиться и по-хамски, и с помощью армейского метода, тогда как квалифицированных специалистов нанимать долго и дорого.
А потому, вывод, если фирме нужны серьезные специалисты, то крайне рекомендуется следовать советам из статьи. Если же достаточно недорогих студентов, то действительно, управленцу не будет никакого смысла как-то там заморачиваться.
Повторюсь - это в вашем частном случае.
И Вы пока не смогли этого вообще доказать.
Вы же понимаете, что это зависит от компании и от её культуры? Для мелкого проекта и небольшой фирмы будут "ТЗ --> реализация --> доработка", для крупной фирмы и внутреннего проекта будет иной подход. В целом, в большинстве случаев, парадигма будет или в стиле водопада, или в стиле гибкой разработки, или в некоем гибриде, но так останется только на бумаге для инвесторов, так как реалии будут разными.
Но в чем смысл вопроса, если корректно получится показать только частный случай?
Но Вы пока не можете доказать или показать это, собственно, это только Ваши слова. На данном этапе Вы пока не можете даже обосновать, почему у Вас возникли сложности с регламентом поведения людей на переговорах, так что пока рано говорить о более серьезных вопросах.
Если разработчиков там нет, то это просто полностью отменяет Ваш аргумент под статьей, которая рассматривает разработку.
В чем смысл тогда был давать его?
Нет, не просто. На данном этапе:
Вы признались, что разработчики не принимают участия в тех процессах, на которые Вы жалуетесь, что приводит к следствию, что Ваш изначальный комментарий не относится к разработке в частности, а потому он не релевантнен со статьей.
Вы несколько раз повторили, что Вы никто не спрашивает вообще мнения разработчиков (откуда, правда, оно появилось, если их там нет).
Вы делаете вид, что занимаете высокий пост и много знаете о чем-то, но Вы даже не смогли составить регламент для переговоров.
Вы сначала жаловались на проблемы, а потом начали их отрицать. Вы сначала жаловались на разработчиков, а потом сказали, что они не принимают участия в вашей деятельности. Вы сначала говорите, что люди действуют некорректно, но сами Вы попытались перейти на хамство.
А потому, абсолютно непонятно, как Вы решали проблемы, которые Вы изложили, и почему метод автора Вы считаете некорректным (и какой тогда более корректный?).
Почему Вы так считаете? Пока что это Ваше предположение, которое будет, возможно, правдивым, когда в проекте только стажеры.
Я не понял этой фразы. Из неё следует, что разработчик не влияет на то, что он делает, ну то есть у Вас будто бы ChatGPT вместо специалиста.
Нет, Вы ошибаетесь еще раз. Это Ваш частный случай для разработки на заказ (то есть Вы сразу игнорируете условный фриланс и аутсорс), а это частный случай разработки в целом, тогда как основная масса продуктов выпускается именно своими разработчиками для компании.
Я правильно понимаю, что Вы считаете, что Вы единственный, которые всё это видит? Это уже близко к хамству, если честно.
Нет. Вы указали очень редкий случай разработки, а также Вы указали те этапы, которые Вы видите, которые Вы понимаете, и указали их так, как Вам удобно, не более чем. А далее, на основе крайне субъективного и недоказанного мнения, Вы сделали вывод о том, что сотрудник А знает меньше, чем сотрудник Б (так как Вы причисляете себя к сотруднику Б).
Лично я пока вижу совсем другое. Ниже будет моё субъективное мнение как руководителя, но я покажу ход рассуждений, которым я пользуюсь.
Вы занимаетесь определенной задачей (как я понимаю, вы продаете проект заказчику). Как часть этой задачи, Вы организовываете совещания. Вы не являетесь формальным экспертом в проекте, а потому довольно часто Вам приходится приглашать специалистов, чтобы они дали свою оценку.
Специалисты не общаются с клиентами так часто, как Вы. Как следствие, они могут действовать неэффективно с вашей субъективной точки зрения. Более того, Вы в принципе считаете, что разработчики не влияют на процесс, не понимают картину в целом и так далее.
На основе этого, вы вводите армейский стиль управления "я начальник - ты дурак", что неявно подтверждается вашими выводами выше.
Вместо этого, если бы Вы следовали рекомендациям @botyaslonim, Вам пришлось бы сделать вот такую вещь:
Определить, что конкретно Вам необходимо от специалистов на созвонах. Определить внутренние правила и регламенты.
На основе этого частного случая Вы могли бы выбрать более общую политику компании, которая была бы в стиле "мы действуем как единый коллектив, индивидуальные мнения (особенно аргументированные) запрещены при общении с заказчиком, приоритет компании на продажах, а не в стремлении к идеалу".
Ну а далее Вы просто-напросто могли бы требовать от сотрудников или согласия с политикой компании, или смены работы. И у Вас вообще не было бы никаких споров и жалоб, просто те люди, которые не согласны с такой политикой, выбирали бы другую фирму. Вам это стоит сделать всего лишь один раз, а далее этот вопрос бы ушёл бы практически полностью.
Почему Вы так не сделали? Что мешает Вам сделать регламент и политику, которая бы распространялась на коллектив?
Нет, Вы не правы в контексте этой статьи (и сайта), так как очень малая доля именно сотрудников в IT имеют к этому отношение. И это очень важно: мы говорим не про мир в целом, мы не берем в расчет другие отрасли, мы именно говорим об IT и о разработке. Вот даже цитата из статьи:
Мы не рассматриваем все профессии мире в целом, мы именно говорим об этой теме. Более того, даже если условный бухгалтер работает в АйТи компании, это не делает его резко частью АйТи, по аналогию, если программист работает в банке, это не делает человек экономистом/банкиром.
Более того, давайте рассмотрим вот этот пункт:
Это не просто пример, это частный случай определенной разработки на заказ (от которой, в целом, отказываются: основная масса разработчиков работают или в компании напрямую, или через аутсорс, когда общение идет именно между специалистами двух фирм, но даже аутсорс очень плохо работает для хоть сколько-нибудь серьезных проектов).
Как следствие, вот эта фраза становится тоже интересной:
так как Вы говорите, что, в Вашем очень частном случае людей абсолютно не интересует мнение разработчика. И да, действительно, такое тоже бывает, вот только, в большинстве своем, квалифицированные специалисты не будут работать там, где не получается применять свою квалификацию, так как там просто платят мало (а кто будет платить за ненужную квалификацию?).
Далее Вы опять ошибаетесь:
Вы перепутали и ставите телегу впереди лошади. Разработка в АйТи - это основное. В зависимости от того, что могут сделать специалисты, Вы будете делать тендер, от этого будет зависеть цена и прочие вещи, если же отсутствуют определенные нерыночные/коррупционные отношения.
Собственно, получается, что эта статья не покрывает Ваш частный случай, не более чем.
Нет, этот аргумент не прокатит, как как Ваша позиция строится именно на том обобщении. Более того, вот эта фраза не является корректным обоснованием:
, так как речь идет не о числе позиций/должностей, а о том, насколько частые в разработке/АйТи Ваш случай. Например, какая доля разработчиков Яндекс, ТАТА или Голдман Сакс вообще присутствуют на таких встречах? Ответ - очень малая доля пересекается с внешним заказчиком в таком режиме, как у Вас.
А потому, Ваш аргумент схож с "вот я работаю юристом и хожу в суды постоянно, а разработчики не понимают процессуальных тонкостей", ибо это редкое событие. А следовательно, корректным ответом будет "раз для других людей это редкость, то разумнее провести инструктаж, а если эта ситуация повторяется, то можно сделать документ/обучалку для сотрудников".
И вот это самый главный вывод, так как если мы подходим к формализации хотя бы части процессов, то мы и начинаем вводить культуру в коллективе. То есть это будет не продавец-самодур, который требует жесткого подчинения, а именно часть культуры компании, где будет определены роли в публичных продажах.
Как следствие, Ваша жалоба уйдет целиком, да еще и не только для Вас конкретно, но и для всей фирмы сразу.
О том и речь. За мои 15 лет опыта, такие встречи были ровно два раза. В первом случае была маленькая фирма, говорил директор (а не тимлид, конечно же), он же все проинструктировал, раздал роли (мы все делали вид, что работаем только над одним проектом и так далее).
Во втором случае было очень неформальное общение, подготовки было мало, но народ понимал важность встречи.
Но, что самое важное: в случае громадного числа разработчиков, такие встречи очень редки, а потому нельзя использовать их вообще как пример, так как от организатора таких встреч требуется жестко проговаривать, кто и что говорит, а также репетировать, если планируется много обманывать (хотя лично я постараюсь уйти из такого коллектива).
Нет, я здесь просто Ваш пример не засчитаю вообще, так как он радикально редкий (это во-первых), а также потому, что Вы уже начали себе противоречить: ведь если специалист А (продажи) не знает про суслика, то разумно предположить, что и специалист Б не знает про суслика (технические вопросы), но Вы опустили эту часть. Более того, если специалист А уже знает о подводных камнях (переговоры), то ожидается, что он расскажет о деталях заранее, а не будет просто накручивать себе цену.
А потому, вот этот абзац пока просто является еще одним свидетельством пользы статьи:
Ну ибо он имеет только тогда смысл, когда присутствуют внешние заказчики, когда управленец ведет разговор о деталях, в которых он не разбирается, за спиной специалистов, но от тех требуется беспрекословного согласия и так далее, что, по сути, и является армейским методом управления "я начальник - ты дурак".
Я отвечаю на Ваш комментарий выше.
Кстати, это отличный пример, почему эта статья очень корректная и правильная.
Как так получилось, что подчиненный "открывает рот" (с точки зрения управленца)?
У меня пока следующие варианты:
Низкая квалификация в команде, а потому люди просто не умеют слушать других. Как следствие, и управленец, и подчиненный делают очевидные ошибки: один не понимает ритуалов так, как их понимает управленец, а другой не понимает, что до подчиненных необходимо всегда доносить требования и ожидания.
Подчиненный играет против компании (другими словами - саботаж), но управленец, почему-то, пока это игнорирует.
Управленец занимается саботажем (намеренно вводит людей в заблуждение), а подчиненный думает, что тот слегка заблуждается.
Тема недостаточно проработана с точки зрения организатора (нет целей, нет человека, который бы собрал цели, не собраны ограничения, не подготовлена необходимая бюрократия и так далее), но об этом все молчат (недостаток опыта или запрет на критику).
Все всё уже решили, но почему-то требуется формальная галочка от специалиста, но самого специалиста вовремя не спросили, так как все понимают, что специалист возразит (это отличается от саботажа выше, так как саботаж был бы намеренным, здесь же, скорее, люди занимались темой, которая за рамками их полномочий). Как следствие, согласие просят дать быстро-быстро, не особо раздумывая.
Это очень редкая формальная встреча (например, суд), но управленец забыл проинструктировать подчиненного, который недостаточно опытен, чтобы знать делали самому (другими словами - это настолько редкий случай, что он не имеет отношения к большинству людей).
Возможно я, конечно же, что-то забыл, но, чаще всего, встречаются именно пункты из перечня выше.
Другими словами, если поиграть в рекурсивную игру "зачем это требуется", то ответом, скорее всего, будет ошибка в руководстве, которая не была решена только потому, что руководству нельзя докладывать об их ошибках.
Но я могу ошибаться, конечно же...
Возможно, это следствие какой-нибудь ошибки в дизайне приложения, в стиле «мы используем ‘select * from …’, а поля присваиваем по индексу ради производительности».
Не думаю, что эти if'ы лишние, так как, ну как мне кажется,
values
должно прийти извне, ну или иначе лучше сразу использовать значение из первого элемента.В
Stream
могут бытьnull
ы, ноOptional
прячет это.Нет, с этим всё просто. В коде
a.b()
мы проверяем, чтоb()
было вызвано (то есть будет физический вызов функции), а в кодеa::b
мы проверяем, что мы получили указатель на функцию. И Jacoco честно говорит, что указатель был получен.Очень хорошая статья, спасибо. Неявно, Вы подсветили важный недостаток Java Streams, а именно - они накручивают покрытие тестами.
Давайте попробуем переписать Ваш код ниже:
Без Stream'ов (и Optional'ов) будет что-то вроде:
Это очень многословно, но, что самое интересно, на анализе покрытия тестами большинство условий будет подсвечено желтым, так как Вы проверяете только одну часть условия, но не вторую. Например, нет проверки того, что нам хоть когда-то не надо отправлять событие.
Более того, вот этот код покажет 100% покрытия если просто его вызвать:
Тогда как мой код выше будет весь "красным". И это важный момент, который я хотел подсветить:
.ifPresent(eventService::sendEvent)
отмечается как "вызванный" вне зависимости того, вызывали ли ВыsendEvent
или нет, так как здесь мы просто передаем ссылку на функцию (а она передается всегда).Если честно, я не знаю, как исправлять эту ситуацию в Java, так как это приведет к диссертации в каждом классе (по объему). В Kotlin, например, код был бы таким:
или:
И вот тут уже отсутствие вызова
eventService.sendEvent(it)
будет четко показано в JaCoCo.Судя по этому рейтингу, Cobol находится на одном уровне с Kotlin (который используется едва ли не в большинстве всех Android приложений, который является рекомендованным по-умолчанию для Gradle, и который входит (вместе с Java) в список языков, которые используются в документации Spring.
Собственно, есть подозрение, что этот рейтинг очень плохо отражает реальность...
Вы специально пропустили глагол "читать", чтобы подчеркнуть, что писать write only код очень легко? :)