zoukankan      html  css  js  c++  java
  • 浅谈技术管理(转载,讲的非常不错,技术和产品都值得一看)

    原文链接:http://hi.baidu.com/ncaoz/item/8a17ff633682fd09a0cf0f78

         针对这些年旁观和经历过的技术产品场景,做一些个人的总结和判定,尽量不涉及争议性话题,比如对一个互联网公司而言,技术重要还是产品重要之类的,这种话题一扯开,各有道理,谁也别指望说服谁。

        此外,加一个前缀,主要针对非技术领导者所面临的技术管理困境,在很多从传统企业转型或个人站转型的互联网企业里,这个问题较为突出。

        以下一些产品经理 or Boss 面临的场景,不知道读者是否熟悉。


        这么简单的需求?为什么开发告诉我要做那么久?

        同行 or 竞争对手都做出来了,为什么我的开发说这个无法实现?

        我明明说清楚了,开发也确认了,给我的产品怎么是这么奇怪的一坨?和我想要的完全不是一回事。

        线下测试都ok,一上线就各种崩溃,诡异现象,弄得我们什么运营活动都搞不了.

        请了个大公司出来的,工资巨高的,结果也没看出比便宜程序员好在哪里?

        天哪,又给我说要重构!又是好几个月啥需求都做不了!

      

        看上去,有没有同感?且慢,程序员也有话说。

        你需求三天一改,两天一变,你以为我代码会72变,我多少工作打水漂了你知道不?

        你说这个简单,你前面系统数据结构各种不支持,我不大改我根本支撑不了这需求,我跟你说数据结构你听么你?

        你告诉我做A,B,C,D,E,我都按你说的做了,做完了你说不是你要的,鬼知道你要什么。

        你就给我这点开发时间,我已经加班给你把事干了,我反正实现了,测试也通过了,线上出问题,你业务场景各种诡异,我哪里知道,又没早跟我说。

         天天有事没事就拉我开会,你知道我思路多难集中么?完全没效率,你尊重过我的时间么?你以为写代码随时抽五分钟就能写一坨么?

         这代码补丁打得,找一个小问题要一个下午,不重构你后续功能没一个可以顺利快速搞起来的,我替你考虑,你还埋怨我?

         哎哎哎,上面的那位童鞋不要乱讲,我设计架构的时候,也没想到现在业务这么变态啊,当时我可是按照标准的流行业务模式设计的。你没理解我架构精髓,就知道重构,你有问题哦你。

         好了,打住打住,架构这话题太大,程序员自己都会pk起来,不和谐。


    下面说一下我的理解和相应的对策。

    问题1:信息不对称

           产品人员往往认为,描述了功能需求,甚至简单的给一个竞争对手的范例,工程师就能完美的实现所有业务需求;但是,工程师对业务的理解往往是欠缺的,因此在产品的塑造上,很可能因为个人理解偏差,带来极大的随意性;即便是产品经理具有超强的控制力和投入,保证技术在功能实现上与使用场景吻合,但往往因忽略了业务的性能诉求,导致线下ok的东西,线上各种问题。

    个人认为,让技术充分了解业务诉求,并参与业务讨论,是有必要的,只有这样,才能深刻理解产品的设计目标和设计要点,这样才能减少产品跑偏,与需求不符的现象。


    问题2:尊重技术人员的时间观

            工程师什么时候开发效率最高?我相信不止我一个人会有这样的感觉,凌晨1点-2点这段是时间,夜深人静,无人打扰,开发效率最高。应尽可能营造无打扰,无中断的开发环境;从设计代码到编程到测试,开发需要整段的时间来思考和实现,比如下午4点有个会,哪怕只有10分钟,等于一个下午没有效率。至少以我个人而言,是做不到可以随时中断,随时继续的开发水准。我几年前比较多的编程都是在半夜完成的。

    所以,产品人员应当与技术人员勤沟通不错,但是请尽量将完整时间给工程师,比如早上上班后开沟通会,保证后续的完整性,下午午饭后立即开沟通会,或者用午餐会的形式,留给完整的下午时间给工程师,都是值得建议的方案。


    问题3:理想主义情绪

           开发人员往往有理想主义情节,希望所设计的架构可以支撑更广泛更持续的应用诉求;有时候产品人员也会有这样的想法,过于追求远大的宏伟目标;理想主义往往导致投入太多的无用功到无谓的兼容性设计上,而实际上,随着业务的发展和市场的变换,往往大部分提前准备的或者按照高端目标准备的设计,都是浪费的;其实,最重要的是把握当下的市场,互联网产品淘汰更新频率太快,未来是怎样,很多不确定的因素。

    一个典型的架构悖论是,为了支撑更多更复杂的业务诉求,而设计了一个非常宏伟庞大的架构,但是新的诉求出现的时候,很抱歉,互联网发展太快,新的诉求超出了最初的预期,然后,因为架构太复杂太庞大,所以无法实现。

    这事在著名的互联网上市公司是经常出现的。

    轻架构,着重当下,代码做好低耦合就可以了,不用把架构弄得太复杂,而且,个人认为,最好的设计是,让后续的程序员(中等水平),不读文档,只看代码就能接手。


    问题4:80%的无用功

           这事可以说是问题3的升级版;也可以说是问题1的升级版;程序员往往因为对业务诉求不清晰;或者为了追求完美,将80%的精力投入到并不存在的业务诉求上,这我也遇到过,而且,当事人,无论是产品负责人,还是技术人员,在我点明之前,都茫然不知,以为只是技术不够成熟才导致周期过长。

    举个简单例子,在统计系统,查看来访的refer统计,如果一个网站有几万个refer来路,请问哪个站长会去看超过1000名以后的来路?这个业务诉求是不存在的,但是工程师却努力的为此纠结,‘我的存储压力太大了啊,每天要存储多少这类信息啊。’ 你需要存这么多么?

    类似的很多数据统计和分析系统里,汇总数据是不能丢的,这是必须的,但是各种排行数据,总有一些长尾是业务上永远不会去看的,这些数据占据了80%甚至90%的存储资源,带来各种负载和查询压力,而实际上,却不存在这样的业务诉求。

    简单说,很多业务系统,都存在这样的现象,有超过90%的数据为了满足不到1%的需求,怎么处理?

    小公司,建议直接砍掉;大公司,留在另册保存,单独查询接口,不占用主体业务资源。

    这样下去,技术压力就会减轻很多,考虑的复杂度就会降低很多。


    问题5:考核机制

           抱歉又要说这个经典案例了,明明可以很简单完成的事情,工程师会说”我要评高级工程师,我需要有技术价值体现啊,我不能这么简单的做啊!“ 这事在大公司常见,所以简单问题复杂化,管理考核体制首当其冲。

    顺便说一句,大公司创新乏力,很大程度是被这个原则拖累的,程序员想的不是把产品做多牛,是自己技术炫出来先,好上一个层级;产品人员只好苦捱技术炫技的过程,错失市场良机。


    问题6:没有足够的思考和设计时间,以及学习研究的时间

           好吧,前面说了,不要追求完美,不要设计复杂的架构,但是即便是轻架构,即便是简单的代码,也需要足够设计和思考的时间;

    小公司、非技术管理者,往往简单的认为,实现开发就是编码、编码、编码。

    其实,设计到位,编码就会如拉稀一般一泻千里;设计不到位,就如便秘一般,寸行难行。

    按个人的经验,自己以前设计统计系统的时候,会想几周,做一些简单代码,测试一些想法和原型;等一切思路上的疑惑解决后,编程就是很简单很容易的事情了。

    看程序员的工作效果,请给予更宽松的时间和绩效考量,不要看一个程序员发呆,或者听音乐,就下结论说他不干活;别真把程序员当码农。

    当然,必须指出,好的程序员,在思考清楚后,实现效率是快的惊人的,也请部分开发工程师别为自己的偷懒和无作为推脱。

    简单的评判标准是,如果给一个优秀的程序员足够的思考和空闲时间,应该有一个代码爆发期;他的成果应该能够在短时间内得到集中的体现。如果是思考一段时间后写代码依然便秘的,那么,这个人的水平大概也就清楚了。


    问题7:资深与多面

           大公司的技术人员,如果不是特别顶级的,往往能力局限在某个领域,当然深度足够,但是广度基本都很欠缺;特别是一毕业就进入大公司的,最悲惨的是在某个特定架构下写程序的,写了五年后出来一看,尼玛原来自己只会写一种架构下的代码。(当然,必须指出,在大公司还是早期小公司的时候进入的技术人员,往往更全面一些。) 而小公司往往需要多面手,最好服务端也会,客户端也会,样式表也会,反正老板是分不出写程序和写程序还是有区别的。但是深度要求,恐怕就没大公司那么深了。


    所以问题来了,从大公司挖一个专家来,结果发现这个不会,那个也不会,还不如自己3000块钱招的野路子程序员;这就是需求不匹配,目标不清楚;如果小公司遇到了非常严重的技术瓶颈,一旦突破业务会爆发性增长;而恰好某个大公司有这个领域的技术专家,那么这种定向的动作是会有很好的效果;但是如果只是觉得技术差点事,或者只是对技术不满意,希望通过来一个大公司的解决问题,这事能如愿的不多;


    当然,还是那句话,从小公司开始就进入大公司的元老核心技术,见证一个公司从小到大历程的,经历过公司几次技术升级的,是非常难得的极品人才,问题是,这样的人,市场上是很难遇到的。而且,就算遇到了,往往也不是小公司请的起的。


    七扯八扯,勉强凑成一篇,最近人退化的厉害,写不动博客了,凑活看吧。

    不认同的,有意见的,您随意吧。


    Meet so Meet. C plusplus I-PLUS....
  • 相关阅读:
    The formatter threw an exception while trying to deserialize the message in WCF
    通过Web Deploy方式部署WCF
    The Managed Metadata Service or Connection is currently not available
    How to create Managed Metadata Column
    冒泡算法
    asp.net core 实战项目(一)——ef core的使用
    Vue学习笔记入门篇——安装及常用指令介绍
    Vue学习笔记入门篇——数据及DOM
    Vue学习笔记目录
    Chart.js在Laravel项目中的应用
  • 原文地址:https://www.cnblogs.com/iplus/p/4490136.html
Copyright © 2011-2022 走看看