Управление разработкой *

Я возглавляю стрим Компьют (Вычислительные Ресурсы, говоря проще) в быстрорастущем облачном провайдере с осени 2024 года. Мы (и стрим Сетей) отвечаем на облачные примитивы, на которых строятся буквально все другие облачные продукты. За это время стрим столкнулся с настоящими вызовами, некоторые процессы пришлось выстраивать.

Когда первый раз мне HR`ы сообщили, что наш оффер принят, я столкнулся с тем, что хоть про онбординг‑адаптацию и говорят, конкретных гайдов и статей нет. На мысль о том, что «что‑то надо с этим делать» меня натолкнула коллега с другого направления, которая постоянно жаловалась на трудности адаптации и отсутствие информации. У нас, конечно, информации было достаточно в конфлюенсе, но, она не была структурирована для быстрого погружения нового сотрудника. Это был тревожный звоночек. Мы тратили месяцы на сложный технический отбор (воронка в 2-3% от кандидатов), находили сильных специалистов, а затем рисковали потерять их в первые же недели из‑за некачественных процессов и информационного голода.

Я исходил из простой мысли: высокий порог входа в наш продукт — данность. Облака, Kotlin, сложная кодовая база — от этого никуда не деться. Значит, нельзя позволить, чтобы к ней добавился хаос в процессах. А задача лида — построить чёткий маршрут, по которому новичок сможет комфортно присоединиться к проекту.

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

3 часа ночи. Звонок от незнакомого номера. «Пользователи не могут залогиниться, п****ц».

Вы лихорадочно листаете Slack. Непонятно, где проблема и кого будить. Подняли тестеров — они тоже гадают. Бэкенд? Инфра?

Идёте во флудилку в телеге, ищете похожий ник тимлида. Не отвечает. Кто замещает — никто не знает. Начинается массовый обзвон. Через 40 минут находится человек. Смотрит код. «Не моё. Это к Сане — он, кажется, редирект криво поменял в гугл клауд консоли». Ещё 20 минут — поиск Сани, доступы только у него.

Утром все разбитые. CTO вопрошает. И становится ясно: баг простой. Проблема не в коде. Проблема в бардаке.

Знакомо? Я тоже через это прошел. И после такой ночи решил: хватит. Нужна система.

Вы когда-нибудь как разработчик хотели официально на работе заниматься тем чем хотите? Отменить все митинги и сосредоточиться на одной проблеме, которой хотел давно заняться, но не было времени? Попробовать новый фреймворк или покодить в свое удовольствие? Звучит заманчиво? В этой статье я хочу рассказать об Get Stuff Done Days (GSDD), которые позволяют разработчикам вырваться из рутины.

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

А именно, когда начинается новый чат в Claude, то там появляются такие подменюшки под окном для чата

Write - Learn - Code - Life Stuff - Claude’s Choice

Кликнул ради интереса последнюю, открылся ещё целый список. И он, кстати, все время меняется.

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

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

Многие думают, что большие компании не совершают ошибки. Но даже если у вас налажен процесс код‑ревью и всё тщательно проверяется, риск накосячить никогда не равен нулю. Хотя, конечно, всегда лучше учиться на чужих ошибках, чем на своих.

Меня зовут Юрий Беглецов, я технический продакт в Точка Банк. Мы с командой делаем универсальные API, чтобы клиенты могли интегрировать банк и дочерние сервисы прямо в свои системы. Иногда у нас тоже бывают провалы — обидные, серьёзные и даже забавные. Две истории из серии «никогда больше» — под катом.

Большинство из нас знает или слышало об управлении инцидентами и проблемами в ИТ и ИБ. Это фактически стало нормой, стандартом. Но как управляют инцидентами и проблемами в бизнес-функциях компании, в функциях отличных от ИТ или ИБ?

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

План проекта, фокус-фактор, управление бэклогом, гайды по канбану, НФТ, управление изменениями, неэффективная эффективность и всё интересное, что писали за последние 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.

Использование искусственного интеллекта – это один из ключевых факторов успеха при работе современных организаций. Но как реализовать его применение для решения конкретных задач внутри корпоративной инфраструктуры? В этой статье мы предлагаем вам подискутировать о том, какие условия необходимо выполнить для того, чтобы «корпоративный ИИ» работал стабильно, не галюцинировал, не нарушал правил ИБ и вообще стал помощником, а не еще одной проблемой.

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

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