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

Выезжаю на WhaleRider

Конференция WhaleRider уже идет, а я выезжаю только на второй день

Буду выступать с докладом:

10 проблем Заказчика на старте аутсорсингового проекта

Обещаю интересный доклад и провокационный троллинг :) До встречи!

Sep 24th, 2012

Рекомендую Тренинг: Психологические техники для коммуникации

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

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

Рекомендую, записывайтесь на двухдневный тренинг в Харькове 29-30 сентября, в Санкт-Петербурге 5-6 октября и в Киеве 3-4 ноября.

Sep 22nd, 2012

Прогибаться или нет?

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

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

«Стоит ли навязывать Заказчику свой процесс?»

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

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

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

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

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

Свою позицию по этому вопросу я высказал, а теперь приведу аргументы.

Всю дальнейшую статью я разбил на 2 части:

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

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

До того, как назвать причины, хотелось бы сделать важное допущение. Все предлагаемые вами процессы и практики на самом деле несут пользу Заказчику. Не вам лично, а именно Заказчику!

Причина №1: Отсутствие непререкаемого авторитета

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

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

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

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

Да, и чуть не забыл. Заказчик не пропустит возможность напомнить вам, что экспертность и опыт – это конечно хорошо, но посмотрите на статистику успешных проектов в ИТ. Просто вижу клиента, который говорит: «Что там статистика говорит? Меньше 30% успешных? 20%+ закрывается не дождавшись результата? Так не нужно мне рассказывать как это делать»  :)

Причина №2: Нельзя изменить процесс разработки без изменения «пограничных» процессов. А это очень хлопотное занятие.

Рассмотрим пример. Вы вдруг решили внедрить SCRUM со всеми его фишками: частыми релизами на продакшн, короткими итерациями и т.д. Даже если вы нашли контакт с руководителем отдела ИТ и вам разрешили делать правильный процесс, то через какое-то время станет понятно, что нужно менять очень многое. Например:

  •  нужно теперь саппорт команду приучить к частым релизам и постоянному обучению нужным фичам
  • заставить спонсоров проекта принимать фичи каждую итерацию и подписывать счета
  • и т.д.

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

Причина№3: Любое изменение – это риск потерять то, что есть.

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

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

Так вот, неизвестно будет ли работать новый процесс, а точно станет хуже. Так зачем рисковать? Ради чего идти на эти жертвы? Тем более что люди опытные знают, что не все эксперименты заканчиваются удачно. Я даже вспомнил одну сцену из фильма, так что впервые линк на YouTube в этом блоге :)

Причина №4: Вы пришли слишком поздно

Народная мудрость гласит: «Коней на переправе не меняют» и одно из главных правил руководителей проектов гласит: «В конце проекта процесс менять запрещено».

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

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

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

 (Продолжение темы “Прогибаться или нет. Часть 2“) 

Sep 20th, 2012

Финансовая мотивация Заказчика. Бонус Клуба по работе с Заказчиком.

Хотите давать клиентам скидку? Тогда вы почти 100% не правы!

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

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

Из-за этого непонимания, После этого совершается серия глупых ошибок:

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

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

  • Финансовой составляющей проекта
  • Финансовой мотивации Заказчика

Я решил, что такая тема обязательно должна появится в Клубе по работе с Заказчиками. Поэтому я решил сделать бонус для всех осенних подписчиков клуба вебинары на тему “Финансовые вопросы при работе с Заказчиком”. Регистрация в клуб продлена ровно на неделю, так как додумался до такого бонуса только сейчас! :)

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

Sep 16th, 2012

Бесплатные материалы: Подстройка

Коллеги из проекта IT-Boost опять раздают хорошие материалы абсолютно бесплатно. Молодцы, что тут сказать :)

Подстройка к (или «настройка на» ?) удаленному собеседнику будет очень полезна тем, кто общается с удаленными командами и Заказчиками. Сами авторы курса пишут, что использовали «секретные разработки КГБ» (для пущего эффекта, конечно :) ), но как бы методики не назывались, они помогут вам в следующем:

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

Хотите получить? Тогда просто введите емейл и вперед :)

Sep 13th, 2012

13-14 октября, открытый тренинг «Аутсорсинг как сервис» в Новосибирске

Я просто хочу поделиться с вами новостью о том, что провожу первый открытый тренинг в Новосибирске. 13-14 октября, сразу после конференции Experts Labs, будет открытый тренинг для всех, кто хочет улучшить свои отношения с Заказчиком и перевести их на улучшенный уровень. Записывайтесь и приходите!

Update: Тренинг партнером и организатором площадки выступила компания Parallels. Спасибо им большое за поддержку! В рамках тренинга участникам предоставляется прекрасная возможность посмотреть как живет Parallels NSK, а на тренинге поработать с кейсами из их практики взаимодействия с заказчиками-сервис-провайдерами

Что такое тренинг «Аутсорсинг как сервис»?

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

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

Программа тренинга – 16 часов, которые изменят вашу работу с Заказчиком к лучшему

День первый

  1. Карта ценностей Заказчика – как понять “чего хочет Заказчик” и как это реализовать в своей айтишной команде.
  2. Концепция «Аутсорсинг как сервис». «Золотые законы сервиса». Простые вещи, которые улучшают ваши взаимоотношения с Заказчиком (NEW)
    • Что такое «сервис» и как применить его в разработке ПО.
    • Доверие Клиента и прозрачность процесса как основные факторы построения хорошего сервиса.
    • Дивиденды и налог на доверие. Сколько стоит доверие?
  3. Знакомство с Заказчиком. Что и как необходимо знать о проблемах Заказчика.
  4. Работа с командой Заказчика. Как сделать работу эффективной и продуктивной.
  5. Требования Заказчика к продукту и процессу
    • Почему требования не могут быть идеальными и как понять «самое главное».
    • Умение слушать Заказчика и его требования.

День второй

  1. Коммуникации:
    • Почему нас не понимают Заказчики и как это эффективно изменить
    • Правила коммуникации.
    • Борьба с невидимками или как сделать свою команду ценной и видимой.
  2. Отчеты. Как писать отчеты, чтобы они приносили пользу.Сервисно-ориентированный риск-менеджмент. Как сделать риск-менеджмент понятным и простым процессом.
    • Эффективная структура отчета
    • 3 главных ошибки в отчетах (done, управление ожиданиями, «хорошие новости»)
  3. Продажа своих идей: 12 шагов, которые позволят вам продать свою идею Заказчику.

Что получают участники тренинга?

Aug 31st, 2012

Сопротивление делегированию и мысли о конференциях

В субботу проводил небольшой мастер-класс по делегированию. Несмотря на последний МК в сетке докладов, получилось втянуть аудиторию и заставить их думать :)

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

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

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

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

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

Aug 27th, 2012

CodeFest Mini: Запись выступления

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

Выступление вышло довольно интересным, так как в главной роли были… пингвины!

Слайды

Видео

 

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

Организация на высшем уровне. Уже традиционный (для этой конфы) виски-енд дополнился шашлыками на свежем воздухе.
P.S. Отдельное спасибо за ящичек Burn-а для докладчиков, после бессонной ночи из-за сдвига во времени и перелета он очень пригодился J

Aug 15th, 2012

Один шаг дальше

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

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

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

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

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

Если брать типичное поведение аутсорсинговых компаний, то в данной ситуации команда пошла намного дальше:

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

Такая команда явно будет выглядеть намного лучше, чем команда, которая «делает только то, что в беклоге».  Но можно ли сделать еще лучше?

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

Jul 19th, 2012

Анонсы событий лета, где можно встретить anotherpm-а

Открытые тренинги и конференции на которые еще можно попасть по ранней цене. Сначала кратко, а потом с подробностями :)

<КРАТКО>

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

28 июля, Новосибирск – конференция Code Fest Mini . Доклад «Заказчик и Исполнитель – 2 точки зрения на успехи и провалы проектов». Первая конференция с шашлыками!

2-3 августа, ХарьковОткрытый тренинг «Работа со сложным Заказчиком». Вместе с Викой Муссияченко опять организуем интересный тренинг.

25 августа, Москва – конференция Pragmatic PM. Мастер-класс «Сопротивление делегированию»

26 августа, Москва – открытый тренинг «Делегирование в стиле Agile».

Еще буду в Херсоне, Харькове, Воронеже, Минске и Москве. Если кто-то хочет пообщаться – пишите в контакты.

</КРАТКО>

==============================================

Вебинар – Клуб по работе с Заказчиком

Читатели блога наверное уже знают о Клубе по работе с Заказчиком и его развитии. Каждый раз он дополняется новыми и новыми вебинарами и темами. Сейчас уже больше 20, к «осеннему призыву» собираемся еще расширять.

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

CodeFest Mini в Новосибирске

Самая большая конференция в Сибири добавляет летний мини формат «для своих». Там будет 1 поток (назло всем!) зато с очень строгими критериями отборов. Выступают только сильные докладчики (пруфлинк). Я, случайно оказавшись в НСК :), буду рассказывать там о том, что могут сделать Исполнители, чтобы разрушить основные мифы Заказчиков.

Да, по слухам, виски-афте-пати (традиционное для Codefest!) будет расширенно шашлыками. Так что я вдвойне согласен!

До встречи в Новосибирске на CodeFest Mini.

2-3 августа – открытый тренинг «Работа со сложными Заказчиками»

Я не часто делаю открытые тренинги, но всегда рад новым знакомствам и новым людям. Поэтому с проверенными организаторами делаю тренинг в Харькове. Описание тренингов и преимущества описаны в разделе «Тренинги». Но для именно этого тренинга сделаю специальные бонусы!

Attention: Тренинг однодневный. Будет выбран или один из дней или большая группа разделится на 2.

Записывайтесь сейчас и посмотрите интересные и практические инструменты работать разными типами сложных Заказчиков. Рассмотрим инструменты работы с конфликтами, жалобами и «наездами».

25-26 августа. Мастер-класс на конференции PragmaticPM и Тренинг «Делегирование в стиле Agile»

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

Я буду делать мастер-класс на тему «Сопротивление делегированию», когда подчиненные всячески пытаются увильнуть от обязанностей, которые им навязывают руководители. Интересные кейсы и практические советы.

Чтобы усилить эффект от мастер-класса, я остаюсь еще на один день, чтобы провести тренинг «Делегирование в стиле Agile». Вот там как раз и разберемся и разложим «по полочкам» каждую составляющую успешного делегирования и как это сделать. Меня сейчас просто «распирает» от этого тренинга, настолько он получается «вкусным».

Приходите на мастер-класс и на тренинг. Естественно «вместе дешевле»!

 Буду рад видеть всех на этих мероприятиях и вне их. До встречи!

Jul 5th, 2012
Page 4 of 22« First...23456...1020...Last »