2005年12月28日

统一版本的诱惑对于任何一个团队都存在,谁不希望事情就那么简单呢?尤其是在管理层而言,这种诱惑简直要命。

有人提到成本问题,是啊,作为一个要赢利的组织,成本就是诱惑。如果从客户角度考虑呢,既节约成本有提高用户满意度的方法是什么?

要么如小陆所说,版本分层,核心一部分总部开发,外围一部分留给当地维护人员解决,这是提高客户满意度的一个办法,显然需要提高维护人员水平,至少可以定制代码吧,要提高维护人员待遇来和水平提高相对应;同样的思路,可以外包给当地公司或者干脆是客户的信息部门处理,不过国内公司大而全的贪欲,我想这样做的可能性不是没有,但是不大,这一点上要向日本外包学习,通过协力完成任务,提高用户满意度。

还有一种是技术解决方法,也许采用的可能性较高,将核心部分固化,变化部分配置化,当然业务分析和设计人员将面临很大的压力(我更愿意称为挑战),不过这又是成本的付出为代价的。

既然都绕不开成本,那我们谈谈成本。
表面上,做项目的公司属于给钱就干活的,钱多多干,钱少少干,反正不吃亏,只有用户用了,离不开了,用户就跑不掉了,盲点在于不主动;客户倒是态度主动,钱越少越好,盲点在于性价比。

还有一个最重要的,就是所谓维护费用难以争取,所以国内项目大多第一版开始,第一版结束,要么换个名头再来。

主动替客户考虑问题,未必吃亏,尤其是文中提到的公司的客户群应该不小,单点的投入有可能产生多点收入,对客户负责的态度也是后来者的防火墙。

那么多软件公司属于哪个产业—第三产业,是服务业,既然是服务,就要有服务的态度,我们已经习惯在酒店里享受别人的服务,为什么轮到我们自己就没有这种意识了呢?

草草行文,有感。

2005年12月16日

笔记图

2005年11月23日

2005年11月06日

    真实的谎言说道的计算机培训,不是今天才有的,在我们这里应该有5年以上的历史了,为了扩大生源,类似“包工作”之类的说法早就有了,我们这里甚至发生过学生找不到工作,在堂堂大学之内将校长暴打一顿的事情。
    一方面是令人心动的宣传,一方面是企业找不到合适的人才,科班出身的也要先进行几个月的基本就业技能培训,学校教的和社会用的严重脱节,这才是要命的地方,上学要花那么多钱,没有美好愿景,谁愿意掏钱,夸大其实的宣传在所难免。
    我也去过这样的学校带过客,坦白说,印度的那一套还是比较实用的,教材比较贴近实战,然而老师教不了,一则大学老师缺乏项目实做经验,二则教学目标还是为了考分,不是注意提高学生思辨能力;单纯就编程来说,也许面对面试回答的还像样,一深入追问肯定露馅。
    春鱼说:“没有人认真地相信这样的夸大地宣传手段,你只是庸人自扰罢了。”,我觉得吕震宇面对社会的责任心值得我们学习,在力所能及的范围内宣传这个观点和事实。

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. (可选项)谈谈工作心得,包括(工作得失,个人见解等),相互交流。
————————————————————–

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