最近，公司在开发一款新的APP项目，由于APP项目本身的时效性要求非常高，所以项目本身的工期被限制到很短的时间，大概就一个月的工作日时间。在这一个月的时间内，项目本身是从零开始搭建的，并且要承受需求变更、目标变更的风险与开发人员不足的缺陷。这就使得团队之间的配合要非常紧密，合作无间，并且在业务逻辑上不能出现大的偏差与错误，对团队的整体素质要求比较高。而令人沮丧的是，我们的团队是刚刚组建起来的，并且团队中有经验的人员又相对较少。

        说到这里，可能有人会说，既然是这样，那项目怎么可能在这么短的时间内完工呢？其实一开始定计划的时候，我也是这么想的，按照以往的开发经验，确实很困难，因为敏捷开发崇尚的每周40小时工作制是有它的道理的，程序猿其实是一个半脑力，半体力工作者，每天集中精力经过8小时的精神上与身体上的摧残，基本上已经耗尽了身体上的能量。剩下的时间是需要好好回顾一天工作中所遇到的问题，及寻求解决方案，这样才能达到最高的效率。每天长时间的体力劳动（加班）会降低程序猿的思维敏捷度，导致生产出来的代码会有很多bug，从而导致生产效率下降（生产效率＝出产的代码/花费的时间）。所以加班不是个好办法。当然，在项目后期，大家的精神会因为联调（指前端与服务器端的数据交互调试）达到长时间也可以高度亢奋的状态，这也就是为啥通常在项目上线的前两天，大家都要加班加点的工作，而不是按部就班的完成上线工作。所以，当初在领导说出项目的上线日期时，我的第一感觉就是，以我们团队目前的能力（包括人员素质，人力资源）是肯定完不成的，就算加班也完不成。但是领导有所要求，作为团队中的一员，应该尽自己所能的去做。（前提是要保证自己不会坐马桶死）然后，我们的团队开始了一个“尽力而为”的开发过程（其实，大多数项目，我们都是在人力不足，工期短的情况下加班加点熬出来的，这是一个很残酷的现实）。

        这次的开发出现的问题完全在我的预料之中，包括由于开发人员对于需求的理解所花费的时间、开发人员开发水平不足所带来的开发效率下降，负责某项工作的人员由于人手不足导致整个项目开发出现瓶颈，旱的旱死，涝的涝死以及必要的不同开发角色之间的相互沟通所耗费的时间。目前，我们还在开发中，并且截止日也快到了。所以在这么一个时间节点，我对整个项目进行了一下反思与总结，我的想法是试图从项目管理的视角上去尽量优化整个项目的开发进度，以降低除硬性开发时间上的其它时间成本。这里强调下，我没有学过PMP，也不大懂CMMI，我的想法完全是根据自己以前的一些工作经历再加上一点点的意淫出来的，所以肯定有鬼扯的成分在里面，如果各位看了觉得不靠谱，那就当我在放屁就好了，嘿嘿，请不要喷我就行。下面，我就向大家说下，我对于项目的理解。

        项目的管理，包括需求管理、标的管理、设计管理与开发管理。项目管理是一个需要一个人主导并且全员配合执行的过程。

        项目管理以标的管理最为重要，也就是我们这个软件是用来干嘛的。这个问题也许看起来很好回答，但实际上并不是那么容易。因为在项目的每一个阶段，标的是不同的。也许在第一个阶段，软件的目的是用来演示的，第二个阶段是用来给内测用户试用的，第三个阶段才是公测给所有用户使用的。项目标的决定了开发策略，是用原型开发，还是用迭×××发取决项目标的是什么。而开发策略不同，会直接影响之后的开发进度。所以项目的决策人在项目伊始阶段，一定要交心以及频繁的沟通交流，确定好项目标的。一个团队内对于软件在某一个时间段上的目标必须是一致的，这样才能有凝聚力。当然，确定项目目标不是一个轻松的活，是需要领导们把想法从抽象到精华的过程，而且是需要技术决策人与项目决策人深度交流的一个过程（所以这种费脑子的事还是给领导们去做吧，哈哈）

        需求管理，为啥程序猿都恨产品狗？因为需求变更。但产品也是无可奈何，因为人的思维本来就是不断进化的，有些东西不画出来，不多想一下就不可能更深入的理解，一旦进行了深入理解，想法一扩展，原先的设计就会被自我否定掉，然后就出现了万恶的需求变更。那么在需求变更的情况下，能够保证项目的进度么？这个要看情况，如果是颠覆性的，比如今天我要生产苹果，明天改生产梨子了，那么可能就保证不了了。但是如果今天我要生产一个红苹果，明天改成生产一个青苹果，我认为还是有办法的。通过软件架构的设计，我们可以做到，在一定范围内的需求变更情况下，把项目进度的延期降到最低。所以如果我们以项目进度为最高优先级，对于需求管理，第一要控制需求变更的范围，第二就是要设计一个好的系统架构。需求管理，在软件工程上是一个很重要的课题，包括需求文档管理与需求开发管理，在传统的需求管理中涉及到大量的跟踪，追溯文档，并且要与后期的开发代码对应。不过在如今这个快节奏的开发过程中变得不再适用，但并不代表我们不需要需求管理。我们应该让需求管理轻量化，比如通过一个excel来记录需求变更的过程以及原因，并且记录需求变更的通过原因及否决原因。这样产品经理可以通过需求变更了解到自己在产品设计中进入的误区，程序猿可以了解到现在有哪些功能是应该要做但没时间做的。决策者也有一个直观的视图了解到目前软件具有哪些功能，是否达到了阶段性的项目标的。

        设计管理，在确认项目标的与需求后，就应该进行架构设计。架构设计对于一个项目的开发及后期的变更起到了至关重要的作用。架构设计要根据项目的人员配比，人员水平，需求变更以及项目进度计划来确定。它不仅仅是一个技术决策，更是一个管理决策。比如在人员配比失衡的情况下，如负责前端的开发人员较多，但负责后端的开发人员较少，那么这个时候，还是按照传统的开发方式，将所有的业务逻辑全给后端人员去做，前端人员只负责视图和套模板的话，无疑是在本来就很拥堵的马路上放行更多的车辆。又比如在一个需求频繁变更的场景中，还是根据功能来设计API的话，那后期的代码更改，不管对前端还是后端来说，就是噩梦。架构设计也不是一个一劳永逸的工作，针对不同的项目标的，架构也会不断的更新。比如第一阶段的架构设计主要是实现系统功能，第二阶段的架构设计需要优化系统性能，那么第一阶段只需设计好业务框架、数据库结构。第二阶段再来设计缓存策略，心跳监听等。

        开发管理，开发管理是始终穿插在开发过程中的。包括项目进度跟踪，联调计划执行、测试计划执行。他们有一个共通点，就是都是需要多人协作完成的。一旦涉及到多人协作的问题，就需要一个协调者来组织。因为大家在都很忙的情况下是没什么时间自愿去充当沟通者的。但是大家又的确有着信息沟通的需求，因为团队中的每个人都有了解整个项目进度的义务和责任。大家对项目整体进度了解了，对需求了解了才能更好的进行各自的工作。打一个很简单的例子，前端了解后端的API是如何设计的，才能知道在哪个页面调用哪支API。同时，后端要知道前端页面内有哪些内容，才能知道如何去设计API，给出哪些数据给前端。这样在真正联调的过程中，才会有更高的效率，不至于修改很多。所以无论是敏捷开发还是传统开发，沟通是必不可少的。我反对长时间毫无目的的会议，但完全不开会，靠程序猿私下沟通，这个效率可能也会很低。

        好久没写博客了，最近实在太忙。以往只喜欢写关于技术方面的问题。这次不知怎么突然脑袋抽风写下了上面的文字，也许是怕自己一闪而逝的想法被遗忘，所以记录下。往后还是会继续写关于技术方面的文章，话说我的apache系列还没讲完呢。。。