对华为系统软件的战略思考(下)–（10）华为研发
作者 陈怀临 | 2008-02-28 16:02 | 类型 专题分析, 中国系统软件 | 28条用户评论 »
|
从前面各章节的数据分析，读者可以初步得出这样的结论，华为的研发实力是薄弱的。这个薄弱是相对于其的年营业额收入，其员工规模，其正在竞争的公司。 通常而言，华为负责的研发部门就是其”华为中央研究部(院)”。其总部在深圳。在各地有其分部，如北京的北研所等等。。。。。。 笔者2006年6月5日写的“华为猜想”一文中，对华为的技术管理方面做过一些分析。结论是：华为的技术管理基本上是不可控制的，是被市场和客户问题牵着鼻子走的。基本上没有引导市场的自主能力。 文章中一些节选如下： “。。。虽然华为在2005年的营业额已达到50亿美金(5Billion Dollars)，但从公开的数据分析，我们可以看出，拥有几万员工的华为其营利利润的比率并不是很高。虽然华为已经认识到仅仅通过廉价的研发人员和廉价的产品价格是行不通的，但目前华为基本上无后力可发。研发的创新性基本上层次不高。因此，华为，虽然在人员上，销售上，已经貌似一个国际性的大公司，但是在公司地位(Credit)，市场和销售上，基本上目前仍然是一个小公司作坊的性质—没有技术和市场主导能力来影响客户，而是被客户所挤压，为了获取底利润的订单，拼命的压低研发R&D的成本，从而能够维护其营业额的持续性增长。胡新宇就是在这样的环境下的工程师。理论而言，当一个高科技公司成长到数万之众，年营业额达到五十亿美金，公司的信誉和市场的领导能力已经建立起来。此话怎讲? 简单而言就是：一个客户宁愿多等待1到2个季度，也愿意采纳一个公司的产品发布。例如，一个行业的领导者可以是这样的一种企业战略：通过定期的访问其目前客户和将来可能的客户，非常明确的让客户知道公司产品的Roadmap，比如2个季度之后产品发布的时间和承诺拥有的新特性(feature)，4个季度之后产品发布的时间和承诺拥有的新特性。。。。 在拥有强大研发实力和信誉的公司背景下，一个高科技公司就不会沦落为市场的奴隶，而是通过信誉和承诺等等来实现与客户的双赢。当然具备这样实力的公司的前提是： * 相对完整的产品线。 *高利润 *强有力的研发实力和管理，定期的，持续性的产品发布。 *信誉和承诺 华为拥有了第一点，其他3点是目前并不存在的或需要提高的。 这就是华为的研发队伍经常出于疲于奔命的根本原因：华为目前还没有能力影响市场，从而其研发周期没有能力自主。
创立于1988年，目前华为挟数万之众，在深圳(总部)，北京，上海，南京，西安，成都，武汉，欧洲，独联体，北美，埃及，巴西，南非，马来西亚，印度，香港，韩国都有其研发中心，技术服务中心或办事处。 其产品线大致分为6大集团： WCDMA – 下一代网络 – 接入网络 – 光网络 – 数据通信 – 视频通信 华为公司提供的解决方案划分为：运营商解决方案，行业解决方案和家庭与个人解决方案。 运营商解决方案，分为：无线网络，固定网络和综合解决方案。 无线网络：WCDMA, CDMA2000, GSM,移动核心网，无线网络规划，3G业务解决方案 固定网络：下一代网络(NGN)，交换网络，接入网络，光网络，数据通信，视频通信 数字电视，固网终端 综合解决方案： IPTV， IMS业务解决方案，增值业务，运营支撑。 行业解决方案： 企业业务解决方案 ， 中小型企业视讯解决方案 ，高清视讯解决方案 远程教育系统 ，多媒体通信解决方案 ， 数据通信教育解决方案 数据通信企业解决方案 ， 数据通信政府解决方案 ， 电力行业解决方案 高速公路行业解决方案 ， 社保行业解决方案 ， 邮政行业解决方案 铁路行业解决方案 ， 教育行业解决方案 ， 公安行业解决方案 华为VoIP解决方案 家庭与个人解决方案 ： 数字家庭 ， 手机 通过考察华为提供的解决方案，我们可以认为： *华为的重点是运营商解决方案。 *行业解决方案中，除了VoIP，其他的基本上是接订单，搞网络集成，收费系统等的工程项目。换句话讲，是来一家，吃一家。吃完一家，少一家。。。 在运营商解决方案中，所谓的数据通信线，其主力应该是北研所。 从上诉可见，华为的结构很大，产品线铺垫的很广，地域分布也全球化了。 笔者的问题是：华为的最重要的资产是什么？“人才，21世纪最重要的资源就是人才!”。 对于华为，其人才的智力贡献体现在那里？ 笔者说：就是那些千万行摸不着，但却看得见的ASIC芯片的RTL，板子的电路图和系统的C代码! 就是这些代码实现了其各个解决方案。 华为什么都可以没有，就是不能丢失上述的代码! 没有这些代码，华为什么都不是。 这些代码不是任正非能写的，不是那些高级副总裁能写的，是那些工程师们一年一年累计出 来的，用他们的青春和汗水。。。。。。 既然我们知道华为最重要的就是那些代码，那么对这些代码的管理就是华为技术管 理层面的一个非常重要的部分。管理的好，其代码质量，代码重用，代码维护，代码移植，代码优化，代码集成，代码升级等等都将顺利；否则，整个华为的智力大厦的”形而下”将是非常脆弱，千疮百孔。华为的系统将举步维艰，其”形而上”的目 标，比如：国际化道路，高新技术研发，公司并购与集成等都将是非常难以达到的。 那么我们来推测华为的代码管理体制。 如果我们假设华为用CVS来控制代码。 从华为的产品线分布，我们基本上可以断言，华为不可能存在一个总体华为代码属（main-line codbase）。例如，我们可以称其为：”huaweios” ，既然不存在一个统一的”huaweios”CVS 根，节点那么华为的代码控制或布局应该可 能是这样的。每个产品线存在一个main-line codbase节点。 各个产品线的CVS节点基本上独立的，并行运作的。其版本发布周期是与各自的项目计划单独联系在一起的。从新闻媒体上可见的消息，我们看不出各个产品线的代码 是有计划的定期升级的，或是周期性的有规律升级的，而是不定期的，不规则的，强依赖于各个项目发布而升级的。 从胡新宇事件的分析，我们猜测了华为在市场压力下的工程部门的项目计划和管理： –没有R&D的自主性和规律性的中长期计划(或处于经常被打断的中长期计划中)。以此推理，我们可以得出如下结论。 为了对付市场和销售部门临时而来的要求，工程部门不得不不断在其mail-line节点 上开出CVS子节点(或我们说拉出一个CVS Branch)。然后，各个子项目分别在子节点上迅速的，拼命的赶工期，check-in 代码，QA测试，然后迅速做特殊发布（Special Release）。 发布后，其工程部门的售后服务，代码维护也不得不将在各个子节点上展开。 我们不妨假设数通业务的代码节点是Tree_Data. 在某个时间点t0，数通的main-line release是 Tree_Data_t0. t0=2006_0628。版本是数通OS 1.0，不失一般性。 随著时间的推移，数通的代码节点就变成了这样一个(图论的)群。 Tree_Data_t0 —————————–Tree_Data_t0_1 —————————–Tree_Data_t0_2 Tree_Data_t1 … —————————-Tree_Data_t0_N —————————-Tree_Data_t1_1 —————————-Tree_Data_t1_2 … —————————–Tree_Data_t1_N … Tree_Data_ti ——————————Tree_Data_t(i-1)_N-1 —————————–Tree_Data_t(i-1)_N —————————–Tree_Data_ti_1 —————————–Tree_Data_ti_2 … —————————–Tree_Data_ti_N … 大家知道，Tree_Data_t0_(1–N)的东西是非常有可能没有回到Tree_Data的主Release Tree_Data_t1的。换句话讲， 飘在往外的子节点的新代码，更重要的是那些从现场反馈回来的bug fix是很难及时回到main-line的。 随著Tree_Data_ti的主Release的增加，飘在外面子节点的增加，整个数通Tree_Data的代码维护，升级将变成一个恶梦。 一般而言，结果是这样的：由于为了对付特殊客户/订单，大量的CVS Branch的飘在 主Release之外，同时主Release又必须在Internal R&D的定义下不断发布新的Release，整个代码的Feature Merge, Bug Duplicate, Bug Sync将成为不可控制，或将需要非常巨大的代价。代码管理者，包括研发人员，有时将不知道一个Bug Fix应该往那 个子节点上放。然后，只能等待客户出一件事情，解决一件。疲于奔命。整个研发队伍将不得不花费巨大人力物力在售后技术维护上。其结果体现在CVS 节点上是，在每个Tree_Data_ti_j下面还会有Tree_Data_ti_j_patchk。每个patch是为了解决某个特定用户遇到的解决方案。 最后，数通的CVS节点结构将变成： Tree_Data_t0 —————————–Tree_Data_t0_1 ———————————————————Tree_Data_t0_1_patch1 ———————————————————- ———————————————————-Tree_Data_t0_1_patchM —————————–Tree_Data_t0_2 ———————————————————-Tree_Data_t0_2_patch1 ———————————————————-… ———————————————————-Tree_Data_t0_2_patchM Tree_Data_t1 … —————————-Tree_Data_t0_N ———————————————————-Tree_Data_t0_N_patch1 ———————————————————–… ———————————————————–Tree_Data_t0_N_patchM —————————-Tree_Data_t1_1 ———————————————————-Tree_Data_t1_1_patch1 ———————————————————- … ———————————————————-Tree_Data_t1_1_patchM —————————-Tree_Data_t1_2 ———————————————————-Tree_Data_t1_2_patch1 ———————————————————–… ———————————————————-Tree_Data_t1_2_patchM … —————————–Tree_Data_t1_N ———————————————————–Tree_Data_t1_N_patch1 ———————————————————–… ———————————————————–Tree_Data_t1_N_patchM … Tree_Data_ti ——————————Tree_Data_t(i-1)_N-1 ———————————————————–Tree_Data_t(i-1)_( N-1)_patch1 ———————————————————– … ———————————————————–Tree_Data_t(i-1)_( N-1)_patchM —————————–Tree_Data_t(i-1)_N ———————————————————-Tree_Data_t(i-1)_N_patch1 ———————————————————– … ———————————————————-Tree_Data_t(i-1)_N_patchM —————————–Tree_Data_ti_1 ———————————————————-Tree_Data_ti_1_patch1 ———————————————————– … ———————————————————-Tree_Data_ti_1_patchM —————————–Tree_Data_ti_2 ———————————————————-Tree_Data_ti_2_patch1 ———————————————————-… ———————————————————-Tree_Data_ti_2_patchM … —————————–Tree_Data_ti_N ———————————————————–Tree_Data_ti_N_patch1 ———————————————————— … ———————————————————–Tree_Data_ti_N_patchM …… 上述CVS节点结构分布是非常有可能的，特别是补丁部分基本上是为了特定客户的问题。在巨大项目短周期的压力下，华为如何可能保证代码的质量的高可 靠性？我们基本上可以认为，许多Tree_Data_ti_j的发布是有许多问题（bug）的。华为 只能通过巨大的人力物力，通过Tree_Data_ti_j_patchk的方式来解决客户问题，来做特殊发布。 另外，由于存在不同的新性能非常有可能在不同的子节点上实现。而各个子节点 又是基于不同的Tree_Data_ti。从而使得不同的新性能的整合工作非常困难。 一次大的整合就是一个巨大的内部项目(Project)。花费6个月到1年一点也不过分。而且， 还将面临巨大的从新测试的代价。 这还是在谈论一个产品先内部(Intra-Productline)的代码管理。如果谈论产品线之间(Inter-Productline)的代码共享，重用，在上述猜测结论之下，基本上是没有任何可能。 结果是，华为内部产品线R&D研发之间存在巨大的重复性工作。任何一个互相产品(ASIC，板子，代码)共用的尝试，都面临著巨大的技术困难(我们先排除技术官僚体制在这其中的争权夺利的消极影响)。 目前，我们的推测结论是：华为的代码维护是一个，从图论的观点，群状结构，而 不是一个随著固定时间间隔(比如3个月，或6个月)有限深度的移动树状结构。这种技术管理导致的代码管理，使得华为的智力基础基本上会面临有一天，或已经，变得不可控制的状态。 。。。” 现在，让我们忘掉华为技术管理在整个华为体系中的被动，来看看那么华为的研发结构是如何的呢？ 来考察一下华为从IBM学的IPD。 一方面由于《基本法》达不到预期的效果，而华为的人员规模，销售额更加庞大，1998年，华为与IBM公司合作启动了《IT策略与规划（IT S&P）》项目，开始规划华为未来3-5年需要开展的业务变革和IT项目，其中包括IPD（Integrated Product Development，集成产品开发）、ISC（Integrated Supply Chain，集成供应链）、IT系统重整、财务四统一等8个项目，IPD和ISC是其中的重点。2003年上半年，数十位IBM专家撤离华为，业务变革项目暂告一个段落。此次业务流程变革历时5年，耗资数亿元，涉及公司价值链的各个环节，是华为有史以来影响最为广泛、深远的一次管理变革。 理论上，IPD能够在研发前期就避免以前需要投入市场后才会暴露的重大问题。以前华为的产品开发都在中研部(中央研究部)，现在改由PDT(产品开发团队)来承担。每个产品都有各自的PDT，每一个PDT团队由研发、市场、财务、采购、用户服务、 生产等各部门抽调的代表组建，像一个个创业型小企业，从研发开始，对市场、利润、产品生命周期等全程负全部责任，共同协作完成一个产品从概念、研发，到生产、上市的全过程，从而真正实现产品研发和市场的同步进行。 中研部是华为头一个面临IPD挑战的部门。以前中研部全权负责研发，市场部门负责销售，中研部做什么，市场部门就卖什么。现在，产品做成什么样完全由不得研发人员，别人都得参与，而这些人以前都是和研发根本不搭界的人。 新的运作流程变为，市场代表带着产品规格、技术参数等信息到市场上搜集客户反馈，据此考虑市场空间、客户需求的排序，哪些需求会对未来产品的市场潜力和竞争力产生重大影响等等。在市场人员的强烈参与下，产品的概念得以形成。 接着，财务代表根据市场代表提供的市场数据算账：需投入多少研发工程师、仪器设备成本、制造成本、物料成本、产品生命周期内销售额、利润等，一份企业业计划书产生了，用以说服IPMT(投资管理委员会，分产品线设立，共有9个)同意为该产品投资。 华为实施IPD的效果任何呢? 一位参与华为IPD变革的华为员工说：执行IPD的基层管理者还没有完全认同IPD，或者是为了维护小集体利益，造成纵横制管理带来的多头领导，产品线和资源线可能为了各自利益，对处于交汇点上的人员提出不同甚至相互矛盾的工作牵引， 使得产品线人员经常感到无所适从。 5年时间过去了。华为聘请IBM的专家给自己的各个部门做管理评分（TPM），以满分5分计，华为2003年的平均分只有1.8，2004年上半年才达到2.3，而2004年的目标是2.7。按照IBM的意见，一家真正管理高效规范的跨国公司，其TPM分值应达到3.5。另外，根据IBM专家的评测，华为人均工作效率只有国际一流公司的1/2.5。华为副总徐直军对此结果并不满意。 IPD顾问说要追求效率，控制成本，但华为今年的市场投入依然是不计成本；后方的产品线改来改去，一线的办事 处该怎么干还怎么干；IPD顾问说产品需要严格按照IPD模式进行规范研发，但在2001年，当某高端路由器产品出手速度落伍于竞争对手时，任正非一声令下，所有程序打乱，突击搞研发，产品得以在极短时间内铺向市场。。。。” 读者读到这里，大概能得出许多结论了。 1。知道胡是如何累死的了。 2。华为的研发(R&D)只有D没有R。基本上是被市场，销售，售后服务赶着走。 对于华为具体而言，其产品属于信息产业的通信领域。如果没有强大的研发(R&D)中的研(R)，而只有D，随着技术的发展，华为和其类似的公司的技术和产品已经或正逐步变成commodity(日用品)。Commodity是常被用来描述一个技术产品的门槛已经变得非常低的时候的术语。 当一个高科技产品已经快变成日用品的时候，靠卖这个产品的利润(margin)将变得非常小。只能靠量(volume)来获得利润。 比如，现在构建一个中低端router, switch, firewall/vpn产品，是一个非常容易 的事情。 –操作系统是免费的。GPL or BSD License. –网络处理器是便宜的。另外，华为狂用Intel的xscale core的IXP系列。 –高端CPU是可以买的。。。 –网络协议stack是免费的. GPL or BSD License. –应用程序(BGP, OSFP,,,,Firewall, IPSEC, SSL, IDS, AV…..You name it)是免费的。GPL or BSD License. –硬件开发版是可以outsourcing的。台湾无数小公司在做。 我们可以看出，对于华为，或其他公司，其工作的主要部分其实就是一个系统集成的工作。当然，我们并不是说系统集成就容易。但我们要清醒认识到，华为的产品离中国的国家战略并不是其所想象的那么近。 我们在操作系统的能力，高端网络处理器的能力，高端CPU的能力才是中国在信息产业方面的国之重器。当然，这都是华为的技术能力不可能涉及的。 3。华为对中央研究部(院)是矫枉过正。在IPD之前，中研院技术驱动一切。是错的。 现在IPD下，是市场和销售驱动技术。也是错的。而这就是华为最本质的错误。华为根本不具备这个条件。技术研发实力还非常薄弱。根本撑不住市场的要求。IPD的结果就是其R&D疲惫不堪。只能靠人海战术。从而导致恶性循环。 | |
  (3个打分， 平均：3.00 / 5) |
10. 华为研发雁过留声
“对华为系统软件的战略思考(下)–（10）华为研发”有28个回复
分析的比较精彩。
代码管理，CVS的使用上估计国内的大部分公司都会遇到这样的问题。最起码我任职过的公司没有一个能很好的解决这个问题的。
希望大侠能在这个问题上谈谈经验。
[...] 对华为系统软件的战略思考(下)–（10）华为研发 对华为系统软件的战略思考(下)–（9）华为专利 对华为系统软件的战略思考(下)–（8）华为VRP 对华为系统软件的战略思考(下)–（7）华为集成 对华为系统软件的战略思考(下)–（6）焦土策略 对华为系统软件的战略思考(下)–（5）釜底抽薪 对华为系统软件的战略思考(下)–（4）资本的力量 对华为系统软件的战略思考(下)–（3）兵家伐谋 对华为系统软件的战略思考(下)–（1，2）前言与兵不血刃 (没有评价) [...]
管理层把研发体系的名声搞臭了，招不到合适的研发员工，而招到的有潜力的员工–要么被提前推到做system engineer，要么疲于很多糟糕code导致的bug，要么受不了压制而辞职，在本来高手就不多的情况下–研发实力可想而知了，其实整个中国的公司也都这样的。。。。就算他现在重新开始只招聘它当初指定的30多所学校的人—也是无济于事的
巨型规模下的软件设计和管理确实是必须解决的核心问题。这也是北研所很累的主要原因之一。
H如果不能在运营效率上持续有效的改进和提升，5年将会成为公司发展的滑铁卢
天下脑子最快的人，无非是在华为和高校里的20～30岁的年轻男人。
但现状是：华为和高校，彼此看不起。
可能H更应该多检讨一些
在华为编码6年，做过系统分析；了解几个边缘产品，华为大部分产品，单纯作为独立产品存在，代码量大致在20万~300万行之间；
而且基本原型都是几个牛人搭建起来的，众多码农在上面耕耘，架构分几年，合几年，再分几年，再分几年；有时候是为了忽悠客户，有时候是为了方便维护；
很多小产品的路标基本和研发是两层皮，因为基本功能在最原始的版本就有了，而新增特性能给客户带来的收入通常不超过20%，其余80%都是基本功能带来的；新路标中，最重要的是性能，一旦该产品性能功能可以满足中国移动的要求，那么后即就不需要路标了；
如果在满足中国移动的要求的基础上，这个产品还有新的质的要求，就会新立项；出来新产品；
现在华为有个倾向：卖解决方案，学埃森哲；走虚的路线；研发分析好需求后，实际代码让外包或者三哥来完成；
权力的核心任老板，最关心的是市场，每年的市场大会是必定出席的，而研发相关的会议是基本不参加的；待遇对比也是很明显的；
另外人力数量质量，现在还可以；虽然不足以出现很牛的人，直接把产品做好，灵活配置就可以满足客户的需求；但是基本可以做到，可以在上面修改满足客户的不同需求，当不同客户的需求都体现在不同分支的代码上时，再重构就很容易构造出能灵活配置满足客户多样性需求的版本；
华为现在对商业成功的渴望远远超过对产品成功；
华为现在甚至认为，有钱可以买来需要的核心技术；从某方面看，DWDM是一个坏例子，让华为有了天真的想法；
我觉得楼上说的不完全客观，研发的会议，任老板也需要能听得懂才行啊，否则去了摆样子，那才是务虚。
说起卖解决方案，我不觉得是学埃森哲，而是学思科、juniper，这个行业都在讲究解决方案，卖单一产品的是小公司做的事情。
不同意不重视研发，要不不会成立美研所，包给阿三是很早就有的事情了，不只包给阿三，还包给过国内很多公司，大多是非核心竞争力的东东，你看ospf的v8这种相对核心的东东，华为的投入和重视程度还是很高的。
研发的收入和市场的收入问题，是绝大多数公司都有的。
“结果是，华为内部产品线R&D研发之间存在巨大的重复性工作。任何一个互相产品(ASIC，板子，代码)共用的尝试，都面临著巨大的技术困难(我们先排除技术官僚体制在这其中的争权夺利的消极影响)。”
这个问题三年来一直没有得到解决。
任老板似乎意识到了这个问题，提出了建设大平台的口号。结果个各个产品线和中研展开了新一轮的抢山头大战。
8楼，似乎完全没看懂7楼在说什么。再看一遍吧
不，看懂了，我也了解一些，我还知道甚至有些产品，两个部门同时做，谁先做出来卖谁的，注意，是谁先做出来，而不是谁做的最好。
我只是觉得不要完全否定，不要偏颇，我们不能说华为重视解决方案就不重视产品了，不能说华为有内部竞争就窝里斗了，不能说销售收入高就不重视研发了。
毕竟华为还活着， 而且对很多欧美企业来说是很大的威胁（我不知道北电和摩托的没落有没有华为的影响），所以希望更客观一点，不要太左，也不要太右。
to ls：
我尝试总结一下7楼的“中心思想”吧
1.其实让任老板出席研发的大会也就是一年花几个小时去做做样子。但是老板连这个样子也懒得做。可想研发的地位
2.卖解决方案其实就是拿张纸忽悠客户。忽悠完了你得把设备做出来。但是华为似乎越来越觉得通信设备是“20%脑力+80%体力”的工作。希望通过部分经验丰富的设计人员带领一群新兵蛋子和外包人员以降低产品开发的成本。因为过去10多年我们就是以这个模式成功的。我不知道你说的CSCO,JNPR对产品开发是不是这个态度。
3.美研所不多说。
4.同一期的研发与市场人员收入差距不多说。但是市场出差有补助住酒店，研发出差一天给6块钱，住宿舍。在公司里面就低人一等。不知道这些歧视性的政策在CSCO和JNPR算不算正常。这些必然会引起优秀研发人员的流失或向市场转移。最终留下1%真正的“奋斗者”和99%因为需要还房贷车贷忍气吞声还不能走的2，3流人才。
综上，华为内部从来没有真正重视过内部研发环境的建设，很多问题都被连年增长的销售数据光环掩盖了。所以才造成里今天这个人均效益只有业界40%的局面。注意，我只是尝试去诠释为什么人均效率低为什么有人要累死为什么这个局面不会改变。人均效率低但只要人均支出更低，相对竞争对手的单位效率就更高。这才是华为的核心竞争力。
NTL从250billion到0.5billion也就用了10年时间。贵族的没落大部分是由于自身发展的惯性，华为只是从外面推了一把而已。
华为是否会在过去成功模式的巨大惯性中走向衰败？希望不会出现那一天
市场是最复杂的社会关系节点。
什么人最精？生意人
买东西给精人与和玩技术孰难？
老板觉得谁难就多给谁钱，否则谁愿意跟你吃苦在前，享受在后
比如一个销售在一个地方做了两年，如果业绩接近0（以至少N百万计的销售中，你的销售在10万周边晃悠，这就接近0），甭说任何客观理由，你还好意思活着在那个地方，是要跳楼还是钻地…..
似乎是个鸡生蛋蛋生鸡的问题。
如果研发做的东西都是接近rubbish，找一堆很“精”的销售还真把这些东西卖出去了。
似乎这就是所谓的，一流销售，二流研发。
公司在前进，天要下雨，娘要嫁人，与我何干。。。继续写代码吧。。。
其实技术和市场是不同维度的东西，没法比。一定要比，就不得不选个比法，比如说要不得不选择和一个王八蛋打交道，你是选技术还是选人？
维度很简单嘛。比cash啦。
或者像11楼说的。地位啦。
似乎不用你说的那么抽象
都是多年的成年人，不想说得太直了，太直了就没意思了，要不你看看
那非常简单：要多少银子，看你下多大本钱，要比钱多地多，就别做RD
是RD泡妞多还是MKT
是RD一掷千金还是MKT
是RD皮薄还是MKT肉厚
是RD做人狠还是MKT做人狠
…
有志于此的青年，就别做RD，当然，别看MKT表面风光体面，手里金钱美酒，怀里环肥燕瘦，你得能承受后面的罪，受不了也别自讨苦吃
从来都是RD转MKT，还没有见过MKT转RD的人。人精就是不一样。还是要趁早认清方向。
跑题了跑题了
说软件战略研发效率呢
大公司大软件一定要有大师：架构大师和管理大师
系统技术架构决定了这个软件产品的技术生命力
平台和产品组织架构决定这个技术架构下组织的开发效能
越大越恐怖，但A/J也许是因为小，看起来要比C做得好些。
系统架构设计初始，经常是有较多的选择，tradeoff很难，大师的水平主要体现在这里（防患），其次才是以后的救火。错误的选择，一般在产品上市后3年内要做evolution时，就会发现当初犯的错误，一些大错误带来的影响很大，甚至很惨
to 理客：
呵呵，今天我和你一位同事聊了，听说了你的丰功伟绩，希望等你那天到上海，我能向你请教请教:)
吴兄太过誉了，我做事平平，说的比做得又多一点，还要向吴兄的实干多学习，有机会到上海的话，一定聚谈聚谈
to 理客：
呵呵，叫我小吴就可以，不用客气。
摩尔定律盛行的时代，更是有志不在年高。
一个总把对产品抱怨装在心里的销售，肯定做不好销售，销售可以面对研发的时候破口大骂，但在你大多数时间是销售的时候，你只把这个产品当作你眼里的情人
那可不，如果你自己都觉得这产品是东施，你咋去忽悠客户乜。。。
to kevin and 理客：
在这个方面，央视很优秀http://msn.ent.ynet.com/3.1/1102/05/5182083.html
想起一笑话，一老外到中国住酒店，七点钟打电话到前台说我电视坏了，换来换去只有一个台。
在这种情况下，客户只能闭上眼睛享受被rape的快感了。。。
你可以卖给喜欢Toshiba的:)
销售要掌握把自己作孩子亲妈的高超演技去卖东西，自己不把自家孩子当亲孩子，还能让别人幼吾幼以及人之幼？再丑的媳妇儿都有人要
假亦真来真亦假，无为有处有还无，其中的奥妙和火候是和人斗的精髓，个人道不同，不可道也不愿意道给别人，研发到市场，有慧根的一年就能转过这个弯来，不适合的人，3年还在原地打转，做基层研发念头太多的，出塔来看看有好处
恩。。。有意思
多谢指点