设计项目管理

项目管理 设计老鸟告诉你设计开发的全流程 (摘自网络:) 我曾经是个机械设计师，也曾经带过设计团队，或许今天我的工作离机械很远了，但骨子里，我一直都还是个机械设计师，估计不论多少年，这点不太会改变。 看到好友提了这个问题，那我就分享下我的想法。 还是从字面上来看，机械设计，何谓设计, 设就是从无到有的过程，计就是复核校验，合在一起，所谓设计，就是一个按照某个要求从无到有并且经过验证校验过，符合全需求的整体过程，是对一个需求的统筹规划的过程。 那么所谓设计，其实就是在谈怎么去满足客户的需求。 为了方便说明，我简单画了张图来解释一个设计的需求是如何被满足的。 为了偷工减料和节省时间，我把项目经理和产品经理以及决策点放在了一起，从的角度来说这是错的，请细心的朋友不要把这个问题放大，这只是我偷懒的做法，不想这张图太夸张(同时也为了防盗版)，而图中的流程和活动大致是正确的。 项目的阶段划分也被我尽可能的精简过，以适合大部分的制造企业。 ? 这只是需求传递的过程，其过程中涉及到了整个设计开发的整体流程，这里就不详述了。 一个设计从最原始的需求开始，需要被业务部门审核，迭代，确认技术可行性，财务规划，预算等等一系列的过程。 需求收集是一个漫长和负责的工作，我们可以借用KJ，头脑风暴，脑力书写法，德尔菲法，强制连接法，奔跑法则，Blitz等等来进行收集。 做出立项并完成一个产品设计必须要满足这样几个条件: 1.符合公司的策略(要么财务上的直接受益，要么战略上某个部署的实施) 2.风险是被识别，而且有可控的风险应对 3.企业有足够的资源来完成项目 4.确保业务是真实的 5.确保我们是可以拿下这个业务的 6.我们做这个业务是值得的(这属于项目组合管理的范畴，不展开了) 以上的最后三条是常规问题，就是Real, Win, Worth，这是项目决策的基本要素。 当决策机构确认了需求，并决定投入资源去开发设计这个产品之后，那所有的需求都应被汇总在一份文件中，由于原始的需求是难以识别的，甚至是非常宽泛和笼统的。产品和市场部门是有义务将需求转化成企业内部可识别的语言的，这样的一份文件我们可以称之为产品需求文件PRD。 而从原始需求到PRD的转换也是一个痛苦的过程，可以借用质量功能展开QFD1.0来完成，通过矩阵式的扫描来获得工程部门可识别的需求。 而这时，项目经理也可以根据被转换和识别过后的需求来定义项目计划和工作结构分解WBS。 那所有WBS确立完了之后，相应的工程师才会接到相应开发设计的指令，以及明确的开发目标，这些目标应该是与PRD中的描述是完全一致的。而且按现在质量学和项目管理的理念来说，我们并不需要提供超出客户期望的功能和服务。 要开始真正的产品设计，之前应已完成概念设计，这是一个高度概括和粗略的整体规划。只有当这个概念设计被客户充分认可之后，才能开始后续的设计。(哪怕是主动开发的产品，也一定是先做过市场认可度的调查，才能开展后续的工作。) 在设计工程师开始详细设计之前，应先完成DFMEA，FMEA作为一种风险预判断的工具，应成为产品的的指导性文件，并确保产品设计时充分考虑了实际使用的状态，并作出预判断和预应对。同时，从PRD或者QFD1.0也可以得出产品设计的大纲，成为后续设计的重要指导。 在产品的详细设计时，应充分考虑客户的需求被满足的情况，以及各种极端的可能性，很大程度上CAE的分析正是基于这样的一种理念。所有的CAE模拟都应与DFMEA中的描述，以及PRD中的需求描述一致。 DFMEA可以成为PFMEA的重要输入，但不是强制输入。FMEA是一种结构性的工具，是可以参考历史资料的，尤其是PFMEA，对于一个成熟企业来说，是积累了大量的经验的。在没有DFMEA的情况下，依然可以制作PFMEA。这份文件将成为产品设计最终实现的重要依据，也是后续各种生产制造的基础文件。而如果我们继续沿用QFD的话，这里QFD3.0将成为PFMEA的另一大重要输入。 所有的工艺细节以及流程，均应以满足并且实现客户需求，不损害客户利益为前提，而不是以自己的便利性为导向。以确保产品设计的意图被100%实现。 所有的设计都免不了验证(V&V)，无论是verification还是validation都在证明一件事，那就是客户的需求是满足的，而且是可以很好的批量生产制造出来的。控制计划CP和质量检验计划QIP，还有各种WI,SOP等文件，几乎所有的生产用的文件，都是为了这个目的而存在的。 只有这一切都和最初的PRD中描述的需求是完全一致的，而且是符合企业量产能力的，那我们才能说我们的设计完成了。 这时，最终的产品规格书PS，才算是定型下来。最后依然要再回过头去，检验最初的需求满足情况。 一个需求是需要闭环控制的，以确保需求在传递的过程中，没有发生重大的偏差，我们不喜欢任何的惊喜。 至此，我们才能说一个设计完成了。 简单说，我们要把客户笼统的需求，变成一个实际工程可识别的语言，转化成可量化的设计指标，然后由设计师按这个设计指标设计出实际的产品，然后进行相应的风险评估，然后通过设计验证确保设计是可用的，且是可以被批量生产出来的，最终再与客户的指标进行相互匹配的全过程。 其实一个设计，就是一个项目，回到项目的定义:在一定时间内为了某个特定目标所完成的产品，服务或者流程。 那么项目的所有的属性也就是一个设计所需要考虑的因素。 套用PMBOK的说法，范围，进度，成本，质量，人力资源，风险，沟通，采购，干系人，甚至更多的要素统统都是，最后整合在一起，也就成为了一个设计。 如果在一个设计工程师眼里，他只看到了一个产品一个功能，或者当前一个特定的设计活动，那他永远就只是一个底层工作人员。前几天我们在聊如何跳出平庸，这里其实就是一个例子，希望每个人都能清楚的知道自己在设计环节里的位置。或者今天你只是在做其中的一件事，但只有你知道了全貌，才能憧憬自己未来的发展。 设计也好，别的工作也好，做到后来，都归结到了两个词上面:Methodology & Philosophy。 也就是系统方法论和理论哲学的问题，这几天老鹰也提到了技术哲学，这是非常好的思考。 最后之所以强调方法论和哲学，是因为一个人的创造力是有限的，我们不指望我们都是天才，那如何通过有限的才华来创造无限的可能,那就是方法论和哲学能带给我们的了，当你熟知设计的全流程，熟知设计的要素和精髓，那哪怕你的所学有限，但你可以通过对经验的归纳和总结，通过不同的排列组合，然后找到问题的新解法。 典型的方法论就是Triz，一种简单但实际的傻瓜式创新方法，已经被普遍的用于产品设计领域了。