还剩8页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
app工程总结报告 做了几个android企业应用工程后,总结了工程的根本开发步骤,希望能够交流 一应用规划※确定功能 ※必须的界面及界面跳转的流程 ※需要的数据及数据的及格式 ※是否需要效劳端支持 ※是否需要本地数据库支持 ※是否需要特殊权限 ※是否需要后台效劳 二架构设计※分层 ※网络连接 ※数据处理-xml、domain ※封装Activity 三界面设计※主界面确定 ※模块界面、列表、查看、界面 ※菜单、按钮、对话框、提示信息 ※界面总体颜色 四数据操作和存储※数据 ※数据类型 ※存储方式 五业务实现※客户端业务解析 六页面跳转 ※每个页面间的跳转 ※菜单、按钮、事件等 当前任职互联网公司APP的专职工程经理,回忆以往的经历,对自己进行总结,也希望对阅读的人有所帮助 先介绍下我的职业路线测试工程师—技术支持工程师兼测试工程师后面简称技测—技测部门主管—技术支持部门主管—客户工程经理—研发工程经理 之前的工作经历让我从不同层面有所收获,在做测试时,除了测试知识外,需要有足够的耐心,描述问题既要简洁又要符合逻辑;在做技术支持时,因为要直接面对客户,要学会沟通技巧,包括口头和文字沟通,要抗的住己客户和内部的压力; 做部门主管,要关注的是团队开展和管理,学会了管理要因人而异,有人渴望知识,有人希望被尊重,有人喜欢耍小聪明,有人喜欢偷点懒……对上要知道领导关注哪些方面,定期总结,汇报及时且有效 以上的经历,在工程管理工作中有很大的帮助 做了将近两年的专职工程经理,分别经历了职能型和矩阵型的组织架构 在职能型的结构中,我的团队中包含了这样几种角色研发、测试、技术支持,有专门的产品人员对接,但不向我汇报 在这样的团队中,从客户提出需求到最终交付,执行迅速,减少了部门之间的协商、优先级调整以及不必要的沟通本钱,工程经理对所有决策和结果负责,我个人喜欢这种结构 在矩阵组织中,我一人负责5条产品线的工程管理,更多的是关注各条产品线能否按照方案完成,处理过程中遇到的问题,有工程相关的、做队员思想工作的 对于工程管理来讲,矩阵型组织中,工程经理权利有限,难以施展 需要向各个职能部门申请资源,很多时候的使用的是参考权利 权利与责任是相匹配的,在矩阵型组织中,工程经理的成就感差 下面说说做APP的一些成长吧 最初我们做的是iphone的app,经历了两个多月的研发和测试,终于在年底前提交审核了,可是无论如何你也想象不到,我们第一版通过审核的过程是多么的煎熬 提审前查了好些资料,大局部是关于提审考前须知,也咨询了有这方面经验的同事,仍旧是被拒4次,前两次被拒苹果给描述的问题很明显,改了 后两次被拒的原因前后矛盾,我们不知所措,最后忍痛去掉了改功能才得以通过 在之后的版本升级时,翻开了这个功能很快审核通过了 首个版本审核,花掉一个多月的时间 有了iphone上的经验,之后的ipad版app进展较为顺利,一审由于名称问题被拒,尽管同类产品命名结构是一样的 苹果的规矩是让人摸不着头脑的 两个月后我们开始了android平台上的同类app开发,这个工程从一开始就犯了一个严重的错误,其带给我们的教训是惨痛的 由于这三个版本的app功能、交互都是一样的,设计、测试、运营都是同一个团队,不同的是开发人员不同,且安卓的开发人员是新招的 这个工程开始,我提出了让产品进行需求讲解,但工程组内大局部人认为不需要进行产品需求讲解,因为之前iphone和ipad的版本都做过了,也都很熟悉,最终我让步了,同意产品提出的方案,产品和研发私下沟通讲解 结果在工程执行到中后期时,工程出现了严重的delay,原因是研发对于产品需求没吃透,做的过程中需要频繁与产品确认需求细节,有些功能不符合产品要求,研发估期不准确等,当时如果再按照之前的做法继续下去,工程根本不可控,何时能完工也不能确定 经过讨论,花了三个晚上,产品、测试、研发一起逐条过测试用例,一来确认测试方案正确性,一方面更细致的让研发了解产品需求,经过这个过程后,进行了一系列补救措施以及赶工,需求细节补充,用例修改,需求变更等,通过大家一致努力,最终工程晚了两周上线 通过这几个工程,总结如下
1、新领域工程,首先要弄清楚这个工程需要哪些角色参与,每个角色的工作是什么,以前所遵循的流程是什么 尤其对于空降的工程经理,要先了解这些内容,不要一上来就改变,除非大家认为急需改变的地方 待工程跑起来后,再不断修正流程,这期间一定要勤于沟通
2、在矩阵型组织中,要善于运用参考权利,建立自己的威信,否那么后续工作开展会遇到很多麻烦 如果这时再去求助于上司,只会让领导觉得你太弱了
3、工程经理不一定要强势,强势的工程经理有时候会引起团队成员的抵触 在整个工程组中,工程经理最能用客观的眼光去看待问题的,要做到对事不对人
4、原那么问题不可以让步,这种让步会带来无尽的困扰,且补救本钱巨大;
5、既定的流程要严格遵循,工程经理协助工程组建立高效的流程,除了建立流程,工程经理还要去检查执行状况
6、必要时采用问卷调查或访谈,这个方法可以用来解决人的问题 通过收集团队成员的反应,也可以检查自己的判断是否有偏差,谈判时有据可依
7、对上报告,简洁有力 要善于总结,通过数据报表说明工程执行情况 遇到重大问题要及时向上汇报,汇报时要提供的解决方案,不要把问题直接抛给领导,要让领导第一时间知道工程进展,以及你解决问题的措施 最有效的营销手段 刷榜、限免、aso优化、换量,特定类型产品可以利用好微博营销 用户除了付费之外,另 一个价值就是传播,大局部产品除了社交类产品属于用户只会因为产品的质量而去传播, 本身要求比拟高,最简单实用的方法就是设置门槛要求用户分享 应用运营前做哪些准备 1aso应用商 店优化准备 应用权重可能的影 响因素应用使用状况翻开次数、停留时间、留存率新应用,或者刚更新会有特殊权重, 下载状况,评论数,评星 关键字匹配影响 搜索结果的要素标题255字节,关键词100字节,收费插件,开发商,汉字算一个字 节,可以把竞争对手的品牌词都列进去,描述内容对搜索结果没什么影响 2logo优化 logo是对点击率影响最高的因素,直接影响产品能走到的高度,工具类以纯色为主,主色2-3 种,如果有生活中的物品做参照再好不过了,立体和质感很重要,游戏类以人物头像进行突 出 3appstore详 细页优化 描述,显示五行, 前三行最关键,对用户转化有一定影响,和大局部渠道合作会要求在描述前面加上他们的信 息,虽然可惜,但是不能吝啬 截图,突出核心功能点并加上一些描述,不要单纯只是画面截图 评论,通常来说评 星数会是评论数的3-4倍除非应用内有引导用户区appstore评论,虽然评论务必得刷, 但是不要刷太过了 4开辟应用推荐, 无论在什么位置,但一定要有,这是资源交换的筹码 5设置收费,刚 开始的收费让运营的余地大很多 正式上线之后 6刷榜在上线 之后刷一点收费版,造品牌,让业内和用户都看到你,在之后的合作会容易很多,据说解决 网先刷后付,不过价钱略贵,这个我没有操作过
[3] 7发码同样是 造势的,投稿并提供码给测评站发文章,和佐佐卡,搞趣之类的做发码活动,不会有太多直 接下载,但是对后面铺垫很重要 冰点降价和发码 同一类型,网易有做冰点 8限免真正的 战斗开始了,限免无疑是真正的第一波带量的渠道,所以选择好合作方比拟关键的限免第一 阵营几家搞趣,iapps,苹果园,软猎,网易 推送力最强的是搞 趣,尤其是他们的特约,如果产品好的话,冲榜肯定没问题,但是他们要求比拟高,所以和 他们的商务搞好关系很重要,其他的几家联合限免效果也都还不错 9资源交换主 动给渠道商一些资源位,能帮助你在和他们的沟通中获得更多主动,刚开始你能提供的量肯 定是很少的,所以就谈按天算吧,换量比拟麻烦,一般也不是特别乐意做 10广告投放 做过一轮限免后资源交换后,有钱的可以开始做广告投放,好的渠道不多,有米,多盟,admob 算是比拟优质的了,尽量按cpa来做,能谈到
3.5块就很不错了 app营销的成 功因素 第一条因素赠送 其有价值有特色的效劳或产品 在所有的广告当中,最强大的词就是,当年的360, hotmail都是这么起来的 第二条因素如何 让传播更加方便快捷 在当今社会化媒体的时代,百度分享,加网的分享,通通要用上 必 须要精简你的营销信息,让他便于传播,一定要是文本格式的 才能像火一样迅速燃烧起来 第三条因素 利用 他人的善意的动机 你一定要搞清楚别人为什么要复制你的信息,传播你的信息能带动他人 的什么欲望一定要把你的营销策略搞清楚,并建立在共同的动机上面,那么你就成功了! 第四条因素利用 现有的人脉和圈子 据研究资料说明,每个人都有50个高质量的人 篇四工程开发总结报告 第七 届齐鲁大学生软件设计大赛—智我团队游戏—长征 游戏开发— 《长征》 工程开发总结报告 团队名称智我团队 团队成员李运强、 邹乐华、路丛磊、刘鸿媛、 宋慧 指导老师岳茂顺 第七届齐鲁大学生软件设计大赛—智我团队模板内容仅供参考 。