zoukankan      html  css  js  c++  java
  • 大道至简第三章读后感

       “言三为众,虽难尽继,取其功尤高者一人继之,於名为众矣。”只是汉书中得一句话,团队中便是如此。

    软件开发,特别是大的工程,很少会由一个人去完成的,基本上都是开发团队。一个人的开发可以成功取决于个人努力,然而三个人的时候呢,就得选出一个领导者了,一般来说,功劳大的,能力强的,便成了整个团队的领导角色。

    团队缺乏的不只是管理,而做管理最起码需要能承担责任,这是最基本的素质。不能承担责任的领导者,他所带领的团队也无法存在。再者说了,做项目承担责任并不等于死亡游戏,如果项目做不成就要掉脑袋,那就好比枕着铡刀做程序;如果项目失败就要递交辞呈,那可能就从来就不会有项目经理。项目的经理是需要时间来成熟的,他们需要有机会来接受任务,承受错误,而不是一开始就享受成功。

         另外,体制的内涵是分两部分的,其一是“体”,即体系;其二是“制”即制度。我们不能将两者分开制定,因为有了确定的团队模式,才能寻求相应的管理制度,并且才能把这样的制度是实在团队之上。一旦两者不能结合,或者不能适应,其中之一便成了摆设,如果没有确定的组织机构,皮之不存,毛将焉附,又如何指望做出来的管理制度“合用”呢?因此,组织模式确定的同时,相应的制度也应随之建立。而制度到底决定了什么呢?员工如果在工作中能出想这样那样的纰漏:没有制度,你就没有办法和依据惩戒员工,因此是管理者的过失;有个制度而没有惩戒他,是执行者和监督着的过失;一而再,再而三的犯错,又一而再,再而三的被惩戒,那就是教而不改,就真正是员工的品行和素质的问题了。因此,先做制度总是好的。至少你在伏剑自刎之前还能将错误归咎到员工的身上。

        并且,一般情况下,动摇制度的不是犯了错误的员工,而是管理者自己。但是,制度也要人性化与公正化。常言道:不知者不为过。对于员工不知道的情况,那就是管理员的失误,不能将错归咎到员工的身上,而是应该自省。再者,在员工之前,相同的或者相关的错误没有被冤纵。这一条是公平化的体现,不管是针对谁,制度都是一样的,没有情面可讲,通常说“特殊情况,特殊处理”在制度面前都是行不通的。规矩一旦被破坏就形同虚设,反而被员工当作笑话当作茶余饭后的谈资,用来类比其他的制度。如此一来,整个制度就离崩溃不远了,反过来,在已经被破坏了的制度面前在做杀鸡儆猴的戏码就会激起大家的不平的声音,因此,最好的办法不是修理人,而是赶紧续订制度。

         而当我们真的开始着手开发时,我们最应该考虑的是:我在组织中扮演什么角色呢?我的职责是什么呢?我又能为这个团队做点什么呢?我想,只有真正掌握了,明白了自己的角色分配,才能将自己的角色演绎好。

  • 相关阅读:
    Java中常见的几种加密算法
    关于redis中过期的key的处理
    Redis 的内存淘汰策略
    AES加密算法原理(加密过程)
    springboot中从配置文件中读取相关参数值
    springboot中切换配置(多个配置文件--生产、开发、测试)
    mysql跨库查询数据
    SpringBoot2.0 的默认连接池----Hikari
    Druid连接池中的缓存机制
    Opus编解码练习
  • 原文地址:https://www.cnblogs.com/huangliping/p/4884331.html
Copyright © 2011-2022 走看看