在一个公司里，销售以及开发二个建制部门之于公司，犹如龙头之于舞狮队伍；尤其是在目前这个多批小量，用户需求迥异，产品开发周期短促的快速反应时代里，公司对于开发部门的有效管制一直是个难题。其实，开发部门虽然非常难管，但却也是最好管的！难管是因为：如果未能管理到要点上去，工程师是不会轻易接受管制与羁绊约束的，即使他们在表面上接受，其内心也可能行消极之实；一旦工程师想要给你出点难题来刁难你，你可能只有干瞪眼（如果管理者不熟谙技术的话）！不过，我始终认为，开发部门其实是个最好管理的部门，因为工程师的需求并不很复杂，多数技术人员是非常好管理的，他们肚子里的花花肠子很少，一旦作为一个管理者你的用心，你的人品以及你的管理能力被工程师认可后，他们大多会去努力工作，尽职尽责的，在很多公司里一般最拼命的部门也是开发部门！所以开发部门的首长用心去管理是第一要务的（开发部门首长工作能力的好与坏直接关系到开发的效率与成本！），光靠简单的组织任命与权利赋予是没有太大作用的，需要我们技术管理者通过实际工作来树立起自己的威信！需要我们倾心的管理，更需要我们科学合理的工作方法以及适应对路的管理制度，这些才是我们研发工作得以实现有序发展的要件。

一般的开发部门（有的会把研发部与技术部门加以分开，研发只做设计的前端，技术部门快速接手去实现其产品化），所采用的管制模式大同小异，在职能建制形式上很多企业将其分成：硬件设计部分，软件设计部分，结构设计部分（ID以及MD，有的还包括平面设计），技术标准化以及项目跟踪管理部分（有的公司也叫做信息管理中心），这些大致职能模块是企业跑不掉的组织建制模式，基本沿用的是前苏联的模式，做起来也是比较得心应手的。

把研发部与技术或工程部门分开后有利也有弊，利的是研发与产品设计工作可以分工较细，实行类似流水的作业模式（适应多批小量模式），让那些高级工程师专门攻克技术难关，做最难的前期开发，利于开发部门集中精力做全新的设计，不被后端生产作业异常处理以及技术保障的繁琐事物拖住后腿，可以全力前冲；但对人力资源的利用则有所损失，如果研发和技术部门不归同一个上级领导，其资源浪费则会更为突出，其人员总数有可能要多出20%以上。对小型企业不建议将其分开，但在具体操作与执行时，在内部的分工上可以适当加以区分，以便给骨干工程师腾出更多的时间去研究新技术、设计新产品，而把一些诸如技术文件的出具，产品的DEBUG，产品的测试等工作交给技术等级略低一点的人去处理。

对锁设计产品的的技术评审及其管制，必须有章法！！现在很多企业表面上管制得很严格，但由于没能管理到要害处，实际上仍然是在听任工程师凭借其自身的感悟在自我把握与全权处理，这样做的风险很大！也很不科学！造成此类的主要原因可能与企业高层对技术管理的一知半解所致，在组建企业技术管制模式时生搬硬套，搞得技术管制不伦不类，非常之可惜！技术管理是企业最大的软资产与积累。

目前，多数企业设计模式的内核部分基本还是参考日本的三段式设计：初步设计，详细技术设计以及工作图设计三个阶段，有的则是加以归并。

在一些企业里，对研发以及产品生产的精确定义还有待明确，我们做产品设计以及生产是以技术图纸与技术文件为准的，必须依靠技术文件去指导生产、指导测试与采购，但有不少企业还是依靠人治、依靠样机来指导与操作，用人道德思想去指导，把设计理念装在工程师个人的脑子里，技术人员一离职，就会陷于频繁的救火性事物之中，非常被动与可惜，中国很多企业目前正在保守此类不当的损失与痛苦！这是典型的东方‘游击队’式的设计模式（打一抢就跑，做几票就走的思想），贻害无穷，后患无度！我们做设计时必须充分考虑到设计人员变动问题，其他人员能否顺利接受，如果接手工作困难，就说明设计是有明显缺陷的！是需要改进的，也说明管理者有工作不到位的地方。

依靠人治是很痛苦的（但如果完全依靠法制而彻底摒弃人治也是不行的!），设计思想以及技术支持都装在工程师的脑袋里，知道与了解信息多的人忙得要死，了解少的人则闲得悠然自得！但不幸的是目前我国80%以上的中小企业，仍然是依靠着人治来推动整个企业的生存与发展，在那里做得很苦很累，也有点很窝囊，企业主都很想加以变革，但实施的结果却鲜有如人意的。

在现代这个非常倚重团队的时代里，设计评审是产品设计的生命力所在（因为只有这样才能发挥骨干工程师对次等级工程师的指导与设计约束作用），所以企业需要投入相当大的精力去找寻好的评审方法与途径，对企业的评审流程需要有针对性的加以设计与优化，不能生搬硬套，在A企业用的很好，但也许根本就不适应于在B企业用；不过，我们评审的诸要素是基本不变，就是设法不断靠近最优最适应的设计方案，争取把技术问题点在早期给发现并加以及时剔除，也就是发挥大家的力量来弥补个人力量的不足与欠周到，规避设计风险与不确定度。

对于设计评审有一个很现实的问题，就是大家工作都很忙，经常是无法抽出更多的时间来仔细了解被评审设计件的主要设计要素，评审有时会流于形式！对这个问题必须加以关注，否则，设计评审只能基本依赖领导的主观臆断了，我的做法是通过几年的摸索逐步制定出一般性的评审内容与要素，罗列出一般性的设计用例，总结出一些设计的潜在问题点以及应对的方法，要求被评审者必须提前二天把东西给到相关人员并加以消化，在评审会议上评审委员必须发言，而且要对言行负责任的，开始这样做，工程师的抵触情绪不小，多有牢骚，但这个必须加以坚持，一旦形成习惯也就被认可了，因为这对大家都有好处，今天评审你的设计，后天就会评审我的了。对于能力强的工程师在评审时的工作付出，需要以一定的形式给予其经济上的弥补，我是以研发工时的形式加以补偿，每做一次评审，我对其做个记录在案，记录大致花费的时间在评审上，年底时给予一定的经济补偿！起码我要让工程师知道，对他们的付出，我是会考虑适当的补偿，这样才能把评审持续有效的做下去。

通过设计评审，可以让新手在设计时规避那些前人已经犯过的错误或可能出现的设计不当，这些就要在评审或者是产品设计会议时就加以交流与传承。

对软件代码也需要加以适当评审，很多企业基本对此是放任自流的，这很可惜，也很危险，对此，不少企业也付出了不少的代价！尤其是在软件架构设计的科学性与合理性上，在软件设计的可复制性上！在工程师力量不足或者是素质不够的情况下，我们也可以采用笨的办法来走审，就是由工程师自述其总体方案设计，对模块的设计，对接口的定义，对涵数的处理与定义，对调用与跳转的理解与处理，对其设计通用性与可借用性的处理，通过这些技术设计要求来制约工程师过多的个性化设计，以期达到设计件的可复制与可借用性，把人力资源发挥到最大，千万不要听任设计师自己去发挥，那样的话，很多本来可以互通互用的东西就会被残害掉了，工程师不喜欢拾人余唾，喜欢自立新门户，对这点必须加以打压！当然，在强制实施这个的过程中，工程师是很反感的，但必须坚持，同时，要用心去化解矛盾。

在处理多批小量，交期紧张的定单时，对产品设计的通用性与可复制性要求很高，做成模块式，插件式，组合式设计，如果做不到这点，那肯定会忙得混天黑地，还收效甚微，有时为了更快地出产品，在设计成本上可以做些让步，在设计的前期就考虑到其它的设计要求，尽管这样做需要增加一些成本，但这是应对快速设计的必须！

对于技术管理制度，我的理解是做到的必须写到，写到的必须做到，否则，就不要去写，不要去做出要求。对于制度不要追求完美无缺，这是技术人员最致命的缺点，喜欢追求完美，所以老是搞不好，总是不满意！我的作法是抓大放小，抓住主要工作面，别太求全责备，别搞得太繁琐，把人搞得疲惫不堪，我很赞同‘缺陷美’，制度或者是产品带有一点缺陷并不可怕，只要我们不断去改进与优化就可以了，如果考虑得过于周详，一个产品设计或者是一个政策老是出不来，老是在完善中，那就不能发挥其作用，等到能出台一个完美无缺的东西时，已然是明日黄花了，没有任何用途了，所以时效性很重要，对于那些追求完美的管理者或者设计师，需要我们去引导，必要时可以适当采取措施施压，这样才能让其及时出成果。

项目管理是产品研发的重头戏，很多企业于此间很是头疼，所以项目周期与质量成本的平衡是管理的追求所在，由于东方人的特点所在，一味而单纯地去采用项目管理软件工具并不能很好地推动项目进度，因为人思想问题尚待解决，工程师要想给项目找个ＤＥＬＡＹ的理由，非常容易！所以软件工具需要采用，对人的管制与对项目的跟踪也是少不了的，对一些重点项目还是需要采用原始的人盯人的笨办法。如果企业能真正实施项目奖励的话，那项目管理会好很多，但需要注意平衡利益关系，否则会引起其他辅助人员的消极抵抗（类似的教训不少！）。

关于快速开发的问题，也是个老生常谈的问题，大家都想能够快速出成果，但不同企业的实际效果各异，我的体会是必须要在制度与人的思想上动手，方法与观念不改变，很难做到满足市场需求，只有让工程师发自内心的认识到，产品与市场的紧密度才行，所以需要把工程师不断派向一线市场，了解一线市场的真实状态与实际需求，否则，工程师还是会你说你的，他做他的，老死不相往来！以致闭门造车依旧。