我说的一切都是错的
有人问《月亮与六便士》的作者毛姆，你写作是按计划写的呢？还是受灵感驱动，啥时候有灵感啥时候才写呢？ 毛姆说：“我只有在灵感来的时候才动手写作。不过很幸运，这个灵感每天早上9点都会准时到来。” 到了晚上码字的时间，想想今天没啥可写的，就不写了吧。第二天还是没啥可写，又不写了。到第三天，你都不会想起码字这件事了。这样的情况经常发生。 但还有另一种情景，还没想好要写什么，但还是坐下了打算写点，一会儿就知道怎么写了。 毛姆的话虽然有点玩笑性质，但也说明了很多事只要去做，就会有解决的办法。关于码字，首先要担心的不是有没有东西可写，而是能不能坐下来每天写的问题。我一开始总是纠结于“写什么”，以至于迟迟没有行动。后来我给自己找了条“后路”，实在没东西写，就抄吧，把每天看到的精彩的段落抄一遍。有了这个“后路”，我压力小了很多，就开始了码字的过程，说也奇怪，一段时间下来，虽然没有做到每天写，但从来没有抄过。 “干就完了”，虽然很简单粗暴，但确很有哲理。所谓船到桥头自然直，只要开始行动了，总会有办法的。
第二次去办住院手续，单子上备注栏写着到2号楼缴费，我一时没反应过来2号楼在哪，只记得第一次缴费是在中医馆那边。想找医生确认下，我指着单子上的备注栏对医生说:”不用去这里吧，是不是还是去中医馆那边缴费”。医生说是的，我也没多想，就直接奔中医馆缴费。缴完费回到楼下，医生打电话说原来的床位被占了，要在一楼缴费处改下。我才发现原来我所在的楼就是2号楼，这里也可办理住院手续。多跑了点冤枉路。重新排队等候，结果人家说我办的是院前，还没办理住院。又跑到院前，又说不需要办院前，直接办住院就可以。最后回到原来的中医馆缴费处，跟他说明情况。原来他那里默认是办理院前的，我的单子也没仔细看，就直接办了院前。
仔细反思了，问题就出在我提问的方式上，如果换个方式问：“去哪里缴费？”，“是不是去2号楼缴费？” 这样的提问就更明确点，我一方面手里指着“2号楼”这几个字，一方面嘴里又说中医馆。让人抓不住重点，我估计医生也没听清我说什么，看见我指着“2号楼”，就认为我在问他“是不是去这里？”，他就回答“是的”。一步错，后面步步错，简单的缴费，花了将近40分钟，搞得我郁闷了好一会。
有效沟通的关键是如何确保信息传递到对方，并被对方正确的接收。我只关注发出信息，没有考虑到这个信息是否容易被对方接收，最后导致自己浪费了很多时间。
从业这么多年，大大小小的项目也做了不少，有多少是真正成功的？当然，如何定义“成功”各有各的标准，从交付的角度来看，项目都是成功的。因为不管过程如何曲折，时间、成本如何超支，最终无法验收、收不到钱的项目实在少之又少。但这样的标准，对项目过程的改进毫无借鉴作用。 Standish Group是一家专注于软件项目绩效的咨询机构，它定义了用于衡量项目“成功”的5个指标：OnTime, OnBudget, OnGoal, Value, Satisfaction。按照这样的定义，我恐怕找不出一个成功的项目了。事实上，全球真正成功的项目也就30%左右，一半多的项目都处在“挣扎”状态。详见下图：
当谈论起项目失败的原因时，大部分人都会“归功”于需求。“客户自己都不知道要做什么”，“功能刚做完，需求又变了”，“客户怎么不上天啊”，这些话我们都耳熟能详了。的确，需求是整个项目的基石，需求的质量直接影响着整个项目的进展。 1994年Standish Group发布了软件项目的CHOAS报告，在影响项目成功的十大要素中，需求相关的要素占比37%左右，具体是：用户的参与，清晰的需求描述，现实的客户期望。有趣的是在2015年的报告中，需求相关的要素只剩下用户参与这一条，占比15%。这说明需求分析的专业性20年来有了很大的提高，用户也逐渐回归理性。 94版的报告同时列出了导致项目失败的10大因素，跟需求相关的占了51.6%，分别是：不完整的需求，缺乏用户参与，不切实际的用户期望，需求变更频繁，提供了不再需要的。虽然15版中没有这项分析，但在我看来，这些因素很多依然存在，而且占比还不小。
需求分析的实践性非常强，因为面对的是用户，世界上没有两个相同的用户，所以我一般不太相信方法论。最近看了徐峰写的《软件需求最佳实践》，整本书并没有空洞的介绍一堆方法论，而是总结了很多作者自身的经验，还是值得一看的。这里我就借他山之石，摘录些个人觉比较好的观点。
需求可分为业务需求、用户需求、软件需求三个层次。
业务需求反映的是系统的高层次目标要求，通常由企业高层管理人员提出，通常体现在两个方面：
问题：解决企业运作过程中遇到的问题 机会：抓住外部环境变化所带来的机会，以便为企业带来新的发展。 用户需求是指用户使用软件需要完成什么样的任务，怎么完成的。通常是在业务需求定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。用户需求是需求捕获的产物，有以下几个特点：
零散：用户从不同角度、不同层面、不同粒度提出的需求，很多时候是一句话需求 存在矛盾：从不同角度去看业务，会有不同的需求，用户之间会存在不同的意见。 软件需求：正因为用户需求具有零散、存在矛盾的特点，需要分析人员进行分析、提炼、整理，从而生成指导开发的、更精确的软件需求。所以说，软件需求是需求分析与建模的产物。
软件需求可以分成功能需求、非功能需求、和设计约束三种类型
功能需求：对功能需求而言，最关键的地方是如何对其进行组织，传统方法大多按照程序的结构（系统-子系统-模块-子模块）来梳理，这样会割裂用户的使用场景。 现代需求理论强调分析人员从用户角度，将系统理解成一个黑盒子，从横向的使用角度来整理需求，建议使用RUP的用例方法。 非功能性需求：最典型有两个问题：一是信息传递的无效性，二是忽略了非功能性需求的局部性。 信息传递的无效性：诸如“高可用性”，“安全性”等需求，一定要有具体的指标来说明，否则这个信息是无效的。 局部性： “系统响应时间小于5秒”这样的话语要明确前提条件，系统在繁忙时段或某些复杂的查询，响应时间很有可能超过5秒。 设计约束：这块内容前期很容易被忽视，而且产生的后果往往比较严重。 之前给客户做过一个小功能，因为比较简单，也没太多重视，功能需求了解完后，直接就让开发做了。做完才发现客户需要支持IE8浏览器，而目前的框架并不支持。所以，只能重新选择框架再做一遍。 设计约束主要包括非技术因素决定的技术选型，比如我之前做的外包项目，用户指定要XX用框架，那就没有别的选择了。还有就是刚讲的预期的软硬件环境。想当然的认为用户都用chrome，导致了返工。
平常很少照镜子，虽然知道白发很多了，但多到什么程度也不是太清楚。反正自己也看不见，眼不见心不烦。前两天对着自己的头顶拍了一张照片，还是有点惊到了。白花花的一片，黑发稀稀落落的分布在白发丛中，要不剃个光头得了。
很多年前就有剃光头的想法，但下不了这个决心，主要还是碍于面子。现在是时候了，早上起来就直奔理发店，师傅三下五除二，就刨光了。看着镜中的自己，感觉比有头发的自己好看多了。我的脸型是下大上小，剃光头会比较难看。这阵子人瘦了不少，上下基本匀称了，整体还看的过去，甚至有更年轻的感觉了，哈哈。
年初就把今年定义为改变的一年，忘掉过去的自己，重新变成一个小学生，从头开始。 把头发剃了，是否也意味着我已经正式上路了？
关于计划，经常挂在嘴边的句子有：
今天打开《用户故事地图》的电子版，被目录的章节名吸引了，第二、三、四章的标题分别是：
相比之前“口号式”的句子，这个定义更加明确，计划的作用一目了然。一直以来，制定计划被认为是管理人员的事，团队成员很少参与，也没多少人认为计划对自己的工作有什么帮助。这正是导致计划流于形式的根源。项目经理很多的时间就浪费在这种拍脑袋计划上，包括我自己在内。
计划如何发挥更少的开发、更快的学习、按时发布等作用？且听下回分解。