Менеджмент

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

Я сначала не понял, что стало происходить. Было ощущение странного дежавю: читаю change request или баг-репорт, киваю, вроде всё логично... но что-то не так, как будто где это уже читал. Слова правильные. Причинно-следственные связи на месте. Термины употреблены верно. Пытаюсь понять в чём проблема – ноль. Как будто читаешь инструкцию к микроволновке, а не описание реальной проблемы. Пытаюсь прочитать ещё раз и ещё раз - с трудом продираюсь через текст с каким-то смутным понимаем того, что написано.

И тут до меня доходит - как обухом по голове.
Мои дорогие гении из техподдержки и продакт менеджер нашли "идеальный" способ сэкономить на обсуждении технической стороны проблемы со мной. И действительно, зачем? Клиент что-то спросил. Они прогнали это через ИИ. И ИИ вник. Глубоко. Старательно. Затем сгенерировал текст, старательно объясняя мне что нужно добавить, починить и даже каким образом это сделать (не имея даже понятия о нашей кодовой базе).

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

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

“Надо увеличить ценность нашего продукта!” - фраза, которую произнес, пожалуй, каждый продакт хотя бы раз за свою карьеру. Эта фраза уже так набила оскомину, что уже потеряла всякий смысл.

А вот такой фразой “это не увеличивает ценность продукта для пользователей” отшиваются многие неугодные инициативы будь-то от команды или от СЕО.

Но что скрывается за этим мифическим термином “ценность для пользователя”?

Давайте разбираться.

Кажется, что цели ставить легко: мы вроде бы чётко понимаем, чего хотим. «Хочу быть богатым». «Хочу начать ходить в зал и быть спортивным» и тд.

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

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

Тем, как правильно это делать, мы сегодня и займёмся.

Если коротко, то, конечно, есть. Но я бы не писала об этом, если бы все было так просто.

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

Сделаем шаг назад и попробуем описать термины «продукт» и проект» и их связь. Вот и все 😊. Собственно, на этом шаге и стала очевидна первопричина всех споров.

В классических стандартах PMBOK, PRINCE2, ISO 21500, ICB «продукт» рассматривается как конечный результат проектной деятельности под запрос. Например, нам заказали строительство дома. Проект – это вся деятельность: планирование, закупка материалов, работа строителей, контроль сроков и бюджетов. Продукт - сам дом, который мы получаем в конце целиком или по частям (кухня, гостиная и т.д.).

В Agile-методологиях Scrum, Kanban, SAFe, Lean «продукт» - это ценность, которая развивается и поддерживается итеративно, понятие «проект» почти исчезает.  Например, продукт – дом пригоден для жизни уже после первых итераций, но со временем только улучшается. Проект – работа с итерациями (Scrum), поток задач (Kanban), оптимизация процесса строительства (Lean). То есть в классических стандартах проект «больше» продукта, в Agile – наоборот. Важно, что здесь мы не говорим об однозначном соответствии классических стандартов со способом реализации, то есть сравнение классические стандарты vs Agile‑методологии это не то же самое, что и Waterfall vs Agile, ведь и в классических стандартах, например, PMBOK, описывается управление проектами через «гибкие» методологии.

Я не экономист и не связан с менеджментом, тем более никогда не интересовался складской логистикой. У меня свой взгляд человека со стороны, разобравшегося и осмыслившего частную проблему. Хочу описать то понимание, которого мне не хватало изначально, как программисту. Хочу сохранить это понимание и, возможно, донести эти мысли для профессионалов в своей области. Возможно, хочу сохранить свои эмоции.. Без формул и заумных терминов, эта несложная математика уровня средней школы, которая может различаться у разных групп людей. Например, кто-то подгоняет lcr под 100%, а другие считают обратное значение и добиваются зеленного уровня в 25-35%, и это просто местные привычки, которые погоды не делают. Поэтому в дальнейшем буду оперировать словами "хороший" и "плохой" lcr, потому что каждый менеджер сам знает, какие цифры под этими словами подразумеваются. Другое дело, есть ли вообще понимание, зачем это считать? Оказывается, самое сложное не посчитать, а объяснить, зачем мы это считаем.

Исследовательская компания Gartner представила тренды развития технологий на 2026 год. Обозреваем ключевые любопытные тезисы.

В 2026 году темпы изменений ускоряются, и ИИ больше не является опцией «по желанию». На конференции Gartner IT Symposium/Xpo 2026 вице-президент Garter Джин Альварес и аналитик Тори Полман подчеркнули, что ключевые стратегические технологические тренды этого года — это необходимые инструменты для CIO и ИТ-лидеров, позволяющие создавать устойчивые основы, выстраивать интеллектуальные системы и защищать ценность бизнеса.

Зумерам стукнуло 30 лет. Хватит думать о них как о «тревожных детях», нуждающихся в более умном руководстве. Сегодняшние зумеры — это первое по‑настоящему глобальное и цифровое поколение, которое уже берет на себя лидерство. А завтра им предстоит управлять поколением альфа. Пора менять оптику.

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

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

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

Я — сертифицированный технический интервьюер в EPAM. За плечами у меня около 800 проведенных интервью: от общих технических скринингов до финальных проектных этапов. Такая выборка позволяет видеть паттерны, которые скрыты от глаз обычного разработчика или менеджера. И мой главный вывод неутешителен: в текущих реалиях практически невозможно достоверно установить реальный уровень кандидата ни за одно интервью, ни за серию встреч.

Да, я знаю про опыт BigTech компаний. Они экспериментируют, устраивая марафоны из 4–5 секций подряд, пытаясь имитировать «реальный рабочий день». Но давайте будем честны: это имитация, которая не имеет ничего общего с реальностью. И вот почему.

1. Фактор нервозности и искажение реальности Интервью — это не работа, это экзамен под прицелом. У каждого своя степень стрессоустойчивости. Я видел десятки случаев, когда у кандидата буквально отключался мозг от того, что на него смотрят и комментируют каждую строчку кода. В спокойной обстановке этот человек может писать гениальные решения, но в режиме live-coding, когда интервьюер дышит в спину, он забывает синтаксис языка. И наоборот: есть люди с превосходными навыками самопрезентации, которые уверенно пишут плохой код, но делают это с таким видом, что джуниор-интервьюер ставит им «Strong Hire». Мы оцениваем не навык разработки, а навык прохождения интервью.

2. Разрыв между вопросами и реальными задачами Очень часто задания на интервью абсолютно оторваны от того, что человек будет делать на проекте. Классический пример: секция System Design. Это стандарт де-факто в бигтехе и крупных аутсорсерах. Мы просим кандидата спроектировать условный Uber или Instagram, обсуждаем шардирование баз данных и балансировку нагрузки. При этом человека рассматривают на роль Senior-разработчика, который ближайшие два года будет писать бизнес-логику в уже устоявшемся монолите или микросервисах. Ему никто не даст ничего проектировать с нуля. Возникает стойкое ощущение, что отделы найма просто усложняют процесс, чтобы продемонстрировать начальству свою «изобретательность» и важность, создавая искусственные барьеры там, где они не нужны.

Найти квалифицированного исполнителя для выполнения технически сложной задачи не так просто. Но практика показывает, что еще сложнее найти квалифицированного заказчика.

Эта статья — крик души Кирилла, основателя одной ИТ‑компании и руководителя подразделения в другой (обе специально не называю). Работал 20 лет в ИТ, писал код, управлял проектами, продавал, сделал пару ИТ бизнесов. Далее рассказ от его имени. 

Привет! Меня зовут Виталий.

Уже более 7 лет я помогаю внедрять IT-решения для бизнеса. Довелось пообщаться с разными компаниями, клиентами, пользователями, собрать интересный опыт. В этой статье вы найдете топ-5 low-code платформ для автоматизации бизнеса, а также мои мысли, наблюдения и опыт в части выбора такой платформы.

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

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

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

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

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

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

Что может быть общего у забронзовевшего Waterfall и «выскочки» Agile? Как оказалось — очень многое.

Вы запускаете сервис и начинаете отправлять письма: транзакционные уведомления, апдейты, подтверждения действий. На старте все выглядит просто — SMTP настроен, письма уходят. А потом внезапно выясняется, что часть писем не доходит, часть улетает в спам, IP-адреса теряют репутацию, а продакт кричит «Где деньги?».

Под катом разберемся, почему это происходит, зачем провайдеры вообще блокируют порт 25, какие варианты организации исходящей почты существуют — и как мы в Selectel пришли к запуску собственного SMTP-сервиса на базе партнерского SMTP-транспорта.

За долгое время работы в ФинТехе у меня сформировался целый набор привычек, которые можно смело назвать профдеформацией. И тема трансфертного ценообразования (Funds Transfer Pricing) - одна из них. Она позволяет абстрактно и объективно взглянуть с финансовой стороны на любую активность, будь то банковский продукт или жизненный выбор. Казалось бы, концепция применяется давно, но публикаций на эту тему крайне мало (особенно в отношении российского рынка), а те, что есть, написаны в таком сухом академическом стиле, что хочется уснуть после первого абзаца. В этой статье я хочу популяризировать понимание данного понятия, но в простой форме, доступной не только прожженным экономистам.

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

Я поделюсь практическим опытом внедрения этих принципов в крупном системообразующем банке в период 2013–2015 годов. Расскажу:

Как мы переходили от интуитивного управления к математически обоснованному принятию решений.

Как эта система проявила себя во время декабрьского шока 2014 года, когда краткосрочные ставки взлетели до 40%.

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

Трансфертное ценообразование — это не просто бухгалтерская механика перекладывания денег из одного кармана в другой. Это инструмент, который навсегда меняет взгляд на экономику проектов.

На самом деле, мы, как ИТ специалисты, так и конечные пользователи довольно сильно привыкли к западным программным решениям за последние несколько десятков лет. Известные вендоры заполонили рынок информационных систем и технологий, начиная от Microsoft, Oracle, SAP, завершая SAS. В голове мелькала мысль: зарубежное, значит качественное и общепризнанное, довольно часто игнорируя тот факт, что есть и наше, отечественное программное обеспечение, в которое нужно инвестировать и которое требуется развивать. Казалось, что западные программные продукты безальтернативны, ведь их внедряют во многие предприятия, в том числе и государственный сектор. Особенно это касалось программных решений SAP, несомненно, линейка продуктов вендора обладает качеством, устойчивостью и масштабируемостью, однако инициативы вокруг SAP в какой-то момент превратились из средства реализации в самоцель. Выпуская программные решения на каждый чих, постоянно обновляя продукты до более совершенных версии, SAP-проекты превратились в успешный бизнес, дающий выгоду не столько конечным пользователям, сколько руководству и компаниям интеграторам. Сейчас же нам предстоит вернуться с небес на землю, вспомнить, что такое кастомная разработка и отечественные программные решения, чтобы занять ту нишу, что оставили за собой, уходя, зарубежные вендоры. В связи с этим, разберемся, что нужно делать для вывода нового программного решения на российский рынок.

Основными документами, описывающими план действий реализации корпоративных целей предприятия служат:

Привет! Я лид системных аналитиков в департаменте корпоративных систем ЛАНИТ. В этой статье я расскажу, как писать качественные постановки на разработку информационной системы. 

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

В этом обзоре я собрал CRM-системы, которые актуальны к 2026 году, — для разных сфер, масштабов бизнеса и сценариев.

Здесь есть простые сервисы для работы с заявками и продажами, CRM для команд с нестандартными процессами, а также open-source решения.