2015年项目管理与技术动态，我说给你听.docx

2015年项目管理与技术动态，我说给你听 PAGE 7 2015年项目管理与技术动态，我说给你听 项目管理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和Ser