Ключевой инструмент многих компаний — Confluence — снимается с продаж. Atlassian официально объявила о прекращении развития on-premise-версии своего флагманского продукта. Новых лицензий не будет уже с марта 2026, а в 2029-м полностью прекратится поддержка.
Привет! Меня зовут Миша Хаджинов — я продакт в DS-департаменте Авито и уже более семи лет занимаюсь разработкой продуктов на основе технологий машинного обучения и LLM. За это время успел пройтись по всем возможным граблям, поэтому решил поделиться опытом, как их можно было бы избежать. Расскажу о рабочем пайплайне, который поможет добиться успеха в разработке с первого раза. Статья будет полезна продактам, которые сталкиваются с ИИ впервые, а также разработчикам без профильной экспертизы.
Сегодня вопрос о женском лидерстве выходит далеко за рамки дилеммы «карьера или семья». Он затрагивает глубинные аспекты самореализации, стиля управления и внутренней аутентичности.
Должна ли женщина-лидер быть мягкой, или ей необходимо проявлять жёсткость, рискуя превратиться в «сильного мужчину»?
Существует теория, что идеальный руководитель — это бесполое, нейтральное существо — человек, чья основная задача — эффективно управлять процессами и командой. Но реальность оказывается гораздо сложнее.
Рабочее пространство, где мы проводим большую часть жизни, неизбежно становится сценой для отыгрывания глубоко личных, часто неосознаваемых сценариев. И руководитель, вопреки желанию оставаться нейтральным, оказывается втянут в эти игры.
Как нетехническому специалисту участвовать в принятии решений, от которых зависят бюджет, сроки и масштабируемость продукта
Архитектурные решения — это фундамент цифрового продукта. Выбор между монолитной и микросервисной архитектурой определяет, насколько быстро вы сможете выпускать новые функции, как будет масштабироваться бизнес и какие команды вам потребуются. Это не чисто технический вопрос, а стратегический, напрямую влияющий на финансовые и операционные показатели.
Многие нетехнические специалисты — продуктологи, менеджеры, основатели стартапов — чувствуют себя исключенными из этого разговора. Их задача — не писать код, а понимать бизнес-последствия выбора и говорить с разработчиками на понятном им языке. Вот практический фреймворк, который поможет участвовать в этих обсуждениях на равных.
За годы работы в управлении проектами я убедился, что каждое внедрение ИТ‑решения — это не просто установка программы. Это история о людях, о проблемах, которые они решают день за днём, и о преобразованиях, которые происходят, когда технология встречается с реальностью. Я хочу рассказать о двух проектах, которые научили меня больше, чем любые учебники.
В современном ИТ сложилась парадоксальная ситуация.
С одной стороны, неплохой уровень заботы о сотрудниках, продвинутая служба HR, хорошие зарплаты и неплохие условия труда. С другой, высокий уровень выгорания, несчастья и болезней, даже хуже, чем в прочих отраслях.
Парадокс объясняется просто: в современном ИТ отвратительная организация. Настолько отвратительная, что многих её директоров впору увольнять, потому что именно они отвечают за её значительную часть, но многого не делают.
И получается, что сотрудники постоянно сталкиваются с переработками и избыточным стрессом, паническими релизами и бюрократией, совмещением и размытыми зонами ответственности. И так далее.
В статье кратко, но ёмко раскрываются 36 организационных проблем, решение которых помогут улучшить жизнь сотрудников и результаты бизнеса.
Даже если они не из ИТ-сферы.
Всем привет! Меня зовут Антон Чижов, я руковожу в MWS центром практик agile. Вместе с Александром Демидовым, директором по разработке MWS, расскажем о продуктовом инженере — новой роли, которая открывает для опытных специалистов более гибкие варианты карьерного трека.
В классических командах каждый участник развивается в своем направлении, но такой вариант подходит не всехм. Специалистам в одной предметной области — например, архитектуре, разработке на Go и так далее — сложно охватить и постоянно держать в уме цели продуктов: у них не так много возможных карьерных треков. Убрать эти ограничения позволяет концепция продуктовых инженеров — специалистов, сочетающих в себе несколько технических компетенций, а также развитые продуктовые и софтскилы.
Сегодня подробно рассмотрим эту новую роль и покажем, чем она может быть интересна разработчикам: кому подходит, какие варианты развития открывает и что дает компании.
Когда я перешел в IT из абсолютно нетехнической среды, на первом же совещании услышал: «Нужно пофиксить баг в продакшене, перед этим замержить пул-реквест, и если что-то пойдет не так — будем экстренно откатываться». Я улыбался и кивал, не понимая ровным счетом ничего.
Оказалось, что язык IT — это не набор заклинаний, а логичная система. И ее можно понять, не становясь программистом. Просто нужно найти правильные аналогии. Этот опыт стал для меня настолько ценным, что я систематизировал его в книге «Птичий язык: как говорить на языке разработчиков не написав ни строчки кода». А здесь делюсь ключевыми находками.
Вот как я начал понимать команду разработки, проводя параллели с привычными вещами.
Привет, Хабр!
Сегодня поговорим про стратегию Go-to-Community вместо Go-to-Market. Звучит, конечно, круто, но суть простая: перестать видеть разработчиков только как лидов в воронке продаж и начать работать с ними как с сообществом на равных, с созданием ценности для всех.
Паника, давка, пожар — как предотвратить катастрофу в месте, где собираются тысячи человек?
Ответ кроется не в увеличении штата охраны, а во внедрении интеллектуальных систем, предсказывающих риски — технологических стражей современных арен спорта. Давайте пройдем путь обычного болельщика, чтобы увидеть, как технологии создают его безопасность буквально на каждом шагу, превращая стадион в цифровую крепость.
На одном из недавних FinOps X саммитов Джрордж Паркер и Уилл Форрестер из Salesforce представили примечательный, на мой взгляд, кейс построения FinOps-модели, что называется «на вырост».
Salesforce является одним из мировых лидеров рынка CRM-систем и предлагает облачные решения, основанные на модели SaaS.
В 2020 году компания приняла стратегическое решение о переходе в публичное облако. Этот шаг потребовал не просто технологической перестройки, но и кардинально нового подхода к управлению облачными финансами. Поскольку теперь каждый инженер мог напрямую влиять на расходы (читай — создавать объекты расходов), традиционные методы бюджетирования — когда ресурсы ограничиваются квотой того, что есть в приватном облаке — перестали быть эффективными.
С 2021 года сотрудники в разных исследованиях всё чаще говорят: «я хочу регулярный, полезный фидбэк». В разных выборках от 80% до 96% респондентов отмечают пользу обратной связи и её влияние на мотивацию. Но статистика показывает ужасную разницу между желанием и реальностью: по данным Gallup и Happy Job, более 75% сотрудников не получают достаточно обратной связи, и лишь около 16% считают её действительно полезной.
В этом и заключается главный парадокс: сотрудники жаждут конструктивного диалога, а на деле получают либо размытые комментарии, либо откровенно демотивирующую критику. Корень этой проблемы кроется не в злом умысле, а в отсутствии у менеджеров конкретных навыков: как сформулировать мысль, выбрать верный момент, наметить план исправления и оказать реальную поддержку. Большинство руководителей искренне хотят помочь, но их не научили главному: как давать негативную обратную связь, чтобы сотрудник не чувствовал себя плохим работником, а видел перед собой чёткий путь к улучшению.
Эта статья будет полезна менеджерам, которые хотят давать мотивирующую и полезную обратную связь. Рассмотрим самые частые ошибки, которые приводят к выгоранию сотрудников, и правила, по которым легко построить фидбэк для самых сложных ситуаций.
Договор вводит в оборот и хранит интеллектуальные права на товарный знак и другие объекты. Вы монетизируете интеллектуальную собственность.
В IT-индустрии существует фундаментальная проблема, которая годами заставляет команды срывать дедлайны, терять миллионы в перерасходах и выгорать от бесконечного пожаротушения. Парадоксально, но корень этой проблемы лежит не в сложности технологий или недостатке ресурсов. И это оценка задач, а именно попытка оценивать принципиально разные типы задач одними и теми же методами – и это фундаментальная ошибка.
В корпоративной разработке существуют два параллельных мира задач, которые требуют совершенно противоположных подходов к планированию. Первый мир – это исследовательские задачи, где вы пытаетесь найти решение в условиях высокой неопределенности, когда контекст известен лишь частично. Второй мир – типовые задачи с заранее известным объемом работы и предсказуемыми рисками. Смешивание этих миров в единую модель планирования — вот что приводит к катастрофическим последствиям для проектов.
Заслуживает ли карьера руководителя твоего внимания?
Почему ты пашешь за троих, а повышают коллегу?
А что, если ты всегда хотел в менеджмент — но не понимал, с чего начать?
В этом пошаговом гайде я раскрою мотивацию руководителей и поделюсь рабочим рецептом старта управленческой карьеры. Советы будут полезны не только тем, кто строит карьеру, но и тем, кто развивает собственный бизнес или хочет повысить качество своей жизни.
Зачем вменять совершение финансовых операций и других сделок с денежными средствами, полученными за разглашение коммерческой, налоговой или банковской тайны, в качестве легализации (ст. 174.1 УК)?
Ответ прост: чтобы конфисковать денежные средства или иное имущество, которое «легализовали». Ведь ни полученные, ни облеченные в законную форму денежные средства и тому подобное имущество в перечень конфискуемого, в отличие от предмета легализации, не входит.
Правоприменитель использует любые компенсаторные механизмы для обращения имущества в доход государства.
Я видел сотни команд, которые пытались внедрить систему управления и бросали через пару месяцев. Каждый раз звучал один и тот же вопрос: как сделать так, чтобы команда начала работать в системе?
В этой статье я разбираю восемь простых приёмов, проверенных на тысячах пользователей. Попробуйте их — и вы сможете не просто «вовлечь людей», но также ускорить выполнение задач и сэкономить бюджет.
Если вы пишете, потом переписываете, рефакторите, а снова переписываете – вы что-то делаете не так. Другая крайность – пытаться всё сделать идеально с первого раза, а так как это невозможно для сколь-нибудь нетривиальной задачи, то можно войти в ступор. Описанные ниже идеи могут помочь в этих случаях, дав некоторый критерий того, что уже можно писать код, так как понимания достаточно. Или того, что уже нужно писать код, так как понимания достаточно и дальнейшее промедление — это прокрастинация в чистом виде или саботаж.
Привет, Хабр! На связи руководитель проектов редакции компьютерной литературы издательства «БХВ» @Holmogorov. C 15 по 19 октября во Франкфурте проходило, пожалуй, самое известное мероприятие, которое каждый год собирает сотни тысяч читателей и тысячи книгоиздателей со всего мира. Речь идет о международной книжной ярмарке, известной под названием [Frankfurt Book Fair](https://en.wikipedia.org/wiki/Frankfurt\_Book\_Fair), или, на языке организаторов, Frankfurter Buchmesse. Несмотря на сложную международную обстановку и объективные трудности, превращающие получение европейских виз в увлекательный квест, мы побывали на этой выставке, чтобы оставаться в курсе последних тенденций на рынке компьютерной и технической литературы. О том, что мы там увидели и услышали, мы хотим вам сегодня рассказать.
Представьте: в одном углу опенспейса — молчаливый архитектор, который рисует новую схему взаимодействия микросервисов. Рядом — дотошный QA-инженер, который на код-ревью проверяет не только логику, но и нейминг переменных. Его сосед — бэкенд-разработчик, который одной уместной шуткой снимает напряжение перед дедлайном. А по коридору несётся энергичный тимлид с криком «Ребята, я придумал, как ускорить деплой!». Это не сцена из сериала «Кремниевая долина» — это ваша команда разработки, если посмотреть на неё через призму теории Белбина.