项目管理之我见 (转)

项目管理之我见 (转)[@more@]

项目管理之我见XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />

徐岩柏

 

一个好的管理者不是那种需要个人成功

或以人为本的人，而是那种喜欢权力的人

—大卫·麦克莱兰(David McClelland)

 

  我非常欣赏这段名言，猛然看来这可能与我们的思想格格不入，中国几千年的文化都是人与人之间和和美美，你好我好大家都好。可是这种境界可能很难长久。“不想做将军的士兵”是成不了一个好的管理者的。

  本人有幸得老师指点，在学生时代就开始商业软件的编码，从学徒到技术狂热追寻者，从程序员到一名项目管理者，每一步都给了自己很多的教训。现在从一个新的起点，我开始冷静下来，分析项目管理中的方法，这只是笔者自己的拙见。

  项目管理者上有懂事层、经理层，监工层，下只有被称之为‘上帝’的编码兄弟，如果把编码人比喻称普通工人农民，那项目经理就应该是基层三级干部，嘿嘿。做基层干部是及其不容易的，需要很好的经验和管理技能。那么究竟如何做一个好的项目经理呢？过程如何？

  一个项目要从下面几个方面来考虑：项目成本、技术范围、时间控制、结果效益。这些也不是孤立的，它们是环环相扣的。

  项目成本决定项目的生命，一个50万的项目和一个500万的项目其生命周期是大大不一样的；技术范围可以决定开发的人力成本，对项目的质量控制有重大的影响；时间控制则可以在市场上占据先机和优势，同时对项目的人员配备产生影响；结果效益不言而喻，决定企业的生死。

  做一个项目往往经过如下的过程：

l  需求分析

这个过程就是知道要做什么的过程，能把生活中的业务用文字描述出来，并进一步细化。这个过程是个艰难与抽象的过程，可能需要反复多次。这就要求一个项目经理有敏锐的观察力和良好的文字功底。如果你想向这方面发展，你要先培养自己这方面的能力，如果你连笔都懒的动的人，我想你可能不适合做项目经理。有时领导和上司的一句话、客户的一个埋怨都是一个关键的材料。编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口，这要是一旦做错，将最终会给系统带来极大损害，并且以后再对它进行修改也极为困难。那么如何才算一个较好的《需求分析报告》呢？笔者认为有这么几点：1需求要完整，能把客户的要求都包含在内，同时使得开发者能从中找到设计和实现这些功能的信息。2需求要正确，那种凭空猜测的功能是不可靠的，而且需求不能有二义性。3需求要可行，这可能是不少项目经理的误区，项目一开始就设想要如何如何的功能强大， 没有详细考虑使用的环境和限制范围，使得在实施时因技术可行性原因而修改需求，这就要求和小组的部分人员对需求的技术进行可行性分析。

l  项目计划（设计）

计划决定着谁去做、花多长时间去做、消耗多少费用的问题。作为项目经理，你在这时可能还是孤家寡人，你要制定良好的设计报告，这是向老板要兵要马的依据。一个良好的设计报告可能是这个项目中最重要的部分，甚至导致项目的生死。当然这也是最难做的，由于项目管理是一个创造性的过程，项目早期的不确定性很大，所以项目设计又不可能在项目一开始就全部一次完成，必须逐步展开和不断修正，这又取决于能适当地对设计的执行情况作出反馈和控制，以及不间断地交流信息。

l  项目的实现（编码）

这一部分就是项目怎么做的问题了，虽然这些是每个程序员的工作，可是作为项目经理，这时更要有良好的组织才能。有了兵马，如何行军打胜仗？应该从下面几个方面来考虑：1 团队建设。怎么使得这个团队有生命力，发挥每个人的能力，这可以说是项目经理的社交技术，项目中有性格各异，兴趣不一的兄弟，如何协调。比如外向型的人，说话直来直去，可能会使你难看，下不来台，可是这种兄弟往往能指出你的不足和缺点，使你更好的改进你的工作方法，即使吵了架，喝上两杯也就什么都忘了；一个内向型的兄弟就应该冷处理，不要当面说其不是，要单独细聊，还要及时关心他的生活。了解每位兄弟的兴趣和长处，众人拾材火焰高吗！ 2项目的分解。怎么把一个大的项目分解,需要项目经理有丰富的经验，如果你不懂技术，那你应该去做投资、做懂事、总经理和人力资源经理。作为项目经理你应该能知道你分解的每一部分有多大的工作量和技术难度，它交给哪一个开发者最为合适，这样你才能确切的安排时间进度；另一方面就是这些分解部分的重要级别，一级重要的部分、可能会给其它部分带来重要影响的部分(一些共用模块)，要优先安排进行。其它的不重要的部分接下来进行，一旦发生不可控因数，可以把最不重要部分先去掉，同样使项目顺利交付。项目经理可以不是本开发团队中技术最好的，但他(她)一定要是对需求最清楚的。还有就是有个攻关人，当项目进展中出现了技术难关，影响了项目的进行，或者项目的中间有人员流动，就需要攻关人来解决难题，其它的兄弟则继续按计划进行，来保证项目的按时交付。3 时间控制。有了兵马，有了对兄弟的了解，有了项目的分解细化，剩下的应该就是监督和交流了，每个人只是埋头苦干自己的部分，你是没办法了解进度的，交流不会影响进度，一个良好的时间控制，能使得每个人工作起来很轻松，不要把所有的时间都用在编码上，IT业是个知识爆炸的行业，每个人都要不断学习新知识，这就需要有一定的时间来创新。要是Micorsoft的员工都只是写程序，那就不会有如今优秀的软件(思想)出现。只有个人和项目都能到达目标时，人的成就感才会更强烈，才不会有我出卖脑力就是混饭吃的感觉。项目经理的另一个误区就是认为他的兵可以在此项目中学到更多的知识，不用再另外安排时间，“你做这个部分可以学到×××技术或你看这一块也很有难度不是,可以学到很多”等等，可是你也冒了最大的风险，你不能知道他需要多久才能学会，你不知道在使用这个他不熟悉的×××技术时会有多少bug,没有办法，你的项目就成了他学习新知识的试验地。从编码人员来说，他也担心出现问题，当修改BUG成了工作一部分时，他就会灰心丧气，后果也是很糟糕的，怎么办？那就给你的兵一个学习、创新的机会。当每个人知识都在增长时，项目还不更好控制吗？4质量控制。说白了也就是编码质量控制，这同样也要求项目经理懂技术，在个性化的算法中要有统一，界面如何、命名如何、注释如何、数据和算法如何以及最终的性能如何都要有事先的规划，包括使用的设计开发工具等都要做好要求。

l  项目的测试

当编码完成时，作为项目经理的你不要认为可以松口气了，你要对可能出现的任何结果负责，BUG出现了，你要分析可能原因，召开项目交流会，不要把责任一下子推到你的兵头上，要协助解决，使得能将错误快速排除。还有就是测试报告不要要求太高，例如每一个普通操作数据接口，你都要进行压力和性能测试是很荒唐的，你是在测数据库，不是你的项目。作为项目经理你要清晰认识到：bug是不可避免的！

l  项目的维护与升级

这是最后一个问题了，你要利用这一段时间对项目进行总结，召开工作汇报会，给老板和懂事汇报工作，召开项目组会议给你的兵以最恰当的感谢和肯定，没有他们你是不能完成任务的，这样也能为今后项目的再次合作打下良好的基础，然后你的兵有些可能升了职或调到另外的一个项目组了。

 

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752019/viewspace-958805/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10752019/viewspace-958805/