zoukankan      html  css  js  c++  java
  • 部门管理制度、规范的建议

    最近收到一位同事给我提出的部门管理制度和规范的建议。我觉得其中很多建议提得非常系统、到位、具体。在这里,我将整封邮件内容贴出供大家参考。

     

    反思……


    随着部门人员的不断增多,我在部门外的杂事的不断增多,导致在管理工作上留出的时间不足,目前部门的管理工作确实出现了一些遗漏。

    同时,我非常高兴能收到同事对我真诚地提出建议。不论是技术、管理,还是任何一方面。

    虽然下文中提出的每一条建议并不一定都是合适当下情况的,但是我认为大多数还是很有用的。接下来,我已经制定并会采取了一些具体的措施,来逐步完善部门的管理!具体内容,由于涉及内部事务,在此就不写出了。

     

     

    下面是收到的邮件的内容:


    管理制度、规范整理

    1、 根据当前团队管理中出现的问题整理的意见和建议
    1)、团队是需要规范来约束的
    任何一个团队,都需要有相应的规范来约束其行为。既然是团队,就不是一个人的组合,一定是由两个或者两个以上的人组成了,[当然也有一个人的团队],为了完成特定目标而组合起来的一个组织架构。由于成员的成长经历、知识架构和相关阅历都会存在差异,必定导致由人组织起来的机构有行为的不一致性。如何规避这样的不一致性对团队不好的影响就需要规章制度,对组织架构里面的成员的行为进行规范,正所谓没有规矩不成方圆。规则可以包括【行为准则】,【合作准则】等。我们不能主观的认为,由于团队的成员都是有相当工作经验的人组成的,在他们之间就会很容易的形成统一的认识,亲密无间的合作,这是错误的想法。对于工作经验越丰富的人就越需要有相应的规范来约束,因为每个人的经验是不同的,就会导致想法和做法是不同的。就算是双胞胎都会有很大的区别,更何况从来没有合作过的人呢。
    2)、团队是需要领头人的。
    蛇无头不走,鸟无头不飞,在一个组织里面一定要有一个头领,他负责任务的分配,合作关系的协调,资源的协调,不要指望一个团队在没有Leader的情况下自动、自发的工作和学习,这是由人的差异性决定的。尤其是在技术团队创建的早期中会存在彼此不服的情况,类似这样的思想如何去解除,单独靠人的自觉性很难,靠每个人的经验也不可能。而且在团队会议上如果发生分歧怎么办,也必须要有相关的人员进行处理,所以说人与人之间关系的协调就是Leader要做的工作,当然也有其他的工作。大组织有大组织的Leader,小组织有小组织的Leader,这样做可以有利于任务的分解,并且在任务出现问题的时候可以找到相关的负责人。这样就可以从上而下的建立好一个责任追查的机制,不至于问题出现的时候找不到负责人,避免了大家对责任的推卸。
    3)、规范流程是需要培训的。
    培训是知识传承的重要环节,如果该环节缺失或者有问题,也会导致工作中会出现各种各样的问题。当初刚到公司,只是告诉我们有一些东西需要看,没有相关的培训,就导致该知道的事情不知道,应该准守的规章制度没有准守。规范的流程制度是需要培训的,让组织者和执行人、包含团队成员都能深刻的理解流程的含义,让流程更好的去执行。培训的过程是持续的,不断改革和优化的,最终产生适合本团队的规范的流程制度。培训的范围是团队里面的每个人,让大家都能更好的理解规范的要点,更好的去执行规范所要求的操作,为相应的产出做好基础的准备。
    4)、规范流程产生的原则是一个整体。
    任何一个规范的流程都是通过一定的原则提炼出来的,这些原则的关系是一个整体,是不可拆分的,我们不能拿出其中一个原则去规范团队,其他的原则就是可有可无的。我见过很多的团队会使用敏捷开发,在开发的过程中发现了一些问题,就是对敏捷没有一个完整的认识,有的只是知道其中几点,还有的是照猫画虎而来的。就会导致某些人的一些说法,我用了敏捷了,开发也没有发生什么变化。原则体系是一个整体的,意味着这些原则是不能独立存在的,各条原则互为彼此,相互依赖,从而产生规范流程。如果团队对这些原则没有一个很好的认识,就会导致错误的使用,有时候导致以偏概全。团队也就会出现这样或者那样的问题,而且这些问题是没有很好办法解决的。
    5)、规范流程产生效果是需要一个过程的。
    有很多的团队出现过类似的情况,比如:当听说某一个规范流程很好,就直接拿过来,生硬的套在现有的团队上。没有一个持续的培训过程,没有一个持续理解的过程,最后导致团队管理混乱,而且找不到原因,这是管理者的责任。而且有的管理者认为,我把规范的流程拿过来,使用了,就会产生相应的效果,但是大多数团队会越来越乱。因为规范流程产生效果是需要一个过程的,包括团队里面每个人的理解,然后才是执行。如果有新队员的加入,又会设计到培训和理解,这个不是一蹴而就的,需要各个环节的配合,缺一不可。同时规范流程产生效果的基础是对流程有一个正确的认识。
    6)、规范流程执行效果归于短板理论
    这个短板理论会根据团队成员职责的不同,影响的程度也会不一样。一将无能累死千军,说的就是如果一个团队的Leader如果对规范流程的理解不到位的影响,最后就会导致规范流程成了一个摆设,没有起到应起的作用。相对而言,队员的对规范理解的短板影响相应就很小了。如果要想让规范的流程起作用,必须保证团队的每一个人都能很好的理解规范,Leader更是如此,否则都是枉谈。
    7)、有了规范,就要看团队成员的执行力的问题。
    为什么很多团队有相对比较完善的规章制度,但是团队管理起来依旧是混乱的,那就是因为团队成员的执行力有了问题,有规范,却执行不了,或者执行不下去,当然也可能有其他原因,如果说去掉其他原因,单纯从团队来讲就会涉及到团队整体的执行力的执行的问题。如果团队的Leader是一个可左可右的人,就会导致团队里面的成员对规范和准则的不确定性,也就导致了执行力出现问题。而且团队执行力是一个贯穿团队管理始终的一个要素。上下要一致,意见要统一,确保执行力的可执行性。如果在执行力方面有问题,再好的制度都会形成摆设。在执行力方面不能出现忽左忽右的想法,而且执行要执行的彻底,不能使用特例推翻规范执行。
    8)、团队Leader的职责。
    电影是导演的艺术,团队就是Leader管理艺术的体现,领导者在团队管理中担任着重要的角色。他负责团队的组建、资源的调配、合作关系的协调、任务的分配、进度的把握和过程的控制的管理。Leader的作用就好像群狼的头狼的作用,没有Leader的团队是没有战斗力的。当前团队Leader的职责是由缺失的,该肩负的责任没有负责到,导致规章制度就成了摆设。团队是合作的艺术,但是如果单单靠每个人的自觉性是不够的,必须由相应的管理者处理在合作过程中出现的摩擦,统一团队意思形态。当团队成员意见发生分歧的时候,Leader要冷静的处理,如果处理不好,只会加剧事件向相反的方向发生。Leader是以为冷静者,任何时候都要比成员要冷静,冷静的思考才能更好的处理团队发生的问题。
    9)、应该建立经常性的巡查制度,保证制度和管理的执行。
    当我们建立了完善的制度,并不代表事情就结束了。我们如何去查看制度的适应性,如何查看管理效果,就需要我们应该建立巡查制度,积极的去了解制度的适应性,管理的适应性,根据结果产生相应输出,这个输出就是对制度的持续的改进,对管理的持续改进。如果认为有了好的制度,好的管理,就一定能产生好的结果,未必。有好的结果必须有好的反馈制度,根据不同的条件适时的去修改规范和管理方法。在管理中一劳永逸的做法是不存在的。
    10)、太多的口头话的东西,历史数据不可查。
    当前团队有一个很大的问题,习惯性的口头决定,没有形成可以查询的历史数据。这样也会导致团队任务管理的混乱。比如:今天做了一个决定,过了几天做具体事情的时候不知道如何做事情了,当时讨论的规则和最初的想法都无从找到,只能重新讨论、重新调研,然后做出了项目决定。有时候也会产生歧义,并且大家都对当时的情况不记得了,导致会议冗长,重复讨论问题。每次会议,或者决定都要产生可以追溯的数据,可以是文档,日志或者其他形式的数据,这个是没有二义性的,也为准则提供了很好的基础。
    11)、会议的方式、决定的方式和讨论的方式的问题。
    当前团队开会的方式是,如果有问题,就会把相关的所有人员都召集上,大家共同讨论决定结果。乍一看,好像不错,挺民主的。这样的效果就会导致会议的无限加长,最终也很难形成一个统一的方法。因为每个人的阅历、技术和相关资质是不一样的,就会导致在讨论问题的过程中,要不把问题扩大化,或者偏离主题。同时没有人对会议的目标和范围进行把控,经常导致延长会议,效率低下。而且讨论的方式,有很多人习惯性的用一些特殊案例去推翻一些普遍的规则,就导致在这样的问题上讨论不下来,而且越多的人参与讨论,问题的复杂性就更甚,同时没有人及时叫停。会议不需要相关的所有人,只需要相关的主要人员参与就可以。特例的提出需要深思熟虑,不要想当然,同时也要考虑特例提出的原则性把握。而且在这个过程中一定要有人对会议范围和进度进行把控,来提高会议的效率。
    12)、有输入必须有产出,做事要有始有终
    当一件事我们做了很长时间后,并且也自认为很了解当前的工作方式后,就会形成一种习惯,而且是不好的习惯。当我们做事情的时候,如何查看进度,就是要看您的产出量。这个产出一定可以查询的、可以度量的、可以定量的。当日事当日毕,不会让项目延期而给自己留借口。有输入就要有产出,而且这些产出是可以落地的,长期操作就会形成良好的习惯。就像当前的团队一些问题,就那开会而言,开会看了很久,有输入,产出呢,很少,或者是无效。或者拿【反思会议】来讲,目的很好,也有输入,输入就是写文章,写自己的感受,但是产出呢,也有,当然有了,而且每个人都总结了很多改变意见,但是这不是产出。我认为的,有了这些东西,相关部门有没有做相应的改变,有没有相应的产出,这才是真正的产出。
    13)、管理中不要存在形式主义。
    反思会议是一种很好的反省和自反省的会议,可以改进流程,提高我们的效率,但是眼下看来是变了味道。一套完善的管理思想,一定会伴随着相应的管理软件、过程方法的产生。管理中每一步的设计都是有其道理的,如果成了形式主义的产物,就会对人产生惰性思维,对团队的积极的特性是有影响的。因为大家都感觉这个东西可有可无,或者说可做可不做,所以就选择不做,如果非要做,好坏又是一样的,那我就糊弄一下就得,慢慢的会是一个积极向上的团队开始变得涣散。既然制定了制度,就去踏踏实实的去执行它,每个步骤都要有相应的产出,这个过程是不被打断的,通过持续的改进形成规范。
    14)、在团队管理中需要赏罚分明。
    在一个纪律严明的团队面,每个人都是很认证的工作,很信服的工作,而且大家会避免错误发生。但是在我们当前的团队里面不是这样的,做错了也不罚,做的好也不赏,这就好像回到了大锅饭的时候,好与坏一个样,做与不做一个样,这样的团队的战斗力不可能强了。在好的团队里面,一定是赏罚分明,职责明确的。这种思想要扎根于团队,你的错误耽误了团队,或者耽误了项目,你要收到相应的惩罚,让每个人知道自己做错了事情的后果,这样下来就会迎来一个另一个结果。

    2、 管理者能力和执行力的问题
    1)、团队的管理者一定是一个比较冷静的人,最起码比其他成员要冷静,不容易激动。如果团队管理者自己都很容易冲动,那就更谈不到管理团队成员了。这样的团队也会很容易形成一个混乱的局面,很容易因为一个问题争论不止。
    2)、团队管理者在个人意识或者判断上不能是一个左右摇摆的人,老大都摇摆了,下面的人怎么看啊。尤其是在表达个人观点的时候,不能说这个好像不错,那个也好像不错,这样是不应该的。给别人的感觉没有主见,不可靠,让团队成员没有安全感。
    3)、会议需要民主,但是过度民主就没有了民主。团队管理者可以在一些问题上争取大家的意见,听听大家的看法,然后综合判断出结果。这样做没问题,但是切记所有问题都询问,并且在判断这个过程中又是左摇右摆的,是最可怕的。争取大家的意见,当大家都正常的表达完自己的观点的时候,就可以做决断,避免重复讨论问题导致会议无休止。如果这个过程发生争执,要果断的制止,防止事件的扩大化。
    4)、团队的管理者不需要事事都要得到团队里面的认可才可以执行。因为人的生长环境、知识结构、阅历的不同,会对同一问题得出不同的结果。
    5)、在团队里有等级是便于管理的,减少了一些不必要的问题,比如:对对方的认同感。这个是在团队管理中表现最突出的。在一个没有管理者的团队里面只能是工作效率差,问题多。在团队管理中不宜讲“你们的技术都是最好的”或者“你们差不多”,人为的平等化就会导致大家彼此的不服气,有时候也会存在明争暗斗的情况,这样做反而打破了形成规范的团队气氛。
    6)、团队管理者一定是一个有着强有力的执行能力的人。当前团队的问题,很大一部分就是由于执行力不够造成的。有开发规范,但是没执行,也没有人检查,也没有任何人会因此受到惩罚。执行力的贯彻是靠管理者的逐层下达实现的,而且是不能更改的,是坚决的。任何托词都不能成为没有执行的接口,这是一般准则,如遇特殊情况,可以具体情况具体分析。
    7)、团队管理者要有自己的迭代周期,这个迭代周期用于检查下属成员的工作情况。这个周期可以是一周一次,但是间隔不要太大,否则积累的问题会越多,管理成本也会提高。
    8)、会议的把控,讨论对象的把控和讨论范围的把控。当前团队开会的时间总是很难定,而且总是感觉时间不够用,这就是团队管理者没有对会议进行很好和有效的把握。
    9)、团队里面不要存在【XXX,XXX和XXX】这样的平等的组织,他们之间也要有相关等级去约束,一定要按着能力排序,这样会减少不必要的麻烦。做技术的有一个通病就是:感觉自己的想法是正确的,感觉自己的设计是最好的。在平等环境里面就会出现一些不和谐的声音。
    10)、有了等级有些工作也就好安排了,比如:是否需要下级审核上级的设计,如果需要审核应该是相关能力差不多的人进行评审或者能力更好者评审。这样做可以减少沟通成本,增强沟通效率。比如:一个简单的单词就能了解对方的设计意图,但是如果不在一个层级的人就需要解释更多,有时候解释的再多,可能对方也不能很好的理解对方的设计理念。两个不同层级的人进行沟通也容易产生你说你的,我说我的,彼此都不能很好的理解对方的情况。

  • 相关阅读:
    阿里Java开发规约【摘录】
    JavaWeb【八、JSP指令与动作元素】
    JavaWeb【七、JSP状态管理】
    JavaWeb【六、JavaBean】
    JavaWeb【五、内置对象】
    JavaWeb【四、JSP基础语法】
    JavaWeb【三、Web程序编写】
    JavaWeb【二、Tomcat安装】
    Django 模板层
    Django auth模块
  • 原文地址:https://www.cnblogs.com/zgynhqf/p/6155524.html
Copyright © 2011-2022 走看看