硬件项目开发管理方案说明.docx
- 文档编号:14946944
- 上传时间:2023-06-28
- 格式:DOCX
- 页数:16
- 大小:67.50KB
硬件项目开发管理方案说明.docx
《硬件项目开发管理方案说明.docx》由会员分享,可在线阅读,更多相关《硬件项目开发管理方案说明.docx(16页珍藏版)》请在冰点文库上搜索。
硬件项目开发管理方案说明
硬件项目开发管理方案(草案)
硬件项目开发管理方案
编写目的 ..............................................................................................................................2
关键词 ..................................................................................................................................2
摘要 ......................................................................................................................................2
1.项目管理概述 ..................................................................................................................2
1.1.项目的特性 ...............................................................................................................2
1.2.项目的生命周期 .......................................................................................................3
2.实施分析 ..........................................................................................................................4
2.1.项目申请 ...................................................................................................................4
2.2.可行性分析 ...............................................................................................................4
2.3.立项以及开发计划 ...................................................................................................4
2.4.总体设计(需求分析) ...........................................................................................5
2.5.详细设计 ...................................................................................................................5
2.6.开发(实施) ...........................................................................................................6
2.7.测试...........................................................................................................................6
2.8.项目验收 ...................................................................................................................6
2.9.项目结束 ...................................................................................................................6
3.文档记录 ..........................................................................................................................7
4.项目冲突 ..........................................................................................................................7
1 / 8
硬件项目开发管理方案(草案)
引言
编写目的
为了使公司的硬件开发便于管理、监控和绩效,因而要使其流程化、规范
化,使其成为公司的长远战略发展中的良性节点。
关键词
项目特性、项目生存周期、可行性分析、文档记录、约束力。
摘要
分析项目的特征,抓住中间的环节,同时结合公司现状,有针对的提出实
施办法。
1. 项目管理概述
为什么要进行项目管理?
如果所有的工程都是按照既定的计划,然后在特
定的时间节点处达到所需的成效,一切都在计划管理的掌控当中,那就不需要
项目管理了。
但是实际情况并非单一任务独占人力资源、硬件资源,项目管理
就是要合理的调节好人力、物力、工时、财力以及其他影响因素之间的关系,
然后使各个资源点分配合理,从而使得项目利益最大化。
打个比方,实际上同
一个人可能同时在多个项目上,就像 CPU 一样,必须有个分时调度的规划,这
样才不容易死机。
项目管理者的角色就是为了让各个资源点合理有序的被使用,
让项目的进展有条不紊、健康的发展并完结。
项目管理就是要按时、低成本、高效地交付成果。
一个好的项目管理者,
能够有效地评估和调节项目中人力、资源和工时之间的矛盾,进而提出调配规
划和解决方案。
项目管理者要对新上任的项目进行调研,有一个宏观的了解才能做出下一
步的抉择,调研的对象要包括:
用户需求、关联厂商、人力资源、物质条件、
财务预算等等。
1.1. 项目的特性
项目是具有以下特性:
1) 目标性
2) 唯一性
3) 时间性
4) 资源有限性
2 / 8
硬件项目开发管理方案(草案)
5) 相关性(阶段性)
6) 风险性
7) 可行性
8) 计划性
9) 成效性
项目的由来不是空穴来风,它的进程要受到如时间、资源、风险等相关因
素影响。
一个完整的项目,不能含糊不清,不能虎头蛇尾;一个成功的项目,
不能无限延期交付,不能耗费无度。
1.2. 项目的生命周期
一个典型的项目生命周期:
启动、计划、执行、控制、收尾。
如图 1-1:
图 1-1 典型的项目生命周期示意图
项目的生命周期是一个以投资和时间作为坐标的曲线示意图,项目生命的
每个环节都有它独特的功效。
当然项目不会凭空而来,要启动得有缘由,就像
一个商人通常是不会做亏本生意的。
项目启动之后,在结束前,无论哪个环节
受到忽视,所造成的后果只有一个,即表现在图 1-1 中为该曲线围成的绿色区
域变大——面积增加。
换句话说,就是投资量加大与时间跨度增加,然而这两
个因素,哪一个增加也不是我们想要的。
项目管理者,就是在有限的资源约束下,运用系统的观点、方法和理论,
对项目涉及的全部工作进行有效的管理,即从项目的投资决策开始到项目结束
的全过程进行计划、组织、指挥、协调、控制和评价,以实现项目的目标。
而
做项目管理的目的,反映在此曲线图上,就是在能够清楚的认识项目生命周期
中投资和时间关系的基础上,分析影响项目生命曲线的具体因素,找到关键的
环节让其曲线面积变小,从而达到最优的结果,设法到一个成功的项目开发。
我们公司内部的一些硬件开发的小项目,很多还都局限在“口头项目”,在
时间、资源、人力协调方面约束力很弱,经常出现项目一拖旷日持久、投入甚
至没有度量,很难被称之为成功的开发项目。
3 / 8
硬件项目开发管理方案(草案)
2. 实施分析
2.1. 项目申请
启动一个硬件开发项目,原始的推动力会来自于很多方面,比如市场的需
要,产品换代的需要,为了降低成本更新的需要,提高某方面能力的需要等等,
所以作为一个硬件系统的设计者,要主动的去了解各个方面的需求,并且综合
起来,提出最合适的硬件解决方案。
项目都是为了满足特定的需要而产生的。
一个好的提议,经过管理者的磋
商讨论、形势分析,以及技术人员的分析研究,最终得到一个结论:
执行或放
弃,还是把某一部分外包。
在这里,管理者的决策好似启明灯,技术人员的评
定则是前行者的动力,两者缺一不能达成最终目的。
PS:
外包情况,可行性分析的结果是肯定的,而目前自己的技术力量不够,但
是可以通过外包来达到要求,从而可以承接这个项目。
2.2. 可行性分析
说明该硬件开发项目的实现在技术上、经济上和社会因素上的可行性,评
述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定
实施方案的理由,最终以能够确定是否需要立项开发。
如果是对外项目,则要确认对方粗略需求框架,在公司内部进行较详细的
功能及需求描述,根据该分析进行判断。
风险评估是必要的,比如,我们承接一个项目,如果项目不能按时交付就
要承担一定的风险。
比方说,由于外包部分的不能按时交付,导致我们的整体
项目的交付延期,那么我们的风险和外包厂商之间的风险分担,必须有平衡之
处。
当然风险的来源也是多种途径的,不局限于某一特定约束。
硬件开发在硬件项目的立案之前,技术可行性分析是关键,不能因为草率
的决定,导致日后执行之时才发现这样那样的问题,也就是说硬件技术是否真
正可行,必须落实到详细的需求和技术细节上。
我们对这部份硬件开发前的评
判不够,为什么总有宣告失败的开发,根源就在这里。
2.3. 立项以及开发计划
有了好的项目来源以及着实可行的因素分析,这些条件的满足,得以达到
立项的最基本要求。
在双方基本对上述需求、功能达成一致的情况下,甲乙双方各自落实项目
负责人,评估项目成本、收益、风险等诸多方面因素做出项目计划书,并交付
项目审批委员会审批。
这里会涉及到财务、工程技术人员等,签订合同、立项。
项目成立,要为硬件项目实施方案制订出具体计划,应该包括各部分工作
4 / 8
硬件项目开发管理方案(草案)
的负责人员、开发的进度(总体设计、详细设计)规划、开发经费的预算、所
需的其他资源等等。
项目为什么要立案?
就是要产生一定的约束力,这样才可能有好的监督和
自律作用。
就像纪律和法律,纪律是制定给那些遵守纪律的人的,而法律则恰
恰是制定给那些不遵守法律的人的。
因为纪律里只规定可以做什么,而法律则
规定了不可以做什么,并对违反法律的人做出相应的惩治条例。
前者是以道德
为准绳,后者则以律法为准绳,这样就造成了约束力的强弱。
目前公司里的一些“项目”,是很模糊的,没有书面形式的立案,没有明确
的时间限度,也没有对物质消耗的度量以及其他条件的约束等待。
这样就存在
着两个致命的缺点:
1、 没过多的约束,效率可能会很低;
2、 工作积极性、热情以及责任心很低。
最好能对引入奖励机制,不能给员工产生这样的感觉:
就是做项目与不做
项目的收获是一样的,项目做得好与做的差收获也是一样的。
这就是为什么需
要有约束力的文件备案和项目的绩效。
没有约束力,就不能有效的评判完成与
否、好坏之分,最终导致效率低下;没有绩效,员工的积极性就被无形的打压
住了,自然什么工作积极性、责任心全部轻若浮尘。
2.4. 总体设计(需求分析)
对所开发硬件的功能、性能、用户界面及运行环境等做出详细的说明,要
有具体的技术说明文档。
它是在用户与开发人员双方对硬件需求取得共同理解
并达成协议的条件下编写的,也是实施开发工作的基础。
该需求应给出功能接
口逻辑等的各项要求,为后续工作提供物理和电气性能做好准备。
概要实际阶
段的工作成果,它应说明功能分配、模块划分、输入输出以及接口设计、运行
流程设计、数据信号形式设计等,为详细设计提供基础。
相关部门的支持,比如涉及到与计算机通讯需要软件部门帮忙制作测试软
件等。
通过总体规划,把所需的各项资源(不同技术的人力工时)理出清单,
向上级申请审批。
毕竟最底层负责硬件开发的工程师对软件有所需求的时候,
不可能也没权利给软件部门加载这样一个软件任务。
为什么公司内部的一些任务,部门之间存在打乒乓球的现象,就是因为项
目一确立就存在着含糊的部分。
比如说开发硬件,需求谁负责给出,技术指标
谁负责制定,执行中谁负责监控等等,这些责任都不是单方面的,有很多都是
部门之间或者公司与客户之间相互协商的,由项目负责人来权衡协调,项目的
职责一定要明确。
永远不要去向不懂该项目的人要这要那——或者可以说是向
那些项目不关联、不牵扯的人和部门索取信息。
举例说公司内部 DAU 硬件部
分信息,就应该向生产部硬件室咨询,因为这是他们的职责所在;如果你去向
集测室、系统室等去咨询,很有可能是徒劳,而且即使有见解,正确性又如何
考究呢?
一句话,总体设计就是要分工和责任明确。
5 / 8
硬件项目开发管理方案(草案)
2.5. 详细设计
在总体设计方案之后,按照技术说明书的需求,着重描述每一模块是怎样
实现的,包括实现信号控制、处理、逻辑流程等,以功能和性能要求为最终目
标,选择适当的器件以及电气接口。
在详细设计时要力求全面周到,毕竟这里
是开版做 PCB 的参考依据。
如果说标准都出现了错误,后果的严重性也就不言
而喻了。
在设计功能和调试验证时,应做好调试中修改记录文档,以便在后续的定
版之前有个完善、清晰的参考。
不要为了之前已经确定了的东西,反复查询耽
误不必要的工时。
2.6. 开发(实施)
原理图、PCB 以及相关的程序设计,电路调试、功能验证。
作为一个硬件项目的开发流程中的环节,这个环节应该是最为重要的,因
为这个环节是把想法转化为实物的一个关卡,自然是要求最为详细、设计力求
缜密,尽可能少出错甚至不出错,因为这里是缩短开发周期的关键点,少一次
修订,就能节省很多宝贵的时间。
2.7. 测试
硬件产品设计的功能完善后,在调试结束后,发布之前,需要进行上机测
试,考机测试,以确保产品的硬性指标和质量。
编写用户手册,手册里需要明确指出:
如何使用、如何测试、调试的步骤
和方法等。
值得注意的是,最好测试人员不能是开发人员,以避免当局者迷的情况,
而且使用者更容易发现潜在的问题。
通过测试,发现归纳问题,最好能以书面
形式反馈给设计人员,然后改版修订,并重复以上开发测试步骤,直到硬件完
全合格才能进行以后步骤。
2.8. 项目验收
经测试合格后,进行项目验收归档,发布定版后的相关文档,包括原理图、
PCB 版图、成本核算、元器件清单以及程序和软件的归档备案。
最终版本的归
档备案是必须的,这样才能增加后续项目的归宿性、可塑性和扩展性。
我们公司有些硬件的可塑性不强,就是因为当初的档案工作不够完善。
比
方说 DAU 数字板的问题,之前硬件室试图改造,就是因为备案的 Pal 器件逻辑
是错误的(文档备案非最终版本),导致假定该逻辑正确为前提的设计,出现了
源头错误,因而很难挽回失败的结局。
6 / 8
项目阶段
所需文档
说明
项目立案之前
项目说明
项目来源背景等
可行性分析报告
市场调研、为满足特定需要等
技术调研报告
立案
项目启动审批以及说明
项目立案、参与人员组成等
开发初步计划
制定研发总体规划
其他部门的支持和需求
项目牵扯软件、预算开销以及耗费(库房)
开发
总体方案
详细方案
原理图等具体要求
修订记录
调试中发现新问题的修改备案记录
测试手段流程
测试中发现新问题如何解决
提交验收
测试验收报告
产品发布
技术发布文档
包含器件清单、成本核算、硬连线等
用户手册
硬件项目开发管理方案(草案)
2.9. 项目结束
以文档形式备案项目整体过程环节情况。
项目总结,项目开发完成以后,
应与项目实施计划对照,总结实际执行的情况,如进度、成果、资源利用、成
本和投入的人力,此外,还需对开发工作做出评价,总结出经验和教训。
3. 文档记录
在项目开发过程中,应该按要求编写好不同阶段的各种文档,文档编制要
求具有针对性、精确性、清晰性、完整性、可追溯性。
而我们公司的现状就是:
很多成熟的东西没有流程式的、文档记录式的归
档备案,以至某些不必要的流程, 每个人都要走一遍,甚至每次都要反复走一
个没有意义的途径。
比方说,新员工入职,在各自职位上甚至连一个最基本的
岗位培训都没有。
这样就导致一个结果,每人新人都是在自己摸索,前人的经
验不能有效的传递下来,而老员工的应急处理能力也就被局限于之他前遇到过
的问题。
遇到一个他没遇到的问题(这里可能是那些根本算不上是新问题的问
题),他就会和新员工一样茫然,如果更老资历的员工已经离职,那么如何处理
问题就会变得很难,这就是为什么我们不能站在前人的肩膀上的原因——没有
备案的经验总结。
参看如下表 3-1,这里只是示意性的参考。
技术可行性(此文档可包含于可行性分析中)
表 3-1 项目阶段与所需文档
在相关的进程节点处做好相应的归档,便于任务的回顾以及控制流程提高
效率。
文档的设置,要有成文的规定,要有约束力,不然形同虚设,就像做得
再好的计划,不能付诸于实践,没有任何意义。
7 / 8
硬件项目开发管理方案(草案)
4. 项目冲突
当多个项目同时发生的时候,如何调节好人力资源的分配和调度,就变得
很关键。
通俗的说,一件生产工具,同一时间只能被一个人占有使用,你占用
该工具,别人就不能使用。
道理很简单,人的工作机制也不是多任务并发的。
不同项目同时需要调配同一人力时,项目经理之间就要进行协商,权衡优
先级和各自项目的风险轻重,万不得已的时候会舍卒保车,做出抉择。
8 / 8
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 硬件 项目 开发 管理 方案 说明