2005年10月22日

每一个项目经理都希望自己的团队无坚不摧,任何一个亲身经历的经理,都不会觉得这是一个容易的事情。

最近看到以前同事发来的PPT,在讨论各个国家的团队文化的时候,问道“中国团队的有哪些典型特征?”,其中一个答案令人喷饭,“创造规则,然后一起蔑视它”。

我有时候挺佩服那些管理专家,说的道理总是颠扑不破,很是阳春白雪,我只有一些朴素的信念和土办法。

团队中最重要的是沟通,达到良好的沟通基础是诚信,亦即说话算话,说到做到。

有些制度规定写的确实很好,然则无可操作性,那么只好一起蔑视它了。

既然是规则,则不应强加于人,子曰:己所不欲,勿施于人,比如规定大家上网,不要去和本专业,工作无关的地方,去了则处理云云,其实宣布完了就完了,什么时候执行完全看需要,更有甚者,自己带头违反。

比如工作日报,刚开始的时候,声势浩大,然则不出一月,一切还原,先是大家报告越写越少,直至停止。以至于最后大家都想不起来当初为什么要写这个咚咚了。领导者只想让别人写,自己从来不看,这就是原因。

于是诚信在无行中就消失了。

2005年10月16日

今天手机上蹦出一个任务,“布置一下donews,好像今天在家的家务似乎不重,开干吧。

俺不算不懂的,所以直接从Donews Blog小花招》系列 看起,我也是怕麻烦偷懒的人,DoNews Blog模板之十 一起放风筝 很不错,抄啊,谢谢dodo和老白

在这个基础上可以慢慢加东西了,一点点搞。写程序的时候,我总是(包括提醒自己同事)MSDN开始抄,要不还有sourceforge, codeguru可以抄,当我确信这个轮子只有自己发明的时候再发明吧。

重复发明轮子很有快感,但是事倍功半的时候多;事情也有反过来的时候,这种情况总是发生在抄是抄了,只是不知为什么要这么抄,所以为了保证事半功倍,搞懂了再抄。再次向dodo和老白致谢。

2005年10月14日


汇报工作也需要八股文

日常工作汇报是经常发生的事情,如何汇报好,不是一件容易的事情。

初入行者,往往缩在后面,汇报时往往三言两语,不着重点的报过去了;也有报流水帐的,甚至连详细步骤一一道来,稍有有工作经验的往往将“大概”,“也许”,“可能”四处填充,听者昏昏,不得要领。

其实一个开发团队的例会还是需要一些八股文,例如:

本周工作计划完成XXXX项,实际完成XXXX项,没有完成XXXX项;
其中Bug有XXXX个,处理XXXX个,还有XXXX没有处理;

评价计划和实际工作之间的差距,原因,分析,对策
Bug处理评价

下周计划工作内容,本周工作对下周的影响是什么
以上是一般成员的回报内容,是不是清楚多了?

也有这样的规定:
工作汇报主要叙述三个方面:
————————————————————–
1. 概要性讲述本周内的工作情况,对本周的工作做总体上的概括
2. 对本周工作进行具体的描述, 叙述工作的完成情况,以及下一步的工作情况和可能造成的影响。
3. (可选项)提出本周工作中遇到的困难或不明白的地方,大家讨论
4. (可选项)谈谈工作心得,包括(工作得失,个人见解等),相互交流。
————————————————————–

相对来说,我更喜欢上一个规定,因为可操作性更好。

2005年10月13日
CCC经理:
    你好!
    现在就我的情况及目标向您汇报。
    对于这个行业,我没有长期呆在这里面的打算。所以,我也不想成为项目经理。
    现在的情况是,我只想做一个程序员。或许,就象AAA一样。目的也简单,付出一定的劳动,得到相应的收入。也就是说,工作的目的对我来讲,就是维持生存。当然,如果其中大家相处很愉快,那就更加值得了。
    所以,对于各次的学习交流什么的,我看你是旨在培养一个项目经理,我不想参加,也不想讲课。当然,如果你硬要我去做,我会感到很不愉快,质量自然很差,也影响你的心情,浪费你和大家的时间。
   但是,对于在工作中出现的问题什么的,我倒是觉得大家可以交流一下。对于学习,那是各人自己的事。
   以上是我的意思,请原谅我目标的改变,浪费了你的宝贵时间。
   至于明天的讲课,我不想讲,一则我觉得我自己还有些不明白,二则大家也没有想听的欲望。
   敬礼!
   BBB
  
这是我收到的一封MAIL,不错,至少说了大实话。古语说,法乎上,取其中,目标的降低,意味着结果也将降低。
这个行业每天都在变化,包括技术,有时觉得疲惫也很正常,可以考虑转型了。
2005年10月11日

关于AOP的七个猜想中写道:

3。存在AOD/AOA猜想。
OOP对人类的影响远不如它的两个弟弟OOA/OOD,后两者已经为整个软件开发行业带来了一次意义深远的革命,它至少使得全世界开发团队的人数扩大了10倍,开发工具和平台的复杂程度增加了10倍,完成客户某些简单要求的成本降低了90%,唯一的遗憾的是,软件开发的效率几乎没有数量级上的变化(依据《没有银弹》)。既然存在AOP,我们猜想也会存在AOD/AOA,比如会存在面向方面的重构手段,面向方面的设计模式,面向方面的最佳实践,面向方面的过程管理,以及在UML的未来版本中看到为面向方向而专门做的改进,甚至添加一个新的UML图类型。当这些东西都产生的时候,AOP才真正发展到了鼎盛时期。

打岔一下,我也在想:

OOA  ->  analyze pattern

OOD -> design pattern

为什么没有和OOP对应的 Programming Pattern呢?