跨越：程序人生-产品人生

作为程序员，当要做一个项目时候，我们最关心的是这个项目有哪些功能，然后考虑每个功能如何实现；
而作为产品经理，当要做一个项目时候，我们看重这个项目的业务场景是什么，解决用户什么问题。

有一种方法叫“5W1H”法，即分析问题时候思考下： 
why：为什么做
when：什么时候去做
who：谁去做
what：做的目的是什么
where：从哪里入手
how：怎么做

作为技术人员时，遇到这样的需求，你需要考虑的是How，如何提供给顾客四分之一英寸的钻头，钻头要多长多锋利等等。
而作为产品，你需要考虑的则是Why，你要思考或是询问为何顾客需要一个钻头呢，自然不是回家摆着，而一定是他需要打一个洞。
那么再问，为何要一个洞，可能答案是挂一副画，装饰一个墙面等等。

项目启动

任何产品启动都有其启动的源头，即其愿景。
了解愿景的方式有很多，可能是招标文件，可能是相关业务调研，也可能是公司的商业战略。
具体的方式跟行业或者产品类型相关，但在项目启动时候一定要搞清楚这个问题：
为什么要开发这个系统？我们用这个系统能解决什么问题？
接下来是进行涉众分析，搞清楚这个问题：
谁关心这个系统？会涉及到他的什么利益？

然后就是投入和风险：
这个系统愿意花多少钱？允许多少时间？
客户参与度如何？有没有度量方式？技术上是否存在风险？是否有重要人物反对？以前是否被取消过？
在项目启动前对项目进行提前摸底，才能顺利进行接下来的工作，避免返工以及尽可能避免风险。

需求分析

在项目启动时候我们了解了项目的愿景后就可以开始梳理业务流程，进行需求调研了。
业务流程是和现实挂钩，客观存在的，进行业务流程梳理时候需要抛开计算机的概念，这样才能彻底搞清楚客户的业务。
根据项目的愿景我们可以把项目按照法律法规、岗位手册、职务说明等或者直接的客户访谈拆分为一个个的业务，
并确定每个业务的范围、目标、流程和涉众期望，从而获取业务用例。
然后用文字、活动图、时序图等方式将其表示出来，即形成一个个业务模型。

需求调研是一件很繁琐的事，其难点在于用户的需求难捕获、易变。这时候我们可以把自己想想成用户，然后问这几个问题：
对系统有什么期望？打算在这个系统里做些什么事情？
做这件事的目的是什么？做完这件事希望有一个什么样的结果？
当每个需求我们自己都能回答好这几个问题时候，自然做出来的业务模型就是合理可用的模型了。

系统设计

根据我们需求分析的结果，就可以进行系统设计了。
将业务用例抽象为系统用例，即考虑如何用系统实现这个业务，为完成这个业务我需要哪些功能？
确定完功能以后，接下来考虑的是交互设计和视觉设计。
交互设计即系统如何和用户进行交互，用户如何一步步操作系统以完成对应业务；
视觉设计即系统的UI效果。

有的人可能觉得UI效果交给美工就行了，但我觉得产品经理一定要参与视觉设计，
首先优秀的视觉效果一定是和业务挂钩的，
比如某个按钮图标，其图标内容就应该让客户知道这个按钮大概是做啥的，
或者界面的整体风格配色，也应该是和业务背景挂钩的。
而这些业务和功能，产品经理应该是最熟悉的，所以他也是必须参与的。
当然进行这些设计时候还有很多原则，比如主页面一定要清晰、尽量避免繁琐的操作，尽量将数据可视化展示等。

其他注意事项

产品经理作为承接用户和技术人员角色，沟通能力是非常关键的；
产品经理需要控制整个产品的进度，包括事情的优先级和整体资源的协调；
产品经理一定要有责任心，敢于担当，敢于背锅；
产品经理要和各个部门打交道，所以最好培养出良好的人际关系。

 

本人来自其他文章摘录，如有雷同，请告知。