Category: 管理智慧

Flag一月小结：

Flag1：读书1本。

本月终于读完丹尼尔•卡尼曼的《思考•快与慢》，4星评价：“拖拖拉拉啃了几个月终于啃完，文字非常乏味，几乎是一部社会心理学学术著作，但内容极尽详实，大量实验数据和推论揭示了随处可见的人类认知谬误的根源。我们的认知系统划分为两个部分：“系统1”反应快速、依赖直觉，几乎不需要努力就能完成任务，但常常带来错误结论；而“系统2”则懒惰，工作起来需要集中注意力，但理性、精确。理性思考，向来不易。”

Flag2：观影2部。

《芝加哥七君子审判》，豆瓣8.6，我打5星：“政治审批，呵呵，美式民主”。第二部是《曼达洛人第二季》，豆瓣9.5，元旦追完，this is the way. 评价颇高的《心灵奇旅》我反而感觉一般，可能是审美疲劳和鸡汤厌倦了。

Flag3：博客2篇。

连这篇，正好两篇。

Flag4：微信不超过2条。

共3条，其中一条是孩子老师要求转发的。

结论：一月Flag目标达成，再接再厉。

-=~-=~-=~-=~华丽的分割线-=~-=~-=~-=~

一月都忙于2020的年终总结，各种数据汇集、分析，一半的时间在会议室。忙忙碌碌转瞬即逝的一月，我们到底收获了什么？企业这样发展是否就能达到未来我们期望的样子？这世间最迷人最可怕的是未来不可预期，时间不可逆转，你只有一次机会。我们是否行进在“正确”的道路上？

昨晚午夜梦回，构思了这个模型：

企业能否持续健康发展，应该是市场水平、技术水平和管理水平并行发展，缺一不可。市场水平是挣钱的能力，技术水平是持续竞争力的保障，管理水平是可预期的不犯错的能力。只有市场水平，是皮包公司。只有技术水平，是草创团队或科研小组。只有管理水平，好像不存在这种呃。有市场水平和技术水平而缺管理水平，是有核心技术、核心市场的小企业成长到大企业的必经阶段，需要引进高水平管理人才和管理体系才能加速成长，就像当年华为引入IBM的IPD和ISC进行核心业务流程变革。有技术水平和管理水平而缺市场水平，常常是技术派学院派起家的企业，在市场搏杀中缺乏商业关系和销售精英的结果，有技术懂管理的海归博士创业铩羽而归的数不胜数。最后，有市场水平和管理水平而缺技术水平的公司，要想突破瓶颈反倒可能是最难的，因为核心技术不是一朝一夕练就的，就算是舶来品也需要有技术专家能够消化吸收为我所用，谈何容易。君不见武汉弘芯血淋淋的例子？

那么，我们属于哪种类型？相对来说，市场水平较高，当然“较高”也是局限在老总身上，而销售团队还缺乏独当一面的人才。管理水平和技术水平较弱，说不出哪一个更弱。但是从能力建设来讲，技术能力的建设更加任重道远，需要管理层坚定不移的投入。

不论哪一种水平提升，都离不开核心人才。我们，显然还缺乏三类核心人才。

路漫漫……

首先声明，本文非严谨学术论文，无数据分析，无实例支撑，基本只有假设，尤其后半段，包括那张图。目的只是素描一个粗糙的想法，因为，人老了，不记下来就会忘掉。

言归正传。通常生产率(Productivity)可以定义为单位时间内生产的产品数量。在软件开发领域“产品数量”难以找到像螺钉、纽扣一般明确的计件单位，所以软件生产率多以代码行或功能点的数量进行计算。而功能点的定义通常又比较含糊，不同软件产品、不同团队对于功能点的定义都不尽相同。所以代码行几乎是大部分软件企业衡量生产率的唯一标准：Productivity=LOC(Line of Code)/Effort。对这个定义，有两种解读：一，相同时间内（让我们暂且归一化resource，所以时间就是Effort）写的代码行越多则生产率越高；二，完成相同代码行花的时间越少则生产率越高。第二种解读可以理解为编程高手、熟手，基本没错。第一种解读却隐含了另外一个没有明说的假设条件：相同的代码质量。而这个假设条件非常重要，否则，哪怕能够实现同样的功能，我也可以堆砌出一大堆没用的代码。注意这些代码并不是“废品”（“废品”就是bug了），而是“低效”的代码。

这又不得不谈到代码的“效率”问题。那么是否完成相同功能、没有bug的代码，行数越多就“效率”越高呢？让我们先分解一下这个“效率”。我理解代码的“效率”应该包含三个方面：一，代码的片段运行效率，比如算法的选择，内存利用，I/O操作等等；二，代码的整体结构效率，比如函数的定义，头文件的选取，软件架构设计，设计模式的运用等等；三，代码的维护效率，主要指代码的可读性，别人是否很容易接手你的代码。

代码的片段运行效率，事实上跟代码行的多少没有太直接的关系。因为算法的优劣并不等价于代码的多寡。代码的多寡也不能决定内存、寄存器、堆栈、I/O是否有效利用。有时候过于精简的代码反而耗费更长的机器时间。当然过于冗长的代码是一定会降低运行效率的。我无法找到一个准确的曲线来表示代码行和运行效率的关系，也许每个软件都有不同的曲线，也许压根就无法用简单单变量函数表示出来。但大体上，应该还是个概率分布如泊松分布之类的。对于代码的整体结构效率，大体还是有原则可循的，过于精简的结构和过于冗长的结构都会降低程序效率，所以，这是否意味着它还是一个类似泊松分布呢？而对于代码的可维护性，相信大多数程序员都深有体会，一行代码完成过多功能只能让读者不解，而为了某些目的弃简就繁的写法也会让读者头晕。呃，所以，貌似这还是一个类似泊松分布。我当然还是无法确定这三个分解因素在构成“有效”代码时的权重，所以，那就还是假设一条综合泊松曲线得了，如下图黑线所示：这就明显了，随着代码行的增加，总会有那么个时候软件的效率开始降低从而我们所希望衡量的有效生产率开始降低。其实想个极端的例子：A同学完成一个功能用了一整天，但他这一整天中其实只写了50行代码，但算法恰当，逻辑清晰，结构合理，可读性强；B同学也用一天时间完成同样功能，但洋洋洒洒写了500行——因为重复了若干遍本可以抽象出来的函数。B同学的生产率是A同学的10倍，但B同学写的却是烂程序（当然，也许B同学也不是故意的）。如果简单以这样的生产率作为激励标准，那么显然对于A同学是不公平的。而我们希望更多的像A同学这样的程序员。

可惜的是，那个代表最佳代码行的G点真的很难找到啊。

软件工厂、软件蓝领这样的术语在中国已经念叨了十余年了，除了北大青鸟、托普软件、重庆正大这样的软件学院还在沿着这个思路继续培养软件蓝领之外，真正做软件产品的公司，能做到将软件研发像制造业的流水线一样分工的有几个？没有！

几年前公司内也有人尝试软件分层研发模式：需求管理是一拨人，设计是一拨人，编码是另一拨人，测试当然还有一拨人。结果不了了之。

前些天看亚当斯密的《国富论》中关于劳动分工的阐述，茅塞顿开。亚当斯密说：“分工使得相同数量的劳动者能够完成比分工之前多得多的工作量，其原因有三：第一，劳动者的熟练程度因分工而提高；第二，工作之间因连接交换而损失的时间减少；第三，机械的发明为劳动提供了便利，简化了工作，劳动者的工作量随之极大提升。”而这，恰恰是软件工厂和软件蓝领热衷者的理论基础。

亚当斯密其实没有说错，因为亚当斯密关于劳动分工的所有论述都有一个明确的前提：制造业。而在亚当斯密生活的十八世纪，还没有出现软件这个产业。用在软件研发上，这三点理由有两点半都是不成立的！

第一，劳动者的熟练程度因分工而提高。如果是制造业，无疑这是正确的，因为你制造的对象是单一的，可重复的，基本无变化的，于是熟能生巧。软件研发却不是这样。世界上没有两个软件是一模一样的，一样的只有廉价的拷贝，研发过程却永远是唯一的。现代项目管理认为“项目”是一个组织为实现既定的目标，在一定的时间、人员和其它资源的约束条件下，所开展的一种有一定独特性的、一次性的工作。由于目标不单一、不可重复，就算将研发分层，各层所做工作也不可能单一和重复。就像软件项目的产出，都是独特的、唯一的软件产品。没有哪个组织哪个公司愿意花钱生产已经能从市场上找到并且满足需求的软件。至于模块化生产这样的理想，MDA这样的理论，在没有出现明确的大规模应用之前，都是浮云。

第二，工作之间因连接交换而损失的时间减少。这是“精益”管理（LEAN、JIT）中的要点之一，但还是只适用于制造业。软件研发是彻底的脑力劳动，“生产线”上的是代码，无形的代码，蕴含着无数逻辑、判断、需求关系、依赖关系的代码，你永远不知道上游会交给你个什么东西。通常情况下，软件工作之间的交换包括从需求到设计，从设计到编码，从编码到测试。试想一下完全分工研发，设计人员拿到需求说明书之后就能立即开始设计吗？不能，要首先消化、吸收和理解，要和需求人员反反复复沟通。这就是连接交换时间，无法减少。设计人员做出设计交给编码人员，编码人员能立即开始编码吗？不能，还是要先消化、吸收和理解，要和设计人员反反复复沟通。这也是连接交换时间，无法减少。同样的，测试人员如果拿到需求就开始测试，一定会出现很多漏测或误报。为什么无法减少这些消化、吸收和理解时间呢？根本原因还是跟上面一样：每个软件都是不一样的。Facebook够高效吧，因为他们人人都既做需求，又做设计，又做编码，还做测试（看这篇文章）。在软件研发行业，越细的分工，效率反而越低，因为连接交换时间反而因为分工的细化而加大。

第三，机械的发明为劳动提供了便利，简化了工作，劳动者的工作量随之极大提升。亚当斯密认为，正是因为分工让人们的注意力更专注于一个目标，才能产生更多的提高效率的方法。事实上对这点我最多同意一半。分工确实能让人更专注，但是否就因此能产生更多的提高效率的方法却因人而异。聪明人哪怕做一次也能找到更好的方法。安于现状的人一辈子就干一件事也不见得能有所创新。专注于一个目标可能造成思维更狭隘和局限，对各层次都了解也许能触类旁通、相得益彰。现在不都流行跨学科人才培养吗？从我们公司的十年创新历史看，创新多的总是那一小部分人，不论他们做什么。当然了，这也是个概率问题，不知道有没有专家做过更权威的统计，所以对这点我同意一半。

有人肯定会提到印度，软件外包、软件工厂的第一大国。不过你有没有听说过哪个著名软件是印度公司做的？哦对了，他们只做外包。那么有没有研究表明他们的效率就很高呢？我看绝大多数报道都只强调他们的规模大，效率嘛，不知道。

抛开效率问题，软件工厂、软件蓝领还是有用的，但也局限在严格执行CMMI之类软件工程规范的外包公司。但要发展软件产业，绝不能仅仅依靠软件外包，毕竟，软件外包是软件业的下游产业。

软件的质量到底意味着什么？我们从来都是靠SQAP中定义的几个metrics来度量，比如DTRC，SRE，Virtual Zero，等等。满足这些指标后，软件就可以发布给用户了。这不是问题，因为软件总是需要度量。问题是，为什么这些指标对于我们所有的产品线、对于全球所有地区的客户总是一成不变？这样的指标是否代表了客户需求？还是仅仅是工程师团队对质量问题孤立认识的简单结果？我们有许多产品线，投入了巨大的测试成本，投入市场后却多年没有见到意想中的客户反馈的问题。难道是我们的产品完美无缺了？显然不是，上百万行代码的软件产品几乎做不到零缺陷。如果客户不能发现问题，是否意味着我们的软件质量有可能已经Over Quality了？将那部分Over Quality的资源用在别的更需要资源的地方，岂不是对公司、对客户都是好事？

遗憾的是目前为止我还没有见到研究Over Quality的资料，因为Quality是红线。我们所有的教义都强调质量第一，不成文的规则指导人们尽量减少质量风险。一旦形成习惯，就再没人思考Why。为什么我们不能依照客户对于质量的认识来定义产品的质量要求而不是盲目地追求质量呢？我们都在强调满足客户对软件功能的需求，为什么不能从客户感受出发满足客户对质量的真实需求呢？琢磨了下，也许可以用这个模型：横坐标Staff.Month代表测试资源的投入，纵坐标Q代表质量，或者潜在缺陷（Latent Defect）被发现的比例。蓝线（E）代表工程师团队投入测试资源后软件质量的上升，可以理解为SRE（Software Reliability Engineering）。红线（C）代表客户满意度，可以理解为随着客户使用软件的增加，能发现软件中潜在缺陷的可能性。当E和C相交时，意味着工程师和客户共同发现了所有缺陷。E和C可能永远不相交吗？其实只要调整E和C各自的横坐标比例，E和C应该总是会相交的。我们总是试图提高a到u，对客户来说当然是好事，可是测试资源的投入将从A上升到U，这真的划算吗？也许客户觉得l的质量就不错了，我们是否就可以相应只投入L的测试资源？我们也许可以考虑一些安全区间，比如比客户期望高出5%的质量要求，像这样：客户要求u，我们要求u’（= u * 105%），客户要求l，我们要求l’（= l * 105%）。相应投入测试资源为U’和L’。

这个模型的难点在于如何建立准确的客户满意度的数学模型。说难也不难，我们在几乎所有产品线上，都有若干年积累起来的客户相关数据，包括客户发现的缺陷和客户对产品满意度的调查报告。这些也许足够建立一个相对准确的数学模型并且协助我们设定客户期望的Q了，进而指导我们安排合理的测试资源。

这里当然还有很多细节问题，比如SRE不适合自动测试，影响C的除了使用时间和用户数量之外，肯定还有别的因素，等等。不过，模型总是可以从简单到复杂，最重要的是模型背后的逻辑。而这，恐怕也是目前公司无法突破的现实。

继前不久摩托罗拉宣布将在明年一季度分拆手机部为“Motorola Mobility”独立公司，刚刚又宣布年底前以12亿美元将网络部出售给诺西。EMS（Enterprise Mobility Solutions）部门将成为“Motorola Solutions”公司唯一的业务部门。这对于我们身处每年盈利却因为其它部门亏损而无法得到回报的EMS部门来说，绝对是重大利好。比如我们看看今年一季度的财报：2010年摩托罗拉一季度销售额为50亿美元，其中EMS部门销售额17亿美元，运营收益1.41亿美元，手机部销售额16亿美元，亏损1.92亿美元，网络部销售额8.96亿美元，运营收益1.12亿美元，家庭宽带业务销售额8.38亿美元，运营收益2000万美元。人尽皆知手机部在V3之后就连年亏损，而网络部因为在3G战略上的失误和在LTE、WiMAX之间摇摆一直未能走出困境。所以EMS是支撑摩托罗拉度过这几年艰难时期的核心业务部门。

各个业务部门的拆分也意味着摩托罗拉不再坚持大而全的战略，而是更加专注于一个最擅长的领域。EMS部门的核心业务就是专业对讲机，而专业对讲机正是摩托罗拉从二战时就开始并一直坚持的核心业务，几十年来一直雄居该领域的龙头老大位置。因为专业对讲机的行业属性而不为一般消费者所认知，比如公安、消防、石油、城市应急、调度、林业等。

兼并容易拆分难。就像长胖容易瘦身难。更难的是，企业在长期发展战略中的专注和执着。业界因为专注和执着而成功的例子太多，比如Intel、微软和苹果。也有太多反例，比如联想、海尔、四通和实达（找中国的例子最容易）。再次瘦身，也许是摩托罗拉这几年做的最正确的事情了。

最近研究关键链理论(TOC)，里面提到的两种管理原则-成本世界和有效产出世界，是否真的是完全对立？是否关键链理论对于有型的生产制造业更适用？对于软件类企业如何衡量“存货”的积累？为什么会有“学生症候群”和“帕金森症”？关键链的实施对于员工心理的影响有没有完整的评估？关键链是否是经理的杀手锏而是员工的噩梦？Tell me how you measure me and I will tell you how I will behave. If you measure me in an illogical way… do not complain about illogical behavior. 告诉我你是怎样衡量我的，我就会告诉你我会怎样行事。

Cause-Effect Matrix是项目管理或6 Sigma管理中常用的一个工具，解释为：A tool that can help with the prioritization of Key Input and Process Indicators (X’s) by evaluating the strength of their relationship to Output Indicators (Y’s). 意思就是如果某个事情的结果是由多个原因导致的，那么这个工具可以通过评估各个原因指标(X”s)对于结果指标(Y”s)的权重关系而帮助你对这些原因指标进行优先级排序。从而指导相应的行动计划。

生活中有时一团乱麻，多种烦恼纠缠在一起，不知道到底该忙哪个，似乎个个都很重要。但显然并不是所有的事情都是一样重要的。用这个工具或许能帮助我们理清思路。

前天偶然发现电脑上的一份文档，是3年前为LP那段忙碌时期做的分析，正好就是用了Cause-Effect Matrix：

#	项目(X)	成功影响	失败影响	重要度	成功可能性	优先权重	当前优先级		行动计划
1	工作	收入	收入，面子，精神压力	29	10	290	3	M	更聪明、高效地工作；加强和头的沟通
2	在职学位	职称、工作、转行	工作，面子，精神压力	37	8	296	2	M	跟随课程，认真准备
3	论文	职称	职称，面子，精神压力，工作	33	2	66	5	L	安排写作日程
4	锻炼	身体、小孩	身体、小孩	34	7	238	4	M	目前坚持每周一次；买辆自行车
5	日常生活	身体、小孩、工作、学习	身体、小孩、工作、学习	66	7	462	1	H	11:30pm以前上床睡觉；坚持吃药片和酸奶
6	小孩	精神压力（工作，学习，收入）	舆论压力，精神缺失	13	5	65	6	L	积极调理

重要度=成功影响+失败影响（见下表），优先权重=重要度×成功可能性，当前优先级按照优先权重排序。下面是量化的成功或失败影响因子，当然是自己心目中的分量：

影响元素(Y)	比重
收入	8
面子	7
精神压力	6
职称	6
工作	8
转行	2
身体	10
小孩	7
学习	8
舆论压力	2
精神缺失	5

结果就很清楚了，保证有规律的日常生活仍然是所有事情中最重要的，然后是拿到学位，工作等等（要小孩被排到了最后！）3年后的今天再看LP这些X，日常生活很有规律，学位已经拿到，工作没有问题，论文都已发表，连小孩都1岁多了！只有锻炼因为带小孩原因没能坚持。

其实我这个Matrix比起标准的还是有些变化的。附上标准的格式：

Moto无疑正在经历寒冬，也许是她80年来最寒冷的一个冬天。春节过后的望京园区一片萧杀，近千人被layoff。但是，萧杀仅仅发生在MD。看看我们的EMS，似乎根本感觉不到一点寒冷。也难怪，在MD的Q4营运利率亏损25.3%的情况下，EMS的Q4还能有21%的增长。可是，居安思危，未雨绸缪，EMS是否可以永远乐观？

EMS的业务与MD当然有很大的不同。MD造手机，已经属于快速消费品，在Moto老迈官僚的慢节奏下难以同其它新兴公司竞争。输掉不足为怪。所谓缺乏创新，其实也只是这种慢节奏的一个表现而已。John Kotter说过，企业的经营业绩其实不过是企业文化的一种表现。所以，从根本上，Moto应该检视自己一直以来引以为豪的企业文化了。

Moto的文化其实大部分都很好，不然不会活了80岁还基本上都是业界领先。她对顾客、对员工的尊重，对产品质量的追求，鼓励创新等等，都是很好的文化要素。问题出在，速度！21世纪已经是互联网的世纪，世界已经变平，但是Moto似乎还习惯于上世纪八九十年代的速度。Moto对客户投诉非常重视，可是响应速度，很慢；也在不断进行内部流程改造，但是速度，很慢；也在不断开发新产品，但是速度，很慢；领导们天天都在开会讨论问题，但是决策，很慢。公司大了，机构庞杂了，流程复杂了，有关没关的人都要开会、审批，速度不慢才怪！

2009年新年伊始，又有众多的Scorecard压下来。就EMS内一个Division，就有24个Scorecard，大而全。但是其中没有一个是针对机构、流程与决策速度做改进的。治标不治本。

EMS目前还穿得暖暖的，还感觉不到冬天的寒冷，还在闲庭信步。可是也许有一天当衣服被对手无情地撕去，冬天更加寒冷时，就只能加快步伐甚至奔跑才能度过寒冬了。

我有中国银行借记卡一张、信用卡一张，希望能通过网银手动从借记卡还款到信用卡。这个功能很常见，相信招行、工行、建行的用户都能实现。于是我兴冲冲开始了一个噩梦之旅。

首先到中行柜台办了借记卡网银业务，拿到一个动态口令牌。问小姐如何关联信用卡，答曰从网上直接关联。回家后从中行首页“登录新版网上银行”进入，一切顺利，能管理借记卡了。但是根本没有地方进行信用卡关联。在打过3个不同的800或400中行咨询电话后终于闹明白必须到柜台办理管理。我#@￥%！

隔段时间又到中行柜台关联信用卡，小姐说不能关联，斩钉截铁就是不能！@#￥×（！

回来后继续电话、上网站查，应该能啊！又去，这回小姐说她们从来没关联成功过，原因不详。但是愿意试一试，只是必须让我带上动态口令牌。啊，没带！@#%￥&×！

第二天老实带上动态口令牌继续拜访中行，小姐倒腾了半天，也没问我要口令牌就说还是不行，不过这回给了理由：我的借记卡是新身份证办理的，信用卡是老身份证办理的，位数不匹配，所以系统认为这两张卡是俩不同的主，不能关联！……%￥#@×！

这回我彻底服了，中国银行作为国内银行的老大，不仅是几大银行中最晚推出网银的（今年才有真正意义上的网银，而我99年就用招行一网通网购图书了！），营业员业务是最不熟的，网银系统也是做得最烂的，连个新旧身份证匹配都没做。从软件开发流程来看，犯了以下若干错误：

1，需求缺陷。显然开发人员没有通过Use Case详尽分析各种用户使用情况（Scenarios），遗漏掉同一用户可能使用新、旧身份证办理不同卡的情况。这是错误的开始。
2，设计阶段严重失误。就算需求遗漏了，任何一个系统设计人员在设计关联时，如果需要比较身份证是否匹配，就应该想到身份证有新、旧之分即长度之分。这是常识啊，地球人都知道。所以我只能想像设计人员考虑到了但是因为觉得既然需求没写，就可以不管。其实这在软件开发中，属于非功能性需求或隐含需求，没有写出来也需要实现。当然最好写出来。总之错误流传了下去。
3，代码阶段严重失误。就算需求和设计都遗漏了，任何一个代码开发人员在定义身份证变量时，首先就应该考虑长度问题，同样，常识啊。所以我只能想像代码开发人员考虑到了但是因为觉得既然设计没写，就可以不管。由于代码开发人员的疏忽或失职让错误继续前进。
4，功能测试不足。对于复杂系统，仅仅依据需求说明书进行测试还远远不够。Monkey Test或Expert Test都能发现一些交互的、隐藏得很深的、需求说明书不能完全覆盖的问题。显然由于没有足够的功能测试，这个错误再次向用户逼近。
5，Beta测试没有或无效。所谓Beta测试就是在系统正式发布前让部分最终用户先行体验，进而发现问题并及时修改。Beta测试不是软件开发必须的，但是对于复杂系统是强烈推荐的。所以，我严重怀疑中行网银没有进行Beta测试，就算有，也无效，因为没有发现这个严重问题。Beta测试几乎是软件面对用户前的最后一道关口，没有Beta测试或无效的Beta测试最终让问题暴露在用户面前。

如果中行在网银开发的上述5个流程中任何一个发现并报告这个问题，并及时修正，就不会让我如此郁闷（想必还有不少用户有同样的遭遇）。可惜的是没有一个环节堵住了这个问题。要么是流程还有漏洞，要么是执行者（开发设计人员）缺乏经验或责任心，毕竟，再好的流程都是人在执行。

更可怕的是，从我发现问题到现在又过了快两月了，问题依旧。所以，我郑重决定，从此不用中行卡。

10月30日摩托罗拉公布了今年第三季度财报，总体亏损4.52亿美元（有些媒体报道亏损为3.97亿，其实那是刨除了很多一次性支出-Excluding Highlighted Items），其中手机部（MD）亏损就达到8.4亿美元，彻底拉下企业移动解决方案部（EMS）和宽带及移动网络事业部（HNM）总共挣到的6.66亿美元。所以，手机部的噩梦还在继续。从高通来的CEO Sanjay Jha在手机部的townhall上沉痛宣布裁员以节省开支。同时宣布推迟原定的2009年第三季度完成手机部拆分的计划。因为当前的金融危机显然不能提供良好的市场环境，也就不能满足股东的利益需求。情理之中。

此前我有篇文章摩托罗拉（手机业务）衰落原因之我见分析手机部问题的原因包括：

1，产品线：新产品太少，靠V3系列打天下，缺乏创新。
2，市场重心：亚洲在最近几年和将来的很长一段时间都会是全球最大的手机市场，但是摩托罗拉似乎对亚洲一直漫不经心。
3，营销策略：降价太快，成了降价王和街机，丢失了利润和用户忠诚度。
4，重点产品：受V3成功的拖累，没有在本是领导地位的PDA上全力耕耘，丢掉了高端商用客户，而这本是摩托罗拉的一面旗帜。
5，功能设计：界面操作缺乏人性化，有些功能操作繁琐。
6，软件一致性：在用户界面设计上缺乏一致，在平台选择上也辗转反侧。

现在，我们终于欣喜的看到Sanjay展示了一系列改革措施：

1，首先是平台整合，重新对芯片、操作系统和用户界面进行了筛选和组合。目前摩托的手机芯片采用了包括高通、德州仪器和飞思卡尔的9种，整合后只有高通和德州仪器的4种。目前的操作系统包括Linux Java、AJAR、P2K、Symbian、Windows Mobile等9种，整合后只保留Windows Mobile、Android、BREW和P2K共4种。用户界面设计也从目前的9种整合到5种。整合前的芯片、操作系统和用户界面的组合共24种，整合后只有8种。很显然，这样的整合是我们期待已久的，它能直接解决上面提到的问题6，也能一定程度帮助解决问题1（平台少，研发周期就短，新产品推出就快）、问题4（整合平台后可以有足够精力耕耘高端产品）和问题5（整合界面后可以有足够精力对用户界面和功能进行系统性优化）。
2，组织架构大幅调整，重组为三个团队：产品线管理、研发和业务。其中业务部门分为四个大区：北美、拉美、欧非亚，以及大中国区。这意味着中国区可以绕过以前的亚太区而直接同美国总部沟通了；中国的市场地位再次提升。这也是对问题2的较好解决。
3，重新定义目标优先级，利润（Profits）重新回到了优先级金字塔的顶端。这显然直接针对问题3。

Sanjay同时还强调了摩托罗拉产品要做到的4个品质：由创新带来的差异化，加快产品上市周期，降低成本以及提高质量。当然这些也是历任CEO都强调的。

总体来看，这些改革措施基本上是对症下药了。当然我们还希望看到更多具体的措施，尤其是针对问题1，4，5的措施。考虑到当前横扫全球的金融危机和可能继续恶化的2009年经济环境，摩托罗拉手机部要真的扭亏为盈还尚需时日。我乐观的估计，也要到2011年甚至更后了。至于能否重夺市场第一，其实已经不重要了。准确的说，重夺市场第一，只能是赢利后的自然结果，而非公司的直接目标。