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

📌 Дайджест «Школы менеджера организации»

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

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

#менеджмент #управлениекачеством #принятиерешений #команда #стратегия #организационноеразвитие

«Мы тут все на ты». А говорить всё равно страшно

Есть устойчивое убеждение: хороший руководитель должен быть «своим». Без лишней дистанции, на «ты», всегда рядом. Звучит приятно. Только близость сама по себе почему-то не делает разговор честнее.

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

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

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

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

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

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

📌 Дайджест «Школы проектного специалиста»

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

🔹Сорок лет модели Фалера: почему обещание серебряной пули не осуществилось
Новые инструменты делают разработку удобнее, но не отменяют фундаментальную сложность корпоративных систем: много участников, уникальные правила и множество взаимосвязей.
🔹Почему команды срывают сроки, даже когда в них работают сильные специалисты
Проблема часто не в компетенциях, а в постоянном переключении между сообщениями, встречами, срочными запросами и чужими задачами.
🔹Клиент не будет ждать. Он просто откроет другое предложение
Коммерческое предложение — не отчёт о внутренней проработке: если затянуть с ответом, клиент сравнит альтернативы и выберет того, кто быстрее снизил для него неопределённость.
🔹Почему схема процесса может неожиданно развалиться
Схема описывает процесс так, как о нём рассказывают, но реальная работа может жить в неформальных договорённостях, почте и привычках сотрудников.
🔹Почему точные требования иногда опаснее неопределённости
Преждевременно зафиксированные требования могут привести к системе, которая формально соответствует ТЗ, но не помогает бизнесу в реальной работе.
🔹«Нам не нужен ваш руководитель проекта»: как меняется спрос на ИТ-услуги
Заказчики всё чаще хотят сами управлять приоритетами и сохранять экспертизу внутри компании; поэтому на старте особенно важно договориться о ролях, правах на решения и ответственности за результат.
🔹5 правил управления проектами, о которых вспоминают поздно
Короткое видео о сроках, изменениях объёма работ, своевременной эскалации проблем, живом плане и выводах перед следующим запуском.
🔹PRINCE2: что спасло проект после аварии
Кейс прокладки газопровода под рекой: как PRINCE2 помогает распределять роли, контролировать этапы, управлять рисками и качеством в сложных технических условиях.

#управлениепроектами #проектныйменеджмент #ИТпроекты #требования #бизнесанализ #PRINCE2 #управлениекомандой

Доброе утро, друзья!

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

А нового, возможно, и не нужно. Иногда достаточно чуть повернуть голову.

Знакомый человек может оказаться будущим партнёром по делу. Навык, который годами считался обычным, вдруг становится востребованным. Привычная рабочая проблема — идеей для нового проекта. Даже случайный разговор за кофе иногда даёт больше, чем длинное совещание с красивой повесткой.

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

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

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

Иногда это все, что нужно для полного счастья.

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

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

Знакомая картина. Руководитель получает неприятное письмо и тут же пишет ответ. Жёсткий. Аргументированный. Через десять минут понимает, что отправлять его не стоило. Проблема ведь была не в отсутствии ума. Ума хватало. Не хватило маленького промежутка между раздражением и действием.

Вот этот промежуток и есть самое полезное место для осознанности.

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

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

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

Классная «плоскостная» демонстрация работы гравитации.

Пирамида тестов хороша. Пока не пришла в 1С

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

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

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

Обычно её пытаются «исправить» количеством тестов. Но дело вообще не в красивой пропорции. Главная ценность проверки в другом: насколько быстро она отвечает на вопрос — что именно сломалось. Если падает сценарий из двадцати шагов и после этого несколько часов ищут причину, сама цифра покрытия мало утешает.

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

И вот что интересно. Иногда перевёрнутая пирамида для 1С вполне разумна. Доработка может быть разовой, а создание идеального набора тестов окажется дороже самой работы.

Пожалуй, хорошая система тестирования измеряется не формой пирамиды. А временем между изменением кода и понятным ответом: всё работает или вот здесь сломалось.

Водопад умер. Но почему-то продолжает работать

Водопад хоронят уже четверть века. в 2001 г. вышел Agile-манифест, появились спринты, доски, итерации, гибкие команды. А потом открывается план большого внедрения — и там всё знакомо: требования, проектирование, разработка, тестирование, сдача. Разве что слова стали современнее.

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

Заказчик в такой системе покупает не столько результат, сколько предсказуемость. Фраза «через полгода будет вот это» звучит спокойнее, чем «через две недели посмотрим и решим, что делать дальше». Хотя первое обещание иногда гораздо менее честное.

У гибкости вообще есть неприятная особенность, о которой любят забывать. Она требует постоянного участия заказчика. Надо смотреть результат, принимать решения, менять приоритеты. Регулярно. А у финансового директора, производственника или главного бухгалтера обычно есть ещё одна небольшая проблема — основная работа.

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

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

Пожалуй, спор давно не про «водопад или гибкость». Вопрос проще и неприятнее: сколько неопределённости организация действительно готова терпеть. Не на презентации. В договоре, бюджете и ежедневной работе.

Сотрудница пять лет не была в отпуске — у нее накопилось 135 дней отдыха.

Используйте отпуск вовремя!

Ведь если компания спокойно работает без человека несколько месяцев, невольно возникает вопрос: насколько сотрудник действительно незаменим?

⏱️ Клиент не будет ждать. Он просто откроет другое предложение

Реальный сюжет из коммерческой рутины. Клиент просит коммерческое предложение и называет срок — условно до среды. И дальше начинается внутренняя работа команды: а давайте ещё уточним объём, а вот тут не уверены, а можно ли подешевле, а вдруг они имели в виду другое.

Желание собрать побольше информации — это не порок, это нормальная реакция на неопределённость. Тем более что клиент и сам её привносит: у него внутри разборки с начальством, конкуренты и сомнения в собственном выборе.

Но вот в чём штука. Пока команда уточняет объёмы по телефону или в переписке, клиент не сидит сложа руки. Он открывает другие предложения. Их обычно три-пять, и он выбирает не лучший, а тот, где риск для него меньше. Отсутствие предложения — это не ноль, это просто «не наш выбор». Тут даже считать ничего не надо.

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

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

Единственный честный ход — зафиксировать допущения: объёмы, состав работ, срок поставки, что считать включённым. Строчка «принимаем, что…» в КП возможно превращается потом в пункт договора, а на старте это просто строка, которая снимает бо́льшую часть будущих претензий.

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

Ответ «давайте всё изучим» тут проигрывает ответу «вот эти три вещи точно, остальное — после первого этапа». Конкретика снимает страх быстрее данных.

И уж точно не помогает способ затянуть с ответом и при этом всё изучить до винтика. Так с клиентами не работает. Им нужен ответ в срок, а от нас — реалистичная, а не идеальная оценка.

Хорошее предложение — это не доказательство, что всё известно. Это приглашение начать диалог. И кто приглашает первым, тот обычно и остаётся в памяти.

Почему схема процесса может неожиданно развалиться

Бывает, что аналитик может потратить четыре дня на описание процесса согласования договора. Где нарисованы все этапы, описаны точки, где нужно решение, поставлены вопросы, которые раньше висели в воздухе. Модель получилась на восьми страницах, её показали заказчику, и те кивнули — мол, наконец-то всё по полочкам.

Через три недели на совещании выяснилось, что согласование давно идёт иначе. Не по модели.

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

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

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

Что из этого следует?

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

Второе. Старое никуда не денется, но понимание придёт только в разговоре с живым человеком из процесса. Именно из процесса, а не из соседнего отдела. Там, где делают руками, а не согласовывают письмами.

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

И последнее, спорное. Иногда описание нужно не ради схемы. Его цель — разобраться самому. Разобрался, и можно выдохнуть, не защищая результат.

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

Почему дешёвое внедрение дорожает после победы в конкурсе

На конкурсе самое дешёвое предложение выглядит убедительно — до начала переноса данных и испытаний. Кто оплачивает разницу между ценой и реальным объёмом работ и какой вопрос стоит задать до выбора подрядчика?

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

📌 Дайджест «Школы менеджера организации»

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

🔹Стратегия или самообман: что происходит на корпоративных сессиях
О том, почему одни стратегические сессии приводят к реальным изменениям, а другие заканчиваются презентацией, которую больше никто не открывает.
🔹Невидимая работа руководителя: кто потом объясняет принятое решение
Про то, что само решение занимает минуты, а основная работа начинается потом: объяснить его клиенту, команде, смежникам и руководству.
🔹Как понять, что показатель стал целью и начал портить процесс
О том, как полезный KPI постепенно превращается в самоцель и начинает искажать работу команды.
🔹Чем грозит запуск ИТ-проекта без Устава
Разбор того, почему отсутствие устава почти незаметно превращает управление в постоянные конфликты и исправление последствий.
🔹«А что ты предлагаешь?» — вопрос, который тормозит решение проблемы
Про то, как привычка требовать готовое решение от сотрудника заставляет людей скрывать реальные проблемы.

#управлениепроектами #стратегия #KPI #уставпроекта #менеджмент #команда

📌 Дайджест «Школы проектного специалиста»

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

🔹Экспертное мышление — это не талант, а набор рабочих привычек
Шесть привычек из консалтингового подхода McKinsey: структурировать проблему, начинать с вывода, выделять главное по принципу 80/20 и проверять гипотезы.
🔹Парк юрского периода — компания, которая выросла на старых процессах, рискует вымереть
О том, почему отлаженные процессы и привычная иерархия могут стать слабостью, если организация не успевает адаптироваться к изменениям вокруг.
🔹«Клиент всегда прав» — красивая фраза, которая ломает и команду, и продукт
Почему профессиональная забота о клиенте иногда означает вовремя сказать «нет» требованию, которое вредит продукту, срокам или качеству.
🔹Конфликт без крика: как цели и роли незаметно сталкивают людей
Конфликты в проекте часто возникают не из-за личных качеств, а из-за разных целей, неясных полномочий и отсутствия договорённостей о принятии решений.

#управлениепроектами #проектныйменеджмент #экспертноемышление #команда #клиентскийсервис #управление

Памятка менеджеру: как гарантированно завалить простой проект

Сохрани себе. Особенно если хочешь однажды посмотреть на команду и спросить:
«А почему мы опять не успели?»

1. Объяви дедлайн
Поставь дату в таск-трекере. Лучше красным.
Неважно, верит ли в неё команда. Неважно, обсуждали ли вы ресурсы, зависимости и реальные ограничения. Главное — чтобы дата была. Дата создаёт ощущение контроля.
Если задача просрочена, просто перекрась её в более тревожный оттенок. В какой-то момент красный цвет перестанут замечать, но это уже не твоя проблема.
2. Соглашайся на все «маленькие дополнения»
«Давайте просто добавим ещё одну фичу».
Соглашайся. Ты же не хочешь выглядеть человеком, который мешает бизнесу.
Потом выяснится, что кнопке нужен новый сценарий, сценарию — отдельная логика, логике — ещё три согласования, а всё вместе необходимо срочно протестировать до пятницы.
Но не переживай. Формально это всё ещё одна маленькая доработка.
3. Не сообщай о проблемах слишком рано
Разработчик заметил, что решение разваливается? Отлично.
Пусть сначала попробует разобраться сам. Потом обсудит с коллегой. Потом вы подождёте ещё пару дней — вдруг действительно само рассосётся.
Заказчику сообщи, когда проблема станет достаточно крупной, чтобы её уже нельзя было скрыть за словами «есть небольшой нюанс».
Именно так формируется доверие.
4. Разработай идеальную методологию
Проведи несколько встреч.
Создай красивую презентацию. Добавь матрицу ответственности, дорожную карту, цветные статусы и, если останутся силы, отдельный слайд про прозрачность.
Не проверяй, пользуется ли этим кто-нибудь в реальной работе.
Живой процесс, который команда действительно соблюдает, — это слишком просто. Настоящий менеджмент должен быть сложным, желательно настолько, чтобы его нельзя было применить без специального совещания.
5. После провала напиши разбор
Подробно.
С причинами, выводами, ответственными и мерами по улучшению. Отдельно укажи, что в следующий раз необходимо «усилить коммуникацию».
Положи документ в папку с названием вроде Postmortem_Final_v7.
Перед следующим проектом не открывай.
Если кто-нибудь спросит, учли ли вы прошлый опыт, уверенно ответь:
«Да, конечно. Мы провели работу над ошибками».
Это универсальная фраза. Она звучит убедительно и не требует доказательств.
Главное правило
Не пытайся сделать проект предсказуемым.
Предсказуемость лишает менеджера возможности героически спасать ситуацию в последний момент. А без этого зачем вообще нужны дедлайны, статусы и экстренные созвоны?

P.S. Если ваша команда узнаёт себя в этой памятке — не спешите проводить ретроспективу. Сначала убедитесь, что кто-то потом действительно её прочитает.

Экспертное мышление — это не талант, а набор рабочих привычек

В McKinsey и других консалтинговых компаниях людей учат не просто «много анализировать», а быстро превращать сложность в понятное решение.
Структурировать проблему. Начинать с вывода. Отвечать за результат. Искать главное по принципу 80/20. Постоянно задавать себе вопрос «И что из этого следует?». И проверять гипотезы вместо того, чтобы собирать данные «на всякий случай».

Собрал в инфографике 6 привычек экспертного мышления в подходе McKinsey.

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

Язык ускоряется: почему мы тараторим быстрее бабушек

Ученые из Института русского языка сказали, что мы теперь говорим быстрее, чем наши бабушки с дедушками. И знаете, в чем причина? Гласные стали короче. То есть не то чтобы мы специально торопимся, просто сам язык так устроен – система гласных упрощается, а согласных становится больше. Звучит как какая-то математика, но если вдуматься, все логично.

В древнерусском языке гласных было куча. Потом они постепенно исчезали, и вот сейчас их осталось мало. Дальше сокращать уже некуда, поэтому начали меняться сами звуки – они стали короче. Отсюда и скорость речи. Часто слышишь от старого поколения: «Куда ты тараторишь, ничего не понятно!» А нам кажется, что говорим нормально. Оказывается, это не характер, а фонетика. Ну, отчасти.

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

Но есть в этом что-то грустное. Бабушкино «слишком быстро» – это ведь не просто слова. Это целый разрыв между поколениями. Мы торопимся, глотаем звуки, а они помнят другую музыку речи. И эту музыку уже не вернуть, как ни старайся. Язык не спрашивает разрешения, он просто меняется. А мы просто говорим. Быстрее, чем раньше. И даже не замечаем.