“zlsc005”通过精心收集，向本站投稿了10篇项目经理成长日记（1）―― 启言，下面是小编给大家带来的项目经理成长日记（1）―― 启言，以供大家参考，我们一起来看看吧!
篇1：项目经理成长日记（1）―― 启言
系列文章目录索引：《项目经理成长日记》
如果你爱他，那么让他去当项目经理，因为那里会是他事业的天堂；如果你狠他，送他去当项目经理，因为那将是他的地狱，
软件开发工作应该属于分工比较明确的行业，每一个项目的启动，调研，开发，测试，部署，用户培训和后期维护等一系列的过程都有不同的角色参与其中。在这一系列的角色中项目经理是最直接的管理者，无疑显得格外的突出和重要。软件项目开发的成功率本身就不高，在众多的失败过程中，由于项目经理在管理上存在的问题造成项目无法按时交纳，质量不高甚至失败的例子在我看来数不胜数。虽然项目经理的能力并不是项目失败的直接原因，因为影响项目成败的因素有很多，但是如果一个合格的项目经理，对于项目的整个开发过程来说，如何利用他的经验和能力来有效合理的管理项目进度，从而避免很多无谓的失误，在项目的最终成败中还是占有关键作用。
对于很多从事软件开发的人来说，项目经理是他们事业上追求的目标，从初出校园的小牛犊，从最低级的学徒似的初级开发人员，再不断的努力和学习，慢慢得爬到有经验的中级程序员，再后来到高级程序员，到后来的大牛人才，慢慢开始带领新人，开始接触项目管理上的工作。我想很多人的轨迹都是这么一步一步的过来。在整个过程中我们彼此都在学习，关于很多的技术方面的知识可以通过网络和书籍进行学习。但是如何做一名项目经理，如何做好一名项目经理，倒缺乏一个系统的学习框架，包括我自己在内，也是跟随前人身边学习，自己观察，在一次次错误后进行反思后才有所进步。这个话题的文章我考虑了很久后才决定要写出来，在一系列的文章中结合我自己的项目和我自己身边的项目，希望能够将这些经验与大伙分享，通过讨论，彼此共勉。机会往往是给有所准备的人，不论你现在是否是充当项目经理的角色，但是如果你有所准备，我想对于你来说机会只是迟早的事情。
项目从规模来说，可以划分微型项目，小型项目，中型项目和大项目，当然还有超大型的项目，对于工数在一人/月（一个中级程序员开发一个月，总计21个工作日）的项目定为微型项目；对于工数在1人/月到10人/月之间的规模称为小型项目；对于工数在10人/月到100人/月之间的规模称为中型项目；如果超过 100人/月的项目称为大型项目；对于我们所讨论的项目管理中，对于超过1000人/月的项目不做讨论，因为一般的公司来说，还是比较少能够遇到中规模的项目，
如果从类型来说可以简单的划分为产品开发和项目开发，产品的开发一般会有后续定期的产品升级性开发，项目的开发时间跨度也会比较长，对于项目的开发来说，一般是指为了满足某一特定客户而开发的软件，其开发周期往往会比较紧张，后续的开发主要是针对客户的新功能追加，这种项目的开发往往会划分为几个阶段分步进行。
如果从合作方式上也可以划分为自主研发和外包开发，甚至还有部分项目使用外驻人员进行项目开发，有时候开发还受到地域性的影响，两地，三地合作开发，国内国外的合作开发，还有甚至多国之间的合作开发。
不同的项目开发方式都会有不同的问题出现，比如说小型项目和大型项目的人员配备上就不可能一样，外包开发和自主研发的项目计划也不一样，跨地域的合作上的时间差异和人员的沟通和本公司内部背靠背的模式也不一样。项目中实际可能发生的事情千奇百怪，这些问题绝大部分都需要项目经理来过问，分析和决策。所以说项目经理或许对于很多人来说将会是地狱，一旦深陷其中，很难有苦尽甘来的那一天。但是如果方法得当，管理手段有效，能够合理的规避风险呢？那你将会感到项目中的一切对你来说游刃有余，团队中每个人也都能相应发挥自己的特长，也都能从中找到各自的成就感。
生与死只在一线间，好和坏也是如此。希望能够从项目经理的角度来看看项目实际过程中我们会遇到哪些问题，该如何去处理这些问题，通过着一些列的文章能让你对项目的整体过程有更全面的了解，同时也能够让你更清楚项目经理的日常工作和行为职责。
本文出自：www.cnblogs.com/yice/archive//03/05/1403780.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的人一样，如果他在已经在过去出现过过种种的问题，那么对于这种关键的合作人员自己就需要加倍留心；团队组建过程中的人员的安排等，对于人员的风险需要考虑到位，比如说外驻人员的管理问题等；对团队成立后协同工作等问题考虑，还有项目技术和业务风险的考虑，这些都是在项目还没有开始的时候需要考虑的点，而不是等到项目真正开始做的时候才意识到有这些问题，因为项目一旦开始的时候，我们要面对的是如何解决这些问题，而不是考虑这些问题的原因。
回到自己的座位上，看着还在他们忙碌着，老马，阿毛，木子，超仔，大师, 杰克着几个我能够指望共同作战的团员，他们也是我有信心去啃着块硬骨头的基础。
本文出自：www.cnblogs.com/yice/archive//03/05/1403780.html
本文版权归作者所有，欢迎，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
篇4：项目经理成长日记（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估计感觉到我说得比较理想化，微微笑着应答道。
“实际上公司也在提倡项目独立核算的问题，这样的话，每个项目经理都会被迫有成本的概念，这样在坐项目的时候他们也就会考虑到人员消耗的成本，只要每个项目经理能够掰起指头算算进帐和出帐，那么他们在坐项目的时候，也就不会在盲目要人，而且前期的项目估算也就会花更多的精力去做。在过程中也会对人员做一个比较合理的安排，不会把一个人随意固定在某一个项目中，这样人员资源如果达到最大化的使用，那么这笔帐也就比较容易达到一致。”自己说完之后，也笑了笑，我也在笑自己，其实道理说得比较容易，但是实际做起来的话，可不是上下两个嘴皮子一掰就完成了，这样的话，对于项目经理来说无疑是一个不小的考验，以前项目经理主要需要对项目的成功与否负责，现在如果说又要让他们能够像会计那样算账，能够小气持家似的做项目，对于很多的项目经理的来说无疑是一个不小的考验，这些经验不是一日培训就能够做到的，毕竟需要在整个项目过程中时刻去留意，这些都是逐渐锻炼培养形成的。
对于公司来说，项目盈利是对绝大多数项目组的一个基本要求，虽然有部分的项目组会因为公司战略发展的原因，对盈利并没有做要求。对于大部分的软件公司来说，项目经理并没有过多的感觉到这种盈利指标的压力，毕竟如果说项目能够准时高质量的交付给客户使用，也就隐讳的说明这个项目是一个不错盈利的项目。但是对于一个合格的项目经理来说，我们需要有这种成本和独立核算的意识。毕竟我们的项目组作为公司的一个部分，我们需要确保我们的项目组能够产生效益，不会亏损。
我听到很多的公司中都希望倡独立核算的机制，一方面项目组希望能够借助独立核算的机制，能够比较清晰的了解到项目组所能够创造的价值，如果一个项目组的效益非常良好，那么这个项目组的成员所能够获得的收益也就能够相应提高，从而打破以前一碗水端平的现象，能者多得，从而加大项目组内部的良性竞争机制。从公司的角度来看，引入独立核算的机制，一方面能够给所有的项目组引入成本意识，另外一方面，就是通过竞争的机制来提高员工的积极性和效率，从而使公司和员工达到双赢得局面。
我个人到非常提倡这种核算的机制，但是对于绝大部分的公司来说，只能是希望而已，因为很多公司从公司整体的运作考虑，并没有实际去按照这种方式来管理项目，虽然说会天加入成本独立核算，但是由于赏罚没有并行，所以这种引入也就成了一种点缀，并没有发挥到任何的作用。
本文出自：www.cnblogs.com/yice/archive/2009/03/30/1425072.html
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
篇5：项目经理成长日记（4）――态度决定一切
系列文章目录索引：《项目经理成长日记》
超仔刚刚推门进来，屁股还没有碰到他的椅子上已经让人感觉到他欢喜轻飘的神色，我抬头望着他眼睛，神色中洋溢的满是欢快，我看着他那兴奋的样子，微微笑着问道：“签完了？结果还可以吗？”
“还不错！”
“能满意就可以，继续努力。”
“嗯。”
我知道超仔刚刚和公司签了新的合同，在新合同里他的工资有了一定的提高，这些都是因为对于他去年的绩效考核成绩还不错应该得到的结果。
年底对于我来说，可真是多事之秋，因为我需要在年底前完成对我团队这些人的一年的绩效评定，这些不但关系到他们年终的奖金，也影响到来年他们工资的涨浮。虽然自己一直讲究的是赏罚分明的做事方法，但是往往对于我来说要清晰分析哪个人在过去的一年中犯了什么样的错，对于这些错误去做一个评定，算其功过，工作不亚于一个项目的开发。一方面如果我评定的尺度太严格，那么最明显的一个影响就是年底年终奖金和来年的工资，在工作中涉及到这部分利益的东西处理起来本身就是敏感，所以自己一直都是平时严厉甚至苛刻，但是到这个时候，我反而会手下留情，只要态度对位，错误可以酌情考虑。对于我来说，一个人的态度决定他的一切。
“我的工作目标就是要替掉你。”这是超仔在面试的时候留给我印象最深的话，也因为这句话我发而对他有不少的好感。人最应该有的是有自信，超仔是刚刚毕业一年的新人，在面试时候做在我前面表情僵硬，全身紧张的他，在我问“你希望进入公司之后，能够有什么养的发展方向时？”这样的回答可能是一种自大，但是在我看来，这也是他的自信。也这是这种自信让我决定录用这个计算能力不算好，但是我觉得各种条件还算合格的小伙子。
当然我也非全凭一句“就要替掉你。”就把小伙子招聘进来，然后放到自己身边使劲搂拧，我想自己还不至于有这种变态的爱好。我喜欢面试的时候让应聘人员都手动填写一份简历，虽然很多时候他们自己都带了一份打印的现成简历，但我还是会让他们把公司那份表格填写完整，虽然很多时候他们自要把内容抄写过去就可以，但是这也是我对他们的第一个考验。很多程序员的字写的都有大师级的水平，对于他们来说，楷书，行书都不足以表达他们的意境，狂草，唯有这个才能体现他们的追求。有不少程序员在填写这个简历的时候，字迹就和天书一样，当然文字也像蛇一般的在纸上盘绕。
对于我来说，我只是通过这张简历看看他对自己的一个态度，我不要求他们的字能够达到书法家的水品，但是至少要工整，整个纸张让人看起来要干净清晰。我很难看到你对目前的工作有多少的渴望，但是我可以通过你写下来的文字看出来你是否重视这个事情，如果连工作机会都不重视，那以后的态度就值得担忧。所以通过这个我也放弃掉不少的人，虽然有些人在和我免谈的时候给我感觉也非常不错，但是如果两者结合在一起评定，如果后面没有做好，那么我只能认为他是学院派的，能说未必能做。
超仔长的不像程序员的样子，一米七五的个子，相貌也有几分帅气，留着平头短发，每日衣着新潮个性。他平时个性活泼开朗，又一次他还请了一天的假，说是去参加超男的选拔赛，结果回来之后，感慨道：“强人太多了，人外有人。”不过自己到没有为被淘汰的事情耿耿于怀，倒是很享受乐在其中的过程。
超仔进入公司的时间也只有半年左右，在这边年里面他不到两个月就给他转正了，比公司规定的三个月试用期提前了一个月多。肯学习和努力的态度让我对自己当初挑选他感到非常满意。在第一个月培训的时候，让他整理了以前遗留的旧的项目，那些项目本身缺少相关部分文档，但是由于项目一直在延续开发，所以久而久之，也就这么一直持续的做下来，那些已经对这些内容滚瓜烂熟的人也就没有心情去做，后来者也之能够在前辈的口传身教的情况下才能了解其中的奥妙，我一直希望能够把这部分资料补充完整。但是由于人手上不足，所以就一拖再拖。
公司对新人有比较详细的培训计划，在这些培训之外，我对超仔说：“你看看这个程序，因为你以后需要维护和开发这个，如果你有时间的话，可以把熟悉开发环境的步骤写成文档，文档的格式可以参考项目组内其他的模板，内容你线考虑一下，但是有一个要求，如果另外一个新人来接触这个程序，我需要他再看了你的稳当之后，就可以把环境搭配起来，
些做的方式可以图文结合。”
结果在一周之后，超仔就给我说：“小余，我把那份文档写了一部分，你先看看有什么问题，如果不行的话我再修改。”
很多人都知道程序员非常讨厌写文档，所以很多程序员写出来的文档比写出来的代码还要难读，有时候读这种文档就是一种折磨，比读法律条款还难受，估计很多时候需要和法律文件一样，需要再配套上一本详细的解释才能把问题说明清楚。
但是超仔的文档让我非常满意的地方在两个地方，一方面再环境搭建的时候，用了截图的方式描述，而且每一幅图都是用作图工具简单的剪裁过，只保留关键部分，而避免乐像其他人那样是整个屏幕的图片，在么个图中对于操作关键区域还用红色正方形边宽标注说明，每个图片还有编号。
另外一个是整个文档是用Excel文档做成的，因为公司比较喜欢用Excel做给中开发文档，但我尝试着用打印预览的时候，让我惊奇的事情发生了，总共10页的文档，每一页都调整过，图片没有出现跨页的问题，而且打印的页头和页尾都修改过了，并没有保留上个文档的名称，作者和日期也都是正确的。
“页面打印是你调整过的？”看着文档，我轻声问道。
“我常常听到你让大家发邮件给客户的时候，要预览一下。所以我也就调了一下。”
听到这话，我心中是暗自窃喜，一个新人能够有这样的工作意识和态度，实属可造之才，技术可以学习培养，但是如果你想改变一个人做事态度其难度要远远大于技术上的培养过程。
超仔在后续半年的工作中也有犯了不少的错误，从刚刚开始技术上弱势，但是好学肯问，其进步的幅度不小，也使得他在很快的时间内能够达到对他所定位的能力要求。在于我看来这一切取决于他的态度，态度端正。
“态度端正，学习良好。”我的脑海中突然冒出这几个字，这不是小学时候，老师在每学期的期末成绩单上最喜欢用的两个评语。什么是态度？怎么才能算是端正呢？我在心中问了一下自己：“我的工作态度算不算端正呢？”或许像超仔这样的新人属于上升求学阶段，所以憧憬无限，但是对于我来说呢？当年何尝不是如此，现在还是不是一就有这样的心境呢？
“哎。”想着想着，不由自己叹了口气，难道我老了吗？怎么我还没有感觉到青春灿烂，这青春怎么就没了呢？看看坐在开发室中的其他人：老马，阿毛，木子，超仔，大师, 杰克这几个人，我们应该是活力无限的开发团队。
“Hi,小余，你在吗？”还没等我在继续发愣，MSN上的就弹出消息来。是上海的PM李。
我急忙回过去问有什么事情。
“我刚刚给你发了一封邮件，我把需要像客户移交的内容重新做了一个整理，你再看看有什么问题没有？”
我突然记起来，昨天晚上快接近9点的时候，我还在理发店修头发的时候，就接到李从上海给我打过来的电话，她问我现在有没有先前她发给我的计划列表，因为明天客户需要确认，所以她想今天晚上再把这份计划列表完善一下，如果我笔记本上有备份的话，给她转发一份，结果我刚好也只是把邮件接收到公司的机子上。最后我听到她在电话里说了一句：“那好，我明天早点去公司去修改一下，然后再给客户。”
李在一个月之前已经和公司提出离职的申请，因为她家庭的原因，她需要到国外发展。应该说再过两天她就会到美国去了，她本来是这个项目上海的项目经理，但是对于我来说，她是一个非常优秀的项目经理，从她身长我看到了一个项目能够成功的关键，态度。也就是她的这种工作态度，让整个项目有序稳定的进行。
在听完李的电话之后，我里一直佩服到，这才是工作态度。
本文出自：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人之间彼此独立成章，每个人都自己对于某个功能写一套代码，可能由于项目缺乏标准的原因，缺乏有效的代码注释，开发的人也懒的去读代码，分析功能，就自己写了一套；还有可能因为怕对现有的代码进行修改，影响了其余部分的功能，所以就再写一套代码，这样项目中存在的重复性的代码就非常多。在后期维护的时候，带来的结果是往往改了左边丢了右边，问题不断的出现。
在团队开发中，我们既要控制我们代码的冗余，避免出现大量无效杂乱的代码，这些代码往往来自于开发工具的自动生成，有时候来自开发人员低效率的代码编写。还需要对代码进行归纳集中，对通用性，公用性的代码进行抽象，提取。同时还需要加强开发规范的约束。通过这些来保证代码的质量和效率。
一个程序员一天能够写出来的代码是有限的，我们既要减少他们彼此之间的重复劳动量，还需要提高他们的代码书写质量，如果质量能够得到控制，那么效率就能够提高，进而就是时间的节约。如果我们能够从有限的时间中节约出来部分，那么项目的整体进行就是另外一番景象。
本文出自：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.”都是你需要具备的能力。如果说是对日，对欧美的外包服务开发，需要有良好的语言沟通能力，比如说日语，英语。还需要了解不同国家的文化差异等等，这个时候你可能需要充当起桥梁的作用，如何与国外的客户进行沟通和交流，包括有工作安排，技术上等一系列问题的沟通工作。
给自己的定位
项目管理本身就是一个比较复杂的过程，不像行军打战那样，有了一盯一眼的制度就可以管理好项目，因为项目的变数太多，情况迥异，也就没有放之四海而皆准的管理方法。所以对于不同类型的项目来说，我们需要了解项目的特点，在我们有良好的基础准备的前提下，根据自己的能力特点，再结合项目的实际情款来不断调整工作中的方法和内容。
虽然我们很难有一个标准化的管理手册来指导每一个希望做项目经理的人，但是我们可以从别人身上去借鉴各种成功或则失败的经验，特别是别人失败的经验，因为别人的成功可能我们很难克隆，但是我们可以避免别人错误再我们身上重演。
不想当将军的士兵不是好士兵，但是不想当项目经理的程序员未必是坏的程序员。毕竟对于技术领域来说，程序员的最终发展方向项目经理未必是一个最优秀的方向，程序员可以走的道路有很多，可以往架构师，分析师，资深技术人员，咨询师等等。路可能有很多条，而且每一条对于人员的能力要求也都不一样，都有良好的发展机会。所以对于自己能力的判断和分析，认清自己，给自己合理的定位是直观重要。让自己的才华得到发展和认可是今后职业道路上一个关键，自己要才尽其用。
本文出自：www.cnblogs.com/yice/archive//03/17/1414256.html
本文版权归作者所有，欢迎，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
篇8：项目经理成长日记（5）――五指有长短，能力各不同
系列文章目录索引：《项目经理成长日记》
终于结束了近一个小时的枯燥会议，每周五公司级别的项目周会就像一个例行的检查，多少有点不痛不痒的味道，大部分的时候就是一个例行贯事，每个项目组按照顺序汇报一下各自项目组的情况和需要，如果不出现大的问题的话，也就是有本上奏，无本退朝的一个过程，或许有些人觉得这是一个比较浪费时间而且意义不大的会议，每周浪费大伙一个小时的时间去再次陈述这些本来在邮件中已经说明的问题和项目进度，不过存在就有价值，这个会议的最大的功能在于能尽量使各个项目组之间有部分的消息互通，至少能让大家了解到一点，其他人都在做什么，从而避免了每个项目组过于孤立的现象。
今天的周会时间有点长，主要由于两件事情的讨论超出了会议的议程安排，第一件事情是大伟负责的项目目前进度出了问题，目前人员处在一个持续加班的紧张状态，即便如此，对于项目的最终Release时间还是比较确定的状态，用大伟的话来形容就是：“我们能够按时完成，但是可能会有点小问题。”一句比较含糊的托词，如果说套用官方的言词就是：“对于项目能够按时完成，我们还是谨慎乐观。”另外事情对于公司来说是一个好消息，公司将在下个月启动一个新的项目，这个项目是今年规模最大的一个项目，其业务方向主要针对美国的医疗领域，规模大概有150人/月。
这个项目将会被安排到我们项目组来处理，消息对于我来说就是一个挑战，对于自己来说，这个规模的项目也是超过了以往的一切项目，在会议上听到这个项目将由我来接手处理，不由小小的兴奋了一把，但是这股兴奋的感觉很快就被冲淡，自己粗略的考虑了一下项目组内目前的工作量和目前的人员情况，不由感觉到这个活不太好揽。不过有压力才有动力，这是我一贯的做事风格，类是这种明知会将苦重重的活，我越能够信心十足。我简单的在自己的记事本上写下了以下下周的关健工作内容：确认项目的具体开始时间和结束时间；调整目前项目组内的工作内容；向客户先要部分的开发相关资料；了解一下公司内部其它项目组的人员状况。
会议后半程的内容我没有听多少，只是对于大伟的问题大家有部分的讨论，我才回过神来参与，大伟虽然说自己还是有信心能够保证项目的进度，但是为了保险起见，希望从其它的项目组借调两个人来协助他们做一些类是测试的工作，这样的话总的进度就可以进一步得到保证。以目前公司的架构模式，每个项目组相对独立的运作模式，如果说希望从其它的项目组借调人员，这种短期人员的借调有时候是比较困难，因为每个项目组目前来说都处于比较繁忙的阶段，目前闲暇的人员不多，即便其它项目组肯借人，大多放出去的人员也都是能力相对比较弱，正常情况下人不可能把项目组内部优秀的人员借调出去，这或许也是人的一种私心。
在公司的协调安排之下，最后还是给大伟支援了两个人员，这才把讨论不休的会议打住。会议结束后我还在会议室坐了一会，我的脑袋里还在考虑下周的工作顺序，盯着自己的笔记本在对刚刚写的问题进行细化，把工作分解到下周的每一天。突然一股浓浓的烟味直接灌进我的鼻子，我不用抬头就能猜出是大伟，这个烟枪一天最少一包烟，如果遇到加班或则心情不好的话，估计两到三包都有可能。
“少抽点烟，怎么心情不好？”看着大伟吐着烟圈，我问道。
“没有，只是有点累。”大伟嘴里叼着烟，目无表情的应道。
“我看到你们项目组的那些去年刚刚毕业的学生，最近是天天加班到晚上11点左右。这是怎么回事？”
“噢，那时我故意的。”
“故意？”我一时没有明白，疑惑的问道，“为什么要故意呢？”
“我是按照我自己的工作能力给那些新人安排工作，如果说我是能够在上班时间内完成工作的话，那么那些新人肯定需要加班了。这样他们才能进步。”大伟的表情中开始露出得意的神色。
“怪不得他们要加班，你工作了多少年，他们才工作多少年，再说了你拿的工资和他们那得工资能一样吗？”
“我就告诉他们，如果你想工资那得和我一样，那么这些工作你能够准时完成，那么你就有机会，
”大伟熄掉手中烟头，用双掌在脸上使劲得措动。
“那你该不会是按照你的能力来做的项目估算吧？”对于大伟的这个逻辑我并不能苟同，但是我还是想了解项目的问题。
“嗯…..”大伟支吾着回答到。
“哈哈，你这是自作自受。”我对着大伟带着嘲讽的笑声说道。
对于大伟的做法我却是无法苟同，虽然他的失误在于前期的估算过于乐观而且并不准确。但是对于给新人安排工作的方式上存在有比较大的问题，如果说前期的估算出现失误，这些错误在后期项目开始过程中还可以进行添加人员的方法进行补救的话，那么对于人员使用不当的问题，就像整个项目过程的绝症，其会影响到整个项目过程。
项目组中开发人员从能力上有几个不同的级别，系统架构师（Systems Architect）,高级工程师（Senior Engineer）,中级工程师（Middle Engineer）和初级工程师（Junior Engineer）等等。对于每个级别上的人员的能力和开发技能都有一定的差异。这些就像我们手的手指一样，五指有长短，能力个不同。不同能力的人员应该在项目组中相应的工作内容和工作量。
在正常的项目中我们讲究的是人尽其用，但是不能把一个项目在开始的时候就设想是通过发挥项目组人员的超水准的基础上来完成。很多人都说人在一定的压力之下，能够超能力的发挥出他们的水平，但是比代表说所有的人都能够在这种环境下能够有说突破，很多人在持续长时间的高压下会显得精神不振，萎靡的情况。所以作为项目管理来说，不能再项目一开始的时候就采用这个立足点来进行开发工作。
对于大伟所说的那种歪论，我只能回应以自作自受的答案。我们给个人都是在逐步的学习和进步，如果说有一定压力灾，对于学习确实是一个比较有效的促进。但是作为项目经理来说，需要明白的是一个问题，我们的职责在于项目，而不是在于锻炼新人，新人进入项目组织后，通过项目过程的工作和学习能够提高他们的能力，这些是项目的副产物。而我们首先要保证项目的进度，质量。我在实际的项目开发过程中，对于给新人的工作计划都是按照其能力的80%-90%进行安排，很少会针对新人能力的100%进行工作任务分派，因为新人由于缺乏经验，所以在项目实际过程中如果遇到问题，他们解决这些问题的所采用的方法和思路都存在有时间的风险，有时候他们可能由于一个问题会难住他们，消耗掉很长的时间。即便我不断强调说如果有遇到问题，在一个小时内解决不了的话，就要把问题抛出来给大伙来共同处理，但是往往这个问题被最后迫不得已提出来的时候，都是在一天或则更长的时间之后。新人在开发过程中遇到这些问题的概率非常高，所以在工作安排工程中必须要考虑到这种风险。所着一旦推倒第一张加班的牌，那么后续的将是多米洛效应，加班将一发不可收拾，进入恶性循环阶段。
对于实际的项目中我会采用减算安排工作的方式，那是因为我需要保留对项目整体的进度有更大的回旋缓冲时间。无论对新人还是对高级工程师，中级工程师和初级工程师我都会采用一样的策略，因为人脑不是机器，所以我们无法保证我们时时刻刻都能正常的满负荷运转。但是在平常的学习过程或者非实际项目的锻炼过程中，我会采用超负荷的工作安排模式，这个时候给人员的工作量安排都是100%-120%的程度，因为这个时候我的主要目的在于人员培养，所以需要一种超强度的环境，营造一种压力的气氛。其实开发过程何尝不是一个不见硝烟的战场，如果你想要在战场上不受伤，只有在平时多多受伤，这样在真实的战场上才能从容应对。
对于项目组中我们需要比较清楚的了解每个成员的能力和个性，如果对于他们的能力了解能够像看着我们手指头那么清楚，我们就能够依据他们的长短，让他们协调发挥出水平。我们需要避免工作不分能力，均等划分的安排方式，更不能把项目寄托在成员的超水平发挥的基础上。在工作中我们需要明白项目的最终目的，项目成功还是锻炼人员，从而采用减算还是加算得工作安排方式。
本文出自：www.cnblogs.com/yice/archive/2009/03/25/1421328.html
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
篇9：项目经理成长日记（7）――说是细，做的粗
系列文章目录索引：《项目经理成长日记》
估计绝大部分的公司都在提倡一个口号：“注重细节，”但是往往是口号容易喊，行动却是千辛万苦，何谓细节？也就是自身工作的每一个环节、每一道流程的琐碎小事，而这些小事又常常容易被人忽略。有很多人有雄才大志，内心中充斥着舍我其谁的非凡气魄，但其眼高手低，小事不屑，大事难成，最终只落得一事无成的悲哀。
软件开发亦是如此，提倡了许久的注重细节，更有甚者许多公司标榜自己的优势在于：“我们更注重细节。”然而如果说我们要做到和自己提出的口号一致的时候，我们该如何去做？该做什么的事情才能够称得上我们注重了细节呢？
今天早上我把阿毛狠狠的训了一顿，我扳起的面孔，铁青的脸色连我自己都可以感觉到我的怒火不小。看着阿毛那貌似无辜的样子，我知道他肯定认为我是小题大做，估计找个借口来找他出气。
今天早上我在接收邮件的时候，看到昨天阿毛昨天给客户发送的邮件中，客户的名字拼写错误，把Charles拼成了Chirles，这已经不是他第一次把这个名字拼错，之前我只是压制自己的火气，毕竟人都会有犯错误的时候，所以当下用比较缓和的口气告诉他：“阿毛，你把Charles的名字写错了。下次发邮件的时候一定要小心，不要把人家的名字搞错。”
“嗯，我知道了。”对于阿毛毛燥的个性，我当时对于他漫不经心的回答做了一个预言：“这个错误他还会继续犯。”
结果不幸让我预言中了，时隔不过几天，把客户的名字再次拼错。我就决定来个小题大做，需要让阿毛知道这种粗枝大叶的做法是到了该改善的时候。我把阿毛叫到会议室中。
“你昨天发邮件的时候，在发出去之前，自己再次检查过了吗？”估计我一脸严肃的样子让气氛马上变得非常紧张。
“检查过了？”阿毛没有看着我，低着头，声音有非常小。
“阿毛，这已经是你第几次出现这种大意的错误？以前写代码的时候没有按照标准命名，代码注释没有按照标准书写，甚至界面上的文字出现拼写错误，这些都算了，但是你连客户的名字都能够写错，你想想客户在接到你的邮件之后，一开头就看到自己被人改了名，会高兴吗？他会怎么看你的呢？”
我看着阿毛低头默默不语的样子，我本想继续说的话题也就就此打住，对于眼前这个刚刚毕业一年的新人来讲，或许他觉得我说说的一切都是小事情，能够按照要求通过代码实现功能，把功能做到尽善尽美才是他的追求，变量命名，对齐代码，代码注释等类的小事不是衡量他能力的指标。
我没有告诉他客户在评定我们能力的时候，不只是看我们是否能够实现功能，因为那些是项目开发的基本要求，他们对我们能力的考量是在于每一次的交互沟通之中，通过对邮件，文档，代码的细节部分去评定你以及于你的开发团队的能力和水平。有一次客户在嘱咐我们和他们项目组下面的某个开发人员沟通的时候需要加倍留心，虽然那个开发人员的能力和热情都很不错，但是客户觉得他比较粗心，因为那个开发人员每次整理的文档的时候，都随意采用文件格式，可能是word或则Excel，反正每次都不太一样。就这么一件小事，客户就在主观里认为这个人存在有问题。对于他们自己内部开发人员都是如此，更何况对我们，这评定的尺度可能更为严苛。
我也不知道该如何继续训斥阿毛，我们彼此沉默，看着对方。
我在想着该如何去指导阿毛，让他了解到要注意细节，毕竟即便我像唐僧一样，把“要注意细节，做好细节。”在他的耳边天天念叨，估计也只是他头上的紧箍咒，只会紧紧地勒着他的脑袋，让他感到不适和反感。
做好细节？我自己是怎么做的呢？我在努力的回忆自己这么多年来的工作过程。记得在日企的时候，我自己学会的第一件事情就是在发送邮件的时候需要调整邮件的字体和字号，发信得内容是日文，所以需要把邮件内容设置成日文的明朝字体和对应的字号，
在日企的三年期间，每一封邮件我都这么处理，甚至说现在发送英文的邮件，虽然说已经把邮箱的字体和字号都做了设置，但是为了避免有时候从word拷贝过来的文字带有的字体格式，我还是会在发送之前再次设定。这只是小事，我做了这么多年，已经成了一种习惯。
我在回忆自己这么多年来有多少类似的习惯，我倒不想把他一一列举给阿毛听，因为很多东西都微不足道，比如我要给客户发送设计文档或则工数预算文档的时候，我会先做一个打印预缆，特别是Excel的格式，确保打印效果不会出现跨页，还有确保目录是否已经刷新等等，因为做对日外包的时候，日本的客户会将内容打印出来后讨论。如果说有一次客户发现打印的图片或则格式不整齐规范，那么第一直观的印象就是一个差值，当然做好客户也许不会感觉到什么，因为那对于他们来说，每次都如此，那么这些就是应该的。
在我团队工作的人都知道，我在做代码Review的时候，先看的是代码的折叠和对齐，因为自己曾经遇到过这样的客户，如果发送给他们的代码中，出现代码没有按照要求对齐，那么这也算一个bug，会最终统计到产品的质量中。而且是一个比较低级的bug, 这是日本一家非常大的软件公司，他们的理由倒也非常简单，如果连代码的对齐都做不好，那么怎么能够相信你能够保证产品的质量呢？或许吧，随手对齐代码的小事，也就成了他们检验的最开始的标准。
很多类似的这些都是小事，也都是细节，这么多年来自己都在重复地做，对于自己来说很多已经成为一种习惯，但是如果统计起来我为这些习惯付出了不少额外的劳动，即便是文档能够保证打印正常，每次改动后发送给客户，我都要多此一举地检验，这样自己才能够安心地发送给客户。如果现在希望阿毛和自己一样能够明白这些，做到这些，有点强人所难的味道，毕竟现在他的目光还没能够看到做到这些事情会给自己带来多大的提升，不如解决一个技术难点，多看技术知识点能够带来的收获大。
我没有再和阿毛说得更多，只是再三叮嘱道：“下次一定要注意这些细节的东西，不要让别人看到你毛毛燥燥粗心的样子。”
作为项目团队来说，每一个项目经理都会意识到需要注意细节，也都能够明白注意细节能够进一步促进项目的质量，但是如果说要实际做起来，有很多的琐碎小事都容易在过程中被遗忘，抛弃。特别是在项目周期很紧张的情况下，连主要的开发周期都显得非常紧张，哪有时间去理会那些对齐，注释等等小事，所以每个人都在努力地赶工，结果虽然项目在计划期限内做得个似模式样，准备给客户交付使用的时候，小问题不断，此时再回过头维护的时候，那些代码有甚者连自己都要仔细揣摩回味才能够知道为什么当初要这么做。
我们知道要注意细节，但是如果我们真正要做好细节，不论做什么工作，都要重视小事，关注每一细节，把小事做细、做好、做透。这些小事在实际的过程中看似可有可无，而且极为消耗时间，但是如果能够坚持做好，持之以恒，形成处理事务的良性循环。“泰山不拒细壤，故能成其高；江海不择细流，故能就其深”。其效益也就非常明显。
项目管理中有一个节约时间的原则，在有限的时间内我们需要合理的利用时间，毕竟很多项目的开发周期都比较紧张，时间不够，所以我们需要避免过程中的错误，特别是重复性的错误，如果我们能够着眼于细节，说到做到，那么我们就可以一方面提高项目质量，另外一方面也为项目节约反复开销的时间。
我不知道该如何让阿毛明白这些道理，大量的工作中，我们都是在做一些小事，假如能把自己手头上的每一件小事做好、做到位，就已经很不简单了。如果整个团队能够做到这些，我坚信无论是再难啃的硬骨头项目，我也是充满信心。
本文出自：www.cnblogs.com/yice/archive//03/05/1403780.html
本文版权归作者所有，欢迎，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
篇10：项目经理成长日记（2）―― 你能承受多大责任
系列文章目录索引：《项目经理成长日记》
自己一个人独自回想工作了这么多年，到底给自己留下了什么？如果要给自己找一个答案，或许有两个会在今后很长一段时间一直影响自己的东西，一个是在工作了这么多年让自己明白了我们要担负什么样的责任，另外一件是工作这么多年给自己的颈椎留下了不小的病症，一好一坏或许是这么多年的最大收获。
我们该如何看待责任
时至今日蒙牛老总牛根生说过的那句话还让我记忆犹新，“有德有才，破格重用；有德无才，培养使用；有才无德，限制录用；无德无才，坚决不用。”在我认为德的基本就是这个人的责任心和他的态度。无论是软件行业还是其他的行业，在很多的时候考核一个人是否符合相应的工作岗位，职位技能往往不是最主要的考核标准，而在所有的考核标准中，人的品性和责任态度才是考核的关键。
什么人活得最轻松，不负责人的人。丈夫有责任给妻子一个良好的生活环境；父亲有责任给孩子一个良好的生长环境；孩子有责任赡养自己的父母；员工有责任做好自己的本职工作；所有的这些都是一些基本的责任。如果一个人富有责任心，生活中的这些责任会让自己感觉到沉重的压力，一旦人在这些压力的之下，要想过的轻松舒服就很困难。所以如果你希望自己过得轻松写意，你放下一切的责任态度，做个不负任何责任的人，那么或许你会过得比较轻松，但是你也将成为社会中一个不合格的人。
软件开发本身属于脑力密集型的劳动，所有的一切都依托于人，软件行业本身和其它的制造行业有一个本质性的差异，软件主要依靠人的智慧来进行工作，虽然我们现在看到很多的软件工程管理书籍，无论是大师的作品，还是坊间口声相传的经验之谈，我们都很难解决一个问题，我们很难像制造行业一样，让我们每个程序员写出来的代码都能够像机器加工出来的那样，每一个行代码都能够像一个模子印出来的，很难做到整个团队写出的代码像出至一人之手。所以软件行业的工程管理比其它的工程来说要存在有更大的困难，那么在这些问题困挠之下，整个行业对人的依赖尤为严重，对人的依赖程度也就造成对人本身品德和责任心的要求程度相对要高。
在自己工作这么多年来，感觉最轻松的时候还是刚刚毕业的时候，那个时候是初出校门，作为一个新人进入项目组中，对于自己最大的挑战主要是能不能按时准确的完成自己相应的模块开发工作。后来开始负责项目之后，虽然也在做编码开发工作，但是所担心的和让自己欢欣的事情和开始已经完全不同。如果你希望自己能够能够作为一个合格的项目经理经理，那么你首先需要明确自己的肩上的担子的分量。在我们的工作中，我们每个人必须承担工作的各种责任，如果我们缺失这种看待责任的态度，那么工作最后的结果往往将会以失败告终。
对于自己在这几年的最大一个一个收获就是让自己更明确到责任重于泰山的道理。当然也是这种态度让自己能够坚持着把一个一个项目做下去，做好这些项目。如果要对自己做一个评价，或许在技术上我不敢说自己有十足的优势，但是这些年养成的这种做事情的方法和态度还能值得一提。
在项目中你该承担什么责任
如果你要问项目组中谁的压力最大，一般说来应该是项目经理，当然项目经理所拿的工资相对来说也会比较高，责任和压力本就应该和报酬成正向比例关系。项目经理对下必须对项目团队成员负责，向上必须对公司负责，同时还需要纵向向客户负责，所以项目经理经理就像一个传动轴承，这个项目的运作应该在他驱使之下有效稳定的运转。
项目经理需要考虑项目的成本因素，所有的公司都是以盈利为主要目的，有时候公司会出于其他的因素和目的，对于项目的盈利并没有很严格的要求，但是项目经理要有成本的概念和意识，要有团队的总体成本和利润要有基本的计算方式。同时还需要控制项目的质量和进度，还有些项目还要求有保密意识和其他的相关要求，这些都是项目经理需要向公司负责的地方。
如何组建好一个团队，如何培养团队的成员，让每个团员很够在一个比较良好的环境中工作和学习，能够实现每个人的目标和各自的价值观，把团队建设成什么样类型，和项目经理所采取的方法有直接的关系，有些项目团队组建后团队人员如走马灯似的换，有些团队组建后队员除了编码之后就没有任何的学习机会，如何利用有限的资源和合理的安排，让团队的成员都能够发挥各自的特长，让每个人都能够体现自己的价值，有时候需要替项目组的成员去和公司去争取他们所应该有的福利和报酬，这就是对项目团队和团队成员所要承担的负责，
我们每一个项目最终都将面对我们的客户，有时候我们的客户的要求会让我们很难接受，甚至有时候会让我们团队感觉到很恼火，但是作为一个项目经理需要化解这些对项目团队一个不利的因素，一方面需要避免影响团队的士气，另外一方面需要和客户进行沟通，明确那些要求可行，那些要求不可行，对于不可行的要求需要给一个比较合理的解释，避免由于后期无法完成对客户造成欺骗的行为。同时需要控制项目的整体进度和质量，保证项目最终能够解决客户的为，这些就是对客户负责的一个态度。
如何树立团队的责任意识
对于项目组中项目尽力所承担的责任应该说是最大的，无论项目的成败都和项目经理由直接的关系，所以任何一个项目做项目总结的时候，如果项目成功的话，需要给项目经理记上一功，如果项目失败的话，不论任何原因，棒子首先需要打在项目经理的身上。项目经理需要对项目的得失成败负上完全的责任。
在一个项目团队中，需要有各个不同的角色相互配合才能最终完成项目，需求调研人员，系统分析人员，高级程序员，初级程序员，测试人员，配置管理人员等，虽然项目经理在项目中的责任最大，但是项目中每一个成员都会有相应承担的责任，或许说着这都是一些工作的职责，开发人员需要按照开发中的各种要求进行开发工作，测试人员需要按照测试的要求准备测试文档和数据等，所有的角色都会有各自的工作内容，在实际工作中我们是每一个角色协作来完成项目，有时候由于项目的规模偏小，有些人可能会同时充当多个角色，比如说高级程序员有时候需要同时兼顾系统分析人员，项目经理有时候还需要兼顾测试等等。但是不论规模的大小，项目经理需要非常清晰的意思到每个角色的工作职责，在项目分工中对各种工作要比较清晰，合理化安排。同时也需要让每个工作的人员清楚的知道自己的工作要求和检验的方式，避免含糊性的安排，做到责任清晰。
明确责任的首要是明确工作内容，对于团队成员中需要做到责任均衡，尽量避免能者多劳的问题，工作中进行工作安排时往往容易把工作重点都落到部分能力较强的人员上，这种安排比较容易造成工作天平的倾斜，一旦倾斜的严重，这部分开发人员就比较容易造成由于精力不足造成质量问题。所以项目经理在安排工作中需要有个权衡，如果说存在人员能力不均衡问题，那么在工作安排的时候，需要尽可能抽取重复性的工作，让能力欠缺的人员做这部分工作，同时需要协调他们学习，也需要明确学习的目标和结果。
对于团队中我们需要树立一个责任意识，同时需要有合作精神，在项目开发中整个团队需要彼此合作，有时候一个人的问题有时候会影响到整个团队的质量和进度。我们最终给客户交付的是一个完整的程序，其中任何一个部分出了问题，客户对整个产品的评价都会因此而改观，客户不会说那个模块怎么怎么样，而是说你这个程序怎么怎么样，这就代表说是一个整体的结果，所以项目经理需要在团队中树立起这种整体的责任意识，避免团队中出现个人自管门前雪，不理他人瓦上霜的现象。
你能承受多大责任
你有没有评价过你的项目经理，你有没有对你的项目经理感到无奈和气氛，如果你希望自己能够往项目经理方向发展，在我看来你首先需要考虑的不是你的技术背景，你的管理经验是不是足够，首先要考虑的是你是不是有能够承受那些责任的心态。如果你是项目经理的话，那么你负责管理的团队无论人员多少，他们需要在你的协调下工作，那么你肩上担负的就是那些人的工作结果和评定，还有来自公司的各种压力和考核。这些比单纯写代码要劳心许多。
影响项目成败的因素有很多，但是如果说项目经理缺少责任心，我可以说项目必败无疑。正是因为这样，我才会在此一再强调责任心的问题。
本文出自：www.cnblogs.com/yice/archive/2009/03/10/1407411.html
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
