做了好多项目，这次想聊一下怎么分析项目，算是自己的拙见，也是自己的一点总结吧。
研发工程师的工作就是不断的处理业务需求，但PM提的需求应该如何来评判、分析呢？我觉得可以从三个方面来考虑，分别是What、Why、How。
What
主要分析做的是什么？理解项目，是一切的前提和基础。只有深刻的理解项目，项目才有可能做好。
来源
不知道大家曾经有没有过这个想法：这些PM从哪里搞了这么多项目？
想明白这一点，有可能辨别出PM的能力、公司的管理能力。
产品
很多需求来自PM自己的观察和规划。这和PM能力强相关。
合作过一些PM，他们对业务了如指掌，对业务如何发展成竹在胸。年初便规划好全年或未来三年的计划，制定好发展骨架。每个项目都是对骨架进行填充。这会让研发同学有目标、有成就感，觉得未来可期。
还有一些PM会仔细分析数据、经常体验自己的产品，通过这种方式发现很多问题，然后对产品进行优化。
业务
运营、客服等部门往往处于一线，直接对接用户。他们能收集大量用户反馈，这些反馈会输送给PM。
还有一部分来自于产品上自带的反馈入口。
收到这些信息后，PM需要想应对之法。这些反馈往往是用户的痛点，解决后能大幅提升用户体验。
反馈的内容很考验PM的抽象能力，需要判断是否真的是痛点，选择合适的解决方案。万万不能听到啥就做啥，否则很可能导致团队努力做了一年，都不明白自己到底完成了什么目标。
老板
还有一部分需求直接来自于老板。
虽然我觉得老板应该把控大方向，不应该直接推动项目，但总有一些老板选择主动下场，让产品推进某个项目。
对于这种操作我不是很认同，倒不是说推进的这个项目有问题，只不过这种操作弊大于利。
一是老板推某个项目，有时候真的可能是脑子一热，根本没有调查，自己觉得不错就让执行了。
二是很多公司向上管理，即使项目收益低，但因为是老板的需求，便耗费大量人力去做，没有把人力放到真正重要的地方。记得以前PM让做一个项目，内容极其复杂，需多部门配合，所有人都怀疑产出，但因为是老板推动的，大家只能做。最终效果呢？这个项目需要经多长时间才能覆盖人力成本，我都不好意思说！
公司的前进方向，老板和PM是对齐的。如果对齐制度不好，就修改对齐制度，如果PM理解得了、执行的好就留，如果PM理解不了、执行不好就换。
内容
产品提出的需求，应该包含以下元素：BRD、PRD、UE、UI
BRD：即商业需求文档，是基于商业目标或价值所描述的产品需求内容文档，其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据
PRD：产品需求文档，是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述
UE or UX：User Experience 用户体验，PM用UE讲解需求，使研发、测试等同学有直观感受
UI：User Interface 用户界面，主要给前端同学开发使用
一般通过这四个元素，研发人员能够理解这个项目需要做成什么样子。防止出现下方展示的情况：
最好
最好提前规划好的项目与一些优化、迭代项目并行，而且前者应该占的比例更大一些。这样才能建造出稳固的城堡。这也是为什么我在对产品经理的一些思考里认为产品经理重要的原因。
Why
了解要做什么之后，需要思考一些问题。这些问题能够让我们发现项目的核心点，能够脱离于项目看项目。
为什么要做这个项目？
这个项目是为了业务发展、为了解决用户痛点、为了向上管理？很多研发同学觉得这与自己无关，其实是有关的。
对于一线研发同学来说，想明白为什么要做这个项目，就能明白项目解决的核心问题是什么。只有分析出主要矛盾和次要矛盾，真正执行时才能有的放矢。
对于技术经理，需要判断项目在当前阶段做是否合适，是否有更重要的事情要做。
其实产品有一个重要的职责就是宣贯项目的重要性，如同打仗之前需要先申明行为的正义性。
项目属于哪个模块？
系统一般都会有架构图，需要判断项目属于架构里的哪一部分。
例如电商一般有交易、订单、用户等模块，做的项目属于哪一部分？还是说这个项目为系统扩展出新的模块。
通过这个问题，我们能够更好的把握系统架构的现状。
是否有其它方案？
明白项目核心点后，就要想想，PM的方案是否流畅，是否存在更加合理的方案。这也是为什么一直在说要了解项目核心点，因为这是目标，目标只有一个，方案却能有很多。条条大路通罗马。
PM提供的方案，在解决核心问题上是否是最优的吗？是否有更简单的方案能够满足要求？
这里提一点，尽量不要总是用小技巧完成需求，一定要把握好度。否则可能产生缝缝补补又三年的效果，衣服虽然能穿，但是会一片一片的。系统终究是一个统一的整体。
项目有什么收益？
项目能带来多大收益？可以通过哪些数据进行判断？
这些问题一定要在PM提出需求的时候进行询问，可以检验PM是否真的考虑过这个问题。对于IT类工作而言，数据是检验真理的唯一标准。达成数据也是相关参与同学的最终的目标。
当然，有很多项目，在前期无法给出具体的收益，我们也不能因为缺收益数据就不开发项目。
研发和产品需要有数据驱动的共识。 虽然PM无法给出具体收益，但需要用哪些数据来查看收益是一定要提供的。
需要做的大而全吗？
根据项目大小、收益，思考功能是否要做大而全，能否将部分内容砍掉，先上线核心点，其它慢慢迭代。
项目快速发展时期，应该采取小步快跑的方式，先满足最核心需求，即用20%时间完成80%的核心功能。这样也能快速调整方向，数据不符合预期迅速改变打法。
项目到达稳定期后，可以用80%的时间提升20%的体验。
这一切都是在理解了项目、知道项目要解决的核心问题、估计好项目产出之后，才能做出的决定。
项目最终会发展成什么样？
这是对未来的思考。当前项目并不是最终版本，那最终形态会是怎样的？
了解这一点，对设计当前系统、今后设计相关系统，能做出更高质量的判断。
How
经过What和Why的思考后，How对研发同学而言更容易一些。
怎么做可以分两部分来讨论：
一部分是宏观上的项目管理，可以看项目流程管理
一个是当前项目需要怎么设计。磨刀不误砍柴工，项目做得好，一定要有好的技术方案。
技术方案
完成技术方案，邀请相关同学对技术方案进行详评，能够确保大家达成一致，实现了从需求层面到技术层面的统一。一份好的技术方案模板，能够帮我们缕清很多细节点。
对于技术方案中的内容，每一点都需要确认搞明白，不能想当然。
在设计文档的时候，个人喜欢使用数据驱动的方法，先将db设计好，然后在此基础上思考每一个接口、每一个状态如何变更。同时思考并发、异常等情况。
这里提供一份模板供大家参考：
一、项目背景
二、核心需求点描述
(简要的两三句话，描述几个最核心的需求点；描述清楚满足了哪些用户、在哪些场景下的哪些需求)
三、技术方案
-
架构图&流程图
-
异常流程考虑(选填)
例如：对关键环节，超时、下游调用返回错误等如何处理。用户提示文案会怎样、是否有重试和补偿等
-
存储设计(cache,db,es等) 【必填】
（如果有数据库等重要存储新增、变更，需把相关设计进行说明）
-
兼容性评估【必填】
-
接口安全性评估
-
性能&容量评估
-
API定义【必填】
-
建议QA要测试的点(选填)
四、异常情况下业务影响的评估
评估当此系统稳定性、逻辑、对外返回的数据出现异常时，对B/C端核心功能的影响，并评估在其他系统的监控是否完备
五、对账&资损点&监控评估
六、上线方案
七、小流量方案&计划
八、线上观察&监控内容
九、回滚方案
十、评审结果
十一、项目总结
总结在整个项目过程中值得分享的问题，可以是这么几个方面：1. 方案设计和需求方面思考；2. 开发和上线过程中遇到棘手问题；3.思考项目流程存在问题；4.其他任何可以分享的经验
总结
项目分析不但是技术问题，也是管理问题。希望大家不要只沉浸在做项目中，要跳出项目，从更高处理解项目，会有更多的收获。
资料
- UI、UE和UX三者之间的区别？
最后
大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）
我的个人博客为：https://shidawuhen.github.io/
往期文章回顾：
扫一扫
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
