爱图腾技术副总黄之豪：从需求到交付——优化你的移动应用开发流程

CMDN第二十一期活动于10月11日在北京福泰酒店公寓举行。本次活动以“移动客户端的外包项目管理”为主题，邀请爱图腾技术副总黄之豪将从先期APP需求调研以及报价原则、APP UE/UI设计流程、APP开发流程计划以及项目实施管理、APP测试标准流程以及相关工具、APP持续集成以及多渠道提交、产品后续迭代等方面与各位分享爱图腾开发团队的移动APP标准化生产流程实践。

爱图腾技术副总 黄之豪

黄之豪：今天我跟大家分享一些我们公司在外包中的一些管理经验，任何项目管理经验跟各个公司背景有关系，每个公司根据自己背景不一样，所以管理方法有一些区别。我先得介绍一下我们公司的背景便于大家理解我们有些东西为什么这么做。

我们公司就是致力于移动互联网的外包，这块应用做开发平台包括iphone、Android、WP7，并且从实施流程上，从设计，到UE、UI设计，到开发和测试，到迭代上线，以及之后的维护。

项目管理

首先第一点是为什么需要项目管理，题目很空，大家也想到这个问题，当然我这里面的答案也是大家心知肚明的，非常明显的。从我的角度的话，给大家强调一点我的想法。

第一个最重要自古以来做任何项目都有人监管，起到一个监工的作用，人之初、性本惰，有点悲观，但是实际上就是这样。不监督的话，其实大家都有惰性，作为开发人员前三天不着急，觉得还有时间，最后几天才开始赶工，那肯定最后结果不如意。所以从这一点来讲的话，我觉得肯定要避免一个问题，就是监工的人一定不能是做的人，所以这个职责要分开。自己给自己抽鞭子走的人不好找。

第二点是检查，检查的人也不能是做的人。因为做的人不识庐山真面目，只缘身在此山中。包括测试，如果测试一个项目测试时间长了他也看不出问题了，所以我们经常很多大众用户来讲的话，看到某一个产品，直接一看就觉得可能会发现一些问题，觉得这个产品很烂。其实不是，为什么需要广大用户的测试，就是因为发觉每个人看的第一眼发现问题是最多的，所以需要这个过程。所以在测试环节中，经常会有团队测试的概念，而不是一个人一直在测。这个是保证项目质量，所以需要去做检查。

第三就是做计划。像刚才讨论做计划的问题，这个计划我觉得从我的角度来讲，我觉得一定要做的。可能项目开始的过程中，包括做计划的时候肯定有需求分析，根据商业价值做一个优先级，像刚才李宁说的项目是倒退的项目，压死的时间点不能动，我们应该按照优先级把前面的需求放在1.0版本或者是1.1版本不能换，把这个确定功能需求，哪一个时间点完成哪些功能需求都要定下来。所以说做计划是一定的，如果看不到头的马拉松，他做事效率一定是低的。

沟通这个是非常重要的一点，在做项目的过程中，这种需求变化、设计变化，我们公司已经实施做过上百个客户端，绝大部分都有变化，没有变化的基本上没有。从这一点来看，沟通是非常重要的一点。这一块一定要有项目经理来做沟通，依赖程序员沟通，程序员比较宅，整天面对二次元，他沟通能力这块还是值得考量，所以应该有专门的项目经理去沟通。

还有就是像依赖我们需要接口依赖、设计依赖这种也需要及时去沟通。另外这块强调一下就是说沟通这块重视一下跟客户的沟通和老板的沟通，跟客户的沟通没什么可说的，这个沟通过程中加速项目的进行。跟老板的沟通是一般项目经理经常疏忽的一点，你要不跟老板沟通，有问题的时候找他，他平时不知道，这时候你管他要资源什么的，他会非常痛快的给你吗？这肯定就有问题了。但是平时你在项目进行比较顺利的时候也跟他沟通，他会觉得你真正需要帮助的时候他会觉得你之前因为他看到了进展，所以他觉得你已经付出努力了，这块确实真的遇到问题，他会给出伸出援助之手，所以跟老板沟通绝对不能忽视。

其他的通过项目管理的方法，达到各司其职，各司其职就能降低职位门槛，假如说一个开发工程师既负责沟通，又做计划，又负责开发、测试，包括各种上线，那他这个人要不然非常贵，要不然特别难找。如果能达到各司其职，这个人假如说有人员变动，你这一块就很好的补充，能降低职位门槛，降低人员流动风险性。

还想强调一点就是时间永远不够，资源永远不足，这一点我想说一个心态问题，因为有很多项目经理愿意抱怨，时间不够，人不够什么的，这一点我想说从我的管理经验来看的话，这个是永远存在的问题，不可能避免，所以你要通过在这个环节上，你就充分体现你的管理价值，你能够把这个各个资源协调开，而不是说单纯去抱怨，你通过管理手段降低成本的解决方案。

最后就是说你能够充分利用资源，降低成本。要用最简单的方法解决问题。

业务流程

这个是我们公司一个组织结构，这个结构也没有什么特别，只是随便展示一下，但是里面每个公司可能都差不太多。这一块我们公司的结构是按智能来划分的，像这块有IOS的团队，Android的团队，测试的团队，设计团队，还有专门负责技术难题的技术的顾问。项目经理这一块是一个池的概念，池这个就是项目经理是一组，有项目经理能力的人，来一个新项目的话，从这个项目经理这个池里面找一个现在合适的项目经理来做，下面的人就是说像高级IOS开发工程师，他一旦沟通能力各方面能达到这个项目经理程度的话，就可以把提拔为项目经理。做项目经理或者是助理项目经理，都有职位岗位的津贴，这个属于绩效，不是今天讨论范围之内。有这个池化项目经理资源比较充足，而且项目经理可以并行管理项目可以多一些。

架构组这一块像这一块有一个程序员发展路线有架构师的分支，架构师这一块主要是来解决一些有难度的问题，然后从分散到集中这个是一个情况，最后必须集中某一个人对项目有一个全盘的把握，这样他才能做出最有效的决策。

接下来就是进入到实施流程的正题了。这里面首先是需求和报价，然后是设计，然后是开发、测试、持续集成、更新迭代，这个是传统瀑布式的开发流程。后面还会提到敏捷开发。

首先需求调研这个阶段，需求作为一个承包方拿到的需求的完善程度是不一样的，有时候只能拿到一个基本的想法，比如说客户方的领导老说，我们要做一个彩票的客户端没了，就这样，剩下的你去想。这种情况是一种需求。然后如果再详细一点的话，可能给出一个功能框架，可能是一个脑图的形式，或者是一个TST以前基本模块一些名称，再细点可能涉及到细节描述，比如说像风险、收藏都会给你规划出来。再进一步是产品原形，X，像PS做原形图。再细一步就是UE、UN设计，这个真正投入开发了。

在需求沟通的这个阶段，我们需要挖掘客户真正的想法，有些时候这个我想大家应该平时都有这个经验，有些时候客户表达不出来自己真正想要什么，许多你在不断的沟通中才能了解他真正想法，并且引导他。

产品方案这一块，在他给出的只是一个IDEA，或者给出功能框架基础上，需要产品经理的介入，来给这个产品进行完善。我们公司虽然不做产品，但是也有自己的产品经理，就是来做这种方案的事情。来一个IDEA的时候，能把这个方案做成非常细化的功能，相当于帮助客户把这个产品免费完善了。如果要是对于客户非常重视的话，还会给他免费的来做一些UE、UI设计方案，最后出一些风格稿。

需求契合，你是从用户的角度出发还是客户的角度，从精神来讲，50%：50%，各占一半，这样情况下既满足最后实际的用户，也能更贴近那个客户。

你出来的方案需要对需求进行再次沟通，引导他往你的思路上靠，并且倾听他的想法，再调整，再排逆向法的一些优先级。相关的工具就是下面列这些，大家可能都用了，像脑图、这种产品原先设计工具，设计师用的PS等等。

需求完了，之后开始到报价了，报价这一块我们是根据工作量评估的人日数，应该公司都差不多，通过人日来报价，尤其需要强调一点的就是设计这一块，设计可以看到这一块给规划了一个设计创意系数，因为设计这一块像做产品的公司，设计师的能力最后转化成自己的产品在市场上有竞争里。对外包这个设计师的能力高低怎么转化为自己实际的营收呢？越需要设计和创意在里面，你需要增加一些费用，不能单纯按工作量来算。

沟通这一块对于客户你是看重短期还是长期，给多少折扣，是不是有风险，如果客户给时间过短，就需要看需求，要不然打死也完不成，最后不好说了。

这个相关工具没什么特别的，这一块着重强调一下，在我们公司有一个特别有意思的一个EXCEL脚本，它里面有一些红，可以通过填工作量可以计算出成本，这个成本包括人员、设计、房租等等，你做完了可以知道这个报价有多少利润在里面，并且能看多少砍价的余地，EXCEL是非常有用的，在报价过程中能降低很大工作量。

报价完了，如果你接到这个项目了。恭喜你，进入到设计的这个阶段了。有些项目可能客户来做，有UI设计就跳过这步了，我们公司一般是有设计这步，设计一个流程就是这样，需求沟通，到交互设计，到风格表，UI设计，到完成，公司最初的设计是没有UE交互设计，所以造成一些问题，如果要直接拿分工档来说的话，有些问题进行返工这个工作量是非常大的，所以用UE交互的方式来沟通。

UE分工表是很重要的，UE还需要最好的产品经理介入，设计师做产品更多关注美观、优化和流程，产品经理关注功能表现，海耶界面的元素，要注意主次，让用户一眼看到你最重要的功能，而不是说一眼看的都是乱糟糟的，都差不多，用户也不知道该点哪一个，所以有一个最好产品经理进入，从产品把控。

风格稿很重要，风格稿定了后面工作就比较好做了，只是工作量的问题。风格稿做一页、两页、三页，还是一版、两版、三版，这个根据资源的情况还有客户的要求来决定的。每个阶段需要沟通的，这个沟通是非常重要的，每一个阶段都要跟客户沟通，这样有问题及早去发现、去调整，去修改这个风格。

设计完了之后就进入开发流程，像这个是我们一个开发的计划，这个开发计划是一个粗略的比较概略的计划，因为我们公司从今年开始逐渐的新的项目转为用敏捷开发的方式来管理了，所以有更详细的计划到每日了，但是粗略的计划还是有，这样给用户和客户发的时候，发一个粗略的计划，让他看到现在项目进行到什么阶段，这个计划里面有时间、工作内容、每周要更新一下完成的情况，然后如果要是没按时完成的话，写一下备注，没完成原因，还有补救的方案。

在做这个计划的时候，一定注意它的可实施性和全面性，比如说这里面第一条，项目启动、完整需求沟通，接档，这个都是接项目的时候需要做的，我们很多项目没有考虑，一上来就是做UI开发，这样这些工作还是要做，最后就会DELAY，这就缺乏一个可实施性。

还有一个就是这里面有国庆放假也给规划在里面，这个在缺乏一些管理经验的项目经理身上经常发生忘了假期的事情，其实像一周的时间是非常长的，假如说忘了的话，客户才不会为这个给你延长时间，最后他还是要求你最后的时间点，你最后平白无故少了一周，开发人员还怨声载道的去通过周末加班补这个时间。

相关的工具也是EXCEL、PROIECTS、EVEMOTE、JIRA，为什么用EVEMOTE，就是程序员可以自己看到这个变化。这个小图是用EVEMOTE一个标签，通过标签可以快速筛选，可以看某一个项目经理管哪一个项目，直接这个项目情况都可以看到，包括上线中、开发中、暂停、测试中各个状态都能快速筛选，我觉得这个是非常有用的。大家可以用别的共享工具，但是目前我找到这个是最好用的。

另外在开发过程中，有关技术部分，首先就是技术积累，做外包的过程中，肯定有一些相似的东西，这一块肯定就是你积累出自己的基础框架，常用的控件还有函数。这个好处非常明显的，如果把这个基础的框架给剥离出来，这个框架维护人是非常有经验的，你将来的项目的实施实际的业务代码非常简单了，这样抗人员流动的风险性达到提高了。一个人如果是离职或者是抽到其他项目上，他的业务是很好交接的，因为真正基础框架里面会把真正的适配性、稳定性全都解决了80%。

还有代码规范也是为了这个来准备的，就是说大家协作开发，假如说项目现在缺人了，需要补进来，把时间压缩，如果有相同的代码规范的话，大家都很好上手，我们公司目前开发人员都是随便在某一个项目看到一个代码都能够非常快速的入手，就是因为它统一的框架和统一的代码规范。

专家组这一块在过程中解决难点问题，来做一些代码复查，公司框架的维护、代码规范的维护。我们还有技术分享例会每周解决项目中的问题、经验，来共同提高。还有技术博客共享代码，这样避免重复发送名字。有些公司这些小技巧、小方法都有，没有必要太细的说。

进入到测试这一块了，测试阶段首先要区分几个测试阶段。不同的测试阶段它代表你现在BUG大概还剩多少？这个产品完善程度到了一个什么程度？我们规划了四个阶段AIPHA、BETA、RC、RELEASE，测试类型有功能、界面、体验、性能、容错、兼容，尤其做客户端的开发项目，兼容是非常重要的，尤其是iphone5出来了，这方面是很重要的。在测试之前还有用例，有项目不用写用例，就写一个用例提纲，保证在一百条以内给出一个模块，指导你不要遗漏某个模块的测试。BUG跟踪这个是必须的，管理这个BUG的复查，关闭等等各种状态。

涉及到的工具就是EXCEL来管理BUG，更好是把管理系统，像MANTISBT这是我们公司使用的，还有很多其他的工具大家都可以尝试使用。

另外一点就是应用的持续集成还有多渠道提交。持续集成不知道其他公司用的多少，通过我们公司使用觉得这个是非常有必要的，能够大大减少开发部署打包的成本。持续集成这一块我们使用的Jenkins，这个非常有名的，对Android和iphone都可以使用的，可以同步代码，可以定时打包，可以定每天夜里三点打一个包，这样第二天测试人员过来，不用问开发人员要包，直接拿过来就可以部署，产品经理人想看直接拿过来包，老板想看直接拿过来包，根本不需要无聊的沟通要什么包，开发人员频繁打包，这个没有必要的。

另外就是提交这一块，iphone这一块还好，顶多加一个91，Android有很多市场渠道，我们之前有提交上百个渠道，那个基本上得打一到两天的包一直在打，有一个改动全重新打一次，这个简直是一个变态的任务。所以如果有这个持续集成的方案，这一点根本不用去考虑，当我们改完一个小改动之后，点一个按钮，所有包里面可能有不同渠道的标志，都自动通过脚本去改，改完了之后就剩下包了，直接就发出去了，根本不用花费那么多的人力。

产品上线之后就涉及到后续的迭代，这个需求肯定是不断变化的，除了像产品正常的规划需求以外，还有一些来自竞争产品的压力，比如说竞争产品上了一个什么新功能，你要觉得不上可能竞争力就减了，这种是非常常见的情况。还有用户的反馈，觉得你想要什么功能，还有领导的想法，这些都是肯定在迭代的过程中需要去不断的增加的。增加这么多需求的话，一定需要有版本规划和管理，每一个版本规划几个版本，比如说1.1、1.2、1.3版本都需要哪些功能这些都是需要记录清楚的。

还有在外包这一块，有一个特点增加新需求不是直接去做的，需要评估一下它的，一般我们公司有免费维护期有半年，这个期间改任何BUG没有问题，但是新需求需要考量是不是要免费帮你做还是要报价。这个肯定是作为外包承接方都需要考虑的问题。

敏捷开发

下面介绍一下敏捷开发，敏捷开发这一块刚才我听说昨天讲了一个SCRUM，敏捷这一块现在用比较多就是SCRUM，关于SCRM模型不多说了，说一下SCRUM模型还是有一些局限性，包括我们不断探索在实际工作中遇到一些问题怎么最好的解决，主要来自于SCRUM提出者是日本人，日本人做事在前期需求的时候考虑比较清楚，光需求做半年到一年的时间，在这个过程中，他已经把他想要的想的非常清楚了。各种文档非常完善，甚至伪代码都有了，我有个朋友在东芝中国，他就说一个需求通常做半年，基本上伪代码都可以看到，他们做事就是把功能大块砍掉、给改变这种情况少，但是在中国这个环境下，这种是非常常见的。另外像日本的在工作中经常一个人在一个公司一干就是一辈子，所以人员流动性比中国环境不太一样，比这块好的多。所以他的局限性有一部分来自于他的历史，当然还有很多局限性，当然现在又提出了各种对于敏捷的优化概念，也是针对与它的局限性提出的。我们也不能说它有局限性我们就不用，它有很多的好处，我们公司提出了它里面认为比较好的一些核心思想来实施，一些边缘的思想可能没有继续做引用。我觉得最好的就是找到适合自己的敏捷方法，这个方法没有说哪一个方法是最好的，适合自己才是最好的。我们引入的核心思想第一个就是功能细化、需求沟通。在传统的开发中，可能在前期更多的在于做一个详细的PRD这个需求文档给你描述清楚了，实际上在敏捷里面更多强调你面对面的沟通，所以在这一点上，我们是非常认可的，在像刚才程序员那个，在最开始的时候，其实应该是面对面多沟通几次，把这个需求真正说清楚，然后在开发过程中，开发人员才不会到后面才去理解这个需求，有些功能都做错了，再去改，那样的话已经晚了。

第二点就是按迭代来规划项目计划。如果要是像功能细化的话在SCRUM模型里面，有STORY，如果有这个你就可以规划每天完成那些工作量，这个工作力度已经细化到每日了，他强调一个每天的站立的一个理会，每天汇报当天的进度和接下来的计划，还有当天遇到的问题，所以这个力度是可以算是看得更严，这个基本上想把人当做机器来用，但是开发人员通常普遍反应比较累。

第三就是开发迭代中加入测试的环节。一般在传统瀑布式模型里面测试放在最后阶段，这样在开发的过程中，你可能已经暴露出来的一些问题没有及时改，到最后来一个返工，这时候再改有一点晚了，所以通常在测试环节会比预先计划的时间要长，敏捷的开发模式里面建议开发时间非常短，基本一周或者是两周，像Android和iphone每次迭代一周，每次迭代完了都要测试一周的工作，而且敏捷里面有一个模块就是每一个迭代都是做一个模块的功能，这个测试也是比较完整的测试一个模块。这个模块假如说太大的话，你可以细分没有问题，但是总能找到一个合适的大小的模块，适合这次迭代。

第四点就是来主动推动项目进度。有些项目在实施过程中，客户一直不知道进展状态，这种情况不利于沟通，到后面你最后再发现问题的话，就来不及了，所以说要每周都进行一个主动的汇报，跟客户汇报一下我们当天进行到什么程度，并且发实际的包给客户能拿到手里面真正的使用，去看到它，去把玩它，客户才能知道你当前真正进展到什么程度。

第五点要先做一些简单的功能，快速的看出成效。能够快速的看出界面，有些可能先从底层做起，说底层已经做很完善了，客户看了什么都没有做，实际上应该是从像我们公司先从UI，先从皮做起，把皮先做漂亮了，里面再去补充，那样客户能够明显看到你的进展，并且从直观的感觉你这个做的是进展非常快的，而且觉得非常好。

其他的一些使用方法，比如说结对开发，结对开发因为一个开发人员他自己做项目是比较孤独的，遇到问题他通常可能遇到一个问题，觉得难解决，他可能有时候先往后放一放，先休息一下，喝一杯咖啡，上上开心网，玩玩微博，之后再说，这种情况是很难的，但是管理人员是看不见的，所以如果要是能够相互扶持的话，同时也能是相互监督，他们两个人来做的话互相可以看到进度，自己也不好意思落太多，是非常有好处的。

还有一个好处就是假如说这个项目里面某一个人请假，请假的情况是非常普遍的，开发人员家里有点事，谁生病了，或者自己生病了请假几天到一周都有，但是因为敏捷这里面是强调每天都要有进展的，所以走一个人是影响比较大的，这种情况下如果你找一个人加入这个项目补一下这几天的工作是非常容易的，因为前面提到了有技术框架还有代码规范，他从技术上这方面没问题，另外从业务方面，因为是结对开发，另外一个人对业务很熟悉，所以他可以带这个人马上可以熟悉业务，基本上熟悉业务时间在两小时之内，所以这个好处是非常明显的。

第二个就是在整个项目实施过程中，不断的沟通，敏捷里面还是强调沟通的重要性，以人为本，强调沟通，所以在实施里面假如说一般不是在客户方面，这个基本都是通过邮件、电话去沟通。

第三点就是项目完成以后的项目总结，项目完成以后，通常你会有一些经验跟大家一起分享，避免别的项目犯同样的问题，或者有一些好的地方去分享。

这一块看板和演进图基本上SCRUM的使用工具，这一块不知道大家有没有接触过。看板是非常简单的，它就是把任务分成各个阶段，这里面有to do、doing、完成，每一个标签都有一个功能，这个功能完成了就贴在里面的标签，这样直观能看出来所有功能在什么进度，这个是对于这次迭代把握非常明显。假如说今天周三了，看现在还有好多在前面，肯定有问题，你需要调节资源补一下。像绿色这条线是代表最完美的开发的状态，它是直线往下降，随着时间的推移，工作量已经做完的是非常匀速的下降，到最后是零的开发状态，就是已经开发完了。实际开发状态这个曲线是有波折的，假如说看到某两天都是一条平的线，肯定这个项目有问题了，你就要及时地去关注它，及时地去调节。

这个演进图对于一个公司管理层，平时不太去关注项目，更适合看演进图，平时瞟一眼一下能看到某一个项目是有问题，某一个项目是没有问题，就能及时的解决。

项目实施中的风险计划与变化，功能需求、设计的增删改、变化相应原则；影响已定计划于功能需求？是。立即变化。否放入下次迭代或下一版本。

第二个就是项目时间的压缩，项目进行到一半的时候，突然客户方老板一声令下压缩两周时间，压缩三周时间，这个也是经常遇到的，所以这个时候其实我们没有什么太好的解决办法，这一块基本上调配资源，要不然就是进行一些需求删减，注意把这个删减完的需求进行版本管理，在协调一个时间，既然时间压缩了这么多，先做主要的功能，其他的功能放到1.1版，按照时间点做完了之后，我们马上做这些功能，这是一个沟通过程中可以去商量的一些东西。

还有就是开发依赖的延期，比如说我们开发客户端跟接口链条，把依赖尽量避免并行，有依赖先去做完，做UI设计的时候，做接口的事情，然后接口完成之后，基本验收没有什么问题的时候，再做客户端开发，这样可以避免这种问题。因为如果要是我们自己的人员时间延长的时候，这都是额外的成本的投入，但是当然对于做产品的公司，我还是建议并行的，不把这个依赖的内容放到前面去做，可以并行，这样可以加速。做外包我不建议。

然后开发人员的变动，这个在每个公司可能都是常见的，这个就是刚才我提到的需要统一框架代码规划去解决这个东西，基本能够解决。

开发难点由专家组并行去做，还有一点是验收的强度，可能到后面才发现经常有一种问题就是客户在验收的时候说老板是Android，他的ROOM是某一个项目的论坛下的一个ROOM，自己里面进的短信你怎么去做，但是他又非得要求你去适配，这种情况下，非常被动，所以一定要开始的时候约定适配机型还有系统，还有分辨率，像刚才说的情况，那个ROOM确实经过调查已经废弃了，连他们自己都不要那个版本，这种情况下要跟他沟通，这个ROOM用户量非常少，不需要做适配。

最后项目经理最后的职责，管理方法其实就是虽然永远无法达到的，但要无限接近，团队中永远会有开发人员抱怨各种问题，这个是很难避免的，不管是什么开发管理方式肯定都有这个问题，在这种情况下团队的文化、激励机制、竞争机制很重要，大家克服这些问题。在团队真正有困难的时候，项目经理还有管理层人员要挺身而出，真正带着大家解决这个问题。最后引用某人曾经说过一段话作为总结，战争打的一塌糊涂的时候，高级将领的作用是什么？就是要在看不清的茫茫黑暗中把心拿出来燃烧，用自己发出微光，带这你的队伍前进，照亮后人前进的道路，这个是你需要做的最后的职责。