人月神话 发表于 2007-6-22 22:56:34

[原创]培养做项目计划时的系统观

<span style="color: rgb(0, 0, 255);">客户最关注什么</span><br/>
<br/>
产品质量往往是基本,这是一个默认属性。但是做到哪个度仍然可以谈,所以首先要清楚用户对质量要求的优先级,一般来言可能是可用-&gt;易用-&gt;性能-&gt;安全。这一般叫测试类型,另外就是测试的等级表明测试要达到何种覆盖率或程度。这些都影响到项目周期。<br/>

<br/>
除了默认质量要求,项目周期往往是客户最为关注的。这个往往并不是经过详细的估算,排完进度了再确定下来的,而是项目一开始往往就由客户敲定,而项目范围
往往也是在合同就会明确下来。所以跟用户敲项目周期就显得很重要了,根据软件工程和经济学得出结论是:对于一个软件项目我们可以考虑投入更多资源来缩短项
目周期,但当项目周期缩短到一定度以后,投入再多的资源也没有用。因此项目经理谈判的底线为在不考虑人力资源情况下项目能够达到的最短周期,如果这个最短
周期还达不到客户要求,必须缩减项目范围而不是牺牲产品质量。<br/>

<br/>
项目计划重点就是通过调整各个要素,保证项目能够有8,9成以上的胜算,对于影响到项目成功的全部列入风险和关键问题进行跟踪。项目经理在计划完成后一大
半的时间都应该花费在消除不确定性上。项目失败往往并不是进展过程出现太多异常,而是一开始项目经理就不清楚自己有几层把握,一开始也没有分析清楚有哪些
不确定性和关键要素。<br/>

<br/>
<span style="color: rgb(0, 0, 255);">项目周期敲定了再排进度</span><br/>
<br/>
如果简单的认为项目周期确定了再排进度就只能是倒排进度,那说明还没有真正理解各要素的平衡和进度安排的实际含义。项目经理往往根据项目周期倒排不切实际的进度计划,那导致项目进度延期就是必然的事情了。<br/>

<br/>
制定进度前最重要的仍然是根据人力资源情况和项目周期来综合考虑生命周期模型的选择,是瀑布还是增量迭代,这个直接影响到WBS的分解。而WBS中我们又
最关心工作包或任务的粒度问题,这个需要和可用的人力资源配合起来,一个功能模块分解细后可以更多的人力资源参与进来,使更多的任务能够并行,但无疑会增
加前面接口设计和后期集成的工作量。当接口设计和集成工作所花费时间大于开发任务并行所缩短的时间时候,这个时候就到了分解的最小粒度。在这个粗细粒度间
就是可以通过调配人力资源能够获取的最大进度压缩。<br/>

<br/>
在IT项目中由于岗位角色划分,往往并不适合采用关键路径的方法来预计进度。进度安排关键在让所有人都尽可能早的动起来,在这里可以考虑的思考方式是:<br/>

<br/>
1.关注项目关键资源,关键资源必须优先安排来执行关键任务<br/>
2.通过组件细分和迭代,增加后期集成时间,但缩短前期关键路径等待时间<br/>

3.通过每日构造将测试也迭代起来<br/>
4.进度紧往往更不该跳过需求和总体设计评审而直接编码,后期返工往往是灾难性的<br/>

<br/>
<span style="color: rgb(0, 0, 255);">最有效的方法论和过程</span><br/>
<br/>
在裁剪过程的时候,必须清楚的认识到哪些过程元素是保证项目成功的核心要素,哪些是可以省略的。XP方法论对于任何一个功能的开发仍然是遵循小瀑布,而不
是跳过程。一个设计思路可以在纸面设计草图后就可以开始编码,后期再形成规范的文档,但决定不是说不经过设计就开始编码。需求,DEMO原型,总体架构,
数据库设计,评审,项目开发模式和规范都是重要的元素,都应该最有效的去发挥作用。因此以下是可以考虑的关键点<br/>

<br/>
1.DEMO原型必须和用户沟通确认,但需求阶段技术架构工作可以并行<br/>
2.需求和架构,数据库必须经过评审<br/>
3.架构或总体设计完成后必须进行培训,强调后续的开发模式和规范<br/>
4.架构开发不一定要全部完成才能开始后续工作,但事先要定义清楚接口<br/>

4.详设可以出纸面草图,面对面沟通后即可开始编码,后期再补规范文档<br/>

5.对于100%要做的不涉及业务规则功能可提前编码,如一些基础表的维护

长云 发表于 2007-6-22 23:03:02

<p>人月兄的好文章!</p><p>上次从你的博客上看到本篇时就觉得很受教,谢谢你发到家园来分享!</p>

人月神话 发表于 2007-6-22 23:05:48

谢谢。最近没有好文章,只有发前面觉得不错的老文章了。

南华学童 发表于 2007-6-24 19:07:39

排除人的合作因素之外,最重要的莫过于关注流程规划了。而流程关注非要以系统观才能见全局,愿我们在追求成效基础上继续进步。

swordliang 发表于 2007-6-26 09:16:20

楼上三位老哥的文章我一直都在关注,希望你们多给家人分享你们的心得啊,小弟先代表家人(即使代表不了)在此致谢了

cyl1984092 发表于 2007-6-27 20:55:50

<p>这篇文章,小弟看的不太懂,说明本人基础不扎实。</p>

人月神话 发表于 2007-6-30 23:14:32

讲的很好,按常理应该是你讲的这样操作。即先初估一个周期,然后应该根据范围和具体的估算,排出进度计划后再修正项目周期或平衡三要素。但很多情况下客户更关注项目周期,项目周期这条边灵活性很小,所以很多时候只能调整项目范围和人力投入。

ziyue 发表于 2007-7-6 08:24:23

<p>非常感谢!有些启发。</p><p>&nbsp;项目周期方面还涉及一些具体问题,可能没有楼主写的那么简单</p>

AndyLeau 发表于 2007-7-6 09:00:17

人月与CCGT说的是两个不同的角度来规划或操作项目。<br/><br/>人月,强调的是客户的需求,更多的操作客户订单;即始于客户需求。<br/>CCGE,是从项目的角度来操作或看待项目;可以看作是技术导向。<br/>

AndyLeau 发表于 2007-7-6 09:01:11

人月的操作,比如说投标,况标等情况出现的较多。
页: [1] 2 3
查看完整版本: [原创]培养做项目计划时的系统观