控制进度的问题

你还是没有回答我的问题。其实我的想法很简单，就是你究竟是怎么知道现在你的项目进行到哪里了，而现在到达的这个点又在项目的进程中的什么位置。并且这个进度是只有你知道，然后转述给别人，还是大家都用一个评测系统自己去计算出来。
其实你已经做得很好，因为你说你的项目切分很细。不过我想进一步知道，这个细究竟是基于什么的细——是基于项目的需求，还是基于程序的内在结构。如果是基于需求，那么你又是如何知道这些需求究竟代表了你代码结构的完成情况；如果是结构，你又如何知道这个是如何反映项目需求的完成情况。这个结合点在什么地方，你又是如何给客户或者投资方解释这一结合点的。 

o6z为啥总能把我模糊的地方说得这么透彻呢
我们目前的做法基本上以程序内部结构来分解任务，进而构成项目进度，这样的好处是开发组能比较好的把握开发进度，但老板又往往从需求的完成情况来了解项目进度，每次老板跟我要开发进度报告的时候，只能凭感觉编一个大致的数据，不知o6z在这方面有什么好的建议没有

当然可以，不过需要等一下。
我现在使用FDD，可以解决这个问题，而其他的方法我觉得也存在。等大家有时间了，我会专门讲一下全部的内容，算是给javaeye3.0献礼。

  继续前几天的话题，关于需求和结构契合度以及在进度上主要表达那个部分的问题？

  从o6z提出这个问题之后，我仔细考虑了2天，并努力回想以前是如何操作的。结论是似乎没有什么明显的冲突。
需求和结构上可能最大的问题就是，一个看似简单的需求需要一个庞大的程序结构来支撑。或者一个看似简单的需求变动，会影响到项目的整体结构上的变化。出现这种情况，在进度上说明清楚就行，同时说明，需要多少时间可以完成，或者调整需求的开发优先顺序。这一切都是随时告知运营组或者和他们协商过。
  
   前者从表面上看就是， 需求进度无变化，程序结构却在搭建中。后者，则需求变根需要很多时间和精力。
在操作上会明确的告诉运营组“开发组在处理基础框架，或者修改基础框架，或者搭建基础框架“。基础框架或者说是底层框架（平日中应该都是如此说的）

   日常的对运营组的进度说明，都是按需求来的（按结构他们也听不懂）但是并不是完全不提结构上的问题，基本可以分 总管理后台，前台页面，和用户管理后台三大块来的。但是前期，会告诉运营组，数据库搭建中，底层框架开发中，总管理后台的那个部分会在什么时候开始.... 等结构上进度，以及需求上实现何时开始 。

   具体的开发，基本的顺序，就是 数据库，总管理后台，然后从网站首页开始，置顶而下的开发全部的页面，同时随时和运营组通气，并根据他们的需要，调整开发优先度。这样，从运营组的角度看，他们会先得到总管理后台（可以添加基础数据），首页，其他二级页面，以此类推。这样下来，就算运营组完全不懂技术，过了初期开发阶段，运营组也能够大概的估算出总体的进度情况，如果当中出现技术难题，需要时间解决的，马上告知，这样运营组和开发组就在进度上不会因为技术问题导致有太大的时间估计偏差。

  没有明显的冲突，我感觉关键还在于项目的透明程度要足够大。让项目相关的人员知道目前项目的情况，也许是进度，也许是技术难题，也许是其他的。 说清楚就行。

靠，误操作投了个隐藏帖，呼唤大家来挽救。

项目的透明度问题，可以说是一个基础性的重要问题。不仅仅是进度方面，而且在其他方面，这个问题一样是关键性的影响因素。这一点我想我们的认识相同。
那么我们需要分析一下不透明性来自哪里。显然对于进度这个问题，业务人员往往是以业务的完成度来核算，而开发人员则以结构的完成度来核算，财务人员则以时间距离来核算，管理者则以资源的付出与回报来核算。大家虽然在一个项目中，但是却操着不同的语言。这恐怕是不透明的根本原因了。
那么面对此种问题至少有两种策略，一种是解释自己的语言，也就是jack现在做的。这是一种很容易想到，并且很直接的做法。如果大家互相间非常信任，并且合作时间很长，无疑会是有效的，就如同现在jack说的一样。另外一种就是设计一种世界语言，用来在各个角色的人之间沟通，我现在的努力就是在这个方面。
当然我们来看jack的实际情况，其实各个不同的角色对进度的问题看法并不相同。也就是投资人觉得进度还应该快一些，而开发者则认为需要保持一个合理的速度。这种情况其实就是投资人觉得你应该更快的满足我的需求，从而获得更多的利益；而开发者则认为构造这样一个结构需要的时间已经不可能再压缩，否则会付出代价。这个时候其实就还是回到前面那个问题，也就是我可以给别人解释清楚我的语言，但是价值体体系则还是不同的。
说清楚，并不能解决价值的核算问题。这其实就是我建议大家思考的问题所在。

投其所好即可

你做个网站都那么难，完了，我们那种飘洋过海翻山越岭的工程项目不用做了～

其实，我觉得，你还是要搞清楚产品和项目，我也在做一个网站，承载公司内部业务的，做了快10年了，中间经历的项目不计其数，现在仍然同时有多个项目在运行着。
如果你是在做项目，那么项目一定有范围，有交付时间点，如果只是想知道项目的大概进度，那么划分一些阶段并设定几个里程碑点是简单的做法。
o6z说的核算的问题，您太厉害了哇，我们花了几KW在研究还没搞清楚的问题呀～

那么里程碑又是如何设立的呢？在里程碑之间就不需要掌握进度了吗？特别是你们这些有多个项目同时存在的项目，如果公司要求精确核算，精确管理，你那个里程碑基本就没啥用场。
而且我认为网站开发的一些特点是里程碑设定比较困难，要求的速度比较快、时间短，先上线再修改是普遍情况。

会有公司天天核算吗？不会，呵呵

我们是月度核算的，就我所做的软件实施类的项目来说，
财务核算：比较简单，通过工时算出人力费用，加上软硬件费用和其他费用，很精确。
已完成工作的进度：通过WBS可以算出一个进度，有两种类型（工时型，工期型），算法不同，不过确实都不精确，只能参考
项目管理部门还会给我算两个拍马屁的指数CPI,SPI，我不知道他们咋算的

里程碑，也简单，就是几个重点的交付件，例如概要设计完成、代码开发和系统集成测试完成......里程碑之间，恩，还有更细的活动和小里程碑点，例如我的代码开发和测试是分几次迭代......在WBS中会体现，不过我们的任务粒度还没有LZ说的那么细

我们的系统承载公司内部业务，可用性要求比较高，做一次变更意味着一次风险，所以我们对质量控制的是比较严的，如果是因为bug而修改做变更，那是我们工作没做好，要挨板子的（当然肯定会有bug，但是不能紧急重要到要为此单独变更一次，一般的bug可以临时先找些替代方案，然后搭其他项目的车再上线）。

系统所承载的业务，肯定不可能通过一个项目做完，就是已经做好的业务流程，以后也可能变，这样的情况导致系统修改，那就是另外一个项目了。只要公司存在，我想我们这个网站的项目会无穷尽地做下去。可能是我们现在整个流程运作比较顺畅了，基本上每年我们要做什么东西在年初就比较明确了，然后设置几个产品路标，每个路标可能包括几个项目，按预定计划慢慢做就是了。

先前我可能有点误会您说的核算了，我理解的核算包括成本确认、收入确认、项目工作进度确认......虽然不同角色的核算所看的角度不同，范围应该是一样的，和项目或产品范围一致

变化总会有，但是是不是需要那么频繁的变呢？

你们的项目，可以说更加类似于项目，而不是产品，更加不是网站。这样的情况下，一般企业不会采取细化管理的方式。但是对于很多的产品和网站开发，细化的管理还是很有必要的。这个细化管理的活动，在开始仅仅会带来很少的成本增加，而建立好系统和习惯之后就只有产出没有啥成本投入了。关键是由于有了细化的基本，那么项目中的相关人都可以很直观的看到资源流转以及项目的生产情况。
对于里程碑的说法，我想你还没有理解，其实很多需要多项目协作的时候里程碑根本就效果不大。比如你是一个业务专家，日程是满满的。那么你确定好了，下周三可以有2个小时参与项目A的业务讨论。而要把你的参加价值增大到最大，那么就必须做很多准备活动。而这些准备完成的太早，就不能很好的反映当时的项目情况，如果完成太晚，数据又收集不齐全。那么你的里程碑能不能起到很好的作用呢？我看作用有限。类似的理由还有很多。而另外采取非里程碑和里程碑结合的方式，本身就不会带来成本的增加，而且很可能会带来成本的降低。比如可见性高了，浪费的点就能明确的找到了，就可以针对性的根除了。等等还有很多好处。
关于核算的问题，你本也没有理解错误。其实我的意思有两层，一层是针对这个帖子的，另外一层是一个全面的核算体系的。而不过由于角色的角度不同，立场不同，实际上他们理解和把握的项目范围也不同，能理解的数据含义也不同。

关于变化的问题，不是你需要不需要变化，而是网站开发这个事情，我还就没有见过变化少的。这里存在一个你意志不能控制的角色，那就是网站的客户。基本上客户的喜好是随机的，希望通过调查和市场分析得到其规律，并不比在开发中更多的引入变化来的成本更低，而且往往会更加昂贵。