Структура дорожной карты, гайд по скрамбану, аналоги джиры, диаграмма Венна, убивающий таск-трекер, работа с синдромом самозванца, как понять, что хочет заказчик, и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
В прошлом квартале я внедрил Microsoft Copilot для 4000 сотрудников.
$30 за место в месяц.
$1,4 миллиона в год.
Я назвал это "цифровой трансформацией".
Совету директоров понравилась эта формулировка.
Они одобрили за одиннадцать минут.
Никто не спросил, что это вообще будет делать.
Включая меня.
Я всем говорил, что это "увеличит продуктивность в 10 раз".
Это не реальная цифра.
Но звучит как реальная.
HR спросил, как мы будем измерять это увеличение в 10 раз.
Я сказал, что мы "задействуем аналитические дашборды".
Вопросы прекратились.
Три месяца спустя я проверил отчёты по использованию.
47 человек открывали его.
12 использовали больше одного раза.
Один из них — это я.
Я использовал его, чтобы пересказать письмо, которое мог прочитать за 30 секунд.
Это заняло 45 секунд.
Плюс время на исправление галлюцинаций.
Но я назвал это "успешным пилотом".
Успех означает, что пилот не провалился явно.
Финдир спросил про ROI.
Я показал ему график.
График шёл вверх и вправо.
Он измерял "AI-enablement".
Я эту метрику придумал.
Он одобрительно кивнул.
Теперь мы "AI-enabled".
Я не знаю, что это значит.
Но это есть в нашей инвесторской презентации.
Старший разработчик спросил, почему мы не используем Claude или ChatGPT.
Я сказал, что нам нужна "энтерпрайз-безопасность".
Он спросил, что это значит.
Я сказал "комплаенс".
Он спросил, какой именно комплаенс.
Я сказал "все виды".
Он выглядел скептически.
Я назначил ему "встречу по развитию карьеры".
Вопросы прекратились.
Microsoft прислала команду для кейс-стади.
Они хотели представить нас как историю успеха.
Большие компании нацелены на Процесс и совершенно не работают на Результат, это их и губит.
1.Специфика больших компаний.
Всем известна фраза: «Слишком большие, чтобы разориться». Но слишком быстрые изменения мира и рынка могут свести на нет те преимущества, что казались раньше абсолютными.
Неоспоримое преимущество - размер и финансовая подушка может иметь для больших компаний обратный эффект, то есть сделать их неконкурентоспособными на рынке. Такое становится возможным из-за специфики их корпоративной культуры.
Основная проблема больших компаний, которая в конечном итоге может их погубить – это чрезмерная увлечённость процессами, так, что результат теряется из виду. Конечно, регламенты и политика - это именно то, что делает компанию уникальной и выделяет ее на рынке, для клиентов в том числе. Но когда регламенты становятся важнее результата, то это приводит к потере эффективности, к финансовой и креативной деградации.
Всем привет! Меня зовут Артем — за последние 10 лет поработал в больших компаниях, стартапах, консалтинге на позиции продакта и проджекта. Сегодня расскажу про мой подход работы с бизнесом и технической командой и про то, как превратить хаотичный поток задач в предсказуемый фреймворк.
В моей профессии Roadmap — ключевой артефакт. И при правильном формировании он способен выводить продукты из хаоса в предсказуемость. Дорожная карта не про сроки, а про баланс интересов — прикладная часть этого тезиса как раз и будет раскрыта в статье ниже.
Поработав в разных доменных областях я видел десятки команд, которые работали в постоянном пожаре. И везде проблема была одна и та же: никто не понимал, что мы делаем завтра и почему именно это.
Тогда я пришел к фреймворку «Квотирование» — методу, который делает дорожную карту предсказуемой в любой среде: в стартапе, enterprise, консалтинге.
Лучше всего, перед формированием дорожной карты использовать RICE для расстановки приоритетов, а только потом положить задачи на дорожную карту.
Привет, Хабр! Я Артём Клещев, технический писатель в СберТехе. Я пишу документацию к продукту Platform V DropApp — решению для управления контейнерными приложениями. Наша команда работает в парадигме Docs-as-Code.
Мы столкнулись с проблемой: при каждом изменении продукта нам нужно было менять документацию сразу в нескольких репозиториях — для каждого исполнения продукта. Но мы нашли решение, как оптимизировать процесс. И хотим поделиться рекомендациями по ведению единого источника в Docs-as-Code — будет полезно тем, кто хочет шаблонизировать документацию и сэкономить время для творческих задач.
В статье покажу, как построить удобную архитектуру репозитория продукта с применением шаблонов и MyST-разметки в парадигме Docs-as-Code. Расскажу, как вместо поддержки нескольких разрозненных комплектов документации создать библиотеку шаблонов с общим контентом. Надеюсь, что опыт нашей команды поможет вам избежать ошибок и лишних шагов.
Я программист 1С с 18 летним опытом работы с 1С:Предприятие и общим опытом коммерческого программирования 22 года.
С начала января 2025 года я перешел на парадигму работы "AI first" с полным созданием всего необходимого посредством ИИ кодинга.
Мне понадобилось более полугода, чтобы разработать и протестировать на реальных рабочих задачах пайплайн работы с нейросетями, учитывающий особенности разработки под 1С. После чего я начал делиться накопленным опытом с коллегами, и собирать от них обратную связь о их нейросетевом опыте работы с 1С.
Эта статья - текущее подведение итогов от меня и порядка пятидесяти коллег.
Итак, что на сегодня, 12 декабря 2025 года, нейросети делают полезного для 1Сников (программистов и аналитиков)?
Вопрос выбора системы управления продуктовой командой перестал быть теоретическим упражнением. Jira больше не обновляется, техподдержка молчит, а требования к импортозамещению никуда не делись.
Тысячи команд одновременно столкнулись с необходимостью искать альтернативу, причём желательно не методом научного тыка.
История с Jira — это не просто уход очередного западного вендора с российского рынка. Это идеальный шторм из трёх факторов, которые делают дальнейшее использование системы проблематичным даже для тех, кто готов работать на старых версиях.
Может показаться, что в современной разработке только и успеваешь, что реагировать на изменения: новые интеграции, обновленные бизнес-правила, смена технологического стека. В итоге команды тратят недели на задачи, которые должны решаться днями, а каждое новое требование встречается с сопротивлением. Но что если существует подход, который превращает постоянные изменения из головной боли в конкурентное преимущество? Сегодня мы поговорим о проектировании на основе нестабильности — архитектурной парадигме, которая позволяет системам становиться лучше с каждым изменением.
Бэкенд-разработка — устойчивое и востребованное направление в IT. Но с ростом в карьере растут и требования к разработчику — нужно знать языки и API до проектирования архитектуры, понимать распределённые системы, облака, DevOps-подходы и иметь софт-скиллы.
О том, что требует рынок на уровне джунов, мидлов и сеньоров, как прокачиваться на каждом этапе и выстраивать траекторию развития, — рассказываем в статье
Меня часто поражает, как технически грамотные люди спорят, есть ли у LLM интеллект или это всего лишь математические вычисления по определенному алгоритму без зачатков разума. И что самое интересное, иногда оппонентами в споре за наличие интеллекта у генеративных нейросетей выступают люди, которые таким образом рекламируют свое IT-решение, не понимая, что тем самым они только создают себе проблемы.
Ведь создавая рассуждающую иллюзию интеллекта, разработчики фактически ставят крест на возможности какого-либо реального применения подобных решений в серьезных задачах, так как имитация разума превращает потенциально полезный рабочий инструмент в игру на бубне без каких-либо гарантий качества и воспроизводимости полученных результатов.
В статье будет рассмотрена большая часть современных агентских IDE которые хоть кто то из знакомых и подписчиков использовал, а именно: Cursor, Kiro, Claude Code (Расширение), Roo Code, Kilo Code, Antigraviry, Cline, WindSurf, Continue, TRAE, Qode, Warp ADE, Zed
Для тех кто не любит читать итоговая табличка конечно же в начале:
В последнее время я читаю эссе Шона Гёдеке о том, что значит быть Staff+ engineer. Его статьи (в частности, Software engineering under the spotlight и It’s Not Your Codebase) абсолютно точны и кажутся до боли знакомым опытом для всех людей из «Big Tech».
Теоретически, я соответствую тем реалиям, которые он описывает: я Senior Staff engineer в Google. Тем не менее, его работы вызывают у меня тягостное чувство беспокойства. Сначала я списывал это на цинизм, однако, поразмыслив, я осознал, что проблема заключалась не в написанном Шоном, а моей интерпретации.
Шон не врёт: он точно описывает то, как жить в мире, где разработчики — это винтики в системе, а приоритеты меняются каждый квартал. Но моя работа не походит ни на что подобное, и глубоко внутри я понимаю, что если бы мне пришлось действовать в подобной среде или работать так, как он это описывает, то я бы выгорел в считанные месяцы.
Вместо этого я пошёл по другому пути, на котором упор делается не на внимание руководства, а на систему, и где ты не винтик, а несёшь ответственность.
Пока вы смотрите сериал, инженеры Иви обновляют код и готовят релизы. А DevRel-менеджер помогает им рассказывать об этой работе громко и интересно.
В статье рассказываем, почему его задача — не охота за кандидатами, а построение мостов между разработчиками и IT-сообществом.
Привет, Хабр! Я Владимир Вощук, CEO и основатель IT-компании и автор медиа «вАЙТИ». Наша компания прошла через несколько экономических спадов, и ключевой урок, который мы усвоили, заключается в следующем: сокращение бюджета — это не призыв к тотальному замораживанию всей деятельности, а необходимость в стратегическом перераспределении ресурсов. Сегодня я расскажу о системе, которая позволяет определить, какие проекты требуют немедленного «стоп-крана», а какие — «зеленого света».
Привет! Сегодня мы продолжаем разбирать требования, которые вспоминаются нам за день перед релизом.
Если функциональные требования отвечают на вопрос «что система делает?», то эти — на вопрос «насколько хорошо она это делает и сколько это стоит бизнесу». И именно их качество больше всего влияет на архитектуру и стоимость разработки.
В этот раз сосредоточимся на этой тройке: сопровождаемость, надежность и безопасность. Это те требования, которые незаметны пользователю, но определяют, будет ли система жить года или превратится в дорогое и опасное чудо техники.
Не переключайтесь!
В статье описываю практический опыт построения корпоративного ИИ‑ассистента: от структуры базы знаний и графовой модели до фильтрации контекста и контроля версий. Материал будет полезен продактам, архитекторам, маркетологам и всем, кто внедряет ИИ в бизнес‑процессы.
«Garbage in — garbage out», как мусор в корпоративной Базе Знаний мешает корректной работе ИИ и как мы предлагаем это исправить.
Сегодня многие компании внедряют ИИ‑агентов по упрощённому сценарию: загружают PDF‑регламенты, Excel‑прайсы и архивы переписок в векторную БД, после чего ожидают, что модель будет корректно отвечать на вопросы пользователей.
Такой подход, известный как Naive RAG, в большинстве случаев приводит к нестабильным результатам: несогласованные ответы, ошибки в тарифах, применение устаревших инструкций.
Причина — не в возможностях моделей: современные LLM хорошо работают с контекстом. Проблема — в структуре данных, которые подаются на вход. Если знания представлены в виде фрагментов без связей, версий и семантической целостности, то на выходе появляется то, что обычно называют «галлюцинациями».
Представьте, что вы спрашиваете банковского ассистента про банкоматы в Москве, а он присылает карту Саратова. Или ещё интереснее: официальный бот внезапно начинает отвечать русскоязычным клиентам на латинице.
Это весёлые будни ИТ в банке, где каждый релиз похож на русскую рулетку. Потому что есть один нюанс — у нас нет предпродовой среды. Вообще.
И пока эта проблема не решена, мы живём в очень интересном, мягко говоря, режиме.
В нормальном мире должны быть среда разработки, тестовая среда, нагрузочная среда и предпродовая среда. Мы это понимаем, но нас никто не слышит.
Мы выносили эту историю на общебанковские управляющие комитеты, стучались к руководству. Но руководство долгое время считало, что предпрод — это какая-то наша прихоть. Их логика проста: «А что? Всё же вроде нормально, ничего не падает... Ну вы же как-то справляетесь! На фига вам ещё какая-то среда?»
А правда — в том, что мы не особо справляемся. Точнее, мы вывозим, но исключительно на морально-волевых. Мы держим системы на плаву героическими усилиями команды, компенсируя отсутствие инфраструктуры своими нервами и овертаймами.
Задачи висят без исполнителей, сотрудники забывают про дедлайны и ещё 9 проблем, которые можно решить за пару минут.
Программное обеспечение прошло долгий путь от набора команд до комплексных софтверных человеко-технических систем. Небольшие программные разработки, призванные решать локальные задачи, постепенно превратились в набор приложений, далее появились программные системы, включающие организационную составляющую, а позже – информационные системы как совокупность человека, техники и программных продуктов. Логическую последовательность завершили корпоративные информационные системы, объединившие в себе множество информационных систем [1].
Корпоративные информационные системы позволяют автоматизировать набор бизнес-процессов. Чем больше процессов, тем представительнее стандарт, цифровизирующий их. Так наиболее известным и востребованным классом систем является ERP [2]. ERP-системы охватывают практические все административно-хозяйственные операции компании и представляют средства для их автоматизации. Помимо ERP доступен широкий набор прочих классов: MRP, TMS, WMS, APS, BI, MES и др. Если раньше идея объединить все стандарты в единый класс казалась обоснованной, то на текущий момент – это утопия, так как слишком стремительно развиваются технологии и появляются новые виды систем.
Потребность в управлении различными классами программных систем, являющихся основой функционирования современного предприятия, становится все более востребованной и незаменимой: достижение стратегических целей компании тесно связано с вопросом цифровизации бизнес-процессов. Среди множества сводов знаний, применимых к информационным системам: PMBoK, BABoK, BPM CBoK, DAMA-DMBoK, EABoK/TOGAF, SWEBoK, ITIL [3-9], последние два являются наиболее релевантными тематике данной статьи. Свод знаний по программной инженерии, SWEBoK, охватывает весь жизненный цикл информационной системы, в то время как лучшие практики по управлению ИТ-услугами, заданные в ITIL, не ограничиваются рассмотрением только софтверных решений, а представляют все многообразие ИТ-продуктов.
Каждую пару лет кто-нибудь замечает, что крупные технологические компании иногда пишут на удивление мусорный код. Если вы не работали в большой компании, то вам может быть сложно понять, почему это происходит. Уровень зарплат в крупных технологических компаниях позволяет привлекать многих компетентных разработчиков. Они работают довольно неспешно, поэтому создаётся впечатление, что у них достаточно времени, чтобы выполнять работу качественно. Как же появляется плохой код?
