项目总结怎么写啊? 创业项目总结
项目总结报告该怎么写
XX项目总结报告
XX单位管理委员会（你要汇报的机构，不能针对个人）：
受领导指派，我于XX年XX月XXX日负责XX项目。X个月来，在领导的大力支持及同志们的密切配合下，项目进展顺利。于XX年XX月XX日圆满地完成了该项工作。现将项目建设情况汇报如下：
一、项目基本情况：
这一段回顾一下项目立项的依据及意义。
二、建设中的工作情况（最好给每一个小标题都起一个煽情的名字）
你是如何干的。包括你的指导思想、工作方针、工作措施、工作实际。可以加入一两个工作片断，以显得更加真实、感人。其实主要目的应该是向领导邀功。
三、
建成后的各项指标，要有具体数据，并以简要的分析做结语（这一段和二、建设中的工作情况调换也可以。灵活掌握吧）。
四、存在的不足：
（在这里矫情一下，比如发现了自身知识积累不足等）
五、几点体会：
（在这里你向领导表忠心。以“总之，在领导的大力支持下，该项目取得了成功，你个人的业务素质也在工作中也得到了提高”结束本段）。
以上是XX项目工作情况。请审阅。
XXX（这里是姓名，前面也可加公司名称和职务）
年月日
项目总结怎么写啊？
如何写项目工作总结 2008-12-30 06:27
| 一、项目总结应达到的目的 1. 确认本项目中什么是行之有效的，其原因是什么？ 总结不是歌颂功德，但一定要写出成功的经验以及采用的特殊方法或工具，便于积累知识和经验。 2. 防止重复错误 在项目过程中会发生许多错误，通过总结出现的错误及其采用的改善措施，作为改进流程和改进项目管理的依据，防止错误再次发生。 3. 激励团队成员 项目组成员都想知道自己干得如何。在项目启动时LPDT就应该确定项目要总结的内容，包括项目评价的标准、所采用的方式以及参加评价的人员（如部门经理或项目总监等）。其中应包括项目组成员绩效的评价，只要评价是公正、公平、公开的，就会激励项目组成员更加积极地努力工作。 4. 作为项目实践的证据 有时候，客户（包括公司内部客户）在选择项目承包方时，需要参考你出示的相关项目成功实践的记录，这时候项目总结报告将成为重要证据。 二、项目总结应包括的内容 1. 项目时间 实际项目进度与计划的比较结果如何？其间有哪些变化？实际工作量与估计的差多少？这些问题的答案都应在项目总结中体现出来。公司要建立并完善历史经验库，项目总结应为此提供准确、全面的数据，便于后续的专案得到有价值的参考信息，以帮助他们提高计划的准确性，从而提升公司研发的竞争力。 2. 项目成本 对于未建立项目核算的组织，可以用加权(人×天)数来表示人工费用，对于不同角色的人员可以赋予相应的权重。 3. 项目质量 要详细说明项目的最终交付件与市场需求的符合度（也就是需求的实现状况）。对于公司内部项目，客户可能是你的上司或组织本身。 4. 人员管理以及沟通交流项目组成员的绩效表现如何？开发过程中的内部、外部沟通交流是否充分？对项目有何影响？这些问题的答案也应在项目总结中充分体现。 5. 采用的新技术或新方法这里主要指项目管理方面采用的新技术或方法，例如项目计划与项目监控所运用的工具。也可以是别的，如软件开发项目中的用例（CASE）工具等。使后续的专案组参考采用后能够提升研发的效率与项目控制的能力。 6. 项目特点要说明与以往项目比较，本项目有何特别的地方？例如特殊的需求、特殊的环境、不同常规的资源供应等。总之是一些具有挑战性的事件以及关键的解决方案和实施过程。使后续的专案组能够借鉴，用来回避可能遇到的项目风险。 |
最后坚持一个原则：项目总结应对事不对人。不要把失败的项目总结写成一篇批判、抨击甚至人身攻击的文章；不要将失败的项目总结会开成批斗会。
项目总结都要写哪些内容？请各位大侠帮忙哦！
1 项目概述知
1.1 产品
简要说明项目所完成的产品的功能、特点
1.2 项目组成员
描述项目所涉及的角色和人员
2 项目状态总结
2.1 进度
项目实际进度与计划 的对比
2.2 工作量
项目实际工作量与计划工作量的对比
2.3 成本
实际成本与计划成本的对比
2.4 规模
代码、文档实际规模与计划道规模的专对比
2.5 关键计算机资源
各资源实际占用率与计划占用率比较
2.6 风险
实际发生的风险、所造成的影响和采取的行动与计划的比较
非预计风险的数量
2.7 技术方案评价
项目采用的技术的利弊
2.8 KPA状态
2.8.1 需求管理
用户需求更改的次数
更改需求造成的影响
2.8.2 组间协调
组间曾出现的问题和解决措施
2.8.3 里程碑评审
实际完成的里程碑评审
2.8.4 培训
实际完成的项目培训与计划的比较
2.9 其他
项目经理希望说明的项目的其他方面的状态
3 经验及教训
根据第2节中项目状态总结，项目经理分析项属目所获得的经验以及今后应该注意问题
4 建议
针对项目中的实践，项目经理提出一些改进建议，例如对规范。
5 结论
说明项目是否成功，以完全满足验收标准为成功。
软件测试 项目总结怎么写啊？高手指教下
能表达得有条理就可以了。不必介意格式。总结无非就是总结经验，吸取教训咯,本人什么时候参加了什么项目的测试
这个项目是干什么的
我在项目组中做了什么
遇到了什么困难 如何解决的
通过这个项目我学习到了什么
我要感谢谁谁谁
我以后要在什么方面加强
此致
敬礼
附件一
X项目的测试工作到今天算是全部结束了，除了后期维护必要的一些回归测试和用户使用手册的撰写外，整个测试阶段告一段落。
从10月底进入项目，在测试经理的帮助下开始学着写项目测试文档，到根据文档的每日功能测试及回归测试，再到整个项目进行迭代后对测试文档的重新架构及整体回归测试，直至最后的统一交付测试，我个人提交总BUG数为244个。
在这244个BUG的提交和回归过程中，在测试文档的写作及修订中，我对整个项目的逻辑及架构逐步清晰，对项目之间所需的复杂交互的认识也越发深入，对项目功能逻辑上的测试如何进行也更加明晰。
下面我简单谈谈对项目的认识、经验和教训，以及对未来改进的一些建议！
一、对项目的认识
进入这个项目是在今年十月底，当时测试经理和C已经把Setting（当时是Admin）部分的测试结束了，所以我直接开始接着D的测试文档继续往下写（当时是从Revenue的Report部分开始，即现在的Report模块）。因为跳过了逻辑部分，所以对整个项目逻辑理解很不够，开始写的测试文档也非常浅显，就是描述了一下页面布局。这里我的感觉是，测试人员进入项目初期，项目经理有必要指派专门人员与测试人员沟通，帮助其理清整个项目的顺序逻辑。当时C简单地跟我介绍了一下整个项目，我的感觉是沟通不够，对逻辑理解比较欠缺。
Report部分写完，就直接开始测试——用自己刚写完的文档进行测试，效果显然不够理想。因为测试人员刚进行该模块测试文档的编撰，再让他对该模块进行测试，这样做的一个后果就是，测试人员会先入为主地觉得自己不需要按部就班地照着文档进行测试（因为文档就是自己写的）。还有一个很大的问题就是，倘若测试人员在文档撰写上存在严重漏洞的话，他在测试时仍然不可能发现自己的漏洞所在。所以我建议测试文档撰写人员与测试人员最好不要是同一个人，这样有助于发现测试文档构建的漏洞。
测试完Report后，紧接着开始进行Expense模块测试文档的撰写。这时我开始接触到一些逻辑，即Expense与Setting部分联系的逻辑。这时遇到的问题最多最杂，随时随地都需要与C，甚至项目经理进行沟通。由于之前对主功能（Setting部分）的不熟悉，这种一边沟通一边撰写的测试文档可以说是漏洞百出。由于项目时间也比较紧，我需要在一周内完成整个Expense模块的测试文档，所以最终完成的文档很不理想。这里我觉得还是之前沟通不到位的问题，应该有一个对整个项目非常熟悉的人来帮助测试人员理清整个项目逻辑再进行测试文档撰写，而不是一开始就撰写测试文档。
接着就是根据自己撰写的Expense文档对Expense模块进行测试，效果也不够理想。这里我还有一个建议就是，如果测试人员在初始进入项目时没有得到及时沟通，至少需要给他一周时间先对主功能（即Setting部分）进行完整测试，对照需求手册及主功能发现的BUG，对主功能进行深入理解。
Expense测试完成后，开始对整个项目进行回归测试。在这个过程中，我逐渐理清了整个项目的逻辑，也开始试图修改以前的文档。但由于文档量太大，文档结构不够清晰，时间也比较紧，修改难于进行。大部分原因是我经验不足造成的，之前撰写测试文档时，思路过于混乱，想到哪里写到哪里，导致最后文档难于维护和修改。
回归测试结束后，整个系统逻辑已经比较清晰。这时项目进行新一轮的迭代，用户需求改了很多，其中包括增加、修改大量功能、名称，以及对整个系统结构进行重构。这对测试文档而言改动点非常多（包括结构顺序改变、测试编号订正、功能模块名称修改等），而且需求文档并未因此变化，造成最后测试文档与需求文档的不匹配。这是一个协调的过程，系统迭代后，需求文档应及时随着系统进行修改。
迭代开发过程中，测试基本上是项目改到哪就测到哪，这里面最大的问题不是发现修改模块的BUG，而是发现修改该模块后牵涉到的其它模块出现的BUG。这种连带BUG的产生可以说是防不胜防，让测试人员苦恼不已。到现在我也没想出解决办法，只能说对模块之间的联系及交互逻辑理解仍需加深。
迭代开发后期，开始对整个系统从头回归一遍，这时候又发现了许多以前从未出现的BUG。这个时期大家都很烦躁困惑，曾经运转良好的页面，突然出现存储问题；曾经更新正常的功能，突然无法更新；曾经显示正常的Excel，突然显示错误… …这些都让人苦恼，当然，这些应该都是正常现象。测试人员在测试后期尤其需要提高警惕，不能漏过任何一个功能点，更不能忽略任何一次貌似无用的查询、翻页、按键。
最后，是大家一起进行的交付测试，人员包括了所有的编程人员及测试人员。这期间，除了对基本功能的回归测试外，还包括了并发测试及性能测试（这主要是编程人员在做），除此之外，我将过去提交修正过的所有BUG重新验证了一遍。在并发测试中，我们发现了很多之前单人测试难以发现的并发问题（包括多人一起提交，一起选择，一起修改等等），并发问题可以说层出不穷，甚至包括了同一台电脑打开两个页面分别进行修改的问题（由于我从一开始就是打开两个页面来测，一个为用户本人，一个为该用户代理人delegator，所以有些问题在早期已经暴露），这是测试中的一个重点，也是比较严重的漏洞，需要在以后多加留意。
在验证过去修正过的BUG时，仍然发现不少问题，有些是BUG本身的问题，有些是BUG附带问题，还有很多验证时联想到的问题。这一验证过程效果非常明显，所以我建议在项目末期有必要将过去修正的BUG重新认真验证一遍，可以在短时间内收到奇效。
至此，整个项目的测试算是告一段落。用户过来测试后提出一些BUG，经过分析，绝大部分属于用户的一些想法，与测试漏洞无关，整个测试算是圆满结束。
二、经验和教训
这个项目是我接手的第一个项目，也是一个理论联系实际的过程，回想起来，收获颇丰。
经验主要如下：
1、 学会如何将书中的理论与实践相结合；
2、 学会如何根据项目Demo及需求文档撰写测试文档；
3、 学会如何根据项目变更修改测试文档；
4、 学会如何用英文撰写文档，提交，验证问题；
5、 学会如何理清项目逻辑，如何更深入地撰写文档并进行测试；
6、 学会如何与编程人员沟通交流，获得解答，以便正确提交BUG；
教训如下：
1、 撰写测试文档前没有理清业务逻辑，导致前期测试深度不够；
2、 撰写测试文档时结构不清晰，导致后期难以维护和修改；
3、 测试过程中心态有些浮躁，有些急于求成；
4、 还没有形成测试思维，测试过程思维显得有些混乱；
5、 对BUG轻重缓急界定不够，导致有时测试难以继续进行（对一些影响进度的低级别BUG优先级定得太低）；
三、对未来改进的一些建议
经过这次完整的项目测试，学到了很多，也发现了很多问题。对于未来项目的测试，我如下几个不太成熟的建议：
1、 在测试之前项目经理有必要对测试人员进行项目培训，让测试人员对整个项目心中有数，在撰写测试文档时有的放矢；
2、 在测试文档撰写之前需要定义一个撰写规范和标准，大家按照同一个标准撰写，有利于日后文档的维护；
3、 同一个项目功能测试至少应有两人，可以交叉编写模块测试文档，交叉检查文档，交叉进行回归测试，交叉验证BUG，这样有利于避免单人测试考虑不足的漏洞，也能产生更多新的想法，还能相互督促完善文档，提高测试进度；
4、 从一开始就高度重视并发问题，并发问题暴露得越早越易于修改；
5、 项目后期除了不留死角、轮番地扫遍每一个角落（多人协作）外，还需要将过去所有解决的BUG全部验证一遍，会发现不少难以预见的BUG；
6、 对于本项目，目前还有32个延迟（Pending）的BUG，里面大部分为性能和并发问题，还有一些光标、排序及空数据遗留问题，这些看似无关紧要或暂时难以解决的问题都是未来亟需解决的关键所在；