我们专栏里大部分的内容都是在教大家怎么做需求分析，需求分析是一个比较抽象化的东西，如果你在工作中也恰好负责过项目的研发管理，肯定会发愁怎么做好质量保证，怎么让你们的小团队以及合作的上下游团队能够通过一个具象化的东西来对其各自对需求的理解，建立共识，避免事到临头出现各种“我以为你xxx”这类的细节疏忽。
那么这里就有一个问题，假如我接到的项目，需求分析、技术评审做的面面俱到，开发流程也很规范，那这个项目就一定会成功吗？
我想大家一定知道答案是否定的，我们从接到需求了就闷头开始写代码，进化成了做详尽的需求分析，各种图该画的画、技术评审该搞的搞，为什么项目还做不好呢？
今天我们就额外聊一期这个话题，因为前面的内容都是一些公式化的东西，大家看完再结合自己平时对业务和技术的理解肯定是会在自己的技能上有提高的。
这期的内容跟你自身或者团队每个人的硬技能没太大关系，而是跟项目管理、涉众识别、利益分析有一定关系，当然我在这方面也不是专家，只是看到了一些表象背后的东西跟大家一起聊一些。
本节还会用一张图总结项目从立项到写代码实施前所有的隐形工作，让大家对项目的评估和风险把控变得更精准，未来在接到项目、需要你独立负责时，可以直接拿出来参考。
还未订阅的朋友可以看下专栏中的精品内容，通过公众号或者扫码都可以订阅阅读，公众号和小报童两个渠道同步更新。
闲话不多说，在我们接到项目的时候，假如你是一个负责项目管理的人，或者是你是一个开发组的组长，那么我建议你在接到需求的时候，不要着急开始我们之前介绍的业务需求分析的工作，而是先做战略分析和需要分析。
战略分析
这个环节主要是了解需求的背景、公司为什么做这个项目，以及公司对这个项目上的期待是什么？具体点来说以下哪个是项目的初衷
赚钱（解决用系统人的问题，提高效率也算赚钱） 积累业务和技术为后续产品打好基础 积累客户关系 政治任务，必须要做
关于这部分信息和项目的背景一般只有公司中层才能了解得比较清楚，但是只要你花一点时间基本上是能从产品经理或者其他职能的人那里了解到这部分消息。 作为执行层，很多时候当我们觉得这个项目赚不了钱或者对技术和业务的积累没有多大帮助的时候会觉得项目很扯淡，因为有的需求确实在明面上很看着很荒谬，人在不认可自己做的工作的价值时会非常难受，所以我建议你不管是不是身担项目管理的职责，都尝试着去分析分析。
需要分析
这部分对做项目管理的人就很重要了，需求是给我们的任务，而需要则指的是一个业务在持续发展中涌现出来的亟待解决的问题。这部分的分析可以从以下几方面入手。
分析项目的目标：总体要达到什么目标，解决什么问题 找出关键涉众，有的资料中也叫干系人 分析涉众的利益和关注的问题： 有的人是项目的直接受益者，比如使用系统的业务人员，对项目关注度高、配合度高。
