最近在做实验，看怎么样才能够提高小团队的的项目开发效率。我碰到的场景，相信很多互联网公司也会碰到，在有限的时间、有限的资源情况下完成一个项目，并且在一定时间范围内升级功能达到具有竞争力。

这里定义的小团队是有一个项目经理，1-2个程序员，1个网页设计，测试则是不同项目组交叉设计。

原来存在的问题：

1 团队之间口头沟通多，书面沟通少，项目开发到后期发现会遗漏一些重要功能或者出现原来想到的问题。
2 页面设计和程序开发发生死锁，导致进度受到影响。
3 功能设计描述不清，造成页面设计和程序开发理解上的歧义。
4 测试时间的紧张造成没有很多时间和资源进行错误修正，影响产品质量。
5 由于进度始终不能如期完成，总是有项目的特性没有完成，造成团队疲惫，没有成就感，影响士气。
6 产品开发无法达到设计期望值，所以无法和竞争对手拉开差距，影响公司整体战略。

我再借助一下“敏捷开发”这个术语，下面的方法绝对不是真正的敏捷开发，只是觉得这个词可以很好的描述我要表达的意思，当然也可以称呼为“有效率的逼迫性的按照时间管理的项目基于有限资源的小团队开发方法”

首先是准备工作：
1 通畅的电子邮件系统，因为大量的消息将通过电子邮件来传递。这一点我仍然不满意目前自己团队使用的的系统，我理想中的电子邮件系统是google mail企业版，免费，并且7G的容量，加上google日历和文档共享，足够小团队使用了。不用再担心自己的邮件服务器什么时候会出问题，google 日历可以和很多中应用同步，不管你是windows，还是leopard或者iphone。

2 trac。我一再推荐使用trac来管理项目特性，简洁有效。除了安装稍微有点麻烦，基本没有缺点，基于sqlite数据库，便于管理。trac支持多人 多项目的管理，可以有效的非配工作，不需要再手工写工单了，当然也不需要昂贵的ms project了。trac是免费开源的软件。

3 svn。不用再说了，如果主要还是基于windows开发的话，暂时不要去想git了，用svn足够应付小团队开发所需要的版本管理功能，加上强大的windows桌面端tortoiseSVN的话。

4 im工具，推荐使用msn或者gtalk，后者的好处是所有的对话都会存盘，便于以后搜索。如果你使用的mac的话，那么只有adium了，足够了。 windows的话除了原生的那些im程序以外，推荐pidgin，除了可以集成多个聊天帐号以外，还可以支持otr加密方式，这样windows、 linux下的pidgin+otr和adium(本身自带支持)之间的对话都将是加密的，基本不能窃听。

开发工具项目不同，各有所长，这里就不说了。

现在说说我设计的开发流程，先来说说要达到的效果：
1 目前设定所有项目在每周可以发布一个build版本，除了第一个b1达到最基本要求以外，之后的b2、b3等等要每周增加需要的功能，功能可能来自用户，可能来自市场竞争所需。
2 每一个build包括功能设计、特性分解、可行性分析、页面设计、程序开发、功能测试、整体测试。
3 根据项目需要完成的指标，一般网站来说，无非是用户数(包括用户活跃度等)、pageview(包括uv)、商品(条目)数量、成交情况等，每周根据数据情况来调整本周build的功能和优先级，来尽可能的完成既定指标。

所以前面说这是一种逼迫式的开发，对于项目管理的要求很高，这不是传统上用个project画一个甘特图就可以的，而是时间和资源的限制，效果的逼近。

目前在公司里，有两个项目采用了这样的方法，刚刚开始不久，还不能说取得很好的效果，不过感觉已经比以前效率高了。

整个方法的实施过程如下：

1 每周一开会讨论本周build要完成的特性，并估计下一个build要做的特性。本周build特性一般在10个以内，排好优先级顺序，按照1个程序员 3-4个人天来计算。下一个build甚至后一个build的特性确认主要是列出必须做但是在本周肯定来不及实现的功能，这样可以根据之后的数据分析来再 次客观的评估是否这个功能真的是”必须”，或者实现的细节有否和初衷有所差异。另外，这样可以让整个团队从产品角度清楚自己项目在本周会做到什么样子，下 周什么样子，对于功能设计、数据监测、测试、市场推广都有益处。一般开会时候要确认项目上线时间和相关工作计划，主要是数据是否有升级、服务器部署是否有 问题、数据监测方法、测试计划以及最重要的运营安排。

2 开发，这个就和一般项目没有什么区别，按照规划好本周要完成的特性的优先级进行，所有重要的沟通全部用邮件进行，项目经理需要在最快时间内响应需要决定的事宜，并有可能去调整特性优先级、build特性规划等。

3 bug and fix，当项目在运行的时候，会暴露出诸多小问题以及一些可以改进的UI、UE和功能点，为了不影响原来build在本周设定的目标，这些一律归到bug and fix这个trac上的milestone。然后区分几种情况：

致命bug：立刻修改，因为已经在运行了，所以需要立刻修改。
提升UI和UE：根据本周工作量，纳入本周的build或者下周的build，在下周一的会议上提出。
功能优化：在下周一的会议上讨论，原则上本周build不考虑。

凡是完成了的bug and fix都在close后注明是在哪一个build完成。

4 测试，测试通过邮件做内部测试，一般没有时间和资源做广泛的外部beta测试和用户面对面访谈，就只好不同的项目小组交叉测试了。测试人员可以当着项目经 理或者开发人员逐一支出问题在哪里，这样便于项目经理描述问题。所有发现的错误和问题记录到上面的bug and fix，致命错误由开发人员立刻纠正。

5 发布，一般每周四开第二个会，决定是否进行发布，以及发布中可能存在的各类问题，当一个项目进行到build3之后，一般发布上也不会有太多的数据迁移和 运营准备要做了。发布前做好数据备份当然是必须的，同时视情况调整产品运营手册等。周四的会基本上也可以知道本周的工作量完成情况，再思考一下，下周一又 要开始新一轮的build了。

6 竞争对手分析，如果是竞争性产品，项目经理要有很清楚的产品路线图，以周为单位来知道自己负责的产品目前和竞争对手差距在哪里，若干时日之后，还有多少差 距。一般得不到竞争对手的数据，所以各类数据只好自己进行监测和目标设定了。当你的产品经过一年50个build的发布，我想竞争对手日子会很难过了。如 何针对竞争对手设计产品，我还有一个曾经在2004-2005年获得收益的”半盲法”，以后再分享。

基本流程就是这样，实际实施还有很多细节，比如文档管理、设计标准规范、开发规范、对于销售的支持和响应带来的影响、矛盾的功能如何平衡、怎么进行数据分析(怎么看懂google analytics)、设计、开发、测试、运营的同步和异步操作等。之后慢慢再讨论。

小团队的项目开发，还有一点就是士气和团结，不团结的团队，没有士气的团队，不喜欢互联网的团队，那么就算有再好的方法，也是无用的。这个话题已经超越项目管理的范畴。