从技术到管理的七个问题


  时间像一把无情的刀,改变了你我模样,转眼很多年已经过去了...

  曾经年少轻狂的我已经变成了别人看来成熟稳重的职业经理人,虽然我并不喜欢这样一个称呼。

  从打工到创业、再到把公司卖掉、又重新作回打工仔,我也算经历了很多次身份和角色的转变。有些是主动性的,比如当初创业,身份从打工变成老板,那是对自己梦想的一种追寻;而有些却是被动性的,不得不去面对,比如公司卖掉后,身份又回到打工。

  其实身份的转变是可以很快适应的,因为屁股决定脑袋,在其位、谋其政。站的立场不同,那么想法也会自然而然的转变过来,不需要有什么技巧或者经验可以传授。

 

  但是,角色的转变却并不是那么容易的一件事情,就比如从技术人员到管理者的转变!

  我曾经看到很多人都栽倒在这个问题上,相当多原本优秀的技术人员,在这个转变的过程中成为了并不合格的管理者,一来一去,就等于同时造成了两个错误!这对一个规模并不大的团队来说,打击将会是致命的。

  回首自己10多年的职业生涯,也经历了这样的一个过程,最早是一个普通的程序员,慢慢成为主程序,然后是项目经理、总监、现在成为了制作人,管理着200个人的近10个项目团队。

  亲身经历加上所见所闻,见到了太多太多这样的案例,也曾时常和朋友同事们探讨交流,但始终还是无法得到标准的答案。不希望老是犯同样的错误,想把自己的想法和大家分享,相互印证,所以提出了下面的七个问题,既是问自己,也想听到大家的见解。

 

  问题一:深入骨髓的技术情节下,怎么适应角色的巨大转变?

  问题二:曾经的同事、如今的下属,关系[来源:GameRes.com]如何处理?

  问题三:我是不是一定要是最强的?

  问题四:面对打酱油的人,该怎么办?

  问题五:制度与人性化,哪个更重要?

  问题六:如何保持团队的创新动力?

  问题七:先付出还是先得到?

 

  七个问题,看似简单,但每个问题或许都有不同的答案,也都可能存在巨大的争议。所以我想多给自己一些时间,计划每周拿出一个问题来集中讨论,这样应该能想的更清楚一点,那么分享就能更透彻一点。

  今天就当开个头,破个题,下周谈第一个问题。

 

  最后,为什么要写这个?

  无他,就是给自己找点事情,加点压力,多思考一下而已。

  如果凑巧能给正在进行角色转变或准备转变的你带来一些帮助,那么我就更心满意足了。

问题一:深入骨髓的技术情节下,怎么适应角色的巨大转变?

  先明确一下,这里讨论的技术是广义上的技术,不止局限于程序技术。如果限定在在游戏这个行业内,那么不仅仅只有程序员才是作技术的;实际上,包括策划、美术、QA甚至运营人员,我认为都是做技术的,只不过是专业技能不同而已。

  我想,基本上所有朋友的职业规划都不会仅仅只定位于一个最初级的技术人员,每个人从内心来讲都是渴望不断提升的。其中,有些人专注于技术,希望成为一个领域的专家;而另外一部分人,会逐渐从技术转向管理;两条不同的成长线其实就是我们经常在一些大公司听到的所谓双阶梯成长。

如下图所示:

            大师 <---> 制作人

           导师 <-------> 总监

  (技术阶梯)  专家 <-----------> 经理   (管理阶梯)

         资深 <---------------> 主管

        高级 <-------------------> 组长

       中级

      初级

  这个文章系列的主题,就是从左边跳向右边的过程中发生的事情。要注意,跳得不好,你是会重重的摔下去的。

  正常情况,一个人职业生涯的前几年,目标可能是深入学习技术,不断提升专业能力,几年过后可能就会晋升为技术主管,这个时候角色就开始转变了。

  还有一种情况也是时常发生的,由于团队突然发生变化,如同赶鸭子上架一般,你临时就被推上管理岗位了,在完全没有任何思想准备的前提下,角色转变的事实就已经摆在面前。

  两种情况的发生虽然不同,但是本质上面临的问题是一样的,先谈谈我的看法吧:


  最核心的问题:要认识到,作为管理者,团队的成功才是自己的成功!

  因为别人对你的评价已经从你行不行,转变为你带的这只队伍行不行。不管你的技术再好,如果团队不行,还是证明你不行!反之,就算你不作任何具体技术,但是团队出成绩了,就说明你行。所以,要时刻提醒自己,目标是什么。

  一旦明确了目标,那么很多事情和决策也就有方向了,是把时间精力投入到技术上能让团队成功?还是投入到管理和培养上更能让团队成功?

  这个问题是没有答案的,因为团队构成不同,当时面临的情况不同,就有不同选择。

  比如我在做公司第一款游戏的时候,曾是项目负责人,又兼主程[来源:GameRes.com]序,照理应该更多的时间花在管理上,但是因为团队不大,总共十来个人,4、5个程序员,沟通管理成本还不高,所以很多的时候我都是在做技术的,大概只有20%的时间用在管理上。当然,后来随着团队规模的扩大,管理占用的时间也逐步上升。

  后来公司成立新的项目组,团队五六十个人,这个时候如果项目经理或主程序还是把80%的时间埋头于技术研究上,那么我想这个项目成功的可能性几乎就没有了。因为管理问题会不断的冒出来,作为负责人你必须解决,那么你也就不可能安下心来做好技术,最终的结果是两头都做不好。

  所以,这个时候你自己必须更多的投入管理,技术上学会放权,信任你的伙伴,一开始他们的确有可能在经验上有欠缺的地方,但是要相信每个人都在成长,而且谁也不比谁笨多少,技术上你能做到的事情,我相信大多数人也都能做到,只不过你先作了一步而已。善于成就他人,而不再只是满足于自己点滴的技术成就上,我想这就是从技术到管理的一次飞跃!

  总结一下,我认为,不论技术还是管理,其实都是个人自我实现道路上的一种手段而已,在对的时间做对的事情,就可以了。


  另外,真正好的管理者应该是让人感觉不到管理的,如同球场上的裁判。如果把成为管理者当成是成为明星,可以受到大家的追捧,那必将失败。或者认为管理就是当老大,控制他人,那也必将失败。


  好了,这个话题就到这里吧,啰嗦的有点多了,如果你能看完我想也已经不容易。以后的话题争取更精炼些,在这个微博横行的时代,看这么长的文章真的是辛苦大家了。

  转载自:http://bbs.gameres.com/showthread.asp?threadid=166839

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
运维管理平台技术规范是指在进行运维管理平台开发和运维工作时需要遵循的一系列技术规范和最佳实践。以下是一些常见的运维管理平台技术规范: 1. 安全性规范:包括用户身份认证、权限管理、数据加密、安全审计等方面的规范,以确保平台的安全性和数据的保密性。 2. 可用性规范:包括高可用架构设计、故障恢复机制、监控和告警等方面的规范,以确保平台的稳定性和可靠性。 3. 扩展性规范:包括水平扩展、垂直扩展、负载均衡等方面的规范,以支持平台的高并发和大规模用户访问。 4. 性能规范:包括性能测试、性能优化、资源管理等方面的规范,以确保平台在高负载情况下的性能表现。 5. 日志和监控规范:包括日志记录、异常监控、性能监控等方面的规范,以便及时发现和解决问题。 6. 配置管理规范:包括版本控制、配置文件管理、环境隔离等方面的规范,以确保平台的配置一致性和可追溯性。 7. 自动化规范:包括自动化部署、自动化测试、自动化运维等方面的规范,以提高开发和运维效率。 8. 文档规范:包括技术文档、操作手册、API文档等方面的规范,以便开发人员和运维人员能够理解和使用平台。 以上是一些常见的运维管理平台技术规范,具体的规范内容还需要根据实际情况进行具体设计和制定。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值