精编范文做项目的一些心得体会word范文 10页Word格式文档下载.docx

精编范文做项目的一些心得体会word范文 10页Word格式文档下载.docx

《精编范文做项目的一些心得体会word范文 10页Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《精编范文做项目的一些心得体会word范文 10页Word格式文档下载.docx（9页珍藏版）》请在冰豆网上搜索。

以下是我对项目管理的一点体会记录。

需求等级

视觉A：

图片没有分享功能吗?

技术K：

图片有链接转发分享、微博或邮件形式分享等多种分享，全部开发的话需要推延时间表。

策划D：

图片只做预览、下载已经足够了，暂时不做分享。

交互E：

如果我们的用户是基于邮箱用户，图片的邮件分享还是建议做。

如果在前期产品需求文档中没有明确定义每个需求的优先等级，或者说项目成员对需求的优先等级没有明确的意识，可能类似的争论会时

常发生在项目成员之间，每个人会基于自己对产品目标的理解来考虑这个需求是否要做，什么时候做，做到什么程度而产生分歧，因而增

加项目推进的阻力。

所以在前期产品需求文档中，必须明确定义出每个需求的优先等级，需求的粒度可细化到每个大功能下的子功能需求，如：

图片分享功能

的转发链接分享、邮件形式分享这样的子功能需求。

等级的划分依赖于前期的用户需求调研、产品的预定目标、开发成本、运营计划等;

一般的需求等级划分：

P0-Musthave：

如果缺失，产品不能发布

P1-Shouldhave：

如果缺失，产品能发布，但不能达到预定目标（功能/性能）

P2-Nicetohave：

做了则更好

P3-Neutral：

对产品没有明显的好处，用户不在意

每个需求的优先等级确定之后，产品经理根据产品预定目标、开发成本、运营计划等来定义一个等级分界线，高于或等于这个等级分界线

的需求在本期开发，部分根据成本、运营计划等因素调整到下期开发，而低于这个等级分界线的需求则只会在下期开发，这样让全体项目

成员对本期要做的需求达成共识。

需求等级的实际应用：

WBS各工作包Triage的参考基准之一;

Triage即确定需求任务是否要做，是否要现在做的一个共同决策过程;

在Triage的过程中，任务

owner对自己的任务以及其他人的任务有更全局的认识。

Bug的Triage的参考标准参考基准之一（也是zerobug*注1和codefreeze*注2时间节点计算的参考基准之一）;

Triage即确定测试中

的Bug是否要修，是否要现在修;

如：

在功能开发期间，P0、P1、P2及以上的Bug都要修;

当进入接口冻结期后，只有P0、P1normal

及以上的Bug才允许修，以保证优先的Bug问题更快地被解决。

*注1ZeroBug：

当前不存在activebug，或不存在高优先级或特别严重的bug

*注2CodeFreeze：

除高优先级或特别严重的bug外，代码冻结不再接受提交

WBS

相片上传的界面还没有搭建好吗?

这部分我们需要先做起来。

前端J：

视觉设计师没有完成呢!

我在做相片的展示页面，还没有做到相片上传。

项目各成员对自己需要负责的任务粒度细分不到位，每个任务的交付时间点不够明确，对任务之间的依赖关系也不够清晰，造成项目推进

中的协作成本提高，项目时间预估准确率不高，项目控制的风险增加;

因此在产品需求文档确认之后，必须做工作分解WBS（WorkBreakdownStructure），即把需求分解成较小的、易于管理的工作包。

一般

的工作包是最小的“可交付成果”。

工作包必须详细到可以对该工作包进行估算（成本和工时）、安排进度、分配负责人员或组织。

项目经理、项目成员和所有参与项目的职能主管都应该参与WBS工作，根据项目规模情况，可以由项目经理或各模块主策划来组织。

组

织方负责召集有关人员，集体讨论所有项目工作，确定项目工作分解的方式后，各职能方提交各自的WBS，汇总后画出WBS的层次结构

图。

结构图中应包括每个工作包名称（内容定义）、指派人员名称、所需工时、可能的依赖关系等;

WBS的工作包，最终以任务形式录入到QA中进行跟踪管理。

WBS的好处：

为资源、成本、进度、质量等控制奠定共同基础，确定项目进度和控制的基准;

为各独立工作包分派人员，规定这些人员的相应职责，便于项目职责的落实和明确划分;

针对各独立工作包，进行时间、资源需要量的估算，提高时间、资源估算的准确度，并确定工作顺序，提高协作效率，利于更准确的制定

项目进度计划表;

——————————————————————————————————————————–

QA可视化项目管理

我完成到图片分享功能，图片下载的bug已经就提交上来了，但是我现在没有时间改bug。

测试F：

我已经提了一轮的bug了，但是我不知道bug什么修好，然后我可以去复查。

图片分享功能开发完成了?

可以测试了吗?

产品经理：

现在大概还有多少P0的bug?

zerobug时间节点是否需要后延?

如果没有QA，项目的状况不是对每个项目成员透明化，就会出现以上的各种情况;

QA作为协同式任务管理工具，通过对每个任务的记录和跟踪，让项目成员对整个项目的情况有直观的了解，项目经理可随时监控项目推

进中的风险是否在可控范围，并提前快速作出调整。

不管是前期开发的工作包还是后期的测试bug，均以任务的形式录入在QA里，然后对这个任务的一些基本属性做设置，如：

属于哪个

milestone、哪个模块等，然后由各个阶段的Triage的负责人按照需求等级标准来对任务作分类定级，并确定是否做，是否现在做;

所有

的任务都必须经过Triage并approve通过，才能开始工作。

Triage的决策需要多个层面的知识（结合产品、技术、进度等多方因素），特

别是在大项目中，Triage往往是一项群体工作，以功能小组（featureteam）或产品决策组的方式来进行。

在项目的不同阶段，可以由不同

的角色来主导Triage流程。

在任务approve后，各职能方leader将任务指派给相应具体执行的人员。

执行人员，也就是任务的owner，必须设置任务的Statusdate，

Status任务状态是Working（进行中）;

Statusdate即完成日期点，Statusdate应真实反映实际工作计划，并应契合项目时间表。

在执行人员完成任务时，QA会通知各职能方leader去关闭这个任务，关闭的意义在于通知任务的相关跟踪者，可以着手下一部分的工作，

如某功能代码任务关闭，即相关测试人员就知道可以开始这个功能点的测试工作;

通过任务在QA系统里的记录和跟踪，以及任务状态的实时更新，最终会汇总生成各种可视化的图表，项目进展直观，且可度量，能够很

好的把握整个项目推进的节奏，对项目中各项问题和风险定位更容易，并可在周会上对项目的所有成员公开进度信息，便于协调一致;

其中最重要的图表：

glidepath任务走势图：

“实际任务走势”与“计划任务走势”的对比，可以衡量出计划与实际的偏差。

每日构建

我们只在每个小milestone才会打build。

希望可以每日bulid，我可以每天拿到最新的版本进行测试。

测试Q：

我建议测试前期可以每个milestoen打版本，但是中期开始，每日build。

每日构建（dailybuild）是指每天对整个项目做一次完整的自动构建，生成可执行文件的过程，对Web类产品，每日构建通常要伴随自动

部署的过程，将这些可执行文件部署至测试环境，并按照一定的规则对这个安装包或测试环境做版本编号，是一种Publicbuild的管理方

式。

每日构建是编译管理的一种方式，项目初期，可根据根据需要按照一定的频率打，如：

每周、每个milestone，随着项目的进行频率逐渐

增加build的频率，如：

每天build。

每日构建的好处：

每日构建让从产品经理、项目经理、策划、交互、视觉等所有的项目人员从第一个小功能模块完成开始，能够随时测试最新的版本提交

bug，并能及时了解技术开发的进度;

每日构建让测试人员从第一个小功能模块完成开始，能够每天测试最新的版本，提交新bug和复查部分bug，而不需要等着某个小

milestone或者所有的功能代码都实现了，再开始测试，大大增加了测试和开发的重叠时间，测试更充分，测试和开发的迭代效率更高，

产品质量控制得更好;

而且bug提交到qa上，也会一并附上build版本号，方便技术还原现场，更快地解决bug;

每日构建使得技术必须对每天自己输出的代码负责，一旦每日build失败，必须检查原因，并纠正不可再犯，以避免再次build失败，这

样能非常有效地提高所提交代码的质量，减少bug的产生，加快开发效率;

虽然搭建并维护dailybuild，需要比较大的工作量，但绝对物有所值。

文章来源：

/news_show.asp?

news_id=404

篇二：

实施项目心得与体会

项目心得与体会——实施人

事是人做，做事的同时明白人最终是重点。

明白什么是因地制宜、因势利导、轻重缓急、察颜观色、用户是上帝但又非绝对。

态度认真和头脑清楚应该是做好一个项目的基本条件。

写点个人体会，供大家指点，在讨论过程中共同提高水平。

体会一：

了解项目是什么项目，谁提出来，解决什么问题。

项目开始阶段是一个最重要的阶段。

项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，从接触各类角色的人从中获取不同信息进行过滤、形成自己对项目的认识。

这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。

体会二：

项目牵涉的项目干系人，了解他们对项目的看法和期望是什么。

这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，项目经理在一个项目中提前接触了不同角色的人，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。

没有永远的朋友，也没有永远的敌人，只有一致的利益。

体会三：

本公司领导对这个项目的看法和重视程度。

本公司领导的看法决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。

你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？

是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响；

体会四：

项目计划制定，通知公司内部相关人员、用户。

使得整个项目参与人员保持步调一致，信息畅通。

在做整体项目计划前，还要大致计算一下你手上的资源。

首先是时间，现在市场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。

对于这一点，你在做项目的风险控制计划的时候要充分考虑。

其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，。

最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间；

体会五：

需求确认阶段，引导用户但要切合实际、站在双方立场考虑问题，让用户