Outsourcing as a service

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

• Более серьезный. Жизненный цикл компании по Адизесу.
• Менее серьезный. 12 типов Заказчиков (о которой уже писал)

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

Какой из шаблонов выбираете?

Типизации Заказчиков сейчас похожи на беспорядок, который творится в биологии и ботанике, когда цветы объединяют в семейства по форме цветка (крестоцветные), а животные в отряды по копытам (парнокопытные). Благодаря такой классификации, лошадь и корова, вроде как немного похожие животные, в классификации отстоят друг от друга на таком же расстоянии, как корова и бурундук Но такой хаос в соседних науках нас не останавливает. Мы настойчиво пытаемся найти классификацию Заказчиков, забывая, что они тоже люди. А ни одной универсальной системы классификации людей так и не придумали. Пока…

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

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

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

1. Определяем тип конкретного Заказчика
2. Переключаем свое поведение на нужный шаблон.

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

А еще наша мечта в том, чтобы эти шаблоны переносить за собой из проекта в проект. Вот работал у меня один шаблон в проекте АВС, так если Заказчик «похож», то и в проекте ХАВ тоже будет работать. Опять простота и счастье!

И это счастье несбыточно и я попробую это доказать.

Вообще идея статьи родилась, когда я натолкнулся на пост коллеги @pimenaus, где он разбирал «Смертельную болезнь №4» по Демингу:

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

И вдруг, я понял, что это же о шаблонах! Почему управляющий приносит шаблоны из прошлого места? Да потому что новый подход требует больших вложений. Нужно разобраться во всех сложностях нового проекта. А тут ничего не нужно делать… ты там выиграл за счет M&A, или за счет использования дешевых ресурсов, то и тут это будет работать.

Главное, что Айтишники наступают на эти грабли с завидной регулярностью. Сколько раз я видел, как нанимали HR директоров с не-айти предприятий. Тот приходил и говорил, что мы перейдем на массовые дешевые ресурсы, так как на прошлой работе это принесло результаты. По странной случайности, такая стратегия приводила либо к увольнению… директора, либо к смене стратегии.

Но вернемся к нашим Заказчикам и их типизации.

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

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

1. Психотип Заказчика (конкретного человека)
2. Опыт Заказчика (конкретного человека), который подкорректировал некоторые шаблоны, заложенные в психотип.
3. Цели Заказчика
4. Культура организации Заказчика
5. Ваш психотип
6. Ваш опыт
7. Ваши цели
8. Культура вашей организации
9. Культурные особенности
10. … и наверное еще с десяток пунктов

В целом, описанные выше факторы личного взаимодействия имеют больший вес, чем тип Заказчика и шаблоны его поведения. Не занимайтесь ерундой по поводу типизации. Изучайте конкретного Заказчика (как и конкретную ситуацию) и вкладывайте усилия в развитие отношений. Только так можно использовать шаблоны. Хотя зачем они тогда, если каждый Заказчик для нас уникален?

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

Я тут общался со многими коллегами по поводу паттернов поведения и решения проблем, когда мы не можем убедить  Заказчика в необходимости Agile и т.д. Причина проста – на сайте есть кейс об «анти-аджайл заказчике», который нужно решать.

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

1. Долбить сильнее и чаще. То есть набрать фактов для решения конкретных проблем в других командах и еще раз (а может и не один) рассказать это Заказчику. Пока он не сдастся под нашим напором.
2. Долбить качественнее. Использовать разнообразные техники продаж (СПИН) и манипуляций, чтобы его убедить Заказчика.

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

Да не будет работать такой подход! Заказчик, судя по описанию и кейсу, очень толковый и работает на уровне логики, чем на уровне эмоций. И все манипуляции и ведение переговоров разобьются о вопросы «А зачем?». Так сказать «Trololo mode on»

Как решать кейс?

Как ни удивительно, но здесь пока виден один выход. Раз Заказчик требует логических обоснований и хочет понимать глубинный уровень, то нужно копать в сторону понимания Agile процессов. И не просто копать, а уходить на уровень «Ха» (по модели Сю-Ха-Ри).

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

Вот несколько шагов к решению.

• Читать книги по agile-процессам и их подходам и пытаться там найти закономерности и базовые правила (Agile Manifesto не предлагать по причине размытости). Но так как книги чаще всего написаны в директивном или описательном стиле, то понять «почему» это работает – не так просто. Мое личное мнение: Большинство книг по Agile написано в виде описания успешных историй. Мотив такой: нам было плохо, потом подумали и решили взять аджайл и стало хорошо.
• Нанять эксперта в этой области. Он принесет свой опыт и понимание особенностей процессов. Не факт, что он сам будет понимать КАК это работает, но у него есть свой опыт и набитые шишки.
• Само-коучинг. Задавать команде вопрос: «А почему у нас это заработает?» и «Что будет нас мотивировать сегодня-завтра-через месяц?». Это подготовит к вопросам Заказчика и даст возможность «подтянуть» себя.

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

Знаете решение лучше? Комменты работают…

В этот раз решил начать описание сложного кейса с истории из детства:

В детстве я очень не любил ответ «Потому что так нужно!». Это так удивительно, когда ты пытаешься выяснить причины поступков или подходов, а в ответ сталкиваешься с тем, что другие люди или не знают почему это так или не хотят тебе отвечать. Вот так меня и мучал вопрос: «Почему нельзя ставить что-то горячее в холодильник? Горячее нужно охладить, а холодильник предназначен для этого!» или «Зачем в футболе офф-сайд? Ведь так же голов меньше!». Смириться с ответом «Потому что такие правила» я не смог и начинал читать-копать-выяснять-додумывать. И это приносило результаты и удовольствие от открытий, хотя иногда меня не любили за такие вопросы

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

А теперь сам сложный кейс:

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

Команда описала преимущества перехода на скрам и все «плюшки», которые получат. Но тут Заказчик проявил себя в полной мере… Все началось с невинного вопроса: «А почему Скрам работает?». И тут оказалось, что кроме маркетинга и стандартных фраз из курса CSM о коротких итерациях и счастливых Заказчиках, у команды нет объяснений. Дальше Заказчик развил тему и начал спрашивать «А зачем ретроспектива? И зачем делать такой долгий планнинг ? и т.д.». Шквал вопросов, атакующих правила, выбили команду из колеи, ведь простых ответов на них нет.  А как только Заказчик понял, что команда не понимает сути процесса, то сразу перешел в режим отрицания. Дальше Заказчик сам себя накрутил тем, что «додумал» факты о том, что команда хотела проводить «процессные эксперименты за его деньги». И я его понимаю!

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

Почему-то я подумал, что эта команда не одинока. В нашем мире мы часто просто опираемся на правила и не задумываемся о том, что стоит за ними. Мы предлагаем Заказчику внедрить TDD и авто-тесты или приходим к начальству с новой идеей обучения и т.д. А вот на вопрос «ПОЧЕМУ это работает?» у нас ответа нет

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

UPD: Добавил разбор ситуации.

P.S. Хотя можно ли такого Заказчика назвать “анти-Agile”?

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

Обожаю увлекательные конференции

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

Мы (Сергей Бережной и Макс Вишневецкий) объявляем набор в новую закрытую и неформатную тусовку киевских менеджеров ИТ проектов == pmclub.org.ua. Никакого булшита о «теориях». Наш конек в новом формате: вы присылаете свои реальные кейсы и в начале встречи голосованием выбираем 1-2 для разбора. А ведущий (или эксперт, который будет приглашенным гостем) на реальных проблемах показывает свои знания и доказывает, что он эксперт. Никаких подстав или подготовленных сценариев. Если назвался экспертом – будь готов решать ЛЮБУЮ задачу из зала. Участники встречи будут активно вовлечены.

Да, действует отбор участников! У нас будет небольшая группа и мы будем фильтровать, чтобы на встречу не попали те, кто не может внести пользы. То есть если вы не ПМ, то вам нужно доказать, что вы нужны на этой встрече. Ожидаемый лимит группы – 30-40 человек.

Регистрация стоит 100грн. При этом мы сразу говорим о том, что все деньги (кроме прямых затрат на кофе-пиццу) пойдут на благотворительность. Это абсолютно не коммерческий проект!

Первая встреча уже 14 ноября в 19:00. Я попытаюсь быть первым экспертом и будем разбирать кейсы по работе с Заказчиком. Регистрируйтесь и присылайте свои кейсы.

Записывайтесь на сайте сообщества, будет интересно и необычно! Такой необычный формат стоит того, чтобы попробовать! 

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

30 октября, Харьков – обучающий курс «Школа IT продаж»

1-2 Ноября, Москва – Международная конференция SECR 2012

10 ноября, Харьков – NETwork Conference 2012

11 ноября, Харьков – мой открытый тренинг «Делегирование в стиле Agile»

14 ноября, Киев – первая встреча клуба ПМов Киева (тсс, секретно)

16-17 ноября, Минск – Конференция руководителей проектов SPM conf

30 ноября – 1 декабря, Минск  - Крупнейшая конференция по тестированию ПО SQA Days 12

Неплохо, да? А теперь поподробнее…

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

DONE! 11-го ноября в Харькове будем разбирать проблемы Делегирования в стиле Agile

 8-го декабря в Киеве буду рассказывать о проблемах Работы со сложными Заказчиками

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

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

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

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

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

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

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

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

Ну вот я и решил… и до сих пор обхожу эту практику мимо. Да и не собираюсь нарушать данный курс.

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

Группа тренинга уже сформирована и осталось 4 свободных места! То есть 13-14 октября в офисе компании Paralles встречаемся, для того, чтобы разобраться в вопросе «как работать с Заказчиком»!

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

Подарки

Подарок №1 – “after-party” вебинар вопросов-ответов. Разбор сложностей и ситуаций по результатам тренинга. Вебинар будем через 3 недели после проведения тренинга. Да, в тренинге есть много домашнего задания, а выполнить его не так просто. И я сделаю вебинар по ответам на вопросы. По отзывам участников такие вебинары дают не меньше пользы, чем половина тренинга! Конечно, ведь они уже нацелены на то, что вы попробовали и будете делать.

Подарок №2 – Приглашение на бонусные вебинары осеннего клуба по работе с Заказчиком. В этом клубе будет много интересного и уже намечены несколько бонусных вебинаров:

• Финансовая мотивация Заказчика (я уже делал резонансный анонс)
• «Как сложно быть Product Owner-ом» – вебинар от бывшего разработчика, который ушел в РО.
• «О работе с Заказчиками в продуктовой компании»
• «Удаленная поддержка Заказчиков»
• И т.д.

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

Несколько постов назад я начал рассказывать о том, стоит ли навязывать Заказчику свой процесс. Если кратко – стоит, несмотря на то, что у Заказчика есть множество причин для отказа (читайте первую часть).

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

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

Давайте просуммируем причины отказов от перехода на новый (может даже улучшенный) процесс, опираясь на аргументы из первого поста серии:

1. Недостаточно авторитета
2. Изменения нельзя или очень сложно изолировать от других процессов
3. Боязнь выбрать «не то» и потерять существующие выгоды
4. Банально нет времени на реализацию изменений

Добавляем список причин из опыта работы (не описаны раньше):

1. Нет заинтересованности в изменениях (Сидим на попе ровно (С) ). Ситуация похожа на состояние «Да чего мне тут что-то менять, мне через год на пенсию»
2. Политическая обстановка внутри компании Заказчика сейчас не позволяет ухудшить ситуацию даже кратковременно
3. Есть недавний негативный опыт и он «еще болит»
4. …

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

1.       Позитивная большая «плюшка» в случае успеха

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

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

Ключевые вопросы, на которые вы должны ответить:

• Как это изменение поможет бизнесу Заказчика? И я всегда делаю акцент на слове «бизнес».
• Достаточно ли большие выгоды, для того, чтобы Заказчик начал что-то делать? Значима ли сумма экономии или новых доходов? Можно посчитать % от бюджета проекта.
• На что кроме финансов могут повлиять данные изменения?

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

Note: Кстати, одной из плюшек могут быть не деньги, а опыт или авторитет. Например, предложение о том, что мы с тобой, дорогой Заказчик, сделаем первое внедрение Kanban’a в огромный отдел поддержки и в случае успеха у тебя и у нас появляются неплохие перспективы на рост в карьере и бизнесе.

2.       Кто отвечает за внедрение и результаты процесса?

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

После того, как Заказчик выслушает ваше предложение, то у него возникнут вопросы, которые он может и не задать вслух:

• А насколько сами исполнители будут отвечать за результат? И насколько они заинтересованы в успехе?
• А что будет, если процесс не приживется? Кто будет платить за неудачно потраченное время?
• Какова будет ставка с их стороны? Каков их вклад (ставка) во внедрении этого процесса кроме «рекомендаций»?

Во время написания предложения исполнители об этом не думают, особенно если модель взаимодействия Time&Material.

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

Note: Почему-то мне подумалось, что проекты по фиксированной цене как раз и направлены на то, чтобы закрыть эту уязвимую область, где ответственность лежит только на Заказчике. Но это совсем другая история…

3.       Четкая картина внедрения изменений в кратко- и долгосрочной перспективе

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

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

Заказчик, получив ваше предложение о внедрении нового процесса сразу «протестирует» его на детали:

• Какие области будут затронуты? Тем самым намекая на возможные изменения в пограничных процессах
• Куда дальше будет развиваться процесс? Насколько далеко вы видите развитие?
• Разбили ли вы процесс перехода на фазы? Есть ли у фаз критерии входа-выхода
• Когда лучше всего начать, чтобы не зацепить текущий график поставок?
• Готова ли инфраструктура для этого?
• Что понадобится для поддержки систем процесса в следующем году?
• …

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

4.       Ваша уверенность

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

Я как Заказчик задам себе вопрос: «А насколько они сами верят в то, что предлагают? Или это реализации чьих-то амбиций или фантазий за мои деньги?».

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

Уверенность (иногда даже беспочвенная) очень помогает продать тот или иной процесс.

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

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

Предлагайте и изменяйтесь к лучшему!

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