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

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

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

Привет! Меня зовут Вика, почти 4 года назад я пришла в Naumen на стажировку. Потом работала системным аналитиком в Naumen SMP, а сейчас руковожу командой сопровождения web SMP. 

Еще до тимлидства я слушала подкасты продактов. Это помогало накапливать общую картину, что важно в управлении. Когда сама стала тимлидом, начала искать книги и статьи уже о том, как выстраивать работу с командой. Почти все советы были для команд с опытными и самостоятельными специалистами. В моей — только джуны, которым нужна совсем другая среда: больше поддержки, объяснений, пространства для ошибок. Универсальные рецепты тут не работали, поэтому я искала свой путь.

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

В 2021 году Мартин Одерски представил Scala 3. С тех пор экосистема адаптируется, а интерес к ней растет: Scala 3 становится стандартом для новых проектов, в то же время Scala 2 постепенно сворачивается.

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

Привет! Меня зовут Ирина, уже более пяти лет я работаю в сфере бизнес‑ и системного анализа. Сейчас я — системный аналитик Project Ruler. До этого около трех лет занималась внедрением продукта Naumen Contact Center. Поэтому всегда много взаимодействовала с заказчиками, пользователями, разработчиками, тестировщиками и другими участниками процесса.

Кажется, все просто: поговорил, собрал требования, передал их в работу. Но на деле коммуникация — один из самых сложных аспектов в работе аналитика. Где‑то не так понял, что‑то вовремя не зафиксировал, не смог отстоять свою позицию — в результате сроки сдвигаются, продукт не попадает в ожидания клиента, а сам аналитик оказывается на грани выгорания.

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

Привет! Я Стас, уже больше года работаю продактом в ITSM 365. В эту ИТ-профессию попал не сразу, ранее строил карьеру в проджект-менеджменте: собирал требования, делал ТЗ и брифы, реализовывал проекты. Но мне стало скучно — слишком много рутины, нет места творчеству и возможности влиять на продукт. Тогда определил, что может принести удовольствие в работе: новые задачи, реализация идей и возможность принимать решения. Продуктовая разработка подошла по всем пунктам. Так началось мое путешествие из проджекта в продакты.

Я понимал, что меня ждет много трудностей. Однако скиллы проджекта сильно пригодились. Благодаря им за год достиг неплохих успехов в продуктовой разработке. Например, сократил «time to market» фич релиза в три раза и уменьшил трудозатраты команды на их выпуск на 20%. В статье расскажу о сложностях, с которыми столкнулся при смене роли, и как их преодолел. Также поделюсь, какие навыки помогли стать менеджером продукта.

Привет! Я Даша, системный аналитик и программный директор курса «Профессия аналитик в IT» от Naumen. Образование и развитие других — важная часть моей жизни. Когда я ушла в декрет с младшей дочкой, решила не откладывать карьерные цели и полностью погрузилась в переработку нашего курса для аналитиков. Хотелось сделать его максимально полезным для студентов.

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

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

Это подтолкнуло Костю, проектного разработчика в Naumen, создать краткое руководство по написанию плохого REST‑сервиса. Уже несколько лет он занимается поддержкой и развитием проектов на Naumen Service Management Platform, часто сталкивается с проектированием REST API и точно знает, каких ошибок лучше не допускать.

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

Привет! Меня зовут Аня, я аналитик в Naumen Erudite. За четыре года в компании у меня было несколько проектов внедрения с крупными заказчиками. Не всегда работать на таких проектах легко — нужно уметь находить правильный подход к разным типам заказчиков, чтобы продолжать эффективно взаимодействовать.

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

Привет! Я Саша, уже почти пять лет я работаю в 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 Project Ruler. Команду сформировали в прошлом году, но им уже удалось завершить несколько проектов и создать уникальную атмосферу внутри. Игорь Путин, владелец продукта и тимлид Naumen Project Ruler, поделился, как живёт стартап внутри компании.

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

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

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

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