项目的坎坷一生（上）

之前的博客，聊了一些需求的事儿，从需求采集、分析、筛选到产出物————各类文档等等。。。

今天，就说说关于项目的一些事儿。。。

 

一、从产品到项目

项目的定义：只会进行一次，包含多项互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。

产品是解决某个问题的东西，项目是一个过程。

1、做产品VS做项目

①从生命周期角度区别

做产品的生命周期相对较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程；

项目有特定的目标，生命周期短，通常在项目开始以前就有明确的起止时间，通过验收则表示项目生命周期完成；

②从具体要做的事区别

做产品的过程会有很多探索的过程，随着各种内外信息的变化，需要不断修正进程，不断创新；

项目在开始就已经有明确的目标，更注重计划与控制，项目的过程很像执行一个任务；

共同点：协调沟通，对未来一段时间做出计划等因素；

③从产出物的角度区别

产品可以是批量生产或提供给大量用户使用的，相对通用，通常考虑用有限的资源去满足更多的、更大利益回报的需求；

项目只进行一次，意味着每次都是定制的、个性化的，通常为了满足特定需求，产出物也比较个性化；

④产品和项目的关联性

“做产品”的过程，正是通过做一个又一个项目实现的，但并不是简单的项目累加。在产品渐渐满足目标用户群体的通用需求后，继续做下去会使产品变为一个项目的集合体，臃肿不堪；

这时候需要细分市场，产品可以升级为“产品线”，按不同市场推出不同产品。表现形式可称为版本、模块、增值服务等，其本质是通过合理的安排项目来实现产品的规划。

 

2、产品经理VS项目经理

产品经理（product manager）和项目经理（project manager），工作都需要跨团队，工作范围也有重叠，都是简称PM，那么他们的区别又是什么？

产品经理：靠想。产品经理是做正确的事情，其所领导的产品是否符合市场的需求，是否能给公司带来利润。因此产品经理必须能规划整个产品的架构和发展路线，能确定产品的定位和受众，

         能预计产品真正的价值和效益。

项目经理：靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。即使项目本身不能真正盈利，那往往是产品规划出现了失误。

用《人人都是产品经理》作者苏杰的话说，就是：一个内部驱动，一个外部驱动。

对产品经理来说，最重要的是执行力与创造力，产品经理决定做不做、做什么、做多少，保证方向正确。他的想法是“我要把它实现！”

对项目经理来说，最重要的是执行力与控制力，项目经理决定怎么做、谁来做、何时做，保证方法得当。他的想法是“我要把它完成！”

 

二、一切从项目启动开始

1、团队组建

项目启动后，第一件事就是“团队组建”。通常在项目中，会有如下几种角色：

PD：负责这个项目的需求，其中的某一个可能兼任项目经理；

开发leader及其团队：负责开发的时间计划与任务分配，并全程掌控设计、编码直至上线的过程；

测试leader及其团队：负责测试相关的任务，比如需求分析，测试计划、方案的设计，工作安排，质量模型等工作；

UE（用户体验团队）：对于互联网产品来说，负责产品给用户的展现，比如交互效果、视觉效果等；

其他角色：团队的人员角色会随着项目的进行不断微调，无须一开始就把人凑齐，只要关键几个人到位就可以继续做下面的事情。

 

2、项目计划

做项目计划，首先要做的第一件事，也是最重要的事情，就是再次评估工作量，并推算出“工期”。

最开始的需求阶段，已经做过一次工作量初评，但随着项目的展开，PRD相对来说也会进行细化，这时候开发和测试进行工作量评估，会更加准确；

还有一点，初评是leader等人进行评估的，未考虑谁来做什么。而项目正式开展后，需要根据每个工程师的特点。擅长技术领域等因素进行工作分配，把工作任务分配给最合适的人。

然后开发测试leader把各个工程师的工作量汇总，推算出工期；当然也要考虑到各个项目任务的依赖关系，留出一定的buffer。

PS：高手要调入项目的关键路径（影响项目完成时间的关键任务）。

 

3、沟通必不可少

在项目的整个生命周期中，无时不刻都需要沟通，由于沟通问题导致的项目问题，日常工作中已经出现很多例子了。比如：权利责任不明确，出工不出力，对需求理解的不一致，遗漏

了项目相关部门、责任方等很多情况，所以很有必要在一开始就约定好项目的沟通方式。

PS：沟通方式只是一种手段，而不是目的；不管选用何种沟通方式，结果都是为了项目成功。常见的沟通方式有如下几种，仅供参考：

项目晨会：一般不超过15分钟，参与人员主要有PD、开发、测试，简述昨天做了什么，遇到什么问题，哪里需要辅助解决，今天预计工作是什么等等内容；

项目日报：一般以测试介入后开始，主要内容为今日完成工作，未完成工作，遇到问题及如何解决等内容；

项目周报：同日报类型相似，只是内容上更全面，以及方便随时调整工期和计划；

评审会：需求评审、设计评审、用例评审以及系统测试完成后的功能评审等；

项目变更通知：项目发生变更或需求变更等较大的变更，需要及时通知项目所有干系人；

发布上线通知：项目发布前以及发布成功后需要给全体干系人发布公告通知；

 

4、随时做到心中有数

其实就是项目管理，做项目的目标无非就是多快好省：范围大、时间段、品质高、资源省。但要完全做到这几点，难度是地狱级别的，因为实际的制约因素太多。

综合而言，在尽量保证品质的前提下，在时间、人力物力、项目范围三点上做平衡和取舍。

在了解项目背景、目的、目标等前提下，明确任务后，首先分解任务，即著名的WBS（Work Breakdowm Structure：工作分解结构）。

其实每个项目，都没有固定的流程，但每个项目的流程管理，都有一定的共通性，多实践，然后总结经验，渐渐就有了自己的一套行之有效的流程，不过还是要灵活运用。

 

三、需求？哦不，文档！

项目开始后，不仅开发要做代码开发，PD也需要开发，这个阶段，PD的内容是“需求开发”，即大家俗称的“写文档”。

1、PD最常写的几类文档

BRD：Business Requirements Document：商业需求文档。这是产品生命周期最早的文档，内容涉及市场分析、销售策略、盈利预测等，通常给BOSS看的，短小精炼，没太多细节；

MRD：Market Requirements Document：市场需求文档。内容包括可行性分析、商业目的、功能/非功能需求分块、优先级等；其产出物一般有Feature List、业务逻辑图等；

     这是从商业目标到技术实现的关键转化文档。

PRD：Product Requirements Document：产品需求文档。它是对产品功能的进一步细化，是PD写的最多的文档，也就是上面所说的“需求开发”的过程；

     其主要包含整天说明、用例文档、产品Demo等，会对产品功能做具体描述。

FSD：功能详细说明。比较像常说的用例文档，主要包含产品界面、业务逻辑的细节等内容；与此同时，硬件设计、数据库设计、表结构设计等工作，也要由技术人员开始编写了。

PS：以上几种文档其实都有重合点，大多公司没有这么严格的文档要求，灵活运用即可。记住：写文档也是手段，而不是目的，最终结果，还是——-要把项目做成功！

△关于PRD：

通常来说，一个项目会有一到多份PRD，每个PRD会包含逻辑相关的若干功能点，主要的构成元素如下：

修订历史：包含每次修订的日期、版本号、说明和作者，以便于日后追溯；

项目概述：包含项目的背景、意义、目的等，描述业务领域知识，以便于读者可以明白这个项目的一些关键点，形成项目思维框架；

功能范围：对本PRD涉及的角色、系统做出简单说明；

词汇表：对本PRD涉及的专有词汇、术语等做出说明；

非功能需求：如性能、数据监控等需求；

其他：其他任何需要说明的内容都可以写在里面；

上面的部分是总体说明，之后是用例文档部分，其中包含对PRD中所有用例的说明，各种类图、状态图、流程图，以及每个需求点的详细说明等。

 

2、UML、Demo和概要详细设计

了解产品的童鞋应该都知道，做产品需要产出很多的文档，其中包括各种用例，说明文档，图表等，而UML大多是用来将需求转化为图的一种工具。

UML：Unified Modeling Language，统一建模语言，它试图将软件工程过程规范化；

     利用UML，可以产出很多图，比如类图、用例图、状态图（系统里的实体转换）、时序图、活动图（比较接近我们所谓的“流程图”）等很多图形说明文档；

Demo：即所谓的产品原型图、演示版的东西；

几种常用的图形绘制工具：Visio、PPT、Axure、Dreamwever、Xmind等工具；

概要设计和详细设计：举个例子，比如一个登陆输入框，长度限制在多少个字符，允许最多输入几个汉字、敏感字、非法字符、是否必填、对齐等，就是比较详细的设计；

                 当然，一般的设计都是产品从业务角度描述，而工程师负责技术上的实现和描述等；

 

3、需求评审

当产品的产出物————需求文档给到后，工程师一般并不直接拿来用，为了保证产品质量，还需要做这件事：需求评审！！！

所谓需求评审，一般都是项目中关键的小团队坐在一起，一方讲，另外几方听，统一认识、消除误解，及时发现偏差以及随时改正的过程；

在互联网行业，一般参与需求评审的主要是PD、开发以及测试人员，所以有了需求评审、设计评审、测试评审，按照项目阶段，大概顺序为下：

需求评审：即PRD评审、UC评审、Demo评审的总称。一般在需求相应部分完成后进行，PD将PRD说给开发、测试听；

设计评审：在概要设计和详细设计完成后进行，由开发工程师把对需求的理解以设计文档的形式说给PD、测试听；

测试评审：也是俗称的用例评审，是在测试用例编写完成，测试开始执行之前，由测试工程师把对需求的理解说给PD、开发听；

每种评审一般都会进行多轮，没问题的快速通过，小问题当场确认，大问题带回去重新思考解决，循环往复。。。