http://rdcoo.chinardm.com
公 告
登 陆
日志日历
导 航
日 志
评 论
链 接
统 计
 
项目跟踪经验一谈 

最近公司正在进行一个与官方卫生系统的流体检测设备项目,我出差在外,就全权委托一位项目经理实施项目协同的管理工作,该项目需要四方的协作。今天上午,在MSN上问起项目进展情况,D经理答复我说“刘工说他那部分按我们的计划做的差不多了”“**研究所那边完成70%了”,于是,我把D经理说了一顿,他倒是一声没吭的似乎都表示接受,但估计憋在心里的“小题大做”四个字只差脱口而出了。

于是触发我在此简单问题上的一个idea,要写出来,警示大家,因为这个现象太普遍了。我走访的企业、辅导过的客户、领导过的下属、汇报过的上级、协作过的机构,统统都发生过,也正在发生着。这个说法就是“**那部分代码我已经完成了80%”“**电路基本弄完了”…那部分代码是按行数统计的、还是按功能的个数、还是按模块的数量统计的80%,我不知道;电路板是样板电路调完成了、二次定型制版完成了、还是定型实物/电路图/BOM单/检验说明等系列文件都全部弄完了,我也不知道。

我们注意一下,这个说法有什么问题吗?当然有,要么完成的比例是虚数,代表性体现是“差不多”“基本调通”“应该没问题”;要么是比例很准确很量化,但被乘数确实很虚的数,于是被乘数*乘数的结果仍然是个虚数,这部分的代表作就是“那部分代码已完成80%”“那块电路板已调通70%”;

按照这个方法汇报的工作,我们作为客户、或作为管理者,仍然不知道该项目还有哪些问题,我们理解的目标和汇报者理解的目标一定会出现偏差。最有可能出现的是难度小工作量大的全干完了,汇报说完成了95%,可就是剩下的所谓5%,就是那难而又难的难点,5%基本决定了项目100%的失败。汇报者的百分比是按工作量估计的,决策者是按项目难度的比例来听的。最后的时候,管理者再介入帮助解决问题,时间、成本、人力资源、耐心等等都可能已经是不可承受之重。

我处理此问题的经验是:如果我是被汇报者,就只听事实陈述,自己下结论;如果我是汇报者,那我就陈述事实,让听者自行下结论;

“差不多”“70%”都是别人下的结论,他的价值观、对结果的认同、对问题的判断、衡量的指标,和我都是不一样的,对结果的预期自然也就不同,如果就这种方法处理管理事务,最后的结果一般都会是两边都有怨气。

举例说明,我对某电路板的设计进展情况汇报,

“这部分的晶振部分起振了,波形正常,

I/O接口全部都调通了,接口的定义和数据的传输都测试通过了,

电源的纹波有点大还没解决,但暂没影响应用,

电源变换芯片那一块模块的性能没有测试呢,

还有插座电缆还没做,

电路板屏蔽壳到货了准备明天装

大家做个法官,如果用量化数据说话,这块板子算完成了70%还是80%,说得清楚吗?

 

SMART原则来说,measurable谁都知道,从设计活动分解来说,都知道就是把一个大的问题进行细化,可到了日常具体工作中,形成信息沟通的这个基本习惯为啥就这么难呢?而这,恰恰是很多开发项目不能如期完成、上司和下属都鸡飞狗跳的源泉。

武晔卿 发表于 2009/3/6 17:42:00 阅读全文 | 回复(1) | 引用通告 | 编辑 | 收藏该日志
Re:项目跟踪经验一谈

很难说清

lujun1hao发表评论于2009/3/27 18:09:00 个人主页 | 引用 | 返回 | 删除 | 回复

发表评论:

    昵称:
    密码:
    主页:
    标题: