Менеджмент

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

Заходите утром в Jira, Asana или Yandex Tracker. Перед вами — бесконечный список задач, раскрашенных в цвета приоритетов, разбитый на спринты и эпики. Каждое действие нужно залогировать, каждый комментарий — оставить в тикете, а каждую «помидорку» — учесть в тайм-трекере. Знакомое чувство легкой тоски, стыда за незакрытые задачи и раздражения от бесконечных уведомлений? Поздравляю, вы не одиноки. Это — синдром современного высококвалифицированного специалиста, которого пытаются загнать в систему, созданную для управления… заводскими рабочими начала XX века.

Таки подумал и решил удалить основную часть статьи.
Мотивация — думаю, что я уже в достаточной степени (да и не я один, судя по обилию статей по данной теме) привлёк внимание к проблеме. В том числе, надеюсь, дополнительно замотивировал продуктологов и технологов компании Bitrix обратить больше внимание как на продуктовую (в том числе UI/UX), так и на техническую составляющую их продуктов. Которые, будем надеяться, в следующих версиях будут лучше. И у людей будет меньше поводов к разочарованию. Я за то, чтобы не просто гнаться за формальным количеством фич, а вылизывать и доводить до ума основной функционал, чтобы им было пользоваться действительно удобно.

Часть 1. «Цифровая пена» всё сильнее затягивает

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

С другой стороны, начиная с 30-х годов прошлого века, изменения в производственных системах, развитие компьютеров и аналитики, а также миллиарды долларов, вброшенные в консалтинг, породили вокруг бесконечное количество информации, моделей, систем, программных продуктов. Часто начинает казаться, что современные руководители, просто тонут в этой «цифровой пене», не всегда понимая, как соединить «теплое» с «белым», например, внедрение ERP, желание повысить скорость выпуска и сделать завод более рентабельным, а также развивать «мягкие навыки» (soft skills). И вокруг армия консультантов: «Вам нужно внедрить Бережливое производство», «У вас нет нормального управленческого учета», «Вам срочно нужно ERP», «Зачем тратить большие бюджеты, давайте всё сделаем в экселе» и так далее

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

Цель статьи – сравнить принятие решение и проектный треугольник, чтобы показать условия, при которых можно выбирать зону риска для принятия более качественного управленческого решения. Я пишу эту статью как размышление, а не как научное исследование. Классический проектный треугольник управления проектом достаточно известен: объем, сроки, ресурсы. На практике, для обеспечения качества мы пытаемся контролировать два наиболее значимых аспекта треугольника (хотя надеетесь контролировать все три). В теории мы определяем объем фиксировано, устанавливаем сроки и планируем ресурсы. Таким образом мы пытаемся сохранить все параметры проекта неизменными. Часто в процессе все начинает идти не совсем по плану, и мы начинаем работать с отклонениями и рисками, которые возникают по мере реализации проекта. Как мне рассказывал один из руководителей проектного офиса, в годовой перспективе фиксация объема, ресурсов и времени путем описания требований, создание дизайна, расчет ресурсов и планирование занимают примерно восемь месяцев в году. Таким образом, для реализации остается четыре месяца в годовом горизонте. Не будем касаться актуальности решения спустя год такого планирования и аспектов целесообразности в изменчивом мире. Классический подход вполне имеет место на свое существование. Перед началом введем несколько определений: Объем – это тот список работ, задач или необходимый состав операций который необходимо выполнить. Время – это время которое мы планируем затратить на проект или любые временные ограничения. Ресурс – это в первую очередь совокупные затраты на проект, затраты на персонал, сам персонал который нам необходим, а также иные виды ресурсов или материалов которые нам понадобиться для получение готового объема задач. Если представить проект как треугольник то мы сможем нарисовать вот такой рисунок.

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

В чём корень? Погоня за лайками, кликами и красивыми циферками KPI. Когда алгоритм “затачивают” только под отчётность, теряется главное — реальный результат.

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

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

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

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

Toyota не построила свой лайфстайл “японского качества” без визуальных схем — у них видно каждое звено процесса. McDonald’s стал легендой, стандартизировав каждый шаг и избавившись от хаоса на кухне. А в Amazon автоматизация сработала только тогда, когда был прорисован буквально каждый маршрут товара на складе.

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

Десять лет в бюджетных организациях из них три года работы с ГОЗ показали: сложность не в законах, а в инструментах. Собрал консалтинговую платформу с нуля на React 18 + TypeScript + Vite. Полный CI/CD через GitHub Actions, мониторинг на Sentry, Lighthouse > 90. Делюсь стеком, архитектурой и выводами — как в одиночку запустить production-ready продукт в сложной B2G-нише.

Приветствую всех читателей! Меня зовут Игорь Конев и я техлид команды STaaS (Storage As A Service) в Авито. Сегодня я хотел бы в очередной раз поднять тему оценки задач, а конкретно оценки при помощи Story Points. Хотя мы давно применяем их в работе, оказалось, что команда по-разному трактует детали. Поэтому мы решили систематизировать и выровнять наши знания. Результатом работы стал этот материал, которым я с радостью делюсь с вами. Он не претендует на откровения, но удобно собирает терминологию, практические советы и наш опыт — возможно, это сэкономит вам пару-тройку Story Points.

Главная мысль статьи: Не подстраивайте Scrum под старую структуру компании. Меняйте структуру компании, используя Scrum как инструмент трансформации. Делайте это постепенно, маленькими шагами, постоянно учась и адаптируясь.

Статья является вольным переводом «Re.Imagine Your Scrum Firm up Your Agility» Гюнтера Верхейена.

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

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

Привет, Хабр! Я Николай Видов, разработчик в команде чатботов. Я работал как в небольших компаниях, так и в тех, которые на слуху: EPAM, QIWI, Т-Банке. За время работы я часто сталкивался с понятием продуктовости: «Разработчики должны активно участвовать в бизнесе», «Разработчики должны предлагать улучшения для продукта», «Разработчики должны аргументированно спорить, если не согласны с предложенной функциональностью».

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

Продуктовый разработчик — это следующая ступень эволюции разработчика, который активно участвует в бизнес-процессах. © Никита Пастухов, мейнтейнер FastStream

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

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

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

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

В 1985 году Чжан Жуйминь раздал кувалды рабочим и заставил разбить 76 бракованных холодильников. Для сотрудников убыточного Qingdao Refrigerator General Factory это выглядело весьма странно (холодильники тогда стоили как пара месячных зарплат), но директор хотел проиллюстрировать простую идею: за качество отвечает тот, кто непосредственно делает продукт, а не только начальство.

Сорок лет спустя Haier — империя с выручкой $52 миллиарда — работает как воплощение принципа, который открыли через боль рефакторинга: организационная структура неизбежно диктует архитектуру систем. То, что в IT называют законом Конвея, китайский производитель холодильников воплотил через радикальную децентрализацию всего бизнеса. 

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

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

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

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

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

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

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

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

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

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

Утренний кофе выпит, бутерброд съеден, довольные коты накормлены. Федя сразу включается в работу — дел много, нужно всё успеть. Но для начала нужно обновить локальные исходники разделов из репозитория. Это не первый его релиз. И Фёдор уже привычно запускает синхронизацию.

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

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

Шаг 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. Изучить целевую аудиторию

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

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

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

Telegram Ads для локального бизнеса — миф или реальность?

Мы взяли два полярных кейса — мебельную фабрику в Москве и новостной канал на Камчатке — и препарировали процесс геотаргетинга от А до Я.

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

С цифрами, провалами, и универсальным алгоритмом для вашего локального проекта.

ИИ перестраивает саму ткань разработки: ускоряет релизы, но множит баги, заставляет пересматривать тестирование и принципы командной работы. В 2025-м инженеры и лиды живут в двойственности — между стремительным ростом продуктивности и растущей ценой наблюдаемости, между автоматизацией и риском утраты человеческого взаимодействия. Новый отчёт InfoQ о культуре и методах разработки показывает: индустрия вступила в фазу, где платформенная инженерия становится наследником DevOps, а психологическая безопасность и умение работать малыми итерациями — вопросом выживания команд, а не модного тренда.

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

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

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

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