Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий
•Download as PPTX, PDF•
2 likes•1,742 views
Analyst Days-1. Секция D. Оксана Сергеева
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий
Similar to Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий (20)
More from SQALab
More from SQALab (20)
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий
- 1. «Зри в корень!» или Специфика работы бизнес- аналитика в зависимости от типов проектов и методологий Оксана Сергеева, EPAM Systems
- 2. 2012, Head of MS Division 2011, BA Unit start (6->20+ ppl) 2004, PM (10 - 80 ppl) 2002, PC/BA (3-4 ppl) 1992, Programmer Minsk, 2012 2
- 3. Размышления о том, какое влияние имеют проекты разного типа на аспекты работы Бизнес Аналитика, участвующего в них Minsk, 2012 3
- 4. Почему это важно? Потому что БЭй должен: Понимать риски и знать к чему быть готовым Знать подходы и способы минимизации рисков Уметь подобрать инструментарий и формат артефактов Minsk, 2012 4
- 5. T&M с ограниченным Зависимости Утверждение требований бюджетом Оценка Большая команда трудозатрат Бизнес- SCRUM Agile правила Риски Инструментарий Функциональные Видение проекта Новые технологии спецификации Axure Нефункциональные Фиксированный бюджет требования Прототипирование Неформальный RUP Итерации Waterfall Stakeholders Стандарты Нечеткие требования процесс XP Распределенная команда Новая проектная Пользовательские Изменение Milestone требований T&M команда истории Сложная система Ограниченные сроки Предположения и Планирование ограничения Варианты Пользователи Сработанная команда использования Minsk, 2012 5
- 6. Проекты могут делиться (но не ограничиваться): По методологии По модели ценообразования По цели/scope Minsk, 2012 6
- 7. Итерационный (например RUP) 4 фазы: начальная, уточнение, конструирование, внедрение 9 дисциплин: 6 основных и 3 поддерживающих Вовлечение разных ролей распределяется по проекту неравномерно в зависимости от фазы Agile SCRUM Kanban XP Что-то «свое» Minsk, 2012 7
- 8. Fixed cost (Фиксированная цена) Оплачивается по фазам или по завершению проекта Time and Material ,T&M (Время и Материалы) Оплата ежемесячно по факту (в зависимости от затраченных времени) Оплата ежемесячно фиксированной суммой (как правило за команду определенного размера) Minsk, 2012 8
- 9. New Development (Новая разработка) Разработка новой системы или полное переделывание старой Implementation (Внедрение) Адаптация, настройка и внедрение системы на базе существующей платформы Integration (Интеграция) Разработка интеграции двух и более систем “Evolution” («Эволюция») Развитие уже существующей системы через добавление новых функций, улучшений, изменений и т.п. Minsk, 2012 9
- 10. Я представлю ряд «кратких описаний» проектов. Ваше задание будет определить, что это за тип проекта (или смесь каких типов), по тем признакам, которые вы смогли заметить. Minsk, 2012 10
- 11. Заказчик просит разработать автомобиль, как на указанной картинке, с предоставлением полного пакета чертежей. Он хочет выполнения проекта в установленные сроки и границах бюджета, а также поэтапную демонстрацию результатов. Minsk, 2012 11
- 12. У Заказчик есть автомобиль, который хоть и работает, но перестал удовлетворять современным требованиям. Заказчик просит разработать новый автомобиль с тем же назначением и основными функциональными требованиями, но безопаснее, устойчивее, быстрее и привлекательнее. Он просит завершить разработку через год, при этом ему хотелось бы постоянно контролировать промежуточные результаты. Minsk, 2012 12
- 13. Заказчик просит разработать авто-прицеп для перевозки водного мотоцикла, как на указанной картинке. Заказчик просит предоставить оценку сроков и работ по данному проекту, однако согласен на помесячную оплату работ. Проектная документации его интересует, но только «в рамках разумного». Minsk, 2012 13
- 14. Итерационный Agile Что-то «свое» 1. Списке контактов 2. Плане коммуникаций (кто, что, кому, зачем) 3. Необходимых документах и их формате 4. Инструментарии Minsk, 2012 14
- 15. Fixed Cost T&M 1. Домене, границах проекта, 1. Методологии проекта и место предположениях, ограничениях и (обязанности) BA в ней рисках 2. Соотношении capacity с объемом 2. Требованиях к набору артефактов и работ, который ожидается от BA их формату 3. Процессе уточнения требований, их утверждения и управления изменениями Minsk, 2012 15
- 16. Имплементация Новая (на базе Интеграция «Эволюция» разработка существующей платформы) 1. Системных 1. Возможностях 1. Списке контактных 1. Возможностях и требованиях и и лиц со стороны ограничения границах ограничениях интегрируемых системы проекта платформы систем (приложения) 2. Контроле 2. Наличии 2. Готовности систем 2. Влиянии реализации шаблонов к интеграции и изменений части целей и всех артефактов бизнес правилах системы на всю основных 3. Проведении 3. Интеграционных систему требований “GAP”- анализа входах/выходах и (приложение) в 3. Ключевых их спецификации целом пользователях 3. Необходимости миграции данных Minsk, 2012 16
- 17. И снова о «машинках»… Ваше задание будет определить, что это за тип проекта, возможные риски и продумать, как вы бы организовали работу Бизнес Аналитика в нем. Minsk, 2012 17
- 18. Заказчик просит разработать автомобиль, как на указанной картинке, но при этом он не имеет четкого представления, что же ему хочется «внутри». Его интересует ваша приблизительная оценка сроков и бюджета данного проекта и при этом ему хотелось бы на периодической основе контролировать промежуточные результаты. Minsk, 2012 18
- 19. Minsk, 2012 19
Editor's Notes
- Disclaimer #1 - я не являюсь ни профессиональным докладчиком ни тренером, соответственно могут случаться глюкиDisclaimer #2 - Презентация будет на русском, однако будет встречаться терминология и на английском. Не очень эстетично, зато привычно
- Один раз научившись писать идеальные user story,Готовясь к участию в новом проекте, БЭй должен помнить – его главная задача понять бизнес проблему (или проблему пользователя) и помочь в нахождении пути ее решения. Форма и инструментарий, который при этом будет использоваться должны подстраиваться под потребности заказчика и проекта.Это как подготовка к отпуску: сначала мы определяемся с тем, а как же мы хотим отдохнуть, а затем уже начинаем подбирать экипировку и снаряжение…Понимание окружения и ограничений проекта имеет непосредственное влияние на эффективность и на ценность работы Бэя и, как результат, на собственно САМ ПРОЕКТ…
- Но как «знать/понять», если «много»
- данные четыре могут быть основной отправной точкой. и я предлагаю поговорить о специфике в контексте именно этих четырех типов
- 9 дисциплин: 6 основных (бизнес-моделирование, управление требованиями, анализ и проектирование, реализация, тестирование, развертывание) и 3 поддерживающих (управление проектом, управление изменениями и конфигурацией, управление инфраструктурой)
- Fixed cost - expert level experience is required to make estimates- it's very important to identify and agree on BA activities and deliverables before to make estimates- understanding of scope complexity and boundariesis critical- estimates must be aligned with WBS (project plan tasks) for specific scope- selected project methodology must be taken into account- risks and assumptions explicit definition should accompany estimates it's strongly recommended to agree on this topic before estimation as any change may affect the budgetdo not change (experiment) approaches, procedures and tools in course of project unless it's absolutely critical follow agreed deliverables set- before to start work make sure that you understand all deliverables formats and purpose, studied samples- focus only on most critical and valuable thingsNOTE: most of listed below can be applied to other project types as well as these are quite general approaches and pre-requisites.- know who are stakeholders and communication channels with them- Manage Customer; carefully filter Customer requests (what is within agreed boundaries, what is outside and thus can be done only at extra cost)- however at the same time, feel when and where you can yield to Customer's wishes (usually this might be needed when business conditions are changing)- pre-define on techniques to be used for elicitation- be attentive and focused- early report about risks- use visualization as much as possible (diagrams, mocks, etc)- use screen sharing software and voice communications (if you have to work off-site)- agree on meetings upfront; prepare agenda for them- if Customer does not want to work in the Tracking System where you are managing Requirements/USs - use Issues/Questions log (e.g. Excel) if which you will record decisions on doubtful/questionable itemsT&Min this case it's more important just to understand scope complexity and boundaries; team size and align amount of BAs with this understandingif customer budgets a specific amount of BA positions, then it's important to align BA activities and deliverables appropriatelythis pricing model gives a little more freedom in adjusting processes, procedures and tools but still you have to be reasonable and evaluate benefit of changes against effort needed to make a changestill understanding of Milestones schedule is important as this will help you to focus on right things
- New Development - start with Elaboration phase (no matter what the pricing or methodology models are going to be selected); proceed from understanding of User profiles, Business objectives and high level Business and User goals down to more detailed functional and non-functional requirements, business rules, assumptions, limitations and constrains- if Agile methodology is selected, define interim milestones and evaluate your progress against themUsually this is:- Vision and Scope (including business objectives, business and user goals, high-level functional and non-functional requirements, limitations and constrains, etc.)- Use Cases diagram or at least Mind Map (this actually more convenient and powerful then UCs diagram)- Domain Area Context- Glossary- Release Notes (not only BAs may be responsible for this doc)- User Stories and/or Scenarios- Software Requirements Specifications (aka SRS) (this usually omitted in case of Agile)- different Matrixes (e.g. Permissions Matrix, Supported Browsers Matrix)- Deployment guidelines- User Manuals or something what replaces them (e.g. Video tutorials, in-application Help, etc.)- Business Objects Model- API Specification, Data formats (if required)in case of Agile, to make sure that Product/System will be ready for use split it to major Modules and divide them between interim Milestones; while working on Requirements/features constantly check yourself against these Milestones: at first focus on critical and important functionality, then on the rest if time permitsImplementation you must be SME in a domain (eg. Sales Force, "whatever" CMS, etc.) and understand which business processes/scenarios can be covered by your Systemstart with understanding business needs and gap analyses between them and System "out-of-the-box" capabilities and abilities for customizationVision and ScopeGap Analyses ReportGlossarydifferent MatrixesSRS or User Stories (in case of customization)Business Processes and Rules specificationsIntegration start from integrated Systems purpose, capabilities, limitations and constrains studying- Vision and Scope (including integrated Systems architecture diagrams)- Glossary- different Matrixes- Business Processes and Rules specifications- Data/Messages exchange formats- API specifications“Evolution” - often it ends up with part-time BA involvement- start with Product (System) purpose, functionality and constrains studyingNOTE: in this case a set of BA deliverables will heavily depend on what set of documentation was received with Product/System, however at least following docs should be in work:- Application Map (landscape)- User Story or Scenario- SRS (if required)- different Matrixes- API Specification, Data formats (if required)- every enhancement/change request should be evaluated for the impact to the Product/System architecture and stability- use diagrams, presentations to explain the Customer your vision/proposal on the enhancement/change (in case if it's something sizable)