从两台洗衣机看生活中的经济

        最近几年随着毕业后生活中心从学校转向工作，经济上已经完全独立，并且逐渐有理性的经济意识。不止有空看看五常的宏观调控算学经济，拜读凯恩斯的大作算学经济，在生活中的消费行为是更有效的学习方法。以前租房子，房东的洗衣机是最简单的那种，除了转动什么都不会，每次洗衣耗时耗力。平时懒得用，一到周末就是洗衣日，一大堆衣服要洗上半天多。如果去户外露营或旅游，回来后的要洗衣服更多，实在是不堪重负。而且有些比较好的衣服和冬季的大衣羽绒服，小洗衣机基本洗不了，得拿到洗衣店去洗。前些日子和MM商量打算买个洗衣机，把宝贵的周末休息时间从洗衣中解脱出来。到网上，商店转了些日子，大概了解一下现在的行情。一般国内的品牌主要是低等和中等，国外的品牌是中等和高等。鉴于以前买大件电器的经验觉得国内品牌售后一般不太好，所以决定限定在国外品牌。首先排除日货，否则在主观情绪上接受不了。其次排除韩货，觉得韩货不以质量为重。这样可选范围基本限制在几个欧美品牌。到网上调查了一下，西门子的口碑很好，于是决定买西门子的。在调查发现和另一个被西门子刚收并的品牌博世已经进入国内洗衣机市场，并且在产品完全和西门子一模一样的基础上平均便宜200元左右，这样我们决定买博世的。
       博士品牌洗衣机的也有很多款型，从2000多到5000多不等。MM买大件东西经常持在价钱不离谱基础上尽量一步到位的原则，提议买功能最多，效率最高的。最高等级的是滚筒洗衣干衣机，型号WVT52458TI，具备最高转速，最多功能，可以干衣，价格大概5300。我虽然认同这个品牌，但觉得干衣用处不大，而且比非干衣大概贵800元，但也想不出什么理由说服MM，于是就接受了MM的意见买了这款。买回家到现在大概半年，对机器还是很满意的，无论噪音，功能人性化，服务质量都让我们无可挑剔。但美中不足的是干衣功能基本用不到，而且总觉得价钱贵了些。前不久父母也想买个洗衣机，听了我们当初买的思路，决定买博世的，把家里用了十几年的老双缸换掉。但他们觉得我们买的很多功能不重要，而且效率不重要，所以选择了3100元的款型，回来用了几个星期感觉很满意。
       以前我买洗衣机时还在犹豫，既然房东提供了洗衣机，是否还有必要再买一个好的。因此在考虑买新的的时候总把价格因素考虑在前面。包括旧的方法的水电，需要 花多少钱给洗衣店等等。一下花了5000元买了洗衣机总在计算够送多少趟洗衣店才能抵回来。今天和父母讨论他们用了一个月的感受，忽然觉得买的并不亏，因为我之前忘了算进去另一个重要的因素：时间。新的洗衣机是全自动，把衣服放进去，设定好程序，剩下的等着它叫你晾晒，或者使用干衣功能等着叫你穿就好了，基本不需要人工额外操作和值守。我估算一下买新洗衣机之后，大概我和MM每周共平均少花6小时用于洗衣，一年也就是300小时，合13天。按每月我和MM纯收入12000元计算，13天大概收入5000多元。也就是说一年用于洗衣的时间节省出来时间能买一个全新最高档次的洗衣机。如果算做是一种投资的花，如果不考虑折旧，本金是5000多元，一年回本，此后每年的收益是约100％。随着损耗维护费用逐渐增加，直到它彻地不能工作。当然，并非说我们不把这些时间用于洗衣，可以每年多挣5000多元，但我们可以用节省的时间学习，娱乐，陪父母，做更多有意义的事情。虽然不能直接增加收入，但可以明显提高生活质量，周末可以用更多时间享受生活的快乐，所以还是很值得的。
       生活的经济和市场的经济很大的差异在于非可度量价值，比如体验，比如心情，比如时间和机会。很多价值是很难为货币所衡量，而又是生活的重要组成部分。钱在狭义上对生活而言无非是维持生活的工具，但适当的调整钱与生活这个天平的发码，可以换来更美好的生活，也许就是大家讲的生活质量吧。所以理财也好，经营也好，只是用钱来满足并平衡自己的欲望。知道什么是自己最想要的，也许会觉得生活更有意义。

一次成功的项目管理实践

        月初参加公司给安排的项目管理课程。做软件的嘛，做方案的嘛，早晚要接触到项目管理。想必听听对工作有用。没想到今天第一次从中受益，并非是当项目经理，而是作为项目成员给自己加分。记的项目管理第一节课，老师就说，项目管理绝不仅及是用在软件开发，或者工程管理。生活中无处不是项目，买个房买个车，出去玩一趟都是项目管理实践的机会。现在想起来说得太对了！
        事情从上周说起。周四上午10点我接到Leader给的任务，负责编写一个小模块，用于加载配置数据。需要开发的只是一个类，其中有一个主要的方法load()负责用磁盘上的配置数据在内存中构建一个结构化的数据对象。本来Leader已经基本作好了的一个版本，只是现在由于需求变化，需要改变配置数据的格式和内存对象的构造规则。因此我基本上要重新写load()中的逻辑来符合新的需求，并且要考虑为以后需求变更提供一些可扩展性。配置数据放在一个三层XML中。我需要读取，解析，然后放到一个对应的三层的Map结构中，就是一个Map套Map一共三层的多叉树。我管每个Common叫“不定式”，三层一共三个一元不定式，三个一元两两配对形成三个二元不定式，三个一元同时叠加形成一个三元不定式。一共7个不定式需要在各级循环逻辑中处理。看来这个XML的确比较复杂，更麻烦的是受外界条件限制不能为它定义Schema。
         按照通常的软件开发习惯，首先分析边界条件。比如什么情况Common覆盖Special，什么情况补充Special。 然后写测试用的XML，包括一些测试边界的数据。最后把逻辑流程写到纸上，并标识测试的观察点和异常情况。由于考虑扩展性和最大程度减少数据冗余，逻辑做得比较麻烦。先要把所有Special的数据加载成对象，然后用Common数据来根据情况修改所覆盖Special数据。经过两个小时，设计做好了。用大脑模拟运行几次，没有问题，去和Leader讨论。Leader听我讲了思路，首先对我的设计表示认可，认为能想到的各种情况都考虑到了。但同时他也提出顾虑，主要是这个逻辑写起来会很麻烦，费时间，其次以后别人阅读不容易理解，而且后期超出对目前弹性范围的需求变更的修改会比较困难。讨论了一阵子，发现也没什么更好的办法，因此决定先做做看。这时已经是周四下午4点多了。
        既然设计已经通过认可，我开始着手写逻辑。解析XML是使用JDOM和XPath。开始写发现这个东西比较烦，层层嵌套，层层拆分。代码编写进度比较慢，稍不留神就迷失在嵌套的从林中。到了晚上9点下班，已经处理完一个一元不定式。回家继续努力，到半夜快2点的时候，终于把这个load()写完了。
       第二天早晨，强打着精神来到公司，继续对这个类其他方法编码。到了中午开发部分一切已经搞定，开始测试。由于前期设计工作作得充分，测试并没有太痛苦。因为逻辑做得完善，所以自己思路还是很清楚的。通过第一轮测试发现Common和Special的优先关系都反了。通过Debug跟踪代码发现自己对xPath的//理解有错误，于是反复修改测试。到下午4点半一切搞定，所有测试数据和边界条件都符合设计。上交代码和测试数据，下班回家。离开公司前Leader让我手机一直开机，发现问题随时需要我修改。但我对自己的作业是信心十足的。实际也证明，一个周末我的手机一直安安静静。
       这周一早晨来到公司，第一件事情就是问Leader，我那部分与其他部分合的怎么样。Leader很心疼的看着我说，上周我交的代码很不错，但现在需求变更，需要把配置数据再增加一层。当时感觉自己一阵眩晕。三层已经让自己很困扰了，好不容易解决又弄出个第四层来。三层的时候最复杂情况是遍历三层原数据再累加遍历三层构造一半儿的多叉树对象，一共是6层循环。现在源数据加到第四层，逻辑就是8层循环，代码量也会相应大很多。此外的变更是以前Common用于填充所有叶子，现在改成只填写存在的叶子，因此要增加判断逻辑。更要命的是必须尽快做完，顶多给2天时间。因为我的模块需要被其他业务Pipeline调用，而目前其他业务模块基本都做完了，就等着我们这块完成之后做单元测试。Leader看我为难的样子给我出了个主意，把我以前的设计方案推倒，重新设计配置文件的格式，并且重新构建数据模型。颠倒数据装载顺序，先读取不定式，然后读取相对special的数据，但这种方式依赖每个XML元素中子元素的顺序。按他的建议，我前期做的工作除了让自己对这各模块的业务熟悉之外，其他工作基本都要被抛弃，而且新的思路对增加了XML文件中数据有序的约束，降低了灵活性。好处是如果以后别人读我的代码或修改我的代码会比较容易，而且总体使用时间会比继续按我第一版的时间少。的确他说的有一定道理，降低扩展性，减少初期开发时间，如果没有更多需求变更的确这种方案比较经济。这时我必须做一个决定：继续 在我第一版基础上修改，或是推倒重新做第二版。
        正在为难的时候想起了项目管理课程中讨论过的一个话题：是否完全依照客户意愿在项目进行期修改需求会直接影响项目验收效果。往往通过讨价还价尽量减少需求变更会对验收有利。分析当前的情况，包括了两种变更：业务需求变更和数据结构／算法变更。前一种变更看来是无法免除的，因为这本来就是个潜在变更，而我做是前期我们做需求分析时没有考虑到。第二种变更完全是客户（也就是我的Leader）应对第一种需求的一种策略，目的无非是解决第一个需求。我推想，如果我能把第一个需求解决，他也不会非要求我再按照他的设计重新开发，但风险是我必须按期完成对需求变更导致的开发。寻思良久，我还是决定铤而走险，用一天时间继续按第一版方案修改。如果到明天早晨我不能交付代码，那我就彻底放弃第一版进而开发第二版，并且必须在后天早晨之前完成。后面的事情可想而知，从上午一直工作到半夜，疯狂的工作，舍弃一切没必要的代码，比如调试部分及必要的注释。第二天早晨再到公司虽然晚了一些（早晨实在困的起不来），但心情轻松了许多，而且顺利的通过了他的测试。虽然我告诉他我没有按他的要求完成变更的第二部分，但已经完成了第一部分。如果他坚持认为必须完成第二部分，我会在第二天早晨提交给他第二版。他想了想，似乎也意识到相比之下重要的是尽快交付这个模块，于是对我的工作表示认可。我不但提前完成了任务，还可以让自己后面几天轻松的等着别人的进度。
       这是我第一次在工作中有意识的利用项目管理的知识，和从中尝到甜头。和以往抱着不加思索的满足客户需求的态度相比，适当的策略及技巧在满足客户需求的同时让自己更多的获利，对客户和自己双方达到共赢。看来项目经理的课程远不仅对做“项目经理”这一职务有用，而且为参加项目的成员相互协作提供方法指导。