控制进度的问题

   站在投资人的角度，项目进度也许是越快越好（这点我是假设的），但是各位做项目管理的同学，对于控制进度是如何考虑的?
 
   先说说我自己的.在项目时间允许的情况下,一般我不考虑让项目提前完成,或者提前的太多.如果每个人员在全力工作的时候能够输出100%的功率,那么我更新希望能够让他们保持在60%-80%左右的每日输出功率. 以近可能的延长每个人的工作寿命.
 
   当然这样的情况下,项目进度就会变得不快也不漫.能够一定完成,但是就是需要些时间. 不过可惜这样的项目一般不多,更多的都是比较紧张的.

剥削与被剥削。。。。
剥削者当然希望工人8小时干满。
所以就有了监工这个岗位。
项目经理也一样。。。。

我觉得从投资人的角度看重要的不是快，而是在预定期限内按质完成

我还是想听一下，在你那里啥叫进度，而你又如何知道进度的？

基本上都是每日跟踪,汇总.

因为都是内部项目,大部分的项目的完成时间实际上是一个可以商量的模糊界限,只要不超过某个上限都成.
整个项目任务切分非常细,细到每天都需要重新发布任务.换句话说,每人每天会领到根据他们工作能力定下的任务,任务则根据项目在项目中的优先程度而定. 一般情况下这样的任务,每个人最多不会超过2天就可以完成.当然项目进行中的变动也不少.不过因为每天都是重新发布任务,所以随时可以调整.

项目起始对于完成项目需要的时间只是一个估计,大约完成三分之一之后,基本上就已经很清楚还需要多少时间完成.
  大致情况就是如此了. 也不知道这样的方法是否合理.不过就目前团队的情况来说,这样的工作方式能够保证目前的新项目开发,既有项目的维护,和二期制作的各种任务的完成.

你还是没有回答我的问题。其实我的想法很简单，就是你究竟是怎么知道现在你的项目进行到哪里了，而现在到达的这个点又在项目的进程中的什么位置。并且这个进度是只有你知道，然后转述给别人，还是大家都用一个评测系统自己去计算出来。
其实你已经做得很好，因为你说你的项目切分很细。不过我想进一步知道，这个细究竟是基于什么的细——是基于项目的需求，还是基于程序的内在结构。如果是基于需求，那么你又是如何知道这些需求究竟代表了你代码结构的完成情况；如果是结构，你又如何知道这个是如何反映项目需求的完成情况。这个结合点在什么地方，你又是如何给客户或者投资方解释这一结合点的。
其实搞明白这些问题，控制的问题就解决的差不多了，其余的就是如何控诉速度和使用何种策略的问题了。而如果这些问题不解决，所谓的速度控制和策略也都是无用之谈。
也就是快于慢并非关键，关键的是快和慢究竟是什么标准确定的。而在开发者和项目所有者之间如果不能在这个判断标准上达成共识，自然就会对速度存在完全不同的看法。

最近我刚好在总结FDD方法在实际中使用的讲座，其实开始就是研究这个问题。实际上我也是经过多年的思考和摸索才有了点可以使用的东西，而不同的人由于方法的不同，在这个方面差异会非常大。所以说你如果不能从源头上解释清楚，那么不要说别人，就是你自己都无法对你面临的情况作一个合理的判断和解释。

这样吧，o6z，我先不回答你的那个关于 结构和需求之间的同步率的问题 （同步率这个词来自EVA，就我的理解是表示驾驶人员和同被驾驶机械的合二唯一的程度）。因为我也需要和熟悉管理的同学讨论下，目前的管理是否合理的问题。

   首先，本人属于野路子，对于各种项目管理，开发方法只是知道大概，从不想去了解透彻和应用。具体原因吗，我在别的文字里面提起过。

   先从大点的环境说起。就我个人的理解，项目管理只不过是整个项目运营的一部分，很受项目运营方式的影响。从大环境来说， 整个项目需要运营组，美术组，和开发组三个小组的协同才能完成。 当然运营组是每个项目一个的，美术和开发小组则是全部项目组共同使用的。

   项目开发的流程。
  
   一。 项目方案的确定。
 
   运营组起计划，写出各种方案书
   开发组进行技术可行性考核
   运营组再修改方案
   以上若干循环，到最终确定方案
   然后运营组画出全部的页面效果。

   二。美术方案的确定
   美术组根据项目方案和页面效果确定网站初始风格。（附带一句，本公司是自己运营网站的）
   运营组和美术组最终协调确定美术方案

   三。初始项目结构的确定
   开发组根据方案确定每个功能和每个功能需要表达的内容（就是传统意义上的数据库表和字段）
   运营组根据开发组提供的文档作最终确定，需要那些具体的内容。修正项目方案。

   四，详细美术设计
   美术组根据修正后项目方案，开发组提供的详细内容结构文档，以及运营组的页面效果图，设计出全部的页面。
  
   五，美术方案的修正
   开发组和运营组根据美术组的工作成果提出修正意见（运营组从运营角度，开发组根据技术实现可能性）。运营组最终定稿。美术方案最终确定美术方案最终确定。

   六，美术方案具现化，开发组开始
   到这个阶段，美术方案就可以定稿并作切割，开发组开始确定基础结构和总管理后台的开发。运营组的需求变动开始冻结，除非是根本性设计问题，美术组和开发组不在理会需求变动，一切需求变动仅做记录。
  
    七，开发，测试，修改
    第七部分，先不提，后面再说。
  

  综合上面，个人认为整个过程最重要的部分是，一项工作和一个规则。最重要的工作就是  运营组必须提供页面效果图。运营组的人必须通过纸和笔把他们想象中的网站最主要的版面都画出来。一个规则，就是开发过程中的需求冻结。第一项，保证需求不变形，第二项保证开发过程不被过分打扰。如果没有这两项工作，接下来的项目开发管理就很难操作了。

  上面是流程上的。光光流程还不能说明什么。 下面说下，设计思想。

  网站的一般营运方式就是不停的修改，改不下去了就改版。（没见过第二种方式，那位同学有见到过，提醒下）

  如果转换成软件工程的说法，网站项目实际上都是介于 原形法和迭代法之间，特别是自我运营的那种网站项目。
 
  需求变更了，就不停的修改，增加功能。需求变动的太厉害了，就干脆整个网站抛弃掉重新来过。

  于是乎，项目全部的参与者的都抱有一个想法。不需要设计的很完美，这本身也完全不可能完美。我们的集体口头禅是 “先这样，以后再说”。说来汗颜，不过的确，这句话经常说。每次仅是讨论出一个初步可行的结果，然后实行，然后再根据各方面的反馈重新修正。如果无任何反馈，那么就是最终设计。

  于是项目开发小组就是在这样的环境下进行每日的工作的。（先上班了 to be continue... ）


 

我最近也在思考网站开发到底是项目开发，还是产品开发。一个总的感觉是，一种特殊的产品开发。除非这个功能只是暂时性的、阶段性的，比如应付某次活动；功能要求和性能要求都比较明确，比如就是一个可以容纳3000人同时在线，50人同时发言，等等的聊天室，而且推出之后也不可能或者不需要做改进。你上面的发言，加深了我的这个印象。

实际上你站在甲方的角度上来看的话就没有所谓项目开发和产品开发的区别，区别在于产品是面向可控用户的还是面向大众用户的，换句话说就是用户是不是非得用你这个产品不可。用户是否有选择权这一点让软件质量的不同方面的权重发生很大的变化，这就造成了传统上认为的项目开发和产品开发的差异，以及企业应用和互联网应用的差异。

确实如此，对甲方而言面对开发者，产品和项目本无所谓。但是如果不存在明确的甲方，问题就来了。这也就是你说的面向可控用户还是面向大众用户的差异。
而前面我已经注意到了你们讨论敏捷在产品开发方面的问题，而对这个问题我并不认为有多么严重，因为产品开发的流程和方法已经在传统行业比较成熟，我现在可以去吸收和拿来。但是对网站这个东西来说，我觉得还没有太多的经验和积累可以供我们参考，所以我对这个方面才有更多的兴趣。
比如这个网站，就是对所有者来说是一个推行其业务的工具，并且还不算最重要的工具，应该如何做。而如果网站几乎就是所有者全面的业务平台，又该如何做。我想策略会有所不同，实施过程也会有所不同。
进一步对于一个流程，究竟是应该让它更加稳定，还是应该采取强力的监控、不断测算成本构成最后不断进行调整，也是一个重要的选择。特别是对网站这类需要经常变更的领域，这个选择更加是一个重要的问题。而进度无疑是一个重要的评价指标。