个人2006年博客文章总结和整理

　　注：临近过年假期，准备在假期阶段不再写新的技术类文章，而是对自己15年来的博客文章按年为单位做下总结和整理。按新浪博客当前记录是4229篇博客文章，其中3000篇以上的个人原创文章，接近4年的博客日更写作。
　　你的灯亮着吗？
　　对于专谈问题的书，在2006年阅读了《你的灯亮着吗？》，这本书是著名思想家温伯格（其著作还有系统思维导论，程序员开发心理学）的一本定义分析和解决问题的书籍。全书分六篇由20个寓意深刻的小故事组成，讲述层次仍然遵循定义描述问题》分析问题》解决问题的思路，故事中穿插了诸多的最佳实践和案例供大家参考。
　　读一本书就能够学会如何解决问题是不可能的，所以该书也不是按部就班地教你如何解决问题，更多的我觉得应该是大家通过阅读该书有所思，有所悟，最终形成自己的分析和解决问题的方法论。
　　比如在这篇里面给出的对问题的定义，即问题是你期望和和你体验间的差别，要分析和解决问题时候首先需要搞清楚什么是真正的问题，问题从哪里来是谁的问题等内容。在工作和生活中常犯的毛病是扭曲问题定义，自己人为地去解释和翻译问题从而导致把问题的解决方法作为问题的定义。从而导致后续一连串的错误。
　　对于分析和思考问题，则是需要搞清楚问题的来源，是谁的问题，导致问题的真正根源是什么，原来是否遇到过类似问题等内容。分析和思考问题是否全面直接影响到后续问题的解决。本书给出的几个重要Tips是：A。如果你找不出三处可能出错的地方，说明你没有真正理解问题
　　B。不要轻易给问题下结论，也不要忽略你的第一印象
　　解决问题是最后一步，建立在分析问题基础上，解决问题有多条途径，如果通过各种约束条件选择最佳的途径来解决问题是需要考虑的重要因素。比如书里面提的当别人能够解决问题的时候千万不要越俎代庖，而应该引导他人思考和自己解决；再比如一个一个小小的提醒往往比复杂的解决问题方法更有效，也就是这本书的书名，车出隧道后提醒司机关闭车灯应该如何提示才最简洁有效。
　　高效能人士的7个习惯
　　我个人写过很多的关于个人知识管理，自我管理，自律，个人计划和行动等方面的文章。但是你会发现很多内容都能够在这本书里面找到影子。也就是说这本书里面的7个习惯是可以伴随一个人终身进行自我学习，持续改进和实践的，单单一个积极主动要做好都很难。
　　虽然在06年就在读这本书，但是感觉在最近2到3年很多内容才真正实践到位，通过实践去理解里面的内容，比如以终结为识的深刻道理。
　　这本书给我的几个关键启发点，简单来讲即：
　　其一你要形成个人做事情的原则，比如公正，诚信，守时，尊重他人，履行诺言都是应该遵守的原则。这个原则要长期坚持，不要因为你面对的外在环境或人轻易改变，真正做到表里如一，做到慎独。
　　其二是关注圈和影响圈，你的目标是扩大自己的影响圈缩小自己的关注圈。多去影响他人而不是经常被他人影响。你是主动的去工作和生活，而不是被动的去接受。
　　其三就是发展的三个阶段，独立期只是中间阶段，更加重要的是互赖期的合作共赢，这个需要走出去，打破自我边界，以一种开放的心态面对外在。
　　IT人员的知识体系架构
　　这个是我在2006年整理的IT人员的个人知识体系结构，在这个之后又相继整理了IT咨询人员，需求人员，项目管理人员的知识体系结构。
　　为何整体这个？
　　简单来说即当你在一个业务领域或岗位呆太久后你会发现没有啥新东西可以学习，陷入一种重复机械式的工作阶段而无法自我提升，而整理知识结构的重点就是真正看清楚整个知识体系完整框架，并清楚你当前的位置在哪里。
　　如果你不知道去哪里，给你一张地图也没有用。
　　知识体系结构比较好的地方就是可以结合当前自己的知识技能，个人的成长期望和目标来制定进一步的学习路线，持续改进。
　　像青蛙一样思考
　　首先不应该简单地把该书归类为厚黑学类的书籍，更多的是教会我们认清国内企业文化，在企业特有潜规则下学会做人和做事情。
　　全书一开始就列举出了企业内部常见的十大泥潭，使我们经常绞尽脑汁的面临两难抉择，每个人都希望自己拥有敏锐的思维解决和避开以上现象。个人的智商是认清企业的显性规则；而个人的情商确实帮助我们发现和解析企业的潜规则，而更好地去利用这些潜规则。
　　小恐龙的迷惑：刚踏出象牙塔走上工作岗位的所有毕业生，都是满腹经纶，满怀抱负，自认为自己有先进的理论武装自己，才高八斗，希望在工作中一展鸿图，一到公司后敢说敢做，脑子里面有说不完的新想法和新思路，但却不能被人重视和采纳。自己也在多次受挫后丧失了对工作的兴趣和热情。在恰当的时候说恰当的话，做正确的事情而不是正确的做事，这些可能更是我们该学习的。
　　模仿永远只是外在的，核心的精神是无法模仿的。企业文化不是无源之水，无根之木，它根植于现实的土壤，并受现实的力量所左右。在一杯脏水中不可能倒出一杯清水，只有学会了在泥潭中生存，才能够真正突破泥潭的桎梏。
　　先进的管理学思想得以长驱直入，而在运作层面却遭遇到软性的抵抗，这与我们的泥潭文化有着重要的关系。就如同ERP，CRM在企业实施中遭遇到的空气阻力，本来提高效率的管理工具却转变为了企业的形象工程。
　　崇尚权利，否定个体，缺乏诚信，贪功和拉帮结派是泥潭文化中典型的负面因素。我们经常被这些负面因素困扰而不快乐，存在即合理，因此不应该去逃避这些负面因素，而是如何去应对这些负面因素，又能够不违背自己的准则和价值观。
　　功能点估算原理和案例
　　在06年的5月我整理了功能点估算原理和案例的两篇文章。对于功能点估算当时详细说明估算原理和过程的文章很少，因此这两篇文章后面阅读量都比较大。
　　FunctionPointEstimation功能点估算是一种用来估算项目大小的技术。功能点是对软件功能和规模的间接定量测量，它基于客观的外部应用接口和主观的内部应用复杂度以及总体的性能特征。
　　功能点法和专家法估算最大的不同点在于对估算规模的细化的定量分析上面我们在用专家法估算的时候往往会直接去估算工作量，或在规模的估算中掺杂了生产率的数据，导致估算数据出现问题专家法估算虽然有时候也很准确，但不能提升为组织级可以参考和借鉴的同样规则其实专家法的估算要做准确也是遵循了功能点法估算的思路，在考虑一个软件功能究竟涉及到哪些操作，涉及到多少数据文件的存在，每个操作需要访问哪些数据文件等相关问题只是这些想法停留在专家头脑里面而没有量化出来。
　　功能点法进行估算的时候具体过程是：1。对估算功能单元的类型进行识别
　　2。计算每种类型的复杂度
　　3。计算总体的调整前的功能点数
　　4。根据调整因子对功能点数进行调整
　　当前真正应用功能点估算的很少，而实际在我们后续的项目基本也是基于功能点估算的思路进行了改进，形成用例点估算方法并使用。
　　什么是模式？
　　简单来说，模式就是经过无数次的实践和失败总结出来的，解决特定场景下的特定问题的解决方案和最佳实践。
　　对于模式，PatternAlexander给出了经典定义：
　　每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式你可以无数次地使用那些已有的解决方案无需再重复相同的工作。模式作为现实世界中的一个元素，都是以下这三者之间的关系，它们是：特定的情景，在该情景下反复出现的特定压力系统和使这些压力能够自我释放的空间配置。
　　作为语言的一个元素，模式是一条指令，说明了如何重复地使用这个空间配置，一旦给定的情景适当就释放给定的压力系统。简而言之，模式是一种出现在现实世界的事物，同时它也是一条告诉我们如何创建，何时创建该事物的规则。它既是一个过程，又是一种事物；既是对一个存在的事物的描述又是对生成该事物过程的描述。
　　因此每个模式一定要包括问题，场景，压力和解决方案四个要素。问题：你遇到了什么难以解决的问题？
　　场景：你是在那种场景下遇到的问题，不同场景下遇到相同的问题也可能采取不同模式。
　　压力：有哪些影响方面，哪些约束，由于问题复杂性需要如何折中处理？
　　解决：在以上三要素约束和作用下，已经被前人实践证明的可行方案。
　　开发人员效率差在哪里？
　　如果你读过类似《软件工艺》或《人件》这类书籍，里面经常会谈到好的开发人员的开发效率往往是一般人员的10倍甚至更高。
　　那么开发人员效率究竟会差在哪些地方？在2006年的时候自己进行了总结如下：熟练人员经过多年的积累加上自己的CodeSnip的总结，基本不用额外再查找资料。而一般的开发人员在开发过程中会花掉1020时间去查找资料。熟练人员注意代码复用，并且时刻注意重构和抽取公用代码。一般开发人员是代码拷来拷去完成功能。熟练人员非常注意查找，定位，标签等各种快捷键的使用，定位查找方便快捷，IDE环境也根据习惯定义到最方便状态。熟练人员编码前先思考清楚整个流程，在头脑或纸张上规划好整个实现方式和方法函数的划分。一般人员想到哪里写到哪里。熟练人员写了50行以上或更多代码才Debug一两次，一般人员写了几行代码就要Debug多次，完全通过Debug来验证代码正确性。熟练人员注重代码的质量，单元测试和可维护性，注重各种业务逻辑的验证和边界条件的校验。一般人员只注重简单功能的简单完成。熟练人员提交测试的代码BUG很少，返工工作量很小。一般开发人员由于自测不完善BUG较多，造成大量的返工工作量。熟练人员合理分配自己的时间，规划好每天工作任务，开发过程各位专注。一般开发人员一心多用，边开发边聊Q。熟练人员善于知识的总结和积累，形成自我的知识库和经验库。熟练人员善于发现问题，分析不足而自我持续改进。一般人员在外力干预侠被动改进。熟练开发人员开发重点已经专业到对业务的深刻理解，一般开发人员考虑的是开发上编程的语言和工具。熟练人员善于从各种影响自己开发效率的因素中挤时间，善于使用各种辅助开发工具。而一般人员则不善于这种总结。
　　方法论的切入点
　　方法论是可以解决特定场景下的问题的一系列方法，过程，工具，技术的集合。而学习方法论往往更应该从小问题出发，学习相关步骤和其系统思维的方式。
　　然而对于小问题我们往往一眼就看到了答案，而忽略按部就班地去使用方法论，去积极地锻炼自己的思维过程，或者是先想到了答案再根据结果再反推着具体的步骤和方法。这样导致我们遇到复杂的问题时候往往感到无从下手，因为这个时候缺乏的已经不是步骤的问题，更多的是缺乏系统的思维模式和实践。
　　我当时举了一个例子如下：
　　当爬一个小山坡的时候，还没有爬可能就看到了顶点，看到了中间的亭子等重要里程碑，所以爬的时候也不会去考虑什么方法，也不用去思考也能够正确的爬到顶点。而当你爬一座高山的时候，顶点遥不可及，或者连中途的里程碑点都无法看到，所以这个时候你爬的时候心里面没有底，也不知道自己是否偏离路线，也不知道按现在方式能否成功爬到山顶。
　　可能到这个时候你才会真正意识到了自己在爬小山坡的时候没有注重这些步骤和技术的练习，所以你始终处于爬山的初级阶段。
　　当平时遇到简单问题解决起来得心应手，而一遇到复杂问题就感到无所适从的时候是否该反省和总结下相关的方法论。当对于简单的系统或功能设计和开发起来游刃有余，而遇到复杂的系统却无法进行分析和设计的时候，是否该考虑下系统化进行分析和设计的思维方式和逻辑。
　　如何循序渐进向架构师发展
　　自己原来做DotNet开发，当时写过一篇文章，即如何循序渐进地向DotNet架构师发展。现在摘录了里面部分内容。
　　设计和编码其实是密切而不可分的，对于严格将设计和编码分开的瀑布模型一般也仅仅在大型项目中应用。而及时编码和设计分离，也不是将编码人员不需要思考，编码活动始终是一项创造性的劳动，如果否定这个观点那就代表编码过程完全不需要人员介入而可以完全自动化。
　　因此在这里谈设计主要还是指设计人员的系统化思维能力，设计人员应该比开发人员站高一个层次来分析和思考问题。设计人员最重要的一个技能就是现实抽象的转换，而这个就需要谈到方法论的问题了，技术人员需要积累面对对象分析和设计或结构化分析知识的积累，需要有较强的数据库分析和设计能力。一个设计人员能否成为很好的架构师关键就在这种积累的深度和广度上面了。
　　因此在设计过程中应该考虑的问题有：你现在分析和设计能力能否胜任大中型的应用系统还是只是独立功能分析和设计？设计过程中是否有意识的考虑到组件的复用和相关接口设计准则。是否能够很自然的将分析模式，设计模式的相关内容应用到自己的设计过程中。是否对XP，RUP，面向对象，结构化等方法论都有过较系统化的学习和思考。是否真正理解系统功能需求和非功能需求对系统设计的不同的指导作用。对自己设计的功能是否会根据后期的变更来反思自己的设计为何不能很好的适应变更？是否在设计过程中经常自己开发些原型来对自己的设计思路进行验证？是否专注技术的同时开始专业业务流程的分析，关注业务建模？
　　如果我们在设计和开发过程中经常关注这些知识和技能的话，成为一个合格的架构师是早晚的事情。平时能够胜任工作开发用到的知识和技能是微不足道的，如果自己不是有意识的去学习这些知识的话，那技能是很难得到进一步提高的。
　　读书只有两个层次
　　对于知识来讲分为两类，有锻炼智商类的知识，也有锻炼情商类的知识。而我们读书的两个层次正好和这两类知识相对应。
　　锻炼智商的知识，就如常说的工程技术，理工方面的知识。这类知识的理论和技术性都很强，因此一般遵循的学习路线都是：理论实践理论实践；这类知识如果没有基本的理论储备而想在实践中去寻找真理是很困难的，所以这类技术知识我们一般都是站在巨人的肩膀上，在前人已经获得的理论指导下，先进行相关理论的学习，再实践，再完善自己的理论。锻炼情商的知识，如现在的管理类，思维类，沟通方面，成功学等方面的知识。这类知识更多的是依赖个人的情商而非智商，因此应该遵循的学习路线是：实践理论化指导实践理论积累的方法。
　　任何企图通过成功学书籍或理论来指导成功的都将是徒劳。因此特别是这类书籍，如果没有相关的生活感受，工作经历，即使读了也很难有很大的收获。更多的应该是有了实践经验的积累，有了失败的教训再或过头来读这些书，进行自我的反省和总结，把相关的经验理论化下来后指导后续新的实践。
　　知识存储和思维有感
　　人的大脑的容量是有限的，那大脑究竟应该存储哪些知识以及如何存储？
　　首先一部分是存储理论知识，另外一部分是用来存储理论知识经过实践后或者说没有通过理论完全通过自我实践得出来的经验和技能。
　　实践最重要的还是要形成解决问题的方法论或模式，所以这里有三个要素就是场景，问题和解决方法。这也应该是构成我们经验的重要要素。
　　我们存储的理论知识如果经常不使用或不实践也会遗忘掉，就如你现在根本无法再记清楚高中的几何学公式一样。因此出了学校进入了工作阶段后原来存储理论知识部分要全部移出来存储经验技能。只有经验和技能才具备了更长久或永久的记忆可能。
　　我们一直在做的事情就是要解决特定的问题时候，再来回顾需要用到的理论知识，通过应用理论解决了实践问题后将其转化为经验再进行存储。这样才可能最大限度利用大脑的存储容量。
　　所以在进入了工作阶段后我不提倡任何强化记忆的方法，任何没有实践或理解的记忆都将是暂时的。
　　当工作积累或经验越来越多的时候，会发现大脑仅仅用来存储经验教训或相关技能也不够了，所以这里应该只记录场景问题方法即可，而对于具体的解决步骤，技术或工具应该仅仅记录索引。只要我们在应用的时候能够方便找到就可以了。
　　大脑的容量是有限的，所以我们一定不能去存储没有分解的粗粒度的问题域，而应该将其分解和提炼，并且要重新整合。只记录细粒度的模式条目，这种可以简短到一句话归纳的模式语言是最重要的经验和技能库。
　　关于人员流动的动态建模分析
　　系统思维始终和动态过程是联系在一起的。系统动态学从整体的角度来看待事务，考虑系统中各个对象和因子间的相互影响和作用。当系统中各个因子间的相互作用力达到一致的时候，系统处于一种动态平衡的状态，当任何一个因子由于外界环境因素影响而改变都会打破这种平衡，动态的系统在这种平衡被打破后由会去不断的去调整各因子的值和相互作用，直到下一次动态平衡。
　　IThink，Isee。
　　对于基于这种思想的动态思维建模和模拟软件iThink能够为我们很好的将我们头脑里的想法用模型记录下来。我们相信直觉，直觉也经常帮助我们做出准确的判断，但对于多于复杂的多因素影响的系统直觉则往往是错误的。即使直觉正确也经常只能够告诉我们是或否，但具体的数量级的概率或精确点的数据则是无法得到的。
　　经验或直觉在没有通过模型固化下来之前是没有很好的传递性和继承性的，只有通过模型将思维固化下来才能够形成相关的理论或方法。
　　对于软件团队中人员流动问题在《最后期限》一书中也专门进行了模型的模拟。在这里将根据自己的思路对该模型重新进行整理和建模。
　　首先我们需要得到一个在人员不流动，其项目团队成员都是熟练员工的情况下的一个平衡模型。在这个平衡模型下堆积100个功能点的需求，每天流入新需求约5个功能点，项目团队成员10人，每周工作40h，每小时的生产率为0。0125FPSh，在这种情况下项目以迭代方式进行多版本发布，每个版本持续时间为8周，因此新提交的需求一般在2个月后就可以上线运行。在这种情况下我们得到一个平衡的模型，在这个模型模拟Running的过程中，堆积需求始终保持在100FPS。
　　对于每周40h是理想的情况，当需求积累过多而无法满足的时候往往需要员工加班来解决问题。我们任务加班80h是每周加班的极限时间，而具体的加班时间跟需求积累比率成正比。如果累积需求达到了200FPS，即比率为2时候，则需要加班到80h左右。因此可以利用iThink的图形建模功能得到一个加班时间与需求累积率的函数。
　　假设人员流失为每季度即12周流失一名成员，对于项目成员流失的时候一般提前4周进行资源的提前补充。因此对于人员流入和人员流出都为阶段点的非连续性数据。在老员工离职后新员工的技能提升是一个长期的过程，新员工要达到老员工的生产率水平一般需要2年的时间，但经过1年的时间基本可以达到7成水平，在这里新员工的技能水平提升符合学习曲线。
　　为了模拟较长的单位，将最小时间修改为1个月，同时对新员工的学习曲线修改为线性的方式。对于新员工增加后，需要占有老员工的培训时间，这里暂时将项目可用人数减少0。5进行处理。新员工刚进入时候的技能水平为0。4，以后每一个月后增加0。025，则两年后达到熟练员工的水平。由于需求积累超过限度后引起的加班，暂时不考虑加班过长对人员效率人员流水的影响。对于员工离职，模型假设新员工可以提前一个月入职接手相关工作。
　　在这种情况下进行模拟后发现最终的生产率水平保持在原有生产率的7080左右，而且由于生产率下降引起的需求积累，导致加班增加，加班曲线呈现持续增长状态，显然这并不是一个能够平衡的动态模型。为了减少加班情况，在第一年末在模型中新投入一名不需要培训的熟练员工。加班曲线可以降低下来到46h左右。
　　需求也不再持续累积增加而稳定到120130的水平。
　　供应链顶层数据流
　　这篇文章写在06年的年末，当时对供应链管理，采购和库存控制策略，MPS主生产计划和MRP物料需求计划，研发管理和BOM等业务知识进行系统的学习和整理。
　　当前印象里面是参加了i2组织的封闭1个月的APS相关知识培训，相当系统，这些业务和IT知识融合进一步完善了个人业务领域的知识结构。
　　这篇文章当时笔记记录如下：
　　1。订单要用来冲减预测，订单要考虑订单本身优先级，再考虑时间优先级都经过排序后按照排序的先后关系进行冲减，入MPS的数据流为确认后的订单信息和冲减后的净预测信息
　　2。除了订单和预测外MPS的输入还有确认后的已经下达的请购申请，在制成品和半成品的库存对于ATO装配型企业MPS一般要做到半成品层，这时候MPS需要考虑计划BOM分解对于其它一般考虑分解到产品层，得到产品分时段需求和计划下达量信息
　　3。MPS和MRP不直接交互信息，MPS主计划的结果仅验证主计划和能力的可行性这里需要人工干预，即在主计划验证可行后具体的需求请购信息仍然人工下达，需求请购既用于主计划的MPS的扣减，也用于MRP的入口信息
　　4。MRP的分解原则分两步进行，首先第一步全部分解到最底层的原材料级别的需求，这里源头是需求请购，除了要考虑库存和加工周期外，还要考虑执行中的WIP和在途的采购订单第一步完成后再考虑原材料这块的采购提前期和库存约束，供应商和物料约束当我们需要考虑产能的时候也应该是首先运行无限产能计划，再考虑产能约束计划
　　5。为了更好地进行供应链协同，往往跟供应商间还需要及时地交换和共享预测信息，MRP信息和库存信息供应商反馈的库存信息会额外增加为运行供应链计划的约束条件只有真正实现了这种信息的及时协同，才可能最大化的压缩采购周期和降低库存
　　6。几个没有想得很清楚的问题如果要考虑需求计划和采购订单的一一对应关系，则要增加相关的资源锁定功能，跑增量MRP还好办，如果是跑全量的MRP则还需要考虑历史对应关系信息，非常麻烦。