研发与工程部门的运作思考.pdf

研发与工程部门的运作思考研发与工程部门的运作思考在一个公司里销售以及开发二部门之于公司，犹如龙头之于舞狮队伍；尤其是在目前这个多批小量，用户需求各异，产品周期短的时代，对开发部门的管制一直是个难题，总而言之，开发部门最难管，也最好管！难管是因为：如果未能管理到要点上去，工程师是不会轻易地去接受管束的，即使表面接受，其内心也会有消极怠工之虞，一旦工程师给你出点难题，你外行只能是干瞪眼！但开发部门也是最好管理的一个部门，因为工程师的需求并不是很复杂，多数技术人员是非常好管理的，肚子里的花花肠子不多，一旦你的用心，你的人品以及管理能力被工程师认可后，他们会去努力工作，尽职尽责的，在公司里一般最拼命的部门是管理好的开发部门！所以开发部首长用心去管理是首位，光靠组织任命的权利是没有太大用处的，需要技术管理者树立起自己的威信！威信、倾心管理、工作方法以及管制制度是管理顺利的诸要件一般开发部门（有的会把开发不技术部门加以分开，开发只做设计的前端，技术部门接手去实现其产品化） ，所采用的管制模式大同小异，在形式上分成：硬件设计部分，软件设计部分，结构设计部分（ID 以及 MD，有的还包括平面设计） ，技术标准化以及项目跟踪管理部分，这些是企业跑不掉的组织建制模式，基本沿用的是前苏联的模式，做起来也是得心应手的。

把开发部与技术或工程部分开后有利有弊，利是设计工作可以分工较细，实行类似流水的作业模式，利于开发部门集中精力做全新的设计，不被后端生产异常处理及技术保障的繁琐拖后腿，但对人力资源的利用则有所损失，如果开发和技术部门不归同一个上级领导，其资源浪费更为突出，其人员总数有可能要多出20%以上对小的企业建议不要将其分开，但在具体操作与执行时，在内部的分工上可以加以工作内容的区分，以便给骨干工程师更多的时间去设计新产品，而把一些诸如技术文件，DEBUG，测试等的工作交给技术等级略低一点的人去处理对产品设计的评审以及管制，必须有章法，现在很多企业实际上是在听任工程师凭借其自身的感悟在处理，根本就没有任何的科学性！主要是因为老板对技术管理一知半解，在借用其它企业管制模式时又生搬硬套，搞得管制制度不伦不类， 非常之可惜！ 一般企业的设计模式的的内核基本还是参考日本的三段式设计：初步设计，技术设计以及工作图设计三个阶段，有的则是加以归并在一些企业里，对设计的定义还有待明确，设计是以技术图纸与技术文件为准的， 必须依靠文件去知道生产指导测试与采购，但不少企业还是依靠人治依靠样机来执行与操作，这是典型的游击队式的设计（打一抢就跑，做几票就走的思想） 。

依靠人治是很痛苦的，设计思想以及技术支持都装在人的脑袋里，知道了解信息多的人忙得要死， 了解少的人闲得悠然自得！ 但不幸的是目前我国 80%以上的中小企业，仍然是依靠着人治来推动整个企业的生存与发展，做得很苦很累，也很窝囊，企业主很想加以变革，但实施的结果很少有另人满意的在现代团队时代里，设计评审是设计的生命力所在，所以企业需要投入相当大的精力去找寻好的评审方法与途径， 对企业的评审流程需要有针对性的加以设计与优化，不能生搬硬套，A 企业的很好，但也许根本就不适应于 B 企业，但评审的诸要素是基本一致的，就是采用最优的设计方案，争取把问题点在早期给发现并加以剔除掉，也就是发挥大家的力量来弥补个人力量的不足与欠周到对于设计评审有一个很现实的问题，就是大家工作都很忙，经常是无法抽出更多的时间来仔细了解被评审件的设计要素，评审往往流于形式！对这个问题必须加以解决，否则，设计评审只能基本依赖领导的评审，我的做法是通过一年的摸索并制定出一般性评审的内容与要素，还有一些设计的潜在问题点异以及应对的方法， 要求被评审者必须提前二天把东西给到相关人员加以消化，在评审会议上评审委员必须发言， 而且要对言行负责任的， 开始这样做， 工程师的抵触情绪极大，牢骚满天，但这个必须加以坚持，一旦形成习惯也就认可了，因为这对大家都有好处，今天评审你，后天就会评审我了。

对于能力强的工程师在评审时的工作付出，需要以一定的形式给予其经济上的弥补，我是以延发工时加以补偿，每做一次评审，我对其做个记录在案，这个可能花费多少时间在评审上，年底时一并给予经济回报！起码我要让工程师知道，对他们的付出，我是会考虑回报的，这样才能把评审做下去项目管理圈-PMP 实战圈 群： 24587579通过设计评审， 可以让新手在设计时规避一些已经犯过的错误或可能出现的不当，这些就要在评审或者是产品设计会议时就加以交流对软件代码也需要加以评审，很多企业基本是放任自流的，这很可惜，为此企业也付出了极大的代价！在工程师力量不足或者是素质不够的情况下，只有采用笨的办法来评审，就是由工程师自述其对总体方案的设计，对模块的设计，对接口的定义，对涵数的处理与定义，对调用与跳转的理解与处理，对通用性与可借用性的处理，通过这些技术设计要求要制约工程师的个性化设计，以达到设计的可复制性，把人力资源发挥到最大，千万不要听任设计师自己去发挥，那样的话，很多本来可以互通互用的东西就会被忽略掉，工程师不喜欢拾人余唾，喜欢自立新的门户，对这点必须加以打压！当然，在强制实施这个的过程中，工程师是很反感的， 但必须坚持， 同时要用心去化解矛盾。

项目管理圈-PMP 实战圈 群： 24587579在处理多批小量，交期紧张的定单时，对产品设计的通用性与可复制性要求很高，如果做不到这点，那肯定会忙得混天黑地，还收效甚微，有时为了更快地出产品，在设计成本上可以做些让步，在设计的前期就考虑到其它的设计要求，尽管这样做需要增加一些成本，但这是应对快速设计的必须！对于技术管理制度，我的理解是做到的必须写到，写到的必须做到，否则，就不要去写，不去做要求，对于制度不要追求完美无缺，这是技术人员最致命的缺点，喜欢追求完美，所以老是搞不好，总是不满意！我很赞同‘缺陷美’，带有一点缺陷并不可怕， 只要我们不断去改进与优化就可以了， 如果考虑得过于周详，一个产品或者是政策老是出不来，不能发挥其作用，等到能出台一个完美无缺的东西时，已然是明日黄花了，没有任何用途了，所以时效性很重要，对于那些追求完美的设计师， 需要管理者去引导， 必要是要加以压制， 这样才能及时出成果项目管理是开发的重头戏，很多企业于此间很是头疼，所以项目周期与质量成本是该管理的追求所在，由于东方人的特点所在，单纯地去采用项目管理软件工具并不能很好地推动项目进度，因为思想问题尚待解决，工程师要想给项目找个ＤＥＬＡＹ的理由非常容易！所以软件工具需要采用，对人的管制与对项目的跟踪也是少不了的，对一些重点项目还是需要采用人盯人的笨办法。

如果企业能真正实施项目奖励的话，那项目管理会好很多，但需要注意平衡利益关系，否则会引起辅助人员的消极抵抗。