微博点滴整理(3)

思维，方法论和模式

经验说：一见钟情是因为他/她的面容、气质一下子牢牢攥住了我的心。 实验说：喜欢上一个人仅仅是因为他/她长得很像我们生命中重要的某人。

有教养的头脑的第一个标志就是善于提问。好问的人，只做了五分种的愚人；耻于发问的人，终身为愚人。

一个人经验的积累或解决问题的能力，不是其穷举式的定义和分析问题的能力，而是提出精准假设的能力。任何精准的假设都不是来源于理论知识，而是来源于我们已有的大量实践。实践后成功内化为自我的经验，而这些经验当自己使用的时候他们并不一定要显现化表达出来。

张洵谈到过大量知识是记不住的，所谓鱼和渔的关系。真正内化为一个人能力的是，他的思维、思想和价值观。思维方式和方法（know-why）远比具体的知识和技巧（know-how）更重要。思维决定一切，包括下意识和潜意识。我相当认同，思维力重要性远远大于单纯的记忆能力。

质疑和反思是行动学习的灵魂。行动学习，指通过一套完善的框架，保证团队成员能够在高效的解决实际存在的问题的过程中实现学习和发展。 质疑本身就来源于上一次实践后结果的输入，没有实践连质疑的点都提不出来。一定要避免自我理论盲目质疑他人实践。

思维之基础是解决问题，思维之升华是更好的解决问题，思维之创新是发现新问题。发现前人所没有发现的问题。因此没有意识到问题的存在远远比无法解决问题更加严重。前者掉入无目标而掉以轻心，后者则是有目标而问题驱动。

从最近分析和解决的几个问题总结如下 1.问题一来第一反应就是别人的问题而非自己的问题，是有害的。2.不注意问题的边界分析，或者开始就没有明确的边界。3.没有找到足够的定义清楚问题的基础数据就盲目去解决问题，导致走弯路。或许一两次能撞对，长期看是有害的。

预测是你如何从经验中学习，促使你发现什么是真理。当你观察任何新情况或事件时，以下两件事总有一件会出现：要么经验会满足你的预期，要么不会。当经验满足你的预期时，你的现实大脑模型保持不变。但当经验违反了你的预期，大脑必须更新现实模型以适应新信息。这是你从经验中学习并发现新真理的方法。其本质个人理解仍然是一个模式匹配的过程。

显然，我们的学习会促使短期记忆的产生，并且向长期记忆的转变；同时又有从具体或者叫具像记忆向逻辑记忆的转化过程。而一旦逻辑记忆被自己所发现和认识，并且使用语言可以固定化，再进行传递，那就是知识。

方法论是类，而最佳实践是对象。最佳实践是针对特定的问题，采用方法论中提到的特定方法工具技术的结合，是对方法论的一个实践验证。方法论最大的悲哀就 是，当我们没有实践经验的时候，我们拿着前人总结的方法论，并且没有全面的调查研究就到处宣讲，认为它可以解决所有的问题。就如我们虽然在客户面前穿了一 件华丽的外衣，但是很多时候客户并不认可反而碰得一鼻子灰。

方法论或模式一句核心的话是：针对特定的问题，在特定的环境，特定的人，特定的时间，应该用哪些特定的方法工具来解决。经验一般就是上次遇到某问题解决了，下次遇到类似问题就会了，模式是对经验的进一步总结和举一反三。

软件工程和信息化

软件开发的本质 可以归纳为以下三点： 1. 需求很难或者说无法沟通清楚， 2. 估算不可能精确， 3. 质量很难通过再开发流程中的质量活动来保证。针对这三点我的补充是1.需求是渐进的过程 2.估算要准确讲花费很大的代价 3.质量保证并不能达到质量控制需要的目标。

业务分析涉及：1.确定业务问题和商业机会 2.引导涉众的需要并分析制约因素 3.分析涉众的需要以定义解决方案的需求 4.分析和验证潜在和实际的解决方案 5.管理产品或者需求范围。而我对此看法关键是是业务建模和系统需求建模的分离，或者现在做需求根本就没有业务建模，直接进入到软件需求。

平台的基础服务能力包括两个层面，一个是纯粹技术方面的基础服务能力，包括日志，异常，消息，事务，国际化，缓存等内容。一个是业务抽象后和业务无关的技术能力，包括通用权限模型，通用流程模型，邮件短信组件，常用UI组件。业务平台和技术平台最大的不同是业务平台本身提供了开发多个产品都可复用的业务组件和业务能力。业务平台本身是对多个同类产品通用业务能力的抽取，提炼和下沉。因此多个业务平台可以共用技术平台，而只有相同业务类型的产品可以共用业务平台。

分析包括动态流程分析和静态的数据分析。而数据分析本身又静态和动态分析之分，静态关注数据层次，数据维度，数据之间的关联；动态分析关注数据时间趋势，随流程的转化和映射趋势等。

问题的外部动态线条：一个事物产生问题，经过了我们外部作用力，多个步骤或活动后产生问题，所以要做动态流程分析；内部动态线条：一个事物内部可以分解为多个相互作用的要素，要素之间相互作用和影响产生问题，所以要做内部静态分析。

软件开发里面过度数据量化确实是问题，很多时候我们考虑是我们的分析模型错了吗？其实分析模型本身并没有错，但是分析模型会忽略掉人是情感动物，其次分析模型采集的数据有问题，无法反应真实的情况。所以并不是说你有了分析模型就能得到正确的结果，DMAIC在分析之前还得有定义和测量。

BI的三个核心为数据模型，分析模型，展现模式。没有数据何来分析？没有分析和处理，再好的数据也没有用。最好好的呈现方式可以让别人更好的理解系统分析结果。分析模型在里面承上启下，价值将越来越重要，特别是细分到行业和业务领域的分析模型。

原来讲软件产品是满足需求，但是没有软件需求仍然可以通过其它方式满足。因此软件产品是从时间效率层面来转变需求达成的方式，一是及时获取有价值的信息，一是快速处理信息。而这正是涵盖了软件产品的本质，即信息接收，信息加工和处理，信息输出。信息产生价值，信息的获取效率提升价值。

流程分析和建模过程是由顶向下的，流程和服务构建的过程是由底向上的。功能域-》流程-》用例-》细粒度服务识别。用例到类概念模型，类概念模型形成功能组件，识别的服务形成服务组件。服务组件充当底层技术组件和功能组件的外观，类似facade模式。

对互联网产品，当我们仅仅谈市场和产品研发的时候并不能理解到强烈的闭环。市场+产品+运营则形成强力的闭环，而其中产品变为服务，运营其一考虑服务如何卖？其二考虑如何改进服务让它更好卖。

当程序员遇到问题的时候，他们会把这些问题重新定义，使得问题可以用算法来解决。这样一来，问题转化为他们可以解决的形式，但是程序员解决的只是问题的外在形式，而没有真正解决问题。这句话更加强调的重点还是在问题定义上对由于自我主观经验导致对问题本质的扭曲。

SOA两个方面的解耦，一个是业务需求和技术架构的解耦，一个是操作和数据的解耦。云计算也是解耦，业务系统和IT硬件的解耦，服务能力和物理设备的解耦。业务组件化和组件服务化，是对传统的信息系统分析方法提出的新要求。以后业务系统就是一个个提供服务的业务能力单元。

对于复杂系统一定要做产品本身的细分，推出一些面向不同用户群的子产品，而不是简单的期望交互设计和UCD解决复杂系统的用户体验问题。另外对于复杂系统前期学习时间带来的是后期高效率使用，做成傻瓜式反而可能是错误。

在过程的运行机制相当简单的情况下，典型的方法是采用预定义的(理论的)建模方式。当过程的复杂程度超过了预定义的能力范围，经验性的方式是最合适的选择。-《过程动态、建模和控制》

建模和编程的本质区别？建模是抽象化和形式化方法对现实世界的描述，而编程是对针对建模的一个实现过程。建模的重点是抽象，是对现实世界和软件世界之间核心的衔接桥梁。不管是纯粹的业务建模，还是软件产品中的系统设计建模，其核心都是有效的承上启下。

个人自我管理

一个合格的项目经理最重要的能力是平衡。一个优秀项目经理最重要能力是在达到项目目标的同时培养了一个有战斗力的团队，即时在承受领导压力时候也能够进行好团队核心能力的铸造。为何如此强调团队的原因更加在于项目经理不能简单的看一个项目的成败，而是长期来看多个项目的总体绩效。从这个意义上来说，为了一个项目得失如果损失掉整个团队，这种平衡显然是不值得的。要知道一个成功团的打造和磨合时间远远长于一个项目。

敏捷个人的价值在于，要是原来没有合作过得一群人凑到一起，那先学习敏捷个人培养共同价值观和文化，这是自下而上的敏捷团队形成过程。要是本身已经有一个高度自治团队，再进来人，那就是由上而下，新人直接在实践中融入，要相信团队已有合力的影响力是巨大的。

平凡可以铸就伟大，但是很多时候没有经过是风雨洗礼的平凡往往更多的则是一种平庸，因为他们没有经过考验而陷入一种自我满足。我们不一定能够伟大，但是却一定要拒绝平庸。

镜子虽因外物而显现不同的形象，但却不会改变本身玻璃的本质。人 要修身养心保持一颗简单的赤子之心，需要在这虚幻的浮华世界背后着重守住一颗真实的心灵。人，可以如镜子一样适应这世界多变的万事万物，但人也可如镜子一 般保持自己简单纯真的本质。

很久没思考过心智的问题，回头看五项修炼，越发感觉心智模式的改善绝对是团队学习，系统思考之基础之基础。心智模式一个是内观自我，一个是外观事物，而很多时候忽略的就是内观自我。

德鲁克谈管理的五要素 1. 设定目标 2.确定组织机构和流程 3.激励和沟通 4.设定绩效衡量标准 5.培养人包括自己。而在这五点里面最重要的又是目标和团队，辅助以流程绩效评估的度量体系。