Управление проектами *

Привет! На связи Андрей Ефремов из МТС Web Services. Стать крупным IT-руководителем было моей мечтой — мне было интересно, как и за счёт чего люди становятся директорами, вице-президентами, и я нащупывал собственный путь. В 2009 году я стал IT-менеджером, а сегодня руковожу крупным кластером «Развитие инфраструктуры», и мне по-прежнему интересно расти. За это время я понял: универсального маршрута нет, но есть общие вехи, узкие места и рабочие принципы.

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

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

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

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

Рассказали о 5 тревожных симптомах, по которым понятно: вы почти потеряли контроль над бизнес-процессами.

Привет, я Рома, во время поиска работы я часто сталкивался в вакансиях project и product менеджеров с требованиями «технического бэкграунда» или чего‑то более конкретного, например, составления API запросов. Из своего опыта я слабо понимал откуда берутся данные требования, но запросы в Postman направлять научился.

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

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

Так вышло, что кроме России, я работал в Европе, Казахстане и Австралии и немного в США. И мне есть что сказать на тему «чем отличается российский стиль менеджмента от Европейско-американского».

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

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

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

Статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь. Ну и читайте другие мои статьи на Хабре про управление в ИТ.

Итак начнем с первого и очевидного вопроса:

Если вы работаете с мониторингом в Prometheus или VictoriaMetrics, то наверняка знаете, как алерты из Alertmanager могут быстро накапливаться, требуя ручного трекинга в Jira. А что если автоматизировать это полностью — с назначением исполнителей, метками, компонентами и даже шаблонами для описаний? Знакомьтесь с alertmanager-jira — классным инструментом для обеспечения интеграции Alertmanager (с Prometheus или VictoriaMetrics). Это Alertmanager (webhook) плагин, который создаёт и управляет задачами в Jira на основе алертов, с акцентом на гибкость. Написан на Quarkus, лёгкий и готов к деплою в docker (podman).

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

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

В сборнике уже есть информация по 45+ компаниям, включая Яндекс, Авито, Т-Банк, VK, Сбер, Ozon, Газпром, ВТБ, Самокат, Альфа Банк и др.

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

Шаг 1. Проверить интерес

Чтобы сделать это, нужно заглянуть в головы миллионов людей. Но благодаря современным сервисам это можно сделать легко: идём в Яндекс Wordstat, Google AdWords и Google Trends. Запросы не врут: если люди ищут решение, значит, потребность существует.

Шаг 2. Изучить конкурентов

Здесь в помощь инструменты по типу SimilarWeb, Ahrefs. Мы видим трафик конкурентов и характеристики аудитории. Crunchbase и CB Insights раскрывают инвестиции и инновации: кто вкладывает деньги в эту нишу, кто “выстрелил”, а кто обанкротился. Это честная база реальных кейсов.

Шаг 3. Изучить статистику и макроданные

В России — это Росстат, ФНС, ЦБ РФ, РБК Исследования. Они показывают TAM и SAM (подробнее об этих аббревиатурах поговорим далее) по регионам, количество потенциальных клиентов и экономическую активность.
В мире — Всемирный банк, IMF, OECD. Это фон, на котором работает любая бизнес-модель: динамика экономики, демография, тренды по странам.
Для глубины мы используем отраслевые отчёты: Gartner, IDC, Frost & Sullivan, Accenture, McKinsey, PwC, GlobalData, Euromonitor, Statista. Это уже не просто цифры, а прогнозы и инсайты по конкретным индустриям: от IT до e-commerce и потребительских рынков.

Шаг 4. Изучить целевую аудиторию

Рынок — это не только деньги, но и конкретные пользователи. ВЦИОМ, ФОМ, Левада, а также данные мобильных операторов и банковских исследований помогают нам собрать портрет: возраст, доходы, привычки, потребительские тренды.

Вместе это складывается в трёхуровневую картину.

Бадди — это не персонаж из Fallout, «Гриффинов» или My Little Pony. В HR-сфере так называют сотрудника, который помогает новичку влиться в команду. Его основная задача — быть проводником, своим человеком внутри. 

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

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

Всем привет! На связи Сергей Козлов, директор Мегаплана — системы управления бизнесом для небольших команд. В сентябре 2025 года мы выпустили масштабное обновление продукта: улучшили интерфейс и пересобрали тарифы. Для нового старта нам не пришлось массово нанимать новых сотрудников. Сегодня расскажу о плюсах подхода «всё своими силами». А ещё дам 5 советов тем, кто тоже задумывается о глобальном изменении продукта, но пока по каким-то причинам на него не решается. 

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

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

Почему общение становится такой проблемой? Потому что его слишком много, оно хаотично и не имеет единого центра. Вас дергают коллеги, сыплются непонятные задачи, начальство ставит задания вскользь на созвонах, а через месяц интересуется результатом. Информация теряется в почте, чатах и в собственной памяти. А ещё фоном мозг напоминает: "Не забудь, надо сделать то-то и то-то!".

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

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

Всем привет! Мы сотрудники отдела внедрения мультиязычных систем и сервисов из IT-компании SM Lab: отвечаем за обучение пользователей работе с информационными системами (ИС) группы компаний «Спортмастер». Проще говоря, мы те самые люди, которые находятся между разработчиками, выкатывающими новый функционал, и пользователями, которым с этим функционалом предстоит работать. Обучаем не только сотрудников офисов и магазинов, но и иностранных партнёров ГК «Спортмастер». 

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

Привет, Хабр! На связи Лера, технический писатель в Авито. Сегодня разбираем книгу Барбары Оакли Learning How to Learn — бестселлер о том, как устроено обучение и какие приёмы действительно помогают учиться быстрее и глубже.

В B2C SaaS от CPO постоянно ждут ответов на вопросы в цифрах. Сколько новых клиентов пришло за неделю? Сколько отвалилось? Что этому предшествовало? Всё это уже есть в базе данных, но универсального способа быстро достать эти ответы — нет.

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

При этом первые MVP аналитики можно сделать гораздо проще и дешевле, чем кажется. Они уже приносят пользу: позволяют быстро отвечать на ключевые бизнес-вопросы, не ломая основную инфраструктуру и не собирая штат инженеров. Именно об этом я и поговорю в статье.

Каждый, кто работал над проектами, знает, рано или поздно приходится наступать на одни и те же грабли. Ошибки повторяются, и, если их не анализировать, они будут снова и снова тормозить работу. Я руководитель проектов в компании «ЛАНИТ-Интеграция» с семнадцатилетним управленческим стажем. В моей практике были инфраструктурные проекты, проекты по аудиту и информационной безопасности, телекоммуникациям, а среди заказчиков, с которыми я работал, есть крупнейшие банк, авиакомпания, автомобилестроительный завод, предприятие атомной отрасли России. 

Сегодня в блоге ЛАНИТ я расскажу про инструменты, которые помогают минимизировать риски в проектной работе. 

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

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

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

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

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

И тут мы столкнулись с тем, что, став руководителем, человек не понимал, что он должен делать теперь, и как его деятельность отличается от деятельности просто сотрудника‑исполнителя.

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

Чем же привлекла внимание, эта книга новых руководителей?

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

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

После COVID-19 наша культура труда в основном изменилась к лучшему, но были и негативные изменения, например, увеличение количества совещаний на 13,5%[1].

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

В своей знаменитой статье «Maker's Schedule, Manager’s Schedule» [2] Пол Грэм писал:

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

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

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

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

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