我曾经非常执着的学习编程语言。我有连续几天几夜做Coding的经历，也曾经为了一个技术问题耗上多个星期而导致项目一再延迟。推动这种逻辑向前发展的，是方法和方法论的出现。长期的变成时间，自然的总结，必须沉淀为某种方法，于是过程出现了，于是相关的方法论也就出现了。
这就是时间的成果。方法不是某个人或者某个组织的创作的。时间积累达到一定的程度，微软不提出某个方法，IBM也会提出这个办法。即使他们不提出，可能不是你自己使用这个方法了。方法并不神秘，因为他就是你今天正在做的、从事的和实现的。正如模式是一种方法，而模式就是你昨天书写代码的那个行为。只不过归纳抽取提成了这些行为的内在规律。
你看不到你做事的行为，也就不能理解模式作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验。
分不清玩家和客户的区别，对项目经理来说，是可怕的。这就意味着他不能清楚的知道哪个环节是更加重要的。角色的确定，与i级角色间的沟通问题，在项目过程中也同样重要。工程组织是否合理，相互的协作是否紧密，是这个项目成功的保障。
过程伴随工程而出现，解决的是工程中步调一致的协作问题。那么工程适应未什么而出现的？很显然，软件规模的不断增大是根本的原因推动这种逻辑向前发展的，是方法和方法论的出现。长期的变成时间，自然的总结，必须沉淀为某种方法，于是过程出现了，于是相关的方法论也就出现了。
我有连续几天几夜做Coding的经历，也曾经为了一个技术问题耗上多个星期而导致项目一再延迟。
推动这种逻辑向前发展的，是方法和方法论的出现。长期的变成时间，自然的总结，必须沉淀为某种方法，于是过程出现了，于是相关的方法论也就出现了。
这就是时间的成果。方法不是某个人或者某个组织的创作的。时间积累达到一定的程度，微软不提出某个方法，IBM也会提出这个办法。可能不是你自己使用这个方法了。方法并不神秘，因为他就是你今天正在做的、从事的和实现的。正如模式是一种方法，而模式就是你昨天书写代码的那个行为。只不过归纳抽取提成了这些行为的内在规律。
你看不到你做事的行为，也就不能理解模式作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验。过程伴随工程而出现，解决的是工程中步调一致的协作问题。那么工程适应未什么而出现的？很显然，软件规模的不断增大是根本的原因。
如果说工程关心的是“需求”、“配置”、和“文档”等等这样一些要素，那么这样的工程还是停留在技术层面的：关注的还是工程的实现细节，而非目标。从角色的角度来看，这是项目经理和技术经理所共同关注的那一部分。然而项目经理还必须关注人力资源、项目资金以及多个项目之间的协调等等。这些与工程本身并没有直接关系，而是组织方面的内容。所以在工程环节中“文档管理”和“配置管理”等等中的那个词汇管理，是管理的具体技术和方法：而在组织这个环节中的管理，才是真正的管理学上的用词。我在这张图上，试图从这个角度上来说明：作为项目经理，你必须有一部分是非技术性的.甚至你可能绝大部分的工作是非技术性的。因为与技术相关的管理技能可以由开发经理来做，或者公司对于这一方面有交通已且成熟的规范，因为无需投入过多的精力。你必须俄更关注与这个工程的组织和计划。站在组织者这个角色上。