作为项目经理，怎么组织评审
分类： LINUX
评审是研发各个节点的总结，是质量的保证，可实际上我每次组织的很难达到预期的效果，不知大家怎么看？
比如PCB投板评审，我们总是期望原理图没有问题，封装没有问题，有良好的可生产性，因为这个目的我们才组织去做PCB评审，然而实际的情况，参与评审的人员需要会懂原理图、熟悉封装、精通SMT工艺，实际上这很难做到，评审也就无法达到目的， 最后成了浮于表面甚至走过场的形式，不知大家有没这种感觉？
1. 目标设置过高
"期望原理图没有问题，封装没有问题，有良好的可生产性",
是完全没有问题,还是希望发现设计中存在的问题? 我认为通常应该是后者. 除非你的团队确实有着丰富的经验,那你可以尝试把前者作为目标. 但是很可能"完全没问题"只是良好的愿望.
2. 邀请合适的人参加,每个人都要能够作出贡献,否则就不要邀请.
懂原理图、熟悉封装、精通SMT工艺, 可能不是同一个人, 你可以邀请多个专家参加,群策群力.
3. 最重要的一点,你自己都觉得评审是一种形式,那么它很可能真的变成走过场. 所以评审的组织者很重要,事前需要和大家很好的沟通,不断的明确强调评审的目的. 需要让参加会议的人感到这个会是有价值的,否则就会陷入恶性循环.
Toon分析得有道理, 设计需要经过功能测试, 制程验证等手段进行发现问题并改善. 而评审的目的是尽量避免问题的发生, 把问题在发生前解决当然是上上选, 可确实是我们的希望而已.
此类会议的必要性要看公司及项目情况, 如果硬件工程师和布线工程师经验丰富, 有相应的 check 工具和比较系统的 review 流程, 大可不必兴师动众. 如果实际情况是经验不够丰富的工程师, 各个项目时有制程等问题发生, 又是全新的产品, 此会议定要重视. 而要重视就首先要让上层重视, 每件事情都有 input 和 output, 没有被上层重视的时候最好利用 output 的结果来推动 input 的改善, 有很多很好的工具和手段啊!
作好几件事儿：
1、每个项目一个Check List，列出需要评审的条目，避免遗漏，尤其一些关键点；
2、每个项目一个Issue List，记录每个阶段曾经发生的Issue，有的放矢，尤其是上一阶段发生需要改善、验证的条目。这些Issue包括ID、MD、HW、SW等研发Issue，也包括ALT、Field Test、QA、Sourcing等反应的问题；尤其生产反馈的问题；甚至包括其他项目发生过的问题。
3、如果是正规设计公司，应该有项目阶段目标、各设计部门有自己的Check List。如果没有，推动你老板建起来。
4、如是新手，评审时最好有高手或老板替你压阵。
5、更重要的，是“功夫在诗外”，包括个人知识、经验积累、平时对项目状况细节的掌握、与工程师良好的互动关系（PM别把自己当成“官”，你平时要替他们解决困难或扫清障碍）.....
这就差不多了。
PCB发版，公司如果有流程，可以根据流程和项目的特点进行裁减和增加，形成具体项目的评审流程和评审列表；如果暂时还没有，需要协调有经验的工程师，初步拟定一个，然后召开课题组会议，根据项目的实际情况和公司的实际情况，完善流程和评审列表。
流程方面，主要明确各个评审阶段和大致的控制目标（整体设计/单元设计阶段、样机开发阶段、试制阶段、量产阶段），逐步完善，过程中改进。
评审列表，涉及方面很多，主要原理图评审、PCB LAYOUT评审。如果是以往平台上开发，单元电路和整体设计应该没有大问题，需要调查以往的问题列表和解决情况，进行对应。新增加的功能，需要确认部品规格和单元电路设计、与射频、基带等单元部分的接口，在匹配、逻辑、过流、过压、静电等方面进行考虑。如果是新平台，比较麻烦。
PCB LAYOUT评审布局合理性，关键部分走线，如各路电源的滤波、走线；模拟信号、参考信号、时钟的处理，关键电路屏蔽和隔离、抗干扰、静电处理等处理，需要建立列表，逐一考虑；PCB结构工艺，相互干涉问题，装配合理性；PCB电路工艺，工装夹具、测试软件通用性，售后维修升级问题；
评审的时候，需要请有经验的工程师参加，态度要诚恳。事先组织会议室，安排会议日程。会议中相互尊重，共同攻关，塑造良好的团队氛围。
以上供参考，不对的地方，请大家多提意见。
谢谢13楼的意见。我觉得评审列表比较重要。还有每一个设计单元的审核人员责任要明确，不要大家在一起做好人，放过问题也没有什么责任。
另，每一个项目都需要有一个问题清单，以便后续的项目参考。
项目经理一定要正直，对事不对人。只有你自己先认为评审是必须且有效的，才能保证你的Team也认真对待这件事情。
有些评审的项目我觉得是不是应该放在之前做，而不是之后，是不是会更好呢？
首先，从原理图的角度，之前应该有详细的需求设计或者详细设计之类的文档对应于具体的产品需求，这个时候就应该考虑到元器件采购、生产等各个环节，该部分的文档应该由设计人员提供，然后由项目经理组织评审一下，是否足够完备等，从产品的角度，项目经理或者别的人员肯定会有自己的理解，这个时候先在文档阶段尽可能的做到准确，这样为原理图设计提供良好的基础，在原理图出来之后，大家的评审主要针对之前已经提过的内容（最好有个完备的feature lists），或者有了新的想法，都应该在这个时候提出，另外，就是对原理图进行核对，包括最基本的，连线命名、管脚接法等。如此，有两次的原理图评审后，应该可以定稿。
至于PCB设计，也应该在设计之前，出一个较为详细的设计要求，包括布局布线的详细约定、叠层结构、电地分割等，该文档出来之后，应该由各方面的人一起来评审，从多个角度来考察该文档是否已经足够完备，还需要补充细化哪些内容。如此确定之后的内容，可以避免PCB设计
的返工，大家如果做过PCB都知道，最讨厌的是好不容易快画完了却要从头来。有些评审会开在前面的目的也就是为了尽量减少这种返工的情况，避免浪费精力。
两个文档的评审应该是很关键的地方，能够影响后面评审工作量的大小。这不仅仅是个流程，也是个质量把关、提高设计有效性的过程。当然如果考虑到公司的人手等情况，可以做适当的调整。大家以为如何？
这在项目管理中称之为DR(design review).
首先根据项目内容的多少，变更点的多少，难度等等制定等级，等级越高，需要在出图前确认的内容越多。
需要哪些资料是需要根据公司自己业务关联。
但是项目管理表（记载一些功能啊，接口啊，还有进度啊），另外原理图，系统框图，我觉得这时候应该出较为详细的layout图，如16楼所说，主要IC位置，Connect位置，地的分割等等。
这时候也应该想好了，东西出来该做什么试验了。
如果是完全新的，有必要做DRBFM或者DFEMA，然后请人来Review.
请的人一定要敢于提问题，不管是多么弱的，只要是关于这个项目，都可以问。
所有的文档一定要详细。
另外，还想说的一件事，其实做项目，本身大半时间就是要来做文档的，单纯做设计的项目管理人员，估计这项目好不了。个人意见。赫赫
评审的功夫在评审前，不是在评审时来讨论和解决问题，所以评审前其实结果已定，有问题的地方还是有问题，现在可能暴露了；没问题的地方还是没问题。
评审依据是 各种测试结果，这里有全面的 手机测试计划，测试技术，测试报告
http://www.task-center.com/diary.asp?action=show&id=76
两点
评审资料的完整性需要确认
评审人员需要前期确认设计存在的问题点
评审并不是找一堆人在一个时间去找问题，而是应该大家把自己所看到的问题拿出来一起沟通讨论
PM懂不懂技术不重要，反而很多PM因为懂技术而站在技术立场看项目，最后项目跟着技术走，到最好项目管理非常被动。PM最重要的是运用项目管理控制方法对项目进行控制，而不是跟着研发人员走。但是目前很多PM不懂项目管理控制方法，所以导致项目很难控制。
看了楼上很多的高手都回答得很不错。
我觉得设计评审，关键在一下：
1。首先是设计师的个人水平；尤其是专业能力及看待问题的面，不能仅仅拘泥于自己的工作。手机产品是系统工程。
2。设计评审是设计过程的一个重要的点，在ISO9000和CMMI体系中都有明确的要求。目前依我所见很多企业是设计评审前不准备，设计评审会议上大家相互扯呀，说呀！很不具备系统性，也没有抓住问题的本质。所以建议评审前做好详细，周密的安排。例如评审的资料，评审会议的提前通知，需要评审主要的问题点，必须参加的人员等；
3。评审后的会议总结暨问题点的追踪，验证。很多评审中的问题点是需要验证，还有很多是评审中发现的新的问题都需要在评审会议后继续安排，落实。
以上是我的建议。谢谢！
高人们从理论上都说的面面俱到，我想LZ也不见得不知道这些，难就难在落实上。
因此，评审究竟是走过场，还是真的要找问题，大家在认识上一定要一致。
我的实践是评审对管理人员来说只是管理进度的一个手段，因为其他标志都无法反映进度，如正在熟悉资料，正在设计，正在检查等，都可以一拖再拖。但这样评审往往会成为后续发现问题时研发人员的一个借口，如既然评审过了，出现问题当然要评委负责了。如果陷进这个圈套，如何评审都无法走出来的。毕竟产品质量是设计出来的，不是评审出来的，如果研发人员不认真工作，如何组织评审都无法改进的，除了换个人重做