程序员与项目经理

drin

有多少人能理解项目经理？

我刚升任一个项目Leader，因为是刚刚担当。有很多经验都不足，在这里写给各位程序员，和项目经理看看。

我刚刚当上项目Leader，也是很多人说的项目经理（但其实大多数的管理者应当是ProjectLeader以上的人，看了文章大家就会明白了）。因此我非常明白程序员的想法，最好能不加班，最好分到手上的活少一点，最好表现比其他人优秀，比如最终的Source量多于别人，Bug少于别人，在同Group中成为编程的佼佼者。

于是，我一上来就制定了一个非常低的生产性的Schedule，（也是因为我自己也不喜欢整天加班），C++编程，生产性为3.5! 但是，全公司的生产性是6.7KS/人月，有一个做英文移植的项目生产性是14KS/人月，郁闷啊！在部门经理，公司总经理，公司的SQA人员的疑问中，我将生产性提到了4.0!

    事实证明我是多么的缺乏经验，因为现在我发现将C++生产性设在2ks/人月左右的Group也不少见。

项目有4个机能，手上有三个人，还包括我自己。部门经理对我说，不用编程好好管理就可以了。他是为了我好，但是我知道，如果让手下的2个人去做4个机能，他们会很累！于是我说，“开发人员太少了，我还是参加编程吧！”

由于第一次做Leader，手上要处理的管理文档，竟然有10多份，而每一份都会不停的有来自总经理，部门经理，SQA人员的指摘！其中，有些指摘是正确的；有些指摘虽然正确实施起来却非常困难，我把他们称为理想的；有些指摘则不知道为了什么在指摘，直到有一天从其他几个Project Leader处听到SQA人员有指摘份额，如果指摘不到，他们要受到批评，原来如此，总不能让别人不好完成任务啊，那就让他们指摘吧。

在处理这10几分文档的期间，我每天加班到8，9点，而我的组员则准时回家了。我非常的眼红，于是到了真正开始开发的时候，我把设计文档的50%分给了我的组员，自己承担了另50%。可设计期开始了，我的组员还是准时回家，并且他们在回家时会跟我打个招呼：“***， 我回家咯！”开始，我想他们做的并不多，他们也许可以不用加班，到了设机期的中间时，我不由得狐疑了起来，“他们是第一次写仕样书啊！真的没有问题吗？”但是，只要我催促他们一点，他们的脸上就会非常的不耐烦。可以理解吗，上一个项目还平起平坐，这个项目就变成了他们的头头，他们当然会有点不服气啦。而且其中一个还比我资格老一点，算了大家客气客气，过一段时间就会好的。

    直到设计期快结束时，我发现了那位老资格人员老吊在网上!! 我有一种经验不足，不懂得管理的内疚，但是当我真的开始盯着他时，他的不耐烦更明显了，我想我应该行使我Leader的威严了，因为设计期眼看就要来不及！！

    在我迫令他加班的时候，我看见他又在上网！为了免犯众怒，我没有再次提醒他，而当天因为我前一段时间的努力，到了7点半，我就回家了。第二天，我发现组员在我走了之后，没有继续加班！

    没有办法，我只能让老资格的组员把工作分摊开来，而自己继续加班，做老组员的活。我的部门经理非常的同情我，知道在不停的和客户，总经理打交道的同时，还要做很多的设计，时间会来不及，于是他提出“那份设计书我来帮你做”。而正是这份由部门经理帮忙的设计书最后无法准时交货，因为Leader的事情多，部门经理的事情就更多。好容易来上班，总是在开会，好容易不开会，部门经理又病倒了没来，第二天来了，总经理又因为他的请假和他谈谈心。


    到了OOD阶段，也大致和设计阶段差不多，不过终于顺利进入了Coding。只是这次我负责了老组员的全部OOD部分的设计。

    我尽量平分个个机能，好让组员们各自表现，在OOD阶段时我找老组员谈了一次心，我告诉他因为他的经验，我想重用他。我说的是真心话，这个老组员有他的能力在，但是他需要有个引导，他非常的聪明，只是不细心，没有责任感，又缺乏OOP的概念。我确实想提拔他，毕竟手下的能人多点，我自己也能轻松点。为了这个，我特意将2个非常讨巧的机能非给了他，一个是做界面，一个是这次新加进来的全新独立机能。（也许有人会说，做界面算什么重用？但是在我们的公司里，头头只认作界面的人，也许是因为他们那个时候对于程序的2层，3层概念还不太了解。）

    而老组员就是老组员，每天的上网交流已经成了他和网友之间的任务，所以没过几天，他这里的进度又出现了迟缓的现象。我当即自责，分给他的量太大了！于是叫过新组员，让他做一些老组员的内部处理，而我自己也分担了老组员的剩下的1/3的活。

    如果设计期，OOD的时候，组员们还言听计从，到了Coding就没有这么简单了，他们对于你的指摘，总有很多的解释，毕竟大家都是编程的，大家都有想法啊。而这时我范了最严重的一个错误。老组员开始买房子了，我很能理解，于是我对他说，“你去吧，来不及的话，我来帮你做。”他真的常请假，而我也真的帮他做起了Source。

当Coding、Coding的Review完毕（我们公司是要在Coding完毕后全组对Source进行Review的），我们匆匆忙忙的进入了第一次Test阶段。Test共分3个阶段，每个阶段都是5天，我对他们说，第一天写测试项目的报告，第二三天测试，后两天改Bug。而实际上每次都是第三天，我才拿到测试书，最后两天，我总是加班到很晚，而老组员则总要拖到第六天，他对我的解释是“我能完成的，我不会晚的”，他指的是第六天能完成，而下一个test阶段是不会晚的。为了他的拖延，前任部门经理要求我解释原因，客户常常提出疑问，而客户代表则希望我能好好检讨，请注意，管理我们这个Project的有：前任部门经理，客户代表，客户（2名），SQA。总共是5名，而我的组员只有2名！

到了最后一次测试，已经是临近春节，而这时客户在第二次测试的版本里找到了一个Bug，铺天盖地Mail从5个方向飞来，好在我有一个部门经理，他舍身挡住了枪眼，但是条件是第二阶段测试重测！测试书重写！好容易做完第二阶段测试，第三阶段才做了一天，就是春节前上班的最后一天了，组员都回家了，外地的家！！，我留了下来，测起了所有人的机能，这时也没有什么测试书了，因为今天我就要交货，奋斗到11点，我精疲力尽的看着部门经理，“我们交货吧，我累了！”

春节归来后，我就对自己的懒惰付出了代价，客户在我们的应用程序上找出了2个Bug，并做出了不可接受的评价。而最终我们查明“让他们不能接受”的真正原因是出在他们身上后，客户就是客户，他们是不会承认错误的，他们是上帝，更何况这位上帝来自日本！

又一次强烈轰炸！因为“无法接受”在我们公司从没有发生过，无论我们怎么解释，管理者都希望看见我们能从自己身上找原因，而不是得罪他们的利益来源。站在老板的角度，我很能理解，但是谁能考虑考虑我的感受呢？最后阶段，部门经理也站到了对方，他也倒戈了！更加多的解释需要做，更加多的测试来到了我们的面前。

我说过，在Coding时，我帮组员们改过Source，在测试的时候，我付出了代价。一旦出了问题，组员就对我说，“你改了什么了？”直到我最终拿出证据，证明Bug早就有，不是我的问题。而每当这时，我觉得自己很窝囊！

如今，项目已经无事结束了。客户也非常的满意，并希望与我们进一步的合作。而我学会的则是，好好使用组员吧，别再往自己身上揽开发的活。不要因为他们有事请假，就放他们走，除非他提前完成了手上的活！不要把分给一个人的活再分给另一个人，即使那个人来不及。组员才2个，头头却有6个！！管理上的事情实在是太多，做好管理上的事情已经来不及，何必再自己给自己添乱呢？

现在，我一直在总结，在考虑。仅仅一个项目就有些让我心灰意冷，是不是我只适合做开发？

我把这次开发写出来，是希望有经验的人能给我些忠告。而各位程序员则能理解一下Leader的苦衷。

drin

管理项目是一门艺术，而编程则需要技术。表面看来，我这次的项目在最终交货前没出过什么问题，但是我知道，其中的问题很多很多，如果我不能从中吸取经验，恐怕下次还是会犯同样的错！

有管理经验的人务必给我一些忠告。

joyt

偶也是一个小Leader，但不是做开发的，体会是：体制决定一切，不能适应就走，能适应就混，有点麻木了

厨师

真是好帖子！ 好帖子！

我们公司，部门经理下，就是项目经理，编码公司基本上都是让实习学生和外包的方式完成，我负责项目的管理、整合、发布工作，还要负责外包项目。说实话，去年一年，特别是最后几个月，我不太愉快，手上的活也很偷懒，哎。。。。

谈不上有什么管理的经验，相互讨论讨论吧。总结去年我的工作，我是这样觉得的：
手下的人，各有各的特点，有些人就是偷懒，没办法，多多谈话，要求提交阶段性的成果，而且，最重要的，要让他知道，自己的表现，和自己的工资是有直接联系的（我们这里，工资有20%是自己的上级给的）。还有呢，要和其他部门，搞好关系，特别是行政，多多去聊天，在这个上面花点时间，是值得的。其他的，就不知道了，希望今年不要出什么大事情，让我事业步步高，呵呵！

btw，本帖子，已经加入精华！

carechen

主要问题就是发生在上、下级问题的处理。
对于下级，必须要在里程碑进行控制，如何控制？项目的人员必须作备份[这个往往就是项目经理本人]，对于那个老组员比较简单的做法是：谈心-〉警告-〉谈心-〉弃用-〉谈心-〉申请将其调离项目组。领导在一定程度上必须帮下级背黑锅，但是不能背习惯了，更不能养成下级偷懒的习惯。经常性的讨论会增进组员的工作积极性和效率。
对于上级，要分清工作界限，千万不要将你的工作在上级的要求下由上级来实施，你根本没法控制你上级的进度，最后还是要自己做的。
对于相关部门一定要花力气去协调，这一点厨师也说了，的确非常非常重要！

还有一点也很重要，每天一踏进公司，你就要知道：领导永远是对的。[不是马屁，而是如果大部分领导习惯某种工作、思维方式，那只能说明你们公司的企业作风是这样的，不要认为有什么不对，不对的回家骂，在公司反抗公司的惯有习惯是非常愚蠢的，结局不是你被弃用就是跳槽了事]

厨师

说得好！大家继续谈一点心得，交流交流，呵呵！

还有，我想问问"生产性"是怎么计算的呢？我们公司没有这个概念，代表什么意思呢？数值是越小越好呢？还是其他什么呢？不明白！

carechen

最初由 厨师 发布
[B]说得好！大家继续谈一点心得，交流交流，呵呵！

还有，我想问问"生产性"是怎么计算的呢？我们公司没有这个概念，代表什么意思呢？数值是越小越好呢？还是其他什么呢？不明白！ [/B]

我们也没有，推测应该是合格代码产量吧。

asun

写的好，我想其中一部分原因是管理层和自己可调用的资源不平衡，管理上的琐事严重分散了精力，到最后就形成了恶循环，由于前期设计上的延误，一方面要和组员一起搞开发赶进度，另一方面又要对管理层的质疑作出解释。
还有就是部门经理好像有所失职，没有及时指出你工作上的失误。

学习!

linuxarm

关键是前期的规划，把制度定到那里，明确地说清楚是对事不对人，偶不是和你过不去，而是和你做的工作过不去！

drin

我们公司的制度好像和大家的有所不同。

工资和奖金是固定的，以前Leader可以对下属的工作态度做评价然后反馈给上级管理者，现在，好像也取消了。另外，公司从不因为某一个人的表现不好，而开除、或不续签合同，因为公司的人员数直接决定了公司的收入（因为公司接项目，从客户那里算人月，人月越多，钱也越多。人月是指，做一个项目，需要多少人，干几个月。如果，分到手上的人不是很有用，就只有自认倒霉了。）。

生产性，也是一个非常奇怪的制度。某一个项目，做了10，000行Source，其中不包括空行和注释行，那么这个项目的Source量是10KS（KS:千行的意思），而项目做了10个人月的话，该项目的生产性就是1KS/人月。
最初制订生产性的概念，可能是为了评定项目的努力程度，生产性高，可以认为大家的努力程度高。但现在公司里，片面追求生产性的项目很多，而对于生产性的管理，也有很多的“估算，追踪，评审”的管理工作。

有些组员，为了显示自己的工作量比其他人的大，故意将同样的代码放到不同的函数里，或者是不同的类里，原先应该2000行完成的，他们可以做到5000行，这多出的150%，往往要给上级领导者解释一个多星期。

前一段时间有人在网上讨论过《人月传说》，我觉得公司的制度非常重要，而真正需要读懂这本书的，这是那些公司的真正掌权者。