Воронка продаж в проектах

 

Управление жалобами

[[https://spamanagement.su/manager/client-oriented/372-customer-complaints]]
Выяснение ситуации, понимание причин появления жалобы

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

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

Затем нужно определить обоснована ли претензия.

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

Если претензия обоснована – сформируйте ответ для клиента.

Основной алгоритм по работе с жалобами клиентов

Предлагаем работаем с жалобами клиентов следуя данному алгоритму:

принимаем претензию;
даем первичный ответ;
если его недостаточно для решения вопроса – регистрируем поступившее обращение;
выясняем ситуацию;
формируем ответ клиенту;
отвечаем на жалобу клиента;

формируем план корректирующих действий. 

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

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

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

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

Пример правил эскалации:

 Эскалация – это «подъем наверх» конфликта или проблемы, которые вы не можете разрешить самостоятельно в рамках своей роли или своих полномочий

Пример правил эскалации:

1 Попробовать договориться без эскалации.
2 Если не удалось – честно предупредить, что раз мы не договорились – я вынуждена эскалировать вопрос на такого-то менеджера, потому что интересы проекта и все такое. После этого чудесным образом в половине случаев договориться удается.
3 Продумать внятную аргументацию с позиции влияния поднимаемого вопроса на проект и на его результаты/сроки/бюджет и другие ограничения.
4 Включить в письмо (поставить в копию) или позвать на встречу с руководителем вторую сторону конфликта, чтобы решать вопрос совместно. В случае если вопрос критически важен для проекта – не забыть включить в процесс спонсора проекта, заранее согласовав с ним свою позицию.

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

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

Часто руководители проектов боятся самого слова «эскалация», почему-то считая, что в случае, если они вынесут проблему выше, они продемонстрируют свою некомпетентность,
неумение управлять командой и проч. А зря, пока вы не генеральный директор – 100% влияния и власти у вас все равно не будет (да и в случае с генеральным директором тоже),
а значит – ситуации, в которых понадобится эскалации, неизбежны. И лучше сделать это раньше, пока проекту не нанесен совсем уж большой урон.

 Стейкхолдеры (или заинтересованные лица) – это группы людей или отдельные люди, которых проект как-то затрагивает (как в хорошем, так и в плохом смысле) либо (и это важно, про это почему-то часто забывают!) те, кого проект не затрагивает, но они сами могут его «затронуть» или как-то на него повлиять, используя имеющиеся у них возможности.

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

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

Стекхолдеры

1. Идентифицировать стейкхолдеров
А именно – составить список всех людей или групп людей, являющихся стейкхолдерами вашего проекта.

На этом этапе вам понадобится информация о завершенных проектах и об окружении проекта (о компании и о том, как в ней принято работать), советы команды и спонсора и богатое воображение. Выписываем всех, кого можем вспомнить и кто с большой долей вероятности может как-то повлиять. Как пример – если вы точно знаете, что ваш микропроект генерального директора не заинтересует – не надо его сюда писать, как и Президента РФ или Ким Ир Сена.

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

Отношение конкретного стейкхолдера к проекту и его влияние можно оценить уже на этом этапе (после того, как список составлен) или на следующем.

Под влиянием подразумевается, что при 5 – человек может просто остановить проект и выкинуть его на помойку (если не повезет – вместе с PMом) или наоборот, росчерком пера заставить работать даже самых ярых противников проекта, а при 0 – может только грустно наблюдать за происходящим и ныть или радоваться переменам (но на проекте это никак не отразится).

Под отношением подразумевается текущая позиция человека относительно проекта: при -5 – он сделает все, чтобы проект не состоялся, или просто навредит при возможности (например, ему лично вы не нравитесь), при 0 – ему все равно (либо он вообще пока не знает про проект) и при +5 – готов изо всех сил помогать и поддерживать, ну или хотя бы радостно ждет результата. Если очень хочется – шкалу можно расширить до +/-10, но это сильно не поможет.

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

Agile

 Agile - итеративный подход к управлению проектами и разработке программного обеспечения*

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

Суть: вместо подразделений – круги. Они формируются под каждую задачу.
Порой стихийно: на корпоративном сайте размещают задачу и перечень специалистов, которые необходимы.
Люди сами заявляют себя в круг. Сотрудник может быть участником в нескольких командах, но только при условии, что он не загружен полностью на другом проекте.
Есть два уровня кругов. Первый – внешний, в который входят собственники и гендиректор.
Этот круг ставит задачи.
Второй уровень круга – внутренний. Это и есть команды, которые задачи решают.
Между двумя кругами есть еще менеджер-связной. Он доводит до кругов второго уровня задачи, которые ставит внешний круг.
Никакой многозадачности! Каждый круг решает только одну задачу.
Каждый участник команды, по сути, отчитывается перед коллегами.
!!

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

 

Когда нужен Scrum

для решения нетривиальных проблем - предназначен Scrum

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

В каких проектах нужен Скрам

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

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

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

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

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

Вся статья: [[https://scrumtrek.ru/blog/agile-scrum/5108/kto-takoi-scrum-master-i-zachem-on-nuzhen-komande/]]

Редактировать эту секцию

*Чтобы команда повышала свою эффективность (т.е. качество и/или скорость работы),
необходимо регулярно анализировать прошедшие спринты, выявлять проблемы,
избавляться от неудачных элементов рабочего процесса и, наоборот, закреплять хорошие практики.¶

Как правило, люди не привыкли тратить время даже на выявление проблем своей работы.
В команде людям трудно договориться между собой: что хорошо, что плохо и что не важно, какие препятствия стоит устранять
и какие лучшие практики стоит распространять на всю команду.
А еще труднее потом выполнять эти договоренности.
Это самые сложные моменты в работе Scrum-мастера, требующие длительного времени и большого опыта.

Scrumban

 

Методики управления проектами Scrumban

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

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

Scrumban — это мастерское соединение Kanban и Scrum в одну систему, но существуют некоторые отличия от предшественников:

Разработка внедряется легче, чем в случае со Scrum, и в этом отношении гибридный метод больше напоминает Kanban. В итоге адаптироваться к новой системе проще, а значит работа уже со старта будет более эффективной и понятной.
Постоянное совершенствование. Метод бесконечно развивается и улучшается. Этот процесс обеспечивается в основном за счет внедрения элементов Scrum.
Scrumban использует систематизацию более сложной методики Scrum и визуализацию более легкого в восприятии метода Kanban. Это позволяет командам получать объединенные преимущества двух популярных подходов в управлении IT-проектами.

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

h1. Методология управления проектами Scramban

Scrumban — современный метод–гибрид, использующий непрерывный рабочий процесс из Kanban вместе с полезными элементами Scrum, позволяющий решить проблемы обоих подходов
Как получить максимум?
Если вы заняты в сфере разработки и создаете продукт, оптимальным решением для вас будет использовать фреймворк Scrum, усиленный Kanban-методом. Например:

визуализацией всех этапов разработки от Discovery (когда происходит уточнение продуктовой ценности), до Delivery (когда происходит доведение выбранных задач до готовности)
визуализацией стратегических инициатив, крупных задач, которые будут двигаться по доске, а вы будете управлять ими
ограничением одновременно выполняемой работы на этапах
внедрением системы метрик времени выполнения

Немного о различиях Scrum и Канбан

Разница в смысле встреч и способе их проведения в методологиях Scram и Kanban
Каждая встреча Scrum нацелена на одно из двух:

или на координацию движения команды (ежедневные митинги, планирование, обзор спринта),
или на развитие командного взаимодействия, опыта или навыков Scrum-команды (ретроспектива).

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

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

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

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

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

Чтобы Scrum начал приносить пользу, нужно сделать многое, н-р:
Выделить Владельца продукта -специального представителя бизнеса;
Выделить на 100% всех необходимых специалистов в кросс-функциональную Scrum-команду;
Выделить Scrum-мастера, который будет заниматься развитием самоорганизации в Scrum-команде;
Сделать так, чтобы Scrum-команда могла поставлять результат короткими итерациями (1-4 недели);
Обучить основам работы по Scrum всех...

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

Все инструменты Kanban-метода можно применять при работе по Scrum:
сбор метрик, ограничение одновременно выполняемой работы (WIP-лимит), визуализация и тд.

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

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

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

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

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