浅谈技术型企业管理

浅谈技术型企业管理

过去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字...

管理好管理层

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

现在流行“找客户痛点,不如找领导G点”,不知大家的企业怎么样? -- 引用某网友一句话

原文发布于微信公众号 - Netkiller(netkiller-ebook)

原文发表时间:2015-10-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java学习网

老码农的技术理想

老码农的技术理想  小时候,老师问我,你的理想是什么?我不假思索说是工程师,于是长大之后果然成了工程师。   工作这么多年,一直在思考工程师这三个字的意义,终于...

26710
来自专栏云计算D1net

云计算到底离我们有多远?

现在好象不谈一谈云计算,就不象IT 圈的人。CIO自媒体联盟要求大家统一以此为题写一写对于云计算的感受,这是一篇命题作文。好吧,那就谈一谈这片云到底在哪儿?离我...

2383
来自专栏BestSDK

老码农的技术畅想

小时候,老师问我,你的理想是什么?我不假思索说是工程师,于是长大之后果然成了工程师。 工作这么多年,一直在思考工程师这三个字的意义,终于有一天恍然大悟,原来就是...

2305
来自专栏信安之路

我在拉勾三个月的工作总结

大家好,我是 myh0st ,目前我在拉勾网负责安全相关的工作,包括但不限于:安全建设、等保测评、渗透测试、安全培训等工作,目前我们所在是拉勾下面技术工程部运维...

763
来自专栏静晴轩

小团队的技术管理

最近一年左右兼职技术管理的经验试总结,核心理念就是以人为本。 小作坊   小项目的构成往往是一个相对有经验的人作为 leader,带几个毕业生构成一个三五个人...

2705
来自专栏ThoughtWorks

TW洞见 | 任务优先级和办公室政治

今日洞见 文章作者及图片来自:ThoughtWorks - Jim Highsmith。封面图片来自网络。 本文版权归【ThoughtWorks中国】(微信ID...

3328
来自专栏飞总聊IT

SAP HANA神话(7):屌丝的崛起

SAP HANA系列到这里也就基本结束了。这一章的内容是我和几个朋友聊天以后决定新加的。这两年的database的领域变化很快,快到一个公司刚正确一把站稳了位置...

3643
来自专栏SAP最佳业务实践

从SAP最佳业务实践看企业管理(10)-CRM

假如你是一个销售,你知道你和客户处于什么阶段吗? 客户生命周期描述了客户关系水平随时间变化的发展轨迹,它描述了客户关系从一种状态(一个阶段)向另一种状态(另一...

2696
来自专栏DevOps时代的专栏

从企业案例看 DevOps 转型路线图

前言 在给客户培训DevOps的时候会尽量把整个DevOps体系,包括流程、文化、 技术实践,和业务IT的关系等等传递给客户。但是企业要想从头开始实施 DevO...

2308
来自专栏科技项目

高企认定干货 | 高新技术企业申报常见问题汇总(一)

2017年的高新申报工作已经圆满结束了,并且已经进入第二批名单公示阶段。在项目结束后,小编总结了在今年的高新申报常见的问题,一起来看看这些误区您有没有不小心踩着...

21511

扫码关注云+社区