目的

我们工作中的每一个任务,都应该有质量基础,这样出去的东西才能有最起码的保障。

根据经验,将任务分为:“日常” 与 研究 两个部分,其中又有许多细分项目,理应每个项目都有自己的质量基础。

我们在日常过程中,应该逐渐补齐。

目录:任务结构

初期构思的图
  • 日常
      1. 阅读信息=⇒分析诉求
      2. 回答诉求
      3. 风格化回复
    • 写文
      • 公众号
        • 信息传递
        • 日常推文
          • 玩家心情回复(情感电台)
          • 玩家意见回复
          • 搞笑专题
          • 新闻专题
      • TapTap文章
      • 评测报告
      • 游戏内外公告
      • 游戏运营信息
      • 游戏文案
  • 研究
    1. 研究目的
    2. 逻辑过程
    3. 实践方案 + Demo
    4. 教育测试
    5. 同伙测试
    6. 同伙反馈

引导信息

也就是说,日常任务分类较多,研究性任务基本一致,如果有需要,日常任务需要单独点开查看他们各自的质量保准。日常任务也许是个小项目,很容易就确定质量标准,也许是个复杂的工程,需要作为课题研究。

研究

研究目的

每一次研究,应该明确研究目的,以提高效率,解决问题作为导向,一般要回答:解决了什么问题,或者提升了什么样的工作效率。

逻辑过程

针对研究结果,你的推理过程是怎么样的,目的就是确保别人明白你得出这个结论的理由是什么,在什么环境下可以得出这个结论。

实践方案 + Demo

研究不应该只停留在书面阶段,每一次研究,必须确保有实践结果,以及供别人阅览的Demo,这样才能确保课题的有效性,结果的可证明。

教育测试

实践出的方案应满足工业流程的需求,别人可以在简单了解原理后快速使用,甚至不用了解原理就可以根据手册使用。

所以包含教育测试环节,每一次研究的课题,都应该向其他人进行教育测试,确保结果的可继承性。

同伙测试

当别人以为学会后,要进行他人独立测试,只有他人独立测试并且得出预期结果后,才能证明方法最终的可继承性,才能承认他的简单性,如果在过程中,有许许多多的问题需要咨询,则需要重新思考教学方案或者结果本身是否需要回改。

若伙伴测试皆不能达到预期的满意效果,则课题失败,需要重新进行,或换人研究。

同伙反馈

当同伙测试成功后,应该基于自己的学习与使用流程,用邮件文档形式反馈给课题研究者,文档应该记录在Wiki,最终帮助研究者完善课题结果。

/var/www/html/data/pages/工作细则/任务质量基础.txt · 最后更改: 2018/11/12 16:18 由 john
Powered by PHP Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0 Valid HTML5