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

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

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

На что обращать внимание, когда принимаешь проект в середине реализации

Привет, меня зовут Ярослав, я Backend‑разработчик в отделе Битрикс24 CRM Корус консалтинг. Не так давно я впервые занимался настройкой CI/CD для Битрикс‑проектов, поэтому сегодня хочу поделиться шагами, которые помогут запустить свой первый пайплайн. Статья подойдёт для полных новичков в теме поставки кода.

Автор текста: Денис Салтыков
^{Руководитель практики повышения операционной эффективности, бизнес-архитектор «КОРУС Консалтинг»}

Занимаясь поиском вариантов оптимизации товарных запасов у наших клиентов, мы часто наблюдаем очень похожую картину. Заказчик использует категорийный подход — одинаковые принципы пополнения запасов для всех SKU внутри товарной категории. Чаще всего это очень простые бизнес‑правила, например: «По категории „X“ мы поддерживаем запас на 30 дней, а по категории „Y“ на 60 дней».

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

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

Меня зовут Татьяна Веселова, я руководитель направления ELMA в департаменте CRM и BPM КОРУСа. Недавно мы с коллегами обсуждали тему астрологии, и я решила пофантазировать на тему того, что будет, если совместить ИТ и астрологию.

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

Привет! Меня зовут Анастасия Криулина, я фасилитатор и ведущая командных сессий в КОРУСе. Сегодня хочу раскрыть тему ретроспективы проекта с новой стороны и поделиться не всегда очевидными ценностями, которые дает ретро всем участникам процесса: от руководителя проекта до продавцов и компании целиком.
Сразу сделаю ремарку: статья строится вокруг опыта ретроспектив в проектных компаниях, чья специфика отличается от продуктовых.  

Для подготовки материала я проанализировала свой опыт в КОРУСе, итоги проведенных ретроспектив, пообщалась с коллегами, чьи комментарии вы увидите в статье. Очень надеюсь, что статья «заразит» идеей ретро сомневающихся или поможет тем, кто хочет убедить руководство в пользе таких сессий. 

Вы когда-нибудь слышали фразы вроде: «Какие вы все стали нежные», «Вам бы психологов подавай» или «Придумали себе выгорание и носятся с ним»? Эти фразы часто звучат от представителей старшего поколения, включая некоторых руководителей. Им сложно понять, почему психологический комфорт так важен и теперь сотрудники говорят: «Да, мы стали более чувствительными. Да, нам нужна поддержка. Да, мы можем выгореть». И это нормально.

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

Кто справляется с русским языком эффективнее: локальные разработки или глобальные адаптации? Мы сравнили отечественные модели, такие как GigaChat, с их западными конкурентами, включая ChatGPT. Немного разберемся, какие модели подходят для бизнеса, творчества и аналитики в русскоязычном сегменте

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

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

Привет, Хабр! Меня зовут Артем Майоров, я администратор баз данных в компании MONS (КОРУС Консалтинг).
Расскажу, как мы не дали упасть больше 100 ПВЗ России благодаря спасению Percona
MySQL-сервера.
Подробнее, как это сделать и почему вообще его пришлось спасать, я рассказал в тексте!

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

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

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

Хорошо это или плохо – начинать работу с уже заданного конечного результата? Попробуем разобраться.

Всем привет! Меня зовут Алина Ужве, я руководитель проектов в департаменте корпоративных сервисов КОРУС Консалтинг. Как РП я очень часто взаимодействую со специалистами разных направлений, специализаций и даже возрастов.
Теория, описанная в данной статье представлена так, как я ее понимаю. Текст лишь частично раскрывает тему теории поколений, в конце статьи поделюсь интересными источниками, для самостоятельного изучения материала. Кто знает, вдруг вы найдете полезные инструменты, которые захотите использовать в своей работе?

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

В этой статье мы на основе своего опыта реализации проектов расскажем о вариантах и шагах для достижения цели на примере внедрения решений на платформе ELMA365.

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

Около 10 лет назад у меня возникла идея написать игру именно на Java, поскольку я использую этот язык в работе. Это был своего рода челлендж. Хотел попробовать себя, посмотреть, возможно ли это. И спойлер – возможно. Но проект дал мне больше, чем я мог рассчитывать.

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

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

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

Привет! Меня зовут Антон Бурмаков, я QA Lead в КОРУСе. Со мной Герман Вавилин ( @Decayron85) из команды DevOps. Сегодня расскажем, как мы запараллелили смоук-тесты после мердж-реквестов, встроив их CI/CD и избавились от необходимости поддерживать множество окружений. 

Что в материале: 

Хабр, привет. На связи Оксана Рубанова, разработчик на платформе Optimacros.

Бывают моменты, когда от тебя ничего не зависит, случается что-то плохое просто потому, что оно иногда случается. А бывают моменты, когда понимаешь, что ты – часть / причина этого плохого, но не понимаешь, как до этого докатился, с чего все началось и главное, как теперь это исправить, учитывая масштаб бедствия (и не важно, личная это сфера или рабочая).

Так что ту часть проблем, на которую я имею влияние, я захотела проанализировать и улучшить.

В статье поговорим про:

1. Теории накопительного эффекта и разрушенных окон и их влияния на нас

2. Проблему внутреннего тестирование на проектах и идею, как его можно усилить

3. Рабочий эксперимент с командой, длинною в месяц

4. Результаты участников по итогам челленджа

5. Мои выводы со стороны организатора

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