1、不能界定项目范围。“在这种情况发生时，一个简单的出差登记系统结果变成内建了完整的花费报销管理系统，项目费用、时间跨度和质量都留下不可避免的烂摊子……除了简单的登录真的不需要安全措施了？用户登录系统后真的不能够执行任何系统操作吗？”

　　自己亲身体会过，应该是需求不明确带来的困扰，后只能修修补补，推翻重来、重构，来不及了。

　　需求一定要明确？可是，敏捷呢？敏捷不是一步一步迭代的吗？

　　我想还是需要及时沟通。

　　2、网撒得不够宽。“我们都曾经犯过的一个错误是，只关注系统所有利益相关者中的一两方——通常受让人（为系统出钱的人）和终用户得到了全部的关注。

　　目前比较关注项目本身，关注进度，关注质量，偶尔关注成本（毕竟我现在没有这个责任）

　　3、只关注功能。“……除非系统表现出了全面的高质量（诸如性能、安全、可维护性等等），否则不太可能成功。”

　　做项目关注功能好像是首要的，毕竟是客户可以看到的成果，（性能、安全、可维护什么时候关注比较好呢？）性能，在架构时考虑，写代码时优化。安全，如何策略？可维护，接口，抽象，设计模式？

　　4、用方框和线条来描述。“[一个无所不包的]巨大的Visio图无法成为有效的架构描述，有两个原因：第一，它试图在单一表示中呈现太多信息；第二，没人真正清楚地知道你画的各种符号到底表示什么意思。”

　　UML？文档？用什么来描述？我们恰恰是用Visio/UML+Excel+Doc

　　5、忘了需要培养的过程。“在建造系统的时候常常需要小心的事物包括：开发者和测试者没法真正理解设计，他们不热衷或者没时间学习技术，以及还没有很好的工具支持的新技术，或者新技术会强迫人们以新的不熟悉的方式工作。”

　　有多少公司能做到？公司是工作的地方，有多少公司愿意给你时间？有多少公司有一个培养的计划？不要加班已经不错。如果在大公司，可能一直被挤压？如果在小公司，不要陷入项目已经谢天谢地，或这有时间，大家都是茫然的各干各的。

　　6、平台定义不精确。“光用‘需要Unix和Oracle’来描述你的平台是不足够的。你需要精确地说明每一部分具体的版本和配置，才能保证得到你所需的平台。不然如果有人好心为平台的某一部分升级了一个库，可能导致某些东西停止运作。精确定义平台你才能在部署中避免这样的情形。”

　　这个目前还没有碰到过，都是定义比较明确。如果想想开发时用的版本跟在客户部署时用版本不一样，万一客户是低版本的那可惨了。

　　7、对性能和伸缩能力想当然。“及早开始考虑性能和伸缩性，构建性能模型尝试预测关键的性能指标并定位瓶颈，在设计逐渐成型的同时投入到一些实际的验证性工作中去。这会帮助你提高对设计中不存在严重性能和伸缩性缺陷的信心。”

　　做项目的...好像都是做到具体模块才去想...

　　做产品...做了一个失败的产品，没有考虑这个（当时好像仅仅考虑层次）

　　8、自己发明安全技术。“多 年来许多系统所犯的一个错误是试图加入自己发明的安全技术来提高系统安全性。比如定制的加密算法，开发者自己编写的审核系统，甚至完全DIY的访问控制系 统。自家开发的安全方案基本上都是不明智的。虽然很多人都以为自己可以马上搞出一些聪明的安全技术，但通常都只是自作聪明。”

　　嘿，没有那么牛...

　　9、没有灾难恢复。“要想得到资源来实现系统的灾难恢复机制，其关键在于在若干真实的场景中，具体衡量系统不可用所导致的损失。如果你还能估算这些场景发生的概率，你可以用这两组数据去说服人们灾难恢复的重要性，并获得合理的预算去实现它。”

　　想过，没实际实施过（磁盘阵列，这个算吗？）

　　10、没有撤退计划。“确保无论在系统部署或升级的过程中发生任何事，你都有一份书面的、经过审查的、一致同意的撤退计划，允许你将整个环境恢复到部署之前的状态。”

　　没有，总是理所当然的不会出现问题。或出现问题再解决。