Видение и цели в бизнесе: о чем и зачем?
Я впервые столкнулся с управлением большими организациями, когда меня отправили на завод менеджером ДЦ. Чтобы вы понимали масштаб трагедии: мне было 27 лет, офисная карьера, максимум у меня был был один подчинённый. После переезда мне вручили гигантский склад, несколько сотен человек и парк техники, название которой я с трудом мог запомнить. Сочувственно посмотрев в мои овечьи глаза, мне сказали «ну ты спрашивай, если что» и отправили в плавание.
Первый контакт
Отчаянно барахтаясь в хитросплетениях бюджета, человеческих взаимоотношений и трудового законодательства, я постепенно начал понимать что к чему и даже почти что гордиться своими скромными успехами. Но понимал, что до супер перфоманса мне далеко. В итоге, я пошел за советом «как стать круче» к одному из директоров производств (до сих пор с ним общаюсь и испытываю глубокое уважение).
Послушав меня секунд тридцать, он спросил: «а у тебя есть видение? Куда ты хочешь привести команду через 3 года? Если у тебя не будет видения и не будет чётких целей, то так и будешь топтаться на одном месте и метаться между сиюминутными задачами. Как менеджер ты никому не нужен если не играешь в долгую» .
Мысль засела в голову настолько, что теперь каждый раз, приходя в новую команду, я первым делом формирую виденье, определяя, где я со своей командой хочу быть на горизонте 2-3 лет, и какие крупные вещи для этого надо сделать.
Наша ошибка в том, что даже с хорошим менеджерским опытом, мы сфокусированы на текущих задачах. Мы даже не пытаемся подумать о том, какое будущее хотим построить. А как вести команду, если сам не знаешь, куда хочешь прийти? Поработав в разных организациях, могу откровенно сказать: формирование понятного и амбициозного видения может определить успех команды на долгое время (даже после твоего ухода).
Что по целям?
Цели наполняют работу смыслом и делают ее измеримой. Иначе это движение в никуда. Кратко о том, что мне кажется правильным делать с целеполаганием
Ставить от 3 до 5 измеримых целей. Например: сокращение издержек за этот год X%, Увеличение свободного денежного потока на Y млн. Это чётко, понятно, является хорошим якорем для оценки результата собственной и организационной работы. И еще, цели должны быть сложные, но выполнимые. Нельзя побить мировой рекорд, если не ставить высоких планок. Ну и команде приятнее прыгнуть выше всех
Оценивать рыночные реалии, чтобы не пережестить и не упустить выгоду. Странно и некорректно ставить цель бизнес х2 если весь рынок сжимается в 10 раз. И наоборот, растущий бизнес требует агрессивных целей. Выставляя цели своему отделу, всегда анализируйте, что происходит на рынке, что происходит в других регионах и постарайтесь заглянуть в будущее, какие тренды могут изменить расстановку сил.
❗️Важно Не ставь амбициозные цели от балды. Да, важно закладывать своего рода «коэффициент амбиций», но при этом он должен базироваться над данных и анализе.
Отслеживать результаты. Дисциплинировано. Фанатично. Поставить цели и забыть до следующего отчетного периода - обычная история. Только тогда не ожидай, что люди будут следить за тем, за чем ты не следишь. Повторяй, проговаривай, отслеживай. Празднуй победы, анализируй (с командой) провалы.
Объяснить, как цели коррелируют с видением. Людям важна логичность и последовательность. Так что если у тебя видение про одно, а цели вообще про другое - не ожидай, что команда будет радостно стремиться к твоим непонятным KPI.
❗️Последнее: ни в коем случае нельзя довольствоваться посредственностью.
Поставишь посредственные цели-получишь медленную и инертную организацию, которая их не выполнит, и сам загрустишь 🙃
В своем канале я много пишу про современный менеджмент и бизнес, чтобы делиться накопленным опытом и идеями
Как вы собираетесь добиться успеха без навыков тайм-менеджмента?
Управление временем для руководителей проектов: практические рекомендации и стратегии
Быть эффективным руководителем проекта в современном мире –это мастерство. Мы ежедневно сталкиваемся с горой срочных задач, проблем, бесконечные встречи и письма. Очень легко потерять фокус и контроль над своим временем. Но те, кто обладает навыками тайм-менеджмента, способны выделять главное, оставаться продуктивными и доводить проекты до успешного завершения.
Есть канал Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi , где я собираю много материала (Чек-листы, метрики, стратегии, статьи, книги, кейсы и многое другое), который помогает мне развиваться и помогает другим. Присоединяйтесь, будем рады.
В этой статье я поделюсь своими стратегиями управления временем, которые помогли мне как руководителю проектов максимизировать личную эффективность и продуктивность моих команд. Эти методы могут показаться банальными, однако не судите о них поверхностно, следуя им, вы радикально преобразите ваш распорядок дня.
Определите 3 главных приоритета
Первое и важнейшее правило тайм-менеджмента – определить три основных приоритета на текущий период: день, неделю или месяц. Задайте себе вопрос: "Какие проекты или задачи на данный момент имеют критическую важность?" Возможно, это срочный выпуск программного обеспечения для ключевого заказчика. Или внедрение нового инструмента разработки для повышения эффективности команды. Или найм недостающих специалистов для укомплектования проектной группы.
Какими бы ни были ваши главные приоритеты, убедитесь, что ограниченные ресурсы вашей команды – время, люди, бюджет – сфокусированы именно на них. Ведь как говорил Гэри Келлер, автор книги "Начни с главного": "Единственный способ выжить в этом хаосе – создать для себя еще больший хаос".
После того, как вы определили свои высшие приоритеты, проведите ревизию календаря через призму этих важнейших инициатив. Отметьте встречи, задачи и проектную работу, непосредственно связанную с достижением приоритетов. А все остальное – беспощадно удаляйте или переносите. Не бойтесь практиковать так называемое "мышление с нуля" – регулярно пересматривайте свои планы как чистый лист бумаги и принимайте взвешенные решения о том, какие события действительно необходимы, а от каких можно избавиться.
2. Думайте о своем будущем "Я"
Еще один критически важный принцип для руководителя проектов – всегда думать о том, как ваше "будущее Я" через месяц, квартал или год оценит последствия принимаемых вами сегодня решений. Постоянно спрашивайте себя: "Не пожалею ли я об этом позже? Не отвлечет ли это меня от главных приоритетов?"
Одна эксперт по управлению временем сказала остроумную фразу : "Ваше будущее "Я" всегда более разборчиво и избирательно, чем сиюминутное".
К примеру, представьте, что внутренняя группа по вопросам информационной безопасности предлагает вам присоединиться к их новому комитету по разработке корпоративной политики безопасности. На первый взгляд – заманчивая возможность: статус, новый опыт, контакты. Но затем вы понимаете, что работа в этом комитете потребует регулярных встреч и значительных временных затрат сверх вашей и без того высокой нагрузки.
В такой ситуации полезно будет остановиться и действительно представить себя через 3-6 месяцев. Окажется ли это решение правильным с учетом ваших текущих критически важных приоритетов? Не пожалеете ли вы, что взяли на себя дополнительную нагрузку в ущерб вашим главным целям? Думая наперед, вы экономите себе массу усилий и разочарований в будущем.
3. Сокращайте продолжительность встреч команды
Одна из самых эффективных стратегий управления временем для руководителя проекта - сократить продолжительность командных встреч и митингов по умолчанию, например, с традиционного часа до 30 минут или даже 15-20 минут.
Казалось бы, незначительное на первый взгляд изменение, но оно имеет иной раз просто поразительный эффект. Укороченный отрезок времени вынуждает всех участников быть более дисциплинированными, структурированными и сфокусированными в своих обсуждениях. Когда времени совсем немного, автоматически отсекаются все излишние отклонения, многословие и вхождения в ненужные детали.
Я вспоминаю один проект по разработке крупной веб-платформы, где мы столкнулись с этой проблемой. Ежедневные статусные митинги команды разработчиков, тестировщиков и аналитиков растягивались на час и больше. Участники постоянно отвлекались на посторонние темы, вдавались в ненужные дискуссии и зачастую выходили из встреч более запутанными, чем были до них.
Тогда я принял решение сократить длительность этих ежедневных встреч до 30 минут. Поначалу были опасения, что укороченного времени не хватит, но результат превзошел все ожидания. Команда была вынуждена серьезнее готовиться к митингам, лучше структурировать свои отчеты и говорить строго, по существу, без лишних деталей и отклонений. Эффективность встреч возросла многократно.
Через некоторое время я пошел еще дальше и ввел практику 15-минутных ежедневных встреч. Да, всего 15 минут! Но именно такой ультракороткий формат оказался идеальным для того, чтобы участники максимально четко и конкретно озвучивали только самое важное: прогресс, , план на день и т.д. Ненужной болтовни не осталось вовсе. Команда вышла на поразительные показатели продуктивности.
4. Управляйте срочными задачами в "Горячее время"
Следующая важная стратегия, которую я хотел бы рассмотреть – выделение специального "Горячего" временного окна для обработки всех срочных, незапланированных задач, запросов и инцидентов. Ведь как часто бывает так: вы садитесь работать над важной задачей из ваших трех приоритетов, но внезапно начинаете непрерывно отвлекаться на сторонние входящие вопросы, проблемы и срочности? Фокус полностью теряется, продуктивность стремится к нулю.
Решение этой ключевой проблемы – заблаговременно выделить в расписании специальный интервал времени и посвятить его целиком и полностью решению всех неотложных вопросов и задач. В идеале, это должно быть время максимальной продуктивности и работоспособности - утренние часы.
Помню, как один тимлид в компании, где я работаю, постоянно жаловался на то, что никак не может сосредоточиться на важном коде из-за непрерывного потока срочных вопросов и запросов от разработчиков. Я посоветовал ему выделить для себя окно с 9 до 11 утра как "Горячее время" для решения всех неотложных проблем. В остальное время он работал с отключенными уведомлениями, в режиме полной концентрации.
Эта простая стратегия радикально изменила его жизнь. Более того, увидев ее эффективность, мы стали внедрять принцип "Горячего времени" для разных участников в команде. Каждый разработчик теперь имел пару утренних часов для разбора входящих срочностей, а остальное время посвящал программированию с полным фокусом. Инженеры по тестированию, DevOps и системные аналитики тоже следовали этой практике.
В результате ежедневная продуктивность команды увеличилась на десятки процентов.
5. Система "Inbox Zero" для управления почтой
Следующая боль современного руководителя проекта, с которой я хотел бы разобраться, - бесконечный входящий поток электронных писем, угрожающий полностью поглотить ваше время и внимание. Вечно открытый почтовый ящик, в который каждую минуту прилетает новая порция писем со всех уголков организации. Встречи, документы, вопросы, запросы, уведомления - все в одной бесформенной куче. Как не захлебнуться в этом бардаке?
Решение, которое я настоятельно рекомендую - применять методику "Inbox Zero" от Мерлина Манна. Ее основной принцип - не позволять вашему почтовому ящику превращаться в бездонную яму, куда все летит без разбора. Вместо этого регулярно, например раз в день, полностью разгребайте свои входящие письма, сортируя их по трем категориям:
"Ответить" - письма, требующие быстрого прямого ответа или действия с вашей стороны. Это ваш ближайший фокус.
"Просмотреть" - письма, содержащие прикрепленные документы, отчеты, материалы, которые необходимо внимательно изучить.
"Читать" - письма информационного характера, длинные и/или необязательные к изучению в срочном порядке.
После того, как ваши входящие разобраны, выделите специальные временные окна в своем расписании для обработки каждой категории по очереди. Например, с утра разбираете "Ответить", днем изучаете материалы из "Просмотреть", а вечером, в периоды низкой продуктивности - читаете оставшиеся письма.
6. Установите границы коммуникации
Следующий важный принцип тайм-менеджмента для руководителя проектов, которым я хотел бы поделиться - установление четких границ и рамок для разных каналов коммуникации в команде. Нередко я вижу, как бесконтрольные, бесформенные потоки общения захлестывают всю продуктивность, особенно в распределенных проектных группах.
Люди обмениваются длиннейшими цепочками комментариев в электронной почте, слишком часто созываются на бесконечные рассусоливания по видеосвязи, беспорядочно сыплют сообщениями в многочисленных чатах и на форумах. В итоге формальные каналы коммуникации становятся неформальными и наоборот, сведения рассредоточиваются по многим системам, а фокус на продуктивности полностью теряется.
Чтобы этого избежать, я рекомендую внедрять в команде строгую структуру, где каждый канал имеет четко определенные правила и зону ответственности. К примеру:
Электронная почта отвечает только за формальные одобренные коммуникации, документацию, распространение окончательных решений и ресурсов. Споры и рабочие обсуждения здесь не приветствуются.
Регулярные короткие совещания (очные или удаленные) - для оперативного решения рабочих вопросов и согласований.
Общие чаты и форумы - для мозговых штурмов, мгновенных уточнений, вопросов в свободном формате.
Закрытые чаты или доски задач - как рабочие пространства для обсуждения находящихся в работе задач, требований, кода.
В одном из проектов веб-разработки я как-то обнаружил, что все каналы коммуникации в команде полностью переплелись. Разработчики, тестировщики, аналитики обменивались длиннейшими цепочками комментариев по электронной почте буквально по каждому мелкому вопросу или запросу на изменения. В результате все важные решения, требования и исходный код тонули в этом бесформенном потоке.
Чтобы навести порядок, мы четко распределили зоны ответственности каждого канала. Электронная почта осталась только для формальных уведомлений, распространения финальных решений и ресурсов. Для оперативного разрешения рабочих вопросов и проблем ввели короткие 15-минутные ежедневные митинги. Мозговые штурмы, быстрые уточнения и обсуждения переместились в общие чаты. А для углубленной проработки конкретных функций и задач команда использовала специальные доски и чаты.
Структурирование коммуникационных потоков произвело поразительный эффект. Общая продуктивность команды резко возросла, когда все вернулись в нужное русло. Плюс мы сэкономили огромное количество времени, которое ранее бездарно расходовалось на бесконечный многоканальный шум.
Начните с малых шагов
Наконец, важнейший принцип внедрения любых новых стратегий управления временем - двигаться постепенно, маленькими шагами. Не пытайтесь изменить абсолютно все сразу, это лишь приведет к стрессу и разочарованию.
Вместо этого выберите одну-две привычки или практики, которые проще всего начать применять в ваших текущих условиях. Фокусируйтесь только на них, пока они полностью не войдут в рутину и не станут частью вашего образа жизни. А затем, понемногу, подключайте новые навыки.
Никогда не ждите идеальных условий для изменений. Начинайте прямо отсюда, с того, что имеете в данный момент. Я процитирую мудрые слова Томаса Эдисона: "Идеальное - враг хорошего. Лучше принять решение, пусть даже несовершенное, и неуклонно следовать ему, чем бесконечно оттягивать, пытаясь достичь недостижимого идеала".
Небольшие постепенные сдвиги в сторону лучших практик управления временем приведут к колоссальным переменам спустя несколько месяцев. Я видел это в командах, где мне доводилось работать. От захлебывающихся в хаосе групп к сверхэффективным, структурированным и четко ориентированным на достижение приоритетов. Все начиналось с малого - с одной-двух привычек.
Определите главные приоритеты, пересмотрите календарь, введите "Горячее время" для срочностей. Или хотя бы попробуйте сократить продолжительность ваших митингов. Это будет ваш первый шаг на пути к освоению мастерства управления временем. Надеюсь читать вам было интересно. До встречи в следующей статье или можете присоединиться в Самоучкам https://t.me/+NfVrLMxdKS0yNDNi, там информации гораздо больше).
Формула SMART: как ставить цели, которые реально работают
Цель — это компас, который помогает нам двигаться в нужном направлении в жизни. Без четкой цели мы просто блуждаем, теряя драгоценное время и энергию. Но поставить цель — это только половина дела. Самое важное — это сформулировать ее правильно, чтобы она стала реальным ориентиром, а не просто пустыми словами.
Я знаю, что многие из вас, кто смотрит мой канал Самоучки IT(Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi, работают в IT-сфере или связаны с ней. Программисты, менеджеры проектов, дизайнеры, аналитики и другие специалисты. И, конечно же, у каждого из вас есть определенные цели — как профессиональные, так и личные.
Например, кто-то хочет стать лидом разработки за год-два. Кто-то мечтает открыть свой стартап. А кто-то просто хочет найти интересную и высокооплачиваемую работу в крупной IT-компании. Но очень часто мы формулируем свои цели слишком расплывчато, как "стать успешным" или "достичь карьерных высот". Это не цели, а скорее мечты или желания.
Настоящая цель должна отвечать определенным критериям, которые помогут нам ее четко сформулировать и, самое главное, достичь. Для этого есть отличная методика постановки целей, известная как SMART. Она была разработана еще в 1981 году Джорджем Т. Дораном и активно используется в управлении проектами, бизнесе и личностном росте.
SMART - это аббревиатура, в которой каждая буква означает один из критериев эффективной цели:
S - Specific (конкретная)
M - Measurable (измеримая)
A - Achievable (достижимая)
R - Relevant (актуальная)
T - Time-bound (ограниченная по времени)
Давайте разберем каждый из этих критериев на примере нашей сферы деятельности - IT.
Specific (конкретная)
Ваша цель должна быть максимально конкретной и четкой. "Стать успешным программистом" - слишком размытая формулировка. Что значит "успешный"? Для кого-то это высокий доход, для кого-то — известность в профессиональных кругах, а для кого-то — возможность работать над интересными проектами.
Вместо этого сформулируйте цель более конкретно. Например, "Достичь уровня Middle Python Developer и перейти на позицию лида в команде разработки мобильных приложений в компании X за 2 года". Или "Выучить JavaScript и React и найти работу фронтенд-разработчика в продуктовой IT-компании через год".
Чем конкретнее цель, тем легче будет определить шаги для ее достижения и отслеживать прогресс.
Measurable (измеримая)
Вторым важным критерием является измеримость цели. Вы должны четко понимать, как оценить, достигли вы ее или нет. В IT-сфере это часто можно сделать с помощью определенных показателей или достижений.
Например, если ваша цель — стать лидом, то измерить ее достижение можно по факту назначения на эту позицию и успешной работе в новой роли в течение определенного времени. Если цель — выучить новый язык программирования, то вы можете сдать соответствующий сертификационный экзамен или создать определенное количество успешных проектов на этом языке.
Не забывайте также о "мягких" навыках, которые тоже можно измерить. Скажем, если вы хотите улучшить свои лидерские качества, то можете попросить команду анонимно оценить вас по ряду критериев до и после работы над этой целью.
Achievable (достижимая)
При постановке цели очень важно, чтобы она была реалистичной и достижимой для вас с учетом ваших текущих возможностей, опыта и ресурсов. Слишком амбициозные цели могут демотивировать вас и заставить отказаться от их достижения.
Спросите себя честно: "Могу ли я реально этого добиться?". Если цель кажется слишком сложной или нереалистичной, разбейте ее на несколько этапов. Например, вместо "Стать ведущим экспертом по искусственному интеллекту за год" поставьте цель "Выучить основы машинного обучения и нейросетей и создать первый успешный проект в этой области за год".
Также учитывайте личные обстоятельства. У вас есть достаточно времени и ресурсов, чтобы посвятить себя достижению этой цели? Какие препятствия могут возникнуть на пути и как их преодолеть?
Relevant (актуальная)
Следующий критерий — актуальность и значимость цели лично для вас. Очень часто мы ставим перед собой цели, навеянные обществом, окружением или чужими ожиданиями. Но в итоге достижение этих целей не приносит удовлетворения, ведь они не были по-настоящему нашими.
Спросите себя: "Зачем мне это нужно? Как это соотносится с моими истинными ценностями, интересами и жизненными планами?". Например, если ваша страсть - frontend-разработка, то нет смысла ставить цель стать лучшим бэкенд-разработчиком, только потому что это престижно или высокооплачиваемо.
Проанализируйте, насколько достижение этой цели важно именно для вас, а не для общества или ваших родных. Возможно, стоит скорректировать ее или даже поменять полностью.
Time-bound (ограниченная по времени)
И наконец, последний, но крайне важный критерий — временные рамки для достижения цели. Дэдлайн создает ощущение срочности и мотивирует вас не откладывать дело в долгий ящик.
Поставьте себе четкий и реалистичный срок, к которому вы должны достичь цели — будь то месяц, год или несколько лет. Разбейте этот период на этапы с промежуточными контрольными точками, чтобы отслеживать прогресс. Например: "Выучить Python и Django и разработать полноценное веб-приложение за 9 месяцев". При этом разбейте эту цель на этапы:
1-3 месяцы — изучить основы Python и его синтаксис
4-6 месяцев — освоить Django и разработку на нем
7-9 месяцы — создать и запустить веб-приложение
Так вы будете точно знать, что нужно сделать каждые несколько месяцев, чтобы достичь главной цели за отведенный срок.
Теперь давайте рассмотрим пару конкретных примеров умных целей в IT согласно методологии SMART.
Пример 1: Стать Senior Java Developer
Цель: Достичь уровня Senior Java Developer и перейти на соответствующую позицию в компании X к концу 2025 года.
S (Specific): Четко определена цель — стать Senior Java разработчиком в конкретной компании X.
M (Measurable): Можно измерить успех назначением на должность Senior и переходом к ответственности на этом уровне.
A (Achievable): Достижимо при условии наличия 5+ лет опыта в Java разработке, знании фреймворков, владении английским и готовности постоянно учиться.
R (Relevant): Актуально для того, кто страстно увлечен Java и хочет развиваться как технический эксперт в этой области.
T (Time-bound): Крайний срок — конец 2025 года, т.е. около 2,5 лет на подготовку.
Пример 2: Запустить собственный стартап
Цель: Создать успешный IT-стартап в сфере финтеха и привлечь инвестиции в размере $500 000 к концу 2026 года.
S (Specific): Четкая цель по созданию стартапа в конкретной отрасли и привлечению определенной суммы инвестиций.
M (Measurable): Успех можно измерить самим фактом запуска работающего стартапа и объемом привлеченных инвестиций.
A (Achievable): Достижимо при наличии сильной идеи, команды единомышленников, плана действий и определенного базового капитала.
R (Relevant): Актуально для тех, кто хочет реализовать свои амбиции в сфере инноваций и предпринимательства в IT.
T (Time-bound): Крайний срок — конец 2026 года, т.е. около 3 лет на разработку идеи, создание MVP и поиск инвесторов.
Конечно, каждая личная или профессиональная цель в IT будет индивидуальной. Но используя методологию SMART, вы сможете грамотно ее сформулировать и значительно повысите шансы на ее успешное достижение.
Итак, давайте подведем итог тому, что мы узнали:
Четкая цель — ключ к мотивации и успеху в любой сфере, в том числе IT.Методология SMART позволяет сформулировать цель правильно по 5 важнейшим критериям:
S (Specific) - конкретная
M (Measurable) - измеримая
A (Achievable) - достижимая
R (Relevant) - актуальная для вас
T (Time-bound) - ограниченная по времени
Следуйте этим критериям при постановке любой цели — карьерной, образовательной, личной. Так вы значительно повысите шансы ее реализации.
Не бойтесь корректировать и конкретизировать цель по ходу движения к ней. Это нормальный процесс.
Вдохновляйтесь примерами других, но ставьте цели, которые действительно важны именно для вас.
Разбивайте большие цели на промежуточные этапы. Так будет проще отслеживать прогресс.
Регулярно анализируйте свои достижения и ошибки на пути к цели. Учитесь на них.
Не забывайте ставить перед собой SMART-цели и придерживаться методологии их грамотной постановки.
В завершение еще раз напомню про отличный телеграм-канал Самоучки IT(Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi, посвященный самообучению и построению карьеры в IT, особенно в управлении проектами. Его создатели регулярно публикуют вдохновляющие истории самореализации, разборы полезных книг, советы по подготовке к собеседованиям и многое другое. И кто еще не подписан, подписывайтесь на канал. Делайте репост этой статьи в соцсетях.
Я уверен, что эту методику полезно знать каждому.
Всего доброго!
Исповедь опытного PM: ошибки, которые лучше не повторять
Быть Project -менеджером – это непростая задача, требующая постоянного самосовершенствования. За годы работы в этой сфере, набил немало шишек и совершил массу ошибок. Пришло время поделиться некоторыми из них, дабы предостеречь вас от подобных промахов.
Как отмечают на канале "Самоучки IT (Управление проектами)" https://t.me/+NfVrLMxdKS0yNDNi , ключевая роль Project -менеджера - создать оптимальные условия для продуктивной работы команды. Это предполагает четкое определение зон ответственности, устранение препятствий и расстановку приоритетов, на которых следует сфокусироваться. Однако даже опытные управленцы нередко наступают на многочисленные "грабли", допуская распространенные ошибки. Об этом из личного опыта расскажет опытный PM.
Ошибка №1. Думать за пользователей и заказчика
Однажды мне показали резюме проекта по созданию личного кабинета для клиентов. И в нем были прописаны подробнейшие требования не только к функционалу, но и к дизайну! Причем с самими пользователями никто из команды не удосужился пообщаться и выяснить их предпочтения.
Такая вопиющая ошибка, увы, не редкость. Мы часто грешим тем, что сами додумываем, что может понадобиться пользователям, вместо того чтобы действительно спросить их. А ведь существуют исследования, показывающие, что почти половина реализованного функционала впоследствии не используется вовсе или используется крайне редко. Все потому, что мы идем по ложному пути, пытаясь угадать потребности людей.
Точно такая же беда случается и при взаимодействии с заказчиками. Сначала мы стесняемся переспрашивать и уточнять детали, а потом выясняется, что заказчик имел в виду нечто совершенно иное.
Пришло время расстаться с этой порочной практикой. Не думайте за пользователей и заказчиков – общайтесь с ними, уточняйте требования, собирайте обратную связь, применяйте соответствующие техники. Это не трата времени, а инвестиция в успешность проекта.
Ошибка №2. Думать за команду
Равно как и пользователей с заказчиками, многие Project -менеджеры, включая былого меня, грешат тем, что сами придумывают требования к продукту, оценивают риски, сроки и объемы работ для команды. Но с какой стати я, менеджер, могу учесть абсолютно все возможные препятствия и подводные камни?
Этим должна заниматься команда высококлассных профессионалов вместе со мной. Именно они лучше всего разбираются в тонкостях своего ремесла и трудностях, с которыми могут столкнуться на том или ином участке работы.
То же самое касается и оценок объемов работ. Одному менеджеру крайне сложно адекватно их рассчитать, не имея глубокой экспертизы в различных областях. Выставленные мною сроки и оценки – это просто ничем не подкрепленные цифры, далекие от реальности.
Вместо этого нужно работать системно, занимаясь проактивным планированием и выделяя время на общение с командой. Не лезьте в их работу и не пытайтесь ее делать вместо них. Команда и менеджер должны действовать единым фронтом, объединив экспертизу для создания поистине выдающегося продукта.
Ошибка №3. Микроменеджмент
Микроменеджмент – ахиллесова пята многих руководителей проектов, включая меня. Эта зловредная практика выражается в том, что менеджер начинает пристально отслеживать каждый шаг членов команды: сколько времени кто провел в Zoom, какие задачи передвинул из одного статуса в другой и т.д. Дело доходит до абсурдных ситуаций, когда люди вынуждены выжидать, пока я одобрю их малейшее действие.
Причины такого деструктивного поведения могут крыться во врожденной склонности все контролировать или в плохо выстроенных процессах. Но результат один – команда начинает изнывать от тотальной опеки, что пагубно сказывается на эффективности труда.
Лучший совет, который я могу дать – тщательно проработать рабочие процессы. Определите границы ответственности: что входит в зону полномочий команды, а что решает менеджер. Избавьтесь от лишних этапов согласования и процессов, в которых ваше участие излишне. Доверяйте людям и делайте свою работу, вместо того чтобы изводить команду микроменеджментом.
Ошибка №4. Замалчивать проблемы
Эту ошибку можно считать одной из самых распространенных и губительных. Мы, Project-менеджеры, зачастую боимся озвучить заказчику, спонсору или руководству, что у нас дела идут неважно. Что мы рискуем сорвать сроки, что продукт у нас совсем не получается или мы напрочь не понимаем, чего хотят пользователи.
Такой страх объясним – ведь эти новости никогда не бывают приятными. Однако молчание может дорого нам обойтись. Пока мы продолжаем игнорировать назревающие проблемы, риски постепенно реализуются. В итоге ситуация выходит из-под контроля, сроки действительно срываются, а продукт становится печальной пародией на самого себя.
Поэтому не замалчивайте проблемы. Если ситуация еще не зашла слишком далеко, на ранней стадии вы имеете дело с управляемым риском, а не свершившимся фактом. Открыто говорите о них, не стесняйтесь просить совета и помощи. И что еще более важно – создавайте в команде атмосферу доверия, чтобы и ее члены могли откровенно делиться своими трудностями. Только так удастся предупредить многие беды и свести их негативный эффект к минимуму.
Ошибка №5. Делать работу за других
Этим грешат многие Project -менеджеры, и я не исключение. В прошлом я часто писал код, анализировал данные, рисовал макеты – делал все, что угодно, вместо своей непосредственной работы. Причины у такого поведения могли быть разные: нехватка ресурсов, трудности с согласованиями в больших компаниях или просто желание все сделать самому.
Но лезть в чужую работу губительно не только потому, что это отвлекает от прямых обязанностей Project -менеджера. Есть и другая, не менее важная причина избегать этой ошибки.
Дело в том, что выполняя чужие задачи, я неизбежно начинаю распылять свое внимание и снижать качество работы. Я могу быть хорошим Project -менеджером, потому что именно на этом пути я сфокусирован, совершенствую свои навыки и экспертизу. Но стоит мне попытаться примерить роль, скажем, разработчика или дизайнера - и я уже в лучшем случае буду середнячком. Потому что это точно не моя специализация, я нахожусь вне привычного контекста.
Поэтому не пытайтесь тянуть одеяло на себя, делая вместо команды их работу. Это если и позволит чуть продвинуться, то лишь ценой колоссальных усилий с вашей стороны и сомнительного качества результата. Доверьтесь профессионалам в своей команде, сфокусируйтесь на управленческих обязанностях. В конечном итоге, и вы, и команда только выиграете от такого распределения ролей.
Ошибка №6. Зарываться в бумажной работе
Нередко бывает так, что необходимо запустить проект при полном параде – с презентациями, диаграммами Ганта, качественными отчетами и прочей ничего не значащей сувенирной продукцией. И в погоне за создание этих бумажных куч мы, менеджеры, способны просиживать по многу месяцев, пока сам проект фактически простаивает.
В былые времена я тоже грешил таким ненужным ремесленничеством. Месяцами рисовал диаграммы, по многу раз перерабатывал презентации, дополняя их всё новыми ненужными слайдами. Всё это ради того, чтобы в очередной раз отчитаться перед спонсорами и заказчиками. А затем они просили что-то ещё, и весь процесс повторялся по новой.
Но ведь помнить главное – нам платят не за имитацию бурной деятельности, а за реальные результаты и созданный продукт. Поэтому не подменяйте содержание формой, не пытайтесь прикрыть бездействие ворохом псевдодокументации. Фокусируйтесь на результатах и процессах, ведущих к их достижению. Вы менеджер проекта, так управляйте им, а не просто имитируйте видимость работы.
Ошибка №7. Тушение пожаров вместо планирования
Вместо того, чтобы заранее продумывать возможные сценарии, выявлять риски и держать планы в актуальном состоянии, многие менеджеры, включая меня в прошлом, просто реагируют по наитию на уже возникшие проблемы. Мы срываемся и летим тушить уже разгоревшееся пламя, вместо того чтобы предупредить возгорание.
Отчасти такой подход диктуется ложными установками, будто планирование – это всегда многостраничные Ганты с детализацией на много уровней вглубь. Или, наоборот, сейчас все должны быть "гибкими", а планирование устарело.
Истина, как часто бывает, находится посередине. Конечно, нужно быть готовым к изменениям. Но это никак не отменяет саму необходимость планирования и ревизии планов. Ведь взгляните на ситуацию с другой стороны: когда вы садитесь за руль в большом городе, пусть и знакомом, разве не проще выстроить маршрут заранее? Он будет обновляться в режиме реального времени и поможет объехать пробки, найти оптимальный путь и сэкономить массу времени. Достаточно потратить на это 30 секунд!
То же самое справедливо и для проектов. Время, инвестированное в планирование, окупится с лихвой – за счет предотвращенных ошибок и заблаговременно выявленных рисков. К тому же, это поможет команде понимать свои цели и двигаться к ним осмысленно.
Ошибка №8. Игнорирование рисков
Эта ошибка часто идет рука об руку с предыдущей – ведь если не заниматься планированием, то и риски придется игнорировать по умолчанию. Казалось бы, в чем сложность провести сессию по выявлению возможных угроз? Но стоит только задать менеджерам этот вопрос, как доводы посыпятся:
"В нашем проекте нет никаких рисков!"
"Я ничего не могу придумать!"
Но стоит лишь немного поскрести по сусекам прошлого, как обнаруживается масса всевозможных скелетов в шкафу. Часто менеджеры проектов игнорируют риски не потому, что не понимают их важности, а из-за банальной лени или нежелания копаться в возможных проблемных сценариях. Признаться, в прошлом и я был не чужд такого поведения.
С одной стороны, кажется, что это облегчит жизнь - не нужно тратить время на выявление рисков и разработку мер по их предупреждению или смягчению последствий. С другой стороны, такой подход похож на ситуацию, когда перед поездкой вы отказываетесь от страховки для своего автомобиля. Рисков же никаких нет, зачем платить лишние деньги? Но стоит однажды попасть в ДТП, и вы оказываетесь к этому совершенно не готовы.
Точно так же обстоят дела и с проектами. Отказываясь анализировать возможные риски, вы добровольно отправляетесь в рискованное плавание на утлой лодчонке без спасательного круга. Любая нештатная ситуация грозит нокаутировать вас, когда вы совершенно не будете ждать подвоха.
Поэтому не игнорируйте риски. Начинайте их выявлять на самых ранних стадиях проекта. И не прекращайте этот процесс до самого его завершения - ведь новые опасности могут поджидать за каждым поворотом. Убедитесь, что команда тоже относится к этому вопросу со всей серьезностью. Только так вы сможете обезопасить себя от возможных катастроф и неприятных сюрпризов.
Ошибка №9. Многозадачность
Многозадачность я ненавижу даже сильнее, чем микроменеджмент. Это зло, которое многие почему-то считают добродетелью и проявлением выдающихся способностей. Но результаты исследований неумолимы – лишь 2% людей действительно способны эффективно совмещать множество дел одновременно. Остальные 98%, переключаясь между задачами, стремительно теряют продуктивность.
Я, к сожалению, отношусь к этим 98%. В прошлом я постоянно брал на себя больше, чем мог осилить. Создавал целые горы незавершенной работы, становился бутылочным горлышком проектов. Мысли моим постоянно витали где-то, я никак не мог сфокусироваться на одном деле как следует.
Избавиться от этой пагубной привычки мне помогли два подхода. Первый – просто остановиться, осознать ситуацию и принять, что если я сейчас не отвечу на сообщение, ничего страшного не случится. Можно целиком посвятить полдня решению одной-единственной задачи, больше ни на что не отвлекаясь.
Второй подход предполагает системные изменения. Если приходится постоянно переключаться между разными делами, это значит, что что-то идет не так. Возможно, я лезу не в свою работу или же подменяю собой команду, игнорируя принципы распределения обязанностей. Ведь, как мы убедились, все ошибки взаимосвязаны.
Так или иначе, многозадачность – это ловушка, ведущая в никуда. Не создавайте себе лишних проблем, учитесь фокусироваться на приоритетных задачах по очереди. Ваша команда будет только благодарна.
Спасибо, что вы дочитали до конца.
Подписывайтесь на наш канал Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi
Как помочь себе в предновогодней рабочей панике?
Делюсь правилами, которые помогут вам [и помогают мне] пережить предновогоднюю рабочую панику ☃️😄
📍Перестаньте пытаться успеть все
Выпишите то, что железно должно быть закрыто в уходящем году, и нагло пренебрегайте всем остальным.
📍Не будьте «как все»
Предновогодняя паника зачастую преувеличена и как будто возведена в культ. Если ты не сидишь на работе до часу ночи и не спишь по 4-5 часов, то какой-то ты не такой)))
Как будто стало модно «заебаться». Зачем? Я предпочитаю быть в противоположном лагере.
📍Снизьте ожидания
«О, вот она, — красная черта: новогодний корпоратив/последний рабочий день. Фууууух 🤤», — вздохнули те самые заебавшиеся. Наконец-то каникулы, которые все они так предвкушали.
Друзья мои, разочарую вас, но это всего лишь неделя выходных, которые пролетают, как миг. А потом, прикиньте, «ВСЕ ЗАНОВО!» ахаха))
Чем завышеннее ожидания, тем сильнее разочарование. Потому что большинство людей свои каникулы проведут просто дома, на диване 🤷🏻♀️
📍Избавьтесь от стадного инстинкта и планируйте качественно
Тщательно распланируйте:
• свои закрывающие задачи
• свои личные дела перед НГ
• свой отдых!!!! — придумайте больше активностей и событий, которые запомнятся.
Следуя этим правилам, вы будете в стороне от «лагеря заебавшихся» и вдобавок офигенно отдохнете 🤗
#жизаменеджера #мыслиовеликом
Как найти реально крутого сотрудника без понтов и овер-прайса?
Для ЛЛ: выставить вакансию с требованиями, под которые подходят многие, а в тестовом задании не ограничивать во времени и дать возможность человеку разобраться в новой для него теме. Если разберется, справится с заданием - берем.
Долгое время работая на себя, я не замечал некоторых очевидных минусов подбора персонала по фактическим требованиям под задачи. С одной стороны, ты сразу получаешь человека, который вывозит то, что ты от него хочешь. С другой стороны - обычно это стоит значительно больше.
Уйдя из работы на себя, где бюджетом рулил только я, и войдя в тему больших компаний, где бюджет верстается на год и более, пришел к выводу, что данная тема не совсем актуальна. Можно брать спеца, и платить дохрена, но человеки так устроены, что могут уйти в другое место. И встал вопрос об удержании кадров.
Вариант номер один: постоянно повышать ЗП. Как вариант, вариант. Но повышение от 300К на 10% - это 30К. Вариант номер два: повышение раз в полгода или чуть чаще на 5000 от тех же 50-60К - это от 8 до 10%, и при этом люди значительно более благодарны, и готовы работать дальше.
Кто-то скажет, что специалист за 300К покрывает собой 6 спецов по 50К, но нет. Практика показывает, что при решении задач средне-высокой сложности, это не работает. Лучше иметь одного профи, и кучу подмастерьев, чем несколько "профи". Отсутствие "ковровой" конкуренции внутри коллектива, экономия денег, возможность нагружать не только "интересными задачами". Снижение риска остаться завтра без спеца.
Есть несколько проектов на Питоне. Есть кластер перегруженных серверов. Есть человек, который в одно лицо понимает, как все это работает. Есть день, когда этот человек пишет по собственном. Есть день, когда все идет в разнос, потому что адекватного человека ему на смену найти не успеваем.
После этих дней я принял решение, что больше никогда ни один проект не будет зависеть так сильно от одного человека. И это работает. Ротация кадров происходит, но никогда не возникало больше ситуации, что все пошло по звезде из-за увольнения одного из членов команды.
Возвращаясь к начальному вопросу. Искать нужно не спецов, а тех, кто готов ими стать. Или является ими, но не осознает этого. Поставить задачу по не профильной для кандидата тематике. И сжатые сроки. Если вывезет, значит вывезет и в другой ситуации. И ставить задачи лучше из тех, которые реально встают на его будущей должности. А не "продай мне эту ручку", утрированно.
А "спецы", особенно из IT сферы, меня уже затрахали капитально. Вспоминается мем про пиздабола:
- Ты чо не веришь?
- Серьезно?
- Да, серьезно!
Половина тех людей, которые получали у нас 300+, не смогли адекватно доказать и показать разницу между ними, и их коллегами из темы от 100 до 150. Кроме "опыта" работы с иностранными копаниями. Но нам то какая разница, если мы работаем на русском и с русскоязычными партнерами, и их уровень владения английским C1 по ILS не имеет значения.
Отсюда вывел для себя правило. Если нужен человек, вырасти его. Если хочешь вырастить быстро, проверь на старте потенциальную скорость его роста. Если человек уходит, у тебя есть несколько вариантов для его замены, с +- теми же характеристиками. И знаниями. Ибо росли они в одних условиях и рядом друг с другом. Нахер надо, брать оторванных от коллектива "специалистов", которые сегодня здесь, завтра - там.
Всем успехов в развитии. Пост ни о чем, поделиться решил, т.к. за неделю набирали отдел новый.
Под проект.