这是一篇迟到的总结，原因是此iPhone项目从2010年12月初做到12月底，31日晚上7点才将最后的包交付出去。一般来说项目团队都会精简成2人，但是由于这个项目极具战略意义，客户副总裁是Project Owner，我们将5个人全投入进去，美国那边也投入了全部的资源，所以这个项目还比较有意义。iPhone开发技术见长是一方面，从项目角度来说也学到了不少的东西。
先介绍下背景：
需求方面：11月底来需求，需求不是正规的文档而是一封简单的Email，大体是关于为某行业建立一个全方位的apple平台解决方案，架构是Server + 客户端。这个解决方案以前我们在客户公司平台实现，所以需求较熟悉。
团队方面：能够投入的项目组的有ABCDEF 6个人，其中5个DEV，1个QA。A之前做过一个iPhone项目的UI coding，可认为是高产出DEV，实际他是Tech-Lead，也需要承担沟通的成本。B技术素质好，领悟力高，也做过iPhone项目的自动化测试，有iPhone编程能力，可认为是技术攻关DEV。C也做过iPhone项目，编程技术一般，可认为是一个普通的DEV。D是实习生，聪明但是粗心思考问题不全面，iPhone开发基本不会也错过了之前的iPhone培训，DEV。E是一名成熟的DEV，但是从来没做过iPhone开发，不过他在前期会有其他的事情，所以属于兼职DEV。F实习生QA，没测试过iPhone项目。这里要描述一个事实，人力资源不能变。
设备方面：4台mac mini，2台iPod Touch。意思是最多只有4个DEV可以同时工作。
时间方面：12月底之前完成第一阶段，基本功能实现；之后第二阶段就是把第一阶段做成可配置。
下面是做这个项目的一些经验，感悟和思考：
1. 谁偷走了我的时间？
对于项目而言排一个合理的时间表很重要，一方面是方便追踪项目的进展情况，二方面是给客户信心，因为这是我们团队第一次做iPhone的项目，而且这个项目直接就是重要的战略级产品，客户和我们心里都没底。根据团队方面的背景，有这批没有经验的人开发这么一个产品，我很想把时间线订成2个月，但是事实不行，因为这个产品因为1月份的展览必须12月底交付。
时间线第一个版本就是假设工程师都是成熟的，在12月底可以把所有的功能都交付。我心里没底，但是我知道，如果时间线都不能把所有功能交付，那真实运作起来就一点希望都没有了。
时间线第二个版本是在12月初修改而来，最重要的更新是灵活地根据“复用”原则。比如Functional A 和 Functional B都是非常重要的功能，一般的思维就是重要的功能要先做而且必须做，所以会安排两个工程师一个做Functional A一个做Functional B。但是后来我发现Functional A 和 Functional B从UI上很多东西可以复用，一部分逻辑也可以复用，面对不会iPhone开发的工程师们，可以让有经验的DEV A先做，等做完后，其他的工程师再去“依葫芦画瓢”甚至直接拷贝代码，这样会大大加速Functional B的开发时间。根据这个原则，实际上12月份出这个产品就有很多buffer了，但是这个建立在一个前提下，工程师是成熟的iPhone DEV。
另外一点就是时间线要考虑到工程师的成长性，因为他们的产出不会永远都是“什么都不会的人的水平”。所以一开始就预料到面对这样艰巨的任务，这样的人力资源，要把时间细致地用。比如把一个月分为4个星期，每个星期根据不同的人属性成长安排各不相同。
2. 没有FRD的需求
这个项目没有FRD，基于几个前提：我们团队和客户方项目经理合作两年，彼此间较默契；工程师A和E之前在客户平台上做过类似的系统，对需求很清楚。但是一个项目光知道大体的需求还不行，对于iPhone平台细节的描述是之前没有的，所以有一个FRD则是非常必要的。客户的女项目经理承诺第一周给FRD，后来直到第三周都没能给出来，巧的是团队也刚好从第三周才开始做客户端具体的功能，所以之前影响不大。这个时候QA已经开始抱怨需求不明，对于点一个按钮该如何QA和DEV之间各有各的意见，最后只能求助Tech-Lead。但是诸如此类根据人的判断来定需求毕竟不踏实，于是就发邮件给项目经理要FRD。
以前提到过，项目经理一直忙于1月份展会的事情，所以没能做。有一次电话会议上一向强势的副总裁也帮项目经理低声求情，问能否先不要FRD，有不懂的随时沟通。连副总裁都低头了，再这么也要给个面子啊，于是发邮件给项目经理，大体的意思是“既然你们领导都帮你们求情了，这次就饶过你了吧，不要FRD了，不过我们会加强沟通以确保是你要的”，这邮件让那个女项目经理感激涕零，连夸我们团队专业，让她Very happy。
那怎么加强沟通呢？遇到需求不明的情况，我们会建立一个表格列个矩阵，把所有的情况列出来，然后写入我们的理解再发过去给她确认；或者画流程图，根据FRD屏幕的截图来表示我们对workflow的理解；每天跟她发邮件说今天的情况，以及需要从她那里拿到什么；团队内部每天两个会议，各10分钟或以下，晨会制定今天的任务，晚会总结今天的成果。
3. 你真的做完了吗？
前期DEV A做UI，实习生被安排在DEV A做的UI上面做逻辑（其他的工程师各有各自的安排）。结果实习生很快就来催DEV A做完了UI没有，因为他之前的逻辑做完了， DEV A很高兴因为逻辑做得很快，结果DEV A为了避免耽误实习生做逻辑的时间，特地周末赶来加班把事情提前做完了。结果一测试才发现实习生做完了的意思是“他认为”他做完了，实际上没有，甚至像没有做一样，结果不得不让这次中间版本推延。DEV A就是Tech-lead，因为他的UI做完后其他的工程师可以开始复用，所以DEV A就停止开发，转变为代码评审，专门针对实习生和基础不好的DEV。代码评审结果很不错，找出很多东西，经过总结，各个工程师的开发质量有所提高，也不会再出现“做完了”像没有做一样。
4. 技术能力和项目要求不匹配怎么办？
这个在项目初期就提出了Risk，并有三个解决方案：1. 加班，用时间弥补能力；2. 开通和上海总部资深工程师的沟通渠道；3. 让客户减需求。实际最后这三点解决方案都达到，
加班只用了第二个星期的周末一天，其余每天工作晚一点；
向上海总部的求援信基本都得到回复，而且效果很好；
减需求比较巧妙，不是我们提的，而是副总裁自己提出来的。减的需求都是技术上很困难实现的，我们去问了客户公司一个资深工程师，结果他也说“没想法”，所以副总裁自己就决定这功能不做了。
5. 不同时期，不同角色
DEV A是Tech-Lead，因为有经验所以需要写代码，另外这个项目人员大多不成熟，需求也不明确，所以需要大量的沟通成本。12月的开始两个星期几乎DEV A是最忙的，又要写代码，又要沟通管理团队。直到DEV A的第一个模块UI写完了，DEV A才变身为Tech-Lead，开始做代码评审，开始专注需求分析，沟通，管理。在第二个星期和第三个星期，团队成员开始成长，基本上到第三个星期中期以后，DEV A的角色就彻底消失了，全身心成为Tech-Lead去沟通管理需求，而其他的工程师们的产出也开始增大到正常水平。整体来说项目的环境也是一天一个样，产品的功能越来越多，人越来越成熟，一切都按正常的软件工程模式靠近。
6. 最好的新年礼物
开工大会上的一个提法：这个项目因为要做到12月31日，所以可以说是自己给自己的新年礼物，做好了做砸了都是自己的事情，跟别人无关。Tech-Lead告诉大家这个项目做好了是奇功一件，做不好就陷入信任危机，自己对自己负责。
7. 对商业的建议是最好的附加值
项目在技术方面做好了是对你的本职要求，客户会觉得理所当然，但是如果一个技术工程师提出了在业务上的改进，而且这个改进又非常的有价值，则会让客户非常高兴，因为这叫附加值。当然能够对业务上做改进的技术工程师则需要经验的积累和积极的心态。
8. 无奈的返工
核心的产品核心的人做，不过如果面临人力资源短缺而不得不让一般工程师去做核心的产品，那就做好准备让核心的人在项目后期去返工。道理都明白，在事实面前明知道不行而不得不去做，只好用时间和风险去弥补人力资源的缺失。
9. 接受不完美，赶快出数字
当开发完成第一个模块的时候，因为工程师们的不熟悉会有一些Bug，而且从客户那边也会报一些Bug。那么现在面临选择是修复这些Bug尤其是客户报过来的，还是不顾这些Bug去开发新功能？我们选择了后者，开发新功能。这是在紧张的时间线压力下不得不接受不完美，因为只有把新功能开发出来了才会有效地减少最终交付的风险。
10. 跨国的团队开发合作
因为人力资源不足，在自己公司无法改变，就只好巧妙地跟客户公司副总裁传递这个信息，要来了一个在客户公司的DEV帮忙开发一个功能点。这个DEV在乌克兰，有个问题是他跟我们的时间不一致，比如我们的下午3点他才刚刚上班，所以为了解决团队合作的问题：
分配给他的功能要独立，不要和我们团队功能产生太多的耦合。
我们的Tech-Lead直接管理外援，虽然不认识没见过面没听过声音而且外援是副总裁的资源，但是也要按照正常的项目管理去规定他的时间线。
他通常会把他的功能集成到我们的版本上，然后增加版本号。注意基本不要理会他的版本号，因为他在开发的时候可能大团队代码已经做了很多的变化，所以只用将他那块功能提取出来（因为独立所以比较好提取）再集成到我们的版本上面。产品的交付版本永远从大团队这边发出去。这一点换个角度也比较好理解，外援只是时间地点不一样，否则就跟我们的工程师一样，不能说开发一个模块就加一个版本号对吧。
