实践证明这些计划都是纸上谈兵，有的严重超期，有的质量不过关，有的功能遗漏，很少按预期完成的。这也难怪，就是精心制定的计划都有偏差，何况是随便给出的呢。

这里总结一些个人经验，这是对简单任务而言的。所谓简单任务指的是能分到某个人头上的任务，不包括需要一个小组协同完成的任务（当然部分也适用于小组任务的）。

1.         对任务尽可能的细划。任务分得越细，考虑得越周到，遗漏的可能越少。同时我们对细小任务的估计更准确，我想这也是大家钟爱WBS的缘故吧。

2.         建立任务的风险列表。外在环境、技术难点、甚至近一段时间工作状态，都会影响任务的进度。风险很多，列出我们能处理的风险就差不多了，至于第三次世界大战之类的风险完全可以抛开。根据风险列表，在理想的计划上，加上一定的风险储备。

3.         征求做过类似任务的同事的意见。我们不是神仙，对从未有类似经验的任务，很难估计准确，征求做过类似任务的同事的意见是明智的做法，至少我们能从中了解一些潜在的风险。

4.         不断调整计划。计划不是不变的，早期的估计或多或少的有些偏差。随着任务的进展，一些风险的消除，以及这期间的经验积累，我们可以更准确的估计时间了。一般来说在任务预定时间过去30%左右时，重新评估一下任务计划是比较好的习惯。

5.         及时反馈任务的执行情况。特别是研究性任务，出现计划与实际较大差异的情况是很常见的。让你的上司清楚任务的执行情况，很有必要，一旦出现较大偏差，他可以对你提供帮助，或者对整体计划进行调整。切记不要在时间快完了，才报告出了大问题。

6.         计划要实事求是，不是估计时间越短越好。不要因为面子上的问题，把时间估计得过短。否则你的任务太重，不但会影响你的正常休息和工作情绪，最终无法完成时，面子丢了是小，影响整体计划是大。

7.         采用PSP中一些方法，评估自己的效率。记录在执行任务过程，你的时间分配情况，估计你在做某类事情时的效率，为以后类似的任务提供经验数据。

只有懒惰的程序员才会去编写那些可以最终代替自己工作的自动化工具，才不会成天为了实现相似的功能去编写大段大段冗余重复的代码 - 这种代码往往是软件后期维护和重构的天敌。通常来说，由于惰性的驱使所产生出来的工具和程序将最终极大的提高生产开发的速度。

当然，对于一个程序员来说，光光具备懒惰这个要素还是不够的。在享受懒惰之前，他必须以最大的热情和最高的效率去研究解放自己的途径，比如：找到最有助于开发的工具，最能体现“一次编写，多次复用”精神的代码架构的设计。只有在这些必要的工作之后，才可能真正享受轻松编程的乐趣。

所以“懒”的精髓用一句老话来描述，那就是磨刀不误砍柴功。如果你不想办法磨亮手中的柴刀，就算一天二十四小时都在砍柴，效果也不如拿把锋利的斧头一天只砍一小时。

从这个角度来说，Google给员工的20%自由时间是完全发挥了“懒”的能动力。为了更好的享受偷懒的乐趣，员工会更加具有创造力的去高效完成自己的任务。

夸张一点来说，懒惰才是人类进步的原动力。

笨

这一点似乎比懒更让人不能接受。在解释这里所说的笨的具体含义之前，我们先看看一个聪明人（或者说认为自己足够聪明）会做什么：

1) 停止学习新的东西

2) 不愿意用批判的眼光去审视自己的工作

第1点将使我们很难去接受或者主动的去研究一项新的技术 - 即使新技术能带给他更多工作上的便利。第2点会使我们无法清晰的分析自身工作的问题所在，要对其进行改进或者重构就更加困难。

从这两点来考虑，作为一个程序员太自以为是不见得是件好事情。由于对自身的过于自信，往往无法客观的看待自己和自己的工作。相反的，笨一点（确切的说，谦逊一点）有时候倒有助于开发的顺利进行。举例来说，当程序出现bug的时候，最好尽早承认问题是出在自己编写的代码上面而不是在于编译器（当然除非是字节高低位编码方式之类的问题，这种问题编译器会是错误的根源之一）。如果你太自负的认为自己的程序没有问题而去猜测可能是编译器或者其他的什么外部因素出问题的话，那么十有八九你会在调试过程中走上一长段的弯路。

程序员应该笨一些的更为关键的原因在于，当需要思考问题的最佳解决方案的时候，往往要求我们首先要跳出思维定式。你对系统了解的越多，积累了越多的经验，就越难走出已有的局限，可以尝试的范围就越小。相反的，对于一个什么也不懂的门外汉来说，因为没有任何失败的记忆和潜规则的约束，也就没有什么是“不可能”的，这样的大脑所能迸发出来的在专业人士看起来愚不可及的想法往往正是解决问题所需要的关键点所在。

可能很多程序员都会有类似的经历，在面对别人（尤其是其他部门）对于一个bug的描述的时候，必须把自己摆在一个普通用户而不是程序开发者的角度来分析问题，否则的话可能你永远都想象不到这种错误也会发生。越能让自己变得“笨”起来，越能很快的定位到问题所在。我们先看看这么一段关于web开发问题的程序员和客服人员的对话：

“从昨天开始我们的用户就看不到我们站点上的Logo了。”

“他试过重启浏览器么？”

“是的。”

“他试过重启电脑么？”

“是的。”

“他清空过浏览器Cache么？”

“是的。”

“他的浏览器版本是IE6么？”

“是的。”

“他确信是真的看不到Logo了么？”

“是的。”

“他是在电脑显示器屏幕上看我们的站点么？”

“什么？”

“比如说，它可能是打印出来看不到？”

“不。他是在显示器上看的。”

“除了站点Logo之外，他是不是其他的图片都看不到？”

“什么？哦。我再问问他。”

从这段对话来说，估计用户实际上是禁止了浏览器显示图片的功能（或者他儿子干的）。不管怎么样，如果你不是用这种傻瓜式的思维方式去寻找答案的话，可能怎么也找不到问题的根源。

很多时候，问题发现者对于问题的描述往往是非常片面的，并且加上了主观推测的成分在里面。如果你不能透过这些主观的描述去发现问题的实际表象，或者说根本就是你自己根据程序员的经验逻辑来判断问题所在的话，十有八九会在歧途上越走越远。

对于白痴级的问题，只有用白痴的行为方式才能得到答案。

即便同样是程序员，但对于你的程序并不熟悉，也会经常有这样的疑问：“为什么我调用你的代码出错了？”这种问题的答案，很多时候是因为他们的调用方式不对，或者调用了错误的库文件，或者库文件的版本使用不当，或者根本就没有联接到库文件上。当你想让同事帮你检查一下程序中的一个莫名其妙的bug的时候，一般来说希望他对你的系统了解的越少越好，只有这样他才会问一些你自己认为绝对不可能出问题的“笨”问题。

所以“笨”的精髓在于你如何去思考问题：不要假设些什么，把自己假设的太完美或者把别人假设的很聪明都会使你忽视一些很浅显的事实。思考的前提必须是完整的事实表象，思考的过程必须是抛弃成见的问题跟踪。在发现事实之前作太多的主观思考和臆断，倒不如把自己当作白痴一样来行动更好。

当然，不思考的一个极端是不分情况都直接去做，另一个极端是完全脱离事实，用思想办事。一个优秀的程序员应该做好权衡。10次决定里面的1次错误决定不是致命的；只做5次正确的决定而另外5次没有任何决定才更糟糕。

最后是一个蜈蚣的故事。蜈蚣本来用自己的几百只脚走路走的很快很好，但他从来没有花时间去想过为什么。直到有一天，一只臭虫问他：“你是怎么管理好你的几百只脚的？你不觉得这是件很困难的事情吗？”臭虫问完之后就走了。只剩下蜈蚣坐在地上，不停的思考这个问题，却一直想不出个究竟。从此以后，这只蜈蚣再也没办法好好的走路了

</XML> 
或者在XML标签中通过SRC属性引用： 
<XML ID="XMLID" SRC="customer.xml"></XML> 
也可以使用<SCRIPT>标签来创建一个数据岛： 
<SCRIPT LANGUAGE="xml" ID="XMLID"> 
  <customer> 
    <name>Mark Hanson</name> 
    <custID>81422</custID> 
  </customer> 
</SCRIPT>