План проекта, фокус-фактор, управление бэклогом, гайды по канбану, НФТ, управление изменениями, неэффективная эффективность и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Мой путь в IT начался в 2007-м. Тогда мир ломался: появился первый iPhone, соцсети обещали демократию, а я, верил, что код - это новая латынь, универсальный язык силы. Я ошибался. Код был лишь алфавитом. Настоящая сила заключалась в том, чтобы заставить этот код писать, продавать и нести за него ответственность других людей.
В статье приведен результат опроса сообщества 1С разработчиков на предмет применения ИИ в своей текущей деятельности.
На конец 2025 года был проведен опрос сообщества на предмет использования ИИ. Цель — понять какие технологии\модели\подходы\практики обрели популярность.
Какие технологии «прижились» среди 1С разработчиков, а какие пока воспринимаются с опаской. Так получилось, что моя деятельность во многом связана с продвижением ИИ в среде 1С. Так вот, главный интерес заключается в том что получилось а что нет. А может некоторые практики и технологии упущены.
Также достаточно интересно с какой стороны и кто занимается внедрением практик работы с ИИ в компаниях. «Снизу» или «сверху».
Поэтому аудиторию, пожалуй, нельзя считать среднестатистической, хоть попытки и были.
В этой заметке описана концепция организации производства ПО «Merge Request как транзакция изменения системы, и где в ней возникает eventual consistency». Описывается идея, что МР должен содержать полный список изменений по каждой таске, какие плюсы и минусы этой концепции свойственны а также как её внедрять.
В этом обзоре — 8 таск-трекеров с низким порогом входа и оптимальной функциональностью для ведения проектов. В начале списка — самые интуитивные, ближе к концу — те, где нужно чуть больше времени на освоение интерфейса и логики.
Сохраняйте — пригодится, если в новом году нужно быстро навести порядок в задачах.
Архитектурное ревью в разработке ПО часто выглядит как ритуал: собираемся, смотрим диаграммы, соглашаемся с идеей «надо бы подумать про масштабирование», расходимся — и через пару месяцев ловим те же грабли, только дороже. В этой статье разбираем, как превратить ревью из формальности в инструмент, который реально снижает риски: что именно проверять (и в каком порядке), как задавать вопросы так, чтобы вскрывались допущения и скрытые зависимости, как фиксировать решения, и где проходит граница между «всё переписать» и «достаточно подкрутить одну гайку».
Когда я был разработчиком, мне казалось, что оценивать задачи просто. Я знал код, понимал проект и верил, что 40-часовая неделя — надёжная рамка, в которую помещается всё нужное.
Реальность быстро показала обратное. В каждом спринте оставались незакрытые задачи, сроки сдвигались, а чувство «я где-то ошибся» становилось постоянным фоном — даже если работал честно и много.
Мы пробовали увеличивать оценки, переходить на стори-поинты, но бизнесу всё равно нужны конкретные даты. И если вы называете срок, от него зависят планы других команд — просрочка превращается не просто в накладку, а в риск.
Со временем мои оценки стали точнее. Но став тимлидом, я понял простую вещь: проблема не в людях и не в оценках.
Проблема — в самой модели планирования. Мы пытаемся работать внутри недели, которой в реальности не существует. Давайте разберёмся, почему планы продолжают срываться, даже если команда работает добросовестно и что с этим делать.
Чем хорош малый бизнес, особенно на своем старте? Ему не нужны сложные инструменты: он в состоянии увидеть состояние дел расчетами «на коленке», а план действий уместить карандашом на трамвайном билетике.
А когда бизнес подрастает? Скажем, его месячная выручка становится 100М+, количество сотрудников исчисляется сотнями, а бизнес-процессы усложняются настолько, что перестают быть прозрачными, покрываются «туманом войны».
Эта история про то, как инструмент, понравившийся команде на старте бизнеса, довел её до убытков в десятки миллионов при росте оборотов, когда компания стала крупнее. И как прозрачность вернула контроль и разблокировала рост выручки на 50%.
Мои рассуждения про будущее web‑разработки — не в абстрактном смысле «что будет с React или с PHP», а в очень прикладном контексте: проектная разработка клиентских сайтов для веб‑студий и digital‑агентств.
Главный тезис, который я вижу всё отчётливее: ИИ делает дешёвым «сделать», но дорогим «поддерживать и не ломать». И именно поэтому ценность архитектурной ясности, доменных инвариантов и проверяемых контрактов будет расти, а не исчезать.
Я Олег Одинцов, платформенный инженер App.Farm. App.Farm — собственная разработка Россельхозбанка, которая используется для стандартизации процессов разработки программного обеспечения и предоставления высокоуровневого интерфейса пользователям для автоматизации их задач. Можно сказать, что App.Farm — это автоматизация «под ключ». Пользователь получает полный цикл управления разработкой от размещения кода до деплоя приложений. Более «смузийное» название — IDP платформа.
Периодически слышу, как мне говорят: «В Jira неудобно управлять бэклогом, стандартный список задач мне не нравится». Дело доходит даже до выписывания задач в Excel. Тогда зачем нам таск-трекер?
Сегодня попробую рассказать о решении, которым сам пользуюсь, а именно про применение Structure.
Использование искусственного интеллекта – это один из ключевых факторов успеха при работе современных организаций. Но как реализовать его применение для решения конкретных задач внутри корпоративной инфраструктуры? В этой статье мы предлагаем вам подискутировать о том, какие условия необходимо выполнить для того, чтобы «корпоративный ИИ» работал стабильно, не галюцинировал, не нарушал правил ИБ и вообще стал помощником, а не еще одной проблемой.
Нестабильность – это часть нашей жизни, и, конечно, невозможно избежать нестабильности в вопросах разработки. В современном, постоянно меняющемся мире непрерывно что-то происходит: новые требования закона, новые бизнес-процессы, новые библиотеки и интерфейсы. В этой статье я разбираю принципы проектирования ПО на основе нестабильности. Всех, кто устал переделывать компоненты, а также тех, кто уже научился не переделывать лишнее, приглашаю поговорить про принцип обратных зависимостей, оси нестабильности и принципы архитектурной устойчивости проекта.
Эта статья является продолжением моей первой публикации, в которой я уже рассказывал о функциональном хаосе и поиске архитектурной устойчивости. Прочитать ее можно здесь. Сегодня же мы рассмотрим вопрос с более практической стороны и начнем с более гибкого архитектурного принципа.
Привет, меня зовут Анатолий, я ведущий разработчик в ITFB Group. Наш ключевой микросервис со временем превратился в настоящего монстра. Разросшийся, медленный и перегруженный лишними функциями, он тормозил весь продукт и усложнял жизнь разработчикам. Любая правка превращалась в квест: чтобы внести изменение в одном месте, приходилось разбираться ещё в десятке несвязанных процессов.
Мы решили провести «хирургическую операцию»: за один месяц силами выделенной команды из 10 человек полностью расчистить сервис, вынести из него 40 процессов и вернуть архитектуре прозрачность. В этой статье я расскажу, как мы поставили диагноз, спланировали операцию и справились с самыми болезненными моментами — от войны с конфигами до разрыва общих DTO.
Главный спойлер: результат превзошёл ожидания. Сервис стал быстрее, команды — автономнее, а система наконец-то обрела масштабируемость.
Описание методики фунпацу для достижения максимально высокой личной продуктивности.
Текст содержит подробное описание мотивов для использования техники и самой технику. Написано живым языком и основывается на опыте автора.
Наверняка вы сталкивались с проблемой согласования фичи со службой безопасности. В большинстве случаев этот процесс превращается в головную боль для программиста из-за множества непонятных этапов и деталей.
Регулярно встречая подобные проблемы в своей работе, мы во Flowwow решили внедрить процесс, который помог не только снизить на треть количество времени на анализ корневых причин сложных инцидентов, но и значительно упростить согласование фич для программистов. Этот процесс получил кодовое название ADR.
Open source даёт многое: творчество, свободу идей, среду для роста и обучения. А ещё снижает барьеры в науке, образовании и разработке и создаёт реально крутые и полезные продукты, инструменты и сервисы.
В рамках программы «Код без границ» российские разработчики показали, что открытый код сегодня — это квантовое программирование для управления производством, GraphRAG-движки нового поколения, ИИ для науки и образования, операционные системы для паяльного оборудования и много других инновационных проектов с реальным применением.
Пришло время подвести итоги — давайте узнаем, кто победил в грантовой программе, выбор был непростой!
Рано или поздно, если вы стали сеньором, наступает момент, когда вас просят помочь с адаптацией нового сотрудника. Сначала это выглядит как разовая просьба: показать проект, объяснить пару технических нюансов, ответить на вопросы. Потом в команде появляется ещё один новичок. Потом ещё. И в какой-то момент вы вдруг ловите себя на мысли, что ваша роль в проекте незаметно изменилась — вы больше не просто «тот, кто хорошо разбирается в коде», вы стали ментором.
В середине года появилась адекватная метрика от Яндекса: она позволяла анализировать трафик и принимать решения о дальнейшем развитии направлений портала.
Пришло осознание, нашими пользователя являются люди практически со всего мира, метрика показывала пользователей из 133 стран, 50% трафика приходилось на Россию, остальные 50% на остальной мир.
Некоторые из них известны, некоторые - довольно узкоспециальные, но ВСЕ они очень полезны инженерам-разработчикам и проектным менеджерам.
Интересно, сколько из этих законов будут для вас новыми?
