Один из наиболее эффективных инструментов руководителя, который я пробовал, это заключать "культурный контракт" с каждым сотрудником при его приеме на работу.

Не так давно было много хайпа вокруг хотелок создания бирюзовых компаний. О своем намерении ими стать говорили многие. В итоге тема сошла на нет, а цветовая гамма компаний так и осталась красно-синяя. На мой поверхностный взгляд, причина этому простая - бирюзовые компании базируются только на культурном коде - на неписаных правилах, добровольно разделяемых и выполняемых всеми участниками коммуникаций при том, что явное вознаграждение за каждое действие они не получают. Создание культуры - это крайне времязатратное мероприятие, на которое ни у кого нет времени, да, и люди меняются в компаниях быстрее, чем начинают разделять ее культуру.

Так при чем тут "культурный контракт"? Все просто, при приеме каждого сотрудника моя первая беседа с ним была на основе тезисов:

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

Сложно проводить собеседование с джуном. У новичка пока немного технических знаний и практических навыков, а карьерный путь и того меньше. Спрашивать, кроме теории, пока особенно нечего. Строить прогнозы на аппроксимации предыдущих успехов невозможно.

Что же тогда говорить про эффективность собеседования с IT-абитуриентом.
Который не имеет и намека на технические знания.
Который ни дня не работал ни на одном IT-проекте.
И, который, скажем честно, и сам пока не до конца уверен, а подходит ли ему IT.

Именно такая, казалось бы абсолютно нерешаемая задача, стояла перед нами в рамках двухлетнего проекта. Научиться с высокой степенью точности предсказывать карьеру (или ее отсутствие) у того, кто только планирует получать технические знания.

«На прошлой неделе McKinsey опубликовала статью под названием «Да, вы можете измерить продуктивность разработчиков программного обеспечения». Эта статья вызвала настоящий переполох в сообществе разработчиков ПО. Кент Бек — инженер-программист и создатель экстремального программирования —написал что «Отчет настолько абсурден и наивен, что нет смысла подробно его критиковать».

Хотя мне не понравилось куда клонит этот отчет, я решил взглянуть на положительную сторону: то, как участие McKinsey сигнализирует о растущей потребности даже в «традиционных» компаниях лучше понимать, как работают команды разработчиков программного обеспечения.

Но что-то было не так. Через несколько часов после публикации этой статьи я уже созванивался с Кентом, поскольку мы пытались определитьточно почему мы оба были разочарованы этим отчетом. Мы почти сразу оказались на одной волне и решили, что можем помочь сообществу разработчиков программного обеспечения, изложив словами то, что мы обсуждали. Ниже приведен наш ответ, написанный мной и Кентом Беком, одним "общим голосом".

Это вторая и последняя часть ответа нас двоих Gergely Orosz и Kent Beck:

на статью McKinsey «Да, вы можете измерить продуктивность разработчиков программного обеспечения».

Мы считаем, что фрейморк который  предлагает McKinsey является ошибочным и наверняка приведет к обратным результатам. Такой фреймворк, скорее всего, принесет гораздо больше вреда, чем пользы организациям – и инженерной культуре в компаниях, и на устранение ущерба могут потребоваться годы.

Привет! Меня зовут Полина, я руковожу A/B‑платформой в СберМаркете. В этой статье я расскажу о нескольких нюансах экспериментирования, которые возникают на разных этапах — от дизайна и сплитования до подведения итогов. Если их не учитывать, нам приходиться с осторожностью относиться к результатам или вовсе проводить эксперимент заново. К ним относятся Sample Ratio Mismatch, корректное пересечение тестов, взаимодействие нескольких экспериментальных механик и другое. Разберем как эти критерии обнаружить, найти причину и что делать с экспериментом дальше.

«Баннерная крутилка» —  один из самых высоконагруженных сервисов в Яндексе. Он умеет переживать 700 тысяч RPS, а иногда и больше. Каждый раз, когда приходит запрос, крутилка должна просмотреть базу из миллиарда документов и выбрать из них самые релевантные для пользователя. При этом выдерживаются весьма жесткие временные рамки: 99% всех запросов обрабатываются менее чем за 200 миллисекунд.

Какими принципами стоит руководствоваться при построении подобных высоконагруженных систем? Как устроены стадии отбора документов? Какое участие в ранжировании принимает ML? Обо всём этом на недавнем мероприятии для разработчиков в Ереване рассказал Артём Ваншулин, руководитель разработки ранжирования в команде баннерной системы. Сегодня мы делимся с сообществом текстовой версией его доклада. Передаём ему слово.

Для успеха каждого проекта критически важно, чтобы все его участники одинаково понимали слова и словосочетания, которые они применяют в общении между собой, и, что даже более важно, понимали разницу между ними. Срок. Продолжительность выполнения задач. Трудоемкость. Трудозатраты. В принципе, ничего сложного и сакрального в этих понятиях нет. Главная сложность состоит в том, чтобы договориться об их единообразном понимании на проекте. Обычно проблемы налаживания таких соглашений вообще не отсвечивают в специальной литературе. Однако в случае, если ваши стейкхолдеры сразу не подтверждают готовность сотрудничать в рамках этих понятий, это главный признак того, что на проекте вы уже имеете проблемы. Большие проблемы. Проявление этих проблем в реальном мире – это только вопрос времени. Ближайшего времени. Это индикатор того, что ваша проектная команда столкнулась с рафинированным менеджером.

Гуд ньюз эвриван! Вышло большое обновление учебника «100-Year QA‑Textbook — русскоязычная версия» — одного из самых полных источников по тестированию.

С момента первого релиза (100'000 хабр‑просмотров!) прошло полгода.
За это время столетний учебник стал бесплатным пособием для 10'000+ самообучающихся студентов.

Для лиги лени: много лет в российском ИТ продвигалась политика «Умные нам не надобны. Надобны верные». В связи с этим в российском интернете уже сейчас много интересных моментов и криков боли – свободные мидлы кончились, а джуны не прыгают за табличкой 'морковка будет завтра'. Потому что морковки для них уже давно нет, осталась только табличка, и джуны это знают.

Посвящается моему бывшему руководителю Анатолию А., который на прошлой неделе (в апреле 2024 года) узнал, что контейнеры при настройке по умолчанию вовсе не предназначены для хранения чего-либо, и что скорость дисковых операций контейнера даже с подключенным локальным NVME несколько ниже, чем он представлял.

Привет, Хабр! Я Женя Кучерявый, директор по фронтенду в Rentu. В этой статье расскажу как мы переезжали с Vue2 на Vue3, какие шишки набили и чему научились. Статья не хардовая.

Нативная отложенная загрузка для изображений была добавлена в Chrome 76 через атрибут loading, а затем пришла и в Firefox. Мы рады сообщить, что встроенная отложенная загрузка для iframe теперь стандартизирована и также поддерживается в браузерах на основе Chrome и Chromium.

<iframe src="https://example.com"
        loading="lazy"
        width="600"
        height="400"></iframe>

Встроенная lazy-loading загрузка iframe откладывает загрузку закадровых элементов iframe до тех пор, пока пользователь не прокрутит их рядом. Это сохраняет данные, ускоряет загрузку других частей страницы и уменьшает использование памяти.

Вселенная культовой игры Fallout получила очередное перерождение с выходом сериала от Amazon. Хотя фабула произведения (почти) и не пересекается с играми, главная сюжетная арка осталась прежней: сливки общества укрываются в убежищах от ядерного безобразия, а выйдя на поверхность, оказываются совершенно не готовы к царящей там анархии. Как построить качественный бункер и не облажаться, и что на самом деле случится с людьми и убежищем даже не за двести, а всего за два года изоляции? Под впечатлением от сериала вспоминаем самый масштабный эксперимент по созданию «прототипа убежища» и разбираемся, насколько обнадеживающими оказались его результаты. Спойлер — не очень.

Нужна ли аналитику креативность? Работодатели, похоже, считают, что нет или что креативность не важна. Например, на hh.ru всего 10 вакансий «с креативностью» по всей России на момент написания статьи. И только в двух из них (Ozon и «Ростелеком») говорят напрямую, что креативность нужна.

Я работаю с данными почти 20 лет, и из них семь набирала и растила джунов, три — наставник в Практикуме на курсе «Аналитик данных». Предлагаю вместе подумать, а нужна ли нам креативность, как проверить, есть ли она, можно ли её чем-то заменить и как прокачать.

Если составлять топ самых крутых изобретений человечества, то второе место сразу после кофеварки наверняка займёт opensource – разработка проектов с открытым исходным кодом, которая помогла родиться поистине огромному числу полезных и гениальных продуктов. Причём опенсорс важен не только для сообщества программистов в целом, но и для каждого конкретного разработчика: участвуя в создании программ с открытым кодом, они могут неплохо развить свои скиллы, обрести новых друзей со сходными интересами и, конечно же, потешить своё самолюбие. Признайтесь, вам хотелось бы, чтобы вашей библиотекой пользовался весь мир?

• Введение в процесс Running Lean
  • Три важнейших методологии
  • Roadmap
• Описание процесса Running Lean
  
  • Составьте «План А»
    
    • Определите кто клиенты
    • Создайте бизнес-модели
    • Ранжируйте бизнес-модели
  • Протестируйте и измените план
    
    • Подготовьтесь к проведению экспериментов
    • Категории рисков и четыре фазы тестирования плана
      
      • Фаза 1. Поймите проблему
      • Фаза 2. Найдите решение
      • Фаза 3. Валидируйте качественно
      • Фаза 4. Верифицируйте количественно
• Три стадии стартапа
  
  • Соотношение трех стадий стартапа и четырех фаз тестирования плана
  • Держите правильный фокус
  • Привлекайте финансирование вовремя
  • Масштабируйте правильно

Привет, Хабр! Меня зовут Андрей и я программист. Как и многие, в свободное время я занимаюсь разработкой своих Pet-проектов.

Для себя я писал мобильные приложения, игры на Unreal Engine, пробовал обучить нейросеть генерировать квесты и многое другое. Большинство их них приносило мне удовольствие, самореализацию, рост. А некоторые я мог даже считать своим портфолио.

Но иногда бывало и такое:  

• мне казалось что я пишу «в стол»;

• кризис идей;

• нет сил и желания закончить хороший проект;

• «стыдно» показать свой проект, «да кому он нужен», «это не портфолио» и т.д.

Недавно я решил оценить прошлый опыт и оформить свой подход к работе с pet-проектами, чтобы они приносили пользу и повышали мотивацию, а не создавали выгорание. Вам же предлагаю это в виде списка небольших советов.