Привет! Меня зовут Анна, я архитектор Naumen Project Ruler. Я отвечаю за то, как устроена система: чтобы она соответствовала методологиям проектного управления, но при этом не оставалась «теорией из учебника». Мы проектируем Project Ruler достаточно гибким, чтобы он встраивался в реальные процессы разных компаний и учитывал разные подходы к управлению.

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

Первый вариант быстрее и проще — все готово, платишь и пользуешься. Правда, скорее всего придется пойти на компромиссы в привычных процессах, чтобы найти «общий знаменатель» между ними и возможностями решения. Кроме того, придется приготовиться к постоянным платежам за лицензии.

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

Привет! Меня зовут Дарья, я руковожу продуктом Naumen Project Ruler. Вместе с командой изучаю задачи пользователей и определяю, какие сценарии и возможности продукта нужно развивать, чтобы эти задачи решать.

На статус-митинге руководитель проекта оценил прогресс в 90%, все показатели в зеленой зоне. Команда движется отлично, все по плану. Через месяц все те же 90%. Показатели снова в норме, но почему процент не увеличился? Еще через месяц цифра по-прежнему не меняется. И вот, за две недели до дедлайна статус «краснеет», и выясняется, что до закрытия всех задач нужно не меньше квартала.

Знакомо? Что за магическое число — 90%, откуда оно берется и в какой момент отображает реальное состояние проекта? И в чем тут проблема: РП приукрасил статус, ошибка в планировании либо расчете прогресса? Попытаемся разобраться.

Привет! Меня зовут Игорь, я отвечаю за развитие Naumen Project Ruler. Много общаюсь с заказчиками, изучаю их задачи и практики проектного управления и вместе с командой определяю, куда продукт будет двигаться дальше.

Когда при реализации портфеля проектов выявляется дефицит ресурса исполнителей (на языке специалистов, «переподписка»), чаще всего говорят о некачественном планировании. По моему убеждению, в большинстве случаев дело не в этом. Руководители проектов прекрасно ориентируются в оценке того, сколько ресурсов потребуется для достижение целей. Так что, портфель с заведомым дефицитом согласовывается «с открытыми глазами». Причины — в человеческом и организационных факторах. Объясню подробнее, почему так происходит.

Привет, Хабр! Меня зовут Дима, я бизнес‑аналитик в команде внедрения Naumen. Большая часть моей работы — это коммуникация: с клиентами, разработчиками и коллегами внутри команды. Почти вся она происходит онлайн.

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

Со временем я собрал несколько правил, которые помогают сделать онлайн‑коммуникацию быстрее и не растягивать обычный рабочий вопрос на полдня.

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

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

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

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

В статье расскажу, как мы пришли к этому формату, почему первая попытка собирать идеи клиентов в Excel не сработала, как устроены наши QBR и что они изменили для всех участников.

Привет, Хабр! Меня зовут Кира, я бизнес‑аналитик клиентского сервиса ITSM 365 и куратор командной базы знаний.

Наш продукт развивается с каждым годом, и вместе с ним растет количество клиентских обращений: их становится больше, а сами вопросы — сложнее. Если в 2015 году один бизнес-аналитик разбирал около 300 кейсов в год, то сегодня — около тысячи. При этом средняя оценка работы с обращениями остается на уровне 4,9+.

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

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

Привет! Меня зовут Евгений, я специалист по безопасности приложений в Naumen. Моя работа — поиск и устранение уязвимостей в продуктах и инфраструктуре.

За последние несколько лет искусственный интеллект из экспериментальной технологии превратился в повседневный рабочий инструмент. Сегодня LLM помогают разработчикам писать код, аналитикам готовить документы, а сотрудникам — быстрее находить информацию.

Но есть и обратная сторона. Те же самые технологии используют злоумышленники для фишинга, разведки инфраструктуры и автоматизации атак. Более того, сами языковые модели уже становятся целью для новых типов атак.

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

Меня зовут Катя, я руковожу операционным отделом ITSM 365 в Naumen.

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

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

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

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

За последние пару лет стало особенно заметно: атаки меняются быстрее, чем процессы защиты успевают адаптироваться. Они становятся дешевле, масштабнее и доступнее — во многом за счет ИИ.

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

Меня зовут Динара, я владелец продукта Naumen Service Desk и аналитик в команде внедрения, занимаюсь настройкой интерфейсов для Enterprise-клиентов.

В работе регулярно сталкиваюсь с одним и тем же конфликтом. С одной стороны — система как инструмент бизнеса: эффективность, снижение затрат. С другой — опыт пользователя: его привычки, когнитивная нагрузка и эмоциональный отклик. 

Где здесь золотая середина? И как получилось, что от интерфейсов, которые должны упрощать жизнь, пользователи порой устают сильнее, чем от физического труда?

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

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

Практика быстро показала, что это не так. В статье я собрала мифы о тестировании, в которые я сама верила, и то, как все оказалось на самом деле.

Меня зовут Илья, я мобильный разработчик в Naumen. Моя основная специализация — iOS-разработка. Я занимаюсь развитием мобильного клиента платформы Naumen Service Management Platform, а также Chat SDK в рамках Naumen Contact Center.

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

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

Привет! Меня зовут Ксюша, я руководитель продукта Project Ruler — это система, которая помогает бизнесу управлять проектами и продуктами в едином пространстве и позволяет видеть полную картину: от отдельных задач до стратегических целей компании. Мы развиваем продукт на рынке систем управления проектами и таск-трекеров, где конкуренция высокая, а требования к гибкости и масштабируемости постоянно растут.

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

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

Привет! Меня зовут Дима, я руковожу группой прикладной разработки в Naumen. Много лет работаю с командами, которые делают не одноразовые фичи, а долгоживущие системы — те, что развиваются годами, переживают смену людей, требований и контекста.

В этой статье поговорим о декомпозиции: зачем она на самом деле нужна и какую неожиданную роль в этом играют атомарные коммиты.

Всем привет! Меня зовут Артём Вичужанин. В разработке я больше пяти лет: начинал с десктопных приложений на Delphi и микропрограмм для контроллеров на C++, позже ушел в мобильную разработку. Сейчас в Naumen я отвечаю за разработку мобильных продуктов, и в рамках проектов регулярно сталкиваюсь с вопросами качества кода и автоматизации.

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

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

Привет! Меня зовут Маша, я продакт ITSM 365 в Naumen. Более 8 лет я работаю в ИТ: начинала как бизнес‑аналитик, затем стала продуктовым аналитиком, позже — менеджером продукта. Сейчас занимаюсь Discovery — исследую новые области, где наши решения могут принести бизнесу пользу.

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

Привет! Меня зовут Ринат, я iOS-разработчик в Naumen. В компании я занимаюсь разработкой нескольких iOS-продуктов: клиента для SMP-сервера (Service Management Platform) и SDK чата.

В этой статье расскажу, как мы используем связку Proxyman + HAR, чтобы готовить mock-данные сетевых запросов для интеграционных UI-тестов одного из iOS-приложений. Такой подход выручает, когда для тестов нет возможности поднять сервер с нужным наполнением или сервер не предоставляет дополнительных методов API для имитации определенного сценария — например, переписка в чате с собеседником, обновление статуса заказа.

Привет! Меня зовут Лиза — я аналитик по информационной безопасности в направлении внедрения Naumen Contact Center. В Naumen я работаю около трех лет.

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

Привет! Меня зовут Денис, я руковожу группой R&D в Naumen Service Management Platform. В этой статье — разбор виртуальных потоков (VT) в Java: почему исторически обычные потоки упирались в I/O, как и зачем появились виртуальные потоки, что пошло не так в Java 21, что исправили в JDK 24–25, а также когда виртуальные потоки необходимы, а когда — лучше от них отказаться.

Привет, меня зовут Лиза — в Naumen я занимаюсь задачами обработки естественного языка (NLP). До этого я работала с компьютерным зрением, поэтому, перейдя в Naumen, сменила не только компанию, но и специализацию. Мой первый проект в Naumen стал настоящим вызовом — нужно было реализовать систему аспектно‑ориентированного анализа тональности (ABSA) на русском языке.

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