随笔-15  评论-308  文章-0 
共2页: 上一页 1 2 
  2009年9月11日
摘要: 我是技术人员出身,作为一个组员的时候,只要自己把手上的任务做完就OK了(埋头写代码其实也是件很爽的事,其它的都不用管),当有幸成为一个小组(5个人左右)的组长,刚开始真的是很不适应,当看到有的组员写的代码很乱时,恨不得马上训他一顿,让他重写;看到有的组员速度很慢时,心里比他还急,真想直接帮他CODING等等,让我管几个人真是麻烦死了,一路上基本都是先吃亏、再总结,再实践,如此反复,摸着石头过河。以下是我在这方面的一些管理小心得,与大家一起分享交流。阅读全文
posted @ 2009-09-11 23:45 小山982 阅读(4090) 评论(27) 编辑
  2009年9月6日
摘要: 前面说到过,刚开始带小组,接到一个任务,我就估算了我大概要多少时间,然后小组多少个人就算是多少个我,估算时间=我要的总时间"小组人数(好笨的想法呀,不用时间跟组员交待任务的吗?个个组员都是我吗,比我强的还好,顶多做完了休息,差一点的就麻烦了),结果实际时间多了很多,而且小组里有的人做完了无事可做,有的人则忙得焦头烂额,容易打击组员的积极性,造成组员之间的不满。 随着经验的积累,要想把任务分配得比较合适,首先要对自己的组员有一定的了解,最好能量化,其次要把握好任务(这就看需求分析及系统设计的功力了),以下是我的一点经验,我把我的组员分类(简称ABC分类),主要划分的指标有技术能力,做事速度,业务理解能力。 主要看前两个指标,因为我在做需求分析的时候已经把业务弄熟了,分配任务的时候我会尽量从程序员的角度跟他们描述业务逻辑,以下是我跟组员讨论业务的一点心得:阅读全文
posted @ 2009-09-06 19:15 小山982 阅读(5143) 评论(18) 编辑
  2009年8月28日
摘要: 大学里跟老师做的项目几乎没有一个是按时间完成,都是在拖时间,一拖再拖,每次老师初步地估算这个项目需要多少时间,我脑袋里都下意识地想(老师估算的时间*2,或*3,或者更多),其中最糟糕的一个项目估计用一个月,结果用了一年才勉强结束,实际时间=估算时间*12,我的天呀,当时估计也就是学校这种地方做得出来。到了企业之后,实际时间是估算时间的两到三倍也是很正常的事,这还是在需求明确到85%以上的情况下,需求不清的情况下,时间就海了去了。 项目开始时,客户简单的描述需求,开发方便豪言壮语一个时间(有时这个时间连需求分析都做不完),中间客户改了需求,开发方声称“绝对不是问题”(接项目时要人情、关系之类的,客户改点需求,一般不太好明说要加时间),到了时间了,还差很多没做完(项目组的人赶工都加了好几天的夜班了),给客户演示下,忽悠下客户,然后再说我们再完善一下(一般这时客户也会再提点新需求),如此反复,就不知道要完善到什么时候去了。最后提起这项目,开发方暗骂客户扯蛋,客户暗骂开发方混蛋。阅读全文
posted @ 2009-08-28 00:39 小山982 阅读(5470) 评论(41) 编辑
  2009年8月21日
摘要: 大学的时候,跟着老师做项目,但是没有一个项目是按时间完成的(有的项目压根就没有明确的时间),每个项目都是做到一定的阶段(也有可能是快到交赴时间了),给客户演示一下,然后由客户提意见(有时甚至会把前面的需求都推倒),如此反复,最后客户就将就着用(加上一定的维护),不了了之就算是完成了。 当我在公司里主持开发一个项目的时候,才真正感受到需求不清带来的巨大痛苦。当要做一个项目的时候,客户向我描述他的需求,然后我把这些需求形成文档,设计,等开发到一定阶段,让客户看一下我们的进度,再提一下意见;这一看真是乱了套了,客户看了之后总是能提出“新”的需求,我们再改,客户再看,再来“新”的需求......搞得我一头的包,感觉这项目真是个无底洞、无尽的需求,真是苦不堪言。有时我真想骂客户:你怎么回事嘛,你就不能一次把需求说出来,你在玩我呀?阅读全文
posted @ 2009-08-21 01:34 小山982 阅读(2884) 评论(19) 编辑
  2009年8月9日
摘要: 08年6月毕业的,转眼就过了一年。 回想在自己刚进公司的时候,不知道如何去通过外语去学习一项新的技术;当初步完成了一个项目之后,别人看了总是提出新的需求,然后再改,改完了之后,别人又提出不同的需求,如此反复,郁闷之情尽在不言之中。当自己慢慢当上一个开发小组的组长时,开始时候觉得管几个人比自己直接编码还麻烦,对上头的不理解以及对组员努力程度不满意,经常显得比较急躁。 阅读全文
posted @ 2009-08-09 22:50 小山982 阅读(517) 评论(6) 编辑
共2页: 上一页 1 2