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、，比如涉及到与计算机通讯需要软件部门帮忙制作测试软件等。通过总体规划，把所需的各项资源（不同技术的人力工时）理出清单，向上级申请审批。毕竟最底层负责硬件开发的工程师对软件有所需求的时候，不可能也没权利给软件部门加载这样一个软件任务。为什么公司内部的一些任务，部门之间存在打乒乓球的现象，就是因为项目一确立就存在着含糊的部分。比如说开发硬件，需求谁负责给出，技术指标谁负责制定，执行中谁负责监控等等，这些责任都不是单方面的，有很多都是部门之间或者公司与客户之间相互协商的，由项目负责人来权衡协调，项目的职责一定要明确。永远不要去向不懂该项目的人要这要那或者可以说是向那些项目不关联、不牵扯的人和部门索取12、信息。举例说公司内部DAU硬件部分信息，就应该向生产部硬件室咨询，因为这是他们的职责所在；如果你去向集测室、系统室等去咨询，很有可能是徒劳，而且即使有见解，正确性又如何考究呢？一句话，总体设计就是要分工和责任明确。2.5. 详细设计在总体设计方案之后，按照技术说明书的需求，着重描述每一模块是怎样实现的，包括实现信号控制、处理、逻辑流程等，以功能和性能要求为最终目标，选择适当的器件以及电气接口。在详细设计时要力求全面周到，毕竟这里是开版做PCB的参考依据。如果说标准都出现了错误，后果的严重性也就不言而喻了。在设计功能和调试验证时，应做好调试中修改记录文档，以便在后续的定版之前有个完善、清晰的参考13、。不要为了之前已经确定了的东西，反复查询耽误不必要的工时。2.6. 开发（实施）原理图、PCB以及相关的程序设计，电路调试、功能验证。作为一个硬件项目的开发流程中的环节，这个环节应该是最为重要的，因为这个环节是把想法转化为实物的一个关卡，自然是要求最为详细、设计力求缜密，尽可能少出错甚至不出错，因为这里是缩短开发周期的关键点，少一次修订，就能节省很多宝贵的时间。2.7. 测试硬件产品设计的功能完善后，在调试结束后，发布之前，需要进行上机测试，考机测试，以确保产品的硬性指标和质量。编写用户手册，手册里需要明确指出：如何使用、如何测试、调试的步骤和方法等。值得注意的是，最好测试人员不能是开发人员，14、以避免当局者迷的情况，而且使用者更容易发现潜在的问题。通过测试，发现归纳问题，最好能以书面形式反馈给设计人员，然后改版修订，并重复以上开发测试步骤，直到硬件完全合格才能进行以后步骤。2.8. 项目验收经测试合格后，进行项目验收归档，发布定版后的相关文档，包括原理图、PCB版图、成本核算、元器件清单以及程序和软件的归档备案。最终版本的归档备案是必须的，这样才能增加后续项目的归宿性、可塑性和扩展性。我们公司有些硬件的可塑性不强，就是因为当初的档案工作不够完善。比方说DAU数字板的问题，之前硬件室试图改造，就是因为备案的Pal器件逻辑是错误的（文档备案非最终版本），导致假定该逻辑正确为前提的设计，出15、现了源头错误，因而很难挽回失败的结局。2.9. 项目结束以文档形式备案项目整体过程环节情况。项目总结，项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。3. 文档记录在项目开发过程中，应该按要求编写好不同阶段的各种文档，文档编制要求具有针对性、精确性、清晰性、完整性、可追溯性。而我们公司的现状就是：很多成熟的东西没有流程式的、文档记录式的归档备案，以至某些不必要的流程， 每个人都要走一遍，甚至每次都要反复走一个没有意义的途径。比方说，新员工入职，在各自职位上甚至连一个最基本的岗位培训都没有。这样16、就导致一个结果，每人新人都是在自己摸索，前人的经验不能有效的传递下来，而老员工的应急处理能力也就被局限于之他前遇到过的问题。遇到一个他没遇到的问题（这里可能是那些根本算不上是新问题的问题），他就会和新员工一样茫然，如果更老资历的员工已经离职，那么如何处理问题就会变得很难，这就是为什么我们不能站在前人的肩膀上的原因没有备案的经验总结。参看如下表3-1，这里只是示意性的参考。项目阶段所需文档说明项目说明项目来源背景等项目立案之前可行性分析报告市场调研、为满足特定需要等技术调研报告技术可行性（此文档可包含于可行性分析中）项目启动审批以及说明项目立案、参与人员组成等立案开发初步计划制定研发总体规划其他17、部门的支持和需求项目牵扯软件、预算开销以及耗费（库房）总体方案开发详细方案原理图等具体要求修订记录调试中发现新问题的修改备案记录测试手段流程测试中发现新问题如何解决提交验收测试验收报告产品发布技术发布文档包含器件清单、成本核算、硬连线等用户手册表3-1项目阶段与所需文档在相关的进程节点处做好相应的归档，便于任务的回顾以及控制流程提高效率。文档的设置，要有成文的规定，要有约束力，不然形同虚设，就像做得再好的计划，不能付诸于实践，没有任何意义。4. 项目冲突当多个项目同时发生的时候，如何调节好人力资源的分配和调度，就变得很关键。通俗的说，一件生产工具，同一时间只能被一个人占有使用，你占用该工具，别人就不能使用。道理很简单，人的工作机制也不是多任务并发的。不同项目同时需要调配同一人力时，项目经理之间就要进行协商，权衡优先级和各自项目的风险轻重，万不得已的时候会舍卒保车，做出抉择。