October

1、首先，苦恼来自于追求完美。程序员总是将做事的方式向追求完美的方向调整，然而现实是产品目标更加重要。2、其次，苦恼来自由他人来设定目标、供给资源和提供信息。这其中既有责任与权威不匹配的问题，也有信息不对称的问题。对于程序员而言，他所承担的责任总是大于他所拥有的权威，然而这都是暂时的，在现实情况中，实际的权威来自于每次任务的完成。对于架构师而言，供给的资源由项目管理人员或者技术总监来决...

目录1、首先，没有一个很有效的估算方法。2、我们采用的估算技术隐含的假设人和月都可以互换，错误的将进度与工作量相互混淆。3、由于对自己的估算缺乏信心，软件经理通常不会有耐心持续的估算这项工作。4、对进度缺少跟踪和监督。5、当意识到进度的偏移时，下意识的反应是增加人力。 在众多的项目软件中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影...

目录 why what how who when why 在系统设计中，概念的完整性应该是最重要的考虑因素。也就是说，为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕他们其实包含着许多很好的设计。 what 概念完整性不仅仅包含业务领域上的概念...

架构师的交互准则和机制牢记开发人员承担创造性和发明性的实现责任，所以架构师只能建议，而不能支配。 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法。 对上述建议保持低调和不公开 准备放弃坚持所有的改进建议什么时候容易出现画蛇添足在开发第一个系统时，架构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以会谨慎、仔细地工作。第二系统是设计师们所...

假设一个项目经理已经拥有了行事规范、富有经验的架构师和许多编程实现人员，那么，如何确保每个人听到、理解并实现架构师的决策。下面给出一套实现上述目标的方法，它们对于软件项目同样适用。文档化的规格说明--手册手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；他应该是产品经理或架构师主要的工作产物。形式化定义很多工具可以用于形式化定义，例如数据库设计范式 形式化定义等，形式化...

在满足技术条件、目标清晰、人力充足、材料丰富以及时间充足的前提下，为什么项目还会失败？因为缺乏两个方面，其一是交流；其二是交流的结果-组织。1、项目的交流方式1.1、工作手册是项目必须产出的一系列文档进行组织的一种结构。使用项目手册的一个原因是：里面不仅仅记录了设计思路，还有很多项目演进过程中的信息，甚至可以追溯到项目最开始阶段的设计资料。另外一个原因是：控制信息发布，这不是为了限制信...

项目的少数文档成为关键的枢纽，每个项目的管理工作都是围绕它们运作，它们也是经理们的主要个人工具。少数文档包含哪些内容呢？任何管理任务的关注焦点都是时间、地点、人员、项目内容和资金。正式的文档结构应该如下部分：内容：目标。定义完成的目标、迫切需要的资源、约束和优先级。 内容：产品技术说明。以建议开始，以用户手册和内部文档结束。速度和空间说明是关键部分。 时间：进度 资金：预算 地点：工作...

第一个系统大概率是试验性的对于大多数项目，第一个开发的系统并不合用。它可能太大、太慢而且难以使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的办法。因此管理上的问题不再是“是否构建一个试验性的系统，然后抛弃它？” 而是你必须这么做。唯一不变的就是变化不应该将所有的目标和需求的变更都整合到设计中，如果这样可能开发不出任何产品，应该循序渐进。为变更设计系统功能模...

是否需要里程碑 如何根据一个严格的进度表来控制大型项目？第一步是制定进度表。进度表上的每一件事成为“里程碑”，它们都有一个日期。这个日期是估算出来的，很大程度上依赖以往的经验。里程碑的选择只有一个原则，那就是里程碑必须是具体的、特定的、可以度量的事件，能够进行清洗的定义，具体的里程碑应该是百分之百的完成的事件。如果里程碑是模糊的，那它将成为难以处理的负担。关键路径...