Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка

Я больше года занимаюсь разработкой в Crossover (Chief Software Architect, $100k в год) и могу сказать, что работать тут очень непросто. Но сложности совершенно не те, на которые вы указываете. В основном конечно приходят люди инициативные, которые хотят больше, чем спокойно поработать или посидеть на больничном, и кстати в России таких на удивление немало, насколько мне известно за первый квартал 2018 несколько десятков новых контракторов появилось, на совершенно разных позициях от тестировщиков до VP of Engineering.

Это вам не «настоящая работа, а лучше»: как политика найма Crossover позволяет платить сотрудникам выше рынка

Невооруженным глазом видно, что негативные комменты пишут лиды, которые своим разработчикам не хотят или не могут ставки поднимать. ХО берет оверхед 10% и это открытая информация. Пугаете разработчика отчетностью ИП в налоговой? Туда надо сходить один раз в год, отдать декларацию и это занимает 10 минут, там сейчас очередей нет. Насчет утечки мозгов — кого это на самом деле волнует? Должно волновать чиновников, но их сейчас больше волнует борьба с коррупцией, думаю всем понятно о чем я. Для разработчика Crossover это хорошо, идет он туда или нет, т.к. ставки растут.

Почему в Петербурге так сложно построить карьеру VP of engineering

Везде, где реальный продукт делается, бывает потогонка, только часто не каждый день, а во время релиза. А во время релиза часто и каждый день и каждую ночь. Да, Crossover/ESW умеют выжимать из сотрудников производительность, но и платят за это шикарно по любым меркам, кроме американских. Если посмотреть с другой стороны, т.е. со стороны менеджмента, это вообще отличное достижение. Сотрудники не пьют чай и не ходят по поликлиникам, а работают в рабочее время. Поэтому и маржа.

Начальник, хочу работать из дома

Это вообще разные культуры — разработчики в офисе или разработчики удаленно. Я полгода работаю фул тайм удаленно и это реально сложно. Проблема не в общении — с коллегами постоянно на связи в слаке и в любой момент личным созвоном. Главная сложность — сохранять фокус, очень мало компаний это умеют контролировать. Crossover умеет, но достигается это очень жестким контролем и никак иначе. Веб камера фотографирует каждые 10 минут в случайный момент, также делаются скриншоты, фискируется активность клавиатуры и мыши, и какие программы вообще работают. Попробовали выключить камеры но тут же включили обратно — производительность резко упала )). Думаю все остальные способы ненадежны, каждый самый ответственный и благонадежный товарищ удачно надув компанию на время захочет это повторить. Как говорится нахаляву пьют и язвенники и трезвенники.

Люди — не гедонисты. Учёные определили, почему мы делаем неприятную работу, когда счастливы

По ссылке что-то ничего не открывается пока. Иллюстрация одной из идей статьи, что в хорошем настроении человеку проще взяться за необходимые, но скучные дела, вроде как понятна. Я как раз последнее время часто задумываюсь, как бы изобрести этакий «самомотиватор». Хорошие руководители, которые тебя мотивируют и при этом у тебя остается энергия и хорошее настроение — большая редкость, работать под кнутом эффективно (некоторое время), но неприятно, и губительно для организма. Всякие GTD плохо работают, потому что мозг всегда придумает, как обмануть программу с жестким алгоритмом. Может это исследование — подходящий путь для решения проблемы самомотивации. )

Люди — не гедонисты. Учёные определили, почему мы делаем неприятную работу, когда счастливы

Не очень понятные графики. Что такое вероятность от 0.85 до 1.15? Оригинал статьи к сожалению платный.

Зачем нужно моделировать индивидуальные и типовые сценарии?

Хорошо, пока что действительно интересно, но следуя вашим советам не тороплюсь :). А вы читали «Сумму технологий» Лема? Он в этой тематике очень глубоко копнул, а книга 1963 года выпуска, так что не совсем согласен с вашим утверждением в начале статьи, что моделирование реальности слабо исследовано. Вассерман еще рекомендует «Структуру реальности», «Слепой часовщик» и «Анти-Дюринг» для формирования целостной картины мира, но я еще даже «Сумму технологий» не осилил, уже второй месяц читаю.

Зачем нужно моделировать индивидуальные и типовые сценарии?

Главное, чтобы было интересно. Если действительно будет интересно так долго, то это круто. Но я конечно сомневаюсь. Проверим :)

Зачем нужно моделировать индивидуальные и типовые сценарии?

Статья немаленькая, за 5 минут не освоить, спасибо, поизучаю. То, что терминология ИТ специфична, это нормально — вы же не станете требовать от хирурга чтобы он «по-человечески» в своей среде изъяснялся, а не на латыни, а то не всем понятно о чем это он ;). Если мы говорим о ТЗ, ФТ и прочих интерфейсах с заказчиком (или общении хирурга о предстоящей операции с родственниками пациента), то это конечно совсем другая история.

Зачем нужно моделировать индивидуальные и типовые сценарии?

Сбрасывайте, конечно, интересно. Я думаю, с терминологией надо определиться в рамках решаемых проблем, иначе можно уйти в глубокую философию. Б-аналитики, как вы их называете, на мой взгляд являются по большей части интерфейсом между ИТ и бизнесом. Бизнесу важно достигать целей, а ИТ важно все автоматизировать. В данном случае не совсем понятно, в каком контексте вы работаете. Если в ИТ — то описание бизнес-процесса например в BPMN — это модель, в строительстве домов аналог — проект дома, это тоже модель. Дом — это инстанс, реализация модели, если вы строите для себя — будет в единственном экземпляре, если это П44Т — их будут тысячи. Можно создать реализацию безо всякого моделирования вообще — так природа поступает. С бизнес процессами то же самое, можете их описывать или нет, они происходят. Если их описать и привязать ключевые события к какой-то системе, можно попытаться ими управлять. Что из этого вы хотите хранить и зачем — мне пока не очень понятно.

Зачем нужно моделировать индивидуальные и типовые сценарии?

Проект дома и проект БП конечно в чем-то похожи, но есть и существенные отличия. Дом мы построили один раз, и наш проект будь он типовой или индивидуальный ушел в архив. БП же выполняется регулярно, поэтому мы его и автоматизируем. И фактически при каждом запуске могут произойти более или менее существенные отклонения от зафиксированного сценария, я так понимаю проблематика публикации где-то тут: как моделировать бизнес процессы таким образом, чтобы их было удобно автоматизировать, а также модернизировать и оптимизировать? Действительно, универсального решения так пока и не придумали, хотя методологий существует масса, и каскад с Гантом, и Agile со Scrum, и BPMS с BPMN и SOA с массой технологий вокруг, и все они с большим или меньшим успехом применяются.

Роскомнадзор и передовые технологии отставания

Согласен, у меня такое же ощущение от статьи. РКН плохой, у них хорошо, у нас плохо, мы скоро умрем. Если ты думаешь что РКН такой важный так предложи как с ним бороться, по мне так поставь плагин и не трать на него время. По поводу цивилизаций — у запада есть одна большая проблема, и она их погубит. Пока сохраняется частная собственность на средства производства, основным мотиватором развития остается ловкость в нахождении способов отъема результатов труда других людей. А это автоматически порождает противоположность интересов собственника и работника, что в свою очередь порождает агрессию. В масштабах цивилизации те кто вовремя «подсуетился» развивают армию и нагибают весь мир использовать их язык и валюту. То есть конечно не напрямую, но если немного подумать все шито белыми нитками. Каддафи потребовал допустить в СБ ООН страны не владеющие ядерным оружием, но прошло и 10 лет его ликвидировали. И БОД это на мой взгляд попытка сохранить капитализм, если его удастся внедрить — получим 5-й элемент с Зоргами. Правильный путь — ИТ социализм Вассермана, главная цель общества — максимально раскрыть творческий потенциал каждого, а вовсе не «канализация преступных наклонностей». Надо избавиться от агрессии, армий и осваивать солнечную систему, а не выяснять кто тут главный — я или тараканы.

DevOps — новый уровень взаимодействия групп разработки и эксплуатации

«Основная преграда» между разработкой, включая анализ, постановку и тестирование, и эксплуатацией — это ошибки во внедряемых сервисах, на самом деле это не преграда, а простой конфликт интересов, устранить его невозможно, но можно уменьшить, и пути на мой взгляд всего два — снижать количество ошибок, и увеличивать скорость их устранения. Чем больше автоматизируется разработка, тем конечно меньше ошибок просачивается в эксплуатацию, и тем больше возможностей появляется для анализа слабых звеньев. Но при некачественной постановке или несоответствии квалификации разработчиков сложности задач никакой DevOps не превратит плохой проект в хороший, он только может поспособствовать превратить хороший проект в еще чуть более хороший.