Привет! Я Саша, уже почти пять лет я работаю в IT. Был инженером-технологом, руководителем проектов, бизнес-аналитиком и системным аналитиком в компаниях разного размера. И не понаслышке знаю, как специалистам бывает тяжело разобраться в требованиях клиента. Эта проблема становится глобальной, когда правки в изначальный бриф приходится вносить почти каждый релиз — «Почему нет этого функционала? Мы думали вы сделаете». Отсюда возникают лишние трудозатраты, потеря лояльности клиента и снижение мотивации команды. Чтобы этого не произошло, важно на первых этапах дотошно уточнять каждую деталь.

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

Главная задача продакта — создать продукт, который удовлетворит реальные потребности клиента. Для этого он использует очевидный набор действий: проводит исследования → тестит гипотезы → определяет ценность. Но часто в погоне за фичами забывает эту ценность вовремя актуализировать. Ведь векторы развития бизнеса меняются, а наш продукт уже может не решать новые «боли». Это приводит к потере клиента.

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

Оля — тимлид группы аналитики в Naumen Service Management Platform. Часто аналитики приходят к ней с разными вопросами. Например, как правильно работать с требованиями и общаться с разработчиками, почему не получается эффективно распределить время и приоритизировать задачи. Чтобы помочь команде решить сложности, Оля разработала стратегию самопомощи для аналитиков.

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

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

Динар Каримов, аналитик в Naumen Contact Center, рассказал, в какие моменты возникает неопределенность и как снизить риск ее возникновения. 

Привет! Я Вика, системный аналитик Naumen Service Management Platform.

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

Меня зовут Денис, я тимлид команды R&D в Naumen Service Management Platform.

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

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

В апреле мы провели Naumen Analyst Meetup, на котором обсудили важные для аналитиков навыки. Например, способности эффективно общаться с заказчиком, доходчиво объяснять, внимательно слушать и самое главное — задавать правильные вопросы. 

Junior-специалистам, как правило, сложнее всего дается последний пойнт. О нем и был доклад Саши Николаева, руководителя группы бизнес-анализа в Naumen,  «Как не бояться задавать глупые вопросы и копать в глубь».

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

Нашим коллегам Александру Николаеву из практики BPM и Наталье Ждановой из практики LowCode удалось прокачать два этих паттерна — продуктовый и проектный. В статье они рассказали, в чем видят пользу каждого из типов мышления и как их развить.

В ИТ я оказалась летом 2022 года, успешно прошла стажировку в роли бизнес-аналитика и уже второй год занимаюсь проектами внедрения. До этого работала в маркетинге, поэтому погружаться в мир ИТ пришлось с нуля. Возникало множество вопросов: какие процессы есть во внедрении, где подключается аналитик, как общаться с клиентами и нужно ли уметь писать код. Найти ответы помогли мои навыки из маркетинга.

Руководители IT-проектов (РП) на рынке труда в остром дефиците: по данным hh.ru на 1 вакансию приходится 1,9 резюме. Поэтому часто в компаниях один РП ведет по 5-6 проектов. При такой загрузке успеть все и сохранить качество практически невозможно.

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

В статье Света Кыштымова, администратор проектов в Naumen, рассказала о роли администратора и задачах которые выполняет.

Всем привет!

Меня зовут Александр Денисов. Я работаю в компании Naumen и отвечаю за документирование и локализацию программного продукта Naumen Contact Center (NCC).

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

В Naumen множество команд: одни развивают уже существующие продукты, а другие — создают новые. Сегодня мы расскажем про Naumen Project Ruler. Команду сформировали в прошлом году, но им уже удалось завершить несколько проектов и создать уникальную атмосферу внутри. Игорь Путин, владелец продукта и тимлид Naumen Project Ruler, поделился, как живёт стартап внутри компании.

Меня зовут Денис, я тимлид команды R&D в Naumen Service Managment Platform. 

Наша платформа — зрелое решение для автоматизации бизнес-процессов, а ещё сложная IT-система, которая строится с использованием готовых опенсорсных решений. Чем сложнее и старше продукт, тем больше подобных кубиков — внешних зависимостей, появляется в проекте. И в конце концов, нам пришло понимание, что всем этим «зоопарком зависимостей» надо управлять, желательно автоматически.

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

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

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

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

На сегодняшний день существует несколько популярных подходов к созданию ПО, которые определяют как работу вендоров, так и развитие ИТ-индустрии в целом. Первый — классическая разработка, которая предполагает работу с нуля над определенным программным продуктом для конкретного заказчика. Второй — low-code платформы и их производные, в основе которых лежит принцип ухода от парадигмы «ручного труда» за счет оптимизации бизнес-процессов на уровне платформы. 

Заметным трендом сейчас является рост популярности no- и low-code подходов к разработке ПО. Подобные изменения в свое время пережили традиционные рынки вместе с появлением конвейерного производства, которое сделало доступным для массовой аудитории не только товары, но и оборудование. Похожий принцип заложен и в эволюции вендорных компаний. Причем в последние годы этот процесс заметно ускорился — благодаря цифровизации бизнеса и росту доли заказов с неизбежно похожими параметрами. 

Между тем, до конца разобраться в специфике low-code до сих пор не получается не только у клиентов, но даже у ИТ-специалистов. Например, часть профессионального сообщества опасается, что развитие low-code приведет к отказу от дорогой high-code разработки. В свою очередь клиенты, которые привыкли к high-code, воспринимают low-code продукты как инструмент для создания эскиза информационной системы. Рассмотрим особенности разных подходов к разработке ПО и критерии, по которым их выбирают вендоры и заказчики.

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

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

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

Наличие внушительного портфеля ПО в компании не равно умению эффективно им управлять. Развитие функции SAM (Software Asset Management) часто кажется слишком сложным процессом и не входит в число приоритетов бизнеса. Однако зрелый процесс управления программными активами поможет сэкономить компании немало денег и времени в долгосрочной перспективе.

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

Меня зовут Саша и я аналитик SMP Mobile. Это мобильное приложение, с помощью которого коллеги могут, например, зарегистрировать заявку по QR коду в офисе и не только.

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

Сложно представить свои повседневные будни без использования облачных сервисов Google Drive, DropBox, iCloud и других. Тем не менее, в нынешних обстоятельствах мы вынуждены менять привычные решения. На первый план вышли такие характеристики продуктов, как страна происхождения компании-разработчика, геолокализация данных и другие.

Как быть, если корпоративные сервисы, разрешенные для использования в организации, не справляются?

Большая часть ИТ-конференций — это сборник best-practices, которые призваны не только научить чему-либо, но и показать компанию спикера с выгодной стороны. Также спикеры сталкиваются с NDA — не всеми данными можно делиться, поэтому доказать эффективность предложенных инструментов непросто. В таких условиях сложно полностью перенять опыт коллег и досконально разобраться в вопросе. Но что, если и спикеры, и участники — это сотрудники одной компании? Рамки секретности снимаются и обмен опытом становится более прикладным.

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