摘要： 我是技术人员出身，作为一个组员的时候，只要自己把手上的任务做完就OK了（埋头写代码其实也是件很爽的事，其它的都不用管），当有幸成为一个小组（5个人左右）的组长，刚开始真的是很不适应，当看到有的组员写的代码很乱时，恨不得马上训他一顿，让他重写；看到有的组员速度很慢时，心里比他还急，真想直接帮他CODING等等，让我管几个人真是麻烦死了，一路上基本都是先吃亏、再总结，再实践，如此反复，摸着石头过河。以下是我在这方面的一些管理小心得，与大家一起分享交流。 阅读全文

摘要： 前面说到过，刚开始带小组，接到一个任务，我就估算了我大概要多少时间，然后小组多少个人就算是多少个我，估算时间＝我要的总时间"小组人数（好笨的想法呀，不用时间跟组员交待任务的吗？个个组员都是我吗，比我强的还好，顶多做完了休息，差一点的就麻烦了），结果实际时间多了很多，而且小组里有的人做完了无事可做，有的人则忙得焦头烂额，容易打击组员的积极性，造成组员之间的不满。 随着经验的积累，要想把任务分配得比较合适，首先要对自己的组员有一定的了解，最好能量化，其次要把握好任务（这就看需求分析及系统设计的功力了），以下是我的一点经验，我把我的组员分类（简称ABC分类），主要划分的指标有技术能力，做事速度，业务理解能力。 主要看前两个指标，因为我在做需求分析的时候已经把业务弄熟了，分配任务的时候我会尽量从程序员的角度跟他们描述业务逻辑，以下是我跟组员讨论业务的一点心得： 阅读全文

摘要： 大学里跟老师做的项目几乎没有一个是按时间完成，都是在拖时间，一拖再拖，每次老师初步地估算这个项目需要多少时间，我脑袋里都下意识地想（老师估算的时间*2,或*3,或者更多），其中最糟糕的一个项目估计用一个月，结果用了一年才勉强结束，实际时间＝估算时间*12,我的天呀，当时估计也就是学校这种地方做得出来。到了企业之后，实际时间是估算时间的两到三倍也是很正常的事，这还是在需求明确到85%以上的情况下，需求不清的情况下，时间就海了去了。 项目开始时，客户简单的描述需求，开发方便豪言壮语一个时间（有时这个时间连需求分析都做不完），中间客户改了需求，开发方声称“绝对不是问题”（接项目时要人情、关系之类的，客户改点需求，一般不太好明说要加时间），到了时间了，还差很多没做完（项目组的人赶工都加了好几天的夜班了），给客户演示下，忽悠下客户，然后再说我们再完善一下（一般这时客户也会再提点新需求），如此反复，就不知道要完善到什么时候去了。最后提起这项目，开发方暗骂客户扯蛋，客户暗骂开发方混蛋。 阅读全文

摘要： 大学的时候，跟着老师做项目，但是没有一个项目是按时间完成的（有的项目压根就没有明确的时间），每个项目都是做到一定的阶段（也有可能是快到交赴时间了），给客户演示一下，然后由客户提意见（有时甚至会把前面的需求都推倒），如此反复，最后客户就将就着用（加上一定的维护），不了了之就算是完成了。 当我在公司里主持开发一个项目的时候，才真正感受到需求不清带来的巨大痛苦。当要做一个项目的时候，客户向我描述他的需求，然后我把这些需求形成文档，设计，等开发到一定阶段，让客户看一下我们的进度，再提一下意见；这一看真是乱了套了，客户看了之后总是能提出“新”的需求，我们再改，客户再看，再来“新”的需求......搞得我一头的包，感觉这项目真是个无底洞、无尽的需求，真是苦不堪言。有时我真想骂客户：你怎么回事嘛，你就不能一次把需求说出来，你在玩我呀？ 阅读全文

摘要： 08年6月毕业的，转眼就过了一年。 回想在自己刚进公司的时候，不知道如何去通过外语去学习一项新的技术；当初步完成了一个项目之后，别人看了总是提出新的需求，然后再改，改完了之后，别人又提出不同的需求，如此反复，郁闷之情尽在不言之中。当自己慢慢当上一个开发小组的组长时，开始时候觉得管几个人比自己直接编码还麻烦，对上头的不理解以及对组员努力程度不满意，经常显得比较急躁。 阅读全文