项目管理杂谈

项目管理杂谈

项目管理有个前提，资源稀缺，如人力、时间、资金等。比如，有一个政_府官员，有一笔拨款，于是上了一个政绩项 目，这类项目一般不缺资源，所以也不需要进度管理，做啥时候就啥时候，更不用项目管理软件。如果进度拉长可以增加预算，于是得到更多灰色收入，那么效率可 能是一种负担。我不是危言耸听，你看中国有多少.gov的僵尸网站？

　　项目管理 vs 人的管理

　　其实，标题的意思是，项目管理过程中，关注于项目，还是关注于人。是人适应项目，还是项目适应人。

　　偏向于人的管理，即人本管理，我认为，对于像软件这种思考型行业更有效。因为思考型行业的管理，本质是人脑的管理，人心的管理。人脑的管 理，就是将人的智商充分发掘出来，高效率地工作；人心的管理，就是让员工自动自发、培养其责任感和热情。管理是因为不协调才需要约束，如果大家自动自发、 有责任感，还需要把管理挂在嘴边吗？

　　最好的管理，是员工感觉不到被管理

　　任何外在的手段，无非是让其产生压力、恐惧，如被淘汰、降薪、加班，通过这种力来推动项目。但人的效率，只有在充分自由的环境下才能够发 挥。引力（激励）比推力更有效。《人件》比任何项目管理工具书，更能从根本上解决问题。

　　项目的风险，往往来源于人的风险，如沟通不畅，上下不齐心。

　　信任本身就是一种约束，监督会加强团队的隔阂。

　　激励比控制更容易规范员工行为。

　　如果说在项目管理和人的管理间找到一种关系，那就是：设定目标，然后站在执行者的角度考虑问题。

　　项目管理的前提，是人的管理。人的问题解决后，再来谈管理项目。

　　项目管理，本质上是关注如何在有限的资源下，达到设定的目标。所以，它涉及到成本管理、进度管理和人力管理等资源方面，范围管理和质量管理 等目标方面，以及达成目标所需要的沟通管理和采购管理。

　　成本管理 打个比方，计算器可以为我们DIY电脑时省钱吗？

　　人力管理和沟通管理：关键是处理人的关系，关注当事人的利益

　　范围管理：也许写在纸上大家也就明白了

　　质量管理：决定于流程和执行力度

　　采购管理：就看PM的商务沟通水平了

　　也许，项目管理软件，最后会简化到一个进度管理和任务分配工具，而进度管理，往往Excel甘特图更实用。

　　当然，我说的是中小型项目，大型、规范的项目和团队，可能就很依赖于项目管理软件来做进度。

　　完成项目，需要一种方法，这种方法可能就依赖工具，也许工具本身就提供一种方法。工具有一定的使用环境，就如同我以前一篇文章中， 谈到的一段经历：

　　Bug管理

　　Bug管理，这两年，我们经历了三个阶段。

　　先说说使用环境吧，因为这是 决定一管理软件是否适合的最核心条件之一。

　　人员：有开发人员和不懂软件的业务人员 问题主要是业务员提出

　　距离：原来一年大家在一个办公室，后来IT部和业务部分，距离约1km

　　项目：旅游电子商务网站，包括前台和后台。这类网站重业务和用户体验，技术上没难度

　　最开始，使用的是Bug管理系统JIRA 用了约一年，基本上是推，业务人员不适应，最后我觉得反馈一个问题很烦琐，自己主动废弃了。

　后来，使用Excel，当然这是为bug管理定制的Excel，执行一个月就觉得不行，因为问题汇总、截图等不方便，简单问题这样汇报似乎也太累。

　　最后，使用Foxmail邮件用得非常顺，特别是业务部和我们分开情况下。因为邮件有三个特性很受用：抄送人，延迟执行，贴图。

　　有些很小并且及时的问题，直接通过QQ完成。

　　反正，在我们这个小团队，最后一种方式，直到现在都觉得很适合我们。

　　其实，在Bug管理的背后，有一个非技术支撑：信任。我们的重点不在责任界定、责任追究等和权限有关的事情上，我们只关注目标：问题被及时 发现、及时解决，以及解决过程中的低成本协作。

　　开始应用一款项目管理软件，都存在不习惯、甚至抵触的问题。最难的是改变人的思 维习惯，其次才是行为习惯。前者需要有效的培训和辅导，培训的效果，取决于团队成员多大程度的认同而不是会用，后者可 能需要痛苦的练习。

　　项目管理 vs 过程管理

　　能够将这两个概念清晰区分的人，一般都有真正的项目管理经验。前面说过，项目管理，本质上是关注如何在有限的资源下，达到设定的目标。项目管理，本身和具体开发的实物无关，比如甘特图几乎可以描述任何项目。这就是为什么有些项目还会有产品经理。过程管理，本质上是实现具体实物所需的步骤或流程，而它和具体实物、以及项目团队关系很大。

　　我将两者拿出来比较，主要是因为，我觉得项目的成功与否，与采用的过程关系很大，而这在项目管理软件中很难体现。比如开发企业信息系统，要 建立数据库：

　　如果是大项目，可能有专门的DBA负责建库，不需要和谁一个个字段确认。

　　如果是中小项目，可能是PM或PL负责建库，也不需要其他人确认。最混乱的情况是，各模块开发人员自己建表。

　　如果是偏产品，小团队，比如我建立过一个流程，对我们很实用：

　　引用

　　1、项目经理先和某开发人员沟通需求及业务字段

　　2、开发人员在一个规范的Excel表格中建表

　　3、告知经理，review一下字段命名及类型等，微调

　　4、开发人员在开发数据库中建表

　　5、建完后告知经理，再次review

　　这样，把本来建库的繁琐工作授权给开发人员，解放了经理，也提升了他，还保证了质量。过程其实非常敏捷。

　　权力并不会带来真正高效的的管理

　　可能有人说，我也带过项目呀？如果你带的一批人，一开始都和你关系不错，直到项目结束，你可能并没有接触到真正棘手的管理。当你的项目组，都是一批 有个性、工作性质不同的人，你这时候才会深刻体会到，沟通、协作有多大的挑战，如果再加上一个项目期限，我姑且抛开项目本身的业务复杂性。比如，技术牛 人，往往很有个性，喜欢自己来一套，不遵守团队规范，并且不太喜欢主动反馈，因为自我感觉都OK。如果强推规范和流程，往往会埋没一位人才。

　　还有一种情况，就是大公司的“资深”项目经理，这类人往往受公司高层支撑，比较强势。如果遇到项目组某成员不服管，往往是，要么打入冷宫， 要么驱逐出队，而不是站在员工角度，和他沟通。这种行为可以理解，因为找刺头沟通很烦，再说替换他毫不费力。这样的资深的项目经理，往往并没有多少管理经 验（管理=管人+管事），因为权力并不是领导力，权力并不会带来真正高效的的管理：员工主动性、责任心。再说，他并没 有利用好资源。如果该队员是他带入的，这样做，是一种对己对人都不负责的行为。对于项目经理的他，选择即责任。