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

🔜 Как вы будете рекомендовать девушек в анкетах знакомств, если не вычислите статистическую вероятность симпатии от огонечков на шести сторисах?

🔜 Как вы будете подсчитывать успех кражи внутренних данных компании в обход NDA?

🔜 Может ограбить банк не такая уж плохая идея с вашими вводными данными?

Байес — это палочка-выручалочка.

По статистике 90% мужчин и девушек, что знают метод МСМС, лучше пахнут и получают на 100% больше взаимных симпатий.

Хотите также? — читайте нашу статью по Байесовской статистике в ML для самых маленьких.

Руководитель проекта должен любить людей. И любить с людьми общаться. Потому что к только вы становитесь Руководителем проектов, вам нужно начинать говорить с кучей народа: с командой – это минимум несколько человек, с заказчиками – это тоже часто несколько человек. Еще есть линейный руководитель, руководители команды, руководители заказчиков, релиз менеджеры, инженеры поддержки, внешние эксперты - короче, если вы не любите разговаривать с людьми, если долгое общение вас сильно утомляет, лучше всерьез подумать о какой-то другой работе.

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

Действительно ли надо всегда звонить, а не писать письмо? Какие еще есть варианты?

Как правильно и экологично проводить встречи?

Как не превращать встречи в ППР?

Обо всем этом коротко ниже.

Это очередная статья о том, чего не рассказывают на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

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

Звание «сениор», когда-то бывшее признаком большого опыта и знаний, обесценилось больше всего. Сегодня разработчиков начинают величать «сениорами» невероятно быстро, часто всего спустя три-четыре года работы. Как будто путь к «сениорству», бывший когда-то марафоном нарабатывания навыков и разнопланового опыта, превратился в спринтерский забег.

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

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

По разным оценкам, 60% работников испытывают негативное ментальное или физическое влияние из-за работы, 20% не могут с этим уровнем справиться, а 44% сотрудников испытывают высокие уровни стресса на ежедневной основе.

И потому мы с вами разберём 7 способов выявить причины выгорания и устранить их.

Счастливый сотрудник - успешная компания.

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

Что же можно сделать в каждой из трех ролей, чтобы все остались довольны (и целы)?

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

Когда у вас проблемы на проекте, вам хочется прийти к руководителю, выговориться, пожаловаться, чтобы похвалили и сказали, что надо делать. И лучше, чтобы не по телефону, а лично. Если у вас такое было или есть (у меня было, знаю, о чем пишу), знайте: это нормальная человеческая реакция – в сложный момент хочется поддержки, выговориться, обняться и порыдать - но это непрофессиональная реакция. Вы не на сеансе у психолога, вы на работе. Здесь не платят за "послушать, обнять и принять".

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

Это очередная статья о том, чего не расскажут на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

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

Leading индикаторы измеряют действия, которые происходят до достижения результата, и позволяют предсказывать успех или проблемы. Lagging индикаторы фиксируют результаты этих действий, которые можно измерить только после завершения работы. Оба типа метрик важны и взаимосвязаны: изменения в leading индикаторах могут повлиять на результаты, которые отражают lagging индикаторы.

Мы на Хабр Карьере помогаем IT-специалистам зарабатывать больше, а компаниям — быть в курсе трендов на рынке найма. 

Не так давно мы стали внедрять Индивидуальные Планы Развития (ИПР-ы) в Хабре и это оказалось непросто. Нам стало любопытно: каким специалистам они подходят, как влияют на мотивацию, повышение и как их собирать, чтобы сотрудникам было по-настоящему интересно по ним идти. 

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

К исследованию подключили команду платформы корпоративного обучения Грейд от Яндекс Практикума — оказалось, что ребята умеют круто наполнять ИПР-ы и собирают индивидуальные образовательные треки под каждого специалиста. 

А чтобы пользы от статьи было больше, мы в Хабре сделали сервис для составления ИПР-а, в котором можно выбрать цель, сроки и планировать задачи для достижения результата.

Привет! Нас зовут Даниэл Кнежевич и Максим Макеев. Мы руководим центром компетенций разработки в компании ITQ Group, отвечаем за бизнесовую и техническую часть работы подразделения. В этой статье мы обсудим предпроектное исследование — важный этап разработки IT-проектов. 

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

Знакома ли вам ситуация: тимлид распределяет задачи, всё делает сам, а на свой профессиональный рост и поддержку компетенций вечно не хватает времени? Без него в команде ничего не решается, и поэтому он становится «узким горлышком» в процессе. Отпуск откладывается, ведь без незаменимого лидера всё рухнет. Так происходит годами, и ничего не меняется.

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

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

Что с ними не так? Предлагаю разобраться в причинах и следствиях.

Это серия из трёх постов предназначена для новичков, которые уже находятся в процессе перехода в IT или только планируют сменить нишу.

Здесь будут собраны базовые термины из IT-индустрии, которые стоит знать начинающим Проджект и Продакт Менеджерам, Продукт-Овнерам, а также тем, кто ещё не определился со своей ролью.

В конце статьи оставлю ссылки на 2 других статьи из серии.

Тимлиду постоянно приходится отвечать на вопрос «когда сделаете?» или «когда будет готово?». И часто для ответа на этот вопрос нужно отвлечь от работы своего сотрудника, обсудить с ним задачу и только после этого дать ответ.

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

Недовольными, как правило, оказываются все. Тем не менее все постоянно играют в эту игру, и никто никому не верит.

Однако, если использовать исторические данные по сделанным ранее проектам и задачам, то можно узнать с 80% вероятностью срок исполнения задачи любого типа. Никакой магии. Просто математика и немного теории вероятностей :)) В этом суть Канбан-метода.

Привет! В одном из прошлых постов мы рассказывали вам, что в МКБ пришел Главный архитектор (ГА), Клецких Дмитрий. Проанализировав и оценив состояние дел, новый руководитель занялся изменениями, внедрением новых процессов и методологии. Собственно, об этом и будет пост.

Общее

Цель

• подготовка к рабочему дню и планирование его;
• оценка предыдущего своего рабочего дня;
• поделиться информацией и планами с коллегами;
• получить информацию от коллег, которая может пригодится в течение рабочего дня.

Привет, Хабр! Меня зовут Артур Темиров, я delivery‑менеджер в одном из продуктов X5 (о нём дальше в тексте). Над его созданием у нас трудятся 5 технических команд — в общей сложности это более 60 человек. В статье рассказываю о том, как визуализация является отправной точкой для эволюционного развития процессов, а также об ошибках, которые могут допускаться на этом пути.

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