作为项目经理，怎么组织评审？

llyn

好贴，小弟刚刚开始作项目管理，听到各位前辈的论述，受益非浅啊。谢谢

rainerchy

准备、实质、真诚、投入、总结
学习了

smileking

两点
评审资料的完整性需要确认
评审人员需要前期确认设计存在的问题点
评审并不是找一堆人在一个时间去找问题，而是应该大家把自己所看到的问题拿出来一起沟通讨论

eleanorboy

针对项目的阶段不同，评审的也各有侧重点，而且正确的人才能做正确的事情

jeffliu1973

先看评审体系和标准是否完善，如果很粗糙，没办法控制好的

happybaobei

很多公司都是走过场的，如果PM本身不懂技术，其实很难控制这样的评审是否有效

foxtianxue

进步了~~~~~~,顶顶

jeffliu1973

PM懂不懂技术不重要，反而很多PM因为懂技术而站在技术立场看项目，最后项目跟着技术走，到最好项目管理非常被动。PM最重要的是运用项目管理控制方法对项目进行控制，而不是跟着研发人员走。但是目前很多PM不懂项目管理控制方法，所以导致项目很难控制。

szron

JEFF说的也很有道理,

lisha

都是高手，多多学习！！[em14]

luoye

我也觉得ＰＭ不是需要懂技术的，如果ＰＭ很精通技术，那我们的技术骨干不是要失业了吗？每个人的分工不一样，我们只需要作好自己份内的事情就好了！

Businessman

看了楼上很多的高手都回答得很不错。
我觉得设计评审，关键在一下：
1。首先是设计师的个人水平；尤其是专业能力及看待问题的面，不能仅仅拘泥于自己的工作。手机产品是系统工程。
2。设计评审是设计过程的一个重要的点，在ISO9000和CMMI体系中都有明确的要求。目前依我所见很多企业是设计评审前不准备，设计评审会议上大家相互扯呀，说呀！很不具备系统性，也没有抓住问题的本质。所以建议评审前做好详细，周密的安排。例如评审的资料，评审会议的提前通知，需要评审主要的问题点，必须参加的人员等；
3。评审后的会议总结暨问题点的追踪，验证。很多评审中的问题点是需要验证，还有很多是评审中发现的新的问题都需要在评审会议后继续安排，落实。
以上是我的建议。谢谢！[br]<p align=right><font color=red>+5 RD币</font></p>

jndx

事情是这样，一个公司的研发人员不够，一个设计了别人没仔细考虑审核确实后续生产会存在问题。

ydwyp

ding [em08][em08][em08]

moralthief

高人们从理论上都说的面面俱到，我想LZ也不见得不知道这些，难就难在落实上。

因此，评审究竟是走过场，还是真的要找问题，大家在认识上一定要一致。

我的实践是评审对管理人员来说只是管理进度的一个手段，因为其他标志都无法反映进度，如正在熟悉资料，正在设计，正在检查等，都可以一拖再拖。但这样评审往往会成为后续发现问题时研发人员的一个借口，如既然评审过了，出现问题当然要评委负责了。如果陷进这个圈套，如何评审都无法走出来的。毕竟产品质量是设计出来的，不是评审出来的，如果研发人员不认真工作，如何组织评审都无法改进的，除了换个人重做。


[br]<p align=right><font color=red>+3 RD币</font></p>

jonas123123

学习

oglala

<DIV class=quote><B>以下是引用<I>toon</I>在2006-9-20 13:37:00的发言：</B>
1. 目标设置过高
"期望原理图没有问题，封装没有问题，有良好的可生产性",
是完全没有问题,还是希望发现设计中存在的问题? 我认为通常应该是后者. 除非你的团队确实有着丰富的经验,那你可以尝试把前者作为目标. 但是很可能"完全没问题"只是良好的愿望.

2. 邀请合适的人参加,每个人都要能够作出贡献,否则就不要邀请.
懂原理图、熟悉封装、精通SMT工艺, 可能不是同一个人, 你可以邀请多个专家参加,群策群力.

3. 最重要的一点,你自己都觉得评审是一种形式,那么它很可能真的变成走过场. 所以评审的组织者很重要,事前需要和大家很好的沟通,不断的明确强调评审的目的. 需要让参加会议的人感到这个会是有价值的,否则就会陷入恶性循环.

<P align=right><FONT color=red>+3 RD币</FONT></P></DIV>


說的太好了。！！一次成功的評審就應該從這集點入手。。
[em26][em26]

ziji

好!学习了解中.谢谢!

jamesbond

很多情况下是外行在指导内行

review过程实际上是找问题，在操作中不可能每个人的idea样，于是基于不同的理解每个人都有不同的意见，如果没有一个书面的check list样式的文件来统一指导，那么很可能越改越乱。于是潜在问题没发现，没有问题改出问题

而所能提出的意见，也仅仅是表面上看的到的如placement位置，route线宽等一些空间方面的更改（暂且不论这些更改是否改善或是引入更多问题）。而逻辑原理、PCB varify等深层关系到短路或者断路等硬性致命问题却不能够发现.例如RD考虑可靠性，生产考虑可制造性，sourcing考虑cost，其优先级不一样，一定是RD&gt;Menufacture&gt;Supply Chain。如果RD得不到最直接的support与优先照顾，那么做出来是什么就不知道了。有时候本末倒置是在一些管理混乱的公司中经常出现的，到最后流于形式化而RD是最直接的被驱使作业与承担责任的部门，这样的结果就是出现一系列的严重问题而技术力越来越差。

另外，有楼上说PM不需要懂技术。一些大公司（特别是日系IDH），PM就是项目监督，如果不懂技术，就很难驱动各部门有效沟通，因为一些决策是需要PM自己做出的，而不是分派到下面的工程师来完成，如果PM只是按照schedule来排会议，组织工作，很多情况下不是项目成功量产而是中途cancel[br]<p align=right><font color=red>+5 RD币</font></p>

RD25

不赞同！
相比盖一做大楼，建一个地铁，造一处基站，手机研发领域其实是相对的较小的项目管理领域
这需要项目经理不只要懂得基本项目管理，还要掌握更多的硬件、软件、结构、射频、生产等等，如果连原理图正常几天能完成，pin角定义都看不懂，何谈项目时间管控！
不希望你懂的那么多，但起码你要懂得多些，我们需要更专业的项目经理！