3.3.1 项目定义
经过前面的业务策略阶段，管理层应该做出判断，确定这个项目在可见的一系列机会里是一个高价值的目标，并初步论证了可行性。这时候需要根据前面阶段获得的信息，识别和澄清这个项目要解决的业务问题，定义交付目标，配置所需资源，并在制定在交付过程中期望组织的提升目标。
1．问题定义
做正确的事情，第一步是要识别出正确的问题。阿尔伯特·爱因斯坦曾经说过，“如果我只有一个小时的时间去拯救世界，我会用59分钟来定义问题，用1分钟寻找解决方案。”清晰地定义问题是设定目标、制定计划的前提。我们经常会低估了问题本身的定义对后续方案产生的影响，实际上，仅仅是描述的不同都会对解决方案的方向产生重大的影响。
一个项目的立项通常是为了解决一个或一组业务问题，目的可以是使产品覆盖更大市场和更多用户，或是满足某类客户新的业务需求，为现有用户提供更多价值，也有可能是为了赢得一个重要客户的招投标，完成一次对市场的试探，还有可能是满足某个政府或是行业的合规要求。
Big Bank在这个项目中要解决的问题如下。
•很多个人和家庭拥有相当数量的闲置资金，正以低于通货膨胀率的银行利率在银行里贬值，他们缺乏相对稳健的投资渠道获取高于银行定期存款利息的收益。
•很多个人和小企业主在缺乏短期资金的时候，难以通过一般正规金融机构以舍理利率获取贷款。
•作为中介机构，Big Bank如何高效地撮舍上述两类客户的需求，形成交易并从中获利？
•Big Bank如何通过这个新业务跟已有业务之间的协同作用，扩大对零售金融市场的覆盖，形成竞争壁垒？
Big Teleco正在开发的这个产品，其所面临的业务问题则是进一步拓展下一代无线通信市场的份额，在市场上形成技术领先的优势，而当前这个项目则是为了满足产品在一个新市场部署实验局的规格要求。
如果把项目分成问题域和方案域，不少组织和个人都会不自觉地混淆问题域和方案域。一个具体现象就是，当开发团队讨论一个项目的时候，把所有的时间都用在了分析、设计和实现解决方案上，大家都在说要如何开发某个特性，很少看到有人甚至提起这个特性到底是要解决什么问题，为谁带来什么样的价值，问题的产生场景是怎样的，大家对这些问题的答案经常是想当然。
这种现象其实也跟不少组织中的角色定义有关。在很多领域，分析问题的人和分析解决方案的人被分成不同的角色，比如分析员、架构师、开发人员，三个角色之间的关系明显就是前者为后者分析问题，后者为前者提供解决/实现方案，而后者经常缺乏对问题域的全局掌握和关注，导致做方案的人不时会把时间和资源放在了无关重要、甚至是错误的问题之上。
2．交付目标
一般来说，我们很难通过一次交付就彻底地解决一个业务问题，一次交付的目标更可能是为了达成产品路线图上一系列路标中的一个。这个路标可以是一个新的价值流的端到端的实现，也可以是在现有的价值流上增加不同场景，为用户提供更加丰富的选择。
交付目标应该有可度量的开始点和截止点，也就是有清晰的边界。这个边界可能会在交付过程中，根据最新的信息而调整。但在任何特定的时候，项目的所有干系人对边界都应该有一个清楚的共识。
Big Bank这次的交付目标是在同类机构之前，以最小可行产品的策略，将这项新业务推向市场。
•通过在线方式，帮助借贷双方方便、安全地完成投资和借贷。
Big Teleco这个项目的交付目标是某客户在该特定市场部署实验局所必需的2个关键需求。时间点对于这次交付至关重要，管理人员需要根据市场的要求来定义决策评审点，Beta测试开始时间等关键时间点。
3．提升目标
从来都不要指望脱离日常工作的刻意培训能给交付能力带来本质的提升，就好像没有球员能够不经历无数场的拼杀就能成为伟大的球星，也没有外科医生能不经历无数场的手术就能成就卓越的医术一样，只有真实项目上的挑战才能激发人们学习和创造的潜力。一个组织要分析相关行业和竞争对手的数据，对自身交付竞争力做出评估，有策略地制定提升目标。研发竞争力的提升必须要以项目为载体，在实践当中部署实施。
Big Bank经过分析，认为自己的开发中心在效率上、质量上都领先于同行业的软件开发组织，但是在进入在线业务领域后，竞争格局出现了很大的变化。除了其他金融机构的竞争，各大互联网公司也在尝试进入金融领域，正以各种方式尝试直接或间接地提供针对个人和企业，特别是小企业的金融服务。
这些互联网公司对机会和市场的响应方式和速度，却跟传统金融机构有很大的差别，方式上经常显得更有创意，不拘于已有金融服务的模式，反应速度上不是传统大型机构的步调所能匹配。以往大型金融机构所拥有的网点和客户数量优势，是新进入者不得不面对的坚实壁垒，而这个壁垒在互联网的规模覆盖和社会化营销的效率面前却威力不再。
因此，Big Bank 的管理层决定，这次的项目应该作为一个试点，尝试新的开发方法、流程和技术，以及用户体验设计和网站运营手段，把互联网公司当做标杆，提升对市场的响应速度和产品研发的价值命中率。
Big Teleco 的产品开发团队的划分是基于产品架构对子系统和模块的设定做出的，Big Teleco 越来越意识到这种模式带来的两个问题。
•现有的模块团队的划分开始局限产品架构的设计。系统工程师做设计的时候，总是有意无意地会把现有团队结构和能力范围作为约束条件，影响了最适宜设计的产生。
•能力的细分越来越严重，具备全局能力的工程师越来越少，培养周期越来越长，并且要形成端到端的交付能力，哪怕是为了很小的一个特性，都需要引入大量的沟通和协作成本。
因此，Big Teleco在这个版本的开发中决定在一定限度內打破模块团队的协作模式，尝试根据项目目标组织临时特性团队的工作方式。
4．资源配置
一个大型的开发组织一般都有多个产品、多个版本在同时进行当中。这就涉及到在不同发布目标之间的权衡，决定资源，特别是优质资源的分配。优秀的人员和关键的设施永远都是稀缺的，如果不稀缺的话，倒是让人有点怀疑这个组织的运营效率了。资源的投入经常是多个项目、多个产品之间博弈的结果。
鉴于这个项目的业务和开发方法对现有团队都是属于比较新的模式，为了能够确保交付和学习两方面的目标，Big Bank决定成立一个新的开发团队，从其他团队抽调部分精兵强将，再从外部找个经验比较丰富的厂商舍作开发。
Big Teleco的人员管理和培养属于功能部门的职责，项目经理需要根据当前项目所要完成的活动确定所需技能和相应人员的数量，会同各个功能部门经理、产品线总监，协商获取相关资源。
项目管理人员需要根据项目的目的和里程碑来规划项目，在规划的时候需要覆盖进度、质量、资源和风险各个方面。
5．进度目标
项目管理人员需要根据自身所采用的流程模型和团队在整个产品开发生态系统中的位置，识别交付所需的各项活动、每项活动所需的时间，以及活动之间的依赖，并以这些数据为依据描绘项目的关键路径
，从而制定进度目标。
项目的关键路径信息可以帮助项目管理人员识别交付过程中的里程碑。里程碑提供了一个常规机制来跟踪项目的进展是否跟预期相符。虽然我们强调项目当中的反馈机制应该使相关人员能够尽可能接近实时地获取信息，即刻采取行动，这些里程碑给团队之外更广泛的项目干系人一个必要的机会，一起分析最新的项目和环境信息，调整后续的时间点、投入、工作范围和目标，或做出其他必要的决策和干预。
里程碑的定义要有明确的目标。典型里程碑的标志通常是跟某交付物的验收结束相关，确保验证的力度和问题的解决符合预定的阶段性质量目标。
●阶段性评审的结束，比如需求、设计、测试计划等。
●某个交付物的质量保障活动的结束，比如功能测试、集成测试，用户接收测试（UAT）。
在迭代交付模型里，典型的里程碑是发生在每个迭代结束的时候，以迭代展示（Showcase）为标志。团队会在这个场合将交付物——经过验证的特性，演示给项目的干系人，并获取反馈。有的团队也会利用这个机会（团队外的各方干系人在场的机会），针对一些中间产物，诸如界面原型、架构设计和技术决策分析、测试用例等，收集反馈，甚至开展评审活动。
Big Bank期望在年底之前发布产品，决定采用2周一个迭代的策略，以便及时得到反馈和对计划做出适应性的调整。Big Bank把第一次內部发布定在了第四个月，也就是元旦前的一周，然后，根据这个时间点倒推出了下列信息。
•每个迭代的期望速率（交付的点数）。
•关键交付物的验证时间点。
•外部依赖的检查点、接收和验证计划。
•性能和负载等非功能属性的验证计划。
•用户接收测试的时间点。
这个项目采用典型的迭代开发模型，在开始的时候计划了一个2周的启动阶段，这个阶段的交付物如下。
•需求：目标用户模型（Persona分析）、用户体验路线图、业务流程、信息架构、界面原型、用户故事列表。
•技术：架构设计、关键技术决策、关键非功能性需求的可行性验证。
•计划：估算、优先级、依赖分析、风险分析。
由于这个产品对外部的依赖是几个已经投入使用的后台系统，所以跟那几个后台系统的负责团队确认了开发协作的方式和集成测试的时间点。
Big Teleco使用的是由经典IPD（Integrated Product Development）流程衍生出来的一套结构化、端到端的产品开发流程，包含概念、计划、开发、验证、发布和生命周期6个阶段。IPD流程覆盖产品开发团队（PDT）、财务、开发、支持维护、制造、采购和市场各个组织，本文只关注其中软件开发相关的部分。
在计划阶段，软件相关的交付物包含：系统规格和概要设计、用户体验设计、需求分解和分配、系统测试和验证计划、文档计划、支持和维护计划……
6．质量目标和手段
不同类型的产品有不同的质量目标。对于一个飞行导航系统和一个blog系统来说，其质量的要求自然有所不同，因此使用的测试手段和其他质量保障活动也会有所不同，需要不同的质量保障策略。
Big Bank测试和开发人员来自一个大的资源池，基于项目的需求组成一体化团队，也就是说各个层面的测试和验证是在团队內部完成的。在测试人员主导下，团队中不同角色的代表一起制定了一个覆盖3个层面（单元、功能、集成）的测试策略、自动化策略、用例管理策略。
在这个项目里，开发人员将负责单元测试完成，测试人员将会跟业务分析人员一起定义每个用户估算的验收条件，并设计功能和集成测试用例。功能和集成测试用例的自动化则根据工作量的平衡，由开发人员和测试共同完成。
Big Teleco拥有完整的质量保障体系，具体内容如下。
在产品的整个开发周期里，对各个阶段、各个功能部门的交付物，包括各种分析、设计和计划文档，软件代码和测试用例都有严格的走查、评审机制。
测试手段覆盖开发人员测试（单元测试和单元级别的模块和集成测试）到测试人员测试（包括系统集成测试、Beta测试等）。
Big Teleco的测试团队独立于开发团队，这种组织模式基于的观念如下。
•测试的独立性能够为产品的验证提供跟开发不同的视角和思维模式，因此更有利于发现缺陷。
•测试是一个专门的技能，在组织中应该有专门的团队为能力的培养和提升，以及提炼和吸纳业界的最佳实践负责。
电信类产品虽然日新月异，不过相对于商用软件和互联网软件，主流电信类产品开发技术在过去的十几年间变化不大。同样的，测试策略在同一个产品线里的各个产品和版本之间有很强的继承性，基本是以渐进的方式演化。因此，测试经理在项目定义的阶段，更关注的是参与设定产品的质量目标、制定测试和验证计划，参与项目计划的制定，协调测试资源的到位。另外在电信领域，为本类型产品量身定做的自动化测试工具会大幅降低测试的用例的开发和维护成本，所以测试经理还会需要梳理测试工具开发的需求，甚至带队参与测试工具和模拟软件的开发。
除了独立的测试团队，Big Teleco还有独立于项目的质量保证部门，与各个功能部门紧密协作，负责质量战略和目标的落实。质量部需要做以下工作。
•根据业务目标，协助制定质量策略。
•参与项目计划和计划的评审。
•分析历史项目指标数据，协助制定当前项目的质量目标。
•负责流程的运转和优化改进，以及相关知识和能力的传播和提升。
7．资源的规划
什么时候应该谈投入什么样的资源，包括人员和设备？这个时候，项目管理人员就需要用真凭实据，对照过往的历史数据和项目相关信息，提出资源的要求。
Big Bank的项目团队组成通常是根据项目的需要，考虑技能匹配和时间安排，从部门资源池里选择。这次Big Bank的项目管理人员跟舍作厂商一起对初始的发布目标进行了分析和估算，经过权衡可获得內部人员数量和采购预算，再把交付目标的要求和学习提升的期望纳入考虑，得出的结论是，为了满足要求，需要自己团队出5个人，厂商出10个人。
Big Teleco的项目团队具有相当的稳定性，熟悉一个产品的业务领域，甚至只是熟悉一个模块的业务和技术，都有可能需要1～2年的时间，因此，通常是上一个版本团队的人员释放之后就逐步投入同一产品的下一个版本，人员的稳定性对团队成熟度、技术积累、开发效率都要较大的影响。这个项目也是一样，上一个版本的开发已经进入最后的系统验证阶段，人员开始逐渐投入到这个版本。
对于个人来讲，项目的参与人员需要了解团队计划，评估个人对于交付目标的承诺，并且识别成长的机会。每个人心里都有一本账，而这本账的计算结果会时时刻刻地影响着个人、团队的士气和投入度。
Big Bank的开发人员Tom心里评估着团队的目标和计划是否靠谱，看看自己是应该拍拍胸脯，承诺保证完成任务，还是应该摆出一副苦样子，表示一下对于激进目标的担忧，另一方面又思考着这个项目对自己在技术上还有业务上的成长是否有帮助，盘算着自己在这个项目上的贡献和成果是否成为未来升职加薪的筹码，增加自己在工作市场上的竞争力。