一个“经典”的项目总结，求拍砖

在公司带的预订和资讯项目的过程中收获颇多，但是也暴露了不少的问题。总结大致以下几点

1. 缺乏一个较为长期的计划（不是1~3年的那种中长期规划，而是项目中以周为单位的规划），这样的计划都没有，当然这其中也有很多较为复杂的因素，过于频繁的变更等。

2. 在下达任务的时候没有充分给下属估算各自开发任务的耗时，而是下达的较为强制性的开发要求，例如每2天发布个新版本，其中对于开发人员，及测试人员的抱怨尤为明显。出了员工的抱怨之外，根据 Features, Schedule, Resource 项目铁三角原则，再加上一个质量维度。在有限的人力资源和时间资源下盲目的计入大量的新特性必然会带来质量问题。这么短的时间里开发加入的新特性没有全面完整的测试机会就匆忙的发布出去。如果是有很多用户在使用这个产品一旦有严重的bug出现事故后果是非常严重的。

3. 由于前面的2点便引发了第三点，不少员工说我们的工作，有时候回非常忙，忙得不可开交，有时候很闲闲的蛋疼。过于忙和过于闲对于对于员工造成的影响都不好（过于繁忙会将员工压的不可喘息，太闲容易使员工失去成就感以及忧虑）归根结底导致这些问题。也是反应了缺乏周密的计划所造成的。

4. 从自己的角度出看，也有对做计划有一种恐惧和逃避，我想导致我产生这这种感觉的还是源于，对任务的分解做的不够，以及对每项任务的耗时估算于追求精确而导致的恐惧感，干脆就放弃计划了。另外太僵硬的响应上级的要求，其实上级下达的一些硬指标可以通过阶段性展示取得信任。不必那么死板的一一一安装上级的要求办理。将在外军令有所不受。我想我在这里其实应该扮演一个缓冲带，减震器的。将上级的要求，经过我的调度安排，科学的下达到开发人员那里。不要将不科学，的要求。及巨大的压力带给所有的与员工。要做一个使得上下级均有一个很好的项目过程体验。

5. 给下级安排开发的任务估时没有征求下级的意见，其实在分解任务后，可以在自己估算的基础范围内，在让各自开发人员自己根据任务给出一个具体的deadline,经过双方估算的deadline最后根据项目的总的时间节点综合考量安排。如果紧迫可以在开发人员各自给出的deadline再往前压缩一下。

6. 下达的每一个开发任务都没有给出具体的deadline,这是一个非常严重的问题。一个事情没有截止日期。对于开发人员来说没有紧迫感，对于项目整体来说无法估算当前进度。已经当前任务的进展占总体进度的百分比。已经对整体构成的影响等。

7. 测试的前期介入非常重要, 在项目的早起初步的设计阶段就应该开会早就开发人员和测试人员参加向他们讲述描绘我们将要开发一个什么样的产品和项目，其目的可以让开发人员提前知道要做的是什么事情，让测试人员也明白这一点，明白的同事，开发和测试也可以初步的做一些准备工作，例如开发人员可以做一些技术的预研，实验 测试人员可以准备测试方案，及测试用例等。在这个过程中可以进过若干次会议。随着设计的的越来越清楚详解，大家对所要做的东西也越来越清楚。从而准备工作也做的会越充分。避免早了项目的送测阶段，测试人员没有一个测试计划和用例。甚至对业务逻辑都不清楚。这样工作是低效，无用的。还不说对进度造成的影响。

8. 要做好版本规划工作，每期迭代加入的特性。已经要修复的bug和要优化调整的地方。都应该在特定版本中做规划，开发，测试。在规划做好后就应该同步的进行开发及测试准备工作。

我看完了你的文档，感觉你们应该是敏捷开发。我说一下我的看法
1.迭代周期一般在3周左右比较好，这是我们公司应用多年的经验。
2.版本控制，采用持续集成确保随时可以发布新版本的软件。
3.员工在迭代中的可选任务是可以增加和减少的，这样就不会出现大家都很忙或太闲的情况。
4.任务分解和时间评估是要大家一起讨论决定的，不是经理一个人说了算，对于某些不确定的任务，可以先估算一个时间，分配给一个人后，经过一段时间对任务的接触后在重新估算就可以了。当然这个时间一般在1-2个工作日必须确定下来
5.项目初始阶段，测试人员和开发人员的介入是必须的，没有对整个项目的整体理解，员工会对项目有抵触心理，而且不知道为什么这么做而做是很可怕的，会降低积极性和缺失成就感。
谢谢！

不错。你可以分享一下你们的经验！

这种方式下。你居然还能推动到项目完成和上线。不得不说。你还是很有方法的

如果我们的项目组长，知道这样去管理项目，我们也不至于累成这样。没干多少事，整天觉得累的不行，跟测试的去纠缠，跟现场实施人员纠缠，跟领导纠缠，喋喋不休。。。

分而治之，分而治之，分而治之，分而治之

版本管理，持续集成也是必须的

对这种工期比较长的项目，这位LZ的建议可以考虑一下。

我也说说我们公司的情况

1.迭代周期 一般都是3周，需求按照优先级排序，砍掉饱和意外的需求，如果中途有临时增加的，继续砍需求。
2.持续集成在一个项目上坐，用maven，自动集成，感觉唯一的麻烦就是 需要开发人员必须写junit。
3.每次计划会议后，员工可以自己选择任务，每天站会，员工更新任务状态，可以实时看出burndown 图，如果发现超过预计时间，及时做调整。
4.任务分解和评估，这个是在计划会议的时候，全员参与，产品经理讲解需求，开发测试有任何疑问都可以提出，然后所有开发没人互不影响的评估工时，然后拿出一个大家认可的时间。预估的时候就必然涉及到拆分任务这些。

5.测试开发介入，是从计划会议开始介入，计划会议结束后，测试开始写测试用例，开发开始领任务，然后分解每一个任务为可执行的最小单元，实时更新任务状态。

整个敏捷过程中，出的问题最多的还是需求，计划会议开着开着 就涉及到整个具体的实现上去了（毕竟大部分都是开发），而且需求很多都不明朗，讨论了一番后，产品经理 不确定 就只能等到他会后确认完。而且敏捷过程中，会插进来各种紧急需求，有时候甚至不得不打断整个敏捷过程。

总结得很好。

针对第1点：项目一般都要作出全部的计划。如果是迭代，作了整体的大体的计划，再优先做出第一个迭代的详细计划，有里程碑。

针对第2点：分解时，可以以一个功能为一个大任务，然后再分子任务，子任务以1~2天能完成为好（3天以上就算长了）。分解完了，和团队成员一起再调整。

针对第3点：任务虽然在才安排时是平衡的，但有的人完成快，这样就后期就不平衡了，这时可以适当的让他接别人的未开始任务。用一个甘特图来跟踪任务（绿的表已完成、灰的表未开始、黄的表正在进行），这样每天都可以更新颜色。
每周的周一发本周的任务安排，这样大家知道短期目标。每天下班前询问大家的工作进度、问题，以更新甘特图。

针对第4点：每个任务在富余10%~20%的时间，大家都临时办个事或干什么的，任务太精确了就无法办点别的事。再则你也估不了这么精确，上班谁也会看会新闻、边聊天的，按华为的估算，一天认真工作的时间平均在4个小时。

以过程控制为工具，最后产生正向的结果和对结果负责的人