在前文中，我们介绍了包含需求、用研、策划、开发、交互视觉在内的设计思考全过程。不过直到这里，经历上述环节的产品还只是一个小小的胚胎。我们还遗漏了一系列决定产品生死的重要环节，它们包括：
如何在项目开发过程中管理好人、事、物，以确保新产品如期诞生？
如何用数据分析的方法验证产品每一节点的决策是否正确？没有衡量就没有判断，失去判断力的产品无法存活。
一个产品开发出来后如何才能获取流量，让它触及用户、让用户乐于接受产品？
每个产品都有属于它的生命周期，在不同阶段有着不同的目标和任务，也拥有不同的用户量级。如何思考和把握产品不同阶段的运营方式，助力产品从0到1、从1到N不断成长？
如何打造一个产品的品牌？
在本章里，我们将继续为你拆解上面这些内容。
在类似腾讯的大型互联网公司里，上面提到的工作一般会有专业的团队成员与产品经理协作完成；但在初创型小团队中，一个产品设计者只有身兼数职才能笃定地把控产品方向，带领产品跨越沟壑、走向光明。本章也试图为这样的创业者们提供一些帮助。
第一节 开发迭代
在产品开发过程中，项目团队常会面对一系列问题。它们包括但不限于：
产品不能如期交付，开发成本过高；项目后期实现的东西远未达到设计预期的效果；
团队成员沟通不畅、无法很好地合作，团队信息不透明，人力与时间调配混乱，某些成员忙的时候忙死，闲的时候闲死；
成员不知道自己的任务最终要实现什么功能、达到什么样的交付水平；策划、开发、UI、运营等不同成员对产品的理解各不相同；
团队纠缠于低优先级的任务，导致最重要的事没做，用户流失严重；
产品需求频繁变更，导致项目发布时间严重滞后。
所有这些问题表面看各不相干，本质上都是由目标和风险管理不当所导致的。
在产品项目立项前，产品项目负责人应仔细思考的问题是：项目有多少资源？要达到什么样的目标？人和物的资源成本投入和目标是否匹配？经过详细思考和评估后，一旦确认资源并立项，最重要的任务就是统一团队目标。
统一团队目标包含两个层面的意思：一是提出明确的项目目标，二是确保团队每个成员心中的产品愿景高度一致，能紧密围绕目标作战。
明确的项目目标通常是一个可量化的数据指标，它包括数据效果和完成时间。比如“日活跃用户在某个时限前达到某个量级”。有了明确的效果和时限指标，团队在遇到问题时就能根据目标向下拆解，明确事情的优先级，将那些有助于达成目标的事放在更重要的位置上。
不过仅有数据指标是不够的，项目目标最好能指向一个明确的产品愿景。愿景通常代表产品的品质要求，它保证团队不会因盲目追求数据指标而选用杀鸡取卵的短视策略。比如腾讯“天天系列”手游在启动项目时就明确提出“日活跃达到千万量级”的数据指标。但同时，作为打响腾讯移动游戏“第一枪”的项目，它的产品愿景则是必须达到“世界级水准”。
第二点要求每个团队成员都能紧密围绕目标作战。这个要求听起来容易，实际要做到难度挺大的。如果在一个项目团队里，用研是用研团队的事，需求和策划方案是产品经理的事，技术架构方案是开发工程师的事，交互UI是交互视觉设计师的事，测试用例是测试工程师和QA的事，运营活动方案是运营经理的事——那这个团队肯定没能围绕目标作战。一旦项目出现问题，成员间必然会相互推诿，都认为问题出在别的环节上。凡有项目开发经验的人都知道，项目过程总伴随着各种问题，完全不出问题、产品还大获成功的“完美项目”根本不存在。更重要的是，如果团队成员无法从宏观、整体的角度去思考自己所负责的模块，必将引发内部的设计冲突。因为很多问题从单模块视角出发得出的结论与整体视角出发得出的完全相反。
围绕目标作战的项目成员不会像这样各自为战，相反的，他们就像一个命运共同体，“每个成员都有站在产品总负责人位置思考问题的习惯和行为表现”。任务被团队分解，但目标依旧完整。在这样的团队里没有“我的想法”，只有“更棒的想法”，没有立场，只有理性判断。他们也会就某个问题展开激烈辩论，但那只是为追求“更好的方案”，而不是为捍卫自己的观点。这样的团队里也没有“你的问题”，只有“项目共同的问题”，成员间彼此认可和信赖。他们相信各自能做好分内的事情，但也会在某环节遭遇瓶颈时积极贡献自己的力量，一起想办法解决问题。当内部模块间发生冲突时，他们也能及时跳出自己的角色去讨论，运用相对思维更全面地审视问题。
不过很多时候团队成员目标不统一，问题根源并不在团队成员身上，而是由于产品项目负责人没能在团队内部建立起透明、合理的项目机制。腾讯内部常采用下面几种项目管理方法统一团队目标，提升团队战斗力：
1.对外透明度管理：干系人沟通汇报机制
团队由人组成，人与人的关系是项目推进过程中不容忽视的重要因素。除了项目主要参与者外，还有很多相关人因素影响着项目成败。在项目立项初期明确干系人、分析其权益关系并设立有效的沟通汇报机制，将大幅提升项目对外的透明度。
明确干系人时，我们可以参考宝洁的方法论，找出项目的“PACE”：
P是Participant（参与者）；
A是Approver（审批者）；
C是Consultant（顾问）；
E是Executor（执行者）。
干系人权力/利益方格示例
图片来自腾讯项目管理课程《项目管理，让自己更从容》
不同干系人有不同的底层需求，在项目沟通时我们要尽量做到公开透明，让所有人了解项目全貌。尤其在一些跨部门甚至跨公司协作的项目中，因为有外部合作商或合作伙伴参与，对接和沟通机制就显得更为重要。项目管理者主动进行阶段性汇报，可以让重要干系人掌控项目进度，对项目放心。
2.对内透明度管理：故事墙与站立式晨会
团队成员如果不知道彼此正在做些什么，不知道自己做的事将对其他人产生什么样的影响，也不知道整个项目的具体进展，所谓“围绕目标作战”自然也就无从谈起。故事墙和站立式晨会就是确保团队信息透明共享的有效方式。
故事墙一般会利用团队办公位置附近的白板或玻璃墙面展示，整个墙面分为“Ready（计划）—Play（开发）—Test（测试）—Done（完成）”四栏。不同角色的成员可以将自己的任务需求用同种颜色的贴纸贴到墙面对应区域中，并且由上至下按优先级高低排列。这样对应区域的成员就知道哪些任务是自己当前必须处理的，它们的优先级情况如何，非常直观。当区域责任人完成当前任务后，他可将贴纸下移到后一个区域。例如策划提交了一个需求贴纸，开发完成后可以把贴纸移动到测试区，负责的测试成员就会启动测试工作。而如果想知道项目当前的状况，所有成员只需看看故事墙即可，任务类型、流转与阻滞情况统统一览无余。
除了利用实体墙面展示故事墙外，腾讯还在其线上项目管理平台TAPD[21]中加入了“故事墙”管理流程。如图所示，项目配图来自我QQ秀的老同事Blues（兰军），他的创业项目“梅沙科技户外营地教育平台”目前使用的项目管理工具就是腾讯TAPD平台（本节内容中以下所有项目截图均由Blues提供）。
“故事墙”管理流程图
站立式晨会是另一个确保项目信息透明顺畅的方式。它要求每天早晨启动工作前，团队成员聚在一起开个简短的碰头会，每个人说说昨天的工作完成情况和今天计划完成的工作任务。因为是站着轮流说，大家的关注度和效率都很高，完成昨日计划任务的很有成就感，没能完成的成员则会很难受，无形中凝聚力就上来了。站立式晨会还有利于不熟悉的团队成员间相互了解，鼓励大家发生问题时及时碰头沟通解决。
3.目标管理机制：OKRs
明确项目目标后，团队通过什么样的制度规则来控制和分解目标？又以何标准来衡量目标的达成情况呢？OKRs（Objectives and Key Results）就是由此应运而生的目标管理机制。OKRs意为目标和关键结果，它最初源于德鲁克的目标管理（MBO）理论，后经由Intel发起，在Google使用后被推广开，近两年来广受青睐。
运用OKRs，我们可以将项目总目标层层分解到各个小团队，再从团队分解到个人，这样目标得到了由上至下的分解和贯彻；再通过所有成员由下至上层层保证来确保目标的最终达成。
与KPI相比，OKRs的透明化程度更高，能让项目成员清楚地看到自己在项目中的位置以及对项目总目标的贡献。并且，在层层分解目标的过程中，项目成员还能了解到“什么事是对项目更重要的事”，进而做出更精准的优先级判断。在制定流程上，OKRs通常由成员和直属上级共同制定，这样项目期间如果遭遇竞争环境变化等异常状况，目标也能及时得到反馈和调整。最终项目团队会根据关键事件来评估目标的达成情况，而不是用僵化不变的数字指标做出判断。
具体到目标分解的层面，可以运用甘特图有效平衡和控制最终质量。我们知道，项目最终的产品质量受到三个重要边界的限制：时间、成本和范围。
如图所示，通过对人、时间、任务的分解——WBS（Work Breakdown Structure），项目任务被拆解成小的任务模块，并且每个任务模块只对应唯一的责任人，方便项目管理者监控。
不过值得注意的是，目标任务的分解不仅要尽可能细还需要尽可能全面、合理。
甘特图
首先，任务必须被100%拆解，也就是说所有子模块反向加总要等于全部项目工作。举例来说，如果被分解的任务是一个大型活动，分解时可以面向阶段分解成活动前、活动中和活动后，再进一步分解每个阶段的细节工作。其次，由于不同子模块间存在潜在的逻辑依赖关系，如何识别和安排关键路径就变得异常重要。比如我们可以看一个例子：
4人夜里要过一座独木桥，桥只能容2个人同时通过。过桥必须用手电筒才能保证安全，可4人只有1只手电筒。如果他们各自独自过桥，需要的时间分别是1、2、5、10分钟，如果2个人同时过桥，则需要迁就更慢那个人的时间。
如果把过桥视为项目目标，将用时5分钟和10分钟的人安排到一起过桥就能大大节省整个项目时间，使得最快方案在17分钟内达成。从这个简单例子可以看出，如何分配安排任务将影响到项目完成的时间。
4.目标激励：“日稳定版本”机制
“日稳定版本”机制是指每天项目各平台（iOS/Android）必须产出一个稳定版本供团队成员随时下载体验。“稳定版本”的定义是指没有严重Bug、产品所有基本流程可以跑通，不妨碍体验的版本，允许小Bug和部分不完善功能存在。
这个规定相当于把长期的项目目标拆分成了“以天为单位”的子目标，实现“日清”。以每天的“日稳定版本”为终点，团队的战斗力将得到最大程度的激发。刚开始实行这个机制时，很可能团队成员都会觉得“麻烦”，或感觉它是“不可能完成的任务”。但人的潜力往往超出自身想象，长此以往形成习惯后，团队成员的战斗力将获得大幅提升，并且还会逐渐享受这种日事日毕的成就感。
项目风险管理：需求变更的必然性？
在实际的产品设计开发过程中，由于“最佳解决方案”出现时机并不总是可控，需求变更的发生往往不可避免。假如项目管理者把需求变更视为恶瘤，欲除之而后快，最终扼杀的往往是“产品更好的可能”。
其实需求变更和项目质量一样，属于项目综合平衡、管理的要素之一。某种程度上，我们甚至可以把需求变更看作项目质量优化的一个子类型。正如质量不可能不计成本地提升一样，需求变更也不可能罔顾时限、不断更改。这时，将需要变更的需求按优先级排列管理起来，根据项目开发进度阶段性满足，将是更为明智的选择。
需求管理图