控制进度的问题

1.让每个人都尽量保持100%的输出功率（在工作日内），这样的话，大家可以习惯同一节揍，活来的时候不用磨合，热身之类的。
2.如果作项目之前作一下项目的评估。会有个大概的日期。这个是经验数据。作为进度基础数据，之后以这个数值的400%为向上的报告。
3.把这个大概日期分成N大段。每一个大段都设定完成日期，成为里程碑。
4.里程碑的大小不要小于一周不要大于四周
5.在完成第一里程碑时计算完成时间与预定时间的比值。
6.比值大于150%时将基础进度计划的每一个阶段都乘以这个比值重作进度表。
7.当比值小于75%时同上。
8.如果总计划值大于你一开始提出的400%的话，
也不要降低计划值。比如一个问题卡住了。拖了两周才完成，
那么后面的比值会很大。。
但计划不要变。还是以计划为准。只有第二次超期才进行加班。

谈谈我的看法。

我想在不同职能方向间做统一是一件比较困难的事情，别说投资人和项目经理的目标不同，就是程序员和项目经理之间的目标也不一定相同，如果再加入对这个项目做出来赚不赚钱的考虑，需要考虑的事情就非常多了。如果真的有这么一种通用语言，用它可以衡量“真实的”项目进度，这种通用语言估计也会非常的复杂。比如说google给员工20%的时间做自己想做的事，这时间怎么衡量？从项目角度来说这段时间没有任何进展，但是从老板的角度来看，花了这20%的时间，是给公司增加了知识积累，是有利于公司长远利益的。如果一种通用语言要涵盖各种利益实体，那么这种语言可能还要考虑财务经济管理等内容了。

我不太了解实践中如何做比较合适，应该沟通还是比较好的方法。如果是在理想的状态下，我试着分析一下：

1. 利益个体的不同目的之间有相交关系，有包含关系，有相离关系。如果能够把任务划分的足够的小，就可以说某个任务符合某某实体的利益，而与某某实体的利益无关。

拿google的例子作比，对于一个程序员花了两个小时看与业务无关的编程书籍，这件事可以说完全符合公司的（长远）利益。但是却完全不符合当前项目的项目经理的利益。

2. 如果能够有一个像jira似的软件来监控每一个小的任务，就有可能监控整个项目的进度。其中，每个提交的小的任务需要有如下特点：
该任务需要有属性来指明完成了该任务，哪哪个利益实体受了益，对该利益实体的目标实现有百分之多少的贡献。

比如对于投资人，一个项目做了20天的框架准备，但是一个能用的模块都没有，从投资人的角度来看，这个项目完成了0%，因为他现在拿出这个项目来，连一点用都没有。对于他来说，模块相当于完成的百分比。由此来划分，就可以估计出一个模块中的某个功能对投资人的贡献多大。

通常情况下，对不同利益实体目标的完成度的估计，我想应该有专门的人来负责，然后由不同利益实体本身来作监督。首先是因为任务可能很细，由利益实体来估计完成进度，缺乏精力也缺乏技术背景。而如果不作监督，专门负责的人也不可能有各行业的不同而且复杂的知识背景。

3. 基本上，我想如果能有这样一个软件，或许可以实现这样的功能就是：当我对软件说，我是投资人，软件就显示对投资人来说任务完成了多少。当我对软件说，我是PM，软件就显示对PM来说任务完成了多少。这些是通过对项目中的小任务进行累加得到的。投资人也可以观察从PM角度来说项目完成了多少，这样他就可以两方面都有数。

4. 对小任务提交可能是一件比较繁琐的事情，但是看看现在的JIRA，基本都是小任务提交。对在公司的时间的利用方式的管理，应该只是一个习惯适应的问题。

一些粗浅之见。

这种通用的语言会复杂吗？这是一个非常关键的问题，有很多背景的情况需要考虑。首先一点是，你讲自己的意思，解释给对方听是不是很复杂呢？或者说技术人员对非技术人员解释程序的构造与程序的功能之间的对应关系是不是会很复杂呢？我想这个事情一般情况下会很复杂。而通用的语言是什么样子呢？当然这个语言并不是真的语言，它仅仅是一个比喻。它仅仅是在功能和结构之间可以架起桥梁的一个结合点。也就是需要按照需求的构造进行细分到一定的粒度，会与结构按照结构的原则进行划分得到的粒度，存在一个对应的关系。找到这个关系，就找到了结合点。这个点就成为一个最基本的单位，既可以用来衡量需求，也可以用来衡量结构。也就是大家在这个点上达成共识，并以此来确定和衡量系统的情况。那么问题的关键就是，如何找到这样一个能反映各方关注，同时使用方便，而对各方的利益有实际意义，这样一个点。其实即使如JIRA这样的东西，做的事情也就是这个思路。只不过它还不能保证，这些细小的任务是有足够的均匀性，也不能保证这些细小的粒度对需求来说也是均匀的。
我们经常讲应该加强沟通，那么沟通仅仅是我们用来讲一下的吗？难道不应该有具体的工具，手段，方法来协助，来完善，来增强吗？难道面对面的交流，就仅仅是坐在一起谈话那么简单的事情吗？而交流的有效性的一个关键的保障，不就是用事实和数据来说话吗?当然事实和数据，需要保证其有效，也需要保证其获得的合理，还需要保证其获得的便宜。不过不能因为有这些限制，就否认可以有方法完成这些工作了吧？更不能因为有这些要求，就认为这样的事情，一定是复杂而困难的吧?
其实自从我推荐FDD的方法以来，我就一直强调，FDD的可见性和可操作性，这一点我想大家在没有接触这个方法前，是不会有体会的。当然这个方法，并不是那么简单的靠自己看书就能很简单的掌握的。就如同你看过一部XP的书，回去不可能就那么简单的实施XP一样。但是在有经验的人的指导下，通过实践的总结，这个方法掌握起来还是比较简单的，至少比XP要简单。而其独特性，还在于可以和XP以及Scrum很好的配合，从而形成一个比较完善的系统。同时我经过一段时间之后，还发现FDD的复习功能很强大，也就是可以积累的东西比较多。而且在商业和业务方面也可以使用这个方法。而且在产品设计方面，由于其可积累性，也造成了很多的优势。
问题的关键，不在于存在问题，而在于你是否试图去解决问题，进一步是找到解决问题的方法。

对于项目进度主要是要看产品或项目的功能的需要，所设计的功能和模块的工作量，还有就是目前公司对与这个产品或项目的技术积累，比如开发框架还有目前同事的基本条件来计算出来的，

汇报一定要把风险报告也提交上去，让相关的人都知道，

对于员工的每天的工作量，我也不赞成100%工作输出，这样疲劳期很快就会到来，

时间点一定要把握，

可能我表达得不是很清楚。我说"复杂",是从直觉上来说,这么一种感觉。程序进度可以量化，财务状况可以量化，有些高层决策比如GOOGLE那个例子，是不大容易量化的，更像是艺术一些。

不敢说这样的通用的东西不可能实现，只是从我的经验来看，似乎是一件比较困难的事情。我对FDD不太了解，或许有什么好的方法可以把各种不同的目标都可以量化出来，我也很想听听o老的想法。毕竟自己不在这个领域，很多可能性都看不到，只是作为行外人提一些很浅显的想法。

我说的，大概是这么个几个思路：
1. 是否可以把在查询进度时候的复杂的查询过程分割到各个提交中去，在提交的时候估计提交进度，然后查询的时候作汇总。把一个复杂的东西分散到多个步骤中，或许是一个可能的思路。
2. 不一定非要有一个确定的“总进度”，可以让不同的利益实体有各自的进度衡量。然后总进度或许可以加权计算。

仅仅是从自己的经验提供一些思路。如有更好的办法，我也很想知道。

    通用性，前提应该要定义不少关键字。然后把关键字的定义传达到每一层，每个人。交流中同词不同义是非常常见的，这是交流障碍的一部分。而这样的现象的产生，也是复杂的很，但大都和个人的生活工作环境相关。
  
     在一起工作久了，互相影响，互相墨化，同词不同义的现象就会大量减少，也就是有默契和相互信任。

     o6z的想法，最终如果能够实现的话，是不是每个新入职的人人手一本“职场日常交流关键字字典”，要每日温故，直到全部都记下来？ 把融入新团队磨合期改成背字典，学习一种新语言？
    
    其所需的时间成本，估计同样不小。

别说我们国家，哪个国家，或者哪个组织能达到这个程度？原来您是个完美主义者，呵呵～

看了您前面的言论，加上我们正好采用的是模型驱动开发的方式，我想我可以研究一下FDD，也许可以找到一些可以借鉴的地方。

另外前面谈到“通用语言”，“沟通”的问题，我们那个不怎么精确的里程碑反倒是可以起到这样的作用呢

管理是一门软科学，控制是管理工作的核心之一，而软件开发管理和其它的项目管理相比又有相当大的特殊性，进度不确定性比较大。所以软件开发项目的进度控制应该是相当具有复杂性的问题。
我的观点有以下几点：
1、进度控制有精度的问题，任何过于精细的控制方法都是高成本的。适可而止！所以进度一般都是估算值。（除非项目还没开始或已经结束）
2、进度控制和项目风险密切相关，有时候风险控制的好，才能保证进度。
3、项目目标要明确或基本明确，否则进度控制就是空谈。最好每人每段时间的目标都要基本明确。
4、不同的项目管理阶层可以对进度有不同的算法，只是数字要自己保证是大致正确的就行。
5、很多时候还是要通过交流来保证每个级别上的进度控制。

你说的这个就是《敏捷软件开发》里面说的方言的含义。这个方式当然是最有效的，而形成这样的一个方言语音需要长久的积累。作为一个新人，无论你采取什么方式，想去学习这个语言都会很困难，以至于不可能，这是因为这个方言完全是建立在共同体验的基础上的。那么问题就来了，你是耐心等待一个方言的形成；还是定义好大家各自的语言，然后在慢慢等待方言来替代？我想没有人会傻乎乎的在那里干等的。而同时请注意，这个确定各自语言的过程，也是方言形成的过程，因为在这个过程中也是一个建立共同体验的过程。
而问题还有另外一个方面，不是在所有方面都需要确定一个完整的语言，更不是在所有方面都需要一个特定的语言去表示。其实也就是你只需要在关键的地方，建立一个普遍遵守的语言表达的契约。
而关于进度这个事情，其实很多人都没有考虑到一个背景。那就是绝大多数时候，都是技术人员在向其他人员解释进度究竟到达什么地方了，而不是其他人本质自己收集的数据，建立自己的进度指标。也就是说不管你怎么搞，数据的采集和分发，都是技术人员的事情。而数据的解释，你要么选择在前面一次解释清楚，随后仅仅是小规模的维护。要么就是选择，遇到问题再解释，一直修修补补的方式。究竟什么策略有效，我想大家自己可以根据自己的实际操作得到答案。

我觉得这里的讨论也存在词汇歧义。如果O老能把自己考虑的,比较成型的东西写出来,讨论应该会更有的放矢一些。大家都是按照自己的背景在说,会有各自不同的方向。然而方向可能并不那么重要,重要的是能够坚持一个方向,在一点上把问题和解决方法细化.