海滨擎蟹

本文为转载内容，转自：《知客百科》 - 知客 CRM一个来自我们 CEO 的段子：没有OA大家在办事的时候就会哦？（O），啊！（A）没有DMS的数据分析支持，营销工作不好开展还"得忙死"正如ERP的根据企业资源来定的计划能不能实现要"依人品"所以得出没有CRM的话销售是会"出人命"的这样一个观点虽然只是一个段子，但却基本说明了ERP（企业资源计划管理）、CRM（客户关系管理）和OA（办公自动化流程

最新一期《奇葩说》抛出了这样一个有趣的辩题：美术馆着火了，你会救一幅名画，还是会救一只猫？对于这个题目，两位语言大神李诞和黄执中展开了一场精彩的辩论，堪称“神仙打架”。首先，黄执中抛出一个貌似很高级的观点：“猫和画都是想象的概念，他考验的是你期待自己对这个世界的理解到什么层次。选择救画而不是救猫，不是因为我冷血，是因为随着你对世界的认知越高，你听到的哭声越遥远。”“遥远的哭声”这个说法让人感觉蛮惊

I was very naughty when I was a child. I can’t remember the reason that my parents and i visited one of our relatives,but i was very happy cause a good lunch meant a good day for me.After lunch,i play

内容摘录自：侃哥 - 侃英语虽然是标题党，但内容还可以。来张 celebrity couple 的婚照：爱的备忘录：正文，关于 笑 的几种打开方式smile 微笑She likes cherries. And she has a very sweet smile .她爱吃樱桃，笑起来很甜。laugh 出声大笑Hiddleston gave a deep rumbling laugh at his

结构师的交互准则和机制结构师的交互准则其实就是彻底、谨慎、和谐的与人交流。尽早的交流和持续沟通能够使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。面对估算过高的难题，结构师有两个选择：削减设计或者采用成本更低的方法。然而后者并不是结构师能够控制的，这是在向开发人员提出要求。此时，结构师想要发挥自己的作用，必须：牢记是开发人员承担着创造性功能的实现责任，结构师只

概念完整性绝大多数的欧洲大教堂，是由不同时代、不同的建筑师的设计所构成的。后来的建筑师总是试图在原有建筑师的基础上有所 “提高”，所以雄伟的哥特式教堂上，依附着祥和的诺曼底十字架，展现出属于各个设计师的骄傲。对于计算机体统而言，绝大多数系统体现出的概念差异和不一致性远远超过欧洲的大教堂。这不是由于不同时代的设计师开发的原因，而是由于设计被分成了由若干人完成的任务。我主张，在系统设计中，概念完整性是

外科手术队伍常听到软件经理声称自己喜欢一流人才组成的精干的队伍，而不是那些几百人的大型团队，其实我也有同样的想法。不过，还有一个很困难的问题，大型项目的团队应该是怎样的呢？问题软件经理很早就认识到优秀程序员和较差程序员之间的生产率差异，研究人员对一组具有经验的程序员进行测量。在该小组中，不同人员之间生产率的差别最大为 10：1，编程速度和空间上具有 5：1 的差距。简单来说，工资 20000 程序

空泛的估算编程人员有时和厨师一样，某项任务的计划进度，受限制与客户要求的紧迫程度，然而紧迫程度并不能控制实际完成的情况。例如，约定两分钟内煎完一个鸡蛋，看上去简单，但实际上它无法在两分钟内完成，顾客只能选择等待或者吃生鸡蛋。厨师的另一个选择是把火开大，不过结果常常是得到一个更糟糕的煎蛋。为了满足顾客期望而造成的不合理进度安排，在软件领域中非常普遍。不科学的估算方法，少的可怜的数据支持，完全凭借产品

在众多的项目中，缺乏合理的进度安排是造成项目延期最主要的原因，这比其他所有因素加起来影响还要大。这个灾难是怎么发生的呢？所有编程人员都是乐观主义者所有系统的进度安排背后第一个错误的假设是：一切都将运作良好，每项任务仅需要花费它 “应该” 花费的时间。对于创造者，只有在实现的过程中，才能发现我们构思的不完整和不一致性。编程人员通过非常纯粹的思维活动构思程序，所以很容易自信的认为实现过程中不会遇到困难

在 learnku.com 站上看到一位 CTO 对 《人月神话》 的翻译以及自身的理解，觉得很有学习价值，特此转载。百度百科对这本书的简介：《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。在《人月神话（英文版）》中，既有很多发人深省的观点，又有大量软件工程的实践，为每个复杂项目的管理者给出了自己的真知灼见大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本