Как я не долетел на конференцию, но все-таки выступил
На прошлой неделе я собрался в Ижевск, чтобы выступить на конференции «Инструменты повышения операционной эффективности бизнеса» с докладом о сборке технологии управления проектами. Купил билеты на самолет, приехал в Домодедово, расположился в зале ожидания, но… Наш самолет не успел выполнить посадку и улетел на запасной аэродром в Нижний.
В общем, просидел я в аэропорту около 12 часов. При этом мы несколько раз заходили в салон самолета и снова выходили – то закрывалось воздушное пространство, то время пилота вышло, то еще что-то пошло не так. И на протяжении всего этого времени нам говорили «сейчас все будет, подождите еще чуть-чуть». Каждый раз, когда я это слышал, в голову приходила аналогия с большим сложным проектом, где кто-то сильно накосячил, но продолжает кормить стейкхолдеров завтраками🤡
Рейс должен был состояться в 9 вечера. Наступило 8 утра… Приехала новая бригада и нас снова запустили в салон самолета. И, покатав нас какое-то время по летному полю, пилот снова попросил покинуть самолет🤬
Немного раздосадованный и уставший я вернулся домой и выступил на конференции онлайн. Спасибо слушателям за вовлеченность и вопросы😁
На прошлой неделе я собрался в Ижевск, чтобы выступить на конференции «Инструменты повышения операционной эффективности бизнеса» с докладом о сборке технологии управления проектами. Купил билеты на самолет, приехал в Домодедово, расположился в зале ожидания, но… Наш самолет не успел выполнить посадку и улетел на запасной аэродром в Нижний.
В общем, просидел я в аэропорту около 12 часов. При этом мы несколько раз заходили в салон самолета и снова выходили – то закрывалось воздушное пространство, то время пилота вышло, то еще что-то пошло не так. И на протяжении всего этого времени нам говорили «сейчас все будет, подождите еще чуть-чуть». Каждый раз, когда я это слышал, в голову приходила аналогия с большим сложным проектом, где кто-то сильно накосячил, но продолжает кормить стейкхолдеров завтраками🤡
Рейс должен был состояться в 9 вечера. Наступило 8 утра… Приехала новая бригада и нас снова запустили в салон самолета. И, покатав нас какое-то время по летному полю, пилот снова попросил покинуть самолет🤬
Немного раздосадованный и уставший я вернулся домой и выступил на конференции онлайн. Спасибо слушателям за вовлеченность и вопросы😁
Главная ошибка самых опытных руководителей проектов
В прошлом году мы с командой PMLogix проводили диагностику проектного управления в крупной девелоперской компании (часть 1 тут). Проблема – потеря внушительной части прибыли из-за увеличения сроков строительства. А именно: требования к проектам постоянно меняются, и новые затраты на переделки «съедают» запланированную маржу.
Кажется очевидным, что если проблема со сроками из-за разрастания требований, то и диагностировать тут нечего – и так все понятно. Однако смысл глубинной диагностики заключается в определении первопричин возникновения проблем, которые часто могут быть очень неожиданными.
Подробностями поделюсь позже. Но вот, что я хочу отметить сейчас по мотивам этого кейса – даже самые опытные, мудрые и профессиональные руководители проектов часто совершают одну и ту же ошибку. Какую? Используют проектные документы по принципу «чтобы было». И нужные, полезные документы превращаются из инструментов управления в бесполезную формальность.
💡 Пример: в реестре стейкхолдеров есть раздел «интересы сторон», где прописывается, какую информацию нужно предоставлять всем заинтересованным сторонам по ходу проекта. Если мы пишем в этом разделе что-то вроде «предоставлять своевременную информацию о ходе проекта», то это чистая абстракция. Которая по факту означает, что руководство не получит нужную информацию в нужное время для принятия нужных решений. То есть данные о прогрессе проекта, отклонениях, маржинальности на текущую дату и прочее. И в итоге важные решения будут приниматься не на основе достоверных цифр, а «с потолка».
Почему так происходит? Часто недобросовестное отношение к использованию документов кроется в высокой загрузке руководителей. Понятно, что им надо вывозить проект, а не вычитывать формулировки в документах. Но на самом деле первопричина этой проблемы обычно заключается в том, что руководители просто не видят практической пользы от всей этой «бюрократии».
Коллеги, завтра на вебинаре по внедрению новых правил управления расскажу, как это делать с умом – чтобы ваши сотрудники понимали, зачем от них требуют то, что требуют, и видели ценность в «бумажной» работе. Регистрируйтесь здесь.
В прошлом году мы с командой PMLogix проводили диагностику проектного управления в крупной девелоперской компании (часть 1 тут). Проблема – потеря внушительной части прибыли из-за увеличения сроков строительства. А именно: требования к проектам постоянно меняются, и новые затраты на переделки «съедают» запланированную маржу.
Кажется очевидным, что если проблема со сроками из-за разрастания требований, то и диагностировать тут нечего – и так все понятно. Однако смысл глубинной диагностики заключается в определении первопричин возникновения проблем, которые часто могут быть очень неожиданными.
Подробностями поделюсь позже. Но вот, что я хочу отметить сейчас по мотивам этого кейса – даже самые опытные, мудрые и профессиональные руководители проектов часто совершают одну и ту же ошибку. Какую? Используют проектные документы по принципу «чтобы было». И нужные, полезные документы превращаются из инструментов управления в бесполезную формальность.
Почему так происходит? Часто недобросовестное отношение к использованию документов кроется в высокой загрузке руководителей. Понятно, что им надо вывозить проект, а не вычитывать формулировки в документах. Но на самом деле первопричина этой проблемы обычно заключается в том, что руководители просто не видят практической пользы от всей этой «бюрократии».
Коллеги, завтра на вебинаре по внедрению новых правил управления расскажу, как это делать с умом – чтобы ваши сотрудники понимали, зачем от них требуют то, что требуют, и видели ценность в «бумажной» работе. Регистрируйтесь здесь.
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Что важнее – дизайн методологии или качество её внедрения?
Вот с такого каверзного вопроса я начал свой вчерашний вебинар.
Однозначного ответа здесь нет, потому что:
👉 если методология не подходит компании (не закрывает потребности, не учитывает контекст проектов, особенности процессов), то внедрение такой методологии будет провалено;
👉 если же мы разработаем качественную методологию, но не проведем нужные мероприятия по вовлечению людей, включая руководство, то и её внедрение тоже будет провалено.
Дизайн методологии и процесс её внедрения – это инь и ян. Две части одного целого, необходимые для того, чтобы все в итоге заработало, а новые правила управления приносили пользу проектам. Так что, процесс внедрения всегда идет рука об руку с процессом разработки.
🔥 Вчерашний вебинар побил все рекорды по длительности: 1 час и 40 минут плотного структурированного контента. Тем, кто досмотрел до конца и задал вопросы – отдельный респект.
Запись вебинара доступна в боте PMLogix здесь. Обязательно посмотрите его вместе с моим вебинаром по разработке кастомной системы управления проектами, потому что успех внедрения напрямую зависит от качества самой методологии.
Вот с такого каверзного вопроса я начал свой вчерашний вебинар.
Однозначного ответа здесь нет, потому что:
👉 если методология не подходит компании (не закрывает потребности, не учитывает контекст проектов, особенности процессов), то внедрение такой методологии будет провалено;
👉 если же мы разработаем качественную методологию, но не проведем нужные мероприятия по вовлечению людей, включая руководство, то и её внедрение тоже будет провалено.
Дизайн методологии и процесс её внедрения – это инь и ян. Две части одного целого, необходимые для того, чтобы все в итоге заработало, а новые правила управления приносили пользу проектам. Так что, процесс внедрения всегда идет рука об руку с процессом разработки.
🔥 Вчерашний вебинар побил все рекорды по длительности: 1 час и 40 минут плотного структурированного контента. Тем, кто досмотрел до конца и задал вопросы – отдельный респект.
Запись вебинара доступна в боте PMLogix здесь. Обязательно посмотрите его вместе с моим вебинаром по разработке кастомной системы управления проектами, потому что успех внедрения напрямую зависит от качества самой методологии.
Парацельс ПМ – готовый метод управления проектами, на базе которого можно создать собственную технологию реализации проектов. Уже много лет успешно применяю его в своих консалтинговых кейсах. И сегодня поделюсь одним из ключевых принципов метода, который позволяет:
🚀 быстро внедрять новые правила управления с минимальным сопротивлением со стороны сотрудников;
🚀 получать первые результаты от внедрения уже в ходе разработки;
🚀 делать методологию понятной, небюрократичной и максимальной практичной.
Итак, главный принцип – нужно делать то, что нужно, а что не нужно – делать не нужно 😁 (это правило, которому меня когда-то научила моя начальница, директор по консалтингу Светлана Шлыкова в компании Frontstep, немного перефразировав цитату Винни-Пуха).
💡 Казалось бы очевидно, но на самом деле это ключевая проблема большинства готовых фреймворков. А именно: использование стандартного набора аспектов (областей внимания), что в итоге порождает бесполезную бюрократию, формальное заполнение шаблонов, трату времени и негатив со стороны руководителей проектов.
Да, в готовом решении Парацельс у нас есть минималистичный набор аспектов (цели и эффекты, содержание и качество, сроки и т.д.), которыми важно управлять практически в любых типах проектов.
Однако этот набор всегда трансформируется в зависимости от специфики конкретной компании и ее внутренних процессов. Например, если у вас работают выделенные команды, вам не нужно уделять особое внимание такому аспекту, как ресурсы. Или же если бюджет ваших проектов зависит от банковских займов (например, девелоперские проекты), то одного стандартного аспекта бюджет будет недостаточно (нужно вводить дополнительный, например – финансирование).
Так что, отказываясь от стандартного набора и адаптируя состав аспектов под конкретную организацию, мы создаем максимально простую, но при этом закрывающую реальные потребности проектов и организации проектную методологию.
А еще, так как каждый аспект железобетонно обоснован, потому что решает конкретные проблемы, договориться о важности уделять ему внимание с помощью новых правил управления намного проще. И это тоже критически важно, так как работоспособность любого регламента зависит от того, является ли он результатом реальных договоренностей или же директивным требованием.
🔹 Подробнее о методе Парацельс ПМ, для каких проектов он подходит лучше всего и из чего состоит, читайте здесь
🔹 Здесь можете скачать руководство по методу, чтобы начать применять его для управления проектами самостоятельно
🔹 А если хотите подробнее разобраться в методе и получить от меня личную консультацию, записывайтесь здесь (возможны два формата)
🚀 быстро внедрять новые правила управления с минимальным сопротивлением со стороны сотрудников;
🚀 получать первые результаты от внедрения уже в ходе разработки;
🚀 делать методологию понятной, небюрократичной и максимальной практичной.
Итак, главный принцип – нужно делать то, что нужно, а что не нужно – делать не нужно 😁 (это правило, которому меня когда-то научила моя начальница, директор по консалтингу Светлана Шлыкова в компании Frontstep, немного перефразировав цитату Винни-Пуха).
Да, в готовом решении Парацельс у нас есть минималистичный набор аспектов (цели и эффекты, содержание и качество, сроки и т.д.), которыми важно управлять практически в любых типах проектов.
Однако этот набор всегда трансформируется в зависимости от специфики конкретной компании и ее внутренних процессов. Например, если у вас работают выделенные команды, вам не нужно уделять особое внимание такому аспекту, как ресурсы. Или же если бюджет ваших проектов зависит от банковских займов (например, девелоперские проекты), то одного стандартного аспекта бюджет будет недостаточно (нужно вводить дополнительный, например – финансирование).
Так что, отказываясь от стандартного набора и адаптируя состав аспектов под конкретную организацию, мы создаем максимально простую, но при этом закрывающую реальные потребности проектов и организации проектную методологию.
А еще, так как каждый аспект железобетонно обоснован, потому что решает конкретные проблемы, договориться о важности уделять ему внимание с помощью новых правил управления намного проще. И это тоже критически важно, так как работоспособность любого регламента зависит от того, является ли он результатом реальных договоренностей или же директивным требованием.
🔹 Подробнее о методе Парацельс ПМ, для каких проектов он подходит лучше всего и из чего состоит, читайте здесь
🔹 Здесь можете скачать руководство по методу, чтобы начать применять его для управления проектами самостоятельно
🔹 А если хотите подробнее разобраться в методе и получить от меня личную консультацию, записывайтесь здесь (возможны два формата)
Please open Telegram to view this post
VIEW IN TELEGRAM
«Это лучшее, что я услышал на тему управления проектами за последнее время.»
«Встреча помогла мне добавить уверенности в том, что подход Парацельс более правильный, но при грамотном внедрении.»
«Повысился уровень доверия к методологии Парацельс ПМ, потому что когда что-то новое появляется, это всегда вызывает недоверие. Сейчас будет уже проще двигаться в сторону внедрения Парацельса как методологии управления проектами. Сначала начнем в рамках отдела внедрения, потом на уровне управления, потом, возможно, и на уровне всей компании.»
Вот такой отзыв получил о моем недавнем вебинаре про Парацельс ПМ и личной сессии от коллеги по цеху. Приятно получать такие отзывы 🤝 Если хотите попасть ко мне на бесплатную личную консультацию, переходите в бот PMLogix – там доступны два формата сессии.
#отзывы
«Встреча помогла мне добавить уверенности в том, что подход Парацельс более правильный, но при грамотном внедрении.»
«Повысился уровень доверия к методологии Парацельс ПМ, потому что когда что-то новое появляется, это всегда вызывает недоверие. Сейчас будет уже проще двигаться в сторону внедрения Парацельса как методологии управления проектами. Сначала начнем в рамках отдела внедрения, потом на уровне управления, потом, возможно, и на уровне всей компании.»
Вот такой отзыв получил о моем недавнем вебинаре про Парацельс ПМ и личной сессии от коллеги по цеху. Приятно получать такие отзывы 🤝 Если хотите попасть ко мне на бесплатную личную консультацию, переходите в бот PMLogix – там доступны два формата сессии.
#отзывы
Новый кейс🔥
Помните, я рассказывал вам про кейс диагностики проектного управления в девелоперской компании?
Сегодня делюсь подробностями:
🔹 зачем нужна диагностика проектного управления, если «и так понятно», почему сроки постоянно сдвигаются;
🔹 особенности и сложности реализации девелоперских проектов – от неуправляемого разрастания требований до использования заемных средств;
🔹 почему наш заказчик не мог справиться с постоянными срывами внутренних графиков самостоятельно;
🔹 из чего состоит глубинная диагностика проектного управления и почему для определения первопричин проблем важно привлекать функциональных руководителей в том числе;
🔹 как формировать пул вопросов для интервью и какие методы групповой оценки мы используем; о чем говорит большой разброс мнений при оценке одной и той же области управления;
🔹 какие первопричины проблем мы выявили по результатам интервью и анализа документов;
🔹 что важно учесть при составлении новых требований к проектному управлению, чтобы заказчик мог их реально внедрить, не перегружая операционные процессы компании.
Переходите по ссылке и читайте. Жду ваших комментариев и вопросов🤝
#кейсы
Помните, я рассказывал вам про кейс диагностики проектного управления в девелоперской компании?
Сегодня делюсь подробностями:
🔹 зачем нужна диагностика проектного управления, если «и так понятно», почему сроки постоянно сдвигаются;
🔹 особенности и сложности реализации девелоперских проектов – от неуправляемого разрастания требований до использования заемных средств;
🔹 почему наш заказчик не мог справиться с постоянными срывами внутренних графиков самостоятельно;
🔹 из чего состоит глубинная диагностика проектного управления и почему для определения первопричин проблем важно привлекать функциональных руководителей в том числе;
🔹 как формировать пул вопросов для интервью и какие методы групповой оценки мы используем; о чем говорит большой разброс мнений при оценке одной и той же области управления;
🔹 какие первопричины проблем мы выявили по результатам интервью и анализа документов;
🔹 что важно учесть при составлении новых требований к проектному управлению, чтобы заказчик мог их реально внедрить, не перегружая операционные процессы компании.
Переходите по ссылке и читайте. Жду ваших комментариев и вопросов🤝
#кейсы
Формат 1. Сессия Ясности
Разбираем вашу ситуацию и отвечаем на главный вопрос: что мешает ее разрешить и что с этим делать.
Что вы получите в зависимости от запроса:
🚀 рекомендации по целям проектного менеджмента, проектного офиса в вашей организации
🚀 экспресс-оценку проблем и барьеров, с которыми вы сталкиваетесь
🚀 рекомендации по способам решения проблем в проектной деятельности и ближайшим шагам по их устранению
🚀 рекомендации по критериям выбора ИТ-решений по управлению проектами или стратегии их внедрения
🚀 понимание, как вовлечь руководителей в проектную деятельность и преодолеть сопротивление сотрудников организации при внедрении проектной методологии
🚀 мощный импульс к действиям по улучшению своей ситуации и решению затруднений
Формат 2. Методологическая экскурсия
Покажу, как устроена наша методология изнутри, и помогу понять, как может выглядеть ваша.
Вам будет полезна экскурсия, если вы хотите:
🚀 увидеть внутреннюю методологию управления проектами PMLogix
🚀 обсудить её опыт разработки, использования и развития
🚀 увидеть реальную клиентскую методологию (обезличенную) с разбором элементов
🚀 узнать, что нужно сделать, чтобы оценить «идеальность» своей методологи
Кому моя консультация будет полезнее всего?
🔹 Собственникам организаций
🔹 Руководителям проектных офисов и всем, кто занимается построением системы управления проектами и изменениями
🔹 Топ-менеджерам, отвечающим за реализацию портфеля проектов, трансформации или стратегии развития
#отзывы
Чтобы записаться — перейдите в бот PMLogix и заполните небольшую анкету.
Please open Telegram to view this post
VIEW IN TELEGRAM
Как подстраховаться от неудачного опыта с подрядчиками?
Решила как-то раз компания X внедрить корпоративную ИТ-систему для автоматизации логистических процессов. Все сделали как надо: просчитали экономические эффекты, назначили руководителя проекта, выделили команду, нашли подрядчика из топ-3 самых экспертных и известных… Согласовали объем, подписали контракт и приступили к работе.
Прошло три месяца. Потом полгода. Минуло девять месяцев. Работа идет полным ходом, однако понимания, на какой стадии находится проект по внедрению и когда все это закончится нет ни у заказчика, ни у подрядчика.
Казалось бы, у выбранного ИТ-интегратора огромный опыт и высокая экспертиза… Что же пошло не так?
А вот что:
⚡️ требования к системе постоянно разрастаются и добавляются новые функции, не предусмотренные договором;
⚡️ отсутствуют актуальные планы и отчеты, из-за чего непонятен прогресс проекта и нет информации по отклонениям;
⚡️ команда подрядчика фокусируется только на текущих задачах, игнорируя планирование;
⚡️ нерегулярные встречи по проекту, которые проводятся без опоры на отчеты и превращаются в дискуссии с непредсказуемым содержанием и т.д.
В итоге, конечно, систему доделали и внедрили спустя X месяцев, но какой ценой?
🔥 Коллеги, всем советую послушать мой новый подкаст, где затрагивается эта тема. А именно: даже если у подрядчика высокая экспертность в предметной области, это еще не гарантия продвинутых навыков в управлении, а также успеха проекта.
⭐️ Гость подкаста – руководитель отдела планирования и контроля проектов SetlTech Сергей Стадник, который в прошлом году привлек меня с командой PMLogix к разработке кастомной технологии управлении проектами.
Сергей поделился, как новый подход к управлению помогает не только избегать сюрпризов с подрядчиками, но и наращивать компетенции внутри компании.
Смотрите подкаст на Youtube или в ВК видео.
Решила как-то раз компания X внедрить корпоративную ИТ-систему для автоматизации логистических процессов. Все сделали как надо: просчитали экономические эффекты, назначили руководителя проекта, выделили команду, нашли подрядчика из топ-3 самых экспертных и известных… Согласовали объем, подписали контракт и приступили к работе.
Прошло три месяца. Потом полгода. Минуло девять месяцев. Работа идет полным ходом, однако понимания, на какой стадии находится проект по внедрению и когда все это закончится нет ни у заказчика, ни у подрядчика.
Казалось бы, у выбранного ИТ-интегратора огромный опыт и высокая экспертиза… Что же пошло не так?
А вот что:
⚡️ требования к системе постоянно разрастаются и добавляются новые функции, не предусмотренные договором;
⚡️ отсутствуют актуальные планы и отчеты, из-за чего непонятен прогресс проекта и нет информации по отклонениям;
⚡️ команда подрядчика фокусируется только на текущих задачах, игнорируя планирование;
⚡️ нерегулярные встречи по проекту, которые проводятся без опоры на отчеты и превращаются в дискуссии с непредсказуемым содержанием и т.д.
В итоге, конечно, систему доделали и внедрили спустя X месяцев, но какой ценой?
🔥 Коллеги, всем советую послушать мой новый подкаст, где затрагивается эта тема. А именно: даже если у подрядчика высокая экспертность в предметной области, это еще не гарантия продвинутых навыков в управлении, а также успеха проекта.
⭐️ Гость подкаста – руководитель отдела планирования и контроля проектов SetlTech Сергей Стадник, который в прошлом году привлек меня с командой PMLogix к разработке кастомной технологии управлении проектами.
Сергей поделился, как новый подход к управлению помогает не только избегать сюрпризов с подрядчиками, но и наращивать компетенции внутри компании.
Смотрите подкаст на Youtube или в ВК видео.
Топ-3 моих лучших решений в жизни
Недавно задумался о том, какие из моих решений оказали на мою жизнь наибольшее влияние. И понял, что несмотря на то, что все они были «спонтанными», в итоге оказались самыми верными. Ниже поделюсь, почему.
1️⃣ Бросил институт
После 11-го класса я поступил в Московский авиационный институт на факультет самолетостроения (кафедра «Динамика и управление полетом»), но… Не дождавшись второго курса, я бросил учебу.
Так получилось, что выбор этого ВУЗа не было моим осознанным решением. Подготовительный год оказался сложным из-за проблем со здоровьем, и мне пришлось пойти по пути наименьшего сопротивления – продолжить трудовую династию и выбрать то, что более или менее знакомо. В общем, я сдал первую сессию, поучился еще какое-то время и понял, что это не мое. И покинул МАИ буквально одним днем – вышел и больше не вернулся.
По рекомендации тех, кто уже учился в ВШЭ, я понял, что сфера менеджмента для меня намного интереснее. Так что, после решения бросить МАИ я выбрал Высшую школу экономики. Подготовился на четырехмесячных курсах, поступил на бесплатное отделение и оказался там, где я и должен был быть.
2️⃣ Бросил стабильную, комфортную работу
Моим первым местом работы по специальности стала компания Samsung Electronics. В частности, я занимался производственными проектами по сборке телевизоров. И все было хорошо: офис в центре Москвы, достойная зарплата, понятные перспективы. Однако несмотря на то, что по большому счету меня все устраивало, я понимал, что здесь от меня мало что зависит и меня легко заменить (при этом я стал единственным ведущим экспертом по местному сборочному производству).
Так что, в какой-то момент я решился на настоящую авантюру: принял предложение от директора завода «Сигнал» в Энгельсе и получил должность руководителя продуктового комплекса (большой начальник). В мои обязанности входило управление разработкой, производством и логистикой бытового отопительно-газового оборудования. И на протяжении 1,5 лет я каждую неделю ездил из Москвы на завод в 15 км от Энгельса.
Так почему же это решение бросить стабильную, хорошо оплачиваемую работу и уйти непонятно куда оказалось для меня правильным?
Тот опыт, который я получил за время работы на этом заводе, поистине бесценен. Кроме того, что я мощно прокачался как профессионал в производстве и разработке «железных» продуктов, я научился работать как с невероятно умными инженерами, руководителями советской закалки, так и с самыми простыми работягами. А еще получил запоминающийся опыт разруливания забастовки сварщиков и увольнения одним днем бывшего руководителя криминальной группировки. Ну а выстраивать рабочие процессы с местными кладовщиками, у которых зарплата в то время была на гране выживания… Поверьте, это тот еще квест.
Ну разве мог я получить настолько богатый жизненный и профессиональный опыт, сидя в уютненьком офисе в центре Москвы?
3️⃣ Бросил найм и ушел в свой бизнес
Все началось с того, что меня уволили с последнего места работы, где я трудился на позиции руководителя проектного офиса.
Дело было так: в какой-то момент я реализовал несколько больших и сложных проектов (включая вывод из кризиса программы по запуску автоматизированной банковской системы), после чего все мои функции свелись к поддержанию текущих процессов. Но из-за того, что мое мнение по поводу различных подходов к управлению и решению вопросов постоянно шло вразрез с мнением руководства… я стал очень неудобным. Так что, попрощались со мной именно с такой формулировкой – «нам не по пути, мы не видим тебя частью команды».
И возникла дилемма – вернуться в мир корпоративных интриг или же начать свое дело.
И я выбрал второе.
И это тоже оказалось судьбоносным решением.
Вот уже 9 лет с небольшим перерывом я занимаюсь собственным бизнесом, которого не было бы без всех этих решений: бросить первый ВУЗ, уютный офис Samsung Electronics и работу в найме.
Ну что, откровения за откровения? Какие судьбоносные решения были у вас?
Недавно задумался о том, какие из моих решений оказали на мою жизнь наибольшее влияние. И понял, что несмотря на то, что все они были «спонтанными», в итоге оказались самыми верными. Ниже поделюсь, почему.
1️⃣ Бросил институт
После 11-го класса я поступил в Московский авиационный институт на факультет самолетостроения (кафедра «Динамика и управление полетом»), но… Не дождавшись второго курса, я бросил учебу.
Так получилось, что выбор этого ВУЗа не было моим осознанным решением. Подготовительный год оказался сложным из-за проблем со здоровьем, и мне пришлось пойти по пути наименьшего сопротивления – продолжить трудовую династию и выбрать то, что более или менее знакомо. В общем, я сдал первую сессию, поучился еще какое-то время и понял, что это не мое. И покинул МАИ буквально одним днем – вышел и больше не вернулся.
По рекомендации тех, кто уже учился в ВШЭ, я понял, что сфера менеджмента для меня намного интереснее. Так что, после решения бросить МАИ я выбрал Высшую школу экономики. Подготовился на четырехмесячных курсах, поступил на бесплатное отделение и оказался там, где я и должен был быть.
2️⃣ Бросил стабильную, комфортную работу
Моим первым местом работы по специальности стала компания Samsung Electronics. В частности, я занимался производственными проектами по сборке телевизоров. И все было хорошо: офис в центре Москвы, достойная зарплата, понятные перспективы. Однако несмотря на то, что по большому счету меня все устраивало, я понимал, что здесь от меня мало что зависит и меня легко заменить (при этом я стал единственным ведущим экспертом по местному сборочному производству).
Так что, в какой-то момент я решился на настоящую авантюру: принял предложение от директора завода «Сигнал» в Энгельсе и получил должность руководителя продуктового комплекса (большой начальник). В мои обязанности входило управление разработкой, производством и логистикой бытового отопительно-газового оборудования. И на протяжении 1,5 лет я каждую неделю ездил из Москвы на завод в 15 км от Энгельса.
Так почему же это решение бросить стабильную, хорошо оплачиваемую работу и уйти непонятно куда оказалось для меня правильным?
Тот опыт, который я получил за время работы на этом заводе, поистине бесценен. Кроме того, что я мощно прокачался как профессионал в производстве и разработке «железных» продуктов, я научился работать как с невероятно умными инженерами, руководителями советской закалки, так и с самыми простыми работягами. А еще получил запоминающийся опыт разруливания забастовки сварщиков и увольнения одним днем бывшего руководителя криминальной группировки. Ну а выстраивать рабочие процессы с местными кладовщиками, у которых зарплата в то время была на гране выживания… Поверьте, это тот еще квест.
Ну разве мог я получить настолько богатый жизненный и профессиональный опыт, сидя в уютненьком офисе в центре Москвы?
3️⃣ Бросил найм и ушел в свой бизнес
Все началось с того, что меня уволили с последнего места работы, где я трудился на позиции руководителя проектного офиса.
Дело было так: в какой-то момент я реализовал несколько больших и сложных проектов (включая вывод из кризиса программы по запуску автоматизированной банковской системы), после чего все мои функции свелись к поддержанию текущих процессов. Но из-за того, что мое мнение по поводу различных подходов к управлению и решению вопросов постоянно шло вразрез с мнением руководства… я стал очень неудобным. Так что, попрощались со мной именно с такой формулировкой – «нам не по пути, мы не видим тебя частью команды».
И возникла дилемма – вернуться в мир корпоративных интриг или же начать свое дело.
И я выбрал второе.
И это тоже оказалось судьбоносным решением.
Вот уже 9 лет с небольшим перерывом я занимаюсь собственным бизнесом, которого не было бы без всех этих решений: бросить первый ВУЗ, уютный офис Samsung Electronics и работу в найме.
Ну что, откровения за откровения? Какие судьбоносные решения были у вас?
«Заткнись и слушай», или мои ред флаги в клиентах. Часть 1
Один раз я вернул деньги клиенту. Ранее мы с ним уже работали, и довольно успешно (мне даже написали рекомендательное письмо), но вот уже на новом проекте был другой руководитель, с которым у нас не срослось. И я в итоге отказался от проекта.
Когда я говорю о ред флагах в клиентах, конечно, имеется ввиду не компания, а конкретные люди. Которые могут вести себя так, что… ты либо откажется, либо сделаешь пометку в голове, что в будущем с этим человеком ты больше не будешь работать ни за какие деньги. Либо тысячу раз отмеряешь, прежде чем согласиться на новый проект.
Итак, мои ред флаги👇
🚩Если мы о чем-то договариваемся (формально или неформально), но требования постоянно меняются. То есть, когда клиент постоянно настаивает на том, чтобы мы делали то, что не входит в рамки проекта, даже когда прямо говоришь, что мы об этом не договаривались. При этом я не против сделать что-либо сверх нормы, если эта работа выполняется в качестве моего личного жеста доброй воли. Конечно, мы всегда стараемся найти компромисс (и в 90% это получается), однако когда клиент жестко требует выполнить все, что ему хочется вне рамок договора, это абсолютно неприемлемо.
🚩 «Заткнись и слушай». Когда требуют делать все под диктовку, не слышат аргументов, постоянно перебивают. Удивительно то, что обычно такие клиенты нанимают тебя именно за высокую экспертизу, но в итоге напрочь игнорируют твое мнение, потому что считают себя очень опытными. У них «нет времени на споры», потому что все уже решили сами и другое мнение не интересно. Схожая ситуация, когда ты все-таки высказываешь его, а тебе говорят – «а мы считаем по-другому и все».
🚩 Когда клиент манипулирует своей властью при подписании актов или уже в ходе работы. То есть пытается прогнуть на то, чтобы мы опять же сделали больше, чем договаривались – связывает подписание актов с выполнением работ, которые не задокументированы (попросить можно, но требовать – нет). Такое поведение – сразу три красных флага!
🚩 Когда требуют сделать невозможное. Например, у нас был проект, где нужно было построить отчетность на уже настроенных процессах в ИТ-системе. Но система уже была настроена так, что встроить туда отчетность просто невозможно, а её саму никто менять не хотел. Так что, мы довольно быстро это поняли и отказались от проекта.
🚩 Когда требуют сделать то, что ты не хочешь делать. Один раз меня попросили провести сессию по сценарию клиента (отвергнув мой сценарий), а я этого делать очень не хотел. Но все-таки решил пойти навстречу, хотя знал, что предложенный сценарий неэффективен и неудобен. В итоге все так и вышло – совещание превратилось в свободную дискуссию, и я понял, что зря пошел навстречу клиенту. Потому что за итоговый результат работы, качество проведения совещаний, отвечаю я, и нельзя всегда позволять клиентам делать все, что им захочется. Это, кстати, совершенно не значит, что я не учитываю их пожелания. Однако идти на поводу у клиента и при этом создавать внутренний конфликт с самим собой – для меня тоже неприемлемо.
🚩 Когда требуют доказать, что «вода мокрая». Многие вещи в управлении проектами и изменениями научно не обоснованы, и один раз я работал с руководителем проекта, который требовал предоставлять научно доказанные аргументы. С такими руководителем я тоже больше не захочу связываться, потому работа с ним затягивается на очень долго.
Интересно то, что когда мы пришли к топ-менеджеру, который был удивлен, почему мы так долго копаемся, он в итоге сказал: «Зачем это обосновывать, мы вам верим».
Продолжение следует! Делитесь пока в комментариях своими ред флагами🔥
Один раз я вернул деньги клиенту. Ранее мы с ним уже работали, и довольно успешно (мне даже написали рекомендательное письмо), но вот уже на новом проекте был другой руководитель, с которым у нас не срослось. И я в итоге отказался от проекта.
Когда я говорю о ред флагах в клиентах, конечно, имеется ввиду не компания, а конкретные люди. Которые могут вести себя так, что… ты либо откажется, либо сделаешь пометку в голове, что в будущем с этим человеком ты больше не будешь работать ни за какие деньги. Либо тысячу раз отмеряешь, прежде чем согласиться на новый проект.
Итак, мои ред флаги👇
🚩Если мы о чем-то договариваемся (формально или неформально), но требования постоянно меняются. То есть, когда клиент постоянно настаивает на том, чтобы мы делали то, что не входит в рамки проекта, даже когда прямо говоришь, что мы об этом не договаривались. При этом я не против сделать что-либо сверх нормы, если эта работа выполняется в качестве моего личного жеста доброй воли. Конечно, мы всегда стараемся найти компромисс (и в 90% это получается), однако когда клиент жестко требует выполнить все, что ему хочется вне рамок договора, это абсолютно неприемлемо.
🚩 «Заткнись и слушай». Когда требуют делать все под диктовку, не слышат аргументов, постоянно перебивают. Удивительно то, что обычно такие клиенты нанимают тебя именно за высокую экспертизу, но в итоге напрочь игнорируют твое мнение, потому что считают себя очень опытными. У них «нет времени на споры», потому что все уже решили сами и другое мнение не интересно. Схожая ситуация, когда ты все-таки высказываешь его, а тебе говорят – «а мы считаем по-другому и все».
🚩 Когда клиент манипулирует своей властью при подписании актов или уже в ходе работы. То есть пытается прогнуть на то, чтобы мы опять же сделали больше, чем договаривались – связывает подписание актов с выполнением работ, которые не задокументированы (попросить можно, но требовать – нет). Такое поведение – сразу три красных флага!
🚩 Когда требуют сделать невозможное. Например, у нас был проект, где нужно было построить отчетность на уже настроенных процессах в ИТ-системе. Но система уже была настроена так, что встроить туда отчетность просто невозможно, а её саму никто менять не хотел. Так что, мы довольно быстро это поняли и отказались от проекта.
🚩 Когда требуют сделать то, что ты не хочешь делать. Один раз меня попросили провести сессию по сценарию клиента (отвергнув мой сценарий), а я этого делать очень не хотел. Но все-таки решил пойти навстречу, хотя знал, что предложенный сценарий неэффективен и неудобен. В итоге все так и вышло – совещание превратилось в свободную дискуссию, и я понял, что зря пошел навстречу клиенту. Потому что за итоговый результат работы, качество проведения совещаний, отвечаю я, и нельзя всегда позволять клиентам делать все, что им захочется. Это, кстати, совершенно не значит, что я не учитываю их пожелания. Однако идти на поводу у клиента и при этом создавать внутренний конфликт с самим собой – для меня тоже неприемлемо.
🚩 Когда требуют доказать, что «вода мокрая». Многие вещи в управлении проектами и изменениями научно не обоснованы, и один раз я работал с руководителем проекта, который требовал предоставлять научно доказанные аргументы. С такими руководителем я тоже больше не захочу связываться, потому работа с ним затягивается на очень долго.
Интересно то, что когда мы пришли к топ-менеджеру, который был удивлен, почему мы так долго копаемся, он в итоге сказал: «Зачем это обосновывать, мы вам верим».
Продолжение следует! Делитесь пока в комментариях своими ред флагами🔥
Мои ред флаги в клиентах. Часть 2
Продолжаю тему неприемлемого для меня поведения со стороны клиентов. Если вы пропустили, здесь часть 1.
🚩 Когда клиент допускает неуважительные высказывания о моей команде. Что кто-то из консультантов слишком «зеленый», что-то не может или слишком медленно делает свою работу. Я не против замечаний, но они должны быть высказаны в уважительной форме. Но когда они переходят все грани, это уже пять красных флагов сразу. Кстати, клиент, от которого я отказался, именно так себя и вел – устроил моему стажеру унизительный допрос с пристрастием в духе «а ты вообще кто и как давно ты работаешь».
🚩 Когда постоянно требуют объяснять элементарные вещи по много раз. Когда мы начинаем совместную работу, то всегда знакомим клиента со своей терминологией, инструментами и прочим. Например, есть такие базовые вещи – план, факт, прогноз. Один раз мы объясняли клиенту раз пять или даже больше, что означает каждый из этих терминов, особенно, в чем разница между планом и прогнозом. И вот, что я понял – когда клиент не слушает и даже не старается вникнуть (может, потому что считает себя большим экспертом), то работать с ним снова мне точно не захочется.
🚩 Когда не отвечают на заданные вопросы. То есть, когда ты пытаешься что-то выяснить, например, уточнить детали о том, что и как устроено в компании, а тебе отвечают – «ну мы же об этом уже говорили». И я сейчас не говорю о ситуациях, когда консультант реально пропустил что-то мимо ушей, но даже в этом случае ожидаю, что клиент сможет еще раз ответить или пояснить свой ответ, а не «воспитывать» консультантов.
🚩 Когда очерняют тебя и твою работу перед своими руководителями. Один раз до меня дошел слух, что про меня за спиной говорят то, что я никогда не слышал на общих встречах или хотя бы в формате личной обратной связи. Абсолютно неприемлемо.
🚩 Когда нет культуры согласования документов и постоянно вносят правки в новых местах. И этот процесс может оказаться бесконечным. Большой красный флаг.
🚩 Когда постоянно говорят, что что-то не нравится. Причем обычно такие высказывания носят характер оценочного суждения в духе «так никто не делает» без четкого указания, что же конкретно надо исправить. Или высказывают конкретное замечание и добавляют «ну и остальное тоже поправьте». А когда пытаешься уточнить, что это «все остальное», тебе отвечают, что нет времени объяснять.
🚩 Когда клиент не готов уделять проекту достаточно внимание. Все на бегу, содержательно поговорить не получается, не вникают в суть, не готовятся ко встречам, не принимают нужные решения. А еще не делают необходимые изменения со своей стороны и избегают принятия решений, например, о распределении ответственности или выдаче прав.
🚩 Когда не уважают границы. Например, мы договариваемся о режиме работы – что мы не работаем в выходные или поздно вечером/ночью. А заказчик начинает злиться, почему я быстро не ответил на письмо в субботу поздно вечером или не подготовил презу на выходных.
🚩 Когда не вникают в суть конфликтной ситуации и принимают решение исключить кого-либо из команды без каких-либо разбирательств.
🚩 Когда во время конфликта переходят на повышенные тона и используют крик, ненормативную лексику.
🚩 Ну и финальное: когда тебя откровенно пытаются на*бать. То есть заплатить меньше денег за то, что якобы не сделано, при этом совершенно забыв о том, что сделано намного больше того, что даже не входило в рамки проекта. Когда я столкнулся с такой ситуацией, то все же постарался доходчиво донести, что так делать не надо, и мне заплатили 100%. Но, если бы мы не решили вопрос… это мега красный флаг. К такому клиенту я точно никогда больше не вернусь.
Коллеги, а вы когда-нибудь отказывались от клиентов и почему?
Продолжаю тему неприемлемого для меня поведения со стороны клиентов. Если вы пропустили, здесь часть 1.
🚩 Когда клиент допускает неуважительные высказывания о моей команде. Что кто-то из консультантов слишком «зеленый», что-то не может или слишком медленно делает свою работу. Я не против замечаний, но они должны быть высказаны в уважительной форме. Но когда они переходят все грани, это уже пять красных флагов сразу. Кстати, клиент, от которого я отказался, именно так себя и вел – устроил моему стажеру унизительный допрос с пристрастием в духе «а ты вообще кто и как давно ты работаешь».
🚩 Когда постоянно требуют объяснять элементарные вещи по много раз. Когда мы начинаем совместную работу, то всегда знакомим клиента со своей терминологией, инструментами и прочим. Например, есть такие базовые вещи – план, факт, прогноз. Один раз мы объясняли клиенту раз пять или даже больше, что означает каждый из этих терминов, особенно, в чем разница между планом и прогнозом. И вот, что я понял – когда клиент не слушает и даже не старается вникнуть (может, потому что считает себя большим экспертом), то работать с ним снова мне точно не захочется.
🚩 Когда не отвечают на заданные вопросы. То есть, когда ты пытаешься что-то выяснить, например, уточнить детали о том, что и как устроено в компании, а тебе отвечают – «ну мы же об этом уже говорили». И я сейчас не говорю о ситуациях, когда консультант реально пропустил что-то мимо ушей, но даже в этом случае ожидаю, что клиент сможет еще раз ответить или пояснить свой ответ, а не «воспитывать» консультантов.
🚩 Когда очерняют тебя и твою работу перед своими руководителями. Один раз до меня дошел слух, что про меня за спиной говорят то, что я никогда не слышал на общих встречах или хотя бы в формате личной обратной связи. Абсолютно неприемлемо.
🚩 Когда нет культуры согласования документов и постоянно вносят правки в новых местах. И этот процесс может оказаться бесконечным. Большой красный флаг.
🚩 Когда постоянно говорят, что что-то не нравится. Причем обычно такие высказывания носят характер оценочного суждения в духе «так никто не делает» без четкого указания, что же конкретно надо исправить. Или высказывают конкретное замечание и добавляют «ну и остальное тоже поправьте». А когда пытаешься уточнить, что это «все остальное», тебе отвечают, что нет времени объяснять.
🚩 Когда клиент не готов уделять проекту достаточно внимание. Все на бегу, содержательно поговорить не получается, не вникают в суть, не готовятся ко встречам, не принимают нужные решения. А еще не делают необходимые изменения со своей стороны и избегают принятия решений, например, о распределении ответственности или выдаче прав.
🚩 Когда не уважают границы. Например, мы договариваемся о режиме работы – что мы не работаем в выходные или поздно вечером/ночью. А заказчик начинает злиться, почему я быстро не ответил на письмо в субботу поздно вечером или не подготовил презу на выходных.
🚩 Когда не вникают в суть конфликтной ситуации и принимают решение исключить кого-либо из команды без каких-либо разбирательств.
🚩 Когда во время конфликта переходят на повышенные тона и используют крик, ненормативную лексику.
🚩 Ну и финальное: когда тебя откровенно пытаются на*бать. То есть заплатить меньше денег за то, что якобы не сделано, при этом совершенно забыв о том, что сделано намного больше того, что даже не входило в рамки проекта. Когда я столкнулся с такой ситуацией, то все же постарался доходчиво донести, что так делать не надо, и мне заплатили 100%. Но, если бы мы не решили вопрос… это мега красный флаг. К такому клиенту я точно никогда больше не вернусь.
Коллеги, а вы когда-нибудь отказывались от клиентов и почему?