理论好比是教人如何在地图上规划一条路，而实践则好比是要在现实中一步一个脚印地走完这条路。虽然从地图上也能看到山川河流的标记，但是和实际的跋山涉水、翻山越岭相比，还是有天壤之别。不仅地面上的荆棘丛生在地图上看不到，而且突然从山上滑落的巨石更是制定计划时意料不到的。理论和实践之间的这个距离，是成为一名成熟的开发经理 所必须跨越也是最难跨越的鸿沟。
工程延期、Bug丛生、沟通冗长、人心浮动，这些现象可能是因为开发经理个人管理能力或经验不足，也可能是整个细分行业不够成熟，没有形成方法论，造成各种混乱。其实这种现象在全球IT行业都是普遍存在的，需要大家一起透彻地总结、分析、实践。
软件工程是一门综合学科，因此软件工程师的培养本身就需要大量的计算机语言和计算机知识，还有相关的数学、物理、电子电路等知识，门槛很高。而想要对软件和计算机之外的行业业务实现模拟，软件工程师还要对该业务所在行业的专业知识进行一定的积累，并要跨越听得懂和能执行两个阶段，然后才能够用另外一种语言，也就是计算机语言表达出来。这是一个相当高的要求。
本章主要介绍和解决以下问题，这些也是全书的基础：
·开发经理的工作内容和个人品质。
·产品开发过程全管理细节。
·产品开发过程管理需要注意的事项和细节。
3.1
开发经理及研发体系介绍
无论是传统企业，还是互联网企业，软件的开发生命周期基本上都包含以下几个关键的活动：
·确定业务需求
·编码
·测试
·上线
这些活动按顺序发生，每一个活动都是下一个活动启动的前提，而且必须严格按照时间顺序推进，才能最终得到结果，这是一个典型的生命周期过程。不同的活动，从项目启动开始，随着时间的积累，直到软件上线结束。当业务发生了变化之后，如果这个软件需要修改，会再次经历一个完整的开发生命周期。和上一个开发生命周期的区别在于，本次生命周期的起点是上一次开发生命周期的终点，也就是说，每一个开发生命周期本身也是按照时间顺序排列的，这些开发生命周期组成了软件的生命周期。
理解了软件的生命周期后，管理人员要学会用科学的工作方法来管理软件开发生命周期，而不是僵化地照搬流程。流程的作用是规范开发过程，你必须理解后才能使用。
绝大多数IT公司，无论是软件外包公司还是产品研发公司，都会按照行业划分事业部，而项目组是事业部最基本的业务运作单位，各事业部内设专职的开发经理，开发经理对项目（产品开发）的全过程负责，因此他是公司最重要的基层管理角色之一。大多数公司的产品开发过程又会作为一个项目来进行运作和管理，所以我们这里就按照开发经理制，讲讲开发经理（产品开发经理）的职责及其所需具备的品质。
3.1.1 开胃故事
记得读书的时候听过一个故事，说某市公务员面试题是这样的：
请你对以下4件事情进行排序，说清楚具体应该按照怎么样的顺序执行。
（1）有一位你的老上级到北京疗养，明天约好了见面；
（2）明天上午10：00需要会见重要的外商；
（3）下属今天送到了医院，正在动手术；
（4）明天需要完成部门年度工作总结。
我们不去关心这个考题的真伪，当时报纸上说的正确的处理方式是：
（1）早上6点起床，7点半到达老上级住所，陪同吃早饭；
（2）吃早饭时向老上级汇报今天需要会见重要外商，请老上级谅解，不能多陪；
（3）老上级一定支持你的工作，继而转去会场；
（4）去会场途中打电话，安排助手去医院看望手术后的下属并慰问家属；
（5）会见外商结束后，立即赶回单位，组织人手编写年度总结，并通知可能晚上需要加班。
3.1.2 什么是软件
1.软件发展历史
从冯·诺依曼结构开始，程序逻辑开始脱离硬件，采用二进制编码。软硬件两者结合，一个可编程的大脑就出现了，这也是为什么我们把计算机叫作电脑的原因。在硬件上运行的程序就是软件，用来控制硬件的行为。通过编写软件，可以制造出各种各样具备不同能力的“人”，而这所花费的时间会比培训一个真正的人少很多。
随着半导体技术的进步，硬件的成本越来越低，但性能越来越高。摩尔定律：当价格不变时，集成电路上可容纳的元器件数目，约每隔18～24个月增加一倍，性能提升一倍。软件方面，为了简化难度，开始采用汇编语言，进而出现了类似于人类语言的高级语言，比如C/C++/Java等，这使得人类可以用这些高级语言，把人类的知识传递给计算机，并训练计算机掌握某种技能。
软件的发展历史，可以说是用机器模拟人的进一步发展。在计算机出现前，人们用机器来代替人进行生产，也就是所谓的机械化生产。软件的出现，也许很多人没有意识到，包括这个历史过程中的参与者，实际上是人类有意无意地在计算机上模拟自己这种原始动机的体现。人们对于时间的恐惧，导致人们不断地去为延长自身生命而努力，提升自己的生产力是其中的一种途径。软件可以让人们节省大量的工作时间，从而有更充分的时间去关注并推进自身的核心生命周期。
软件模拟出了一个虚拟的世界，人们在自己创造的虚拟世界中互相联系，形成了一个虚拟的社会，从而给人类带来了极大的便利。换句话说，软件是人类实际需求的虚拟化实现，通过软件让机器完成本应由人类完成的工作，这样人类可以做更多有创造性的事情，可以更多地休息、享乐。
2.软件的作用
软件的主要目的就是把人类生活的非核心生命周期软件化、虚拟化，以提供更低的成本和更高效率的新生活，让核心生命周期的运行能够更加容易，让非核心生命周期的处理更少地占用人类的时间，变相地延长人类生命。这正是人工智能的可怕之处，因为人工智能强大之后会存在替代人类的核心生命周期的可能。
企业在采用软件之前，需要先搞清楚软件可以帮助企业做什么。软件的出现，确实可以降低业务的成本。但是在没有软件的情况下，业务也是一样能跑的。如果只是为了跟风而采用软件，说不定反而提高了企业的经营成本。想想企业引入的ERP系统，真正能够帮助企业的成功案例有多少？我们经常说软件或技术是业务的使能者（Enabler），实际就是把业务的成本从很高降到了很低的程度而已，并不是有了什么新的业务。另外，软件也不是降低业务成本的唯一方式。
3.软件生命周期
软件的生命周期可以拆分为软件开发生命周期和软件运行生命周期。软件的开发生命周期结束后，生成的是软件，紧接着软件运行生命周期就开始了。一个完整的软件开发生命周期推进的过程，一般称为软件的研发。执行软件开发生命周期的人员，称为软件研发人员。参与一个软件的所有研发的人员的集合，一般称为软件研发团队。
软件的出现使得机器的生产生命周期产生了分工，形成了硬件生产生命周期和软件生产生命周期两种形式。
人们对世界的访问生命周期发生了切分，形成了软件的访问生命周期，从而打破了物理时空的限制。对时空限制的突破，极大地提高了生产力，人们不再需要花费大量精力来跨越时空的限制，只需很短的时间就能够做到更多的事情，从而完成更多的生命周期。
3.1.3 什么是开发经理
对很多从事技术工作的朋友来说，开发经理不仅是个“光环笼罩”的职位，也是走向管理的一条“捷径”。但是，“捷径”并不代表最快，更不代表很容易。开发经理更像是个专业岗位，需要依靠领导力来解决和激励团队，靠沟通和协调推进项目，甚至需要一定的政治和文化意识才能获得支持。这些软能力很难通过理论教导获取，更多的是要通过实践、经验分享方式获取。
写在前面：无论多难，都要记住一点，只要别人不赶你走，你就厚着脸皮待下去，这样你才有可能熬到项目成功。
开发经理职务描述
开发经理是公司委派的负责实现产品开发目标的个人，是公司授权的产品开发负责人，是产品开发的直接组织者和领导者。
开发经理的职责
1）对产品开发全过程进行组织和管理，按预期交付产品开发的成果；
2）管理产品开发团队，为成员提供技术和业务上的支撑，使之高效而愉快地工作，并获得最满意的工作体验；
3）管理对外关系，以取得外部对交付成果及过程的最满意评价。
也就是说，一个合格的开发经理必须同时做到“按预期交付成果”“让客户满意”“让员工满意”。
开发经理的主要任务
1）与产品经理交流。IT项目/产品一般比较复杂，实际交付或上线风险较大，需要在项目启动前约定好工作范围、进度计划，要估算成本和人力资源。开发经理需要近距离地了解需求、资源等约束，这样制定的项目实施方案才会切实可行。与产品经理交流不仅有助于开发经理深入了解客户需求，也可以帮助产品经理了解开发经理的能力。
2）负责产品开发交付。明确产品开发立项之后，开发经理负责围绕预期目标，遵循确定的规范执行项目。开发经理不仅要制定思路清晰、考虑周密的计划，还要调整资源、委派任务，推进计划的执行。执行过程中，还要及时处理出现的问题，定期向相关人员汇报进展，保证在规定的时间和预算内交付项目进展。
3）完成产品开发收尾。完成交付成果之后，要将成果移交相关部门，确保相关部门可以稳定地使用系统。然后，将后续服务移交给服务部门，确保客户得到后续的服务保障。开发经理交付的成果直接决定客户满意度，影响客户是否愿意付款，因此公司还可能会要求开发经理（如果同时身兼项目经理的情况下）配合交付部门完成收款工作。
4）管理干系人的关系。一个IT项目可能涉及投资方、客户、分包单位、合作伙伴，甚至可能包括政府、社会等各方面的关系，面对的客户也不只是一个人，而是一个群体。开发经理作为各方的桥梁和纽带，要随时处理各方信息，保持密切沟通，解决矛盾冲突，只有这样才能让客户满意。
5）管理项目团队。由于项目团队的临时性（有可能开发经理并不是团队的实际负责人，只是普通一员，在该项目中被选为开发经理，职级上和团队成员平级），开发经理需要花费很大的精力寻找合适的资源，优化资源配置，建立合理的组织结构，确定清晰的职责分工。项目过程中还需要通过各种措施进行团队建设，打造高效团队。
从这些工作任务的性质来看，开发经理是项目的推动者、技术的输出者，也是关系的协调者。总的来说，开发经理往往是决定一个项目成败的关键人物，要求其职业素养高、技术能力强、综合能力强、职责范围广。也正是因为要求太高，所以很多公司将开发经理、项目经理区分开，即项目经理可以不用管技术，专心做协调、进度把控工作。
题外话：关于项目经理职位，想要走纯项目经理路线的同仁注意了，这是一条无悔路，后面会遇到的困难无数，如果半路发现实际情况和最初的想象有很多差距，觉得自己不适合做项目经理，那问题可就大了。因为，这不仅对外部部门和团队会造成非常大的不利影响，对自己也非常不利，毕竟技术的发展实在是太快了，再想退回到技术路线的难度很大。我们这里还是主要讲开发经理。
3.1.4 开发经理素质
作为开发经理，有几个基本素质是必须具备且非常重要的：
1）领导力。领导力是指通过领导他人来完成工作的能力。开发经理虽然是项目领导核心，但需要依赖团队完成任务。由于项目组的动态性和临时性，在一些公司，开发经理对于团队成员并不具备完全的管理权力，所以更需要将一组成员凝聚成一个团队，激发和影响他人为了共同的目标而努力工作。开发经理和大家是平等的，很多时候还要走在别人的前面。你不仅要自己先做到要求别人做到的事，而且要知道“下一步”应该干什么，下一个目标在哪里。开发经理的口号应该是“跟我冲”，而不是“给我上”。
2）责任心。项目执行过程中会遇到很多困难，经常会超出预期。这个时候，能够帮助开发经理挺下去的可能只有“责任心”了。具备强烈责任心的人，出于对承诺的负责，会倾尽全力达成目标而不言放弃，因此也是可靠、可信的人。这样的人，公司、客户和团队才会对其放心，才会全力支持。具有强烈责任心的人，也会非常注重细节，能主动发现问题，会时不时地在脑子中模拟一件事的执行过程，设想各种意外情况，考虑如何应对。这样的人比别人看得远，看得透。
3）积极主动。积极主动的人最大的特点是不会经常抱怨，因为抱怨本身是没有用的。开发经理是项目组的“主心骨”，如果这个人很容易慌乱，那这个项目也会混乱。开发经理必须时刻保持好的心态，如果团队成员始终看到一个信心满满、镇定自若的开发经理，大家也会充满信心。如果团队总是看到一个整天愁眉苦脸、满腹牢骚的开发经理，大家可能担心他随时崩溃，自然自己也不会积极主动了。
4）抗压能力。项目中会出现各种突发事件，有时候需要忍受极大的压力。有抗压能力的人在困难来临的时候仍能镇定自若，仍能冷静思考，即使在无能为力的时候，也能保持“风度”和“幽默感”，从而稳定军心、解决问题。很多技术出身的经理其实不太能承受得住压力，一旦他们被领导骂了或者被施加了压力，他们会直接把火向下传导，不知道在自己这一层控制一下，先调查清楚再发火（最好是不要发火，而用沟通的方式解决问题），这是他们管理团队的一个弱点，需要不断改进，否则会出现团队成员激烈反抗的情况。
3.1.5 软件开发模式介绍
1.瀑布式开发模型
瀑布式开发模型是一种严格按照需求—设计—实施—交付四个阶段进行软件开发的模型，并且在各个阶段结束时要经过严格的评审，只有当能够确认一个阶段的开发成果是正确时才能够进行下一阶段的开发。
瀑布模型的四个阶段中，除了分别完成本阶段所定义的活动之外，都必须进行项目管理、质量保证、配置管理和测试活动，这四个活动的过程贯穿整个瀑布型软件生命周期。
瀑布式开发模式本身是没有问题的。比如在建筑行业，其实就是瀑布式开发模式，在需求做完后进行设计，在设计完成之后，再开工建设。区别在于，建筑行业是对空间切分，而空间是现成的，只需要顺从地球的自然地理环境以及地球的重力等因素，大部分都是可预测、稳定的。建筑设计师本身也是建筑的使用者，对用户的需求感同身受，容易理解。
但软件行业存在不同，软件是用来代替业务人员的，首先需要理解业务人员的工作，才能做出设计。而理解业务人员的工作会存在各种各样的困难，特别是沟通的偏差会导致软件的起点会有问题。软件工程师本身的门槛很高，如果没有一位强有力的技术管理者牵头，很容易出现设计阶段普通程序员闲置的情况，因此软件行业采用瀑布式模型时，会存在大量的浪费，最终的结果也往往不尽如人意，这也是为什么其他开发模式兴起的原因。
2.敏捷开发模型
软件开发的生命周期要允许犯错，因为软件模拟的是人，人与人合作总是会因为沟通等问题犯错的。只有通过亲身体验并操作才能够发现错误，仅仅依靠书面和口头的沟通是无法避免错误的。所以要减少错误，就必须要犯错误，只要犯的错误能够得到快速地反馈和纠正就不会造成问题。而且，犯的错误越多，纠正得越快，就越能够减少线上的问题。要想快速发现和纠正错误，就要做好迭代，而做好迭代就必须确保迭代的生命周期足够短。这就是所谓的“敏捷”，核心就在于快速迭代并迅速反馈。
敏捷软件开发（Agile Software Development）兴起于20世纪90年代中期，最早是为了与传统的瀑布软件开发模式相比较，所以当时称为轻量级方法（Lightweight Method）。二十一世纪初，17位该方法的倡导者建立了敏捷联盟（Agile Alliance），并将该软件开发方法命名为敏捷软件开发过程。
敏捷联盟在成立之初总结了四条基本的价值原则：
·人员交流重于过程与工具（Individuals and Interactions over Process and Tools）；
·软件产品重于长篇大论（Working Software over Comprehensive Documentation）；
·客户协作重于合同谈判（Customer Collaboration Over Contract Negotiation）；
·随机应变重于循规蹈矩（Responding to Change over Following a Plan）。
整个过程中夹杂了很多在敏捷开发确定之前已经出现的软件开发方法，包括极限编程、Scrum、特征驱动开发、测试驱动开发等。这些方法在敏捷软件开发流程的各个阶段都有充分的体现和应用。
例如，Scrum主要着重于项目管理，团队中的项目经理需要在每个客户需求到来的时候制定Sprint的周期，定义每个Sprint的目标、分派任务、进行监督，最后总结得失并开始计划新的Sprint。相反，特征驱动开发和测试驱动开发主要被应用于Sprint周期中，如果项目正处于开发新功能时期，这个阶段主要推行特征驱动开发，所有测试和开发人员都将自己的工作重心放在新的功能上面，从开发和测试两个方面来完成各自的任务。如果项目正处于测试新功能时期，这个阶段需要将工作的重点挪到测试上来，所有的测试和开发人员都密切关注着当前版本的缺陷状况。
3.1.6 常用研发管理体系介绍
不管是敏捷模型还是传统的瀑布开发模型，研发的源头都是需求。需求的好坏，直接决定了开发、测试团队的工作是否存在价值。
前面提过，软件的整个生命周期可以分为软件开发生命周期和软件运行生命周期两种形式。软件开发生命周期的主体是软件开发，软件运行生命周期的主体是软件本身。所以软件运行生命周期才是核心生命周期，因为软件运行生命周期的主体和大的生命周期一致。我们本节主要讨论的是软件开发生命周期，对于这一个阶段，目前有很多种管理方式，我们只简单列举CMMI和RDMS两种。
1.CMMI
CMMI （能力成熟度模型集成）是一种过程改进的方法，可用于指导一个项目、一个单位，或一个企业的过程改进。CMMI是美国国防部委托卡内基梅隆大学软件工程学院开发出来的，是一个针对产品与服务开发的过程改进成熟度模型。它包含开发与维护活动的最佳实践，涵盖产品从起始到交付与维护的生命周期。
CMMI包括3个模型 ：
·开发模型，即CMMI_DEV
·采购模型，即CMMI_ACQ
·服务模型，即CMMI_Service
CMMI成熟度等级如下表所示。
2.RDMS
RDMS（Research and Development Management System，研发管理体系）致力于公司的产品开发并提供最佳的实践及指导方法，适用于公司产品开发全生命周期的管理。研发管理体系框架一般包括概念、定义、设计、实现、验证、移交、维护等多个步骤。
3.2
产品开发过程管理
产品研发生命周期是指创造产品的过程，通常各个阶段按顺序排列且互不交互。完成阶段工作的标志称为里程碑。里程碑包括4个要素：时间点、标志性事件、交付物、关闭条件。到达里程碑后要对项目进行评估，确定是按计划继续执行，还是进行必要的变更和调整。
一般情况下，企业开发软件时会按照基线和定制两块并行方式执行项目开发工作。无论什么公司，都需要遵从一套成熟的产品研发过程体系，才能做出质量较好的产品。因此，如果出现项目较多的情况，应该合理地安排基线和定制之前的里程碑，让基线产品能够尽量多地收集用户的通用型需求，为定制项目进度提供技术支撑，减少定制项目中大量更改代码，甚至新增模块等情况发生。此外，产品研发过程体系也需要随着业务实际实现要求变化，不要拘泥于瀑布方式或敏捷方式，凡事都需要找到契合自己的方式。鞋合不合脚，只有脚知道。
为了有效生成某些重要的可交付成果，在需要特别控制的位置将项目分开，就形成了项目阶段。项目生命周期中的各个阶段通常按顺序排列，但有时可能会存在交互的各项目阶段的集合。因为各个项目阶段的工作重点不同、涉及组织不同、人员技能不同，所以根据实际情况将项目划分成合乎逻辑的一些子集，会有助于管理、规划和控制项目。
我们这里以一个基线产品开发过程为例进行介绍。需要注意的是，在项目执行前要明确各个阶段的目标，制定计划、及时沟通，并确保各个阶段所有成员对项目理解一致。
3.2.1 项目启动会
1.目标
项目启动会的目标是明确该产品开发项目的目标。目标不是孤立存在的，它与计划相辅相成，目标指导计划，计划的有效性影响着目标的达成。所以在执行目标的时候，要考虑清楚自己的行动计划，知道怎么做才能更有效地完成目标，否则，目标不清晰或是过高，都会影响项目的实际结果。
2.准备工作
在项目启动会之前，我们需要和用户沟通并明确用户需求。注意，本书我们更多侧重于产品基线开发，所以一般不和外部用户直接沟通，这里所说的用户更多是公司内部的产品经理。
项目启动会需要说明项目目标、阶段划分、组织结构、管理流程等关键事项，并将这些内容写入PPT（最好是有固定格式和范文，让团队内部或者公司内部共同遵守），注意，这些事项需要达成一致意见。对于关键角色任命，事前也需要听取相关领导和项目主要干系人的意见。
参加项目启动会的人员包括部门高层领导、外部主要干系人，还包括团队资深经理、核心人员。
3.过程及议题
项目启动会一般由开发经理主持，议程如下：
·介绍议程和来宾；
·介绍项目目标、阶段计划、管理方法；
·发布项目的组织结构图；
·确认关键角色及其职责，并作出承诺；
·参会人员针对介绍内容进行提问交流；
·高层领导做项目动员发言，激励和鼓舞士气；
·各个相关部门领导表态支持项目工作。
项目启动会后，会议的内容需要整理成《项目启动会纪要》。纪要中记录了项目的启动过程、项目组成员的承诺、各级领导的明确表态等。这份资料作为项目组的第一份正式公告发布，同时宣布项目正式启动。
意见的统一，是项目成功的关键，项目启动会、项目例会有助于统一项目团队的思路，使团队更为团结，也有助于提高团队士气。
4.经验和教训
启动阶段多方面工作混杂进行，开发经理容易忙乱，这个时候，需要迅速建立组织架构、明确分工，大家分头工作，然后再着手制定后续详细的项目计划。
项目启动会准备阶段，最好请一个有经验的专家一起参与，帮助开发经理落实很多关键环节，也需要组织团队内部进行讨论，确保在项目启动会上能够流利地回答参与领导提出的各种问题，包括技术类、产品类，这样有利于启动会之后各项工作的顺利开展。
项目启动会非常重要，其意义不仅在于宣布项目启动，而且是确认人员到位的关键时间节点。会议邀请涉及部门的高层领导出席和表态，可以让项目后续的推进获得广泛的支持。项目启动会一旦顺利通过，需要立即着手进行产品需求讨论、编写。
3.2.2 用户需求
软件开始开发前需要确定投入与产出的比值，也就是ROI（Return On Investment，投资回报率），一旦确定需要创建，就需要安排一系列的资源来支撑这个软件的生存，这是需求的最原始描述。
为什么既要有用户需求，也要有产品需求？因为两者是有差异的，用户需求由用户提出，对技术一般不描述，只描述产品目标。产品需求是根据用户需求转化而来的技术实现需求，需要针对用户提出的产品目标进行细分，总结出具体的功能点，再针对每一个功能点细分为各种不同的操作流程，对每一个操作流程进行技术化定义。用户需求和产品需求容易产生差异，这是因为虽然大家都在谈需求，但是出发点可能不同，造成了双方关注点和思维方式不同。用户需求关注的是系统如何支持业务流程，背后的需求是“实现业务目标”。技术人员关注的是合理技术方案，背后的需求是“工作量”“实现难度”和“系统性能”。
需求理解不一致
很容易出现的一种情况是，产品经理和技术人员不在一个频道上，所谓的征询意见完全是牵引式问答，你得到的永远是沉默式认同。
此时，整个方案的水平完全取决于讲解者一个人的水平，而对于一个非常复杂的方案，一个人是基本搞不定的，哪怕是非常优秀的产品经理。因为只有讨论才能产生灵感，才能发现自己未曾发现的需求，这就是头脑风暴的优势。
召开产品或者技术方案会议的时候，大家最容易犯的错误就是，自己先绘制了原型图，甚至产品架构图，直接来讲解自己的方案。这是一个完全错误的会议方式，基本上浪费了所有人的时间。离开这个会议室，懂的人懂，不懂的人还是不懂。当不懂的人去执行的时候，就需要摸着石头过河，再局部找你沟通，从而失去了大局观和整体性，也失去了自己思维模式之外的解决方案。于是，二流的产品就这样出现了。建议需求评审会议可以分为三个步骤：会前提供材料，会中讲解、讨论，会后解决疑问、缺陷。
针对这类需求理解不一致的情况，总结如下：
1）开任何会议，一定不要上来就讲解方案，应该先讲解场景。每个场景先讨论背后的需求并定义清楚，这也是软件本身的意义——模拟业务；
2）大家一起讨论，研究这个场景背后的需求是不是最佳场景，能不能删除这个场景，或者是否有其他场景可以代替这个场景同时还能满足背后的需求；
3）如果是需求的最佳场景，再开始讨论这个场景下的产品解决方案；
4）这个时候你打开事先设计好的产品原型图、产品流程图、状态图、用例图，你会发现有很多需要修改，修改之后就是大家一起生成的方案。
3.2.3 产品需求
我们需要弄清楚产品经理或项目需求提出者为什么要做这个项目，这是最本质的业务需求分析。需求分析确定的产品需求，都是从业务需求推导出来的，都必须为业务需求服务。
1.产品需求编写
产品需求一般包括产品需求规格说明书和产品需求矩阵。
产品需求矩阵一般按照子系统、功能集、执行单元的结构列出所有的功能需求，每列则对应每项功能的工作步骤以及每个步骤的工作量。
产品需求规格说明书一般包括以下几部分：
1）简介：主要由产品功能和定位简介、常用产品和技术术语、本文参考资料等三部分组成。
2）产品描述：包括产品介绍、产品范围，以及产品遵循的标准等。
3）技术约束和局限：说明实现过程中需要满足的条件和所受到的技术方面的限制，并且说明原因。
4）需求详细描述：按照功能进行划分，列举每一个功能需求，说清楚每一个功能的需求描述、优先级、参与者、实现前置条件、实现后的结果、功能执行过程中的正常过程（这一点是需求描述的重点，需要说清楚当没有任何错误发生时，参与者与产品的交互过程。这一过程展示了本功能的核心价值，每一个用例必须要有正常过程）、可选过程（另外一种正常过程）、异常过程（该过程一般会结束整个用例的正常执行）、特殊需求（一些非功能需求描述）、附加说明（与其他需求的相互关系说明）。
5）接口需求：一般包括用户接口（提供用户使用产品时的接口需求）、硬件接口（指出每一个硬件接口的逻辑特点）、软件接口（其他软件调用接口）、通信接口（指定各个通信接口）等。
6）质量需求：一般包括性能需求（产品支持的用户数量、运行速度、对资源的利用率，以及正常情况下和峰值情况下的处理能力等）、可靠性需求（例如平均可用时间、平均故障时间及修复时间、准确性和精确度、错误或缺陷率）、可用性需求（要从用户使用的合理性和方便性等角度进行描述）、可维护性需求（例如行业标准、编码标准、开放性设计架构等所有有利于可维护性或可扩展性的需求）、安全性需求（保护产品的要素，防止各种非法的访问和使用）、可移植性需求（产品从一种环境移植到另一种环境所要求的用户程序、接口兼容方面的约束）、可测试性需求。
7）用户文档需求：包括用户指南、联机帮助手册、安装指南、配置文件等。
2.需求评审
在需求评审阶段，邀请产品、开发、测试相关人员进行需求评审，产品需求评审主要针对以下几个方面进行：
·WHY：为什么做这个需求？
·WHAT：需求的价值是什么？
·WHEN：需求期望什么时候上线？截止日期？
·HOW：需求是否完整？正常场景是什么？异常场景是什么？技术上分别怎么应对？
例如，产品、技术详细评审需求是否完整，产品功能的正常场景是什么？是否形成闭环？异常场景是什么？是否考虑周全？
需求评审后，由开发和测试负责人分别编写技术方案和测试用例。接下来进行技术方案评审，由开发负责人与其他相关系统的负责人一起讨论，技术方案中必须要有业务流程图和时序图。业务流程图是为了梳理开发对业务的理解，确认是否和需求一致。时序图是为了梳理本次需求涉及的系统交互。技术方案评审通过后，确认工作量和交付时间，反馈给产品经理。
这个过程是需要进行反复讨论的，不管讨论的多激烈，最终能够解决问题才是最重要的。
3.2.4 总体设计
设计阶段的目标主要是对待开发系统的架构进行分析和设计，并建立系统架构的基线，以便为之后的实施工作提供一个稳定的基础。
设计阶段包括了系统架构的输出，一个好的系统架构设计可以帮助人们梳理业务逻辑并抓住核心需求，设计稳定可扩展的业务系统，评估业务开发周期和开发成本，有效地规避风险。例如盖房子的时候得有建筑图纸，有了图纸，才能核算施工周期。
总体设计是整个系统的框架型设计，意义极其重大，一般情况下不能省略（只有维护项目可以省略总体设计，因为基准项目已经设计完毕），所有的产品开发项目均需要首先进行总体设计，它是设计首要步骤，决不允许本末倒置，不能出现先编码后设计的情况，这是软件开发的第二大痛点（第一大是需求不明确、任意变更需求）。
总体设计分为三个阶段：
第一阶段：初始设计。在对给定的数据流图进行复审和精化的基础上，将其转化为初始的模块结构图。
第二阶段：精化设计。依据模块“高内聚低耦合”的原则，精化初始的模块结构图，并设计其中的全局数据结构和每一模块的接口。
第三阶段：设计复审阶段。对前两个阶段得到的高层软件结构进行复审，必要时还可能需要对软件结构做一些精化工作。
1.总体设计说明书格式
总体设计说明书一般包括以下几部分：
1）产品描述：简述产品的主要功能及应用范围、产品的特点。
2）涉及约束：从《产品需求规格说明书》中提取一些需求约束，具体描述最主要的约束，说明产品是如何适应这些约束的。约束主要包括应当遵循的标准或规范、软件和硬件环境约束、接口和协议约束、界面约束、质量约束（例如正确性、健壮性、性能、易用性、安全性、可扩展性、兼容性、可移植性等），也需要描述自己的想法、思路，以及为什么要采取这样的设计。
3）总体设计：产品设计的技术总体介绍，主要包括软件架构及模块划分、模块描述这两部分。
·软件架构及模块划分：概述整体设计方案、技术原理和构建思路，并阐述其主要特点。要求突出整个设计所采用的方法、软件的技术体系架构（例如C/S、B/S等）以及开发软件所使用的技术、工具。如果产品是由多个模块搭建而成，应说明逻辑结构的构成方式（包含网络拓扑图），以帮助说清楚系统结构。
·模块描述：对软件架构及模块划分进行描述性的说明，具体说明每个模块的功能和组成，为概要设计打好基础。
4）接口设计：包括外部接口和内部接口。外部接口说明同外界交互的所有接口安排，包括与外部软件或硬件之间的接口、与各个支持软件之间的接口关系。内部接口描述内部各子系统或模块之间的调用准则及关系，以及一些可供其他模块使用的公共模块的接口及调用方式。
5）备选方案及方案对比：首先列出备选方案，如果有多个方案，需要分节列出，如方案一、方案二等。然后对总体设计中的主选方案及每一个备选方案进行对比说明，需给出各方案的优劣势分析，具体说明各个方案的优劣势，以及如果主选方案失败，可以采用哪种备选方案及采用该种备选方案的原因。
6）集成要点：对集成要点进行描述，例如总体设计中所划分主要模块之间的集成顺序，集成时的特殊设备、特殊环境等。
2.设计方针
1）考虑设计优化问题时应该记住“一个不能工作的‘最佳设计’的价值是值得怀疑的”。
2）应该在设计的早期阶段尽量对软件结构进行精化。可以导出不同的软件结构，然后对它们进行评价和比较，力求得到“最好”的结果。这种优化方法可能是把软件结构设计和过程设计分开的真正优点之一。
3）结构简单通常表示为设计风格优雅，同时保持高效。设计优化应该力求做到在有效模块化的前提下使用最少量的模块，以及在能够满足要求的前提下使用最简单的数据结构。
4）模块划分首先要有合理性，这有助于快速对模块认识和理解，可以按照种类（基于逻辑关系、基于功能）来判断划分的好坏（看模块之间的耦合程度和方式，越少越好、越简单越好。有适当的依赖是件好事，证明模块之间有共享和复用，但不建议模块间过度依赖。做到能不耦合在一起就尽量分开来，能不相互依赖就不要相互依赖）。
5）优化时遵守一句格言：“先使它能工作，然后再使它快起来。”
6）从坚实的内核做起：雪球起点不是一堆散雪，而是捏得很紧密的雪核。
7）从小到大慢慢来：一点一点由小变大，而不是通过一次性组装变大。
3.2.5 概要设计
概要设计主要介绍的是设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每个模块的功能等。同时，还要设计该项目应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。概要设计的目的是描述系统每个模块的内部设计，对总体设计和详细设计承担起承上启下的作用。
概要设计按照结构化设计方法进行设计。结构化设计方法的基本思路是：首先按照问题域，将软件逐级细化，分解为不必再分解的模块，每个模块完成一定的功能，为一个或多个父模块服务（即接受调用），也接受一个或多个子模块的服务（即调用子模块）。模块的概念，和编程语言中的子程序或函数是对应的。
概要设计阶段将软件按照一定的原则分解为模块层次，赋予每个模块一定的任务，并确定模块间的调用关系和接口。
1.概要设计格式
1）简介：说明编写这份概要设计说明书的目的，指出预期的读者，并对本文会出现的专业术语和术语缩写进行解释。
2）总体架构：一般来说包括系统说明、运行环境说明、基本设计概念、总体结构及模块划分、可测试性设计说明、可维护性设计说明、可配置性设计说明等，也可以增加包含尚未解决的问题列举。这部分需要通过一览表及框图的形式说明本系统的系统元素划分，简单扼要地说明每个系统元素的功能，分层次地给出各元素之间的控制与被控制关系。
3）模块说明：逐一说明各个模块的输入输出及主要处理的功能，可以使用数据流图、状态图、流程图等图形化方法对模块的框架、处理流程进行描述。这里我们需要进一步对每个模块进行划分，并对其子模块进行描述，说清楚其功能及是否是关键模块（测试人员根据该信息确定测试方案）。
4）接口说明：包括用户接口、外部接口和内部接口。用户接口说明将向用户提供的界面、命令、语法结构及软件的交互信息，供用户以及上级模块调用，提供的语法结构应该尽量简单并提供默认值。外部接口说明与外界所有信息传输的安排，包括本系统与各支持软件或外部设备的通信协议及接口函数等，也就是对外部引用接口或协议的调用主要考虑驱动、控制软件以及数据传输等。内部接口说明内部各模块之间的接口，包括类的继承、实现、聚合关系以及各个模块之间如何进行数据交换和共享的方法描述。
5）数据结构设计：包括逻辑结构设计、物理结构设计、数据结构与模块的关系。逻辑结构设计给出所使用的每个数据结构的名称、标识符，它们内部每个数据项的标识、定义、长度以及彼此之间的层次或表格的相关关系。物理结构设计需要给出每个数据结构中每个数据项的存储要求、访问方法、存取单位、存取的物理关系、设计考虑等。数据结构与模块的关系需要说明各个应用程序与访问这些数据结构的各个模块之间的对应关系。
