Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Человек со стокгольмским синдромом

667 views

Published on

Доклад Юлии Ериной на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург
www.analystdays.com

Published in: Education
  • Be the first to comment

  • Be the first to like this

Человек со стокгольмским синдромом

  1. 1. Человек со cтокгольмским синдромом
  2. 2. Руководитель проектного офиса i-Sys Labs, г. Санкт-Петербург Кто сегодня с вами Юлия Ерина
  3. 3. Минутка рекламы
  4. 4. Изначальная идея доклада
  5. 5. Немного статистики Вопрос: Ставит интересы заказчика превыше всего Вопрос: Всегда получает только положительные отзывы от заказчика 0 10 20 30 40 50 60 70 80 Аналитик РП Разработчик ТП >7 баллов, % >7 баллов 0 10 20 30 40 50 60 Аналитик <7 б Аналитик >7б Всегда получает положительные отзывы Положительные отзывы
  6. 6. Всех хороших аналитиков любят заказчики. Кошмар начинается, когда… Аналитик воюет с командой. В итоге аналитика любят, а команду и компанию – нет. Аналитик формирует требования, забивая забывая цели и границы проекта. Аналитик преследует цель удовлетворения в первую очередь конечных пользователей. Аналитик «сливается» с командой заказчика и не отождествляет себя со своей командой. «Виноваты разработчики».
  7. 7. А в итоге…
  8. 8. Что об этом говорят руководители 1
  9. 9. Вернёмся к истокам. Какую роль занимает бизнес-аналитик
  10. 10.  Искаженное восприятие проекта, границ и заказчика  Неадекватная самооценка аналитика  Внешний локус контроля  Сдача границ проекта  Сдача личных границ  Защита границ заказчика  Капитуляция Откуда растут ноги
  11. 11. Определение границ проекта • Каковы цели и задачи проекта и каким образом их собираются осуществить в рамках соответствующих ресурсных и временных ограничений? • Кто является заинтересованными сторонами и каковы их потребности в проекте? • Каковы возможности проекта и угрозы для его успешной реализации? MOSCOW (Must have, Should have, Could have, Won’t have for now)
  12. 12. Иными словами
  13. 13. Как выглядят плохие границы «Границы проекта должны включать в себя все накладные, командировочные и т.д. расходы. Подробные требования к системе должны быть выявлены на этапе аналитики.»
  14. 14. Пример: • Часть работ будет выполняться удаленно, в офисе Исполнителя. Для этого Заказчиком будет обеспечен удаленный доступ к необходимым информационным ресурсам. • В рамках проекта реализации Системы заложены две командировки двух специалистов Исполнителя. Расставляем границы правильно Пример: • Предполагается, что Заказчик предоставит Исполнителю переводы названий реквизитов, текстов оповещений, комментариев и других элементов интерфейса на украинский язык. • Дополнительное брендирование Системы кроме применение логотипов в рамках проекта не предполагается. • Предполагается поддержка системой браузеров Internet Explorer 9 и выше, Google Chrome 45 и выше.
  15. 15. Пример: • Предполагается, что обеспечение сервиса коротких сообщений будет обеспечиваться интеграцией с MS Lync (Skype for Business) Расставляем границы правильно Пример: • Предполагается, что в рамках проекта возможность формирования документов на основании хранимых шаблонов с заполнением параметров будет реализована: • не более чем для 5 шаблонов для каждого модуля. • Не более чем для 15 реквизитов карточки, автоматически заполняемых для каждого вида шаблона.
  16. 16. Пример: • Предполагается, что заказчик будет использовать единый каталог пользователей (Active Directory) для всех подразделений. Расставляем границы правильно Пример: • Техническая поддержка на этапах опытной эксплуатации осуществляется командой разработки
  17. 17. Прислушивайтесь к звонкам Колокол звонит ещё на пресейле Чем более мутную игру тебе навязывают, тем четче надо говорить «Нет»
  18. 18. Магический круг проекта  Содержание проекта  Критерии приемки результата  Границы проекта (что входит в проект и что нет)  Ограничения проекта  Допущения проекта
  19. 19. Защита границ проекта
  20. 20. 1 Выстроенный процесс управления изменениями 2 Участие аналитика в пресейлах и в предпроектной активности 3 Прозрачная финансовая мотивация аналитиков в привязке к прибыльности проекта 4 Качественная проработка границ проекта. Изначальное понимание, насколько открыты/закрыты границы 5 Сохранение сработанной команды из проекта в проект 6 Изменение границ в обмен на что-то 7 Своевременная эскалация конфликтов и проблем
  21. 21. Защита личных границ
  22. 22. • Стараться понравиться всем • Казаться лучше, чем есть • Присваивать чужие полномочия • Бояться говорить «Нет» • Оправдываться • Вкладываться больше, чем нужно • Бояться субординации, если она правильная • Забывать про локус контроля
  23. 23. Вопросы? Юлия Ерина i-Sys, Питер http://www.facebook.com/juliya.erina

×