硬件项目开发管理实施方案

《硬件项目开发管理实施方案》由会员分享，可在线阅读，更多相关《硬件项目开发管理实施方案（7页珍藏版）》请在装配图网上搜索。

1、.硬件工程开发管理方案目录编写目的2关键词2摘要21.工程管理概述21.1.工程的特性21.2.工程的生命周期32.实施分析42.1.工程申请42.2.可行性分析42.3.立项以及开发方案42.4.总体设计需求分析52.5.详细设计52.6.开发实施62.7.测试62.8.工程验收62.9.工程完毕63.文档记录74.工程冲突7引言编写目的为了使公司的硬件开发便于管理、监控和绩效，因而要使其流程化、规化，使其成为公司的长远战略开展中的良性节点。关键词工程特性、工程生存周期、可行性分析、文档记录、约束力。摘要分析工程的特征，抓住中间的环节，同时结合公司现状，有针对的提出实施方法。1. 工程管理概

2、述为什么要进展工程管理？如果所有的工程都是按照既定的方案，然后在特定的时间节点处到达所需的成效，一切都在方案管理的掌控当中，那就不需要工程管理了。但是实际情况并非单一任务独占人力资源、硬件资源，工程管理就是要合理的调节好人力、物力、工时、财力以及其他影响因素之间的关系，然后使各个资源点分配合理，从而使得工程利益最大化。打个比方，实际上同一个人可能同时在多个工程上，就像CPU一样，必须有个分时调度的规划，这样才不容易死机。工程管理者的角色就是为了让各个资源点合理有序的被使用，让工程的进展有条不紊、安康的开展并完结。工程管理就是要按时、低本钱、高效地交付成果。一个好的工程管理者，能够有效地评估和调

3、节工程中人力、资源和工时之间的矛盾，进而提出调配规划和解决方案。工程管理者要对新上任的工程进展调研，有一个宏观的了解才能做出下一步的抉择，调研的对象要包括：用户需求、关联厂商、人力资源、物质条件、财务预算等等。1.1. 工程的特性工程是具有以下特性：1) 目标性2) 唯一性3) 时间性4) 资源有限性5) 相关性阶段性6) 风险性7) 可行性8) 方案性9) 成效性工程的由来不是空穴来风，它的进程要受到如时间、资源、风险等相关因素影响。一个完整的工程，不能模糊不清，不能虎头蛇尾；一个成功的工程，不能无限延期交付，不能消耗无度。1.2. 工程的生命周期一个典型的工程生命周期：启动、方案、执行、控

4、制、收尾。如图1-1：图1-1典型的工程生命周期示意图工程的生命周期是一个以投资和时间作为坐标的曲线示意图，工程生命的每个环节都有它独特的成效。当然工程不会凭空而来，要启动得有缘由，就像一个商人通常是不会做赔本生意的。工程启动之后，在完毕前，无论哪个环节受到无视，所造成的后果只有一个，即表现在图1-1中为该曲线围成的绿色区域变大面积增加。换句话说，就是投资量加大与时间跨度增加，然而这两个因素，哪一个增加也不是我们想要的。工程管理者，就是在有限的资源约束下，运用系统的观点、方法和理论，对工程涉及的全部工作进展有效的管理，即从工程的投资决策开场到工程完毕的全过程进展方案、组织、指挥、协调、控制和评

5、价，以实现工程的目标。而做工程管理的目的，反映在此曲线图上，就是在能够清楚的认识工程生命周期中投资和时间关系的根底上，分析影响工程生命曲线的具体因素，找到关键的环节让其曲线面积变小，从而到达最优的结果，设法到一个成功的工程开发。我们公司部的一些硬件开发的小工程，很多还都局限在口头工程，在时间、资源、人力协调方面约束力很弱，经常出现工程一拖旷日持久、投入甚至没有度量，很难被称之为成功的开发工程。2. 实施分析2.1. 工程申请启动一个硬件开发工程，原始的推动力会来自于很多方面，比方市场的需要，产品换代的需要，为了降低本钱更新的需要，提高*方面能力的需要等等，所以作为一个硬件系统的设计者，要主动的

6、去了解各个方面的需求，并且综合起来，提出最适宜的硬件解决方案。工程都是为了满足特定的需要而产生的。一个好的提议，经过管理者的磋商讨论、形势分析，以及技术人员的分析研究，最终得到一个结论：执行或放弃，还是把*一局部外包。在这里，管理者的决策好似启明灯，技术人员的评定则是前行者的动力，两者缺一不能达成最终目的。PS：外包情况，可行性分析的结果是肯定的，而目前自己的技术力量不够，但是可以通过外包来到达要求，从而可以承接这个工程。2.2. 可行性分析说明该硬件开发工程的实现在技术上、经济上和社会因素上的可行性，评述为了合理地到达开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由，最终以

7、能够确定是否需要立项开发。如果是对外工程，则要确认对方粗略需求框架，在公司部进展较详细的功能及需求描述，根据该分析进展判断。风险评估是必要的，比方，我们承接一个工程，如果工程不能按时交付就要承当一定的风险。比方说，由于外包局部的不能按时交付，导致我们的整体工程的交付延期，则我们的风险和外包厂商之间的风险分担，必须有平衡之处。当然风险的来源也是多种途径的，不局限于*一特定约束。硬件开发在硬件工程的立案之前，技术可行性分析是关键，不能因为草率的决定，导致日后执行之时才发现这样那样的问题，也就是说硬件技术是否真正可行，必须落实到详细的需求和技术细节上。我们对这部份硬件开发前的评判不够，为什么总有宣告

8、失败的开发，根源就在这里。2.3. 立项以及开发方案有了好的工程来源以及着实可行的因素分析，这些条件的满足，得以到达立项的最根本要求。在双方根本对上述需求、功能达成一致的情况下，甲乙双方各自落实工程负责人，评估工程本钱、收益、风险等诸多方面因素做出工程方案书，并交付工程审批委员会审批。这里会涉及到财务、工程技术人员等，签订合同、立项。工程成立，要为硬件工程实施方案制订出具体方案，应该包括各局部工作的负责人员、开发的进度总体设计、详细设计规划、开发经费的预算、所需的其他资源等等。工程为什么要立案？就是要产生一定的约束力，这样才可能有好的监视和自律作用。就像纪律和法律，纪律是制定给那些遵守纪律的人

9、的，而法律则恰恰是制定给那些不遵守法律的人的。因为纪律里只规定可以做什么，而法律则规定了不可以做什么，并对违反法律的人做出相应的惩治条例。前者是以道德为准绳，后者则以律法为准绳，这样就造成了约束力的强弱。目前公司里的一些工程，是很模糊的，没有书面形式的立案，没有明确的时间限度，也没有对物质消耗的度量以及其他条件的约束等待。这样就存在着两个致命的缺点：1、 没过多的约束，效率可能会很低；2、 工作积极性、热情以及责任心很低。最好能对引入奖励机制，不能给员工产生这样的感觉：就是做工程与不做工程的收获是一样的，工程做得好与做的差收获也是一样的。这就是为什么需要有约束力的文件备案和工程的绩效。没有约束

10、力，就不能有效的评判完成与否、好坏之分，最终导致效率低下；没有绩效，员工的积极性就被无形的打压住了，自然什么工作积极性、责任心全部轻假设浮尘。2.4. 总体设计需求分析对所开发硬件的功能、性能、用户界面及运行环境等做出详细的说明，要有具体的技术说明文档。它是在用户与开发人员双方对硬件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的根底。该需求应给出功能接口逻辑等的各项要求，为后续工作提供物理和电气性能做好准备。概要实际阶段的工作成果，它应说明功能分配、模块划分、输入输出以及接口设计、运行流程设计、数据信号形式设计等，为详细设计提供根底。相关部门的支持，比方涉及到与计算机通讯需要软件

11、部门帮助制作测试软件等。通过总体规划，把所需的各项资源不同技术的人力工时理出清单，向上级申请审批。毕竟最底层负责硬件开发的工程师对软件有所需求的时候，不可能也没权利给软件部门加载这样一个软件任务。为什么公司部的一些任务，部门之间存在打乒乓球的现象，就是因为工程一确立就存在着模糊的局部。比方说开发硬件，需求谁负责给出，技术指标谁负责制定，执行中谁负责监控等等，这些责任都不是单方面的，有很多都是部门之间或者公司与客户之间相互协商的，由工程负责人来权衡协调，工程的职责一定要明确。永远不要去向不懂该工程的人要这要那或者可以说是向那些工程不关联、不牵扯的人和部门索取信息。举例说公司部DAU硬件局部信息，

12、就应该向生产部硬件室咨询，因为这是他们的职责所在；如果你去向集测室、系统室等去咨询，很有可能是徒劳，而且即使有见解，正确性又如何讲究呢？一句话，总体设计就是要分工和责任明确。2.5. 详细设计在总体设计方案之后，按照技术说明书的需求，着重描述每一模块是怎样实现的，包括实现信号控制、处理、逻辑流程等，以功能和性能要求为最终目标，选择适当的器件以及电气接口。在详细设计时要力求全面周到，毕竟这里是开版做PCB的参考依据。如果说标准都出现了错误，后果的严重性也就不言而喻了。在设计功能和调试验证时，应做好调试中修改记录文档，以便在后续的定版之前有个完善、清晰的参考。不要为了之前已经确定了的东西，反复查询

13、耽误不必要的工时。2.6. 开发实施原理图、PCB以及相关的程序设计，电路调试、功能验证。作为一个硬件工程的开发流程中的环节，这个环节应该是最为重要的，因为这个环节是把想法转化为实物的一个关卡，自然是要求最为详细、设计力求缜密，尽可能少出错甚至不出错，因为这里是缩短开发周期的关键点，少一次修订，就能节省很多珍贵的时间。2.7. 测试硬件产品设计的功能完善后，在调试完毕后，发布之前，需要进展上机测试，考机测试，以确保产品的硬性指标和质量。编写用户手册，手册里需要明确指出：如何使用、如何测试、调试的步骤和方法等。值得注意的是，最好测试人员不能是开发人员，以防止当局者迷的情况，而且使用者更容易发现潜

14、在的问题。通过测试，发现归纳问题，最好能以书面形式反应给设计人员，然后改版修订，并重复以上开发测试步骤，直到硬件完全合格才能进展以后步骤。2.8. 工程验收经测试合格后，进展工程验收归档，发布定版后的相关文档，包括原理图、PCB幅员、本钱核算、元器件清单以及程序和软件的归档备案。最终版本的归档备案是必须的，这样才能增加后续工程的归宿性、可塑性和扩展性。我们公司有些硬件的可塑性不强，就是因为当初的档案工作不够完善。比方说DAU数字板的问题，之前硬件室试图改造，就是因为备案的Pal器件逻辑是错误的文档备案非最终版本，导致假定该逻辑正确为前提的设计，出现了源头错误，因而很难挽回失败的结局。2.9.

15、工程完毕以文档形式备案工程整体过程环节情况。工程总结，工程开发完成以后，应与工程实施方案对照，总结实际执行的情况，如进度、成果、资源利用、本钱和投入的人力，此外，还需对开发工作做出评价，总结出经历和教训。3. 文档记录在工程开发过程中，应该按要求编写好不同阶段的各种文档，文档编制要求具有针对性、准确性、清晰性、完整性、可追溯性。而我们公司的现状就是：很多成熟的东西没有流程式的、文档记录式的归档备案，以至*些不必要的流程， 每个人都要走一遍，甚至每次都要反复走一个没有意义的途径。比方说，新员工入职，在各自职位上甚至连一个最根本的岗位培训都没有。这样就导致一个结果，每人新人都是在自己摸索，前人的经

16、历不能有效的传递下来，而老员工的应急处理能力也就被局限于之他前遇到过的问题。遇到一个他没遇到的问题这里可能是那些根本算不上是新问题的问题，他就会和新员工一样茫然，如果更老资历的员工已经离职，则如何处理问题就会变得很难，这就是为什么我们不能站在前人的肩膀上的原因没有备案的经历总结。参看如下表3-1，这里只是示意性的参考。工程阶段所需文档说明工程说明工程来源背景等工程立案之前可行性分析报告市场调研、为满足特定需要等技术调研报告技术可行性此文档可包含于可行性分析中工程启动审批以及说明工程立案、参与人员组成等立案开发初步方案制定研发总体规划其他部门的支持和需求工程牵扯软件、预算开销以及消耗库房总体方案

17、开发详细方案原理图等具体要求修订记录调试中发现新问题的修改备案记录测试手段流程测试中发现新问题如何解决提交验收测试验收报告产品发布技术发布文档包含器件清单、本钱核算、硬连线等用户手册表3-1工程阶段与所需文档在相关的进程节点处做好相应的归档，便于任务的回忆以及控制流程提高效率。文档的设置，要有成文的规定，要有约束力，不然形同虚设，就像做得再好的方案，不能付诸于实践，没有任何意义。4. 工程冲突当多个工程同时发生的时候，如何调节好人力资源的分配和调度，就变得很关键。通俗的说，一件生产工具，同一时间只能被一个人占有使用，你占用该工具，别人就不能使用。道理很简单，人的工作机制也不是多任务并发的。不同工程同时需要调配同一人力时，工程经理之间就要进展协商，权衡优先级和各自工程的风险轻重，万不得已的时候会舍卒保车，做出抉择。.