"我从25岁起在美国这个竞争社会待了37年,实在很想把那里的严酷告诉现在的年轻人.我之所以不只在日本出书,还在全球出书,巡回演讲,是因为我认为只有把自己放逐到批判的漩涡中,以"不能输"的精神奋战,才能持续磨练自己.一个国家如果没有几十人甚至几百人承受得住这样的锻炼的话,实在很难赢得世界的尊重"

作者只是以一个虚拟项目 - FUBAR.罗列出问题,实例和风险,而并没有提出他的解决方法.似乎FUBAR项目的这些问题并不是像常见的软件问题一样 - 用工具就可以解决. 很多情况下都是掺杂了一些政治因素.比如经理的升职,表面文章,以及一些人情因素,比如情绪化,leader缺少个人魅力...有几条比较"伪",过于政治了.

QUALITY OF WORK AND EFFORT(工作质量和投入)
问题:太多的东西要搞(算法设计,源代码,系统配置,设计架构文档,测试,缺陷跟踪,计划任务),太多而无法确保其符合标准和保证质量.
--其实这些问题可以通过流程化来避免,当然流程化还是需要很多文档.这个一直都是让人很头疼的问题.AUP似乎是一个方向 - 通过快速迭代,直接反馈,TDD来控制,同时减少不必要的artifacts.使用正确的工具和最佳实践,避免搞一些自己独有的东西.

PROJECT PLANNING AND EXECUTION(计划和执行)
问题:项目的计划和执行完全是建立在不现实/不可能的"政治考量"或美好愿望,而缺乏确凿依据(bottom-up grounding).必要和有用的事情反倒因为"没有时间"而被推迟或取消. -- 结果往往并没有因为取消这些事情而节约时间.
--这个应该是认知的问题,知识决定了是否可以在决定之前可以知道做这件事是否有价值.如果没有知识和经验,自然不会去冒险,"没有时间"是最好的搪塞.

QUALITY ASSURANCE AND PROCESS(质量控制和过程)
问题:质量控制(QA)的优先级总是很低.有过程却不遵守.缺少专门的人来评判软件是否是可接受的和管理产品发布.
--也是认知的问题,只看到表面的东西,而看不到潜在的可能.软件的复杂性导致软件很难被检验.而这个时候更应该重视QA而不是回避.觉得QA老是跟自己过不去.当然也有可能是QA太烂,让别人不得不忽略它们. 得!又是人和人的问题.

ARCHITECTURE(架构)
问题:缺少一个合理稳定的架构设计
--这个是老生常谈了.看架构师了.

APPLICATION PERFORMANCE(系统性能)
问题:架构设计时没有考虑到性能需求
--也看架构师的经验和能力

STAFFING(团队)
问题:大多数的人员不是很胜任,经验不足
--这个不是什么问题,有点像是借口.

PRINCIPLES(信念)
问题:开发者都被灌输:好心情,真诚,付出可以战胜一切.但真诚往往最终被用来评判缺乏责任感和承担后果.
--后面那句确实有点意思,有时候真诚反倒成为被别人利用.还是人和人之间的问题.难道真的无法避免囚徒困境吗?为什么会造就出这样的博弈??

INTELLECTUAL HONESTY(不明智)
问题:项目经理不愿意听到坏消息和问题,只愿意听好消息.
--也是人的问题.没什么意思,看人了.

查了一下wikipedia,FUBAR: fxxked up beyond all repair(recognition....)
"FUBAR has sometimes been used in software development in the almost opposite sense: "Fucked Up But All Right," meaning that the system design is fatally flawed, but works anyway."