做项目管理不等于伯乐

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

第四节谁动摇了你的制度
组织模式确定的同时，相应的制度也随之建立。很少有组织几年之后才来补制度的。
    然而制度究竟决定了什么呢?我们先来看看，如果员工在工作中出了纰漏，那么：
    》    没有制度，你没有办法和依据来惩戒员工，因此是管理者的过失；
    》    有了制度而没有惩戒他，是执行者和监督者的过失；
    》    一而再、再而三地犯错，又一而再、再而三地被惩戒，那就是教而不改，就真正是员工的品性和素质的问题了。
    因此，先做制度总是好的。至少在你选择做伏剑自刎的李离之前，你还有机会把黑锅扔到出问题的员工的头上。
    对于一个已经规范管理、体制健全的公司，不容许员工犯错是对的。即使是一次犯错，立即开除也说得过去。但还得是有前提的，这至少包括：
    》    员工已经接受过相关的培训，至少是员工规范和技术技能的学习；
    》    在该员工之前，相同的或者相关的错误没有被枉纵。
    第一条是人性化的体现。中国人常说不知者不为过：员工不知道，管理者也没有给他知道的条件，那怎么能说是他的过错呢?如果是因为不知道而出了问题，那管理者首先应该自省才是。
    第二条则是公平性的体现。不管是针对谁，制度都是一样的，没有情面可讲的，常说的“特殊情况特殊处理”在制度面前行不通。规矩一旦被破坏就形同虚设，反而被员工作为笑柄，用来类比其他的制度。如此一来，整个的制度也就离崩溃不远了。反过来，在已经被破坏了制度面前，若再做杀鸡儆猴状，那猴子是被吓着了，不平声、怨愤声也就跟着出来了。
    因此较好的方法是赶紧修订制度，而不是修理人。
    所以，在更加普遍的情况中，动摇了制度的人往往不是犯错的员工，而是管理者自己。如果在制度面前，既做得到“人性化”，又做得到“公平性”，那么当管理者的便可以多做几次黑脸的包龙图，而脖子上的脑袋便可以比李离顶得长久一些。
第五节 ”那我们就开始开发吧”
    现在，公司的组织机构和制度建设已经完成了，在这个组织机构里，我们已经有了一个或者多个团队。接下来，我们要真正的开始团队建设了。
    这是任务。因为正在读这本书的你，和我一样，是要拉齐七八杆枪，开始·做电子商务工程的了。而在这一切开始之前、再之前的时间里，我还想知道一件事：你知道如何做工程吗?
    我们先来回顾一下。
    前一章说的是编程。嗯，那实在是简单的、愚公式的工作流罢了。我们先不管愚公们的水平如何，以及够不够勤快，反正，他们会编程就是了。
    上一章呢，说的是一部分懒人“创造”或“寻找”到一些编程的方法。这些懒人们可能来源于做得太老的、或者太累的愚公，或者是……一些看着愚公们着急，又被闲出了毛病的人。反正他们找了一些方法出来，而我们的愚公们也已经学会了这些方法。
    现在，有了会(比较快速地)编程的愚公，而且有了公司，我们完成了组织机构建设，我们还找到了一名(或好多名)项目经理，他们一不怕死，二不怕苦……对了，更为可喜的是我们还有了开发部：对内，我们订了一套规章制度；对外，我们还拿到了项目单子。
    “那我们就开始开发吧”——你就这样跟我说。
    很久以前，很久很久以前，人们都是这样做的。拿到项目单子，然后“那我们就开始开发吧”。这样的事出现得很自然，因为积极的愚公们总是有挖山不止的欲望。所以他们一看到项目单子，第一个反应就是：那我们就开始开发吧。
    做了这么多年项目，我现在一听到这句话，就哆嗦。
第六节组织的学问：角色
    现在先考察一下你的公司，在整个供应链管理系统里面，有没有这样的人：他既不归任何人管理，也不管理任何人。如果有，那么就早早地把他开掉好了。
    这样的人在组织机构中是一个盲点，或者空洞。按照我的观点来看，他在组织中不担任任何的角色，既然“不是角色”，那么当然要开掉。
    但是，在你做这件事之前，确切地说是在任何错误被归咎于员工之前，管理者应该先想想是不是自己的问题。
    是的。你可能很快就发现问题出在了管理者那里。因为管理者没有确定组织机构模式，或者没有为组织中的成员进行角色定位和分工。如果这样，出现 “既不能令，又不受命”的人就是必然的事了。
    同样的道理，在工程开始“做”之前就得先把“角色”确定好——可能部分角色是与既已存在的组织机构相关的，例如“部门经理”和“开发人员”；而有些就需要临时授命。
    对于一个项目来说，第一个授命的人的当然是“项目经理”。但接下来的事件就要复杂得多了。按照微软的惯例，授命项目经理的同时，会有“产品经理”、 “开发经理”、 “市场经理”及“文档化和培训负责人”。这当然不表明至少需要5个人才能构成团队，在大量角色从项目团队中抽取与剥离后，我们可以得到一个精减过的团队模型(在后面我会把它叫“R模型”)：
在保障这样一个组织机构模式的过程中，以下几点内容是需要注意的。
》    如果项目针对直接客户，而且没有产品化的可能性(或必要性)，那么可以将与市场(以及市场部门)相关的问题和角色先暂时放在一边。
》    已经存在于开发团队中的成员，不适合在品质部门中兼任角色。
》    (在这个模型里，)项目经理应致力于减少团队中开发角色与其他部门的沟通，必要时开发经理应该站在开发人员之前进行部门间的交互。
》    品质部门、文档和培训部门和客服部门应该主要由专职人员构成，尽管开发人员可以(或者经常会)参与文档、培训和客服工作，但这也通常是他们较不能胜任的角色。

这是中小型规模的公司和团队的参考组织机构模型，对大型团队并不适用。

在这个模型中，我们仍然看到了一个至少由三个人构成团队。其中，在开发经理和开发人员之间，既存在主从关系，也存在协同关系。而项目经理，则在团队中处于领导者、组织者和团队保障者的地位。

如果非得要精简到两个角色的团队模式，那么这种情况下，通常是开发经兼任项目经理。因此这位开发经理一定要能清楚地区分这种双重角色的身份：在任何时候，明确自己是在进行“团队内协作”，还是“团队管理(和组织)”，还是在与“团队外交流”。

如果这个开发经理总是混淆自己的角色，那么，我建议，换人吧。
第七节跟随蚂蚁，但不要栽进蚂蚁洞里
    团队真的需要管理吗?
    这经常是“经营”开发团队的管理者较容易给错答案的问题。这些管理者兢兢业业，试图细化每一个管理环节，将自己的意愿贯彻到……嗯，CPU里去。
    实际上，开发团队并不需要管理。或者说，在你还没有弄清楚状况之前，不要去管它。
    温伯格(GeraldM．Weinberg)在“给软件开发经理的建议”中提到了这样一个问题：开发经理如何面对一个并非由他亲自雇佣的成员组成的团队。温伯格的回答是：
    》    与成员面谈，让他们签约受雇于你；
    》或者，解聘他们；
    》再或者，放弃这个职位。
    温伯格的意思是“没办法管就不管”。温伯格当然可以有更多的选择，他总可以找到适合自己管的公司。然而目前，你可能是唯一的人选。或者你原本就期待这个角色很久了，当然不能像温伯格一样放弃。
     你得找办法来解决团队问题。
    “签约”这样的事，在大多数环境下是行不通的。要知道，既然他们与公司的签约保证不了他们工作的质量，同样与你的这份签约也保证不了。协议并不能建立管理者与被管理者的信任，而只是确保了这种关系。
但是你应该相信我，在你接手这个团队之前，上一任经理也确保了这种关系。然而团队失败了，否则不会换作是你。
    所以告诉团队成员“现在轮到我管理你们了”，根本就是一句废话。或者在你来之前，他们就已经知道你要来了。
    小的时候，我就喜欢观察蚂蚁。我喜欢看它们成群结队地搬着东西穿过小路，或者水沟。我尝试用木棍导引它们改变行动的路线，然而不久之后，它们就会翻过那根木棍，按照既定的路线行进。
&n

上一页：皮之不存毛将焉附

下一页：沟通时项目管理的手段之一