(转)我的管理实践---《人件》读后感

原文地址:http://ivaneye.github.io/2016/02/15/peopleware.html

写在前面

听说《人件》是很久之前的事了,但一直没读。主要是受到了《人月神话》的影响---《人月神话》一直被奉为经典管理书籍,名声应该比《人件》高,至少我是这么认为的。所以先读了《人月神话》,当时还很好奇,《人月神话》和项目管理有毛线关系?读了才知道,“人月”就是我们说的“人天”!读了大概三分之一,不知道是翻译问题还是作者行文方式不适合我,反正读不下去了,感觉说了那么多废话只是说明了“增加人力无法加快项目进度”!所以《人件》也就无限期搁置了!

最近项目组购书,买了这本书,就拿来看看!看了才有一种相见恨晚的感觉。我做了两年多的管理,最近不想做了,又回到了技术。这本书并没有让我学到什么,但是它所提到的很多内容和我当时的管理方式很契合,或者说和我的想法很相近,同时也解释了我最后为什么不想做管理了!

人员管理

“流水的开发,铁打的项目”。相信对有几年经验的开发人员来说,这句话并没有说错。

很庆幸的是,在我管理的两年多里,没有人离职,虽然团队不大,只有七个人。

我把功劳归结为:

  • 项目组成员的自觉性
  • 和我的好脾气

而《人件》给了我更有说服力的说法:“管理者不是让大家去工作,而是创造环境,让大家可以顺利的开展工作”

首先,我承认我自己也是多少有点“高科技幻觉”的!至少,每次别人问我做什么工作时,我回答:“互联网”,或者很屌丝的“软件开发”。基本都会得到“高端”的回应!也就导致我的一丝丝飘飘然,至少在当时是的。

现在,我很认同《人件》里的说法:“从事基础研究并获得根本突破的科研人员做的才是高科技工作,其他人只是在使用研究成果”.在各个技术大会上,你听着某某架构师、某某CTO,说着这个技术如何如何先进,这个架构如何如何好。其实绝大部分都是使用的前人的研究成果,而这些研究成果有不少实际上在很多年前就研究出来了。

另一个现象就是,虽然软件行业在外人以及不少行内人看来是“高科技行业”。但是,在管理上,仍然使用的是传统行业的那一套:项目就像流水线一样,而开发人员则像流水线工人,开发人员是可替换的!从软件架构来看:开发人员就像一个个的模块,某个模块出问题了,换个相同的模块就行了!

而实际上,虽然软件行业不是“高科技”行业,但是与传统行业还是有一个很明显的差异的:软件行业是“思维密集型”行业,而大部分传统行业是“劳动密集型”行业。

说到这里,我脑子里出现的画面是卓别林的“摩登时代”---他在流水线上拧螺丝的情景。可以想象,替换一个拧螺丝的流水线工人的成本能有多大?而替换一个软件开发呢?

  • 首先需要找个人和他交接
  • 有新人进来了,还要再和新人交接
  • 新人还需要熟悉整个环境

所以,在软件行业,人是“个体”,不是“模块”!

可能得益于我的性格---“懒”!我这人不喜欢被人管,也确信,大部分成年人不喜欢被人管---大家都是成年人了,有自觉性!所以,我的管理完全建立在大家有自觉性的前提上!同时,给予了充分的自主性。所以我的管理很轻松:

  • 按个人能力及偏好划分计划
  • 每日反馈进度
  • 有问题,协助处理

很庆幸项目没有出现大误差:

  • 期间安全发布了两个大版本,n个小版本
  • 没有做过任何强制的加班规定,项目组人员自觉按计划执行!
  • 除了版本发布前夕,基本没有什么加班情况!
  • 项目组成员没有感到特别大的压力,能专心做自己的工作

我个人是不喜欢加班的,相信没人会喜欢加班!而且特别特别讨厌强制性加班---没事也得留在公司!所以我在管理时,没有做过任何强制性加班的决定。我认为强制性加班完全提高不了效率!《人件》中也有同样的观点!

首先,效率是什么?单位时间内的工作产生更高的价值。而强制性加班,实际上是在单位付酬的情况下掠取更多价值!

其次,长期的强制性加班,会导致人员的流失,增加了替换人员的成本。实际上就抵消了,加班所带来的所谓的效率的提升!

总的来说,在人员管理方面,我个人觉得做得还不错,有点“无为而治”的感觉!

环境

作为一个一线开发人员,应该有过这样的体会:思考一个问题,或者对某个问题进行编码!终于搞完了,抬头一看,“靠,三小时过去了”!或者正在兴头上,突然电话响了,或者下班了,直接就郁闷了~

反正我是深有体会!《人件》中给了个词"Flow",中文版翻译为“流”!这是一个渐入的过程,很像做梦!在《盗梦空间》里,小李子说了这么一句,原文不记得了,大意是:“你能回想起来你是什么时候开始做梦的吗”?这里,也同样可以问一句,“你能回想起来,你是什么时候进入Flow状态的吗”?

我有这样的体会,所以在管理项目时,也在给项目组成员提供这样的环境!但是作为一个小项目经理,我没办法改变公司的格局,只能尽自己能力所及,做一些事情!

  • 首先,需求接口人是我。也就是说,我先对需求把关---做还是不做,什么时候做
  • 现网问题全部提到我这里,我进行整理分发---通过jira
  • 进度压力由我扛着,不传达到组员

这使得组员在项目中能专注于自己的事情!另一方面,我自己就和“Flow”说拜拜了!这也是我最后不做管理的其中一个原因!

招人与留人

招人方面我体会不深,我本人主业是技术,项目管理只是副业~~~所以招聘时,我更关注的是技术:主要是基础以及发展潜力!

而在留人方面,我并没有做什么特别的事情!我赞同:“用人不疑,疑人不用!”《人件》里提到“领导力”这个词,并说到提高“领导力”,需要做的几件事:

  • 主动承担任务
  • 明显胜任工作
  • 为任务准备提前做足必要的功课
  • 让每个人创造最大的价值
  • 实施过程中保持幽默和明显的善意
  • 有感染力

对应到我自身来说,我做到的是:

  • 主动承担任务[Yes]
  • 明显胜任工作[Yes]
  • 为任务准备提前做足必要的功课[Yes]
  • 让每个人创造最大的价值[不确定]
  • 实施过程中保持幽默和明显的善意[有善意,有没有幽默就不知道了]
  • 有感染力[什么是感染力?]

算是有点“领导力”吧!

团队

团队方面,个人体会和《人件》所描述的没什么共鸣!

我是个海贼迷,索隆粉!我个人比较赞同索隆在阿拉巴斯坦对乔巴说的自己对团队的理解:“你尽全力做好你该做的,我尽全力做好我该做的!如果你没做好,就揍你!”当然,这里的揍不一定就是真的揍了,可以想象一下,在团队里,其他人都在尽力做自己该做的事情,你没有,你会是什么感觉?

《人件》中提到团队需要目标一致!我个人觉得好难,甚至不现实!前几天刚读了托尼.巴赞的《思维导图》!书里有个实验,就是找了几个人,四人一组,针对同一个词来进行联想,然后统计有多少词是四个人都想到的!实验结果是,即使是年龄相当,经历相当的四个人,联想到相同词的概率都非常的小!所以我觉得要让项目组成员目标一致很难!

比如,有人工作就是为了赚钱!你能说他肤浅吗?你工作不是为了钱?有人工作就是为了充实自己!你能说他自私吗?你不需要项目经验来太高自己?你要让所有人都要把目标变成完成高质量的项目!有可能吗?

但是目标不同又如何呢?

你工作是为了赚钱!ok,没问题。你就把公司当作赚钱工具。你工作是为了充实自己!也没问题,你把公司当作学校!但是前提是你需要完成你的职责!你需要完成你的职责,来换取你所想要的!

企业文化

企业文化这么虚的东西,我真没什么体会!但是有些病态的企业文化我能体会,同时也是我不会去做的:

  • 比如全公司的强制性加班
  • 无意义的会议!以及会议的跑题!
  • 过多人参与的会议,等等

另外,我不赞同所谓的“家”的企业文化---把公司当作家一样!在我看来,公司和家是对立的联系!

人是有责任心的动物!你为了家庭才出来工作,这是对家的责任感驱动!而对公司的责任感是建立在对家的责任感之上的!因为,对公司的责任感,能获得更多的回报,来照顾家庭!而过多的工作,又会导致对家庭的忽略!

结语

针对两年多的管理体会,以及《人件》的阅读,目前管理给我的体会就是: 管理,是一种服务!为了让成员快乐地、有效率地完成工作!

时间: 2024-10-17 08:49:39

(转)我的管理实践---《人件》读后感的相关文章

《人件》读后感

<人件>的着眼点并不在软件开发本身,而是在软件开发中的“人”.<人件>提到:软工本质上工作的主要问题,与其说是技术问题,不如说是社会学问题,软件的设计本身需要社会,需要“人”的肯定.全书没有涉及到任何软件技术,主要探讨了专业软件团队管理的问题,分析了如何维护一个合格的团队,一个合格的团队是做好软件的必要条件. 第一部分 管理人力资源.本部分介绍了一种完全不同的考虑.管理人的方法.一种特别适应人力资源的非模块化特点的方法.首先,作者提出了如下观点:从本质上来说,软件工程中的主要问题是

统筹高效利用时间——《小强升职记(升级版):时间管理故事书》读后感

      统筹高效利用时间 --<小强升职记(升级版):时间管理故事书>读后感 看完<小强升职记:时间管理故事书>,很有感触.书只是以小强为人物线索,通篇讲解如何管理.高效利用时间,和功利的升职等没有任何关系.全书着重讲如何利用时间,如"摔倒身上的猴子"等方法很受用.也想让媳妇和大家伙读一遍. 每天的忙碌,为什么有的人效率很高,有的人效率很低,同样的任务还要加班(这点我做的也不好).很大的原因往往是时间安排的不合理,分不清轻重缓急,没有目标,或者有目标容易

Atitit。 沉思录 与it软件开发管理中的总结 读后感

Atitit. 沉思录 与it软件开发管理中的总结 读后感 1. <沉思录>,古罗马唯一一位哲学家皇帝马可·奥勒留所著 2 2. 沉思录与it软件开发管理中的总结 2 2.1. 要有自己的培训..(不要总是依靠公共图书馆) 2 2.2. 要做大架构,优先大架构 2 2.3. 各司其职 世间万物各有所用,各司其职 2 2.4. 优秀的培训不一定能造就出强大的成员...但总比没有强 2 2.5. 顺势而为,随遇而安. 2 2.6. 看穿生死,淡泊名利. 2 2.7. 保持理智,洞察世事 2 2.8

业务技术协同线上化的硬盘式研发管理实践

摘要: 在云效平台策划推出的<持续集成与交付:阿里最佳实践>专题中,阿里云效产品专家代平为大家深入浅出地分享了互联网的研发管理理念,解析了企业研发管理面临的挑战和困难,揭密了如何结合云效产品进行业务技术协同线上化的硬盘式研发管理实践. 摘要:在云效平台策划推出的<持续集成与交付:阿里最佳实践>专题中,阿里云效产品专家代平为大家深入浅出地分享了互联网的研发管理理念,解析了企业研发管理面临的挑战和困难,揭密了如何结合云效产品进行业务技术协同线上化的硬盘式研发管理实践. 以下内容根据演讲

读{人件}有感

                                                                                                   读<人件>有感 本书共分为六个部分,分别为管理人力资源模块,办公环境模块,正确的人模块,高效团队养成模块,沃土模块与快乐的工作六个模块. 在第一部分中:具体描述了人的工作机制,人是非模块化的,将模块化适用于个人是起不到效果的,而在我们大多数的工作中,问题更多在于社会学的领域范畴,而非技术上的,我们的

投资人的能量往往大多远远不仅于此,他能站在不同的角度和高度看问题(要早点拿投资,要舍得让出股份)——最好不要让 Leader 一边做技术、一边做管理,人的能力是有限的,精力也是有限的

  摘要:在创业三年时间里作为联合创始人,虽然拿着大家均等的股份,我始终是没有什么话语权的,但是,这也给了我从旁观者的角度看清整个局面的机会.创业公司的成败绝大程度取决于技术大牛和公司 Leader,这两个人最好能在性格上形成互补,而遗憾的是我们公司是同一人. 关于决定是否创业 2012年4月,正好三年前整,在深圳能源正混的郁郁不得志的时候,大学的好兄弟找到我一起创业,他们有钱.有 idea,就是差人,当时的我还是技术菜鸟,本科学的也不是计算机,看着移动互联网蓬勃的发展羡慕不已.很快就答应了一起

人件——有所感悟

<人件>这本书刚开始听名字,感觉是一本很让人纳闷的书,人件?人贱? 原来人件的意思是,人与计算机发生交互的时候人的那个条件.这么说起来还是有点拗口,简单的说来,就是人与计算机活动的时候,人的那种活动. 这本书,简单总结起来介绍了如下的内容: 1 管理人力资源 2 办公环境 3 使用恰当的人 4 团队的生产力 5 开心的工作 6 续写 下面简单的针对有印象的部分,写下感想. 1 帕金森定律 帕金森定律讲述了如下的定律: 如果一个很平庸的人作了管理,那么摆在它面前的只有三条路: 1 退位给有能力的

《SQL Server企业级平台管理实践》读书笔记——SQL Server如何设置自动增长和自动收缩项

原文:<SQL Server企业级平台管理实践>读书笔记--SQL Server如何设置自动增长和自动收缩项 SQL Server允许用户设置数据库初始值和最大值,可以通过自动增长或者自动收缩进行配置.通过这些配置,我们可以防止数据库空间问题而导致的应用程序修改失败或者SQL Server磁盘空间耗尽的事情发生.一般来讲,如果数据库不是很忙,默认的设置为自动增长,这种方式能够满足大部分的需求.但是在大量并发的情况下,申请数据文件和日志文件增长本身是一件非常消耗系统资源和影响性能的工作.所以如果

人件札记:项目失败的原因

前言:新装修的办公室,满屋子的甲醛味,到了下午头就开始承受不住,但是不能阻止小编我的学习动力哈,人件札记的开山篇"此时此刻,一个项目正在走向失败",从此篇文章中,看看项目失败的原因到底是什么? 项目失败的原因 项目失败的原因,我们很容易归咎于技术,除了把原因归咎于技术,我们很难找出其他的借口. 但是项目失败的原因很多情况下在于管理人上. 在国内,多半的管理者出身于技术.一些人能够在技术细节上听的进去建议,并且付诸努力找到解决办法. 而一旦在面对管理的问题时,很多人压根不关注于细节,他们