Школа проектного специалиста

🔥 Делимся опытом впечатлениями! «Школа руководителя проектов» — один из флагманских курсов, за который мы регулярно получаем благодарность! А вы еще успеваете присоединиться к новой группе! Старт 24 августа — регистрируйтесь на сайте.

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

Что сегодня зависит от меня? Утро современного человека начинается не с восхода солнца. Оно начинается с чужих проблем. Телефон ещё толком не сфокусировался перед глазами, а там уже всё готово: кто-то прислал сообщение в 7:14, рабочий чат успел обсудить срочный вопрос, новости сообщили о новой причине тревожиться, а приложение заботливо напомнило о делах, которые вы вчера не сделали. Прошло минут пять. Вы ещё лежите в кровати, но мысленно уже присутствуете на совещании, спорите с незнакомым человеком и немного переживаете за мировую экономику. День ещё не начался, а внимание уже разобрали. И вот здесь неожиданно полезным оказывается человек, который жил почти две тысячи лет назад и не знал ни рабочих чатов, ни push-уведомлений. У Марка Аврелия тоже было кому испортить утро. Марк Аврелий был римским императором. Поэтому совет «просто не обращай внимания на неприятных людей» подходил ему примерно так же, как современному руководителю совет отключить корпоративную почту. Люди всё равно приходили. Со своими просьбами, интригами, претензиями, конфликтами и удивительной способностью создавать проблемы именно тогда, когда проблем уже достаточно. В «Размышлениях» Марк Аврелий заранее напоминает себе, что в течение дня встретит людей назойливых, неблагодарных, высокомерных, коварных, завистливых и неуживчивых. В каком-то смысле это очень древняя версия утреннего просмотра рабочего календаря. Только вместо того чтобы удивляться: «Ну почему они опять такие?», можно задать себе другой вопрос: «Что сегодня зависит от меня?» Вопрос подозрительно простой. Поэтому его легко принять за очередную красивую фразу для картинки с рассветом. Проблема только в том, что применять его гораздо труднее, чем опубликовать. Начальник сегодня не в настроении Допустим, утром руководитель недоволен вашей работой. Можно провести несколько часов, мысленно доказывая ему, что он неправ. Потом пересказать разговор коллеге. Потом ещё раз воспроизвести его вечером дома, уже с улучшенными репликами, которые почему-то не пришли в голову во время разговора. Есть только небольшая неприятность: настроение начальника всё это время остаётся его настроением. Вашими остаются ответ, аргументы и дальнейшие действия. Это не означает, что нужно соглашаться со всем подряд. Стоицизм вообще довольно странно превращать в искусство терпеливо кивать. Речь о другом. Можно спорить о решении, не пытаясь управлять чужой головой. А это две очень разные задачи. Особенно трудно не управлять интернетом Кто-то написал неприятный комментарий. Человек находится неизвестно где, возможно, уже забыл о своём комментарии и спокойно пьёт кофе. А вы продолжаете беседу. Сначала в голове. Потом открываете комментарий ещё раз. Потом придумываете особенно точный ответ. Потом решаете не отвечать. Через двадцать минут всё-таки отвечаете. Незнакомый человек потратил на вас полминуты. Вы выделили ему вечер. В этот момент вопрос «что зависит от меня?» становится почти бухгалтерским. Чужое мнение? Нет. Удалить из мира людей, которые думают неправильно? Пока соответствующий функционал не выпущен. Решить, сколько собственного внимания отдать чужому мнению? Вот это уже ближе. Планы обладают неприятным свойством не спрашивать нашего разрешения Самолёт задержался. Клиент перенёс встречу. Сотрудник заболел. Подрядчик обещал прислать документ вчера и теперь почему-то «уточняет у коллег». Особенно раздражает последняя категория событий. Ведь план был хороший. Иногда даже в Excel. А хороший план в Excel создаёт особое чувство: кажется, что реальность теперь юридически обязана ему соответствовать. Не обязана. Можно сколько угодно злиться на сорванную встречу, но вернуть её в календарь силой раздражения не получится. Зато остаётся следующий ход: перенести задачу, предупредить людей, изменить последовательность работ, пересчитать последствия. Не самая эффектная философия. Зато рабочая. Мы вообще любим контролировать то, что нам не принадлежит Чужие решения. Чужие эмоции. Репутацию. Погоду. Рынок. Реакцию клиента. Прошлое. Особенно прошлое. Это, пожалуй, один из самых странных объектов человеческого управления.

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

⛔️ Проекты буксуют из-за коммуникации. Согласитесь, эти бесконечные уточнения в переписке, размытые технические задания, необоснованные уступки съедают не только время, но и экономическую эффективность работы. Мы запускаем интенсив «Деловые коммуникации для ИТ-специалиста» — практико-ориентированный курс, где за 2 недели и 4 живые встречи вы получите конкретные инструменты: → Техники активного слушания для выявления истинных потребностей заказчика → Презентации ИТ-продуктов на языке выгод по методике BOMBER-B → Переговоры по модели Томаса-Килмана → Автоматизация деловой переписки через ИИ-ассистентов с готовой библиотекой промптов ✅ Результат: паспорт компетенций, чек-листы, шаблоны и сокращение времени на рутину до 5–10 часов в неделю. 🧑‍💻 Для аналитиков, разработчиков, менеджеров по продажам, КАМов и администраторов проектов. 👉 Все подробности и заявка: на сайте #IT #softskills #деловыекоммуникации #обучение

🚀 Старт уже через 2 недели! Новый поток авторского курса «Школа руководителя проекта» с обновленной программой! Что вас ждёт: 🔹 2,5 месяца интенсивной практики по стандартам PMBOK 🔹 Разбор реальных IT-проектов, а не абстрактных теорий 🔹 Инструменты, которые можно внедрить с первого занятия 🔹 Обратная связь от преподавателей-практиков Этот курс для вас, если вы: ▫️ хотите систематизировать опыт в проектном управлении ▫️ чувствуете, что проекты «едут» не так, как планировалось ▫️ готовы выйти на новый уровень — от исполнителя до руководителя Места ограничены. Подробности и регистрация на сайте.

Запись вебинара про корректировки закупок и продаж до ввода остатков: -Значение корректных начальных данных для последующей работы ERP-системы и последствия некорректного начального баланса; -Алгоритм корректировок закупок до начала ведения учета в 1С:ERP; -Шаги по проведению корректировок продаж до начала учета в 1С:ERP; -Инструменты для проверки устранения расхождений и ошибок. Смотрим: https://vkvideo.ru/video-63402641_456240376 #1C #ERP #1CERP

📖 Документация, которую реально читают Знаете, какой документ в проекте читают реже всего? Тот, который написали «потому что надо». Толстый, подробный, с красивым оглавлением — и мёртвый. Потому что его никто не открывает, кроме автора. И когда новенький приходит, он всё равно спрашивает у коллег, а не лезет в документацию. Почему так — давайте разберёмся. Потому что большинство документации пишется не для людей. Она пишется для проверяющего, для отчёта, для «ну обязаны же быть регламенты». И получается текст, который формально есть, а фактически — мёртв. Почему документация умирает Первая причина — пишет не тот, кто делает. Документацию часто поручают «специальному человеку», который не работает с системой напрямую. Он переписывает то, что ему объяснили, в красивую форму. Получается аккуратно — но оторвано от реальности. Через полгода документ не соответствует тому, как всё работает. Вторая — не обновляется. Написали в год внедрения. Потом система меняется, дорабатывается, перестраивается. Документация — нет. Через два года она бесполезна. Все это знают, но никто не обновляет, потому что «некогда» и «вроде и так работают». Третья — пишет для себя. Автор документирует то, что ему кажется важным. А читателю нужно другое: не «как устроено», а «как мне сделать мою работу». Разница огромная. Один пишет про архитектуру, другой ищет «как создать документ». Оба правы. Но второй не находит. Что делает документацию живой Живая документация — это не та, что написана идеально. Это та, которую открывают, когда надо что-то сделать, и находят ответ. Вот что отличает её от мёртвой. Пишет тот, кто делает. Не «документалист», а человек, который сам работает с системой. Он знает, какие вопросы возникают, какие шаги непонятны, где люди спотыкаются. Его текст — не литература, но он правильный. Потому что написан изнутри, а не снаружи. Обновляется по ходу. Не «раз в год большим обновлением», а по мере изменений. Изменился процесс — изменили документ. Добавили функцию — добавили описание. Документация — часть работы, а не отдельный проект. Структурирована под задачу, а не под систему. Не «раздел Справочники → подраздел Контрагенты → пункт Создание». А «Как завести нового контрагента: три шага». Люди ищут действия, а не архитектуру. Возвращайте им действия. Короткая и конкретная. Лучше пять строк, которые отвечают на вопрос, чем пять страниц, которые надо прочитать целиком, чтобы найти одну крупицу. Стереотип «хорошая документация — это толстая» в корне неверен. Хорошая документация — это та, которую можно прочитать за минуту. Практичные форматы, которые работают Не всё нужно описывать текстом. Иногда другой формат работает лучше. • Пошаговые инструкции. «Сделай это, потом это, проверь вот это». Короткие, с конкретными шагами. Идеально для рутинных операций. • Скринкасты. Три минуты видео, где показано, как сделать задачу, заменяют десять страниц текста. Особенно для новичков. • Чек-листы. Для процессов, где важно не забыть шаги. Не описание, а список «отметил — сделал». • FAQ. Сборник реальных вопросов, которые задавали люди, с ответами. Живой документ, который пополняется. Онбординг как тест документации Лучший способ проверить, работает ли ваша документация — посадить новичка и попросить сделать задачу, пользуясь только документами. Если он справился — документация живая. Если постоянно спрашивает — мёртвая. Это не проблема новичка. Это проблема документации. И это самый честный тест. Вывод Документация — не «обязательная часть проекта». Это инструмент, который либо помогает людям работать, либо валяется мёртвым грузом. Разница — не в объёме, а в подходе. Пишет тот, кто делает. Обновляется по ходу. Структурирована под действия, а не под систему. Короткая и конкретная. Мёртвая документация съедает время на написание и не возвращает ничего. Живая — экономит время на вопросы, обучение, ошибки. И становится тем, ради чего её и пишут: надёжным способом передачи знаний. #документация #проектная_команда #практика #РП #аналитика

Смена отдыха — тоже работа Лениться теперь тоже предлагают правильно. Звучит немного тревожно. Потому что современный человек уже почти всё делает правильно: работает по приоритетам, ест по калориям, спит по приложению, ходит по шагомеру. Осталось составить регламент ничегонеделания, назначить ответственного и вечером проверить результат. Но отдых почему-то не наступает. Свободная минута сегодня редко остаётся свободной. Рука сама тянется к телефону: новости, сообщения, короткие видео, ещё одно короткое видео, потом совсем последнее. Тело вроде лежит на диване, а голова продолжает перерабатывать чужие мысли, лица, споры и срочные сенсации. Получается не отдых, а вторая смена. Только без зарплаты. Клинический психолог Юлия Денисова-Мельникова напоминает простую вещь: мозг и нервная система не могут постоянно работать в режиме продуктивности. Иногда полезно просто лежать, бесцельно гулять или смотреть в окно. Причём без задачи «сейчас надо хорошо восстановиться» — иначе отдых превращается в очередной пункт плана. Источник И вот здесь начинается самое сложное. Ничего не делать многим уже почти физически неудобно. Возникает чувство, будто время пропадает, пока где-то другие развиваются, успевают, читают полезное и наверняка уже выучили новый язык. Хотя, возможно, пропадает оно как раз тогда, когда даже пауза забита информационным шумом. Настоящая лень — это не слабость и не отказ от дел. Скорее короткий момент, когда от человека вообще ничего не требуется. Даже стать лучшей версией себя. Редкая, между прочим, роскошь.

Дайджест «Школы менеджера организации» за 3–9 августа На неделе говорили о сложных управленческих темах: как быть честным и не переходить границы, почему KPI иногда искажает реальность, зачем руководителю делегировать и откуда у топ-менеджеров берутся сомнения в себе. 💬 Где проходит граница между радикальной честностью и грубостью — читать 📊 Почему сотрудники начинают работать на цифры, а не на результат — читать 🎯 Почему привычка «сделаю сам» мешает руководителю развивать команду — читать 📈 Чем отличаются цель, KPI, показатель и метрика — читать 🎭 Почему синдром самозванца особенно часто проявляется у руководителей — читать Читайте, сохраняйте и делитесь с коллегами, которым интересны управление командами, развитие руководителей и эффективная организация работы.

🌉 Когда разработчик становится архитектором (и почему это больно) Переход из разработки в архитектуру выглядит как повышение. Деньги, статус, уважение. На деле — один из самых тяжёлых переходов в карьере, потому что меняется почти всё. Не должность, а профессия. И многие не готовы к тому, насколько это больно. Давайте честно разберёмся, что происходит с человеком, который «стал архитектором», и почему этот путь нередко заканчивается выгоранием или возвратом обратно в код. Главный шок: ты больше не делаешь В разработке главное удовольствие — видеть результат. Написал, запустил, работает. Моментальная обратная связь, понятный результат, чувство «я сделал это». Архитектор так не работает. Архитектор не пишет код — он его проектирует, описывает, объясняет. Результат его работы появляется через месяцы, а иногда и годы. И чаще всего — в чужом исполнении, которое отличается от задуманного. Это первый и самый тяжёлый шок: ты больше не видишь свой результат сразу. Ты видишь его через призму чужих рук, чужого понимания, чужих ошибок. Многих это ломает. Человек скучает по коду, возвращается «помочь», начинает писать сам — и превращается либо в помеху, либо в «главного разработчика с приставкой архитектор». Ни то, ни другое — не архитектура. Второй шок: ответственность без власти Архитектор отвечает за систему в целом. Но не он нанимает людей, не он ставит сроки, не он решает, что войдёт в очередной выпуск. Он советует, рекомендует, предупреждает. А решения принимают другие. И если решение оказалось неверным — отвечать тоже ему, потому что «он же архитектор, должен был предусмотреть». Это классическая ловушка: ответственность есть, власти — ограниченно. Умение жить в этом напряжении — один из главных навыков архитектора. И он не врождённый. Третий шок: ты работаешь не с кодом, а с людьми В разработке люди — помеха, отвлекающая от кода. В архитектуре — наоборот. Главная работа архитектора — это не диаграммы и схемы. Это переговоры. С разработчиками, которые не понимают, зачем так. С руководителями, которые хотят «проще и быстрее». С заказчиками, которые не понимают, почему «просто кнопку» нельзя сделать без перестройки половины системы. Знаете, что самое тяжёлое? Доказывать очевидное. Архитектор видит риски, которые другие не видят. И объяснять эти риски людям, которые хотят «быстрее и проще», — отдельное искусство. Многие талантливые разработчики, став архитекторами, не справляются именно с этим — не с технической частью, а с человеческой. Четвёртый шок: цена ошибки возрастает на порядки Ошибка разработчика стоит часов или дней. Ошибка архитектора стоит месяцев или лет. Неверное решение на уровне архитектуры может проявиться через год, когда уже всё построено на этом решении, и «переделать» стоит как новый проект. Это тяжёлое давление. Архитектор живёт с постоянным ощущением: «а что, если я не прав?». И в отличие от разработчика, не может быстро проверить — результат проявится нескоро. Что помогает Признать, что переход — это не «продолжение разработки на новом уровне», а смена профессии. С другими навыками, другим складом ума, другим удовольствием от работы. Учиться переговорам, а не только технологиям. Архитектор, который не умеет объяснить и защитить своё решение — бесполезен. Даже если он технически гениален. Найти себе наставника. Человека, который прошёл этот путь и может поделиться опытом. Университетского курса «как стать архитектором» не существует. Реальный опыт — бесценен. И, главное, — не пытаться быть и разработчиком, и архитектором одновременно. Это разные роли. Выберите одну и выполняйте её полноценно. Вывод Архитектор — не «разработчик рангом выше». Это другая профессия. С другими радостями и другими болями. Переход тяжёлый, но если пройти его честно — он открывает уровень влияния, недоступный разработчику. Влияния на то, как система будет работать не сегодня, а через пять лет. Если вы в этом переходе — потерпите. Если думаете о нём — взвесьте. Это не повышение. Это смена пути. Ссылки и контакты Есть еще наш канал в MAX.   #архитектура #карьера #разработка #софт_скиллы #практика

✨ ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ «ШКОЛЫ ПРОЕКТНОГО СПЕЦИАЛИСТА» За прошедшую неделю, 3–9 августа, вышли материалы о границах проекта, баге в пятницу, управленческой перегрузке, адаптации новичков, метриках и развитии senior‑специалистов. 🚧 Как договориться, что НЕ входит в проект Сроки часто срываются не из-за слабой команды, а из-за незаметного расширения состава работ: к первоначальному запросу постепенно добавляют новые задачи, но дедлайн остаётся прежним. Статья о том, как заранее фиксировать границы проекта и обсуждать изменения с заказчиком без конфликта. 🐛 Стадии принятия бага, который всплыл в пятницу вечером Ироничный текст о знакомом сценарии: критическая ошибка появляется в конце рабочей недели, а команда проходит путь от отрицания до кофе, коммита и долгожданного подтверждения от заказчика. 🎙 SADT и IDEF0: как устроена строгая логика процессов Выпуск о методологии функционального моделирования: как через блоки и дуги декомпозировать сложную систему, описывать входы, управление, механизмы и результаты процесса. 📵 Самая незаметная ошибка — быть всегда на связи Постоянные сообщения, звонки и согласования создают ощущение занятости, но вытесняют работу над действительно важными решениями. Автор объясняет, как доступность руководителя приучает команду передавать ему всё больше вопросов. 🌱 Новички в крупном проекте: как не убить проект и не сломать людей «Бросить в воду» — плохая стратегия для сложных проектов, где цена ошибки высока. Материал о том, почему новичкам нужны понятные задачи, контекст, регулярная обратная связь и безопасный способ задавать вопросы. 📊 Как правильные метрики заставляют компанию работать неправильно Люди начинают оптимизировать то, чем их измеряют: поддержка шлёт отписки ради скорости ответа, продажи делают звонки ради плана, а качество уходит на второй план. Текст — о риске подменить бизнес-результат красивыми цифрами. 🧱 Карьерный тупик senior: ты всё умеешь, но некуда расти После уровня senior технический рост становится менее очевидным: редкие позиции архитектора, тимлида или техдиректора подходят не всем. Статья разбирает, почему это не обязательно выгорание и какие траектории развития остаются у опытного специалиста.

🎬 Один проект — два фильма: заказчик и подрядчик Пятница, вечер. Самое время посмеяться над тем, что объединяет нас всех. Один и тот же проект глазами двух сторон — два совершенно разных киносюжета. На совещании Заказчик: «У нас простые процессы, внедрим за пару месяцев». Подрядчик: «У них там ад, но на совещании улыбаемся». В договоре Заказчик: читает одно. Подрядчик: написал другое. Оба: уверены, что договорились. На старте Заказчик: «Ну, начали! Когда первые результаты?». Подрядчик: «Мы ещё не получили доступы. И данные. И НСИ. Хотя бы НСИ». На середине Заказчик: «А можно ещё вот это добавить? Совсем чуть-чуть». Подрядчик: «Опять. Снова. Как всегда». За неделю до сдачи Заказчик: «Кажется, нам нужно пересмотреть подход». Подрядчик: «Мы это предсказывали на старте. В протоколе. На странице три». На сдаче Заказчик: «Ну, в целом похоже на то, что мы хотели». Подрядчик: «Это ровно то, что в спецификации. Которую вы согласовывали. Полгода». Через год Заказчик: «Хорошо, что всё-таки сделали. Хотя было сложно». Подрядчик: «Хорошо, что всё-таки сделали. Хотя было сложно». Знаете, что смешного? На финальной строчке они наконец согласны. Все хотят одного — чтобы проект закончился и заработал. Просто путь к этому каждый видит по-своему. Хорошей пятницы и удачных проектов. Чтобы кино было со счастливым концом. 🍿

SADT появилась ещё в конце 1960-х как способ разложить сложную систему на понятные действия. Без магии: берётся большая функция, например «управлять производством», и раскладывается на более мелкие — закупать, планировать, выпускать, контролировать. Позже подход лёг в основу IDEF0, который до сих пор используют при описании бизнес-процессов, проектировании информационных систем, автоматизации производства и внедрении ERP. Особенно полезно там, где все говорят о процессе разными словами и уже немного запутались. Сильная сторона SADT — она заставляет не просто рисовать квадратики. У каждого действия есть вход, результат, правила управления и ресурсы. Сразу видно: что приходит в процесс, что из него выходит и почему он вообще работает. Но есть и минус. Хорошая SADT-модель требует времени и дисциплины. Если увлечься детализацией, можно нарисовать такую иерархию, в которой потеряется даже автор. Поэтому это не универсальная замена всем схемам, а инструмент для ситуаций, когда сложность действительно надо разложить по полкам.

Разбираем ключевые различия между целью, параметром, метрикой, показателем и KPI. В статье показано, как путаница в терминах приводит к ошибочным решениям, суррогатным «ключевым» показателям и странной системе премирования. И как навести порядок в управленческом языке, связать KPI с критически важными результатами и перестать измерять всё подряд только потому, что это легко выгружается в Excel? Читать полностью: Цель, KPI или метрика: почему менеджеры называют одним словом разные вещи.

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

Как правильные метрики заставляют компанию работать неправильно Странная штука происходит с людьми, когда им ставят чёткую цель. Они начинают в неё попадать. Любой ценой. Даже если сама цель в итоге приносит компании вред. Вот, скажем, отдел поддержки. Поставили метрику — «время ответа клиенту». Отличная же цель, что плохого. И правда ничего, пока через полгода не выясняется, что сотрудники просто шлют отписки в первую же минуту. Формально — ответ дан, метрика закрыта. По сути — клиент в бешенстве. Или продажи. Завели план по звонкам. Менеджеры начинают звонить кому угодно и как угодно, лишь бы набить цифру. Качество разговора, нужен ли клиенту этот продукт вообще — мимо. Главное — отзвонить. Это же не со зла. Люди просто реагируют на то, чем их измеряют. Поставили одно — будут делать одно. Поставили другое — другое. А то, что не измеряется, тихо отмирает, потому что за него никто не отвечает. И вот парадокс. Чем умнее выглядит система метрик на бумаге, тем сильнее риск, что вся компания начнёт под неё подстраиваться. Не под реальность, а под табличку. Потому что табличка простая, а реальность сложная. И людям свойственно выбирать простое. Самое незаметное тут — что никто не задумывается, чего именно мы на самом деле хотим. Быстрого ответа или решённой проблемы? Звонка или продажи? Цифры или результата? Это разные вещи. И если их перепутать — метрика начнёт работать против тебя, очень старательно и очень послушно.

Телефонный спам победят за счёт бизнеса Телефонный спам, похоже, решили победить самым понятным для бизнеса способом — сделать каждый звонок платным и подписанным. Мобильные операторы начали блокировать массовые и автоматические вызовы, если компания не заключила договор на маркировку. В среднем такая маркировка стоит около 30 копеек за каждую попытку. Даже если человек не ответил. По прежним оценкам, общие расходы российского бизнеса могут превысить 20 млрд рублей. А количество звонков с признаками массовости, поступающих из сетей фиксированной связи, с начала 2026 года выросло на 155%. Такие данные приводит «Коммерсантъ». На первый взгляд, всё логично. Звонит компания — на экране должно быть понятно, кто именно. Не загадочный номер, не «служба безопасности чего-то», а нормальное название. Мошенникам сложнее, людям спокойнее. Но есть одна бытовая неприятность. Вместе со спамом под блокировку может попасть вполне нужный звонок: из клиники, службы доставки, банка, сервисного центра. Просто где-то не оформили договор, не передали данные или операторы не договорились между собой, как ими обмениваться. Получается занятная картина. Раньше компании платили за то, чтобы дозвониться. Теперь ещё и за право быть узнанными. Причём платить приходится даже за короткое «абонент не отвечает». Скорее всего, дешёвых обзвонов действительно станет меньше. Только доверие к звонкам одной подписью не возвращается. Если компания звонит пять раз за вечер, надпись с её названием делает раздражение не меньше, а просто более адресным. Возможно, главный итог маркировки именно в этом. Теперь хотя бы понятно, на кого злиться.