读大道至简之我见1—

近日花了一些时间在读周爱民老师的<大道至简>，全书整体来说是本好书，不过有些部分却不是很认可，在这里来谈一下，对于整本书观点，我的一些看法。

1. 团队管理

在第一家公司，我也有幸领导了一个小组开发项目，虽然小组不大，只有四个人，但是个人认为麻雀虽小，五脏俱全。虽然有的人身兼数职，不过总体上的职责还算是明确。因此虽然时间不畅，但是对团队管理还是略微有些自己的看法。

做为一个管理者，无论是技术，还是非技术，有一点都很重要，就是一定要都担当，我们也可说一定要能够承担责任！这也是作为团队老大最重要的一点。有什么事情，不要埋怨下属，要有，“你做，出了事我给你担着！“这样的决心。当项目失败时，首先检讨自己，而不是批驳下属犯了什么什么错误。毕竟，你是团队经理，出了问题，你的责任是最大的，手下的事情是你安排做的，手下是你选的。我们可以告诉手下的开发者他错在哪里！但不要把失败的原因怪罪于他，记得，项目成功了，是我们大家的成功；项目失败了，我是最大的罪臣！

其实很常规的道理，可是随着年龄的增长，貌似却越来越害怕了这份责任的承担。

制度应紧随组织划分。一个成型的企业，一定是有一个组织结构的，这个结构对应到技术部来说，很可能是研发组，开发组，维护组，测试组等等，而每一个组织，都应该建立其合适的制度，这个制度要符合两个特点：人性化和公平性。举个例子，我们不讨论特别标准的情况，只说对于一般企业来说，测试不是和开发同时进行的，而往往是先开发，后测试，这就意味着测试要比开发的工作时间晚，同时也意味着下班时间要晚，那么这个时候，我们指定测试也要同开发组的成员都是朝九晚五就有些不合理了，无论是从他们的生活习惯，还是从公司的利用效率来讲，这都是不好的，这就是人性化。而公平化就是我们所说的，王子犯法与庶民同罪。“特殊情况特殊处理”，这在团队管理中是应该绝对杜绝的。什么是特殊情况？这个特殊情况由谁来界定？这就必然会导致阶级矛盾。

2. 建立合理的组织

世界上几乎没有人是万金油，就像一个数语外理化生政史地门门第一的人，几乎是不存在的，也就是说，每个人都有每个人的强项，也有着自己的弱项。

周爱民在书中提到：“做管理！=做伯乐”。我对这个观点深表怀疑，也许我理解的伯乐与他理解的伯乐不同，但是在我看来，作为一个管理者，需要具备“知人善用”的素质。三国时期，刘皇叔对诸葛亮评论马谡时说：此人不可重用。而诸葛亮却用之镇守要地街亭。这就是帅才与他人的区别。

在一些企业中，有着“轮岗”一说，虽然已经日益沦为一种形式。然而却是挖掘人才最笨的一种办法。让每个人都尝试各种职位，然后找到他最适合的位置（当然，此处所说的“轮岗”并非许多企业中，从开发到销售的轮岗）。然而，对于恨多企业来说，这样的代价是他们承受不起的，于是，就要求管理者必须知人善用，把每个人放在他最合适的位置，让他扮演其最恰当的角色。

在组织中，每个人都应该有自己的角色。在我提到我在第一家公司的小团队中，四个人，我会针对每个人的爱好，以及我对其技术水平的理解来给予其不同的职位。

我不善交际，因此我找了一个有着一定行业经验，但技术一般的人A去调研需求，总结需求，而外界与我们其他三个人是完全隔离的，我们可以保证我们的开发不会受外界的任何影响，因为一切的沟通都由A来完成，然后传递给我们三个人。其实这个人才是真正意义上的项目经理。因此我给项目经理的定位是：沟通+业务为主，技术为辅。

我和另外一个人B负责核心BLL和Common的编写，其中牵扯到业务逻辑，牵扯到一些比较复杂的技术点，我们会专心解决，我们每一个类的设计，每一个模块的设计，都会由我们两个人商讨，然后四个人共同讨论。而我，除了此工作外，还会负责一些Code Review 和一些技术点的选择，然后直接向技术总监汇报。我给自己的定位是“开发经理”。而B，我对其的定位是“核心程序员”。

对于OA行业来讲，会牵扯到大量的数据库操作，存储过程等的编写。在这里我则把所有的这些工作都抛给了程序员C，你可以不去考虑上层业务，但是一定要专心把 SQL写好，然后返回我们在业务逻辑层所需要的结果。我们不妨将C称之为简单的DBA。

在这个组织结构中，每个人都有着自己明确的分工，不会说，在一个团队中，一个项目经理领着三个程序员，而这三个程序员是没有具体的角色定位的，这样的组织就是一个失败的组织。一个团队中，当我出了问题，我知道我该去找谁能帮助我解决问题，团队中需要全才，但是如果人人都是全才，那么这个团队绝对不会成功。

在我看来，对于一个小型团队来说，无职位高低之分，只有角色之分。项目经理并不是大于程序员，而只是他在做程序员之外的事情。管理者的加入并不是为了管理，而是为了协调；并不是为了“管理”团队，而是为了让整个团队能够更好地运转，这才是团队角色的核心之所在。

周爱民在书中有这样一段话，我非常认同：

项目经理应该致力于减少团队成员中开发角色与其他部门的沟通。品质部门，文档和培训部门和客服部门应该主要由专职人员来构成，尽管开发人员也可以做到这些，但是这些往往是他们最不擅长，也是最不希望担任的角色。

3 . 牢记旁观者清

“放权”，是我们平时在管理学课中听到最多的一句话。

而我在这里的总结是“旁观者清”。这也是我看来，放权最大的价值之所在。

周爱民在书中，将开发人员比作是一群蚂蚁。管理者可以跟着蚂蚁去任何地方，但是有一个地方是绝对不能去的，这个地方就是蚂蚁洞。如果你在洞外，你可以发现问题，如果你在洞内，你就只能做一只循规蹈矩的蚂蚁。

在这里，我不赞同周爱民完全跳出的观点。在我看来，作为一个优秀的团队管理者：

一方面，你需要站在团队的角度看问题，我是团队的负责人，我代表的是团队的利益，而并非任何外界的利益。试想一个团队的开发部经理，整天都吵着宣扬着技术无用论，那么这个团队的技术会是什么样子。

另一方面，你要站在整体上看问题。时刻要记住，你是名管理者，而不是开发者。开发者可能会关心，我的这个方法如果优化0.01秒，但这绝不应该是你管理者该关注的问题，你把握的只应该是宏观方向，项目经理只应该控制需求和把握项目进度，开发经理应该把握技术的大方向和着眼于项目整体的宏观设计。

在这里，我总结一下就是适当的放权，才能让你的眼界更宽广。

原文

读大道至简之我见1——团队管理相关推荐

读大道至简——编程的精义感想
时光过得真是快,转眼我就步入了大二.我对于我所学的专业,虽不敢说得上是热爱,但至少我已经喜欢上它了.想当初被这所大学录取的时候,我不是那么的欢喜,主要就是因为我没有想到我会被计算机系录取.上大学接触的 ...
读大道至简第五章有感
该章开篇第一个部分写的是做过程不是做工程,主要介绍了软件工程的创立及成熟的标志.其成熟的标志是软件工程的瀑布模型的提出.瀑布模型将软件开发的过程分成需求,分析,设计,开发和测试等五个主要阶段.在瀑布模 ...
读大道至简第二章感悟
愚公很勤快,他每天都很努力的"叩石垦壤",不停的"箕畚运于渤海尾".年复一年,日复一日,无止无休.只是为"毕力平险,指通豫南,达于阴".但是 ...
大道至简（第六章）读后感
大道至简(第六章)读后感还是不乐意去读,但总算可以耐心的读下去了,这也许也算是读大道至简以来的收获之一吧.第六章的题目是从编程到工程,看到工程二字,让我不由想起了前几天和高中同学聊天.他报的燕大土木 ...
大道至简之九：周期的实质与投资机会
大道至简之九: 周期的实质与投资机会时寒冰 (一) 由于新书迟迟不能出来,重启这个系列. 我从内心里感谢一直默默支持我的朋友,最希望大家能够赚钱,以弥补通胀损失,让自己的生 ...
读《大道至简——失败的过程也是过程》有感
再次怀着热情读了大道至简的第五章--失败的过程也是过程.作者首先告诉我们: 做过程不是做工程 .为什么这么说?作者讲到,按照模型,做完过程的每一个阶段, 并不等于做工程.或者说,工程并不是这样就可以做 ...
读《大道至简—是懒人造就了方法》有感
读了大道至简第一章编程的精义之后,我觉得感触颇深,于是乎我又读了第二章是懒人造就了方法 ,之后果然没有让我失望,第二章写的也是非常的好,非常的吸引我. 第二章的开头便引用了李冰凿山的故事,在战国时代, ...
大道至简读后有感
大道至简读后有感今天的读后感是在读完第二章之后写的,这一章的标题乍一看很有意思,题为是懒人造就了方法,其实细细一品,很是有道理.这章也分为四节,分别是"是懒人造就了方法", ...
咳咳，软工新手读《大道至简》读后感
<大道至简>读后感本书是周爱民先生把这本<大道至简>表达为"阐述软件工程的思想核心",书中又分为八个章节,接下来我想把我对每个章节的认识分开来介绍. 在第 ...
读《大道至简》第2章有感
大道至简第二章主要讲了"懒人创造了方法",在这一章节中作者就同一时代得愚公和李冰在挖山时的方法做了比较,结论显而易见,李冰的烧山之法完胜愚公.是的,愚公只会日复一日的"勤 ...

读大道至简之我见1——团队管理

读大道至简之我见1——团队管理相关推荐

最新文章

热门文章