最近又开始写博客了，之前写的断断续续的。（很喜欢小团队的协作方式，大公司太麻烦了。吐槽结束）

    要做好真正的产品，产品经理要对质量负责，设计要对质量负责，程序员要对质量负责，测试要对质量负责，运维也需要对质量负责……。这里说的“负责”，不只是纸面上的责任，不是“我做好我份内事就行，最后产品能不能行，有人操心，我管不了”的工作态度，而是工作的使命感，自愿自发地从最终产品的角度来完成好自己的工作。我们已经无数次地看过这样的现象：产品质量无比差劲，谁都不能满意，最后追求起来，却是人人都没有责任。要解决这种问题，就必须把质量意识落实到每一个参与者身上(我曾经看过一本讲质量的书《质量免费》，说的也是这个道理)。

"设计科学"并不存在 ，把这个作为目标是误入歧途。只有坚持怀疑论（liberating skepticism），解放思想，才可能根据直觉和经验进行讨论。

这次来说说做K12项目遇到的问题（看不惯这帮老家伙自以为是）。

先说说第一大问题：设计模型

小项目，一个功能特点（或者叫亮点），通过规划，一步步成为一个产品，再衍生成一个公司。这是创业。

大项目，一个大战略，然后一步步做出来。主流是瀑布流 。这是典型的工程师的设计思维，纯理性模型。这样的理性模型好处在于，在项目早起就给出了目标的明确陈述、相关必要条件以及约束说明，方便团队的协作。该模型可以这样简述：目标，必要条件，效用函数，约束，资源配置、预算和关键预算、设计树。设计师一边做设计，一边进行设计树的探索，那么设计树上的结点实际上不是决策，只是暂定方案。

瀑布流

Royce对该模型的批评在于，尽管毗邻方块之极有反向箭头表示逆向的工作流，但是该模型仍然行不通。因为一个广泛认同的观念是，创新性设计并不是先把问题定死，再去寻找一个令人满意的概念解决方案；它似乎更像是针对问题的结构本身（或者叫问题模型）以及解决方案的思路这两者同时进行研发和完善的，这就包括了不断地在两个空间（问题空间和解空间）之间进行循环往复的分析、综合和评估过程的迭代。

产品流程图 

瀑布模型（spiral model，by Moehm&Royce）普遍存在的一个道理在于沟通需求和学术指导的本性都意味着一个占主导地位的设计过程模型被需要。

那么，如果问题空间和解法空间（需求定义和解法研发）共同“演化”（或者叫原型迭代，类似生物进化论模型即随机迭代和自然选择，虽然设计是强目的的选择）（得我有空画个图直观一些）。看到很多伪装成“设计-构建-测试-部署-维护-扩展”包罗万象的XX方法论（比如我现在的东家，摆出一副想高屋建瓴的姿态）。显然，我们需求更强调对于需求递进式的探索和构造，此外，该设计模型是没有一个收敛的过程。但是该模型并没有表示阶段里程碑和合同的节点。

此处不对比提被批评丰富多彩但相当不简洁的旋转木马模型。就拿鼎鼎大名的《The Cathedral and the Bazaar》大教堂与市集来说吧。该模型的运作机制就如同集市，开源社区的成员发现需求开发一个模块来满足需求。（买家以投票的方式通过增加在全球化的社区中以电子化形式表现的威望来给供应商回报。“威望”这种名的需求，马斯洛需求理论的自我实现这层在经济学上应该是得由其他收入养活开发者才行得通）

但是该模型的优势很明显，创造了一个开源文化的奇迹，这与愚蠢而无同情心的“为金钱而工作”以及“把我的知识产权发生的权益拿来”等心态真是天壤之别。而且，市场化的选择机制同样作用于产品缺陷修复过程。Roymond的大作，有很多真理、洞见和智慧，受益匪浅。列举几条。市场选择机制才是事实上的质量控制；所有设计过程都共有的关键要素在于对用户的需求、希望和验收标准的发掘，开源让“构建者同时也是用户”（这样需求必要条件、验收标准和鉴赏品味本能地来自于自身的经验，因为也充满了只可意会的技巧）。

所以当设计者只能用间接经验设计的生活，开源就行不通了。所以大教堂式的还是很有市场的。

再转场看看Boehm的螺旋模型（很多用Axure就是这么干的）。该模型强调的是原型方法，它主张远在异国可以跑起来的圆形成为可能之前，就从用户界面原型和用户测试起步。但其实这个换个角度想，这个设计仍是以设计师和产品为中心，而非以用户为中心。

-------------------------------掉书袋到这里------------------------------

这些里可以得出一些公认的东西一个正式的设计过程模型是必需的。目的是组织设计工作，辅助项目内部以及与项目相关的沟通工作，亦有益于教学。设计过程模式可视化的几何表示至关重要，因为设计师们擅长空间思维。对工程师来说，设计的理性模型是自然而然的。但线性的按部就班的模型具有很大的误导性，它不能反映出设计师的真实工作。理性模型在实践中一直存在，就是因为它简单的逻辑。

先告一段落