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

9-10 июля открытый тренинг в Харькове

9-10 июля, Харьков! Единственный открытый тренинг «Аутсорсинг как сервис» этим летом!

Внимание. Тренинг в ХарьковеЧто такое тренинг «Аутсорсинг как сервис: фокус на Заказчике»? Это открытый тренинг, который ни одного участника не оставил равнодушным. Тренинг, который изменит ваш подход к Заказчикам и вы вместе от этого выиграете.

Подробно о программе тренинга можно прочитать в разделе «Тренинги». Остановимся лишь на основной идее тренинга: Думайте о Заказчике, решайте его проблемы, заботьтесь о нем и это принесет вам отличные дивиденды.  Для этого есть законы и практики, которые можно почерпнуть из множества областей сервиса, которые работают уже тысячи лет. Но уникальная особенность тренинга в том, что в нем удачно объединены как законы сервиса, так и АйТишные реалии работы с Заказчиками.

Запись, цены, скидки и убедительные аргументы далее…

May 31st, 2011

Управление ожиданиями 2: Виноваты сейлзы (?)

В первом посте (Управление ожиданиями на примере чая) я рассказывал о том, что такое управление ожиданиями и сделал акцент на том, что каждый из участников команды разработки отвечает за формирование ожиданий Заказчика.

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

Управление ожиданиямиГлавной причиной завышенных ожиданий служит служба продаж и маркетинга. Почитайте маркетинговые материалы вашей компании. Вы, с большой вероятностью, увидите слова о годах опыта, о десятках-сотнях выполненных и внедренных проектов, о integrity, reliability, agility (и прочих словах для bullshit bingo). Естественным образом Заказчик, увидев ваш опыт в нужной области (а сейлзы обязательно упомянули об этом), будет ожидать «старта с пол-оборота». Заказчик уверен, что вы его понимаете, знаете все тонкости данного бизнеса и будете выполнять его идеи быстро и без глупых вопросов. А как показывает практика, существует не так много компаний-разработчиков, которые быстро могут собрать команду экспертов в данной области.

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

Но, тут очевиден конфликт интересов:

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

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

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

«Обещай меньше, делай больше»

в англоязычном варианте

«Under promise and over deliver»

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

Классный пример именно такого подхода пессимистов в сфере близкой к АйТи (интернет магазин) я прочитал в книге Тони Шей «Доставляя счастье». Пример построен на том, что они постоянно обещали доставить товар за 2-3 дня, но в 90% случаев доставляли за 1. Много раз у ни был соблазн сократить «официальное» время доставки до 1,5 дней и поставить это конкурентным преимуществом, но(!) 5% доставок не делались за 1,5 дня… Поэтому обещания в 2-3 дня так и остались официальным сроком поставки. Но 95% случаев превышали ожидания покупателей, чем заработали очень хорошую репутацию.

Если вы знаете другие правила для управления ожиданиями – непременно комментируйте…

May 30th, 2011

Управление доверием в виртуальных командах

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

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

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

В общем, рекомендую к прочтению статью  Алексея Корецкого.

 

May 24th, 2011

Пятничный Заказчик

Пятничная байка про стандартного Заказчика…

История из чата:

Andrey:

про управление требованиями… навеяло что-то..
anotherpm: :)
Andrey: сначала 2 часа конференс кол, в течение которого мне выкручивали руки заставляя взять на себя обязательно сшить не меньше 3 шапок а потом пришел девелопер и выяснилось что он сделал то что я хотел, но только это использовать нельзя :)

 

May 19th, 2011

«Должностная инструкция Product Owner-а»

Собираю список того, что должен/не_должен делать хороший Product Owner в команде. Какие действия PO были эффективными, а какие деструктивными. Практика приветствуется:)

>>>Вступление и описание проблемы

Должностная инструкция Product Owner-аВ очередной раз натолкнулся на то, что маркетинговая машина SCRUM (наиболее успешный sales в мире agile) захватывает «неокрепшие умы» и все хотят побыстрее приобщиться к этой успешной и модной практике.

Но SCRUM – это не только ежедневные stand-up-ы и «стикеры на доске», хотя с виду это кажется именно так :).  Поэтому в реальной жизни многие команды и Заказчики сталкиваются с проблемой. И из этой проблемы есть 2 выхода: или сказать, что agile – это красивая обертка за которой ничего нет, или почитать литературу (а потом нанять консультанта :)).

Литература говорит, что agile – образ мышления (тот самый mindset), который определяет поступки для каждой роли. Вот только плохо получается объяснить Заказчику, что ему нужно менять свой mindset. Самым добрым вариантом ответа может стать фраза «…давайте я буду бизнес делать, у меня на него mindset настроен…», а недобрый вариант может начинаться с «… не учите батьку… ваше дело кодить».

Да и вообще менять mindset взрослого человека – дело хлопотное и дорогое. Поэтому лучше просто сказать, что конкретно нужно делать или чего избегать, чтобы роль Product Owner-а была максимально эффективной в команде. А если перевести это в цифры и деньги, то такой список будет явно выигрывать у идеи «просто поменяйте образ мышления».

>>> Собираю идеи

Очень хочется, чтобы активные участники блогов и аджайлисты ответили на 2 простых вопроса:

1. Что нужно делать Product Owner-у, чтобы команда была максимально эффективной и ощущала себя командой?

2. Какие действия PO приводят к тому, что эффективность и сплоченность команды падает?

По мере поступления ответов буду обновлять пост и составлять некую «Должностную инструкцию Product Owner-а»: что нужно и не нужно делать (what to do and not do).

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

Немножко о формате:  Важно отметить, что полезным будут практические советы. Ответ «нужно чтобы Product Owner любил команду» будет абсолютно правильным в сакральном смысле, но не очень полезным в практическом. Вы же не придете к РО с запросом: «Пожалуйста, ознакомься… пункт 5 говорит о том, что нас надо любить. Будь добр, начинаем со следующего спринта». :)

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

Даже одна идея от каждого посетителя – уже большой вклад в общее дело :) Не стесняйтесь, пишите идеи.

P.S. Лучше сразу залогиниться на сайт (в правом верхнем углу), а потом писать коммент. Прикручена регистрация со всех соц.сетей, так что это 1 клик :).

 

May 18th, 2011

Интересные события в мае

19-20 Мая, Минск.  SEF.BY – самая большая ИТ конференция Белоруссии. Я там буду выступать 20 мая.

20-22 Мая, Москва. Тренинг «Профессиональная работа с людьми» от Орлова и Панкратова (С).

26 Мая, Киев. Встреча “Cool IT”: «Как создать образ лидера? Для тех, кто уже руководитель и для тех, кто только планирует руководителем стать»

28 Мая, Киев.  Тренинг «Техники неформального лидерства. Тюнингуем лидерскую харизму». Харьковские коллеги приедут жечь! Есть скидки от блога anotherpm.com

 

Детальное описание событий дальше…

 

Software Engineering Forum Belarus – 2011

Для меня центральным в конце мая событием станет выступление на конференции SEF.BY.

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

Во-вторых, оргазнизаторы постарались сделать все на высшем уровне, о чем рассказал председатель Совета директоров компании EPAM Systems Аркадий Добкин.

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

Добро пожаловать в Минск на SEF.BY…

May 12th, 2011

Управление ожиданиями на примере чая

Управление ожиданиями на примере чая

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

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

Пример 1. Завышенные обещания, которые не были выполнены.

Представьте себе ситуацию, что ваш босс рассылает на всех следующее письмо:

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

Вы немного удивлены, раньше-то было 2 сорта, да и то с перебоями, а теперь целых 18! Но это очень приятно, и вы уже начинаете прикидывать как бы все это попробовать за пару дней, а может даже начали читать форумы о тонкостях заварки «белого чая с западного склона горы АБВ…».

На следующий день, придя в «чайную точку» вы обнаружили только 9 сортов чая. Естественно, вы будете расстроены. Во-первых, обещание нарушили в 2 раза (9 вместо 18)! Во-вторых, нет вашего любимого белого чая с того самого склона. В итоге вы очень разочарованы этим фактом и начинаете критически воспринимать происходящее: «А босс наверное пьет все 18…», «Ага, очень похоже на ситуацию с новогодней премией…», «да, всегда так, навешают лапши, а сделать нормально не могут..».

Пример 2. Завышенные обещания, которые не были выполнены.

Ситуация письмом босса с чаем повторяется с одним изменением: Босс говорит, что видов чая будет 6, что в 3 раза больше, чем есть сейчас!

На следующий день, придя на работу вы обнаруживаете те же 9 сортов чая. Как ни странно, вы будете приятно удивлены и позитивно воспринимать происходящее: «О, так это даже лучше, чем обещали!», «А ты пробовал вот этот сорт?… Он хорош!».

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

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

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

Продолжение следует…

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

P.S. Круче всего управление ожиданиями поставлено у суровых сибирских мужиков… Но вынесу я анекдот лучше в твиттер :)

May 10th, 2011

Обновилось описание тренинга

Свершилось!

За пару выходных дней я наконец-то добрался и основательно доработал описание тренинга “Аутсорсинг как сервис”. Выставляю на суд читателей:

Новая программа и описание тренинга “Аутсорсинг как сервис”

 

P.S. Большое спасибо “Клубу тренеров” от проекта Stratoplan.ru, которые помогли с идеями :)

 

May 7th, 2011

Точка зрения: Заказчик и Исполнитель

Недавно прислали очень интересную презентацию, которую сделали совместно сотрудники компании ЕРАМ и Citi-Банка. Презентация описывает интересный подход к тому, как выглядят различные модели взаимодействия Заказчик-Аутсорсер и какие плюсы и минусы есть в каждой модели. Хоть презентация и верхнеуровневая, но зато очень откровенная в плане «скрытых» мотивов как аутсорсера, так и Заказчика при каждом типе проектов.

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

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

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

Apr 28th, 2011

Работа с командой Заказчика: Видео с Software People

Наконец-то это свершилось и организаторы конференции выложили мое выступление на конференции SWP11.

Пока еще не могу побороть «удобность» хостера видео, так что смотрите по этому линку (в новом окне)!

А так как на видео не видно слайдов, то отдельно выкладываю и презентацию:

И кто скажет, что на 9 слайде маугли НЕ похож на Асхата? :)

Кроме видео я еще решил с большим опозданием написать свой отзыв о конференции.

Apr 26th, 2011
Page 12 of 22« First...1011121314...20...Last »