Петров Алексей — про разработку, управление людьми и проектами

12 лет в IT, последние 10 лет занимаюсь развитие digital продакшена для ecom.
Есть в fb. Пишу в телеграмм. Для связи тг.

PMBOK 7: Руководство по выживанию в джунглях современных проектов

Недавно я закончил чтение PMBOK Guide 7-го издания, к этому чтиву я подходил 3 раза. Не самое легкое чтиво на вечер, но достаточно интересное. Это почти как фильм «Бойцовский клуб», при каждом прочтении открывается с новой стороны.

Шестую версию PMBOK не читал целиком, только ключевые тезисы, но довольно легко проследить тренды 7 версии. Ключевой вопрос для меня был как это применять на практике. Управление проектами — это динамичная область, где всё больше акцент делается на гибкость, адаптивность и ориентированность на ценность, и PMBOK 7 прекрасно отражает эти тенденции.

Кому стоит почитать.

  1. Менеджерам проектов, работающим в условиях высокой неопределенности и быстро меняющейся среды;
    Тем, кто хочет понять современные подходы в управлении проектами, включая гибридные методологии;
  2. Руководителям и лидерам команд, которые стремятся создать эффективные команды и доставлять ценность стейкхолдерам;
  3. Всем, кто заинтересован в построении гибких и адаптивных процессов в своих проектах.

Русская версия в формате pdf

История

  1. PMBOK Guide 1-е издание (1996) — первое издание стандарта управления проектами.
  2. PMBOK Guide 2-е издание (2000) — обновленное руководство с расширенной информацией по проектным процессам.
  3. PMBOK Guide 3-е издание (2004) — акцент на связь между процессами и ключевыми областями знаний.
  4. PMBOK Guide 4-е издание (2008) — добавлена четкость в описания процессов и методов управления проектами.
  5. PMBOK Guide 5-е издание (2013) — добавлены процессы для управления стейкхолдерами.
  6. PMBOK Guide 6-е издание (2017) — в этой версии было уделено внимание методологиям Agile, гибким подходам, и расширен раздел по управлению стейкхолдерами.
  7. PMBOK Guide 7-е издание (2021) — значительно изменен, с акцентом на принципы и гибкость в управлении проектами. Меньше внимания уделено процессам, больше — адаптивным методологиям и результатам.

Изменение структуры и акцентов

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

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

Две ключевые части:

  1. 12 принципов управления проектами;
  2. 8 доменов производительности.

12 Принципов управления проектами

Принципы дают основу для гибкости и адаптации. Их можно сравнить с ориентирами для менеджеров проектов, которые должны выбирать подходящие инструменты и методы под специфику каждого проекта:

  1. Быть ответственным управляющим
  2. Создавать совместную команду проекта
  3. Эффективно взаимодействовать с заинтересованными сторонами
  4. Фокусироваться на ценности
  5. Распознавать системные взаимодействия и реагировать на них
  6. Демонстрировать лидерское поведение
  7. Адаптироваться к контексту
  8. Формировать качество в процессах и результатах
  9. Ориентироваться на сложность
  10. Оптимизировать реакцию на риски
  11. Использовать адаптивность и устойчивость
  12. Обеспечивать изменения для достижения желаемого будущего состояния

8 Доменов производительности

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

  1. Заинтересованные стороны: управление ожиданиями стейкхолдеров и обеспечение их вовлеченности.
  2. Команда: формирование, развитие и поддержка команды, создание подходящей среды для работы.
  3. Развитие и планирование: гибкость в подходах к планированию, возможность адаптации планов в ходе выполнения проекта.
  4. Проектная работа: выполнение основных задач проекта с учетом специфики и потребностей.
  5. Доставка ценности: фокус на максимальной полезности результатов проекта для бизнеса и клиентов.
  6. Неопределенность и риск: проактивное управление рисками и неопределенностью, внедрение инструментов для их минимизации.
  7. Адаптация и повышение производительности: улучшение процессов в ходе реализации проекта.
  8. Моделирование знаний: управление знаниями и использование информации для улучшения работы.

Модели, методы и артефакты

PMBOK 7 вводит концепцию моделей, методов и артефактов (MMA) вместо жестко определенных процессов. Это позволяет менеджерам проектов выбирать наиболее подходящие инструменты для конкретного проекта.

  1. Модели: Включают Agile, гибридные подходы, предиктивные модели.
  2. Методы: Охватывают различные техники, такие как ретроспективы, планирование релизов, оценка стоимости.
  3. Артефакты: Включают документы и инструменты, такие как устав проекта, журнал проблем, диаграмма Ганта.

Области эффективности

PMBOK 7 вводит восемь областей эффективности проекта:

  1. Заинтересованные стороны
  2. Команда
  3. Подход к разработке и жизненный цикл
  4. Планирование
  5. Работа проекта
  6. Доставка
  7. Измерение
  8. Неопределенность

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

Гибкость и гибридные подходы

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

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

  1. Уровне неопределенности проекта;
  2. Скорости изменений;
  3. Требованиях заказчика и стейкхолдеров;
  4. Характеристиках команды.

Технологический и человеческий факторы

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

Tailoring (настройка процесса управления под проект)

Одной из самых важных практических тем стало понятие tailoring, что означает настройку и адаптацию методологии под конкретный проект. В предыдущих версиях PMBOK предполагалось жесткое следование процессам, тогда как в 7-м издании менеджер проектов должен адаптировать подходы к уникальности проекта, в том числе:

  1. Объем проекта;
  2. Риски и неопределенности;
  3. Внешние и внутренние условия;
  4. Компетенции команды.

Интеграция с другими стандартами и фреймворками

7-е издание PMBOK не является изолированным стандартом, оно интегрируется с другими фреймворками и стандартами, такими как Agile Practice Guide, Scrum, SAFe и другими гибкими методологиями. Это позволяет менеджерам проектов выбирать подходящие инструменты и методы из разных стандартов в зависимости от требований проекта.

Итого

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

  1. Используйте 12 принципов как руководство при принятии решений в проекте.
  2. Адаптируйте подход к управлению проекту в зависимости от контекста и потребностей.
  3. Выбирайте модели, методы и артефакты, наиболее подходящие для вашего проекта.
  4. Фокусируйтесь на создании ценности и достижении результатов, а не только на процессах.
  5. Регулярно оценивайте эффективность проекта в восьми областях эффективности.
  6. Будьте готовы к гибкому подходу и адаптации к изменениям.

Пакет с пакетами

У всех дома есть пакет с пакетами, правда ведь? Забавная аналогия пришла мне на ум, когда я задумался о Google или Excel таблицах, которые используются для управления бизнесом.

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

Но в чем связь между пакетами и таблицами? В какой-то момент появляется таблица, которая становится «навигационной» — в ней содержатся ссылки на другие таблицы, их описание, цели и назначение. Это и есть наш «пакет с пакетами», только в формате таблицы с таблицами.

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

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

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

  1. Любая разработка, даже небольшое MVP, объединяющее 2—3 таблицы, со временем превращается в монстра, который учитывает всё и сразу.
  2. Накладные расходы на разработку и поддержку таких решений значительно выше, чем при работе с таблицами.

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

Когда количество вкладок переваливает за 10—15 штук, у вас появляется лист с навигацией. Всё возвращается к исходной точке — «пакету с пакетами».

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

И ещё один совет: храните резервные копии. Скачивайте их локально или делайте бэкапы в формате Excel, на ПК или сервер. А ещё лучше — настроить автоматическую синхронизацию с Яндекс.Документами, VK или другими сервисами. Формулы, конечно, не сохранятся, но данные останутся в целости.

Парадоксы управления

Вопрос: как управленец, вы должны быть:
Уверенным или скромным? Стратегом или тактиком? Энергичным или спокойным?

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

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

Уверенность vs Скромность

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

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

Вывод: Уверенность необходима для поддержания морального духа и направления к целям. Однако скромность и искренность важны для решения сложных проблем на пути к этим целям.

Стратегия vs Тактика

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

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

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

Решительность vs Гибкость

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

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

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

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

Стойкость vs Уязвимость

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

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

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

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

Эмпатия vs Жесткость

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

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

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

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

Делегирование vs Контроль

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

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

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

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

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

Энергичность vs Спокойствие

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

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

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

Сдержанность vs Прозрачность

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

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

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

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

Личное vs Профессиональное

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

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

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

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

Итог

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

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

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

Завеса перфекционизма

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

Возьмем, к примеру, коробку для iPhone. Стив Джобс и Джонатан Айв превратили распаковку телефона в особый опыт, стремясь к совершенству в каждой детали. Они рассматривали этот момент как еще одну возможность впечатлить клиента и улучшить пользовательский опыт.

Глядя на это, многие приходят к выводу: «Я должен контролировать каждый аспект, сделать все возможное, чтобы добиться совершенства». Но есть одна проблема.

Совершенство не существует.

Несмотря на все культурные нарративы, утверждающие обратное. Люди, за которыми вы следите в социальных сетях, здания и архитектура, которыми вы восхищаетесь — не идеальны.

Эта вера в перфекционизм и есть то, что называется завесой совершенства.

Истоки перфекционизма

Перфекционизм часто рождается из потребности в контроле, которая нередко (хотя и не всегда) берет начало в детстве.

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

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

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

Как пишет психолог Адам Грант:
«Множество исследований показывают, что перфекционисты склонны определять превосходство по чужим меркам. Эта сосредоточенность на создании безупречного образа в глазах других является фактором риска депрессии, тревожности, выгорания и других проблем с психическим здоровьем...»

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

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

Президент Дуайт Д. Эйзенхауэр, напротив, управлял совершенно иначе. Когда ему подали два важных конверта с пометкой «Конфиденциально и секретно», Эйзенхауэр ответил: «Никогда не приносите мне запечатанный конверт. Для этого у меня есть штат.»

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

В современном быстро меняющемся мире вам не нужно совершенство, вам нужен минимально жизнеспособный продукт (MVP), который переведет вас из точки А в точку Б — оставьте «совершенство» на потом. Чаще всего самое важное — это не совершенство, а начало действий.

Грант, «Перфекционизм загоняет нас в спираль туннельного зрения и избегания ошибок: он мешает нам видеть более крупные проблемы и ограничивает нас освоением все более узких навыков.»
Во-вторых, играя в игру перфекциониста, мы отдаем свое психическое здоровье в руки реакций людей на то, что мы делаем. Наше стремление к совершенству, таким образом, диктуется не нашими собственными стандартами, а стандартами, которые другие накладывают на нашу работу, а они могут постоянно меняться.

Искоренение перфекционизма

Лучшее — враг хорошего, гласит поговорка, и это правда. Чаще всего «хорошее» лучше, чем ничего. Хорошее — это прогресс в достижении цели.

Вот три способа перейти от перфекционистского мышления к мышлению роста:

Первый: Сосредоточьтесь на улучшении

Есть разница между совершенством и постепенным улучшением. Совершенство — это существительное, оно привязано к пункту назначения. Улучшение — это глагол, оно активно, всегда в движении, всегда стремится стать лучше.

Второй: Терпимость к недостаткам

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

Успех определяется не достижением совершенства, а тем, насколько мы преодолеваем в наших стремлениях к совершенству.

Третье: Следите за временем

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

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

Итого

Мы никогда не найдем совершенства, мы можем только продолжать свой путь к нему.

Транскрибация встреч: Когда лень — двигатель прогресса

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

Лично я склоняюсь к мысли, что специалист всегда эффективнее в офисе. Этому есть множество причин, но это тема для отдельного глубокого погружения.

Онлайн-встречи: Новая форма корпоративной пытки?

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

Не будем долго задерживаться на очевидных моментах:

  1. Выбор надежной платформы для видеоконференций
  2. Проверка качества интернет-соединения перед встречей
  3. Использование качественного микрофона и наушников
  4. Подготовка и рассылка повестки дня заранее
  5. Установка четких целей и ожидаемых результатов встречи
  6. Ограничение продолжительности встречи (идеально 30-45 минут)
  7. Назначение модератора для управления ходом встречи
  8. Использование функции «поднятия руки» для упорядочения высказываний
  9. Минимизация фонового шума и отвлекающих факторов
  10. Включение видео для улучшения вовлеченности участников
  11. Использование инструментов для совместной работы (доски, презентации)
  12. Регулярные паузы для поддержания концентрации (в длительных встречах)
  13. Запись встречи для последующего анализа и для отсутствующих участников
  14. Использование сервисов транскрибации для создания текстового протокола
  15. Подведение итогов и распределение задач в конце встречи
  16. Отправка краткого резюме и списка действий после встречи
  17. Сбор обратной связи от участников для улучшения будущих встреч
  18. Проверка технического оборудования перед началом встречи
  19. Использование функции демонстрации экрана для наглядности
  20. Соблюдение этикета онлайн-общения (не перебивать, быть вежливым)

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

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

В поисках идеального решения

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

Мы долго использовали Zoom и Google Meet. От Zoom отказались из-за 30-минутного ограничения, а покупать подписку, когда есть бесплатные аналоги, казалось неразумным. Google Meet прекрасен, но без функции записи.

Яндекс Телемост стал находкой — с функцией записи созвонов. Но сервисов, работающих с ним, оказалось крайне мало.

И вот однажды, листая ProductRadar, я наткнулся на сервис MyMeet, обещающий ИИ, транскрибацию и выводы. ИИ нас особо не интересовал (вероятно, маркетинговый ход), а вот транскрибация в сочетании с Телемостом — это то, что нужно.

MyMeet: Спаситель или очередной хайп?

После нескольких тестов стало ясно — сервис работает отлично. Текст разбирается качественно, на выходе получаем HTML и PDF с разделением по ролям — просто мечта!

Как это работает? Создаем встречу в Телемосте, Zoom, Google Meet или Сбер Джазз, указываем ссылку в личном кабинете MyMeet. Вскоре к встрече присоединяется бот и начинает запись.

По окончании встречи в личном кабинете появляется запись с текстом, разделенным по ролям (которые можно назвать по именам), и возможностью скачать PDF. Вишенка на торте — ИИ делает выводы по встрече и выделяет задачи, требующие выполнения.

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

Маркетплейсы: рай для продавцов или билет в один конец?

В последние годы маркетплейсы стали доминирующей силой в сфере ecom. Они предлагают продавцам доступ к огромной аудитории, удобную логистику и кажущуюся простоту ведения бизнеса. Для покупателя так же отличный сервис, пара кликов и товар около дома. Однако так ли безоблачно будущее этой модели? Давайте рассмотрим текущую ситуацию и попробуем заглянуть в будущее.

Сегодня

Сегодня маркетплейсы кажутся очевидным выбором для многих предпринимателей:

Огромная аудитория

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

Удобная логистика

Маркетплейсы часто берут на себя хранение, упаковку и доставку товаров.

Быстрый старт

Не нужно разрабатывать собственный сайт или приложение.

Режим «одного окна»:

Покупатели могут приобрести разные категории товаров в одном месте.

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

Проблемы

Ужесточение условий

Маркетплейсы постоянно меняют правила игры, часто не в пользу продавцов. Например, Wildberries в 2022 году отключил личные кабинеты продавцов с рейтингом ниже 60%, а затем перестал работать по схеме «Маркетплейс» с теми, у кого рейтинг ниже 90%.

Высокие комиссии и штрафы

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

Отсутствие контроля над ценообразованием

Маркетплейсы часто проводят акции и распродажи без согласования с продавцами, что может приводить к продажам в убыток. Например, компания Don’t Worry была вынуждена продавать кофе на 10% ниже себестоимости из-за условий акции на платформе.

Высокая конкуренция

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

Отсутствие прямого контакта с покупателем

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

Ограниченная аналитика

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

Зависимость от алгоритмов площадки

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

Свой интернет-магазин?

Учитывая эти проблемы, многие продавцы начинают задумываться о создании или возвращении к собственным интернет-магазинам. Эта тенденция набирает обороты не только в России, но и на глобальном рынке, включая продавцов на Amazon.

Почитать про зарубежную практику можно тут: https://www.quora.com/unanswered/Why-are-e-commerce-sellers-leaving-Amazon

Свой магазин дает несколько существенных преимуществ.

Контроль над бизнесом

Вы сами устанавливаете правила, проводите акции и определяете ценовую политику.

Прямой контакт с клиентами

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

Полная аналитика

Доступ к детальной информации о поведении пользователей на сайте.

Развитие бренда

Возможность создать уникальный образ и повысить узнаваемость бренда.

Отсутствие прямой конкуренции на странице товара

Покупатель видит только ваши предложения.

Гибкость в интеграциях

Возможность подключать различные сервисы и системы для оптимизации бизнес-процессов.

Снова проблемы

Однако переход на собственную платформу сопряжен с определенными трудностями:

Высокие начальные инвестиции

Разработка качественного интернет-магазина может стоить от 1 миллиона рублей.

Необходимость привлечения трафика

Придется самостоятельно заниматься продвижением и привлечением клиентов.

Организация логистики

Нужно будет решать вопросы хранения, упаковки и доставки товаров.

Техническая поддержка и обновления

Потребуется постоянно поддерживать работоспособность сайта и обновлять его.

Гибридная модель

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

  1. Развитие собственного интернет-магазина для формирования лояльной аудитории и увеличения маржинальности.
  2. Omnichannel-подход: интеграция онлайн и офлайн каналов продаж для создания единого пользовательского опыта.

Заключение

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

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

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

Agile-проекты превратились в проекты Waterfall со спринтами

Из гибких проектов высосана вся гибкость

Agile-проекты превратились в раздутые, неповоротливые Waterfall проекты с двухнедельными спринтами. Подход Waterfall подходит для проектов с известными и конечными требованиями или для создания типовых продуктов, но не для уникальных программных решений.

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

Agile-манифест дает возможность небольшим командам создавать программное обеспечение с минимальным руководством, поощряя самостоятельность и инициативу.

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

Agile обещал ускорить разработку ПО и обеспечить клиента более быстрый возврат инвестиций за счет быстрой скорости разработки и вывода проект. Однако реальность часто не соответствует этим ожиданиям, и в 99% случаев результаты agile-проектов разочаровывают.

Агайл превращается в скуфа

Agile стал настолько популярным, что клиенты или выбирают компании / команды которые работаю с ним или начали требовать agile подход у проекта, даже если этот подход не подходил для их задач или у них не было нужных специалистов.

В книге «Sooner Safer Happier» авторы критикуют тенденцию использовать Agile формально, вместо того чтобы действительно быть гибкими. Agile превратился в продукт, а не образ мышления.

Многие компании и команды разработчиков стремятся к «agile-поставке», которая включает бэклоги продукта, спринты и фиксированные сроки/стоимость. При этом ключевые элементы гибкости часто игнорируются:

  1. Ретроспективы исчезли
  2. Гибкость и изменение методов работы ушли в прошлое
  3. Быстрая поставка в производство стала редкостью
  4. Ожидается строгое соблюдение сроков
  5. Команды лишены реальных полномочий и автономии

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

Само слово «Agile» потеряло свое значение, а из Agile-проектов выжали всю реальную гибкость.

Худший из миров

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

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

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

Wagile

«Гибридный» подход, сочетающий элементы Agile и каскадной модели (иногда называемый «wagile»), не подходит для создания уникального программного обеспечения. Это попытка совместить несовместимое, которая приводит к созданию нереалистичных планов, задержкам и увеличению затрат.

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

Зачем мы сюда попали?

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

Теперь мы наблюдаем эффект «трава зеленее»:

  1. Раньше, на фоне проблем Водопада, Agile казался идеальным решением
  2. Теперь, столкнувшись с проблемами Agile, некоторые ностальгируют по более структурированным подходам

Слишком заняты, чтобы думать

Agile-проекты когда-то привлекали возможностью начать с несовершенного процесса и постепенно его улучшать. Команды разработчиков чувствовали себя более вовлеченными, когда их просили выявлять проблемы и предлагать решения (хотя эти предложения часто игнорировались из-за их сложности).

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

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

Заключение

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

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

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

Ключевые факторы успеха проекта остаются неизменными:

  1. Четкое понимание целей проекта
  2. Эффективная коммуникация между всеми участниками
  3. Компетентная и мотивированная команда
  4. Реалистичные ожидания и планирование
  5. Гибкость в адаптации к изменениям
  6. Фокус на создании ценности для пользователей

Вместо слепого следования какой-либо методологии, командам стоит:

  1. Критически оценивать свои процессы и постоянно их улучшать
  2. Адаптировать подходы под специфику конкретного проекта и команды
  3. Поощрять открытое обсуждение проблем и поиск решений
  4. Фокусироваться на результатах и ценности для пользователей, а не на формальном соблюдении процессов
  5. Инвестировать в развитие навыков и знаний членов команды
  6. Поддерживать культуру доверия, ответственности и постоянного обучения

Будущее разработки ПО не в слепом следовании какой-либо методологии, а в умении гибко комбинировать различные подходы и практики, адаптируясь к уникальным потребностям каждого проекта и команды. Успешные организации будут те, которые смогут создать культуру постоянного совершенствования и адаптации, где методологии служат инструментом, а не самоцелью.

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

Saas vs Self-Hosted: Что выбрать?

Сегодня хочу поделиться с вами своими мыслями и опытом по вопросу выбора SaaS или self-hosted решения? Я прошел через этот выбор не раз и не два, и хочу рассказать вам, какие подводные камни встречаются на этом пути.

Сразу хочу заметить, что выбор очень сильно зависит от размеров компании, команд, стадии развития и других факторов. Если вы маленький стартап или небольшой бизнес, то SaaS вероятно будет лучшим выбором. А если вы крупная корпорация, то выбор по сути уже не стоит — вам, скорее всего, понадобится комбинация обоих подходов с уклоном в self-hosted решения.

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

Для начала, давайте разберемся, о чем вообще речь. SaaS (Software as a Service) — это когда вы платите за подписку на готовое облачное решение. Вроде как удобно: заплатил — и пользуйся. Self-hosted, с другой стороны, это когда вы берете софт под свой контроль, устанавливаете его на свои сервера и сами им управляете. Звучит сложнее, но у этого подхода есть свои преимущества.

У себя в компании мы взяли курс на self-hosted решения и стараемся отказываться от SaaS по мере возможностей, но, тем не менее, эти решения все еще занимают значительную часть используемого нами ПО. Почему так?

Преимущества SaaS, или почему это так соблазнительно

Быстрый старт.

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

Экономия на старте.

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

Масштабируемость

Растет бизнес — растут потребности. С SaaS это не проблема: нужно больше места или пользователей — просто меняешь тариф. Никаких головных болей с апгрейдом железа или покупкой новых лицензий.

Автоматические обновления

Честно говоря, я обожаю эту часть. Просыпаешься утром, а тут — бац! — новые фичи в твоем любимом сервисе. И ничего делать не нужно, все само.

Работа отовсюду

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

Поддержка 24/7

Когда у тебя нет собственного IT подразделения (а у многих малых бизнесов его нет), техподдержка SaaS-сервисов — это просто спасение.

Но не все так радужно в мире SaaS. Есть и обратная сторона медали.

Недостатки SaaS, или почему мы начали смотреть в сторону self-hosted

Ограниченная кастомизация

Бывало, сидишь и думаешь: «Вот бы в этом отчете кнопка была здесь, а это поле — вон там». Но нет, в SaaS ты пользуешься тем, что дают. Иногда это реально бесит.

Зависимость от интернета

Однажды у нас отключили интернет на полдня. Все, приехали — работа встала. С self-hosted такого бы не случилось.

Безопасность данных

Я параноик? Возможно. Но мысль о том, что все наши данные хранятся где-то «в облаке», иногда не дает мне спать спокойно.

Неожиданные ограничения

Помню, как мы уперлись в лимит хранилища на одном SaaS-сервисе. Чтобы его увеличить, пришлось переходить на тариф, который был нам вообще не нужен по функционалу. Деньги на ветер!

Сложности с миграцией

Решили мы как-то сменить одно SaaS-решение на другое. Боже, какой это был ад с переносом данных! Никогда больше.

Преимущества self-hosted, или почему мы все больше смотрим в эту сторону

Полный контроль

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

Кастомизация по полной

Хочешь добавить новую фичу? Вперед! С self-hosted решениями ты можешь подкрутить систему под себя как душе угодно.

Независимость

Никаких внезапных изменений в политике провайдера, никаких неожиданных повышений цен. Ты сам себе хозяин.

Потенциальная экономия в долгосрочной перспективе

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

Но и у self-hosted есть свои минусы:

  1. Высокие начальные затраты Серверы, лицензии, настройка — все это стоит денег. И немалых.
  2. Нужны специалисты Без толкового айтишника тут никуда. А хорошие спецы стоят дорого.
  3. Ответственность за все Обновления, безопасность, бэкапы — все на твоих плечах. Иногда это реально выматывает.
  4. Сложности с масштабированием Нужно больше мощностей? Готовься к новым затратам и головной боли с настройкой.

Так что же выбрать?

Честно? Нет универсального ответа. В нашей компании мы используем микс из SaaS и self-hosted решений. Для каких-то задач удобнее и выгоднее SaaS, для других — self-hosted.

Вот несколько советов из моего опыта:

  1. Рассматривайте варианты. Есть масса бесплатных self-hoste решений, да возможно, они хуже saas, но их можно дорабатывать
  2. Интеграции. Перед внедрением, оцените насколько новый сервис интегрируем с текущими.
  3. Комьюнити. Бери решение где шире распространение, если возникнут сложности — вы сможете найти единомышленников.
  4. Стек и API. Смотрите свой стек или api должно быть открытым со всеми возможностями.
  5. Оцените свой бюджет. Если денег в обрез, начните с SaaS.
  6. Подумайте о безопасности. Работаете с чувствительными данными? Лучше self-hosted.
  7. Оцените свои технические возможности. Нет айтишников? SaaS будет проще.
  8. Подумайте о будущем. Планируете быстрый рост? SaaS легче масштабировать.
  9. Проанализируйте свои бизнес-процессы. Нужна глубокая кастомизация? Смотрите в сторону self-hosted.

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

Бюрократ, самодур, циник и наседка

Интересная свойства для руководителя, не правда ли?

Не так давно я вернулся с конференции для агентств и продакшенов, где темы были довольно интересными, а спикеры поделились ценным контентом и своими инсайтами. Среди всех выступлений особенно запомнился доклад Алексея Кельина на тему «Выращиваем управленческий состав. Модель органичного лидерства».

Эта тема откликнулась в моем сердце, вероятно, потому что она лично для меня довольно интересная, болезненная, и именно этим я сейчас активно пытаюсь заниматься в своей работе. Сам доклад был довольно коротким для столь обширной темы, но, как оказалось, существует версия лекции продолжительностью 2,5 часа, доступная на YouTube.

Я не мог упустить возможность углубиться в эту тему и посмотрел полную версию.
Лекция Алексея раскрывает множество аспектов лидерства и управления, от базовых стратегий до высших уровней развития руководителя. Она заставляет задуматься о собственном стиле управления, его сильных сторонах и возможных «подводных камнях». Более того, она предлагает пути развития для лидеров, стремящихся выйти на новый уровень управления.

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

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

Базовые стратегии управления

  1. Командир: Использует личную власть и авторитет для достижения целей. Командир добивается исполнения через прямые указания и контроль.
  2. Опекун: Объединяет людей и налаживает связи между ними. Опекун фокусируется на создании гармоничной рабочей атмосферы и поддержке сотрудников.
  3. Координатор: Обеспечивает взаимодействие между сотрудниками и является связующим звеном. Координатор организует работу команды и следит за выполнением задач.
  4. Регулятор: Достигает исполнения через внедрение и поддержание правил и нормативов. Регулятор создает систему правил и процедур для эффективной работы.

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

«Темная сторона» базовых стратегий

Каждая стратегия может иметь свою «темную сторону»:

  1. Регулятор может стать бюрократом-формалистом, чрезмерно фокусируясь на правилах в ущерб эффективности.
  2. Командир может превратиться в тирана-руководителя, ценящего личную преданность выше эффективности.
  3. Опекун рискует стать чрезмерно заботливой «нянькой», не давая сотрудникам возможности развиваться самостоятельно.
  4. Координатор может стать «подрезателем», постоянно меняющим планы и цели без объяснения причин.

Условия перехода на «темную сторону» включают выгорание, потерю мотивации, несоответствие команды стилю управления и отсутствие интересных целей.

Объединяющие лидерские стратегии

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

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

Развитие лидера и следующий уровень

Для перехода на новый уровень лидеры должны освоить смежные стратегии и преодолеть определенные внутренние барьеры:

Вождь (развитие командира)

  1. Должен освоить навыки регулятора и опекуна.
  2. Создает систему порядка, безопасности выполнения плана и лояльности.
  3. Выстраивает иерархию, распределение власти и идентичность «племени».

Синергет (развитие опекуна):

  1. Выстраивает систему отношений внутри команды, горизонтальную коммуникацию и систему ценностей.
  2. Должен отказаться от роли связующего звена команды и перестать быть «оболочкой» команды.

Визионер (развитие координатора):

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

Франшизер (развитие регулятора в бизнес-технолога):

  1. Создает эвристики для эффективного управления и принятия решений.
  2. Должен допустить людей к формированию правил, но только проверенных и надежных.
  3. Разрабатывает системы поддержки, которые позволяют масштабировать бизнес.

Цена развития и «ночные кошмары» лидеров

Переход на следующий уровень требует внутренней трансформации и готовности платить определенную цену:

  1. Командиры должны отказаться от своего эго и научиться сдерживаться. Их «ночной кошмар» — делегирование власти.
  2. Опекуны должны перестать быть связующим звеном команды. Их страх — потеря любви и уважения сотрудников.
  3. Координаторы должны научиться делегировать контроль. Их опасение — потеря контроля над происходящим.
  4. Регуляторы боятся анархии и отсутствия правил, поэтому должны научиться доверять установлению правил на нижестоящих уровнях.

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

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

Ссылочка на видео, спешите пока еще работает: https://www.youtube.com/watch?v=PbxZaaXTGn4

TG Алексея — https://t.me/AlexeyKelyin

Удаленка умирает? Не спешите с выводами!

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

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

Эрик Юань основатель Zoom, неоднократно говорил о преимуществах удаленной работы, особенно в контексте пандемии COVID-19. Он признает, что гибридная модель (сочетание удаленной и офисной работы) будет нормой для многих компаний в будущем. Однако он также отметил, что, несмотря на популярность удаленной работы, для многих сотрудников важно возвращение в офис для сохранения корпоративной культуры и продуктивного взаимодействия.

Джейми Даймон (CEO JPMorgan Chase) выразил свое негативное отношение к долгосрочной удаленной работе, особенно для младших сотрудников. Он считает, что удаленная работа не подходит для обучения новых сотрудников и для креативных процессов. Даймон также подчеркнул важность личного присутствия для корпоративной культуры и формирования командного духа.

Илон Маск (CEO Tesla и SpaceX) был одним из самых известных противников удаленной работы. Он заявил, что все сотрудники Tesla и SpaceX должны вернуться в офисы на полный рабочий день, если они хотят продолжать работать в компании. Маск считает, что личное присутствие необходимо для достижения высоких стандартов производительности и инноваций, особенно в таких компаниях, как Tesla, где нужно создавать и тестировать физические продукты.

Диагноз по аватарке

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

Эпоха пандемии ушла

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

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

Удаленка не работает для 90% людей

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

Эра фриланса и удаленной работы уходит

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

Плохой баланс между работой и личной жизнью

Работай где хочешь и когда хочешь! Разве это не прекрасно?

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

Удаленка не умрет, не сейчас

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

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

Ранее Ctrl + ↓