Сообщество - IT - Менеджмент

IT - Менеджмент

39 постов 236 подписчиков

Популярные теги в сообществе:

Проверка гипотез по методике HADI

HADI - это метод проверки гипотез, который состоит из 4-х основных этапов: гипотеза → действие → данные → выводы. Этапы идут последовательно один за другим. Затем цикл повторяется снова.

Проверка гипотез по методике HADI Разработка, Тестирование, Гипотеза, Идея, Рекомендации, Совет, Саморазвитие, Длиннопост

Стандартный HADI-цикл

Hypothesis (Гипотеза). На этом этапе выдвигается гипотеза — предположение, что какое-то действие поможет получить конкретный эффект. Гипотеза всегда требует подтверждения или опровержения.

Вот пример гипотезы: «Если я буду делать рекламные посты своего интернет-магазина в профильных крупных телеграм-каналах, численностью от 100.000 подписчиков, я смогу привлекать по 100 новых клиентов с каждой рекламы». Конкретное действие здесь — разместить рекламный пост в тг-канале. А конкретный результат — привлечь 100 клиентов.

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

Вот еще несколько советов, как поставить гипотезу:

  • Цель гипотезы не должна быть недостижимой. Не стоит ставить цель «Привлечь 10.000 клиентов с одной рекламы».

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

Когда вы придумываете гипотезу, оцените ее по 2 параметрам:

  • вера команды в идею в процентах от 1 до 100;

  • сложность реализации по обычной шкале от 1 до 5.

И если получите идею со сложностью 4 балла из 5, но с верой команды всего на 30 % — задумаетесь, стоит ли пробовать.

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

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

Data (Сбор данных). На третьем этапе собираются данные. Они показывают, подтвердилась гипотеза или нет. Данные могут быть количественными и качественными — в зависимости от гипотезы.

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

Insights (Выводы). Последний этап — выводы из данных. Выводы подтверждают или опровергают гипотезу. Можно просто сравнить полученные результаты с ожидаемыми, а можно подключать статистические методы.

Когда использовать HADI-циклы

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

Преимущества HADI-циклов

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

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

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

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

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

Вовлечение команды. В конце каждого цикла можно делать чек-поинты и обсуждать, чего добилась команда. На что стоит направить больше сил, а на что — денег.

Какие сложности возникают при работе с HADI-циклами

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

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

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

Правильно интерпретировать данные и выводы. Сравнивать нужно конкретные цифры и по конкретным метрикам. Если гипотеза ошибочна — не стоит оправдывать её внешними факторами. Лучше сформулировать новую и протестировать её.

Источники: раз, два

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

Показать полностью 1

В продолжение предыдущих статей о Модели Маккинси (McKinsey) 7-S и Модели ADKAR

В прошлых статьях на Пикабу и на канале Самоучки (Управление проектами), мы рассматривали Модель Маккинси (McKinsey) 7-S и Модель ADKAR

Давайте рассмотрим три других важных подхода к управлению изменениями: Модель управления изменениями Курта Левина, Модель перехода Уильяма Бриджеса и Модель управления изменениями Вирджинии Сатир. Эти модели тоже предлагают уникальные методы и принципы, которые могут быть полезны в управлении проектами и изменениями в организации.

Модель управления изменениями Левина

В продолжение предыдущих статей о Модели Маккинси (McKinsey) 7-S и Модели ADKAR Развитие, Карьера, Управление проектами, Длиннопост

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

1. Размораживание (Unfreezing)

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

  • Как применять:

    • Объясните сотрудникам необходимость изменений, используя данные и факты.

    • Создайте чувство неотложности.

    • Привлеките лидеров мнений для поддержки изменений.

    • Проведите диагностику текущего состояния и определите зоны для улучшений.

2. Изменение (Change)

  • Что это: Реальное внедрение изменений. Включает обучение новым навыкам и внедрение новых процессов или систем.

  • Как применять:

    • Обеспечьте обучение сотрудников.

    • Поддерживайте открытость и коммуникацию.

    • Внедряйте изменения постепенно, чтобы дать время на адаптацию.

    • Назначьте ответственных за изменения и установите сроки выполнения.

3. Замораживание (Refreezing)

  • Что это: Закрепление изменений, чтобы они стали постоянными.

  • Как применять:

    • Укрепляйте новые нормы и стандарты.

    • Поддерживайте постоянное обучение и развитие.

    • Проводите регулярные проверки и мониторинг.

    • Поддерживайте обратную связь и вовлеченность сотрудников.

Модель перехода Уильяма Бриджеса

В продолжение предыдущих статей о Модели Маккинси (McKinsey) 7-S и Модели ADKAR Развитие, Карьера, Управление проектами, Длиннопост

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

1. Завершение, потеря и отпускание (Ending, Losing, and Letting Go)

  • Что это: Этап осознания и принятия потерь старых привычек и способов работы.

  • Как применять:

    • Признавайте и обсуждайте чувства сотрудников.

    • Обеспечьте поддержку и консультации.

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

2. Нейтральная зона (Neutral Zone)

  • Что это: Промежуточная фаза, когда старое уже ушло, но новое еще не полностью внедрено.

  • Как применять:

    • Обеспечьте ясное руководство и поддержку.

    • Уделяйте внимание коммуникации и прозрачности.

    • Поощряйте креативность и новые идеи.

    • Поддерживайте сотрудников через тренинги и наставничество.

3. Новый старт (New Beginning)

  • Что это: Фаза принятия и внедрения новых способов работы.

  • Как применять:

    • Вдохновляйте сотрудников и поощряйте позитивные изменения.

    • Укрепляйте новые навыки и знания.

    • Создавайте позитивную атмосферу и поощряйте достижения.

    • Обеспечьте непрерывную поддержку и развитие.

Модель управления изменениями Вирджинии Сатир

В продолжение предыдущих статей о Модели Маккинси (McKinsey) 7-S и Модели ADKAR Развитие, Карьера, Управление проектами, Длиннопост

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

1. Статус-кво (Status Quo)

  • Что это: Начальная точка, когда система работает по устоявшимся правилам и нормам.

  • Как применять:

    • Оцените текущую ситуацию и определите, что требует изменений.

    • Вовлекайте сотрудников в процесс оценки.

2. Сопротивление (Resistance)

  • Что это: Реакция на изменения, включающая страх, тревогу и нежелание принимать новые условия.

  • Как применять:

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

  • Организуйте открытые обсуждения и предоставьте возможность сотрудникам выразить свои опасения и вопросы.

  • Обеспечьте поддержку и обучение, чтобы уменьшить страх перед неизвестным.

  • Привлекайте лидеров мнений и тех, кто уже поддерживает изменения, для снижения общего уровня сопротивления.

3. Хаос (Chaos)

  • Что это: Период неопределенности и дезорганизации.

  • Как применять:

    • Управляйте стрессом и сопротивлением.

    • Обеспечьте поддержку и коммуникацию.

    • Проводите тренинги и информируйте о прогрессе изменений.

4. Интеграция (Integration)

  • Что это: Внедрение новых методов и подходов.

  • Как применять:

    • Организуйте обучение и наставничество.

    • Обеспечьте необходимые ресурсы для успешной интеграции.

    • Поддерживайте сотрудников и поощряйте адаптацию.

5. Новый статус-кво  (New Status Quo)

  • Что это: Достижение новой стабильности, когда новые методы становятся нормой.

  • Как применять:

    • Укрепляйте новые процессы и практики.

    • Проводите регулярные оценки и корректировки.

    • Поощряйте постоянное развитие и улучшение.

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

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

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

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

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

Для более глубокого понимания и практического применения этих моделей управления изменениями, рекомендуется ознакомиться с материалами канала "Самоучки IT (Управление проектами) ", где можно найти множество полезных советов и примеров по управлению проектами и изменениями.

В следующей статье мы  рассмотрим:

  • Модель Маурера

  • Модель 7-ми навыков Стивена Кови

  • Теорию подталкивания

  • Кривую изменений Кюблер-Росс

Следите за обновлениями, чтобы узнать больше о лучших практиках и методах управления проектами и изменениями!

Показать полностью 3

Что такое SWOT-анализ и чем он полезен в проектах

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

1.  Что такое SWOT-анализ

SWOT-анализ — метод стратегического планирования. Он представляет собой анализ четырёх групп факторов, которые влияют на компанию/проект. Аббревиатура SWOT образована от сокращения слов по заглавным буквам:

·  S (strengths) — сильные стороны — преимущества, сильные стороны, уникальные характеристики.

·  W (weaknesses) — слабые стороны — недостатки, слабые стороны, которые тормозят проект.

·  O (opportunities) — возможности — то, что способно улучшить положение в проекте.

·  T (threats) — угрозы — потенциальная опасность, из-за которой проект может пострадать.

SWOT-анализ состоит из двух этапов. На первом этапе заполняют таблицу, представленную на рисунке ниже.

Что такое SWOT-анализ и чем он полезен в проектах Саморазвитие, Совет, Рекомендации, Управление проектами, Проект, Длиннопост

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

Strengths и Weaknesses — внутренние факторы, на которые можно повлиять: состав команды проекта, распределение ролей, расстановка приоритетов. Opportunities и Threats — внешние факторы, никак от нас не зависящие: регуляторные факторы, предоставление информации и принятие решений Заказчиком.

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

2.  Кому и для чего нужен SWOT-анализ

Вот для чего в проектах можно использовать SWOT-анализ:

·  осмыслить свои сильные стороны и сформировать свою уникальность для Заказчика;

·  найти слабые места и понять, как от них избавиться — например, как улучшить процессы и избежать потенциальных проблем;

·  оценить возможные угрозы и разработать план их предотвращения или минимизации;

·  определить цели проекта на краткий или долгий срок;

·  обнаружить направления, в которых в проекте есть потенциал для развития, и найти способы их освоить (доп.продажи Заказчику);

·  выяснить, какие ресурсы понадобятся для успешной реализации проекта.

Что ещё можно анализировать с помощью SWOT?

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

Ещё есть SWOT-анализ профессии — его проводят, когда выбирают специальность или задумываются о карьерном росте. Благодаря методу можно понять, какая профессия вам подойдёт. Например, сможете ли вы в дальнейшем стать руководителем.

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

3.  Виды SWOT-анализа компании

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

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

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

4.  Как провести SWOT-анализ

Пошагово разберём, как сделать экспресс-анализ.

Шаг 1. Strengths — поиск сильных сторон

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

Чтобы найти сильные стороны для SWOT-анализа, можно ответить на вопросы:

·  Чем вы отличаетесь от других команд или конкурентов в лучшую сторону?

·  Почему Заказчик выбрал именно вас (ваш продукт)?

·  Какую обратную связь вы получаете от других Заказчиков?

·  Какие компетенции и опыт есть у вашей команды?

·  Какие особые технологии вы используете? Насколько хорошо у вас выстроены процессы?

·  Благодаря чему вы можете расширять своё влияние в Заказчике?

Шаг 2. Weaknesses — поиск слабых сторон

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

Чтобы найти слабые стороны для SWOT-анализа, можно ответить на вопросы:

·  Какую негативную обратную связь вы получаете от Заказчиков?

·  В чём ваша команда хуже, чем другие (у вас в компании или по сравнению с конкурентами)?

·  Какие ошибки постоянно возникают в бизнес-процессах?

·  Что мешает выполнять поставленные задачи?

Шаг 3. Opportunities — поиск возможностей

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

Например, уход зарубежных вендоров, обнаружение проблем у Заказчика, которые вы знаете как решать.

Шаг 4. Threats — поиск угроз

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

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

Шаг 5. Подготовка матрицы решений

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

S + O — какие сильные стороны помогут реализовать возможности.

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

S + T — как сильные стороны помогут защититься от угроз.

W + T — какие слабые стороны повышают вероятность, что угрозы навредят проекту.

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

5.  SWOT-анализ — сильные и слабые стороны

Что такое SWOT-анализ и чем он полезен в проектах Саморазвитие, Совет, Рекомендации, Управление проектами, Проект, Длиннопост

Источники: раз, два, три

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

Показать полностью 2

Как выбрать квартиру и ни в чем не прогадать. Наглядное пособие

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

В конце экскурсии вас ждет подарок от застройщика, не пропустите!

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

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

Специально для пикабушников застройщик Level Group дарит промокод на скидку 1%! Все подробности смотрите здесь.

Выбирайте квартиру мечты в Level Селигерская и наслаждайтесь комфортом на новом уровне.


ВЫБРАТЬ КВАРТИРУ

Реклама ООО СЗ «Селигерский»

Показать полностью
pixel

Модель ADKAR в управлении изменениями

В нашей предыдущей статье мы рассмотрели модель McKinsey 7-S как инструмент управления изменениями. Сегодня мы подробно разберем другой эффективный подход — модель ADKAR. Эта модель, в отличие от McKinsey 7-S, фокусируется на индивидуальном уровне изменений.

Модель ADKAR в управлении изменениями Развитие, Управление проектами, Саморазвитие, Карьера, Образование, Длиннопост

·  Awareness (Осведомленность)

Что это: Понимание необходимости изменений.

Как применять: Четко объясняйте причины изменений, используйте данные и факты. Проводите регулярные встречи и презентации.

·  Desire (Желание)

Что это: Готовность поддержать изменения и участвовать в них.

Как применять: Показывайте выгоды от изменений для каждого сотрудника. Вовлекайте людей в процесс планирования изменений.

·  Knowledge (Знание)

Что это: Информация о том, как измениться.

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

·    Ability (Способность)

Что это: Навыки и поведение, необходимые для реализации изменений.

Как применять: Предоставьте возможности для практики. Обеспечьте поддержку  и обратную связь во время внедрения изменений.

·  Reinforcement (Закрепление)

Что это: Поддержание изменений в долгосрочной перспективе.

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

Различия между моделями ADKAR и McKinsey 7-S:

  1. Фокус: ADKAR сосредоточена на индивидуальных изменениях, в то время как 7-S рассматривает организацию в целом.

  2. Структура: ADKAR представляет собой последовательный процесс, а 7-S - взаимосвязанную систему элементов.

  3. Применение: ADKAR лучше подходит для управления конкретными изменениями, 7-S - для общего анализа и улучшения организации.

  4. Простота: ADKAR проще в понимании и применении, 7-S требует более глубокого анализа.

  5. Временная перспектива: ADKAR ориентирована на процесс изменений, 7-S на текущее и желаемое состояние организации.

Плюсы модели ADKAR:

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

  2. Простота: Легко понять и применить даже без специальной подготовки.

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

  4. Гибкость: Может применяться к различным типам изменений и в организациях разного масштаба.

  5. Измеримость: Каждый этап можно оценить, что позволяет отслеживать прогресс.

Минусы:

  1. Ограниченный фокус: Не учитывает организационные и системные аспекты изменений.

  2. Линейность: Может не учитывать сложность реальных ситуаций, где этапы могут перекрываться или идти непоследовательно.

  3. Отсутствие стратегического компонента: Больше подходит для тактической реализации, чем для стратегического планирования изменений.

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

  5. Ограниченное внимание к сопротивлению: Не предоставляет детальных стратегий преодоления сопротивления изменениям.

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

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

Канал "Самоучки IT(Управление проектами)" рекомендует использовать модель ADKAR вместе с другими инструментами управления проектами для достижения лучших результатов. Подписывайтесь на канал, чтобы не пропустить больше полезного и интересного материала.

Показать полностью

Что такое RACI-матрица и как она помогает управлять проектом

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

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

1.  Что такое матрица RACI?

Матрица RACI, или матрица ответственности, — инструмент для управления отношениями в команде. Это таблица, с помощью которой распределяют ответственность, полномочия и роли.

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

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

2.  Расшифровка

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

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

·  R (responsible) — исполнитель задачи или подзадачи проекта. Тот, кто самостоятельно выполняет все работы в рамках задачи.

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

·  A (accountable) — ответственный за всю задачу. Участник с этой ролью несёт ответственность за то, чтобы задачу завершили в срок, но не обязательно выполняет её сам. Часто A-участники назначают задачи и подзадачи R-участникам.

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

·  C (consult) — эксперт, который консультирует команду по вопросам, находящимся в его компетенции. Он не выполняет задачу, но даёт советы и рекомендации, которые помогают выполнить её эффективнее.

·  I (informed) — участник проекта, который должен быть в курсе выполнения задачи. Результат задачи или всего проекта влияет на дальнейшую деятельность I-участников, поэтому им важно следить, что происходит.

3.  Как построить матрицу ответственности RACI: разбираем на примере

Разберём процесс построения матрицы RACI пошагово, на примере разработки приложения для смартфона.

Шаг 1. Определяем задачи проекта

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

·  написать техническое задание для разработки приложения;

·  создать дизайн приложения;

·  разработать приложение;

·  протестировать приложение;

·  опубликовать приложение в сторах.

Шаг 2. Определяем участников проекта

По горизонтали выписываем исполнителей проекта — должности либо фамилии сотрудников:

·  менеджер проекта;

·  дизайнер;

·  разработчик;

·  тестировщик;

·  заказчик.

Получается вот такая таблица:

Что такое RACI-матрица и как она помогает управлять проектом Карьера, Развитие, Саморазвитие, Управление проектами, Проект, План, Совет, Рекомендации, Длиннопост

Шаг 3. Распределяем роли

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

R-участники. Это исполнители задач.

·  Писать техническое задание для приложения будет заказчик.

·  Заниматься дизайном — дизайнер.

·  Разрабатывать и тестировать приложение — разработчик и тестировщик.

·  Размещать приложение в магазинах — заказчик.

A-участники. Это ответственные за каждую задачу проекта.

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

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

C-участники. Это консультанты.

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

I-участники. Это исполнители, которых нужно информировать о ходе работ.

В нашем случае тестировщика нужно проинформировать о том, что разработчик закончил свои задачи, а заказчика — о том, что приложение готово и протестировано.

Что такое RACI-матрица и как она помогает управлять проектом Карьера, Развитие, Саморазвитие, Управление проектами, Проект, План, Совет, Рекомендации, Длиннопост

Так выглядит готовая матрица RACI для проекта разработки приложения

Шаг 4. Анализ матрицы и выявление пробелов

Мало просто построить матрицу ответственности, важно грамотно ей пользоваться.

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

Вот типичные ошибки, которые возникают при построении матрицы ответственности:

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

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

·  У участника проекта нет R- или A-роли. В этом случае нужно решить, действительно ли этот участник необходим проекту (речь не идёт о стейкхолдерах, которые могут быть только I). Возможно, стоит пересмотреть состав команды.

·  У задачи много ответственных. Могут возникнуть проблемы при согласовании результата: сколько ответственных, столько и мнений. В идеале на каждую задачу нужно назначать только одну A-роль.

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

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

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

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

4.  Модификации матрицы RACI

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

·  RACI-VS. V (verifier «верификатор») - тот, кто проверяет результат на соответствие заранее согласованным критериям, S (signatory «подписывающий») - тот, кто отвечает за сдачу работы заказчику. V- или S-участников может быть один или два.

·  RACIQ. Новая роль Q (quality) проверяет качество результата.

·  RASCI. Новая роль S (support) помогает основному исполнителю выполнять работу.

·  RACIO. Новая роль O (out of the loop «вне игры») - тот, кто не участвует в проекте.

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

5.  Сравнение RAPID, DACI и RACI

Существует несколько похожих моделей, которые путают с RACI. Например, RAPID и DACI, которые связаны с принятием решений и достижением консенсуса в группе.

Что такое RACI-матрица и как она помогает управлять проектом Карьера, Развитие, Саморазвитие, Управление проектами, Проект, План, Совет, Рекомендации, Длиннопост

Не буду подробно расписывать эти методологии. Если заинтересовало, можете погулить о них. Если коротко - методики RAPID и DACI используются группой перед началом действий, а RACI — это план, определяющий, кто будет эти действия выполнять.

6.  Плюсы и минусы матрицы RACI

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

Плюсы:

·  Ясное распределение ответственностей и ролей в команде.

·  Улучшение коммуникации и снижение конфликтов за счет четкого определения, кто отвечает за какие задачи.

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

·  Улучшение качества продукта или услуги за счет более ответственного подхода к выполнению задач.

Минусы:

·  Сложность внедрения и поддержания этой системы на больших проектах.

·  Дополнительные трудозатраты на разработку ещё одной системы в проекте.

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

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

7.  Заключение

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

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

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

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

Показать полностью 3

Управление изменениями: Как адаптироваться к новым вызовам

В 2024 году мир бизнеса меняется очень быстро. Чтобы не отставать, компании должны научиться быстро адаптироваться и внедрять новшества. Управление изменениями — это важный процесс, который помогает справляться с новыми вызовами. Сегодня я расскажу вам о модели McKinsey 7-S, и как она может помочь вам в управлении изменениями.

Что такое управление изменениями?

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

Почему это важно?

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

Управление изменениями: Как адаптироваться к новым вызовам Развитие, Саморазвитие, Управление проектами

Модель McKinsey 7-S

Модель McKinsey 7-S помогает разобраться, как все элементы компании должны работать вместе для успешных изменений. Она состоит из семи элементов:

  • Стратегия (Strategy)

Что это: Долгосрочные планы компании и пути их достижения.

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

  • Структура (Structure)

Что это: Распределение ролей и обязанностей в компании.

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

  • Системы (Systems)

Что это: Процессы и процедуры для выполнения ежедневных задач.

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

  • Стили управления (Style)

Что это: Способы руководства и взаимодействия с сотрудниками.

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

  • Сотрудники (Staff)

Что это: Люди, работающие в компании.

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

  • Навыки (Skills)

Что это: Ключевые компетенции и способности, необходимые для успеха.

Как применять: Выявите и развивайте критически важные навыки в компании.

  • Совместные ценности (Shared Values)

Что это: Основные принципы и убеждения, которыми руководствуются сотрудники.

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

Заключение

Модель McKinsey 7-S — отличный инструмент для управления изменениями. Она помогает учитывать все ключевые аспекты организации и гармонично интегрировать их. В следующих статьях мы расскажем о других популярных моделях управления изменениями, таких как модель Коттера, модель ADKAR и др.

Если вам интересно больше узнать о проектном управлении, рекомендую следить за каналом"Самоучки IT (Управление проектами)". Там много полезных материалов и советов.

Управление изменениями — это путь к устойчивому развитию и процветанию в постоянно меняющемся мире.

Показать полностью 1

Как в IT-проектах работать с возражением Заказчика «Почему так дорого?»

В предыдущих постах я писал о том, что делать, если Заказчик постоянно генерирует новые «хотелки» по ходу проекта (клац), и что делать, если он просит эти работы сделать бесплатно (клац).

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

Вводные:

Вы находитесь в проекте, у вас есть ограниченный объем работ, бюджет и срок. Заказчик приходит и озвучивает какую-то хотелку. Вы собираете требования, описываете их (ТЗ, ФТ, ТР, что угодно), согласовываете их с Заказчкиом и считаете стоимость этих работ. Но в ответ получаете возражение «а чего так дорого, там же программист за день сделает». Ещё в конце может добавить любимое: «Вы же эксперты».

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

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

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

И последнее: речь идёт о том, что вы для Заказчика – безальтернативный Исполнитель. Если новые работы будут вынесены на ЧЕСТНЫЙ открытый конкурс, где выбирать будут ТОЛЬКО по цене, то абсолютное большинство пунктов ниже будет неприменимо.

Варианты работы с возражением:

Сначала пытаемся договориться на полную стоимость:

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

2.  Обоснуйте сложность задачи. В 90% случаев Заказчик не понимает, почему простая, на первый взгляд, задача стоит так дорого. Нужно это понимание у Заказчика сформировать. Насколько подробно это надо обосновывать зависит от Заказчика – кому-то достаточно объяснения на бизнес уровне, а кому-то нужны будут все технические детали.

3.  Покажите трудозатраты на выполнение. Стоимость работ сама по себе ничего не говорит Заказчику о трудозатратах, которые вы потратите на эти работы. Можно продать 5 человеко-дней за 100.000 рублей, а можно за 1.000.000 руб. Поэтому иногда Заказчику можно сделать бюджетную оценку, в которой будет подробно расписан перечень работ и трудозатрат с разбивкой по специалистам. Например, задача №3 «Реализация кастомной формы на веб-портале», трудозатраты менеджера – 1 чд, архитектора – 5 чд, разработчика – 10 чд, аналитика – 1 чд, тестироващика – 3 чд. Из такой разбивки уже становится понятно, что на самом деле там не неделя работы разработчика, а целых две, так ещё и кроме разработчика 10 чд уходит на другие роли в проекте.

С демонстрацией трудозатрат Заказчику надо быть очень аккуратными. Такое всегда нужно согласовывать со своим руководством, потому что не всегда это применимо. И если вы на это пойдете, будьте готовы к тому, что Заказчик узнает ставки ваших специалистов, и будьте готовы к вопросам «а почему у вас разработчик стоит 50.000 рублей в день?».

4.  Продолжение предыдущего пункта – объясните Заказчику, что вы не просто продаёте какую-то фичу, вы продаёте консалтинг. Это значит, что вы собрали требования, оценили текущую ситуацию, продумали техническое решение, описали, согласовали, поставили задачу разработчику, проконтролировали выполнение, протестировали, показали и тд.

Обычно Заказчик не видит и не понимает все эти работы. Он всегда думает в парадигме «Да там разработчику на неделю работы, почему так дорого?»

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

6.  Предложите не фиксированную стоимость, а оплату по Time&Material. Это когда Заказчик платит не заранее согласованную стоимость за фиксированный объем (Fix Price), а платит по фактически потраченным трудозатратам по оговоренным ставкам. Работа по T&M выгодна исполнителю, так как снимает с него риски, что на какие-то работы будет потрачено трудозатрат больше, чем планировалось. А вот Заказчик наоборот, может потратить денег больше, чем по Fix Price, если какие-то работы пойдут не по плану. Да и генерировать замечания и хотелки Заказчику уже так просто не получится – за них придётся платить.

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

Более того, подсветите Заказчику, что привлечение другого Исполнителя – это огромное количество проблем: кто будет согласовывать техническую реализацию того, что новый исполнитель будет делать? Потребуется арх.надзор с вашей стороны, чтобы они не сломали то, что уже вами сделано? А кто будет за это платить? А кто будет отвечать, если что-то сломается? Всегда можно будет показать пальцем друг на друга и сказать, что это из-за них всё сломалось. А как одновременно несколько разработчиков из разной компании будут на одной среде вести разработку? А тестировать? В общем привлечение другого Исполнителя под какие-то атомарные задачи на вашем проекте – это всегда плохо, надо объяснить это Заказчику, если он рассматривает такой вариант.

8.  Оптом дешевле. Предложите сделать ещё какие-то работы. Да, общая стоимость работ вырастет, но цена конкретной доработки, которую вы обсуждаете, может быть снижена.

9.  Хватит тратить время на торги. Тоже скорее из серии манипуляций. Подсветите Заказчику, что чем больше времени вы тратите на торги, тем больше вы тратите на это трудозатрат, которые вообще-то должны быть оплачены (да, пресейл не бесплатный, но аккуратнее с донесением этой информации Заказчику, не все это адекватно могут воспринять). И ещё подсветите, что «время – деньги» и вместо того, чтобы уже выполнять эти работы, вы тратите время на обсуждение.

10.  Предложите скидку в следующих работах. Сейчас работаете по полной стоимости, но обещаете, что на будущие работы предложите скидку. Особенно хорошо сработает, если Заказчик давит на то, что он с вами нацелен на долгосрочное сотрудничество и обещает еще кучу проектов в будущем.

11.  Объясните Заказчику, что вы – коммерческая организация, и работать в минус вам невыгодно. Если вы сделаете скидку, то эти работы будут вам убыточны. Поэтому вам их проще вообще не делать, чем делать со скидкой.

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

Если договориться на полную стоимость не получилось, и скидку все-таки необходимо предоставить, то возможны следующие шаги:

13.  Предложите альтернативные варианты реализации. Часто бывает так, что решить одну задачу можно разными способами. Поэтому заранее продумайте, какие способы реализации есть, и, дайте Заказчику выбор. Может оказаться так, что Заказчик выберет самый «костыльный» вариант, лишь бы работало.

14.  Выкиньте «дорогие» требования. Часто бывает так, что какое-то требование очень сильно увеличивает сложность и стоимость работ. И может оказаться так, что Заказчику это требование не особо надо. Он может не понимать сложность этой работы, или озвучить требование, не до конца понимая, как оно будет работать и нужно ли оно вообще. Вы, как эксперты, должны понимать, какие работы можно выкинуть или изменить, чтобы это не повлияло на решение изначальной задачи, но позволило бы снизить стоимость.

15.  Предложите варианты с ограничениями. Если все 100% объема работ стоят 1000 руб, то предлагаем варианты: 1. 90% делаем за 900 руб, 2. 80% делаем за 800 руб, 3. 70% делаем за 700 руб и тд. Можно ещё объяснить заказчику, что доделать когда-то потом 10-20-30% будет стоить не 100-200-300 рублей, а как минимум 110-220-330 рублей, потому что сделать сразу дешевле.

Важно эти «выкинутые» 10-20-30% объема работ явно прописать в ограничениях, чтобы потом у Заказчика не было соблазна предъявить вам претензию, почему вы это не сделали.

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

16.  Разбейте задачу на несколько. Следствие предыдущего пункта. Но вы не просто часть работ переносите в ограничения, а сразу договариваетесь, что 70% работ делаете сейчас, а оставшиеся 30% работ оцениваете отдельно и закладываете в бюджет на следующий отчетный период. Тут для вас плюс в том, что, если вы понимаете, что с высокой долей вероятности, вы эти работы всё-таки будете делать, вы можете сразу при реализации 70% работ это учесть, чтобы потом было проще реализовать оставшиеся 30%.

17.  Обоснуйте Заказчику риски. Тут нужно быть очень аккуратными, потому что мы не можем сказать, что «мы здесь накинули 10%, потому что фиг его знает, сколько разработчик будет делать эту задачу – то ли 8 дней, то ли 12. А тут мы накинули 10%, потому что боимся, что вы выскажите кучу замечаний по результатам выполненных работ». Нужно найти те риски, которые можно озвучить Заказчику. Возможно, Заказчик часть из этих рисков сможет снять и тогда оценка будет меньше.

18.  Сделайте задачу «в лоб». Договоритесь с Заказчиком, что вы с ним согласовываете реализацию, делаете задачу так, как согласовали, и всё - не принимаете никакие замечания, не проводите ПСИ. Честно скажу, сами так ещё ни разу не пробовали. Но такой вариант применим, если Заказчик уверен, что требование однозначно трактуется, всем всё понятно и считает, что там нечего делать. Вы таким образом можете немного снизить стоимость, убрав заложенные риски на доработку по результатам демонстрации/ОПЭ. Пункт опасен тем, что Заказчик сможет потом переобуться и сказать, что это вообще не то, что он хотел, надо всё переделывать. И попробуйте доказать, что вы не закладывали доработку в стоимость.

19.  Сделайте скидку сейчас, но в будущие работы добавьте размер этой скидки. Пункт для нас менее комфортный, чем п. 10, но может быть применим для Заказчиков, с которыми есть история взаимоотношений и есть понимание, что будут ещё контракты в будущем.

20.  Попросите что-нибудь взамен. Если вы делаете скидку, пусть Заказчик упростит вам требование где-то в другом месте, в каком-то спорном вопросе примет вашу сторону или снимет какие-то ограничения. Это нормально, когда и вы уступаете, и Заказчик

Общие рекомендации:

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

22.  Можно попробовать передать вопрос обсуждения стоимости работ на уровень выше – вашему руководителю или сейлу. Если вы отвечаете за трудозатраты, которые необходимы для реализации, то ваша зона ответственности – обосновать Заказчику, почему это столько стоит с точки зрения запланированных ресурсов. А вот для обсуждения непосредственно стоимости этих трудозатрат и скидки можно позвать сейла. Но применимо это только если сейл сделает скидку не за счет ваших трудозатрат. Тут всё зависит от того, как у вас выглядит ценообразование.

23.  Если вы все-таки согласились уменьшить стоимость работ:

·  Имейте ввиду, что теперь Заказчик всегда будет просить скидку, так как будет знать, что из вас её можно «выбить».

·  Обязательно где-то зафиксируйте, что стоимость работ такая именно за счет того, что была предложена скидка (можно прям в КП это отобразить).

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

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

24.  Попробуйте узнать, почему Заказчик говорит, что дорого. Им кто-то пообещал дешевле? Или правда денег нет? Или у кого-то просто kpi на то, чтобы сбить цену от первоначального предложения Исполнителя (у нас были такие примеры). А может человек просто любит торговаться, такие тоже бывают. Если удастся получить такую информацию, вам будет легче подобрать аргументы.

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

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

Показать полностью

Соревнование самых быстрых

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

Туалетное делегирование: проблема и способы её решения

Туалетное делегирование: проблема и способы её решения Развитие, Карьера, Саморазвитие, Управление проектами, Делегирование, Длиннопост

Введение

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

Если вы хотите глубже понять, как эффективно управлять проектами и избегать подобных ситуаций, рекомендуем ознакомиться с каналом "Самоучки IT (Управление проектами)" https://t.me/+NfVrLMxdKS0yNDNi. Этот канал предлагает множество полезных советов и практик для улучшения рабочих процессов. Еще у канала есть два бота для тестирования знаний по фреймворк управления Scrum https://t.me/Antitrend_bot и своду знаний PMBOK https://t.me/ggsfgdg_bot

Что такое туалетное делегирование?

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

Причины возникновения туалетного делегирования:

  1. Нехватка времени

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

2. Плохое планирование

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

3. Неверие в важность формальных процедур

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

Негативные последствия туалетного делегирования

- Потеря информации

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

- Снижение мотивации

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

- Ухудшение отношений в команде

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

Как бороться с туалетным делегированием?

  1. Внедрение чётких процедур

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

2. Обучение менеджеров

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

3. Создание культуры обратной связи

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

4. Использование технологий

Современные технологии могут значительно облегчить процесс делегирования задач. Использование проектных систем управления, таких как Trello, Asana или Jira, позволяет фиксировать все задачи и сроки их выполнения в одном месте. Это обеспечивает прозрачность и контроль за выполнением поручений.

Заключение

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

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

А моя рекомендация посетить канал "Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi  для тех, кто хочет углубить свои знания в области управления проектами и узнать больше о том, как эффективно делегировать задачи. До встречи в следующей статье.

Показать полностью 1
Отличная работа, все прочитано!