Человек со стокгольмским синдромом
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,096 views
Доклад Юлии Ериной на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург www.analystdays.com
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (9)
Ähnlich wie Человек со стокгольмским синдромом
Ähnlich wie Человек со стокгольмским синдромом (20)
Mehr von SQALab
Mehr von SQALab (20)
Человек со стокгольмским синдромом
- 2. Руководитель проектного офиса i-Sys Labs, г. Санкт-Петербург Кто сегодня с вами Юлия Ерина
- 5. Немного статистики Вопрос: Ставит интересы заказчика превыше всего Вопрос: Всегда получает только положительные отзывы от заказчика 0 10 20 30 40 50 60 70 80 Аналитик РП Разработчик ТП >7 баллов, % >7 баллов 0 10 20 30 40 50 60 Аналитик <7 б Аналитик >7б Всегда получает положительные отзывы Положительные отзывы
- 6. Всех хороших аналитиков любят заказчики. Кошмар начинается, когда… Аналитик воюет с командой. В итоге аналитика любят, а команду и компанию – нет. Аналитик формирует требования, забивая забывая цели и границы проекта. Аналитик преследует цель удовлетворения в первую очередь конечных пользователей. Аналитик «сливается» с командой заказчика и не отождествляет себя со своей командой. «Виноваты разработчики».
- 7. А в итоге…
- 8. Что об этом говорят руководители 1
- 9. Вернёмся к истокам. Какую роль занимает бизнес-аналитик
- 10. Искаженное восприятие проекта, границ и заказчика Неадекватная самооценка аналитика Внешний локус контроля Сдача границ проекта Сдача личных границ Защита границ заказчика Капитуляция Откуда растут ноги
- 11. Определение границ проекта • Каковы цели и задачи проекта и каким образом их собираются осуществить в рамках соответствующих ресурсных и временных ограничений? • Кто является заинтересованными сторонами и каковы их потребности в проекте? • Каковы возможности проекта и угрозы для его успешной реализации? MOSCOW (Must have, Should have, Could have, Won’t have for now)
- 12. Иными словами
- 13. Как выглядят плохие границы «Границы проекта должны включать в себя все накладные, командировочные и т.д. расходы. Подробные требования к системе должны быть выявлены на этапе аналитики.»
- 14. Пример: • Часть работ будет выполняться удаленно, в офисе Исполнителя. Для этого Заказчиком будет обеспечен удаленный доступ к необходимым информационным ресурсам. • В рамках проекта реализации Системы заложены две командировки двух специалистов Исполнителя. Расставляем границы правильно Пример: • Предполагается, что Заказчик предоставит Исполнителю переводы названий реквизитов, текстов оповещений, комментариев и других элементов интерфейса на украинский язык. • Дополнительное брендирование Системы кроме применение логотипов в рамках проекта не предполагается. • Предполагается поддержка системой браузеров Internet Explorer 9 и выше, Google Chrome 45 и выше.
- 15. Пример: • Предполагается, что обеспечение сервиса коротких сообщений будет обеспечиваться интеграцией с MS Lync (Skype for Business) Расставляем границы правильно Пример: • Предполагается, что в рамках проекта возможность формирования документов на основании хранимых шаблонов с заполнением параметров будет реализована: • не более чем для 5 шаблонов для каждого модуля. • Не более чем для 15 реквизитов карточки, автоматически заполняемых для каждого вида шаблона.
- 16. Пример: • Предполагается, что заказчик будет использовать единый каталог пользователей (Active Directory) для всех подразделений. Расставляем границы правильно Пример: • Техническая поддержка на этапах опытной эксплуатации осуществляется командой разработки
- 17. Прислушивайтесь к звонкам Колокол звонит ещё на пресейле Чем более мутную игру тебе навязывают, тем четче надо говорить «Нет»
- 18. Магический круг проекта Содержание проекта Критерии приемки результата Границы проекта (что входит в проект и что нет) Ограничения проекта Допущения проекта
- 20. 1 Выстроенный процесс управления изменениями 2 Участие аналитика в пресейлах и в предпроектной активности 3 Прозрачная финансовая мотивация аналитиков в привязке к прибыльности проекта 4 Качественная проработка границ проекта. Изначальное понимание, насколько открыты/закрыты границы 5 Сохранение сработанной команды из проекта в проект 6 Изменение границ в обмен на что-то 7 Своевременная эскалация конфликтов и проблем
- 22. • Стараться понравиться всем • Казаться лучше, чем есть • Присваивать чужие полномочия • Бояться говорить «Нет» • Оправдываться • Вкладываться больше, чем нужно • Бояться субординации, если она правильная • Забывать про локус контроля
Hinweis der Redaktion
- Стокгольмский синдром — термин популярной психологии, описывающий защитно-бессознательную травматическую связь, взаимную или одностороннюю симпатию, возникающую между жертвой и агрессором в процессе захвата, похищения или применения насилия. Под воздействием сильного шока заложники начинают сочувствовать своим захватчикам, оправдывать их действия, и в конечном счёте отождествлять себя с ними, перенимая их идеи и считая свою жертву необходимой для достижения «общей» цели. В сфере ИТ данный термин прочно закрепился в адрес людей, постоянно контактирующих с заказчиком и склонных в любой момент «переметнуться» на сторону заказчика. Чаще всего этот термин используют руководители проектов и менеджеры.
- Если обратиться к статистике, то картина получается очень интересная. На последней оценке компетенций мы добавили 1 вопрос, который оценивал бы как раз склонность к стокгольмскому синдрому у различных специалистов. Вопрос звучал следующим образом: Ставит интересы заказчика превыше всего. Респондентам предлагалось поставить балл от 1 до 10. Чем выше балл, тем больше сила утверждения фразы. 1 – соответственно, не ставит интересы заказчика ни во что =) Мы специально сделали немного коварную и размытую формулировку. Но результат оказался ожидаем. Почти 70 % аналитиков компании набрали >7 баллов. Ожидаемо, руководители проектов всего в 12 % случаев ставят интересы заказчика превыше всего. Но у большинства средний балл крутился около 5ки – то есть умеренно высокий: считаются с интересами заказчика, но во главу угла ставят интересы проекта и своей команды. Заметьте, что довольно высок % у специалистов технической поддержки. Действительно, аналитики наиболее склонны к стокгольмскому синдрому. Но давайте посмотрим на еще одну диаграмму. Респондентам предлагалось ответить на вопрос «Всегда получает только положительные отзывы от заказчика». По большому счету, перекос здесь небольшой, но как раз в пользу людей, которые ставят интересы заказчиков превыше всего. В силу малой выборки ( у нас порядка 20 аналитиков) довольно непросто сделать однозначные выводы. Но всё-таки эта статистика дает нам основания полагать, что наличие стокгольмского синдрома и эмпатии к заказчику играет скорее положительную роль на проекте.
- Было бы неправильно не спросить их подробнее, что они считают стокгольмским синдромом и в чем его опасность для проекта и команды исполнителя/подрядчика. Я задала соответствующий вопрос руководителям проектов нашей компании, а также просто друзьям, которые работают в управлении проектами. Вот несколько мнений, которые я выбрала как наиболее интересные: Наверное для меня самым главным является, когда я полностью могу доверять человеку, когда он, находясь у заказчика, является действительно аватаром нашей команды, бережёт ее нервы и время и отстаивает наши интересы, а не его личные интересы. Стокгольмский синдром – это когда отправляешь своего аналитика к заказчику, а обратно получаешь копию их менеджера проекта, которая говорит и думает языком заказчика, забывая, что на нашей стороне тоже есть совокупность причин выстраивать работу именно так. Если сказать двумя словами, то это сливание своих границ и слияние с границами, установленными заказчиком. 4. У аналитика не может быть стокгольмского синдрома. Так как нет обязательных условий для его появления – захват, удержание, насилие. Люди получают деньги за свой нелегкий труд. Другое дело, что даже получая зарплату, многие всё равно не осознают себя в той же лодке, что и заказчик. Отделяют себя. А от этого и получается ощущение противостояния.
- Давайте вместе определим основные признаки «стокгольмского синдрома», которые именно опасны для проекта (вопрос к залу). Дальше постепенно открываем нужные пункты или все вместе.
- Проект начинается с идеи и возникает с целью удовлетворения потребностей человека. Идея состоит в том, чтобы сделать что-то, что кажется необходимым. Преобразование идеи в проект начинается с понимания природы потребности как движущей силы. Поэтому потребности являются основной движущей силой проекта. 3 фазы в определении потребностей: Появление потребностей — все заинтересованные стороны должны предупреждать и предвидеть потребности, реагируя на них проактивно; Признание потребностей — осознание потребностей на основе сбора информации и обсуждения с ЗС. Главная задача на этом этапе – превращение возникающей потребности в цели, которые начнут определять результаты проекта; Формулирование потребностей — прояснение понимания потребности с помощью более точного описания ее характерных особенностей. Формулировка того, что должно быть сделано, т.е. определение границ, формулировка проекта. Когда перечень потребностей (требований) сформирован, модель анализа MOSCOW (Must have, Should have, Could have, Won’t have for now) может помочь разделить требования на обязательные (Must have’s) и желательные (Should have’s). О том, что будет и не будет включено в проект, менеджеру проекта (с подачи аналитика, если это делается на этапе анализа) необходимо достичь соглашения с ответственным руководителем проекта и с управляющим советом проекта. Границы проекта обязательно фиксируются в уставе проекта.
- Необходимо точно определить, что проектная команде делать не будет.
- В примере границы, которые обычно любят расставлять именно заказчики. Такие границы обычно очень выгодны с точки зрения возможностей пропихнуть кучу неоговоренного ранее функционала. Если на этапе предпроектного и проектного анализа вы допустите такую фразу в ТЗ, а не сторгуете её на более выгодную для себя, вероятность провала проекта увеличивается в разы. Еще хуже, если вы сами внесете в ТЗ аналогичную фразу без необходимости. Лучше ничего не писать, чем написать такое. Ружье, которое рано или поздно выстрелит.
- А теперь поговорим о том, какие правильно выделить границы проект (с примерами)
- А теперь поговорим о том, какие правильно выделить границы проект (с примерами)
- А теперь поговорим о том, какие правильно выделить границы проект (с примерами)
- Давайте вместе определим основные признаки «стокгольмского синдрома», которые именно опасны для проекта (вопрос к залу). Дальше постепенно открываем нужные пункты или все вместе.
- Поговорим по каждому пункту отдельно. Огромное влияние на возникновение проблем с границами оказывает искаженное их восприятие. То есть когда аналитик плохо понимает, где они вообще находятся и кто несет ответственность за их сдвиг. Обычно такая ситуация возникает при некомпетентном управлении проектом с фиксированной стоимостью или на проектах по принципу аутстаффинга. На самом деле со вторым подходом все проще, так как в этом случае слияние заказчика и аналитика несёт скорее пользу, чем вред. Совершенно другое дело – это проекты с фиксированной стоимостью, где границы должны быть закреплены максимально жестко. Можно выделить магический круг проекта, внутри вероятность свалиться в стокгольмский синдром аналитику или всей команде становится минимальной. Он включает в себя понимание следующий принципиальных показателей проекта: Описание содержания проекта Критерии приемки результата Границы проекта (что входит в проект и что нет) Ограничения проекта Допущения проекта Четкое понимание всей командой этих пунктов и работа внутри этого круга – огромный залог успешного проекта. Всегда требуйте Пма формализации этих пунктов и согласования их с заказчиком вплоть до отказа от участия в проекте при их отсутствии. И помните, что работа в ситуации полнейшей неопределенности – это очень мощный демотиватор , который выльется в гораздо большие проблемы, чем проект, который был сдан с большими трудозатратами.