2016年，我们应该重点关注App项目管理

      项目管理2015年，在App项目管理领域，仍没有太大的进展。我悲观的认为，App项目管理，已经到了糟糕透顶的地步。
　　从事传统项目管理的工作人员，并没有与时俱进，还在把旧的项目管理方式直接套用在App项目管理上。主要体现为传统项目管理只涉及到产品经理、开发和测试三个团队，开发完毕介入测试，测试完毕随时可以发布上线，如果一个团队延期，另一个团队可以做下一次迭代的工作。
　　但是App开发就不同了，涉及到产品经理、Android、iOS、服务器、测试共计5个团队的协作，有时还会牵扯进H5前端团队，那就更复杂了。
　　App区别于传统项目的另一点就在于它有发版时间限制。2周或4周的迭代时间，到了最后一天就必须要提交APpStore审核或发布到各大Android市场，一般不能延期，否则不光影响技术团队，市场推广团队也会受到影响。哪个做不完或者测不完，就只能等下次发版再上，那就是一个月之后了。
　　既然迭代周期是固定的，App项目管理所关心的，就在于如何能在有限的时间内完成尽可能多的需求，而不是每天纠结于“敏捷白板上的小纸条哪里格式不对了”这种形式主义的东西。
　　如果有可能，我真心想把每个公司所使用的项目管理工具（比如Wiki）废弃了，工程师们往往是在项目完成后才更新Wiki上的项目状态，而做不到即时更新。我只能在每次App发版后才看到大量项目的状态变更。那我还要这种工具干什么呢？而过度的要求工程师实时使用Wiki来更新项目状态，那无疑是重流程的软件公司的打法，不适用于互联网高速发展的文化。越是大公司，这种官僚文化越严重，迭代速度远低于创业公司。因为互联网公司现在钱很多，很多软件公司的项目管理人员都跳槽到了大型互联网公司，无形中就把这种文化也带过来了。
　　说真的，我不喜欢循规蹈矩。我喜欢时刻去改变去尝试，直到找到一条切实的解决方案，所以我经常会到一线去，和团队一起加班一起熬夜。在4年的App项目管理经验中，我观察到的是，对于10人左右的小团队，每天可以在晨会上把产品、Android、iOS、Server、QA的进度都过一遍，控制在10分钟以内。而对于40人左右的中型团队，这时一般会按照Android、iOS这样的技术工种细分为多个小团队，每天晨会问技术经理团队的项目进度，他一般不会知晓团队中每个成员的工作状态，所以这样的晨会是很没有效率的。这时需要把团队按照需求拆分为若干虚拟小团队，每个需求的虚拟团队都由产品经理、具体的iOS开发、Android开发、Server开发和测试人员组成，采取产品经理负责制，每天组织各自的晨会并发会议纪要。
　　项目管理人员手中应该有一份所有人的名单，减去产品经理日报中涉及的人力输出，那么剩下来的人力，要么是请假了，要么是在做技术需求，还剩下来的人，就是真的没事做了，浪费掉了。
　　这时团队每个人的工作状态就都一目了然了。我们不苛求每天都把人力充分使用，但至少要做到哑巴吃饺子——心里有数。
　　那种靠每周发周报的项目管理方式，属于事后补救，难道我们要在一周之后才知道人员利用率不高而导致的项目风险吗？这对于两周发一次版本的App而言，多少有些可笑了。
　　我们不可能安排一个开发人员一个迭代只做一个需求，也许这个需求两天就做完了，难道剩下的时间全都用于修bug吗？这种敷衍的说法，用于哄弄那些不懂技术的老板的。剩下的时间应该去做更多的需求，那么就会有人问什么时间修bug？两周的迭代周期要怎么安排比较合理？
开发只有第1周周二到第2周周三共计7天时间。测试团队要在开发人员提测后立即介入，而不是等到所有项目都完成后统一测试。开发人力不足，一般是第1周加班；测试人力不足，一般是第2周加班，但没有定式。第2周周三晚上为Code Complete，周五晚上为Code Freeze，这两个点很关键，直接决定了是否要加班以及是否会延期。
　　当一个Task的开发时间，从3天（粗略评估）被压缩到2天（精准评估）后，多出的1天时间做什么？
　　首先是看还能不能消化更多的需求。
　　其次，就是重构，做技术需求。App领域有太多的技术需要升级，我分析过100多款国内比较知名的App，发现各自的瑕疵都还是有很多的。Android的技术工作会更多，比如每次迭代要挤出1-2天时间来修复线上千奇百怪的崩溃。
　　最后，就是研究新技术。要时刻了解市面上的新思想和新技术。
　　上述这若干文字，都是在诠释一个词，节奏。
　　团队多了自然就会有沟通上的障碍，从而导致效率大幅下降。而我的观察是，只要让所有团队踩准了节奏，App和Server团队同一时间联调而不是互相等待，按时提测而不耽误测试人员的进度，提前介入测试而不是前松后紧，当所有的团队能够踩住这几个节奏，那么我们就能在有限的时间内按时完成足够多的需求。
　　2016年，我们应该重点关注App的项目管理，多开几次会各个公司分享一下经验，总结出一条好的方式来。
　　技术篇接下来的篇幅，不限于Android或iOS。
　　2015年，各大互联网公司开始经营自己技术团队的微信公众号。以下是我收集到的几个（排名不分先后哦），欢迎读者补充更多的技术团队公众号：
　　淘宝：TaobaoTech天猫：tmalltech手淘：AlibabaMTT微信：WeMobileDevQQ空间前端：QzoneWebBugly：weixinBugly京东：JDTechEd美团：meituantech携程：ctriptech去哪儿：QunarTL途牛：tuniutech当当：当当Tech
　　此外还有技术社区的公众号（排名不分先后哦）：
　　InfoQ：infoqchinaCSDN：mobilehubOSChina 开源中国：gh_430521f7587e51CTO技术博客：blog51ctoCocoaChina：cocoachinabbs
　　通过持续关注这些公众号，尤其是无线相关的内容，可以大致知道业界最新的技术趋势，比如Android插件化编程，比如iOS瘦身。
　　2015年，对无线领域的技术分析正式摆上了台面。之前肯定有公司也在小规模的做这个事情，只是不能多做宣传罢了。
　　竞品分析的手段一般分为几种：
　　1）iOS的代码是无法反编译的，但是Android却可以，大多数App做了代码混淆，但也有的App直接裸奔就发到了市场上。即使代码做了混淆，我们也能从关键片段中看出端倪来。关于这个技术我不能再讲下去了，否则就要教坏小朋友了。目前看起来，对Android进行加固是一个好的办法，也有一些公司从事这个领域，但还没有广泛应用起来，比如说爱加密和梆梆。
　　2）所有的apk或ipa文件，都是压缩包，我们将其后缀修改为zip格式，就可以解压并看到其中的文件了。通过分析这些文件，我们可以学习到优秀的公司是如何解决App体积大小、性能优化新技术，一般的话，一个新的思想或新的技术，都会伴随一个配置文件在App包中，比如ABTest。
　　此外，我们知道，Android App中的动画，会放在Apk包res/anim目录中，当我们喜欢某款App的动画效果时，按图索骥，直接可以在上述目录中找到相应的动画文件；但是，当我们在ipa包中也看到类似的动画文件时，那十有八九是这款App的iOS版本中，存在一个动画引擎，iOS程序员可以把Android团队的动画文件直接复制过来就可以使用了。
　　2015年，我终于看到美团在App中使用ABTest来做产品。产品经理可以根据线上A和B两种策略各自的转化率来迅速决策哪种策略更适合。
　　也许ABTest这门技术，其他公司早就开始在做了，只是没有声张而已，在此请不要笑话我的孤陋寡闻。我把自己在实施ABTest的一些经验分享出来，请参见下面这篇文章：http://blog.csdn.net/jspandasp/article/details/49339443
　　数据驱动产品——我认为这才是做产品的方式，而不是靠拍脑袋。稍微高级一点的产品经理，会收集有利的数据来支撑自己要做的需求，而有意识的忽略那些不利的数据。这多少有些偷奸耍滑，需求上线后的结果也是听天由命大都结局不好。
　　产品需求分为两个方向，一是刚需，二是交互和UI设计。
　　对于第一个方向，需要对这个领域浸染很多年，才能真正知道用户和供应链上的真正痛点，目前我见过这个方向最好的产品经理就是杨威。也许以后还能遇到更好的，但是目前就是他了。2015年我有幸见到了他是怎么在几个月内从谋划到调动整个部门完成了机票整个流程的改造，最后做出来一套逆向报价系统。
　　对于第二个方向，则多少有些自说自话了。一套好的UI设计怎么评定？首先是老板喜欢，这是因为一套设计不可能让所有人都满意，但只要老板满意，就是好的设计，搞定了老板，后面的都好谈；其次是风格要统一；再次是要时刻关注竞争对手的App改版。
　　对于好的交互设计又怎么评定？首先不能设计出“反人类”的交互；其次要看PV和UV数据，看哪里的转化率低；再次看用户反馈，广泛吸取各方意见；最后看竞品，取长补短。
　　无论哪个方向，都需要数据说话。运营才是王道，因为只有他们才能通过调整策略得到不同的数据，分析数据最终做出判断。运营人员欠缺的就是不知道如何把需求组织成文档给开发人员，这时候就轮到产品经理出场了。
　　产品经理应该学点数学，能根据运营妹纸提供的数据，总结成公式，才是好的产品经理。数据驱动产品，重要的事情说三遍，不写出来了，心中默念三遍即可。
　　接下来介绍一款由腾讯团队于2015年发布的App尾随测试的神器，GT（随身调）。
　　2015年的最后一门技术，那就是App缓存命中率。
　　从事App开发的同学可能不清楚缓存命中率的概念。这一般是做在数据库层面，对于频繁访问的数据，会放入缓存中，从而下次访问时不会再执行SQL语句，极大地节省了性能，但是也不能把所有的数据都放在缓存上哦，没有那么大的控件。对此，我们的妥协方案是，设置一个阈值，大于这个阈值，缓存的时间会长一些；否则，就只有3分钟后缓存就会失效。
　　其实这个思想也可以做在App层面，把相同的逻辑搬到App应用中，从而减少访问服务器的频率。有些公司已经在App所使用的服务器接口层面做了类似的缓存策略，但是还没有在App中尝试实施这种策略。
　　结束语本人从事App开发4年时间。当初比较贪心，iOS和Android是一起学的，这就导致了精力要一分为二，结果哪门技术都做不到非常精深，而我又额外花费了很多时间在项目管理上，这也是我所喜爱的一个领域。所以上述若干文字，盘点了2015年App领域的若干新技术和新思想，但难免挂一漏万，或文中观点有所偏颇，还请各位读者多多指教。
　　最后，再奉献给读者们一个建议。微信这个工具大家经常使用吧，我们经常收藏朋友圈中别人分享的一些好的技术文章，但当时看的并不是很仔细，是时候把2015年收藏的所有技术文章重新翻出来研读一遍了，我这几天就在干这个事情，收获还是很大的。