Почему гибкость важнее догмы в Agile и управлении проектами

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

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

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

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

Привет, Хабр. Меня зовут Александр Шеломанов, я менеджер продукта в Uzum Market. Отвечаю за развитие экосистемных стримов — направлений, которые связывают сервисы компании и помогают им работать как единое целое.
В своей статье расскажу, как мы превратили сервис рассрочек в массовый инструмент для покупок и усилили экосистему за счет офлайн-точек и персонализированных предложений. Причем все это в условиях молодого, быстрорастущего рынка, где пользовательские привычки только начинают складываться.

Всем привет! Меня зовут Артём Матюшечкин, я менеджер разработки из команды Толк.ИИ в продукте Контур.Толк — это сервис видеоконференцсвязи для общения и работы. Наша команда сделала суммаризацию, обновила и ускорила сегментацию виртуальных фонов, внедрила шумоподавление в продукт. В этой статье поделюсь опытом управления такой командой, которая пыталась одновременно уместить в себе требования бизнеса и технологий.

Хабр, привет!
В 2024 году мы запустили в «Инфосистемы Джет» программу менторинга для развития сотрудников — без внешних консультантов и больших бюджетов, по инициативе сотрудников, а не «сверху». С тех пор успели масштабировать её на всю компанию, запустив два потока, и даже выиграть премию от Национальной Федерации Профессиональных менторов и коучей (НФПМК) в сфере корпоративного менторинга.
В статье поделюсь честным опытом создания менторской программы с подробностями о каждом этапе запуска. Расскажу не только о первых результатах и успехах, но и о подводных камнях: что получилось не сразу, и какие выводы мы сделали. Также дам практические советы тем, кто думает о запуске такой инициативы в своей организации.

Продолжение статьи о разработке B2B платформы международной торговли
Прошло несколько месяцев с момента публикации первой части, где мы рассказали о концепции и начальном этапе разработки LiqTrade. За это время проект прошел путь от MVP до полноценной production‑ready платформы.
В этой статье я хочу поделиться реальными проблемами, с которыми мы столкнулись, и способами их решения. Никакого идеализированного «как всё прекрасно работает» — только честный разбор косяков, рефакторинга и технического долга.
Дисклеймер: Если вы ищете статью в стиле «10 строк кода, и ваш стартап взлетел» — это не здесь. Здесь будет про то, как мы 3 раза переписывали систему ролей, боролись с circular dependencies и почему наш bundle вырос до 1.2 МБ (спойлер: мы его победили).
Самая популярная для обсуждения тема в бизнес-сообществе России – это недостаток трудовых ресурсов. Все сошлись в едином мнении, что работать некому, а те, кто готов работать, требуют совершенно неадекватную оплату труда.
Именно поэтому мне стало интересно разобраться в этой ситуации, понять, насколько эта ситуация реально существует, и какие варианты решения этой проблемы возможны для бизнеса.
Начнем с самого начала, с того, что в России снижается рождаемость и, следовательно, и бытует мнение, что ее нужно срочно как-то стимулировать. Именно тут кроется первая ошибка, которая при значительной трате ресурсов государства, никогда не принесет результат.
Тем, кто закончил школу и изучал экономическую географию, должен быть известен такой термин как «второй демографический переход», который происходит во всех странах мира, где женщины (а именно они являются инструментом и фактором увеличения населения, количество мужчин для демографии большого значения не имеет) получают образование и начинают быть полноценными членами общества. Они уже не участвуют в деторождении с 16 лет, как это происходит в отсталых аграрных обществах первого демографического перехода.
В связи с этим важно принять тот факт, что рождаемость в России никогда не будет как в условной Африке, а значит надо работать с этим фактом, а не пытаться тратить время и средства на поворот социальной парадигмы общества назад.
Итак, когда мы пониманием, что закрытие школ и ВУЗов для женщин не предвидится, а значит второй демографический переход в России необратим, то бизнесу необходимо научиться фокусироваться на том, на что он может повлиять, а не пытаться изменить уже исторически сложившееся явление.

С подключением, хабровчане! Меня зовут Роман Волков, я Senior DevOps в MТС Web Services. Кроме своей основной деятельности в роли инженера, я провожу собеседования и всегда задаю вопросы кандидатам о том, как они видят пользу, которую их роль приносит бизнесу, как могут оценить свою деятельность, какой у них метод ведения работы. Как многие, я читаю профильные чаты, тематические ресурсы. И... кажется, в ИТ‑сообществе до сих пор бытует мнение, что DevOps и SRE — это следующие этапы развития системного администратора.
Это наблюдение подтверждают и открытые вакансии: практически каждая дает список используемых технологий и бонусов для будущего кандидата, но не раскрывает специфику работы. Если бизнес не транслирует пользу от вакансии — сотрудники подбираются исходя из используемой технологии. А ведь есть разница в том, чтобы, например, администрировать Kubernetes, разворачивать полезную нагрузку в Kubernetes или обеспечивать высокую доступность приложению, развернутому в Kubernetes.
Ситуацию можно сравнить с подбором стоматолога по навыку работы специалиста с бормашиной. В такой клинике у вас высокий шанс попасть как к ювелиру, так и к мастеру маникюра.

Кажется, что РЖД — это такой «вечный двигатель», вне кризиса и перемен.
Годы шли, и железная дорога жила «по контракту»: вози, обновляй, оптимизируй, мониторь, не ломай то, что работает. Но последние пару лет даже у этого монолита начались сбои: индустрия в кризисе, инфраструктура в дудосе от избытка вагонов, ключевые узлы перегружены. Выясняется, что даже у вечной системы есть точки отказа, и иногда их становится опасно много.
Попробуем разобраться, как одна из крупнейших корпораций в стране докатилась до сегодняшней турбулентности. Постараемся максимально избежать скучной статистики (один график я все-таки вставил, не удержался, но только один) и применим системный подход, чтобы понять, как ошибочные решения менеджмента, принятые почти два десятилетия назад, могут подрубить ноги колоссу сегодня и почему важно понимать архитектуру отраслевых гигантов не только сквозь призму их побед и отчётов, но и через цепочку допущенных ошибок, удачных (или неудачных) экспериментов и долгосрочных последствий управленческих ходов.

Представьте, что вы лидер молодого, но быстрорастущего стартапа в области ML. Вам предстоит собрать команду, и вы думаете о том, каких специалистов вам предстоит найти:
- Data Scientist — для создания прототипов моделей машинного обучения, подходящих по задачи вашего проекта;
- ML Engineer — для внедрения в эксплуатацию моделей и сценариев, масштабирования;
- Data Engineer — для создания ETL‑процессов, систематизации сбора и хранения данных;
- DevOps/MLOps — для автоматизации процессов и развития инфраструктуры;
- SRE — для обеспечения мониторинга и надёжности вашей инфраструктуры.
Организовать работу всех направлений с нуля будет задачей не из лёгких. Но как принять этот вызов, если вы не обладаете экспертизой во всех направлениях?

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

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

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

Чтоб сделать, чтобы базой знаний реально пользовались? Один из путей — дать возможность и наполнения, и получения ответов в привычном интерфейсе, без захода в дополнительные приложения.

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

Последние два года я руковожу компанией, специализирующейся на контрактной разработке механических и мехатронных компонентов. Мы работаем с оборудованием для медицины, ветеринарии и неразрушающего контроля, а также производим опытные образцы и малые партии.
Контрактная разработка и мелкосерийное производство требуют особого подхода: задачи здесь уникальны, а контроль за сроками и бюджетом требует особого внимания.
В этой статье я поделюсь опытом внедрения сквозной системы управления компанией, используя инструменты Kanban. Мы построили ее так, чтобы она была одновременно простой, гибкой и масштабируемой.
Коллеги, недавно я задумался о пользе коммуникаций в проекте. Очевидно, что любой проект, кроме разве что совсем домашних pet-проектов, подразумевает взаимодействие с командой, коллегами, заказчиком, регуляторами – да с кем угодно. И организация этого взаимодействия – обязанность менеджера проекта. Но всегда ли составленный по всем правилам план коммуникаций действительно уместен? В каких случаях коммуникации только вредят?
Когда работаешь из дома, привычный маршрут сжимается от ноутбука до кухни. И любое публичное выступление превращается в событие: можно наконец выйти из квартиры, увидеть живых людей, почувствовать, что и сам не лыком шит. Плюс зарядиться и увлечь новых клиентов.
В этой статье разберём: где тренироваться, если вы ещё не выступали, как выбирать площадки и сколько на этом реально зарабатывают.

Или почему мы до сих пор работаем по разработкам управленца, которые должны были сделать труд эффективным, а сделали его невыносимым.
Заходите утром в Jira, Asana или Yandex Tracker. Перед вами — бесконечный список задач, раскрашенных в цвета приоритетов, разбитый на спринты и эпики. Каждое действие нужно залогировать, каждый комментарий — оставить в тикете, а каждую «помидорку» — учесть в тайм-трекере. Знакомое чувство легкой тоски, стыда за незакрытые задачи и раздражения от бесконечных уведомлений? Поздравляю, вы не одиноки. Это — синдром современного высококвалифицированного специалиста, которого пытаются загнать в систему, созданную для управления… заводскими рабочими начала XX века.