app项目总结报告
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
结果在项目执行到中后期时，项目出现了严重的delay，原因是研发对于产品需求没吃透，做的过程中需要频繁与产品确认需求细节，有些功能不符合产品要求，研发估期不准确等，当时如果再按照之前的做法继续下去，项目根本不可控，何时能完工也不能确定。
经过讨论，花了三个晚上，产品、测试、研发一起逐条过测试用例，一来确认测试方案正确性，一方面更细致的让研发了解产品需求，经过这个过程后，进行了一系列补救措施以及赶工，需求细节补充，用例修改，需求变更等，通过大家一致努力，最终项目晚了两周上线。
app项目总结报告【2】
当前任职互联网公司手机APP的专职项目经理，回顾以往的经历，对自己进行总结，也希望对阅读的人有所帮助。
先介绍下我的职业路线：测试工程师—>技术支持工程师兼测试工程师(后面简称技测)—>技测部门主管—>技术支持部门主管—>客户项目经理—>研发项目经理
之前的工作经历让我从不同层面有所收获，在做测试时，除了测试知识外，需要有足够的耐心，描述问题既要简洁又要符合逻辑;在做技术支持时，因为要直接面对客户，要学会沟通技巧，包括口头和文字沟通，要抗的住来自己客户和内部的压力;
店优化)准备
应用权重可能的影
响因素：应用使用状况(打开次数、停留时间、留存率)新应用，或者刚更新会有特殊权重，
下载状况，评论数，评星。
※网络连接。
※数据处理-xml、domain。
※封装Activity。
三界面设计：※主界面确定。
※模块界面、列表、查看、编辑界面。
※菜单、按钮、对话框、提示信息。
※界面总体颜色。
四数据操作和存储：※数据来源。
※数据类型。
※存储方。
五业务实现：※客户端业务解析。
六页面跳转：
※每个页面间的跳转。
※菜单、按钮、事件等。
提审前查了好些资料，大部分是关于提审注意事项，也咨询了有这方面经验的同事，仍旧是被拒4次，前两次被拒苹果给描述的问题很明显，改了。
后两次被拒的原因前后矛盾，我们不知所措，最后忍痛去掉了改功能才得以通过。
在之后的版本升级时，打开了这个功能很快审核通过了。
首个版本审核，花掉一个多月的时间。
有了iphone上的经验，之后的ipad版app进展较为顺利，一审由于名称问题被拒，尽管同类产品命名结构是一样的。
在这样的团队中，从客户提出需求到最终交付，执行迅速，减少了部门之间的协商、优先级调整以及不必要的沟通成本，项目经理对所有决策和结果负责，我个人喜欢这种结构。
在矩阵组织中，我一人负责5条产品线的项目管理，更多的是关注各条产品线能否按照计划完成，处理过程中遇到的问题，有项目相关的、做队员思想工作的。
对于项目管理来讲，矩阵型组织中，项目经理权利有限，难以施展。
app项目总结报告
app项目总结报告【1】
做了几个android企业应用项目后，总结了项目的基本开发步骤，希望能够交流。
一应用规划：※确定功能。
※必须的界面及界面跳转的流程。
※需要的数据及数据的来源及格式。
※是否需要服务端支持。
※是否需要本地数据库支持。
※是否需要特殊权限。
※是否需要后台服务。
二架构设计：※分层。
如果这时再去求助于上司，只会让领导觉得你太弱了。
3、项目经理不一定要强势，强势的项目经理有时候会引起团队成员的抵触。
在整个项目组中，项目经理最能用客观的眼光去看待问题的，要做到对事不对人。
4、原则问题不可以让步，这种让步会带来无尽的困扰，且补救成本巨大;
5、既定的流程要严格遵循，项目经理协助项目组建立高效的流程，除了建立流程，项目经理还要去检查执行状况。
需要向各个职能部门申请资源，很多时候的使用的是参考权利。
权利与责任是相匹配的，在矩阵型组织中，项目经理的成就感差。
下面说说做手机APP的一些成长吧。
最初我们做的是iphone的app，经历了两个多月的研发和测试，终于在年底前提交审核了，可是无论如何你也想象不到，我们第一版通过审核的过程是多么的煎熬。
6、必要时采用问卷调查或访谈，这个方法可以用来解决人的问题。
通过收集团队成员的反馈，也可以检查自己的判断是否有偏差，谈判时有据可依。
7、对上报告，简洁有力。
要善于总结，通过数据报表说明项目执行情况。
遇到重大问题要及时向上汇报，汇报时要提供的解决方案，不要把问题直接抛给领导，要让领导第一时间知道项目进展，以及你解决问题的措施。
app项目总结报告【3】
最有效的营销手段：
刷榜、限免、aso优化、换量，特定类型产品可以利用好微博营销。
用户除了付费之外，另
一个价值就是传播，大部分产品(除了社交类产品)属于用户只会因为产品的质量而去传播，
本身要求比较高，最简单实用的办法就是设置门槛要求用户分享。
应用运营前做哪些准备：
(1)aso(应用商
苹果的规矩是让人摸不着头脑的。
两个月后我们开始了android平台上的同类app开发，这个项目从一开始就犯了一个严重的错误，其带给我们的教训是惨痛的。
由于这三个版本的app功能、交互都是一样的，设计、测试、运营都是同一个团队，不同的是开发人员不同，且安卓的开发人员是新招的。
这个项目开始，我提出了让产品进行需求讲解，但项目组内大部分人认为不需要进行产品需求讲解，因为之前iphone和ipad的版本都做过了，也都很熟悉，最终我让步了，同意产品提出的方案，产品和研发私下沟通讲解。
做部门主管，要关注的是团队发展和管理，学会了管理要因人而异，有人渴望知识，有人希望被尊重，有人喜欢耍小聪明，有人喜欢偷点懒……对上要知道领导关注哪些方面，定期总结，汇报及时且有效。
以上的经历，在项目管理工作中有很大的帮助。
做了将近两年的专职项目经理，分别经历了职能型和矩阵型的组织架构。
在职能型的结构中，我的团队中包含了这样几种角色：研发、测试、技术支持，有专门的产品人员对接，但不向我汇报。
通过这几个项目，总结如下：
1、新领域项目，首先要弄清楚这个项目需要哪些角色参与，每个角色的工作是什么，以前所遵循的流程是什么。
尤其对于空降的项目经理，要先了解这些内容，不要一上来就改变，除非大家认为急需改变的地方。
待项目跑起来后，再不断修正流程，这期间一定要勤于沟通。
2、在矩阵型组织中，要善于运用参考权利，建立自己的威信，否则后续工作开展会遇到很多麻烦。
经过讨论，花了三个晚上，产品、测试、研发一起逐条过测试用例，一来确认测试方案正确性，一方面更细致的让研发了解产品需求，经过这个过程后，进行了一系列补救措施以及赶工，需求细节补充，用例修改，需求变更等，通过大家一致努力，最终项目晚了两周上线。
app项目总结报告【2】
当前任职互联网公司手机APP的专职项目经理，回顾以往的经历，对自己进行总结，也希望对阅读的人有所帮助。
先介绍下我的职业路线：测试工程师—>技术支持工程师兼测试工程师(后面简称技测)—>技测部门主管—>技术支持部门主管—>客户项目经理—>研发项目经理
之前的工作经历让我从不同层面有所收获，在做测试时，除了测试知识外，需要有足够的耐心，描述问题既要简洁又要符合逻辑;在做技术支持时，因为要直接面对客户，要学会沟通技巧，包括口头和文字沟通，要抗的住来自己客户和内部的压力;
店优化)准备
应用权重可能的影
响因素：应用使用状况(打开次数、停留时间、留存率)新应用，或者刚更新会有特殊权重，
下载状况，评论数，评星。
※网络连接。
※数据处理-xml、domain。
※封装Activity。
三界面设计：※主界面确定。
※模块界面、列表、查看、编辑界面。
※菜单、按钮、对话框、提示信息。
※界面总体颜色。
四数据操作和存储：※数据来源。
※数据类型。
※存储方。
五业务实现：※客户端业务解析。
六页面跳转：
※每个页面间的跳转。
※菜单、按钮、事件等。
提审前查了好些资料，大部分是关于提审注意事项，也咨询了有这方面经验的同事，仍旧是被拒4次，前两次被拒苹果给描述的问题很明显，改了。
后两次被拒的原因前后矛盾，我们不知所措，最后忍痛去掉了改功能才得以通过。
在之后的版本升级时，打开了这个功能很快审核通过了。
首个版本审核，花掉一个多月的时间。
有了iphone上的经验，之后的ipad版app进展较为顺利，一审由于名称问题被拒，尽管同类产品命名结构是一样的。
在这样的团队中，从客户提出需求到最终交付，执行迅速，减少了部门之间的协商、优先级调整以及不必要的沟通成本，项目经理对所有决策和结果负责，我个人喜欢这种结构。
在矩阵组织中，我一人负责5条产品线的项目管理，更多的是关注各条产品线能否按照计划完成，处理过程中遇到的问题，有项目相关的、做队员思想工作的。
对于项目管理来讲，矩阵型组织中，项目经理权利有限，难以施展。
app项目总结报告
app项目总结报告【1】
做了几个android企业应用项目后，总结了项目的基本开发步骤，希望能够交流。
一应用规划：※确定功能。
※必须的界面及界面跳转的流程。
※需要的数据及数据的来源及格式。
※是否需要服务端支持。
※是否需要本地数据库支持。
※是否需要特殊权限。
※是否需要后台服务。
二架构设计：※分层。
如果这时再去求助于上司，只会让领导觉得你太弱了。
3、项目经理不一定要强势，强势的项目经理有时候会引起团队成员的抵触。
在整个项目组中，项目经理最能用客观的眼光去看待问题的，要做到对事不对人。
4、原则问题不可以让步，这种让步会带来无尽的困扰，且补救成本巨大;
5、既定的流程要严格遵循，项目经理协助项目组建立高效的流程，除了建立流程，项目经理还要去检查执行状况。
需要向各个职能部门申请资源，很多时候的使用的是参考权利。
权利与责任是相匹配的，在矩阵型组织中，项目经理的成就感差。
下面说说做手机APP的一些成长吧。
最初我们做的是iphone的app，经历了两个多月的研发和测试，终于在年底前提交审核了，可是无论如何你也想象不到，我们第一版通过审核的过程是多么的煎熬。
6、必要时采用问卷调查或访谈，这个方法可以用来解决人的问题。
通过收集团队成员的反馈，也可以检查自己的判断是否有偏差，谈判时有据可依。
7、对上报告，简洁有力。
要善于总结，通过数据报表说明项目执行情况。
遇到重大问题要及时向上汇报，汇报时要提供的解决方案，不要把问题直接抛给领导，要让领导第一时间知道项目进展，以及你解决问题的措施。
app项目总结报告【3】
最有效的营销手段：
刷榜、限免、aso优化、换量，特定类型产品可以利用好微博营销。
用户除了付费之外，另
一个价值就是传播，大部分产品(除了社交类产品)属于用户只会因为产品的质量而去传播，
本身要求比较高，最简单实用的办法就是设置门槛要求用户分享。
应用运营前做哪些准备：
(1)aso(应用商
苹果的规矩是让人摸不着头脑的。
两个月后我们开始了android平台上的同类app开发，这个项目从一开始就犯了一个严重的错误，其带给我们的教训是惨痛的。
由于这三个版本的app功能、交互都是一样的，设计、测试、运营都是同一个团队，不同的是开发人员不同，且安卓的开发人员是新招的。
这个项目开始，我提出了让产品进行需求讲解，但项目组内大部分人认为不需要进行产品需求讲解，因为之前iphone和ipad的版本都做过了，也都很熟悉，最终我让步了，同意产品提出的方案，产品和研发私下沟通讲解。
做部门主管，要关注的是团队发展和管理，学会了管理要因人而异，有人渴望知识，有人希望被尊重，有人喜欢耍小聪明，有人喜欢偷点懒……对上要知道领导关注哪些方面，定期总结，汇报及时且有效。
以上的经历，在项目管理工作中有很大的帮助。
做了将近两年的专职项目经理，分别经历了职能型和矩阵型的组织架构。
在职能型的结构中，我的团队中包含了这样几种角色：研发、测试、技术支持，有专门的产品人员对接，但不向我汇报。
通过这几个项目，总结如下：
1、新领域项目，首先要弄清楚这个项目需要哪些角色参与，每个角色的工作是什么，以前所遵循的流程是什么。
尤其对于空降的项目经理，要先了解这些内容，不要一上来就改变，除非大家认为急需改变的地方。
待项目跑起来后，再不断修正流程，这期间一定要勤于沟通。
2、在矩阵型组织中，要善于运用参考权利，建立自己的威信，否则后续工作开展会遇到很多麻烦。