朋友说最近他在反思之前的一些做事方法，做项目和产品应当是“Quick and Dirty”。他是一个注重细节的人，在我看来会有些太过注重细节。
如果一开始就希望将所有事情做完美将直接导致进度的缓慢。而且当前的世界变化太快，在项目的初期项目的后继走势往往很难预料。如果项目无法很快的推出、反馈、进化，很可能根本就没有机会发展。

所有展现给用户的功能都应当是完美的
“Quick and Dirty”并不是说产品可以是一个勉强可用的半成品。后台的实现可以Dirty，但展现给用户的绝不可Dirty。你可以除了核心功能外，其他啥附加功能都没有，但不可啥功能都有啥功能都Dirty。功能的缺失用户可以等，但已有功能的不到位就会让用户质疑团队的专业性及能力。

程序的Dirty是有底线的
有时候为了验证想法，用最Dirty最快速的方式实现想法是没有问题的。一旦想法被验证值得持续的投入，这时就应当考虑Dirty的成本了。项目短期的Quick很可能是今后无穷无尽麻烦的来源。这时候可以Dirty，但必须是可演化的，Dirty的部分可以在今后方便的改进或替换掉。