Тренинги Сергея Бережного Консультации Сергея Бережного Бесплатные материалы

Реакция на жалобы Клиентов

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

Я хочу рассказать об оценках, которые мы получаем от Заказчика и о том, как быть с ними.

Когда оценки-отзывы хорошие, то все радуются и думают, что так будет всегда :). Хотя оптимизм в отношениях с Заказчиком – плохой советчик.

Вот случилась «неожиданность» и Клиент пожаловался на вас: «Вот вроде бы все хорошо, только вот тут плохо, да тут тоже, а здесь вообще провал». Проблема свойственна любым отношениям или как говорил Малыш: «Дело-то житейское!», и вроде понятно, что ты получил обратную связь, которую нужно адресовать. Дальше все просто: нужно спокойно работать над ошибками. Но тут есть одно «НО»… появляются менеджеры, которые хотят «помочь» в решении проблемы. И помощь эта может обернуться медвежьей услугой для команды.

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

Подход №1: Получил жалобу – Вызвал ответственного (первый, который попался) – Выдал ему «на орехи» – Написал клиенту, что проблема решена – Чувствуешь себя счастливым («порешал» проблемы)

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

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

Подход №2: Получил жалобу – Нашел человека, который сделал ошибку – Попросил его сделать анализ причин – На основании причин (а не проявлений) попросил сделать план действий – Написал Клиенту о плане – Проконтролировал план действий

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

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

Подход №3: Получил жалобу – Самостоятельно выяснил с Клиентом причину – Собрал команду и с ними сделали анализ причин – Разработали план действий по нейтрализации причин – Согласовали план с Заказчиком (верит ли он, что это поможет) – Проконтролировал исполнение плана – Поговорил с Клиентом о том, все ли проблемы решены в достаточной мере (получил обратную связь).

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

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

Как улучшить вариант №3?

Есть такое мнение великого ученого:

«Невозможно решить проблему, находясь на том же уровне сознания, на котором мы ее создали»,

с которым сложно спорить. Теперь контрольный вопрос менеджерам:

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

Ответ как нельзя проще. Руководитель (или менеджер) как раз находится за рамками этой системы и может помочь посмотреть на проблему «извне». Но менеджеры по-старинке предпочитают «дать задачу» и «контролировать ее выполнение». Поэтому и результаты получаются далеко не впечатляющими.

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

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

  • Находить реальные причины проблем
  • Вовлекать Заказчика на всех стадиях работы над жалобой
  • Оторвать «пятую точку» от стула и помочь команде выйти за рамки системы (вырвать из контекста).

P.S. А какой метод работает у вас? Как ваш руководитель или вы сами подходите к жалобам Заказчика на вашу команду?

P.S. Написал пост и подумал, что в программе рассылки «Базовый курс по работе с Заказчиком в ИТ» нет ни одного пункта о сборе обратной связи. Это упущение, которое собираюсь исправить, так что подписывайтесь, если этого еще не сделали!

Oct 4th, 2011

Вебинар: Разница в психологии между нашими разработчиками и американскими заказчиками

В понедельник 26 сентября Владимир Железняк (со-автор блога it-boost.com) проведет вебинар о разнице в психологии работы с американскими Заказчиками. Интересный вебинар с человеком, который знает о работе с американскими Заказчиками очень многое.

Светлана Костикова:
Умнейший человек с очень интересным опытом и карьерой. 15 лет назад переехала в США. MBA, училась в Стэнфорде. О рабочих достижениях – в частности, открывала новый офис Adobe на 200 человек.

Краткий список вопросов веибинара:

  • восприятие русских аутсорсеров американскими business-people:
      • русскоязычные разработчики часто воспринимают американского заказчика как «давай-давай быстрее, качество не надо». Есть ли какие-то стереотипы от заказчика о русских аутсорсерах?
      • как воспринимаются наши технические и коммуникационные скилы?
      • как американцы воспринимают наш английский? Он режет слух? Они гордятся, что говорят на общемировом языке, а мы его учим? Они воспринимают нас, как ограниченных людей или детей?
  • наши стесняются торговаться: зарплата, сроки и тд. Насколько это принято в США?
  • есть ли разница в отношении к устным и письменным обещаниям между этими двумя категориями?
  • работа по выходным и ночам, насколько и для кого это естественно?
  • вопрос, который очень «под запретом» в нашем обществе. Это вопрос о совмещении для женщины роль успешного бизнесмена и успешной матери.
  • роль консультантов в американском бизнесе

Регистрация на Go2Webinar доступна уже сейчас, количество мест ограничено!

Sep 24th, 2011

Бесплатный продукт “Инструменты развития карьеры”

stratoplanМои коллеги Саша и Слава (TM) снова делятся хорошими и полезными иснтрументами абсолютно бесплатно. 1,5 часа видео о карьере с насущными вопросами о следующем:

1. Почему в 90% случаев в компаниях карьерный рост невозможен независимо от прилагаемых сотрудником усилий?
2. Почему многие из нас не растут или растут совсем медленно, хотя постоянно меняют работы, изучают что-то новое и уверены, что заслуживают лучших проектов и работодателей?
3. Какие существуют стратегии карьерного продвижения и что надо делать, чтобы расти постоянно и не навредить себе?
4. Почему простая смена компании не помогает карьере?
5. Что выгоднее: расти в рамках одной компании или время от времени менять работу?

Знаете, я когда прочитал вопросы, то сразу записался. Я бы себе не простил, если бы все это не посмотрел. Карьера – это то, что многие планируют на годы, а если за полтора часа я получу знаний, которые ускорят карьеру хотя бы на 10%, то выиграю месяцы-годы! Неплохая инвестиция, так как ROI просто зашкаливает :)

Подписывайтесь прямо сейчас!!!

Ваш e-mail: *
Ваше имя: *

 

Sep 23rd, 2011

Управление ожиданиями: точка зрения Эксперта

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

Но совсем недавно наткнулся на серию постов от Михаила Завилейского (Директора DataArt) на эту тему. Михаил – очень приятный собеседник, мудрый менеджер и просто очень хороший человек, который всегда радует интересными мыслями и идеями.

Я не удержался и повторю этот контент полностью тут. Каждому человеку, который работает с другими людьми (а особенно с менеджерами и Заказчиками) этот материал будет полезен (Attention: Многа хороших букоф!).

5 способов управления ожиданиями (by Михаил Завилейский)

Sep 21st, 2011

MyStory: Недостижимое отставание

The Ultimate inspiration is the Deadline

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

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

Заказчик ключевой, поэтому крайне важен для подрядчика. Подрядчик реализует проект по разработке и внедрению очень сложного (логически) внутреннего ПО. Проект – fixed price, но (повторюсь) сложный, не типичный, длительный. В силу определенного ряда обстоятельств проект продан очень дешево (как для такой разработки).

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

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

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

 За две недели заказчик систему не протестировал, ссылаясь на то, что система сырая, постоянно возникают проблемы, не позволяющие систему тестировать. Тестирование не закончилось и в течении 2.5 месяцев – команда у подрядчика не расформирована (я писал выше, что заказчик очень важен для подрядчика), заказчик ссылается на гарантийное письмо с обязательством подрядчика устранить дефекты, найденные заказчиком (срок, указанный в этом письме, игнорируется). Работы подрядчика не оплачиваются, т.к. контракт на поддержку можно заключить только когда система будет запущена в эксплуатацию. Дата такого запуска постоянно переносится заказчиком (опять же по словам заказчика из-за того, что в системе еще находятся дефекты). Т.к. система долго не запускалась за это время бизнес поменялся, и уже возникли дополнительные задачи, без реализации которых систему запустить нельзя (а эти доп. фичи также нужно будет тестировать).

 Какие будут рекомендации? :)

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

Комментируйте и Пишите о своих кейсах! Наш опыт помогает другим. В этом можно убедиться, просмотрев уже разобранные кейсы на сайте anotherpm.com.

Sep 19th, 2011

Как сообщить Заказчику, что кто-то уходит из команды?

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

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

Варианты читателей: Что делать, если уходит кто-то из команды и об этом нужно сообщить Заказчику:

—–======= История №1 (by Андрей Радосельский) =======—–

Я год вел проект по внедрению процессов и системы на заводе (ИТ имела 250 человек, включая собственных разработчиков). Проект шел тяжело, но шел. И предполагалось, что будет идти еще года 2-а и ко мне принципиальных претензий не было.

В связи с своим переездом я сменил работу. У меня и нового ПМа стояла задача сообщить об моем уходе команде Заказчика.

При этом все хотели решить разные задачи:

  • Я – уйти так, что бы это не выглядело у Заказчика, что я сбежал от трудностей
  • Новый ПМ – заручится их поддержкой, так как с он с этим Заказчика никогда не работал
  • Менеджер Заказчика – показать, что меня не увольняют за “трудности” или просчеты

Что мы сделали:

  • Созвали внеочередной координационный комитет проекта
  • Явились туда все втроем
  • Я открыл комитет, и сообщил о своем решении (ухожу, передаю дела 3-и недели, эти этапы заканчиваю я, эти уже новый ПМ)
  • Представил нового ПМа и его регалии
  • Поблагодарил за интересную работу
  • Передал слово Менеджеру
  • Менеджер рассказал что “вот такие дела, ко мне претензий у компании нет” и передал слово новому ПМу
  • новый ПМ представил сам себя и …
  • Пошла сессия вопросов и ответов

—–======= История №2 =======—–

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

    1. Во-первых, заказчик видит что вы работаете с командой,
    2. Во вторых это еще одна возможность объяснить заказчику кто эти люди и что они делают, особенно когда людей много и менеджер заказчика хорошо знает только 3-4 самых центральных игроков. 
    3. В третьих можно вместе с заказчиком готовить какие-то превентивные шаги (рейты повышать, новые позиции вводить, придумывать какие-то персональные плюшки). Превентивные шаги лучше тем что их можно делать неспешно и получается дешевле чем попытка остановить человека на выходе. Конечно сильно зависит от отношений с заказчиком.
    4. В-четвертых, в случае если человек все-таки пришел за повышением или собрался уходить, то вы при обсуждении с заказчиком можете сослаться на результаты вашей квартальной беседы и это может помочь выбить нужное повышение. И для заказчика это уже не будет такой большой неожиданностью.
    5. Ну и в-пятых, это стимулирует тебя самого регулярно пересматривать список сотрудников и продумывать возможные риски/сценарии развития событий и готовиться к ним

—–======= История №3 (метод «от обратного») =======—–

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

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

Каждая история – отличный пример, проверенный на личном опыте. И с точки зрения отношений с Заказчиком каждый из примеров служит хорошим пособием о достижениях (примеры 1 и 2) и об ошибках (пример 3).

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

Aug 31st, 2011

Анонс ближайших событий: Немного психологии в АйТи

Коллеги-блогеры из IT-Boost проводят пару интересных событий в ближайшее время.

3 сентября –  вебинар ”офисное пространство”.

Бесплатный вебинар по следам зажигательного выступления на IT Jam «Офисное пространство: секс и насилие» – 600+ зрителей, многократные аплодисменты и смех, 400 секунд на выступление.

Во время вебинара обещают ответить на такие вопросы:

  • +15 к пониманию конфликтов в команде
  • Кто сталкивается с проблемами с личным пространством, а кто – нет?
  • Как люди показывают свой размер и значимость? Как это делается без iPad?
  • Расположение столов «лицом» или «спиной», OpenSpace и т.д. с точки зрения психологии.
  • Кто, к кому и как обычно подходит? Практические выводы для осознанного управления конфликтами.
  • Ваши вопросы

Думаю, что стоит зарегистрироваться и пойти!

5-12-19 сентября Серия из 3.5 вебинаров: Меняем работу правильно

От автора:

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

Сейчас я решил поделиться накопленным опытом. Для этого я объединился с Викой Придатко – наверно, самый известный HR в IT. Вика даст взгляд на ситуацию с точки зрения HR. Кроме того, Дима Снисарь знает массу всего о том, как работать со страхом и с невербаликой на собеседованиях. Это верные +20% к вероятности прохождения.

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

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

Если хотите выгодно менять работу, то записывайтесь на серию вебинаров!

Aug 29th, 2011

Советы Заказчику: Разделяемая Задача

English  Русский 

Разделенная команда

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

Я неоднократно рассказывал о том, какие проблемы есть при общении команды со стороны Заказчика и удаленной командой разработки. Рассматриваю некоторые типичные проблемы на примере реальных кейсов, выступаю на конференциях (видео с Software People  11). И если в своих выступлениях делал акцент на действиях команды-исполнителя, то сейчас хочу остановиться на том, что может сделать Заказчик или менеджер для лучшего взаимодействия команд.

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

Но в этой практике (как и в любой другой) есть и свои большие недостатки.

Вся команда не проходит стадии Forming – Storming – Norming – Performing

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

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

Потенциал команд будет не полностью раскрыт

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

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

Усиливается обособленность команд

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

Команды знают только одну часть проекта

Если одна команда хорошо делает какую-то часть проекта, то со временем уже даже не возникнет мысль о передаче части этой работы кому-то из другой команды. Это будет просто неэффективно. В итоге каждая команда будет знать только «свои части системы». И если необходимо будет резко увеличить усилия в той или иной области (например, под давлением внешних факторов), то другая команда не сможет в этом помочь.  Несмотря на то, что работают над одним проектом, они просто не будут знать того, как устроена другая часть системы.

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

Когда стоит делать упор на специализацию?

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

Как сохранить специализацию команд и при этом не добавить рисков?

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

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

В этом разделе можно прочитать еще несколько интересных “Советов Заказчику”

Aug 28th, 2011

Lean с передовой

Один из лидеров Agile разработки Henrik Kniberg написал еще одну очень полезную книгу. В этот раз о Kanban.

Я уже рекомендовал одну из предыдущих книг Хенрика  «Скрам и Канбан: Выжимаем Максимум», которую даже успели перевести на русский.

Новая книга «Lean from the Trenches. An example of Kanban in a large software project» еще находится в версии 0.7, но, тем не менее, уже интересна и полезна. Я прочитал ее просто на одном дыхании. Книга о настоящем большом проекте с полным использованием Kanban и с описанием всех практик, которые применялись.

Записываем книгу в To-Read-list  на выходные.. :)

Aug 12th, 2011

Мое интервью для подкаста “Откровенно про IT карьеризм”

Сегодня с удивлением обнаружил свою фотку на главной странице Developers.org.ua и потом только вспомнил, что это благодаря подкастам “Откровенно про IT карьеризм”.

45 минут наполненных простыми и провокационными вопросами от Миши и Ольги:

 

Кстати, в конце подкаста можно послушать о том, как получить скидки на мои тренинги.

 

Aug 8th, 2011
Page 9 of 22« First...7891011...20...Last »