易栈网-膘叔

看看别人是怎么评价技术骨干做项目经理的，其实任何事都有利弊啦，不过这里说的几乎都是弊。
学工商管理的时候，对于一个职业往往都是讲究内拔外选，其实是和这个道理是一样。
内拔，对于内部的信息、资料都相对比较熟悉，同样，还有对于人员的能力也是相对熟悉，配合起来可能会比较方便，但缺点是眼界可能不会太开阔，比较容易局限于目前的视野
外选，可能技术能力较强，但同样也有缺点，很多人对于空降兵比较排斥，对于人员的能力不熟悉，短时间内不知道如何分配资源。

再看看别人说的吧：http://www.cnblogs.com/laozizhu/archive/2009/04/04/1429640.html

    开发骨干，由于主要或全部精力均忙于具体技术工作，各种项目管理任务(如：项目分析/评估、项目计划的制定/检查/调整、上下左右的沟通、专业资源调配、 项目组织调整、项目财务控制、风险分析/对策等)不可避免地疏于顾及，项目管理的事情“没人做”，导致项目控制的问题“积劳成疾”，后悔莫及。

    技术骨干担任的项目经理，不可避免地存在着“技术崇拜”，尽可能采用新技术。即使是需求明确的功能，由于实现方式有多种路径，一般都是从技术上采取最优的 路径，而不是从用户操作方便的角度上选择操作最方便、快捷的路径，用户必须严格按开发人员所预设的操作方式进行操作。

    说句老实话，用户是不管你用什么技术的，先进或落后的技术都可以，只要能满足用户的需求即可。这种类似闭门造车生产出来的产品，自然就是操作不便，功能差 强人意的。还有一种情况是，这种情况一般发生在项目后期，开发产品的情况较多，随着开发的深入，总会发现缺少某些功能，或者某些功能不够强大。项目经理对 功能的增加、删除、修改，不是通过集体讨论确定或通过从市场前线人员中了解确定，而是通过凭空想象，拍脑袋来作出决定。特别是对于某些功能的添加，由于项 目经理都无法把握用户是否需要这个功能，需要这个功能的程度，因此是很难令开发人员把握此功能的目的。当然，既然大家都无法把握用户是否会用这个功能，那 自然是应付式开发。只要过了测试，过了项目经理这一关就OK拉。

自从阿朱的那本《三五个人七八条枪，如何走出软件作坊》热卖后，很多有类似经验的人也开始逐步把自己的项目管理经验放出来与大家共享了，或许风格各有不同，但事实上都是为了解决相同的问题。
阿朱因为是做了多年的项目管理，而且从文章看来，他在初期也是一个牛B的coder，然后一步一步的走到今天。
或许这也为那些coder们指明了一个小方向 ？
《项目那点事》是我在博客园上看到的一篇文章，内容还是算诙谐风趣，还没有仔细看完，但好象就是从某一个项目说起，个人以为，该文章可能出不了书。呵呵，随便猜测是不对的
有兴趣的朋友可以去：http://www.cnblogs.com/Pegasus_cc/ 查看一下

项目要求写小结，其实我也很奇怪，不过想想这是领导安排的任务，这还是要完成的。

项目从10月份开始，1月1日上线，共经历了整整 三个月，在这三个月内，我深刻贯彻项目小组领导的精神，按照需求根据进度逐步开展代码的编写工作。

在项目初期需求尚未明确的时候，领导给予了我们充分的授权，但这也使得我们在没有人带领下而出现了迷惘。正所谓，大海航行靠舵手，领导在中后期果断的介入了项目，使得我们在迷惘的灰雾里找到方向。

正是由于领导的后期介入，我们在需求分析、系统评估、代码编写、小组协作方面得到了充分的支持，使得项目的进展极其顺利，最终我们在项目上线前一星期完成了编码工作，并留下了一周的充分时间交由测试小组进行测试并进行程序的BUG修复工作。

在这次的项目过程中，我充分学习到了如何进行小组协作，并在小组协作方面有了一定的心得，对于项目的控制、协调也有了一定的了解。在小组协作的时候，PHP与JAVA代码之间的通讯、协议的制定等也有了长足的进步，可以毫不夸张的说，在下次进行协作的时候，小组之间的联调效率可以上升100%左右。

在项目的进行中，也曾因为理念不同以及小组协作方面与领导产生一定的分歧，但由于领导的大度使得这些问题最终都得到了解决。同时为了照顾加班的同志，领导与加班人员共进退，来得最早走的最晚，使得在加班的时候不显得孤独。

通过三个月的项目进程，使得我在代码编写能力、小组协作能力、进度管理经验、需求分析等方面有了极大的提高，迫切希望下一次项目的到来，可以让我在公司能够学到更多的知识。

写了一小时的东西。按了一个alt+向左的箭头，什么都没有了。。。

不过，我还是会重写的。。一定，i promised

感谢小余给我们带来的文章。本想根据其中的内容想润色一下，但仔细思考后还是放弃了。每个人的思想和观念都有其独到之处，如果我强行改变，那就是改变原作者的思路了。

原文网址：http://www.cnblogs.com/yice/archive/2008/08/08/1264044.html

内容开始

    有个人在交际场合中一言不发，哲学家狄奥佛拉斯塔对他说：“如果你是一个傻瓜，那你的表现是最聪明的；如果你是一个聪明人，那你的表现便是最愚蠢的了。”

    我有个朋友自从前年年末开始召集人马进行一个产品的开发，从零开始做这个产品，历时一年多的努力，据说产品在内部也改了5，6个版本。我看过他们的东西， 总体给我的感觉算是不错。从开发到现在也过来一年多的时间，产品也有了初步的 成型系统，而且比较稳定，按照市场运作的模式，应该进入大力推广的阶段。作为开发内部来说，应该进入一个比较平稳的维护和升级阶段，但是从我和朋友聊过之 后，还有与准备离职的开发人员交流之后，发现其中还有不少故事值得说出来给大伙听听。由于我对整个项目的实际进展了解并不多，只是从侧面去观察，所以文章 所简述的观点都是基于个人的看法。在此我还需要强调一点，些这篇文章不是为了批评PM的对与错，只是希望通过我这位朋友身上发生过的事情，折射出一点道路 来，取其精华，也要避免走他曾经走过的弯路。

   在项目中需要被提及的任务有三个，资深的开发人员SD（senior developer),项目经理PM（Project Manager),技术型老板TB（Technology Boss).这三个人中我接触比较多的是PM,他也就是我朋友，以前共事的同事，对于他的性格 和做事方法和能力比较了解。SD,我以前的同事，虽然接触不太多，但是对于他的技术和做事态度还是了解。TB呢？说实话，没有见过这个人，只是听其他的人 介绍和从事情中来判断他。

   PM是从零开始负责这个产品的开发，从招聘人员，产品的分析，设计都是具体参与在这个项目之中。但是从项目的开发到现在，应该说与他的努力是分不开的。但是本文的主要也是针对于他来写的，因为他是协调TB与SD之间的桥梁，应该说他需要对整个项目进行总体控制。

    由于整个公司属于创业型的公司，虽然有另外一家实体企业提供开发资金，但是很多事情还是需要从头开始做，在一开始的时候，PM既要当项目经理，也要当大内 总管，一手抓项目开发，还要一手抓厕所是否有卫生纸等等。这些琐琐碎碎的事情应该说早就超出了一个正规PM的职责范围。但是创业初期，就要求人员要身兼多 职。我想要不是我朋友的好性格和脾气，别人很难能坚持下来。

    没有PM的好性格，项目不会有今天的结果，但是也是因为他的好性格，才会使项目出现了比较严重的问题，真可谓成也萧何，败也萧何。如果真正从软件开发项目 经理这个角色来看我这位朋友，我觉得他做的并不到位。我们从项目开发的一些事情来看待这些问题，和欢迎大家讨论一下如果是你换到他的位置，你该怎么处理。

    5月的时候,PM从北京回西安来招聘人员(公司原本在西安，今年初的时候搬迁到北京），我帮忙一起面试人员。在招聘过程中他感慨到：“现在招聘不到好的美 工？”听完这句话我觉得非常差异，就听他继续说道：“我希望招聘一个美工，能最快的出图，把老板的项目转变成实际，现在开发中美工的速度跟不上开发的速 度。”

    细细品味他的这两句话，我就感觉到他项目有问题，我当时疑惑的问他道：“我觉得很奇怪，美工的速度怎么会跟不上开发的速度？”因为做Web开发的人来说， 一般情况下，UI的开发和程序的开发是前后进行，有了UI之后，开发人员再进行项目的开发，虽然有时候会受一点点影响，但不至于影响道整个开发进度。后来 继续交流过程中才知道，原来美工出图慢的主要原因是老板变化太快，以至于如果老板一个Idea之后，隔天美工出效果，开发人员进行开发，等开之后老板会认 为和他想的存在有差异，需要在次修改，就是这样的循环过程中就出现了“美工缺乏的感慨”。

    从与SP的交流中，听到他感慨道，开发中变的太快了，因为TB原先也是做软件出身的，但是由于不是做当前的这个类型的开发，所以对某些问题有时候一知半解 的，而且TB是个追求完美的人，其实由于这套产品对图形的质量的要求非常高，因为图形经过处理后需要打印出来，所以我倒可以理解TB对这方面的完美追求。 但是问题不是处在TB的完美上，而是对于TB的个人强势上面，SP说过，在沟通中TB时时常会抛出这句话：“除了问题你负责啊！”。现在SP也决定从这里 离开，我略微了解了一下，由于各种问题的存在，核心的开发人员都有离开的念头，至少作为PM口中赞不绝口的SP已经离开了。

    从事中去分析一下，整个项目开发中可能有不少问题，但是就项目开发的进度把控这块，PM就做的不够到位，至少他没有守住项目的需求变化，老板一个想法，整 个项目进度都会受到影响，而且这些想法有时候时一瞬间的灵感。PM在项目开发过程中，对于如此频繁的需求变化，需要对需求进行汇总，每一个版本的开发尽量 都按照原定的时间安排进行，对于不同的需求变化，在汇总分析之后，阶段性的追加到项目中，以此来降低需求变化的次数已经明确需求的具体内容。对于老板的 Idea倒可以专门安排人员对应他，做原型图后讨论可行性，不要让老板直接接触到开发具体的过程，特别是跨过PM来安排开发人员进行开发工作。

    对于TB的强势没有抗住，如果TB的要求合理，也要尽量避免打乱现在的开发计划，维持开发团队的进度稳定。如果TB的要求是天方夜谭，那就要顶住说:"除 了问题我负责。”对于PM来说，在实际过程中需要良好的沟通技巧，不能单纯对上或只向下，PM除了具备有项目过程中的良好项目风险管理和进度预估，掌控能 力外。另外一个角色就是扮演缓冲剂，调节各方面的沟通与交流。千万不要到了项目失败后，自己感慨说我没有功劳还有苦劳，这种阿Q自慰的方式对于希望成为 PM来人来说就是表示你的失败。就像文章开始的那则笑话中所说的那样，在相同的场合，你的角色不同，你做的事情的评定就不一样。

————END————