项目经理成长日记（6）――对不上的帐
“vvufygv”通过精心收集，向本站投稿了7篇项目经理成长日记（6）――对不上的帐，以下是小编精心整理后的项目经理成长日记（6）――对不上的帐，供大家阅读参考。
篇1：项目经理成长日记（6）――对不上的帐
系列文章目录索引：《项目经理成长日记》
中午吃过了午饭，端着杯茶做在休息室里正稍稍休憩，公司内部特别开辟出一个空间，并装修成吧台，高脚转椅，微高的台面和酒吧里面的样子多少有点类似。不少人见过微软、google的office的专修格调，让多少人羡慕而又渴望。其实程序员作为脑力劳动的工作者，有时候我们太需要像作家那样的灵感源泉，所以office的风格或多或少应该尽量给人营造一种比较轻松的环境，这样在轻松的环境中进行高强度的脑力将会尽可能让二者得到一种缓和,从而使质量和效率更为高效。
“吃过了？小余。”标准的中国人问候的方式，也惊醒了我，闭目养神的状态让我几乎快入眠。
我睁开眼睛，看清楚眼前的人，是财务的Cindy，我把身子抬了一下，报以微微一笑，说道：“嗯，你呢？”
“刚刚吃过，看到坐在这里，刚好有个问题想问你，就过来。”
“找我有事？”Cindy这么直接一说，我倒是一股狐疑。
“哈哈，我是有些问题想要请教你，你上次在会议上说的关于项目估算的问题，我后来仔细想了一下，感觉有些问题不明白，所以想要向你请教一下。”
“噢，是这个。”我记起来了，上周周会上提到了关于项目估算的问题，因为公司内部有几个项目给客户报工数的时候，经过客户的讨价还价之后，都被砍掉了近30%甚至更多。所以我只是简单的介绍了一下做工数的时候应该注意的一些问题。“那你想知道什么问题。”
“其实我想问的是从我这边考虑的，你们在给客户报工数的时候，在最终的合同商也都比较明确的列举了PM, Senior, Middle, Junior 的工时数量，可是这份合同和我们最终投入的人员的总工数有不少的差距。我们实际投入的人员往往都比合同上的数量要多。因为我是做财物的，我不知道项目的具体开发是怎么做的，但是从我这里来看的话，这个帐怎么都对不上，这个问题我一直想弄清楚。”
“嗯……”Cindy的问题倒确实是一个在公司内部非常常见的问题。对于项目开发的时候，我们在计算成本的时候会按照人/月的方式来进行计算，也有的公司按照人/天或者人/时的计算方式，不论采用哪种方式，一般来说计算出来的工数和实际投入的人员数量都会存在一个偏差值，如果说这个偏差值月小，也就说明说项目前期的项目估算做得越好，项目的总体成本和效益也就相对比较可观。如果这个偏差值越大，说明项目存在有估算不准确，或者说项目过程中管理出现问题，也有可能是客户的变更需求造成，对于偏差值越大的项目，其项目风险性也就越高。
我在自己的自己的脑中稍微组织了一下要回答的内容，对Cindy回答道：“其实在项目开发中，这个工数值会存在的偏差，因为我们在项目实际的开发过程中，比如说我们投入了10个人导项目中，开发了4个月，再加上后续的对应和维护的一个月或则更长的时间，如果说在项目估算的时候，我们对于这总的工数计算可能是即便是40人/月，那么后续的维护一个月的时间也就成了一个差异，也就是说我们多话了10人/月的时间。”
“那为什么对应的时间不能算到工数中呢？”
“我只是举一个例子，实际上我们会在工数预算中添加入部分的对应的时间，如果说我们的开发质量比较高，客户的回馈反应也比较快的话，那么我们在后期对应的时候估计只要保留2-3个人来对应问题，其余的人员完全可以退出项目组。这样两个差异值就会小很多。”
Cindy看是明白，但又显出满脸疑惑。“如果说按照你的说法，那么我们的差异应该都比较小，但是现在我们公司有些项目的这种差异非常大，有些项目的投入工数和合同工数的差异都差距有一倍多了，
”
“哈哈，实际上我们在做那些按照人/月工数的的项目的时候，很多情况下我们算得是完成项目所有模块所需要的总的开发时间数量，这种估算一般情况下都是参照一个标准的开发人员的能力来进行估算，比如说一个项目估算了10人/月，那么项目如果说交给一个人做10个月能不能准时做完呢？如果我们按照比较理想化的方式考虑问题，1个人10个月可能做完。如果说我们让10个人做一个月呢？很多情况下是10个人同时开工，反而无法完成，即便非常理想化的情况，10个人也需要1.5个月，那么中间就多出了5人/月的工数差异。”
“为什么会出现这个差异呢？”
“1个人做10个月的事情，如果改换成10个人做一个月，中间最大的差异在于10个人需要沟通和管理，那么这些是可见的额外消耗，同时由于10个在项目工程中不会做到工作一旦完成，马上释放出项目组，我们往往会让他们对应自己的问题，这样也就会造成项目人员工数消耗增加。”
“嗯，这么说合同的人员工数和实际的投入永远无法达到一致呢？”
看着Cindy满脸严肃的样子，我笑了笑说到：“那倒也不是，如果说项目启动阶段项目估算比较准确，开发过程中的管理方式有效合理，人员的安排合理的话，有时候会出现实际投入的人员比合同的上的数量要小的情况。”
“哈哈，那时理想化，至少我这里没有看到实际投入比合同上的数量少的情况。”Cindy估计感觉到我说得比较理想化，微微笑着应答道。
“实际上公司也在提倡项目独立核算的问题，这样的话，每个项目经理都会被迫有成本的概念，这样在坐项目的时候他们也就会考虑到人员消耗的成本，只要每个项目经理能够掰起指头算算进帐和出帐，那么他们在坐项目的时候，也就不会在盲目要人，而且前期的项目估算也就会花更多的精力去做。在过程中也会对人员做一个比较合理的安排，不会把一个人随意固定在某一个项目中，这样人员资源如果达到最大化的使用，那么这笔帐也就比较容易达到一致。”自己说完之后，也笑了笑，我也在笑自己，其实道理说得比较容易，但是实际做起来的话，可不是上下两个嘴皮子一掰就完成了，这样的话，对于项目经理来说无疑是一个不小的考验，以前项目经理主要需要对项目的成功与否负责，现在如果说又要让他们能够像会计那样算账，能够小气持家似的做项目，对于很多的项目经理的来说无疑是一个不小的考验，这些经验不是一日培训就能够做到的，毕竟需要在整个项目过程中时刻去留意，这些都是逐渐锻炼培养形成的。
对于公司来说，项目盈利是对绝大多数项目组的一个基本要求，虽然有部分的项目组会因为公司战略发展的原因，对盈利并没有做要求。对于大部分的软件公司来说，项目经理并没有过多的感觉到这种盈利指标的压力，毕竟如果说项目能够准时高质量的交付给客户使用，也就隐讳的说明这个项目是一个不错盈利的项目。但是对于一个合格的项目经理来说，我们需要有这种成本和独立核算的意识。毕竟我们的项目组作为公司的一个部分，我们需要确保我们的项目组能够产生效益，不会亏损。
我听到很多的公司中都希望倡独立核算的机制，一方面项目组希望能够借助独立核算的机制，能够比较清晰的了解到项目组所能够创造的价值，如果一个项目组的效益非常良好，那么这个项目组的成员所能够获得的收益也就能够相应提高，从而打破以前一碗水端平的现象，能者多得，从而加大项目组内部的良性竞争机制。从公司的角度来看，引入独立核算的机制，一方面能够给所有的项目组引入成本意识，另外一方面，就是通过竞争的机制来提高员工的积极性和效率，从而使公司和员工达到双赢得局面。
我个人到非常提倡这种核算的机制，但是对于绝大部分的公司来说，只能是希望而已，因为很多公司从公司整体的运作考虑，并没有实际去按照这种方式来管理项目，虽然说会天加入成本独立核算，但是由于赏罚没有并行，所以这种引入也就成了一种点缀，并没有发挥到任何的作用。
作者：Yice(小余)www.yice800.cn
本文出自：www.cnblogs.com/yice/archive//03/30/1425072.html
本文版权归作者所有，欢迎，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
篇2：项目经理成长日记
项目经理成长日记（2）—— 你能承受多大责任
项目经理成长日记（3）——给自己的定位
项目经理成长日记（4）——态度决定一切
项目经理成长日记（5）——五指有长短，能力各不同
项目经理成长日记（6）——对不上的帐
项目经理成长日记（7）——说是细，做的粗
项目经理成长日记（8）——吃肉？啃骨头？
项目经理成长日记（9）——兵贵于精，而不在多
项目经理成长日记（10）——百万大侠，能否推敲
项目经理成长日记（11）——我也会笑的很灿然
篇3：项目经理成长日记（8）――吃肉？啃骨头？
系列文章目录索引：《项目经理成长日记》
估计没有人会愿意，甚至喜欢去做那种会让你不死也活脱脱掉层皮的苦项目，没日没夜人如机器扳高速在运转，即便最后项目最终做成了，整个项目组的人也在过程中被折腾得不成人形，或许能够把人做到吐血，以至于丢掉小命的项目不少人曾经遇到过。我把这种项目叫成骨头项目，虽然不少人喜欢啃骨头，特别是硬骨头，在多番尝试努力之后咬到嘴里的肉吃起来别有味道，更有快感，但是这种快感需要付出更多的代价。
什么样的项目会让你在过程中做得比较轻松自如，游刃有余呢？需求明确，开发进度合理，技术风险可控，人员配备到位且团队士气活跃，多方条件一一具备之下，或许你的项目会如大块吃肉一般，过程和结果都那么愉悦，但是这样的项目对于绝大部分的人来说，应该说一个一个美好的梦想。
有没有这种吃肉形的项目呢？有，但是为数不多，至少自己工作了这么多年，也就那么一两次，而且还是10人/月之下的小项目。记忆比较清晰的是一个数据库迁移项目，主要是更具需求完成Oracle 存储过程开发工作，整个项目是4人/月的开发工数，但是投入了2个Senior Engineer，2个Middle Engineer和1个Junior Engineer进行开发，那个时候公司的项目不紧张，人员资源也就稍微富足一点。5个人做了1个月（实际投入工数是5人/月，超过项目预算），由于客户需要我们完成存储过程的开发和测试数据和测试报告，要求测试数据的覆盖率需要100%，时间和人员都比较充裕的情况下，我们想了一个办法来测试存储过程的覆盖率，我们用C#的按照存储过程的逻辑重新编写，然后用Nunit和Nconver结合的方式确保我们构造的数据的覆盖率达到百分百。在生成测试报告的时候，我们又用Excel的VBScript脚本编写模板，自动导出数据和做成报告。这个项目在两个方法被实现后，后期的工作非常轻松，特别是整个项目的质量非常高，客户没有提出过一个Bug。
也只有这样的项目配备和人员结果才能让我们有时间思考和尝试如何做得更好，做到最后就像吃肉般的舒服，对于其它的都是在一次一次地啃骨头，甚至鸡肋，我们在做项目的时候容不得自己挑挑拣拣，所以即便明知食之无味，但是公司不会丢弃。我们也只能硬着头皮顶上去，这个时候感觉自己如果是在炮火霏霏的战场上，自己怀里估计就揣了一杆木枪，还在奋力冲刺。
从早上收到邮件说关于美国医疗领域的那个项目的合同已经基本确定，目前已经可以确定的规模大概有120人/月，这些和上周在周会上的得到的情报基本吻合。只是今天比较明确的是这个项目将会交给我的开发团队来处理，而且客户希望能够在8个月内能够完成项目的开发工作，后续有2-3个月的客户试用测试、交付使用和问题对应阶段。
邮件附件中有一些关于这个项目的简单介绍，项目主要是客户希望能够给美国的医院提供在线服务的功能，能够为医院里面的医生提供在线办公，同时病人提供在线看病和病历管理的服务。邮件里面的内容比较简单，大概地介绍了一下项目的目的和希望，还有几张简单的项目结构示意说明图。
看着邮件和那几片概述性的论述文字，感觉像对着一颗定时炸弹。120人/月，8个月开内完成，还不包括2-3个月的需求调研时间，实际的开发时间也就是5个月。120人/月的工数中，开发估计在100人/月左右，那至少也需要20个人才能够在5个月内完成开发。这种小学的加减乘除地算法在我的脑子来回运算着，越算越感觉到时间紧迫。
“一场艰苦的战。”在自己心里冒出的直观感觉，我深深吸了口气，便站起身准备找项目总监去，对于这个项目的一些事情我需要和他确认清楚。
我把项目总监约到了会议室，还没有等我坐下，他就先开口问道：“早上发给你的邮件你看过了吗？”
“嗯。”
“那好，我们现在可以先着手准备，预计合同很快就会签下来，然后在下月初估计整个项目就会开始。”
“嗯，这个项目已经最终确定交给我们团队来做吗？”我还在需要再次确认这个问题。
“是的，关于人员方面的问题我们也在考虑。到时候会给你协调其它团队的开发人员和部分外驻开发人员。”
“外驻？”听到这个自己感觉压力更大，因为之前的项目中用到过外驻人员，也就是其它公司外派到我们这里，临时性的加入开发，这样的人员在项目中的风险很大，不容易管理。
“是的，这个项目需求，开发和测试的人员都加在一起，预计会有20人左右，从公司目前的人员状况来看，我们只能使用部分外驻人员参与开发，
但是我们还是计划再招聘一到两个的Senior级别的开发人员补充到你的团队中。”
从公司的角度来考虑，对于这种项目的确会希望使用外驻人员的参与，因为为了一个项目一下子把一个团队从目前的7个人一下扩充到20人，一旦项目结束之后，那后续补充进来的人员的安置也就有一定的问题，所以基于成本的考虑，公司的做法倒也合情合理。
“对于具体的人员需求，你再考虑一下，在周五的项目例会上再最终讨论一下。”
“这次谁会到客户那边去做需求？”
“公司本来是想让你到客户那边，但是如果你去了，就没有人管理项目，所以这次会从上海那边派两个BA(business Account) 到客户那里去做需求。”
“嗯，了解。”
“小余，这个项目还算比较大，在做的时候可能会有一些问题，希望你能够努力把它做好，如果过程中遇到任何问题或则说需要任何支援的话，你可以随时找我来解决。”
我微微笑了笑算是做了一个答复，对于这种任重期望的话，无疑往自己的肩膀上又多加了不少分量。项目是没有办法挑选和推托，虽然可以预计到这个项目能够顺利做下来不是那么容易，既然要做，即便是再难啃的骨头，我也要把肉咬到嘴里，越面对困难重重，自己越要坚定信心，这才是自己的个性。
从会议室出来，我就开始考虑整个项目的人员问题，虽然是先着手准备，但是目前团对立面连我在内就7个人，对于即将补充进来的13个人里面的人员和对应的角色都需要自己仔细考虑。其它团队的人员，外驻人员和自己的人员，感觉就像一个大杂烩。从目前的能够拿到的资料来看，对于项目还无法做一个比较充分的预估，因为具体开发的技术性问题和业务性的问题都难以预计。
我在脑海里面首先把人员做了初步的划分，20人的队伍中预计有5个测试人员，对于测试和开发的人员比例我一般会倾向于1：2的值，即两个开发人员会配上一个测试人员，这也是目前公司所采用的模式。测试人员会来自公司的测试团队。那么实际的开发人员会有15个人，15个人中Senior Engineer，Middle Engineer，Junior Engineer的比例大概是1：2：4，所以也就需要3个Senior Engineer，4个Middle Engineer和8个Junior Engineer。
人员的划分到没有多大的困难，结合上自己团队目前的人员情况，所需要的其他人员也就非常清楚。虽然缺少的人员的清单已经列举的非常清楚，但是这也只是一个列表而已，是否能够找到合适的人员与之配备，将会成为项目开发的一个关键因素。
我同时也把上海的那几个BA都回忆了一下，在项目例会上自己需要比较明确的提出人员，否则如果BA的人员出了问题，需求如果无法整理清楚，那么对于项目来说打击会是致命的。
在很多时候，做软件开发是比较辛苦的事情，大部分的项目都像是一块难啃的骨头，毕竟一个项目能够做到万事具备的情况就像 一样，其概率估计是在五六个小数点之后的值，项目在开发过程中各种问题层出不穷，人员不足，周期不足，需求步明确，客户随意变更等等问题都随意可见。所以做项目开发的整个过程无疑就是在面对这些残缺的问题，以及我们在思考如何去解决这些问题。
没有人会乐意做这种啃骨头的事情，除非他已经麻木了。当然我们也在一次一次的这种骨头项目中不断的提升自己，以及在克服重重困难之后看到成功后的那种满足感，这些才是支撑大伙完成项目的一个关键。
如果你接手的是一个可以预见的骨头型项目，要么你放弃不做，高枕无忧，不过可能性非常小；要么你就多足充裕的准备，比如前期的人员考虑以及合作人员的能力考虑，就像选择BA的人一样，如果他在已经在过去出现过过种种的问题，那么对于这种关键的合作人员自己就需要加倍留心；团队组建过程中的人员的安排等，对于人员的风险需要考虑到位，比如说外驻人员的管理问题等；对团队成立后协同工作等问题考虑，还有项目技术和业务风险的考虑，这些都是在项目还没有开始的时候需要考虑的点，而不是等到项目真正开始做的时候才意识到有这些问题，因为项目一旦开始的时候，我们要面对的是如何解决这些问题，而不是考虑这些问题的原因。
回到自己的座位上，看着还在他们忙碌着，老马，阿毛，木子，超仔，大师, 杰克着几个我能够指望共同作战的团员，他们也是我有信心去啃着块硬骨头的基础。
作者：Yice(小余)www.yice800.cn
本文出自：www.cnblogs.com/yice/archive//03/05/1403780.html
本文版权归作者所有，欢迎，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
篇4：项目经理成长日记（1）―― 启言
系列文章目录索引：《项目经理成长日记》
如果你爱他，那么让他去当项目经理，因为那里会是他事业的天堂；如果你狠他，送他去当项目经理，因为那将是他的地狱，
软件开发工作应该属于分工比较明确的行业，每一个项目的启动，调研，开发，测试，部署，用户培训和后期维护等一系列的过程都有不同的角色参与其中。在这一系列的角色中项目经理是最直接的管理者，无疑显得格外的突出和重要。软件项目开发的成功率本身就不高，在众多的失败过程中，由于项目经理在管理上存在的问题造成项目无法按时交纳，质量不高甚至失败的例子在我看来数不胜数。虽然项目经理的能力并不是项目失败的直接原因，因为影响项目成败的因素有很多，但是如果一个合格的项目经理，对于项目的整个开发过程来说，如何利用他的经验和能力来有效合理的管理项目进度，从而避免很多无谓的失误，在项目的最终成败中还是占有关键作用。
对于很多从事软件开发的人来说，项目经理是他们事业上追求的目标，从初出校园的小牛犊，从最低级的学徒似的初级开发人员，再不断的努力和学习，慢慢得爬到有经验的中级程序员，再后来到高级程序员，到后来的大牛人才，慢慢开始带领新人，开始接触项目管理上的工作。我想很多人的轨迹都是这么一步一步的过来。在整个过程中我们彼此都在学习，关于很多的技术方面的知识可以通过网络和书籍进行学习。但是如何做一名项目经理，如何做好一名项目经理，倒缺乏一个系统的学习框架，包括我自己在内，也是跟随前人身边学习，自己观察，在一次次错误后进行反思后才有所进步。这个话题的文章我考虑了很久后才决定要写出来，在一系列的文章中结合我自己的项目和我自己身边的项目，希望能够将这些经验与大伙分享，通过讨论，彼此共勉。机会往往是给有所准备的人，不论你现在是否是充当项目经理的角色，但是如果你有所准备，我想对于你来说机会只是迟早的事情。
项目从规模来说，可以划分微型项目，小型项目，中型项目和大项目，当然还有超大型的项目，对于工数在一人/月（一个中级程序员开发一个月，总计21个工作日）的项目定为微型项目；对于工数在1人/月到10人/月之间的规模称为小型项目；对于工数在10人/月到100人/月之间的规模称为中型项目；如果超过 100人/月的项目称为大型项目；对于我们所讨论的项目管理中，对于超过1000人/月的项目不做讨论，因为一般的公司来说，还是比较少能够遇到中规模的项目，
如果从类型来说可以简单的划分为产品开发和项目开发，产品的开发一般会有后续定期的产品升级性开发，项目的开发时间跨度也会比较长，对于项目的开发来说，一般是指为了满足某一特定客户而开发的软件，其开发周期往往会比较紧张，后续的开发主要是针对客户的新功能追加，这种项目的开发往往会划分为几个阶段分步进行。
如果从合作方式上也可以划分为自主研发和外包开发，甚至还有部分项目使用外驻人员进行项目开发，有时候开发还受到地域性的影响，两地，三地合作开发，国内国外的合作开发，还有甚至多国之间的合作开发。
不同的项目开发方式都会有不同的问题出现，比如说小型项目和大型项目的人员配备上就不可能一样，外包开发和自主研发的项目计划也不一样，跨地域的合作上的时间差异和人员的沟通和本公司内部背靠背的模式也不一样。项目中实际可能发生的事情千奇百怪，这些问题绝大部分都需要项目经理来过问，分析和决策。所以说项目经理或许对于很多人来说将会是地狱，一旦深陷其中，很难有苦尽甘来的那一天。但是如果方法得当，管理手段有效，能够合理的规避风险呢？那你将会感到项目中的一切对你来说游刃有余，团队中每个人也都能相应发挥自己的特长，也都能从中找到各自的成就感。
生与死只在一线间，好和坏也是如此。希望能够从项目经理的角度来看看项目实际过程中我们会遇到哪些问题，该如何去处理这些问题，通过着一些列的文章能让你对项目的整体过程有更全面的了解，同时也能够让你更清楚项目经理的日常工作和行为职责。
作者：Yice(小余)www.yice800.cn
本文出自：www.cnblogs.com/yice/archive/2009/03/05/1403780.html
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
篇5：项目经理成长日记（4）――态度决定一切
系列文章目录索引：《项目经理成长日记》
超仔刚刚推门进来，屁股还没有碰到他的椅子上已经让人感觉到他欢喜轻飘的神色，我抬头望着他眼睛，神色中洋溢的满是欢快，我看着他那兴奋的样子，微微笑着问道：“签完了？结果还可以吗？”
“还不错！”
“能满意就可以，继续努力。”
“嗯。”
我知道超仔刚刚和公司签了新的合同，在新合同里他的工资有了一定的提高，这些都是因为对于他去年的绩效考核成绩还不错应该得到的结果。
年底对于我来说，可真是多事之秋，因为我需要在年底前完成对我团队这些人的一年的绩效评定，这些不但关系到他们年终的奖金，也影响到来年他们工资的涨浮。虽然自己一直讲究的是赏罚分明的做事方法，但是往往对于我来说要清晰分析哪个人在过去的一年中犯了什么样的错，对于这些错误去做一个评定，算其功过，工作不亚于一个项目的开发。一方面如果我评定的尺度太严格，那么最明显的一个影响就是年底年终奖金和来年的工资，在工作中涉及到这部分利益的东西处理起来本身就是敏感，所以自己一直都是平时严厉甚至苛刻，但是到这个时候，我反而会手下留情，只要态度对位，错误可以酌情考虑。对于我来说，一个人的态度决定他的一切。
“我的工作目标就是要替掉你。”这是超仔在面试的时候留给我印象最深的话，也因为这句话我发而对他有不少的好感。人最应该有的是有自信，超仔是刚刚毕业一年的新人，在面试时候做在我前面表情僵硬，全身紧张的他，在我问“你希望进入公司之后，能够有什么养的发展方向时？”这样的回答可能是一种自大，但是在我看来，这也是他的自信。也这是这种自信让我决定录用这个计算能力不算好，但是我觉得各种条件还算合格的小伙子。
当然我也非全凭一句“就要替掉你。”就把小伙子招聘进来，然后放到自己身边使劲搂拧，我想自己还不至于有这种变态的爱好。我喜欢面试的时候让应聘人员都手动填写一份简历，虽然很多时候他们自己都带了一份打印的现成简历，但我还是会让他们把公司那份表格填写完整，虽然很多时候他们自要把内容抄写过去就可以，但是这也是我对他们的第一个考验。很多程序员的字写的都有大师级的水平，对于他们来说，楷书，行书都不足以表达他们的意境，狂草，唯有这个才能体现他们的追求。有不少程序员在填写这个简历的时候，字迹就和天书一样，当然文字也像蛇一般的在纸上盘绕。
对于我来说，我只是通过这张简历看看他对自己的一个态度，我不要求他们的字能够达到书法家的水品，但是至少要工整，整个纸张让人看起来要干净清晰。我很难看到你对目前的工作有多少的渴望，但是我可以通过你写下来的文字看出来你是否重视这个事情，如果连工作机会都不重视，那以后的态度就值得担忧。所以通过这个我也放弃掉不少的人，虽然有些人在和我免谈的时候给我感觉也非常不错，但是如果两者结合在一起评定，如果后面没有做好，那么我只能认为他是学院派的，能说未必能做。
超仔长的不像程序员的样子，一米七五的个子，相貌也有几分帅气，留着平头短发，每日衣着新潮个性。他平时个性活泼开朗，又一次他还请了一天的假，说是去参加超男的选拔赛，结果回来之后，感慨道：“强人太多了，人外有人。”不过自己到没有为被淘汰的事情耿耿于怀，倒是很享受乐在其中的过程。
超仔进入公司的时间也只有半年左右，在这边年里面他不到两个月就给他转正了，比公司规定的三个月试用期提前了一个月多。肯学习和努力的态度让我对自己当初挑选他感到非常满意。在第一个月培训的时候，让他整理了以前遗留的旧的项目，那些项目本身缺少相关部分文档，但是由于项目一直在延续开发，所以久而久之，也就这么一直持续的做下来，那些已经对这些内容滚瓜烂熟的人也就没有心情去做，后来者也之能够在前辈的口传身教的情况下才能了解其中的奥妙，我一直希望能够把这部分资料补充完整。但是由于人手上不足，所以就一拖再拖。
公司对新人有比较详细的培训计划，在这些培训之外，我对超仔说：“你看看这个程序，因为你以后需要维护和开发这个，如果你有时间的话，可以把熟悉开发环境的步骤写成文档，文档的格式可以参考项目组内其他的模板，内容你线考虑一下，但是有一个要求，如果另外一个新人来接触这个程序，我需要他再看了你的稳当之后，就可以把环境搭配起来，
些做的方式可以图文结合。”
结果在一周之后，超仔就给我说：“小余，我把那份文档写了一部分，你先看看有什么问题，如果不行的话我再修改。”
很多人都知道程序员非常讨厌写文档，所以很多程序员写出来的文档比写出来的代码还要难读，有时候读这种文档就是一种折磨，比读法律条款还难受，估计很多时候需要和法律文件一样，需要再配套上一本详细的解释才能把问题说明清楚。
但是超仔的文档让我非常满意的地方在两个地方，一方面再环境搭建的时候，用了截图的方式描述，而且每一幅图都是用作图工具简单的剪裁过，只保留关键部分，而避免乐像其他人那样是整个屏幕的图片，在么个图中对于操作关键区域还用红色正方形边宽标注说明，每个图片还有编号。
另外一个是整个文档是用Excel文档做成的，因为公司比较喜欢用Excel做给中开发文档，但我尝试着用打印预览的时候，让我惊奇的事情发生了，总共10页的文档，每一页都调整过，图片没有出现跨页的问题，而且打印的页头和页尾都修改过了，并没有保留上个文档的名称，作者和日期也都是正确的。
“页面打印是你调整过的？”看着文档，我轻声问道。
“我常常听到你让大家发邮件给客户的时候，要预览一下。所以我也就调了一下。”
听到这话，我心中是暗自窃喜，一个新人能够有这样的工作意识和态度，实属可造之才，技术可以学习培养，但是如果你想改变一个人做事态度其难度要远远大于技术上的培养过程。
超仔在后续半年的工作中也有犯了不少的错误，从刚刚开始技术上弱势，但是好学肯问，其进步的幅度不小，也使得他在很快的时间内能够达到对他所定位的能力要求。在于我看来这一切取决于他的态度，态度端正。
“态度端正，学习良好。”我的脑海中突然冒出这几个字，这不是小学时候，老师在每学期的期末成绩单上最喜欢用的两个评语。什么是态度？怎么才能算是端正呢？我在心中问了一下自己：“我的工作态度算不算端正呢？”或许像超仔这样的新人属于上升求学阶段，所以憧憬无限，但是对于我来说呢？当年何尝不是如此，现在还是不是一就有这样的心境呢？
“哎。”想着想着，不由自己叹了口气，难道我老了吗？怎么我还没有感觉到青春灿烂，这青春怎么就没了呢？看看坐在开发室中的其他人：老马，阿毛，木子，超仔，大师, 杰克这几个人，我们应该是活力无限的开发团队。
“Hi,小余，你在吗？”还没等我在继续发愣，MSN上的就弹出消息来。是上海的PM李。
我急忙回过去问有什么事情。
“我刚刚给你发了一封邮件，我把需要像客户移交的内容重新做了一个整理，你再看看有什么问题没有？”
我突然记起来，昨天晚上快接近9点的时候，我还在理发店修头发的时候，就接到李从上海给我打过来的电话，她问我现在有没有先前她发给我的计划列表，因为明天客户需要确认，所以她想今天晚上再把这份计划列表完善一下，如果我笔记本上有备份的话，给她转发一份，结果我刚好也只是把邮件接收到公司的机子上。最后我听到她在电话里说了一句：“那好，我明天早点去公司去修改一下，然后再给客户。”
李在一个月之前已经和公司提出离职的申请，因为她家庭的原因，她需要到国外发展。应该说再过两天她就会到美国去了，她本来是这个项目上海的项目经理，但是对于我来说，她是一个非常优秀的项目经理，从她身长我看到了一个项目能够成功的关键，态度。也就是她的这种工作态度，让整个项目有序稳定的进行。
在听完李的电话之后，我里一直佩服到，这才是工作态度。
作者：Yice(小余)www.yice800.cn
本文出自：www.cnblogs.com/yice/archive//03/18/1415564.html
本文版权归作者所有，欢迎，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
篇6：项目经理成长日记（10）――百万大侠，能否推敲
系列文章目录索引：《项目经理成长日记》
“闲居少邻并，草径入荒园，鸟宿池边树，僧敲月下门。过桥分野色，移石动云根。暂去还来此，幽期不负言。”贾岛为琢磨这首《题李凝幽居》，也不管交通法规，骑驴闯了官道。对于全诗只有一处拿不定主意，那就第二句中的“僧敲月下门”的“敲”是否应换成“推”。可他又觉着“推”不太合适，不如“敲”好。不知是“敲”还是“推”好。嘴里就推敲推敲地念叨着，也不管屁股下的毛驴往那里走，结果那毛驴也不认识什么大官小官，就直奔韩愈的仪仗队里，韩愈虽然官高位重，但是也是一介文人，问贾岛为什么乱闯。贾岛就把自己做的那首诗念给韩愈听，但是其中一句拿不定主意是用“推” 好，还是用“"敲”好的事说了一遍。韩愈听后对贾岛说：“我看还是用‘敲’好，去别人家，又是晚上，还是敲门有礼貌呀！而且一个‘敲’字，使夜静更深之时，多了几分声响。再说，读起来也响亮些”贾岛听了连连点头。他这回不但没受处罚，还和韩愈交上了朋友。
贾岛在唐朝被人称做苦吟派诗人。什么叫苦吟派呢？就是为了一句诗或是诗中的一个词，不惜耗费心血，花费工夫。贾岛曾用几年时间做了一首诗。诗成之后，他热泪横流。当然他并不是每做一首都这么费劲儿，如果那样，他就成不了著名诗人了。
软件开发和写作在我看来，多少有点相似的味道，都是靠人脑力劳动，通过作者的想象，分析和努力，把原本凭空存在的东西变成现实。只是作家写作可以天马行空，笔尖上挥洒千里，随意发挥。但是软件开发却需要一步一步求证，严谨科学。不过很多人把开发软件也称为写软件，这是因为软件工程的开发和写作一样，都是一字一字的代码堆积成每个功能，然后汇总成为系统，这和写作基本相同。作者往往在需要反复推敲文章之后，才能写出让己让人都满意的美文。那么软件开发呢？
当然在做软件开发的时候，不会像贾岛那样，几年才写成一首诗，这样的产量估计留给自己业余玩玩还可以，对于公司来说，这种产量估计老板会把他那张脸绷得比猪皮还紧。我们在做任何开发的时候，也是条条道路通罗马，对于同样的一个动作，文章中讲究推和敲的意境，对于软件来说，同一个功能，也可以用不同的方法来实现，可能有些人会把其中的公用的功能抽象出来，做成通用的函数，或许另外一些人就通过复制和拷贝来实现这种功能的复用。虽然功能都做到了，但是对于后期的维护的人，估计他对两种方法的会有比较大的反应，搞不好还会念叨三字经，顺带拜会写代码人的父母长辈。
对于软件开发中，我们的代码其实也需要像写文章那样推敲，反复提炼，特别是在于团队开发中，这种推敲工作显得更为主要。不是说我们一个项目完成之后，我们的代码超过十万行，百万行就是一个了不起的项目，其实对于如此庞大的代码量，我们需要在兴奋之余想想到底有多少的代码是有用的代码，有多少的代码是值得再三提炼的代码，而不是说这么多的代码都是废话，就像是海绵浸了水，拧干之后就什么都没有。
我刚刚把面试的人送出会议室，返回到我的位置上，木子已经迫不及待地问道：“小余，刚刚那个时不时那个百万大侠？”并用一种崇拜的眼神望着那人离去的背影，仿佛渐行离去的人就是她仰望已久的偶像。
我听完之后摇了摇头，说道：“不是他，他会在半个之后来。”因为项目的准备工作已经逐步开始，在前期的准备过程中，人员招聘也是非常紧迫的一个环节。毕竟想要找到一个合适优秀的人员，所花费的周期往往都比较长。昨天HR那边送来的几个的Senior级别的应聘者的简历，有些是自己投递的，有些是他们通过猎头找来的。在这些简历中其中有一份简历让阵个团队几乎炸锅了。
简历是Word的文档，在第一页不像一般人的简历那样，先写自己姓名和基本情况，还有一些工作的履历情况。开头先来了一个特别说明，其中说明有两点，其中第一点赫然写到：“XX油田项目曾经在半年的时间写代码量总共写了100万行代码。”说明的第二点就是关于这个项目实现的功能说明。但是我看到这里的时候，看到100万行代码的时候也忍不住惊讶，心里面也不由的佩服此人，毕竟我估计还不可能在半年之内完成这么多的代码开发工作。
“哇，100万！”因为大师也在看应聘者的简历，即便平时显得沉稳的他也不由自主的惊叹道。
“什么100万？”开发室中其余几个人听到大师的感叹，好奇的问道，
很快，此人的简历被整个开发团队的所有成员都阅读了一遍，全部的人对他从满了好奇和期望，都希望能够尽快看看如此厉害的人物到底是什么样子？时不时有三头六背，否则怎么能够在半年内完成如此多的代码工作量呢？阿毛还特地计算了一下这个人每天写代码的数量，半年等于180天，那就是一天写接近5600行的代码，如果一天工作12个小时的话（确实，这样的项目不加班不可能），1个小时需要写460行的代码，那么每一分钟需要写8行代码。经过阿毛的计算，所有的人都觉得不可思议。结果在短时间内，没有人都去关心这人的真实姓名，百万大侠也就加冕给他。木子还特叮嘱我说，如果明天百万大侠来了，一定要让她看看。
我在位置上作了议会，前台就通知说有面试的人来了，我看了一下时间，比约定的早10分钟。我拿着简历正准备和大师一起走到会议室，木子也随后跟在我们的后头，我笑了笑便由着她。我和大师进了会议室，面试的人已经坐在里面，木子脑袋在门口探了两次，便回到了开发室。
我和大师一坐下来，便仔细观察眼前的人，倒没有三头六倍的感觉，中等的个子，年龄和简历上所描述的30岁倒也相符，短短的头发看起来显得很精神，坐在那里喝着水，显得神色自若，并没有看出有紧张的样子。
面试的开始都是流水的操作模式，他简单地做了一个自我介绍，等他一介绍完成之后，大师便直接问到他：“你能不能说说你这个XX油田的项目？”
“这个项目是B/S的项目，其中我完成中核心的功能是报表的功能，因为对于油田项目中报表的要求比较复杂，在这个项目客户需要实现报表的功能是报表的字段可以随意自定义，而且我们还实现了数据正确但是不正常的数据的自动检测和自动预警功能……”
其实他对项目的介绍是比较清晰的，他所承担的主要是针对报表部分的功能，在这个功能上主要实现的是自己编写报表逐渐来自定义报表模板，使用存储过程与通用控件交互的方式实现报表的浏览、导出、打印等功能。对于报表来说，不同的行业对于其要求的复杂度存在的非常大的差异，如果说对于要求比较特殊的行业来说，要实现其报表绝非通过简单的报表工具就可以实现，所以对于这部分的功能的确存在大量编码的可能性。不过由于没有从事过石油行业的开发工作，所以对其中的复杂度也无法度量，所以我就没有针对为什么会有100W的代码去深究。
而大师却紧接着问道：“你简历上写着XX油田项目曾经在半年的时间写代码量总共写了100万行代码。我想知道你这100万行的代码是怎么算出来的？”
“我用工具统计出来的，大概有100W行左右。”
“这100W行的代码都是你自己写的吗？”大师继续问道。
“不是，其中30到40万行的代码是通过代码生成工具生成的，还有部分的代码是html上的代码，所有的代码文件都加在一起大概是100W行。”
大师没有继续追问了，其实到这里他大概也能凭借自己的经验估计出来有用的代码数量是多少，实际上利用现有的开发工具进行开发，开发工具自动生成的代码数量也非常惊人，很多时候开发人员通过拖拖拉拉就可以生成数以万计的代码来，对于这部分的代码统计出来又能够说明什么问题呢？
其实在团队开发过程中，我们需要时常斟酌、推敲我们自己写出来的代码，看看代码的效率，代码的复用性等等。很多时候我们需要控制代码的量，代码并非越多越好，如果成了老妈子的裹脚布，那只会是又长又臭。对于这样的代码，开发一旦进入后期，其维护的成本非常惊人。如果再10人的开发团队中，有时候部分的功能代码是可以通用，但是10人之间彼此独立成章，每个人都自己对于某个功能写一套代码，可能由于项目缺乏标准的原因，缺乏有效的代码注释，开发的人也懒的去读代码，分析功能，就自己写了一套；还有可能因为怕对现有的代码进行修改，影响了其余部分的功能，所以就再写一套代码，这样项目中存在的重复性的代码就非常多。在后期维护的时候，带来的结果是往往改了左边丢了右边，问题不断的出现。
在团队开发中，我们既要控制我们代码的冗余，避免出现大量无效杂乱的代码，这些代码往往来自于开发工具的自动生成，有时候来自开发人员低效率的代码编写。还需要对代码进行归纳集中，对通用性，公用性的代码进行抽象，提取。同时还需要加强开发规范的约束。通过这些来保证代码的质量和效率。
一个程序员一天能够写出来的代码是有限的，我们既要减少他们彼此之间的重复劳动量，还需要提高他们的代码书写质量，如果质量能够得到控制，那么效率就能够提高，进而就是时间的节约。如果我们能够从有限的时间中节约出来部分，那么项目的整体进行就是另外一番景象。
作者：Yice(小余)www.yice800.cn
本文出自：www.cnblogs.com/yice/archive/2009/04/20/1439641.html
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利
篇7：项目经理成长日记（3）――给自己的定位
系列文章目录索引：《项目经理成长日记》
你有没有考虑过自己能够管理多大的项目，能够带领多少人员的项目团队？5人？10人？100人？还是千军万马？但是在现实的项目中，能够带领100人员的项目经理未必能够带好10人的团队，反之亦然，因为作为软件项目来说存在有非常大的差异？无论你是大才还是小才，我们首先要清楚的认识到自己的才能是否能符合项目的实际应用，5人的项目和100人的项目团队中项目经理的工作重心必然不同，如果不区别对待，那么你的结局是大才小用，或者是小才大用。
项目的差异性
我没有机会参加类似IBM的OS／360规模的项目，我所能够参与的最大项目规模不过是100人/月上下的项目，当然也做过产品线的长期开发项目。所以对于那种巨无霸形的项目也只能是望梅止渴，对于其中的奥妙也只能捧读《人月神话》这类的经典，希望能够从中吸取精华来强壮自身。
项目的规模不一样，项目所能够配备给定的人员也不一样，对于大型的项目，除了项目经理之外，还会配置项目辅助管理人员和咨询顾问管理人员等。如果说项目超过了10000人/月这个规模，项目往往会采用纵向切割来进行管理，整个项目会像工厂中产品线生产方式：系统需求；系统设计；配置管理；代码开发；系统测试；文档编写；产品构建等过程，整个项目会根据不同的分工被切割成每个小项目团队，虽然每个团队可能的工作都只是针对于局部，在各自的内部这些工作是相对独立的，但是每个项目又都对其他部分有比较严重的依托，比如系统设计是以项目需求为基础，代码开发是以系统设计为前提，所有的工作序列彼此关联，每个工作都可以独立安排二级甚至三级的项目经理，这样整个项目的组织管理模式也就形成了金字塔的模式，从项目经理到最底下的开发人员形成一个自顶向下的体系结构。这个时候对于项目经理的主要工作也就不能要求事必躬亲，小到一个螺丝钉都要亲自过问，对于这种项目经理的要求更多在于总体协调和整体的掌控上面，他就像一个元帅一般的任务，要的是果断的决策，准确的判断，良好的协调和丰富的管理经验。
实际上大部分的项目经理很难有机会成为如此大规模项目的最高决策者，即便有机会参与的时候，更多都是处在二线或者三线的位置，所能够管理的实际人员也大部分在10人或则20人左右。更多项目经理参与的项目都是中小规模的项目，毕竟中小的项目的数量还是非常巨大，所以有很多的项目经理在从事这种的开发工作。对于项目规模在100人/月的项目对于很多公司来说也算是具备有一定规模的项目，这些项目的人员投入一般都会在10人之上，不会有公司对这种项目采用投入一个人做一百个月的方式。对于10人规模的项目管理对于大部分的项目经理来说可以是一个不小的挑战，因为虽然说项目的规模不能与上述所说的超级项目抗衡，但是项目在整体过程中所做的事情和上述相当，系统需求，系统设计，配置管理，代码开发，系统测试，文档编写，产品构建等都不会缺少，但是在人员配备里面可没有二级或则三级的项目经理，甚至很多时候会有人力资源捉襟见肘的情况，在10人的规模里面可是要包含需求做成人员，项目开发人员，测试人员等。在很多的时候一个人需要充当多个角色，可能在某一个阶段你需要做需求，当需求做完了之后，你又需要投入开发，后期的时候可能需要做项目文档和项目部署，甚至用户培训。所以对于我的直观感觉来说，这种项目对于项目经理的能力要求可能更高，如果要做好这种项目的项目经理，首先最好有比较扎实的技术开发能力和工程背景，这样你的项目估算才能做得比较准确，为后续的开发赢得更多的时间；其次好需要又比较良好的业务知识，因为你可能更多需要做一个用户的接口，所有的需要都需要通过你和客户去沟通，以及最终的定案，所以对于业务的熟悉程度也至关重要；再者需要又良好的计划性，因为这种项目的变数比较多，项目不会像又很长的规划周期，所以如果控制好这些可变因素，已经如何协调内部的有限资源，让资源发挥最大的优势可能成为项目经理每日计划中关键的一部分。
还有不少的项目规模在10人/月左右的项目，这种项目对于很多公司来说属于不痛不痒的项目类型，因为同一个时期内公司可能会有多个这种类型的项目同时在进行中，在这种情况下项目所能够获得的资源就更加有限，往往项目的安置人员也就在5人左右，当然和上面两种情况类是，项目过程的事情还是不可省缺，但是由于项目总体的规模偏小，所以项目的复杂度也比较容易控制，但是这种项目对于项目经理的要求更多在于技术上的要求，因为如果这个时候在安排一个缺乏技术经验的人员做项目经理，那么整个项目组的安排出现一个外行领导四个内行的局面，而且四个内行中可能有一半以上是新人或者初级的开发人员，如果再包括测试等一系列的工作，人员分布上就缺乏合理性，
所以这个时候的项目经理往往都是技术过硬的人员担任，这样可以化解人员不足的问题，但是也有一个问题，对于技术优秀的人员都会有一个通病，首先看不上别人的工作结果和质量，另外一方面往往会以自己的标准去衡量别人和给人安排工作，这样对于新人或者初级的开发人员来说，他们的工作就会出现不合理的问题。同时在做估算的时候也比较容易出现轻易的问题，以自己的能力估算项目进度，结果造成项目估算不准确，后期严重加班的问题。所以这种类型的项目经理需要又良好的技术背景，还需要学习项目的实际管理和合理的人员安排，以及如何做好与项目内部成员的友好沟通和关系。
最后一种项目类型就是那种一个人吃饱，全家不额的类型，项目规模非常小，不到1人/月，所以在这种项目的投入人数往往只有一个人或则两个人。当然这个时候也不会要求说项目开发的那一系列的工作都做到位，很多时候都是口头相传，这种项目的结果大部分之要求软件代码和程序能够满足要求。所以这个过程中很多人可能认为只要管好自己就可以了，但是我认为，时间虽然短，但是事情还是需要做足，比如说需求的明确文档化，还有与外界的沟通等一些列过程实际上都可以和正常的模式一样，对自己的工作也需要有一个良好的计划，这个时候对于自己的要求就是一个锻炼的机会，为今后做更大的项目准备好时机。所以这种项目经理的要求实际不抵，如何管理好自己可能会是一个比较大的难题。
项目类型的差异性
项目从规模差异上来说是对一个项目经理的开发能力，管理能力等有不同的要求。但是如果说从项目类型的差异的角度来看，就会对项目经理的一些其他能力又要求，如果说你做的是国内的项目，那么你需要有与客户沟通的良好能力，能够有足够的能力应对客户的各种要求，如何应对客户千奇百怪的要求，如何合理的说“NO.”都是你需要具备的能力。如果说是对日，对欧美的外包服务开发，需要有良好的语言沟通能力，比如说日语，英语。还需要了解不同国家的文化差异等等，这个时候你可能需要充当起桥梁的作用，如何与国外的客户进行沟通和交流，包括有工作安排，技术上等一系列问题的沟通工作。
给自己的定位
项目管理本身就是一个比较复杂的过程，不像行军打战那样，有了一盯一眼的制度就可以管理好项目，因为项目的变数太多，情况迥异，也就没有放之四海而皆准的管理方法。所以对于不同类型的项目来说，我们需要了解项目的特点，在我们有良好的基础准备的前提下，根据自己的能力特点，再结合项目的实际情款来不断调整工作中的方法和内容。
虽然我们很难有一个标准化的管理手册来指导每一个希望做项目经理的人，但是我们可以从别人身上去借鉴各种成功或则失败的经验，特别是别人失败的经验，因为别人的成功可能我们很难克隆，但是我们可以避免别人错误再我们身上重演。
不想当将军的士兵不是好士兵，但是不想当项目经理的程序员未必是坏的程序员。毕竟对于技术领域来说，程序员的最终发展方向项目经理未必是一个最优秀的方向，程序员可以走的道路有很多，可以往架构师，分析师，资深技术人员，咨询师等等。路可能有很多条，而且每一条对于人员的能力要求也都不一样，都有良好的发展机会。所以对于自己能力的判断和分析，认清自己，给自己合理的定位是直观重要。让自己的才华得到发展和认可是今后职业道路上一个关键，自己要才尽其用。
作者：Yice(小余)www.yice800.cn
本文出自：www.cnblogs.com/yice/archive/2009/03/17/1414256.html
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
【项目经理成长日记（6）――对不上的帐】相关文章：
1.摔了一跤成长日记
2.品味成长日记
3.成长日记作文
4.成长历程日记
5.土豆成长日记
6.成长的日记
7.四年级成长日记
8.成长日记800字
9.豆豆成长日记
文档为doc格式
