• засилье KPI с последующей деградацией продукта, которое по менеджерской логике должно увеличивать DAU;
  
• деградация корпоративной культуры из-за офисных интриг и карьеризма;
  
• снижение продуктивности разработчиков из-за бесконечных совещаний, созвонов, отчётности и использования ПО для «повышения эффективности» (таск-трекеры, тайм-трекеры, календари и проч.);
  
• цифровое истощение и выгорание сотрудников.

Эта статья помогает понять, как команды в Scrum и agile могут давать гарантии и сроки, сохраняя гибкость в планировании. Она будет полезна тем, кто заинтересован в четких сроках реализации доработок: заказчикам, пользователям, владельцам продукта, другим командам и отделам. А также разработчикам — для понимания, почему сроки так важны стейкхолдерам и как можно вести диалог о сроках, сохраняя при этом гибкость.

Я часто слышу, что метрики — не для IT: не в строчках же кода считать эффективность. Но мы в Циан уже несколько лет используем метрики в оценке разработки и знаем, как их использовать во благо.

Меня зовут Алексей Чеканов, я CTO в Циан. Я расскажу, что такое хорошие и плохие метрики, в чём можно измерять эффективность IT.

Можно ли с помощью GitHub анализировать работу, не заглядывая в монитор сотрудника — без скриншотов и тайм-трекеров?

Я Александр Кириллов, технический директор компании Evrone. Больше 20 лет я посвятил разработке. В этой статье поделюсь с вами опытом, который собрал за время работы с распределенными командами. Расскажу о том, как, не нарушая приватность разработчиков, следить за качеством работы на проектах и отслеживать нежелательные паттерны с помощью метрик в Jira и Git.

Когда вы написали продающее резюме, откликнулись на интересующую вас позицию, оно прошло сканирование ATS системой и было отобрано рекрутером, следующий шаг — это созвон с рекрутером для первичного скрининга.

В этой статье я расскажу:

• Что такое скрининг-колл.

• Какие типовые вопросы встречаются на скрининг звонках в США, вне зависимости от того собеседуют ли в стартап или в FAANG компанию.

• А также на какие вопросы вы не должны отвечать на скрининг звонках в США.

Соглашения — важная часть процесса разработки. Они призваны снижать затраты и упрощать жизнь сотрудников. Проблема в том, что часто соглашения, наоборот, только всё усложняют, поскольку они толком не зафиксированы и передаются исключительно из уст в уста, как старые сказки. В процессе передачи они обрастают новыми подробностями, а прежние подробности упускаются. В итоге у каждого участника команды в голове свой набор соглашений, которые он периодически забывает.

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

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

В самом начале у нас в Самокате была задача — внедрить практику нагрузочного тестирования на каждый релиз, чтобы минимизировать проблемы с производительностью на проде. А еще сделать это не потратив все деньги мира, ну и желательно внедрить это не за пятилетку. И вот где-то тут начинается немного магии Поэтому давайте оденем поварские колпаки, возьмем котел и попробуем приготовить PerfOps-инженера который должен нас спасти.

Меня зовут Кирилл Юрков, я SRE-тимлид Samokat.tech. Сегодня поговорим про нагрузочное тестирование. Про то, как мы решали обозначенную проблему, какие грабли нам попались, и какие трудности удалось преодолеть.

Привет, Хабр! Я Екатерина Колесникова, Agile Coach в inDriver. Когда я пришла в команду, заметила проблемы в процессе Product Backlog Refinement. Я предложила новый сценарий этой церемонии — и он сработал. В этой статье поделюсь опытом проведения PBR без скучной теории о «правильном» планировании. 

Каждый разработчик рано или поздно сталкивается с необходимостью повторного использования собственного кода. В проектах PHP для этих целей создаются пакеты, устанавливаемые с помощью Composer. При этом пакеты могут быть абстрагированы от каких-либо фреймворков, либо могут быть предназначены для использования в конкретном PHP-фреймворке. В данной статье рассказывается о том, как создать PHP-пакеты для фреймворка Laravel, но материал будет полезен и тем, кто собирается разрабатывать любые другие PHP-пакеты (как публичные, так и приватные).

Для лучшего понимания данного материала рекомендуется ознакомиться с разделом о разработке пакетов в официальной документации Laravel. А для более детального изучения темы будет полезен данный ресурс.

Данная статья в большей мере ориентирована на начинающих разработчиков.

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

Я разрабатываю сервисы в команде платежей Ozon. Мы много времени уделяем тому, чтобы все транзакции были обработаны корректно, даже если речь идёт о нагрузке в 2к платежей в минуту (именно столько у нас было в пике в период ноябрьских распродаж). Кстати, сейчас, по результатам нагрузочного тестирования, мы выдерживаем 13к платежей в минуту.

Для этого мы готовимся заранее: пересматриваем архитектуру, дорабатываем сервисы, рефакторим код, кэшируем и оптимизируем базы данных. Серебряной пули тут нет, но могу поделиться техниками, которые помогли нам избежать возможных проблем, — будет полезно всем, кто готовит свои сервисы с прицелом на работоспособность под нагрузками.

Мне стало интересно проанализировать данные о своих тренировках за последние несколько лет, и я понял, что обычного функционала приложений типа Garmin Connect или бесплатной версии Strava будет недостаточно. В этой статье я расскажу как получить свои персональные данные о тренировках из устройств Garmin и разместить их в реляционной базе данных с помощью библиотек python.

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

Я составил 50 самых важных вопросов будущему работодателю, которые ты обязан задать на собеседовании.

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

Есть своя идея приложения, нужно понять стоит ли ей заниматься.

По работе, у вас есть несколько идей/фич на текущий квартал и вы хотите узнать, какая наиболее перспективная. Ведь если команда работает над слабой фичей, в то же время она НЕ работает над чем-то сильным и нужным. А время идет.

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

Чтобы фича/идея имела смысл, ваш продукт должен быть кому-то нужен. Причем желательно часто, и сильно. В этой статье я покажу три простых шага проверки идеи, на примере приложения для выбора велосипеда.

Заграничные компании, которые нанимают русских разработчиков — это часто смесь из людей совершенно разных национальностей и культур. Как влиться в такой коллектив, что там творится с языками и акцентами и как культура влияет на рабочие процессы — об этом всем расскажет наш герой с большим опытом работы в многонациональной команде.

Приветствую!

Меня зовут Максим Торнов и я продолжительное время занимаюсь проектами в области управления рисками и аудитом ИТ и ИБ. Помимо этого, я долгое время работал в различных областях ИТ, а также занимался проектами по оценке эффективности и внедрению систем внутреннего контроля, в одной из консалтинговых компаний «Большой четверки».

В данном материале мне бы хотелось рассказать Вам об основах управления риском ИТ.

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

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

Если ваше приложение использует Log4j с версии 2.0-alpha1 до 2.14.1, вам следует как можно скорее выполнить обновление до последней версии (2.16.0 на момент написания этой статьи - 20 декабря).

Log4j уязвимость отслеживаться как CVE-2021-44228 (также известный как Log4Shell) позволяет злоумышленнику выполнить произвольный код в системе. 

В заметке описаны инструменты для проверки зависимости Java проекта от уязвимой версии Log4j.

Вы ещё не слышали, как профессор Гарвардской школы бизнеса «наживается» на своих студентах? Тогда вам, наверное, будет интересно узнать о том, как продать 20 долларов за гораздо большую сумму. Скажем, долларов за 200.

Профессор Макс Базерман придумал эксперимент, который демонстрирует необъяснимое иррациональное поведение будущих профессиональных бизнесменов и менеджеров в их родной стихии — управлении проектами. Кстати, в эту же ловушку попадают и топ-менеджеры крупных компаний, с которыми профессор проводит свои семинары.

Я проходил технические собеседования на системного аналитика в самых разных компаниях и каждый раз записывал все вопросы. У меня накопилось 120 вопросов. Список вопросов выкладываю в этой статье. Даю гарантию, что, подготовившись по этим вопросам, вы будете успешно проходить технические собеседования в большинстве, если не во всех, it-компаниях. Почему? Потому что большинство вопросов повторяются от собеседования к собеседованию. Очень высока вероятность того, что вопросы, которые вам будут задавать, будут из этого списка.