Outsourcing as a service

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

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

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

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

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

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

P.S. Сначала решил поместить эту методику в рассылку Базового курса по работе с Заказчиком. Но потом понял, что там и так много интересного и полезного материала + куча бонусов. Поэтому публикую тут.

11 августа состоится встреча КУЛ-ИТ, которую организовывает неугомонная Вика Придатко.

В этот раз будут 2 новые темы о коммуникациях и нетворкинге:

• Visibility and promotion of your team inside company. How to sell results of your team?

Сергей Ткачук поделится своим опытом, как он за два года в продуктовой компании из 1000 сотрудников на позиции тимлидера прошел от ситуации «А у нас что, есть такая команда?» до «Много о тебе слышал, давно хотел познакомиться!».

• “Зачем айтишнику нетворкинг – почти то же, что про “козу и баян”

Спикеры: Катерина Синдякова – CEO компании 2accomplish, предприниматель в области IT, автор и модератор тренингов Имидж и безопасность в соцсетях, Грамотный networking, Как убедить собеседника за 30 секунд, а также совладелица бизнес-клуба Kiev Business Hunters Club. Инна Кравченко – карьерный коуч и совладелица бизнес-клуба Kiev Business Hunters Club.

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

Приходите… Записаться нужно на блоге Вики Придатко.

Адрес встречи: компания “Lohika“ станция метро Лыбедская,  ул.  Горького 172, 19й этаж, БЦ Палладиум. Вход  в бизнес центр находится справа от основного входа в торговый центр с улицы Панаса Любченка.Карта 
Время встречи: с 19.00-21.00, после 21.00 – как пойдет – общение, обсуждение, пицца, пиво.

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

Тут выкладываю слайды презентации

Для подписчиков «Базового курса работы с Заказчиком» я выкладываю видеозапись вебинара с вопросами и историями из личной жизни. Подписывайтесь!

Решил, что делиться знаниями нужно не только в формате рассылки.

Я буду проводить практический-вебинар для участников группы Стратоплан.ру. Саша Орлов  и Слава Панкратов предложили мне провести вебинар и я не смог отказать :)Так как знаю, что в группе собираются люди, которые развиваются и чего-то хотят достичь!

Заполняйте форму подписки сейчас: Все новые подписчики, которые успеют записаться до 18:55 27 июля получают ссылку на участие в вебинаре:

27 июля в 19:00 (GMT+2, «по Киеву»)

Вебинар «Работа как сервис»

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

Программа вебинара:

• Почему наши аутсорсеры выигрывают у азиатских конкурентов, но проигрывают западным. Неужели мы или они Умнее? Лучше пишут код? Лучше образованы?
• Разработка ПО как сервис – какие не-айтишные сервисы нам ближе всего и как поучиться в других областях.
• Основные законы сервиса в жизни разработчиков ПО
• Что такое позиционирование и что оно может дать программистам, менеджерам и всей команде

Одновременно с приглашением на промо-вебинар вы подписываетесь на уникальную рассылку «Базовый курс работы с Заказчиком в ИТ». Хороший бонус… это я точно знаю, так как потратил много сил на его создание

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

Хочу поделиться приятной новостью с коллегами по ИТ бизнесу. Вот решился написать/записать бесплатный базовый курс по работе с Заказчиками для ИТшников. В него я включил набор простых практик и советов, которые помогут  выстраивать хорошие отношения с Заказчиком и их командами.

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

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

Программа рассылки

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

• Как работает бизнес Заказчика
• Зачем Заказчику он пришел к вам? Какие проблемы он хочет решить?
• Почему люди, которые умеют решать проблемы стоят в 5-6 раз дороже?
• Почему важно узнать Заказчика с человеческой (не деловой) точки зрения и как это может помочь бизнесу?

Как представлять свою команду. Как информировать о ее изменениях.

• Почему Заказчику нужно представлять команду?
• Правильно представляем свою команду. Вырабатываем кредит доверия Заказчика.
• Как сообщить Заказчику, что кто-то уходит из команды?
• Как Заказчик может помочь сохранить текущую команду?

Различные типы Заказчиков и как с ними работать. Примеры нескольких типизаций и наиболее успешные стратегии работы с ними.

• Типы Заказчиков по Адизесу
• 12 типов Заказчиков во фрилансинге
• Основное правило настройки под разные типы Заказчиков.

Чего хочет Заказчик? Основные причины провала ИТ (аутсорсинговых) проектов глазами Заказчиков и что наши команды могут изменить.

• Правда ли, что «Быстро-Дешево-Хорошо» – это единственный путь для удержания Заказчика?
• Как команда может научить Заказчика и как это приводит к результату.
• Предложения и идеи команды.
• Принятие решений и ответственности за них.
• Что делать, если Заказчик просит скидки.

Коммуникации с Заказчиком. Почему они сложны, самые интересные кейсы о том, как улучшить коммуникации с Заказчиком.

• Зачем мы общаемся  с Заказчиком?
• Основные ошибки общения с удаленным Заказчиком.
• Почему Заказчиков нельзя «заставить»?
• Как сказать Заказчику «Нет» и не рисковать при этом?

Что делать, если ничего не помогло?

• Когда пора менять Заказчика?
• Список литературы, которая понятна АйТишнику и помогает работать с клиентом.
• Консультации anotherpm-а

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

Записывайтесь сейчас! Всего 3 клика…

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

Мои друзья “Слава и Саша” (ТМ) проводят необычный ивент в горячий летний день в Киеве, на который очень хочу пойти и вам рекомендую!

Лидершоп - это не магазин лидеров, как многие могли бы подумать, это сокращение от Leadership Workshop.  И мы со Славой Панкратовым проведем его в Киеве 13-14 августа.

Лидерство для менеджера, тим лида и ведущего специалиста.

Инструмент управления людьми в ИТ.

Что такое лидерство в менеджменте?

Лидерский стиль управления:
— Конструктивный
— Эффективный
— Результативный

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

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

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

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

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

Записаться на воркшоп можно на странице:

http://www.stratoplan.ru/trainings/leadership-workshop/

Кейс про несговорчивого Архитектора, от одного из участников моих тренингов, собрал много комментариев от коллег.

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

Во-первых, я считаю, что тут есть как минимум 2 проблемы:

• А на самом ли деле Архитектор не прав?

• Как воспримет Архитектор критику со стороны удаленной команды?

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

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

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

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

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

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

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

Конечно, они будут сопротивляться до последнего. Вы отняли у них дорогу к жизни. Им ничего не остается, как стоять насмерть! Покажи врагу дорогу к жизни! Приоткрой невзначай проход в неприметном месте. Их много и они разные. Есть и раскаявшиеся, и насильно забранные в шайку. Есть и просто трусы. Они побегут. И одного почтового чиновника хватит, чтобы повязать их всех!

Так и сделали. Разбойники были схвачены, доставлены в столицу и казнены.

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

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

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

Самым хорошим решением данной проблемы я вижу следующий шаг: Аутсорсинговая команда находит оптимальное решение и пишет письмо:

Дорогой Архитектор,

Благодаря твоей идее мы натолкнулись на классную идею о том, как улучшить наш продукт. Взяв твое решение за основу, мы «допилили» ХХХ часть и теперь наша система будет более устойчивой/безопасной/быстрой (нужное подчеркнуть).

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

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

Не согласны? Можете предложить лучший вариант решения? Welcome to comment…

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

Я, как менеджер, наверное, пошел бы в дебри «мотивационных излагательств и словоблудия» :)… А вот Антон Наумов (известный харьковский ИТ-мен) в своем блоге предложил свою концепцию самостоятельного развития.

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

Хотите узнать точку зрения зрелого программиста? А какие же все-таки первых 3 уровня? Ответы в посте Антона

Дальше в виде шутки ссылка на “настоящее” ДАО программиста!

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

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

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

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

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

с трудом выразил свое восхищение цензурно :))

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

Только после этого отзыва, я по-настоящему стал понимать своих друзей, по совместительству коллег по цеху (Слава и Саша, привет!), которые учат меня уму разуму. Благодаря таким участникам тренинга понимаешь, что ты все это делаешь не зря. И хочется идти на новые свершения!

P.S. Некоторые из вас вероятно подумают, что я это даю ради рекламы. Что же,  оставляю это право вам.  А если  вы порадуетесь за меня и за ребят, которые учились, я буду немножко счастливее

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

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

В команде Заказчика есть главный Архитектор. В его работе есть особенности: он работает на пол-ставки (! IMHO, очень тревожный фактор для главного технического человека проекта с ~40 разработчиками – 2 аутсорсинговые и 1 внутренняя команды). Архитектор принимает решения самостоятельно, не желает делегировать (но при этом не углубляется в детали); дружит с CEOкомпании-Заказчика (! представляется незаменимым для CEO).

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

Архитектор ввиду сильной занятости не оценил наше письмо, самоуверенно защищает своё техническое решение. Сейчас идёт переписка по этой проблеме, с каждым письмом он всё более пассивно-агрессивен. Как я расцениваю ситуацию (на основе знаний полученных во время тренинга, Сергей Бережной): на одной стороне чаши – Заботливость (решение важное, может привести к проблемам на проекте, мы этого не хотим), Честность, Профессионализм (мы понимаем, что данное техническое решение неправильное); на другой стороне – Оперативность (переписка по проблеме уже отняла время, ещё не закончена, затягивает), Дружелюбие, Вежливость (мы вежливы и дружелюбны, но Архитектор принимает наши письма агрессивно, отвечает без вежливости, воспринимает нас как угрозу своему авторитету).

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

Были ли у вас такие случаи? Что делать коллеге? Как убедить Архитектора принять правильное решение?