Я собираю персональные системы в Obsidian на заказ. Перед работой с новым клиентом я раскладываю его работу на этапы и выписываю, где уходит время и пропадает информация. У продакт-менеджера я насчитал 78 таких мест. Ниже - система, с которой я бы начал, и четыре её узла в деталях, с настройками, которые можно повторить у себя.

Это демо-кейс: типовой каркас профессии. Продукт, пользователи, цифры и конкуренты в примерах вымышлены.

Obsidian - программа для заметок, которая хранит всё в обычных текстовых файлах на вашем диске. Заметки связываются ссылками, а плагины добавляют таблицы, канбаны, графики, кнопки и шаблоны.

Для описания архитектуры важно выбрать подход, который будет понятен всей команде. Одним из них является нотация C4, разработанная Саймоном Брауном.

Данная статья — это продолжение и значительное дополнение моей предыдущей статьи по C4, опубликованной в 2023 году. Здесь я детально разобрала для вас каждый уровень и элемент нотации, распространённые ошибки и спорные вопросы, а также инструменты для создания диаграмм, в частности графический редактор Draw.io и Structurizr для создания C4 через код.

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

Статья будет полезна системным и бизнес-аналитикам, архитекторам, разработчикам, менеджерам проектов и всем, кто участвует в проектировании архитектуры систем.

Всем привет! Меня зовут Павел, я Head of Development в Банки.ру. Сегодня хочу погрузиться с вами в, кажется, уже давно заезженные темы: Single sign-on, OAuth, OpenID и нюансы их реализации. 

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

Я решил восполнить этот пробел и подготовил именно такой материал.
В этой статье погрузимся в теоретическую часть и рассмотрим: 

– основные Flow OAuth 2.0 и отдельно Authorization Code Flow with Proof Key for Code Exchange;
– OpenID Connect (OIDC);
– Single Sign-On или SSO: схему реализации и применение SSO в мобильных и веб-приложениях.

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

Но если почитать, что сейчас происходит вокруг проектного управления, периодически начинают попадаться идеи, скажем так, нетривиальные. Мне стало интересно собрать такие идеи в одном месте и посмотреть, не складываются ли они во что‑нибудь общее (я ж аналитик). Сразу оговорюсь, что далеко не все концепции из списка супер‑свежие, но именно в последние пару лет либо получили новое развитие, либо начали появляться в вполне серьезных исследованиях.

Если интересно, давайте пробежимся по верхам.

Лет десять я пытался привести свои дела в порядок и всё это время наступал на одни и те же грабли. Заводил борды с задачами в Notion, они бодро наполнялись первые пару недель, потом помирали, а разгребать мёртвый борд руками настолько больно, что туда перестаёшь заходить. Складывал поток сознания в заметки, в них удобно записывать, но найти нужное потом всегда проблематично. Писал в Saved Messages в Телеге. Лучшее место, чтобы выгрузить голову за десять секунд, и худшее, чтобы через неделю там что-то отыскать.

Общее у всех попыток было одно: фиксация есть, разбора нет, а потом всё молча умирает под собственным грузом накопленных дел.

Ответ, почему так происходит, я нашёл у Стивена Кови. Его книгу «7 навыков высокоэффективных людей» я прочитал давным-давно и с тех пор являюсь её амбассадором, но у Кови есть и отдельная книга про планирование, «Главное внимание главным вещам». Там он раскладывает все подходы к организации дел на четыре поколения.

В этой статье расскажем, как сделали поиск по внутренней документации в таск-трекере и корпоративной wiki на порядок быстрее, не написав ни единой строчки кода бэкенда

В моём таск-менеджере сейчас больше пятидесяти пунктов, которые начинаются не с «сделать», а с «получить от…».

Документы от заказчиков, результаты от разработчиков, поручения трём личным ассистентам и даже путеводитель от девушки – всё это нужно не выполнять самому, а вовремя проверять и напоминать. Обычная колонка «Ожидаю» перестала справляться, когда ожиданий стало слишком много.

Рассказываю, как я перестроил личную GTD-систему: отделил срок результата от даты следующего контроля, связал Trello с календарями, не стал дублировать GitLab и сохранил одну точку ответственности в иерархии ассистентов.

Мы разрабатываем CV-системы (машинное зрение для производств). А ещё мы принимаем на поддержку решения, которые для нас делают подрядчики. Подрядчики присылают нам документацию, и дальше начинается бюрократический ад.

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

Это непохоже на ревью кода. Это похоже на рутинный чек-лист потому, что есть все разделы, есть все базовые критерии, числа друг другу не противоречат и так далее. И это должны делать очень дорогие специалисты — вместо реальных задач.

Количество итераций проверки одного документа — от 2 до 5. Серьёзно. Формулировки бывают настолько запутанными, что приходится писать кучу уточняющих вопросов.

Ещё есть ТЗ на разметку, там вообще становится понятно, почему Скайнет восстал. Например, надо обвести все надписи на вагоне. А если там мелом написано ХУZ, это должно попасть в распознавание? И вот инженеры сидят и принимают такие решения по каждой мелочи. 

Заставлять инженера, который может писать сложнейшие алгоритмы, по три дня вычитывать по шаблону один и тот же документ — это жестокая история. Правда, очень важная. Просто ничего не делать — не получится.

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

Каждый раз, когда в компании возникают проблемы с производительностью PostgreSQL, обсуждение обычно идет по одному и тому же сценарию.

Сначала DBA оптимизируют запросы. Потом появляются новые индексы. Потом увеличивается размер серверов. Затем появляются реплики. Потом еще реплики. И через некоторое время выясняется, что значительная часть бюджета на инфраструктуру уходит на обслуживание системы, которая изначально должна была просто хранить данные.

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

MS Project в 2026 году превратился в токсичный актив: блокировки, замороженные лицензии, серые схемы оплаты. Но прежде чем бежать, честно: если лицензия бессрочная и проекты не выходят за периметр, можно не дёргаться. А если риски перевесили привычку, разбираем 10 аналогов по классам задач (PPM, SDLC, трекеры), с реальной ценой миграции .mpp и честными минусами каждого, включая наш.

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

Итак мы обсудили задачу классификации и метрики качества классификационных моделей.

Имея такой набор знаний, мы наконец готовы перейти к моделям, которые, в отличие от kNN, действительно обучаются на данных, а не просто запоминают обучающую выборку.

И первый кандидат у нас логистическая регрессия

В фольклоре разработчиков встречаются утверждения о том, что Jira (система управления проектами, разработанная Atlassian) полна по Тьюрингу. Однако в таких заявлениях нет конкретики, лишь смутные упоминания фич автоматизации. В этой статье будет приведено доказательство с инструкциями по реализации и трассировкой исполнения.

Привет, Хабр! С вами Евгений Соловьев. Сегодня представляю вашему вниманию очередную историческую статью по мотивам моей книги «Платежные системы — вчера, сегодня и… завтра?».

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

Почему одни User Story работают как часы, а другие становятся источником бесконечных багов и ночных звонков? За годы работы в FinTech собрал коллекцию типичных ошибок, из‑за которых команды теряют драгоценное время. В статье — живые кейсы, наглядные диаграммы, разбор INVEST и практики Three Amigos, которые снижают число дефектов. Рассмотрим, как превратить сырую идею в зрелую User Story с чёткими критериями приёмки и нефункциональными требованиями.

Если вы читаете эту статью, значит, вы являетесь участником современного Интернета. Интернет, с которым мы сталкиваемся сегодня, значительно отличается от того, каким он был всего 10 лет назад. Как развивался веб, и, что более важно, куда он движется дальше? И почему все это очень важно?

Если история нас чему-то научила, то эти изменения будут иметь большое значение в будущем.

В этой статье я расскажу о том, как развивался интернет, куда он движется дальше и почему это важно понимать.

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

Можно ли при идеальном коде и защищённой инфраструктуре иметь серьёзные проблемы в безопасности продукта? Защитят ли нас полностью современные средства инфраструктурной защиты, анализа кода? А что, если нет? Давайте подумаем об этом на отвлечённых примерах из практики.

Привет, Хабр! Меня зовут Игорь Игнатьев, я директор департамента защиты приложений в VK. Сегодня расскажу о подходе к построению безопасных продуктов, и это будет моя первая статья из цикла про принципы Secure by Design.

Собрал детальный RoadMap навыков Продакт менеджера, который покрывает путь от входа в профессию до уровня CPO.

При составлении роадмапа опирался на свой опыт работы CPO в ProductStar и Lead Product в Т-Банке, анализ вакансий на рынке, а также на опыт менторства 500+ продактов и руководителей продуктовых команд.

⭐️ Что внутри:
• Обзор задач, опыта и зарплаты Продактов каждого грейда
• Подробный ликбез по всем навыкам Продакт менеджера
• Инструменты, необходимые Продактам
• Полезные материалы для поиска работы и развития карьеры

Привет! Меня зовут Андрей Романюк, я руковожу группой качества в онлайн-кинотеатре Okko. В прошлой статье я рассказывал о том, как мы начали взвешивать баги, сам подход к этому взвешиванию, и о том, что это помогло нам сократить количество заранее известных багов, которые мы выкатываем в прод.

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