Я уже лет 10 пишу код на питоне, и последние 2.5 года стабильно работал на американскую компанию. Наверно, многим знакома история, когда ты кодишь-кодишь, вроде всё неплохо, и внезапно ты - самый знающий и опытный в команде и добро пожаловать в тим лиды. Астрологи объявили неделю менеджмента, количество кода снизилось на 100%.
Мы уже собираем данные для исследования зарплат айтишников за второе полугодие 2020, а пока — продолжаем анализировать данные за первое, это последний срез. Сегодня рассказываем о том, сколько платили разработчикам в разных квалификациях и с разными языками.
Методология и выборка, как обычно, в концеЧитать полностью »
Обычно повышение зарплаты выглядит следующим образом. Способ №1, гуманитарный: сотрудник через год работы задумывается, что что-то пошло не так, и пора просить повышения. Дожидается своего локального максимума усилий, и на этой волне идёт к руководителю просить больше денег. С точки зрения теории игр это выглядит как «ну, я попросил, вдруг прокатит». Никаких доводов повышать оклад у руководителя нет.
Дальше сотрудник может поднять ставки. «Повышайте, а то уволюсь». В этой ситуации в проигрыше оказываются оба — руководитель теряет на времени обучении нового сотрудника и стоимости подбора. Сотрудник теряет на том, что может неожиданно уволиться.
Разработчики традиционно пользуются способом №2: сначала проходят где-то несколько собеседований, собирают офферы и приходят с ними к руководителю. «Смотри, вот тут мне предлагают на 20% больше, но мне у нас нравится, повышай на 15%, а то я перейду». Это уже предмет обсуждения. В банальном случае проще повысить и сохранить ценного сотрудника, но это обеспечит проигрыши в связанных играх. То есть создаст прецедент. Поэтому решение принимается (в упрощённой модели) с некоторой долей рандома.
У нас у многих математика в анамнезе. Рассматривая эту игру дальше, можно сделать простой вывод, что такой диалог для сотрудника всегда стрессовый, и он случается в момент после кризисного. То есть сначала человек беспокоится, потом делает потенциально невыгодные действия (проходит собеседования в других местах), потом приходит. Части надо повышать, части не надо. Следующий вопрос: можно ли найти функцию, которая обеспечит справедливую оценку? Будет ли эта функция снимать вот эти стрессовые ситуации?
Регулярная переиндексация каждый год — вариант такой функции. Условно, если в договоре прописано, что зарплата каждый год растёт на уровень инфляции — наверное, можно не беспокоиться. Но Вадим придумал более интересную фишку — привязать это к оценке полезности действий сотрудника для компании. Но как адекватный человек, без KPI.
Если мне не изменяет память, это второй перевод за почти 5-летнюю историю нашего блога. Нашего опыта с головой хватит на сотни статей. Но эта статья как никакая иллюстрирует разительные отличия между отношением к CRM-системам за рубежом и в России и в странах СНГ. Там — внедрение «снизу», активная работа малого и микро-бизнеса, интенсивный рост (и рулёжка в условиях кризиса) за счёт минимальной автоматизации, у нас принципы бизнеса каменного века: сесть на деньги и ждать, обнесёт кризис или таки жахнет по компании, паниковать и полагать, что все компании-автоматизаторы как минимум выходцы из КГБ, а CRM буквально морзянкой передаёт все тайны налоговой, КРУ и ОБЭПу. Но это не так! ИТ и существует для вашей эффективности, для прогресса, для управления информацией. Осталось это понять. В общем, давайте посмотрим, как у них.
Я прочитал немало статей о том, что удалёнка — это зло для разработчика. Что проседает продуктивность, потому что отвлекаешься на бытовуху. Что человек не может сосредоточиться, потому что жена на фоне варит борщ. Что нет живого общения с коллегами и не у кого спросить что-либо в нужный момент. И много-много других аргументов против. Часть этих статей и комментариев было написано до пандемии: кто-то писал из своего опыта разработчика, кто-то с точки зрения менеджера, владельца бизнеса или даже просто эйчара. Другая часть статей была написана во времена ковида.
Представьте себе, что вы директор маленькой средней школы, который ищет нового учителя. Поскольку у вас в штате менее 20 учителей, вы должны убедиться, что каждый человек, которого вы нанимаете, может преподавать во всех классах. Кроме того, вы недавно потеряли одного из своих лучших учителей, человека с 15-летним опытом и наставника для более молодых коллег. Как вы замените его? Вот тут-то и начинается занятное.
Всем привет.
Странная идея владения собственным станком для раскроя листового материала пришла мне в голову довольно давно - когда я оказался на производстве во г.Владимире. В то время, да и сейчас, я провожу большую часть времени в офисе, и конкретно для меня это объективно эффективнее с финансовой точки зрения. Вместе с тем, однажды увидев магию, которая превращает материал в полезные вещи, от такой мысли отделаться я уже не мог.
Я старый. При этом я в ладу с собой. Я не лежу ночью, беспокоясь о своей старости. Но прекрасно понимаю, что я определённо стар — по крайней мере в смысле программирования. Большинство непрограммистов посмеялись бы над мыслью о старости. Во многих сферах в середине пятого десятка лет означает, быть на вершине профессиональных навыков. Но в разработке программного обеспечения любой человек старше 40 часто рассматривается с некоторым подозрением. Люди старше 50 часто выпадают из пула резюме. Человеку за 60 хорошо иметь очень прочную стратегию выхода на пенсию. Но это статья не об определении «старости» или о предвзятости к старикам. Эта статья о том, что «более опытным» разработчикам часто труднее приспособиться к конкретной работе, задаче или среде.
Всем привет, это опять Дима Вдовин. В своей предыдущей статье об интеграции джунов в команду, я вскользь затрагивал тему парного программирования как эффективной практики обучения и передачи опыта. Теперь же я бы хотел более подробно поговорить о практиках парного программирования в командах. Различные их вариации я пробовал на разных проектах, и сегодня хотел бы просто поделиться, какие я вижу в этом плюсы, что дает этот подход.
Мне кажется, чтобы просто объяснить, как устроено парное программирование, можно привести в пример раллийные гонки. Там есть водитель (драйвер) и штурман (навигатор). Водитель сосредоточен непосредственно на управлении автомобилем. Штурман же контролирует на каком участке мы сейчас едем, и подсказывает пилоту о предстоящих поворотах и трамплинах.
Так же и в парном программировании.
Читать полностью »
Всё сказанное в тексте является сугубо моим личным мнением (так, на всякий случай уточняю).
Есть на свете такие штуки – называются франчи 1С. Это партнеры фирмы 1С, которые продают её программные продукты, помогают их внедрять и эксплуатировать, и умеют дорабатывать под нужды заказчика. Так вот, эти франчи пережили за несколько лет довольно забавную трансформацию.
Раньше как было. Возникла у клиента задача – он звонил во франч, к нему выезжал программист, разбирался, решал задачу. Либо на месте, либо забирал с собой и возвращался с решением через несколько дней.
Сейчас такого почти не бывает. В большинстве случаев придётся поработать с тремя забавными персонажами – пузырём, соломинкой и лаптем. Консультантом, аналитиком и разработчиком.
Читать полностью »
