Как часто, работая в инициативе, проводящей изменения в бизнесе, мы сталкиваемся с ситуацией, когда клиент заявляет, что ему нужны эти изменения, и изменения проводятся правильно, но в то же время клиент старается избегать участия в обсуждениях, затягивает с ответами, настраивает своих коллег и подчиненных против происходящих изменений и всеми силами скрыто или явно пытается саботировать или даже полностью остановить проводимые изменения?
Я думаю - очень часто.
Что мы делаем в такой ситуации?
Мы просто соглашаемся: «Ну, да… Нам не повезло с заказчиком в этот раз. Повезет в другом проекте»
Не повезет, поверьте мне! Потому, что это системное явление. И мы, в той или иной форме, будем сталкиваться с этим всегда и в каждом проекте.
Многие ли из нас работают с этой проблемой осознанно, квалифицированно и системно?
Я думаю, что нет…
Чем бы я хотел поделиться с вами?
Я давно интересуюсь темой сопротивлений изменений как теоретически, так и очень плотно работаю с этим на практике. Я проанализировал достаточное количество книг и статей. Мы разработали аналитическую платформу, которая помогла нам собрать и проанализировать реальные случаи из более чем 450 проектов, проводимых в России, Украине, Беларуси, Казахстане, Прибалтике, Польше и т.д.
Мы разработали и опробовали широкий набор практических приемов и объединили их в единый системный подход. Я расскажу в своем докладе об этих техниках и опыте их использования в реальных проектах.
Эти знания помогут вам выявлять, анализировать и устранять сопротивление вашей инициативе по проведению изменений. Вы можете применять эти техники как в вашем текущем проекте, так еще до начала проведения проекта и, таким образом, понять, с каким сопротивлением вы можете столкнуться. Это может с одной стороны позволить понять, насколько компания готова к таким изменениям, и, с другой стороны, позволит начать работать над потенциальным сопротивлением еще до того, как сопротивление начнет наносить вред вашему проекту.
 
О чем мы поговорим:
• Как определить личностей, которые потенциально могут испытывать страх перед предстоящими изменениями?
• Как выявить признаки страхов и опасений, которые могут привести к явному или скрытому сопротивлению?
• Как выявить явные и скрытые индикаторы сопротивления?
• Как разработать общие и индивидуальные стратегии взаимодействия с людьми, чтобы минимизировать или полностью устранить сопротивление вашей инициативе?

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

Позиция бизнес аналитика (БА) в проекте - это позиция особая. БА - это представитель заказчика в проектной команде и представитель технической команды в глазах заказчика. Мы знаем, что научиться говорить на языке бизнеса - это одна из главных задач БА. Но, при этом мы зачастую забываем, что БА, это еще и технический специалист, это IT специалист. 

В то время, когда весь IT-шный мир, т.е. разработчики, специалисты по контролю качества (QA, тестировщики), свободно "говорят" на языке UML и используют объектно -ориентированнный подход, аналитики имеют достаточно слабое представление в этих областях. Как результат: собственно процесс бизнес-анализа проводится спонтанно и непоследовательно, достаточно большие области знаний о бизнесе остаются "за бортом" внимания аналитика, не покрываются и не описываются, разработанные аналитиком документы скорее похожи на документ исследование бизнеса, чем на документацию, написанную для технических потребителей, т.е. требуют проведения достаточно болшой работы на стороне разработки для "перевода" на технический язык, что приводит к неоднозначности или неверной трактовке требований.

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