Менеджмент

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

Что делать в такой ситуации?

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

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

Как справиться с рутиной? Как сделать жизнь интересной, если писать код — не только работа, но и хобби?

Единственный путь, который я вижу — параллельно с основной работой заниматься pet-проектами, открытым исходным кодом, развивать личный бренд, заниматься менторством.

Всем привет! Я уже больше 15 лет в IT, в роли РП 7 лет, до этого  долго был в смежных ролях релиз-менеджера и сервисного-менеджера. Долго мне не давали переходить в РП, но я формировал теоретическую базу и ворвался потом сразу в большие проекты. Сейчас являюсь играющим тренером, люблю сложные проекты/фичи большого масштаба. По запросу занимаюсь менторством, радуюсь когда вижу развитие и рост коллег. Хочу поделиться на мой взгляд ключевыми проблемам которым мало уделяется внимание. Надеюсь кому-то будет полезно.

В этой статье я показываю, как заменить рутинную работу куратора курса простым сценарием в n8n. Всё делается через Google Sheets и Telegram-бота, без строчки кода. Текст написан специально для работников образования и гуманитариев — повторить сможет каждый.

Как была создана одна из наиболее важных моделей, повлиявших на современный финансовый мир (CAPM)...

Только что назначенный доцент кафедры финансов в Университете Вашингтона Уильям Шарп посвятил свои первые годы работе, посвященной модели ценообразования капитальных активов (Capital asset pricing model).

Выродивщийся аджайл, карты Уордли, метод MOSCOW, канбан‑каденции, НФТ, закон Хофштадтера, топ-10 канбан‑досок, запретные слова для ПМов, рынок вакансий, управление кросс‑функциональной командой и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

В 2017 я пытался продавать светодиодные маски и не продал ни одной.

В 2019, будучи школьником, сидел по ночам в фотошопе, делая посты для групп VK.

А в 2021 совершил 12 холодных звонков, чтобы получить первого клиента на таргет. Эта статья — честный рассказ о моем пути.

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

Это история о превращении из фрилансера-многостаночника в руководителя сфокусированного агентства.

Управление корпоративной архитектурой – это та тема, в который на данный момент больше всего «тумана», несмотря на присутствие стандартов и лучших практик (TOGAF, BIZBOK и другие фреймворки).

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

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

Сколько и куда инвестировать в дев-инструменты и платформу, как считать отдачу от оптимизаций (хоть от снижения CPU), и где гонять тесты — на пресабмите или на интеграции? Простых ответов нет. В этой статье я предлагаю целостную модель баланса между затратами разработки и создаваемой ценностью с учётом рисков: успех продукта, продуктивность команды, эффективность ресурсов и стратегические возможности. Дам практичные ориентиры для продактов, инженеров и менеджеров, а также покажу, как инфраструктура и архитектура сдвигают этот баланс и где именно выгодно усиливать автоматизацию и проверки.

Agile-методологии, основанные на манифесте 2001 года, стали краеугольным камнем современной разработки программного обеспечения (ПО) благодаря своей гибкости, ориентации на клиента и способности адаптироваться к изменениям. В России, где IT-сектор демонстрирует устойчивый рост Agile остается доминирующей парадигмой. Однако экономические вызовы, включая санкции, импортозамещение и нестабильность (инфляция 6,2% в апреле 2025), а также технологические сдвиги, такие как интеграция искусственного интеллекта (AI) и DevOps, порождают вопросы о будущем Agile. Действительно ли принципы Agile теряют популярность в российской разработке ПО? Если да, то что приходит на замену?

Российский IT-сектор уникален: он сочетает стремительный рост (CAGR 12% в разработке ПО) с ограничениями. Это стимулирует переход к локальным аналогам и гибридным методологиям. В то же время глобальные тренды, такие как автоматизация через AI и рост DevOps влияют на локальную практику. В этом контексте важно понять, сохраняет ли Agile свою актуальность или уступает место новым подходам, и как российские компании адаптируются к этим изменениям.

Иван с силой скомкал распечатанный макет нового интерфейса. Бумага хрустнула, как лед под ногой. Он швырнул искалеченный лист на полированный стол, где уже громоздилась целая стопка таких же — испещренных его правками, сделанными красной ручкой, словно ранами. Ни одна из них не привела к прорыву.

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

Всем привет! Меня зовут Александр Пряхин, я технический руководитель в Авито Подработке. В этой статье я рассмоатриваю подходы к измерению качества стабильной работы системы, а не только её отказов. Я постараюсь описать, что такое бюджет качества и почему его стоит считать; как SLA, SLO и SLI помогают наводить порядок и принимать решения; и главное – почему техническое качество напрямую становится зоной ответственности тимлида и как через метрики команда может начать говорить с бизнесом на одном языке.

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

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

В прошлых статьях я прошелся по фразам:

Часть один: «Этого нет в ТЗ!» и «Этого нет в моей должностной!»
Часть два: «Мы проговаривали!» и «У меня нет ресурсов!»

И сегодня я пройду по оставшимся. Там будут и совсем гиблые и вполне приемлемые, которые просто надо использовать осторожно.

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

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

Период 2020–2021 годов характеризовался двумя на первый взгляд разнонаправленными, но синхронными процессами. С одной стороны, Федеральная резервная система США инициировала беспрецедентную по масштабам программу количественного смягчения (QE), что привело к экспоненциальному росту денежной массы и притоку ликвидности на финансовые рынки. С другой стороны, Народный банк Китая и другие регуляторы КНР последовательно ужесточали политику в отношении криптовалют, кульминацией чего стал полный запрет на майнинг и транзакции в 2021 году.

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

Мне нужно было срочно придумать, как перезагрузить голову.

Добрый день, уважаемое сообщество Хабра! Я тимлид, и сегодня хочу поделиться с вами опытом поиска работы в 2025 году. Это первый раз в жизни, когда я искал новую должность, уже будучи лидом. В последнее время тема поиска работы всесторонне рассматривается с точки зрения разработчиков. Но как новые предложения ищут лиды?

Предлагаю вам вместе со мной посмотреть на ключевые особенности рынка вакансий лидов в России. Моё мини‑исследование не претендует на объективность: только одно (ладно, два) резюме и только один всем известный сайт поиска работы. Однако можно понять некоторые общие закономерности и обсудить то, как видят нас, лидов, наши потенциальные работодатели. Ну и поделиться друг с другом своими историями в комментариях.

Если вы лид, либо смотрите в эту сторону, а также если вы HR, приглашаю вас дальше.

Привет, Хабр!

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

Концепция #NoEstimates во многом объяснена в публикациях старожилов Agile. Оценки всегда неточны, обычно очень сильно. Единственный случай, когда оценка может сработать — это когда вы строите то же самое снова. Во всём остальном мире — где постоянно что‑то меняется — тратить время на приблизительные расчёты бессмысленно. Гораздо важнее смотреть на реальные показатели команды: скорость выполнения задач, время их прохождения и т. п. Холуб дальше замечает, что планировать «строгие» сроки — это пережиток водопадной модели, а Scrum‑фреймворк даже не требует от команды жёсткого commit«а на объем работ: в Scrum говорят о прогнозах (forecast), а не о фиксированных обязательствах.

Я знал одну компанию, которая занималась продажами В2В и В2С. У них было интересное правило: раз в неделю менеджер имел право послать одного клиента на три буквы, высказать ему матом всё, что захочется, нагрубить в своём стиле и бросить трубку. Директор компании считал это невероятной инновацией и проявлением демократичного стиля управления. Мне эта традиция не нравилась: во-первых, всегда можно расстаться по-человечески, а во-вторых, 7 менеджеров, 50 рабочих недель в год, это 350 посланных клиентов с очень высоким уровнем негатива. Даже если «право» реализуют в 10% случаев, это 35 потенциальных носителей отрицательных отзывов (и это минимальный из рисков). 

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

Привет, Хабр!

Использование OSS‑компонентов — стандарт современной разработки. Под OSS‑компонентами мы понимаем ПО с открытым исходным кодом. Это могут быть приложения, библиотеки, набор файлов, или даже просто фрагмент кода.

Но при использовании OSS есть нюанс — лицензии. Одни библиотеки можно брать без оглядки, другие требуют платежей, а третьи — строгого соблюдения условий. И если в бэкенде зачастую все относительно статично (версии меняются редко, компонентов немного), то веб — отдельная история. Тут компоненты множатся с космической скоростью, версии обновляются каждую неделю, и следить за всем этим вручную просто нереально.

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