浅谈技术型企业管理

过去15年的职业生涯，我服务过很多企业，从一线员工到资深工程师以及各种管理角色。于是也想谈谈我的管理经验与大家分享。 从08年开始从技术慢慢向管理过度，到10年基本完成转型，虽然后面更多是管理工作，但我从来没有离开过技术领域，特别是担任高级管理角色的过程中。 始终关注技术，追逐技术，我的博客专栏与系列电子书更新没有间断过。

领导与管理团队

对我影响比较深的一部电影《U571》

当船长告诉副船长泰莱这些话的时候“作为一个船长，你不能犹豫，你要采取行动，不果然行动，就危及全体船员，往往没有先例可遵循，资料不足，要当机立断”，“你出错，就要承担后果”，“假如你犹豫不决，不能当机立断，就不适合当潜艇队长”，泰莱开始反思。当大幅告诉船长泰莱，“指挥官有无限威严，是可敬可畏的人，他无所不知，无所不能”泰莱就已经担当起了船长的角色

大多数的软件开发者是被“管理”的，而不是被“领导”的，而技术人员更喜欢被领导，而不是被管理。

同样面对项目的一些问题，作为技术管理层你必须拿出方案，而不能将这些问题推给下属：你们看看怎么做，你们大家商量一下给我一个方案...等等

我平时对下属说：你们这么做，应该这样做..... ，而不是：你们看看怎么做，你们讨论一下看看有没有好的方案....（然后告诉我，我在跟上面说），管理层不是传话筒，上传下达的工作，秘书助理更适合。

领导力强，管理可以稍松散一点； 领导力弱，用管理与流程补充。领导力不可复制，只能被另一种替代，管理可以克隆。

我更擅长领导，而不是管理，我认为领导占80%，管理站20%较为合理。

领导能创造神话，管理可持续发展，企业可以从领导型走向管理型，但从管理型过度到领导型阻力重重。

项目管理

项目管理：项目管理从管理角度出发，通常根据软件工程方法实施，通常是告诉领导我们在做什么，但常常无法安照计划进行。 敏捷开发：从开发角度出发，告诉领导我们今天做完了什么！

我认为项目管理模式的软件开发团队，不理利于创新，会降低员工的积极性，员工没有参与感，将员工视为工时，一个部件，一个资源，任凭项目经理的调度，使用。员工的想法无法得到重视，仅仅是执行命令。 这种模式会浪费每个人20%的时间用来维护时间表。

我更喜欢敏捷开发团队，我更喜欢全栈开发人员，让开发人员参与的软件开发周期的每个环节中，人力资源利用率高，让开发工作成为有趣的事，从被动接收任务分配，到主动参与其中。

软件工程当下已经显得落后。尤其是快速变化的互联网行业。

团队合作

团队合作不是挂在嘴边上了，也不是管理层开开会贯彻团队合作精神，就会形成凝聚力，顿时团队有所改善。

事实上磨破嘴皮子也没人不会听你讲什么团队合作精神。对于大部分员工，站到99.9%都仅仅是打一份工，拿到该拿的￥,按时上下班。甚至很多管理层也是为了打一份工，拿一份高薪￥，按时上下班。

真正能不靠管理，工作认为真负责，有敬业心的员工，他们一部分会在某些领域做的跟出色，另一部份会选择创业等等。 你的企业能有这样的员工是运气。

团队合作精神是管理不出来，只能靠领导艺术凝聚一个团队。

出现问题为什么会相互推诿

一旦出现问题，很可能同事反目成仇，背后给你一枪，将责任推给其他人。有时可能是部门相互推卸责任。这种做法会像瘟疫一样传染，影响更多的人或部门效仿。

如果不加以控制，后果很严重，波及面广，一旦成为定势，你再想翻盘非常困难。不管你是否愿意或承认，这将会成为企业文化的一部分。

你想改变，很难！你会发现新入职的员工很快学会并适应这种推诿的企业文化，新鲜血液总是少量输入的，就像得了癌症一样不可控制。

出现这样事情问题出在哪里？

• 管理者不懂技术
• 组织架构不合理，部门与部门是平级关系，平级部门最容易推卸责任。
• 对自身定位，有些管理层认为是权利部门，我们更需要的是服务部门。
• 背黑锅文化

我来详细分析一下：

首先是“管理者不懂技术”，如果管理者不懂技术，什么都想管，又管不好，当出现问题后，这位裁判只能听各部门负责人报告，那个部门的口才好，嗓门高..... 那个部门就有优势，无法做好裁判工作。败下阵来的部门背黑锅，他们也不是孬的，骑驴看账本，走着瞧，挖坑埋地雷也要找回面子。

“组织架构不合理”。平级部门最爱干的就是制定各种流程，让其他部门按照我的流程走，这样每个部门都会如法炮制，流程很多做法是给上面看的。

“自身定位”，我认为每个人或部门都要有服务意识，我在外企工作多年，在外企HR，财务等等部门都是服务部门，确切的说是“主动服务部门”，他们会主动上门服务，例如财务会问问你有没有什么要报销的.....。而在国内大部分部门都是等你去主动找他们，他会会告诉你流程是什么，流程怎么走，这件事我不负责，你应该去找谁。服务意识是需要强行推行，中国人还没有达到服务意识层次。

“背黑锅文化”除了问题急于找人背黑锅，揪出肇事者，责任全是他的，这在中国是惯用手法。我的经验是千万别找人被黑锅，不要单指某人，出现问题谁都有责任。

一旦企业出现这个推诿行为的苗头，必须要控制，不可蔓延。避免出现多个平级部门，必须有人能领导这些部门，做好裁判工作，使他们不敢推卸责任。

例会问题

我通常很少开会。

“中国式开会”就是针对XXXXX问题你们看看怎么做，你们大家商量一下，然后你一言，我一嘴，各个提建议，到头什么都没有解决，一份会议记录发给所有人，几乎没有人看。提意见都很踊跃，具体到谁负责都开始低头。会议内容落实5%不到。

我开会就要有解决方案，成熟的方案，否则不开会，开了没有意义，浪费时间。哪怕是半成品也好过没有。

针对方案细节依次敲定，然后进入到Ticket对应具体负责人。

工作报告

我从不要求团队写工作报告，因为Ticket一幕了然，任务出口是由经我这里确认后发出，对整个项目了如执掌。所以不需要，工作报告。 工作报告是不准确的，可以虚构，不实的撰改，为了写报告而写写报告。 中国权利层都有一种想法，高薪我拿，待遇我享受，活你干。导致企业管理层架空，有能力有实力的员工得不到重用提拔。基层优秀员工没有上升渠道。

任务分配

任务的分配十分讲究，分配任务要精确描述，不能使用模糊语言，那样会造成误解。我的分配原则是5W1H方法：

• What：做什么事？
• Why：为什么做这件事？有什么意义？目的是什么？有必要吗？
• When：什么时候做，完成的时间是否适当？
• Where：在什么地方做，在什么范围内完成？
• Who：由谁负责做？由谁负责执行？谁更合适？熟练程度低的人能做吗？
• How：怎样做

举例，运维任务

• What：为api服务器做负载均衡，多增加一个节点，负载均衡算法采用最小连接数。
• Why：目前api服务器只有一台，如果出现故障将影响倒所有业务运行，顾该服务器存在单点故障，需要增加节点。
• When：本周内完成，周末上线。（此处可以写日期）
• Where：在A机柜，低2机位处，连接倒交换机第三个端口。
• Who：XXX负责网络配置，XXX负责上架，XXX 负责验收测试
• How：增加/etc/hosts设置如下
  • api.example.com 127.0.0.1
  • api1.example.com 192.168.2.5
  • api2.example.com 192.168.2.6

举例，开发任务

• What：增加图片验证码。
• Why：目前用户注册登陆以及发帖无验证吗，某些用户通过机器人软件批量开户/发广告帖，给我门管理带来很大困扰。
• When：2014-06-15 开始开发，2014-06-20 12:00 上线。
• Where：用户注册，登陆与发帖处增加该功能，。
• Who：张三负责验证码生成类的开发，李四负责用户注册，登陆UI修改，王五负责发帖UI的修改。
• How：具体怎么操作的细节，此处省略200字...

管理好管理层

管理好管理层比管理好员工更重要，不要让管理层成为传话筒。你是抱着很大期望提供优厚的待遇聘用管理层，对于所有人来说，你需要一个这样的职位，对于他需要一分工作而已。出色的管理层就像出色的员工一样非常难寻，需要机遇，需要天时，地利，人和。很多管理层也如果普通员工一样平平谈谈，当一天和尚撞一天钟。