What is business analyst?的side note.
以下记载个人想法与笔记.
List
project中包括的内容:
- Project Intro
- Current State (competitors)
- Stakeholders
- Future state diagram
- Requirements
- Possible screen mockups (wireframes or UI flow)
Overview
首先我们得知道what does this project do/ what problem does this project solve.
Current State
同时分析现有的市场.从比较competitors中一来是(相同之处)更加确定自己的project可以解决什么问题,二来(不同之处)自己对于competitors的优势,能解决什么他们不能解决的问题.
Another word, Why beneficial?
Requirements
最最重要的部分.
分析requirements,并按moscow来确定优先度.
MoSCow:
- Must Have
- Should Have
- Could Have
- Won’t Have this time(nice to have feature)
Stakeholders
最重要的部分.
Stakeholders list:
takeholder可以理解为项目有关人员.
了解了requirements之后就可以分配职责.
分析每个人的职责,项目干涉/影响度,在What is business analyst?的笔记中有.
比如RACI chart, stakeholder list.
关于每个requirement记载他们的详细内容:
Requirements Catalogue - project: the project name:
Author: | Date: | Version: | Status: | Page: |
---|---|---|---|---|
Requirement ID | ||||
Requirement Name | ||||
Business Area | ||||
Source | ||||
Owner | ||||
Priority | ||||
Type of Requirement | ||||
Requirement Description | ||||
Associated non-functional requirements | ||||
Acceptance Criteria | ||||
Justification | ||||
Comments | ||||
Related Documents | ||||
Related Requirements | ||||
Resolution | ||||
Version Control |
- Source: User who requested the requirement.
- Owner: The business user who is responsible for the requirement.
- Priority: From MoSCoW.
- Type of Requirement: General, technical, functional, non-functional.
- Requirement Description: requirements must confirm to SMART.
- Version Control: Change history tracking, records the changes that affect the requirement. Needed for traceability/ configuration.
Future
Future state diagram.可以用Swim lane diagram implement.
用图流的方式把整个产品的逻辑理顺.
注意swim lane(比user diagram)的好处是不单单是时间顺序,还有各个stakeholder,很清晰.
Mockup
用Wireframes做非常潦草的demo,这是无关排版无关好看的demo.
用于视觉上告知:我们的产品works like this.
做完project后为图书馆第一次开了会.
很紧张,但把树哥在stakeholder的占重要比中划分了一下,就明白了“啊这些是要跟树哥说的,这些才是要跟其他人沟通的”.
很有启发!不单单是做一个business plan的,更像是如何做plan可以参考的过程.