[职场生存]技术产品永无休止的PK赛
        
      
          zhengyun_ustc 20070212
      
      
      职场生存系列链接:
      
      
        
           [职场生存]细节和感觉[一]:细节
        
      
      
      
        
           [职场生存]细节和感觉[二]:细节包括哪些部分?
        
      
      
      
        
          
            
               [职场生存]细节和感觉[三]:感觉
            
          
        
      
    
      PK每天都在进行…
      
       技术经常和产品或者叫做业务部门做PK,有的有效率,有的甚至仅仅是无谓的争吵。
      
      我们先来给出刘韧式的断语体:
      
      1:争吵是正常的,也是必要的。业务部门一定要学会和技术部门争吵的技巧。
      
      2:刘韧语:“谁都不是超人。所以,大事情一定是很多人一起做的。很多人一起做事情,难免有摩擦。自己还咬自己舌头呢?”我们欢迎有摩擦,创业团队更需要摩擦,而不是和和气气。和和气气的创业团队就意味着平淡无奇的产品。摩擦是常态。
      
      3:两部门的manager需要能够随时跳出三界外,看争吵的流程是否可以提出一个框架,从而能够引导争吵步入正轨,成为有益的争吵,成为总是有产出的争吵。
      
      4:谁能够先一步提出决策流程的框架和执行细节,谁能够推动争吵发展到最后成为有益的成果,谁就将掌握话语权。
      
      5:不要急于下定论。不要急于短时间内解决问题。要分成三种方案来打:短时间内应急解决的立即启动,较长时间内折中方案的设计,长远解决的思路记录下来并安排时间做头脑风暴。
      
      6:多总结固定套路打。
    
      
        
          因缘际会
        
      
      
      业务部常常引发PK的原因有几种:
      
      当业务部门提出对现有产品的改良时,最容易招致技术部门的反击。这时候,往往两票人等在以往的产品细节优劣上争执不下,这可以理解,技术工程师们肯定不愿意承认自己的执行思路有问题,业务们往往也不愿意承认自己先前对需求的解析不清楚以至于执行走了样。
      
      当业务向技术提出一波又一波的需求并设定严格的完成期限时,技术往往会本能地躲闪。现有的问题还有一堆未解决,新的执行思路又难以让技术看到光明或者执行上的稳定性。一旦让技术感觉新需求又是一轮无间道,而不是一个形成了理论、按固定套路打的思路,仅仅是产品部门的试验性或纯粹感觉性的产物,技术不愿给自己招惹新麻烦。
      
      其实,很多事情到最后考验manager或leader的是对人性的理解和应对之策。不单单是IT,也不单单是销售岗位才需要了解人性。
    
      
        
          那么我们如何来拟定框架呢?
        
      
      
      在管理学上,有一个概念叫“决策流程”。大致为,
      
      第一步,问题发现和问题确认。
      
      之后确定决策目标。
      
      拟定备选方案。
      
      评估备选方案。
      
      行动方案的选择。
    
那么如果翻译成Spencer Johnson先生的《”Yes”Or”No”:The Guide To Better Decisions》中浅显易懂的话如何解呢?
      
        
          提出你真正的需求
        
      
      
      毫无疑问,业务部门携创意而来,一定有我们的理由。那么为什么不直接说来呢?
      
      请直接告诉技术部门你心中的那个“她”。先不要提及你对现在产品的不满。
      
      先让技术部安静,听你说,然后让他们回答“是”或“否”。
      
      你可以描述道“第一点,我们希望是简洁的页面、不要新浪式的三栏,我要字体较大、并且是两栏,多留下些空白”,然后阐述说,我们不希望用户第一眼感觉和奇虎没什么区别,都是些擦边信息的千层饼式堆砌。
      
      问技术manager是还是否。
      
      Spencer Johnson先生这么描述这个过程:
      
      “是”或“否”系统方法可以帮助人们判断自己赞成什么,反对什么。如今的世界瞬息万变,我们都需要用更短的时间,作出更好的决定,否则就无法生存,更不用说有好的发展了。
      
      提出的问题总是递进式的。我们先把基调定下来了。从而缩小了大家争论的范围,就算有争论,也被框住了。不要把时间花费在不能转变为实际行动的争执上。
      
      一旦你的一系列问题得到了技术的“是”的回答,Okay,你可以宣布第一阶段到此结束。千万不要恋战。
      
      从此刻起,大家不要再回到这个“问题发现和问题确认”阶段,不要再对一些概念喋喋不休了,不要再对谁应该承担过往的责任上扯淡了。我们直接进入下一个阶段。
    
      
        
          告诉自己所有可以选择的方法
        
      
      
      第二阶段,我们要记住一点:
      
      1:“我们收集的信息越多,就会发现自己的选择越多”
      
      2:不要急于下结论。
    
      往往产品部门在自己的窝里想得美美的,于是就携带着一个横空出世的具体执行思路来找技术要求实施。技术如果不以为然,产品们就仿佛受到了侮辱。
      
      实际上,此时一定要产品部门静下心来了。Spencer Johnson先生告诫我们:“当你思考一个决定,问自己:‘我真的深思熟虑了吗?’这个时候,最好把这个决定放一放,先睡一觉,第二天早上再拿出来重新审视一番。”“一个决定带来的结果可能影响到下一个决定----只是我们常常没有意识到这一点----因为我们必须重视这种以前没有意识到的关联。”
      
      之所以技术最为头疼的业务无间道们变动来变动去,其实大多数原因就出在“一个决定带来的结果可能影响到下一个决定”,于是,大家伙就跟着这种连串影响连滚带爬的。这种就好像最近的莫斯科宣布4月1日起外国人不允许从事零售业务,执行倒是雷厉风行,但是伴随而来的不是莫斯科市民的既得利益,而是物价迅速飞涨,供应不足,全市70%的零售摊位没有本国人来填补空当,于是不得不紧急叫停。
      
      所以这个“拟定备选方案”决策阶段一定要多听听各方建议,不要把业务的既成方案塞给技术。技术呢,也多提几个,应急的方案,短期内能适应潜在变化的方案,长期致力于吸收这个新创意而又更臻完美的方案。
    
      然后呢?
      
      
        
          对事情深思熟虑
        
      
      
      Spencer Johnson先生说了“专注于你真正的需要,告诉自己所有的选择,把每种选择从头到尾想清楚,更好的结果就会自然而然地呈现在你面前。”
      
      “要作出更好的决定,我就要问自己,‘这样下去会发生什么?接下去又会发生什么?然后会怎样呢?’直到我深思熟虑后再作决定,并且确定它能带来更好的结果。”
      
      这就是决策流程的“评估备选方案”。
      
      我发现,业务部门技术部门往往把精力耗费在前面问题发现和问题确认了,在长时间的争吵后,到了真正需要深思熟虑的这个阶段,却筋疲力尽,匆匆决定,于是参加会议的人们离去时都有虎头蛇尾的余味咂摸。
    
最后,才是“行动方案的选择”阶段。
      
        
          当你们结束会议的时候,扪心自问:
          
          我有没有满足自己的真正的需要,告诉自己所有可以选择的方法,并对事情深思熟虑?
          
          □是
          
          □否
        
      
      
       
    
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1509778


 
					 
					