一个程序员的管理思考

   正式做管理工作也有2年时间了,自从今年团队大了以后才开始思考什么是管理.并真正去学习如何管理 今天就将这些思考写下来也算是一种沉淀.

什么是管理

   什么是管理,就是管和理.那什么是管?什么是理?

   我的理解:管是结果,理是过程.这两个是相辅相成的.

   在我的两年的管理过程中,是也从管到理的一个过程.一个从前(带领)到后(推动)的演进.

   刚开始带领团队时,团队规模较小,当时只有3个人,当时是以一个带领的方式去管理团队,以自己的执行力和专业去影响团队.在初期这个方式很有效,并且很幸运的是这种方式还赢得了团队成员们的信任.记得当时兄弟们说我是Leader不是Boss的时候感觉很欣慰.但是随着团队规模的增大这种模式出现了瓶颈.当时当团队有10+人时,发现带领这种模式已经无法带领到每个人了.而且这种模式会导致留给团队成员的空间会减少,这也为后面埋下了一些隐患.所以在后面经历了一个转变的过程,简单的说就是从Leader转成Boss的过程,当然这个过程还是很痛苦的.这个时候就可能不再是带领团队前进,而是推动团队前进.而带领的职责就会转接到比较优秀的团队成员身上了.而当现在有将近30人时,这种转变将变得越来越重要.这个记起某人的一句话:在与不在一个样,有我没我不一样,或许做到这样的境界还需要很多路要走.

   不过在这个过程当中,真正总结出来的就是要有同理心,而这个同理心不单单只是对团队成员有同理心,难的是让团队成员对你有同理心.

   对团队成员的同理心实际上蛮简单的,说简单点就是用真诚换取信任.这个在团队小的时候带来的效果是很明显的. 但是团队变大后只是单纯的做到这点可能已经不够了,这个时候可能需要让团队成员对你有同理心,能站在你的角度来思考问题,但是这个是很难的.还是那句话,有很长的路要走.

管理和技术

   管理有时候和技术也蛮相像的.架构技术的积累和沉淀很多时候表现在抽象能力上.在做架构的时候能将一类问题的单个解决抽象为一个框架,一个平台,一个产品来解决,从而为以后这类的问题提供解决方案.

   而管理上也需要有这样的抽象能力.很多时候在管理上也是碰到很多问题,比如开发效率低,沟通成本高,开发不关注产品质量等等,管理者很多时候都是只针对当前问题进行单个解决,比如开个会训一下,而这种见招拆招的方式会使管理者疲于奔命.如果这个时候也能想做技术方案一样对这些问题进行分析,并抽象和总结出一些术的东西那么后面在碰到这里问题,自然会引刃而解. 而这种抽象出来的术,我的理解很多时候是一些规范,流程,规定等一些可被复制和可被执行的东西,就像技术上的工具,框架之类.

   比如在遇到开发的同学对产品质量不关心的时候,单纯的训诫和批评很难在根本上去解决这个问题,而且成本也很高,后来我们制定了一个流程就是开发同学每天轮流去处理用户的反馈,让开发同学直面用户,从而知道自己的做的东西有多么不靠谱,给用户带来了多少的困惑.这个时候再来开发的时候对产品质量自然有了更清晰的认识.

   在这个基础上,如同技术一样,可以再做一次高级抽象,就像对技术设计而言,会有设计模式,针对架构而言会有很多设计思想和哲学,比如领域驱动设计等等,这些思想并没有具体的实现,但是他们指导了很多实现.

   同样的针对这个思路,管理在术上的抽象可能就是道了,我的理解这个时候就需要有一个团队的价值观的存在了.这个价值观的存在,很多时候就体现在指导术的制定上去.

   比如一个技术团队的价值观是简单,直接,信任,效率,那么它在产出术的时候也会以此为标准.最近在团队内做了一个规定就是一线的开发同学在16点之前不参加一些评审之类的会议,让他们尽量有大段的连续时间来保证开发效率,并且和上游协同同学达成了一致.这样的做法就是在这样的价值观的下的具体实现.

   在这个学习的过程当中,应该和技术的成长有一定的相似性.一开始程序员可能很快的接触到术的东西,比如设计模式,但是理解不深很容易死搬硬套,为了设计模式而设计模式的设计最终会导致设计过度.但随着经验的增加,又会深刻理解设计模式,最后真正指导设计.  在管理这方,还是需要很多经验需要是积累.

技术化管理

   技术团队的核心价值是什么? 我的觉的是产出效率!这里的效率并不是狭义的效率而是广义的效率.

   这种效率不单单只是体现在团队能很快的做出东西来,而是说能对本团队,大团队或者其他团队能产出效率,或者抽象的说是影响力.

   好吧,写累了休息一下~