工作技能反思

工作中遇到的问题进行思考，为什么做得不好；总结，能不能抽象出理论方便之后的决策。

有什么做的还不错。

持续更新……

---

1.  搭好了框架之后，没关心之后填充的内容
   1. 不要每次更改内容都重发产品版本，这是常识
      1. 对于一些内容会经常变化的，尤其是非产品人员（运营、课程）控制的产品组成部分，抽象出一些共用框架，填充内容由内容产出者自行填写，发布（当然，如何发布，发布的权限也需要根据内容的重要程度再仔细定义）
      2. 而且根据内容产出者的需求，尽量考虑全面，以适应不同的内容情况
   2. 但是更重要的是后续的跟进
      1. 内容产出者可能会考虑不够全面；有一些功能在实际使用过程中才会想起
      2. 内容产出者可能会考虑太过全面；可能会担心承担需求变更的责任，定义时什么功能都想要，但实际并未使用
      3. 内容产出者实际执行时没有遵守一开始定义的规则
         • 比如unit group name、unit group short name、unit name、unit short name
   3. 所以，发布之后，需要跟进正式发布内容，看一下真实用户看到的界面，看到的内容呈现；开发也需要一并考虑那些是可以抽出来的共用模块，方便版本优化
2. 对已有功能、结构太尊重，限制太多
   1. 小步快跑，尽量减少开发量的同时，也可以看下哪些是可以优化体验的
      • 每次作业是否需要分题包显示，是否可以有答题卡（category－course－unit group－unit－package group－package；原本内容拆的层级比较多，为了应对不同老师的不同的上课进度）
   2. 先think out of the box，各方面协商下来，做不到，仍可以做一个记录，沉淀下来
3. 项目相关人员没有通知到位
   1. 形式要有
      1. 项目启动，确认好全部参与人员（产品、设计、前端、后端、测试、课程）
      2. 召集开项目启动会议、需求评审、需求移交
   2.  在项目初期就要确定通知机制
      1. 邮件通知（定义好邮件组）
      2. redline 建task
   3. 如果是长期优化项目
      1. 确定好项目发布周期
      2. 文档、素材移交时间、验收时间、测试时间
   4. 如果是从0开始的项目
      1. 确定好最终的时间节点
      2. 阶段性目标、功能点、各步骤时间节点（文档、低保、高保、开发、测试、发布）
   5. 这种比较大的项目初期，还可以定义好每个功能的实现风险程度（嗯，对大家、对老板都要有心理准备）
   6. 除了功能需求，还有性能需求、数据监控需求、兼容性需求等也可以提前考虑

 

这些时候感觉自己是发光的……

1. 场景：学生端产品，在iPad上已经开发的差不多了，准备把这套都放到PC上，替换原有的老版本，避免重复开发。但是比例、尺寸，和老版本不一致（一个是1024*768，一个是960*560），而且老版本被其他合作机构内嵌入他们的官网，有各种各样的布局、背景色，开发觉得无法实现。
   • how：提出把整个内容分成3个系统，登录+学习（iPad中实现）+游戏（非常复杂并且庞大的娱乐系统），登录、游戏系统，保持原来的尺寸，在外面加一个框，即添加插图，透明底，使占用总面积和学习系统一致。改动最小。
2. 场景：教师端产品，一个线下班级的学生，会拆分成多个线上小班上课。然后要对他们的上课视频进行整理，把某个单元的课程归类到一起，并记录上课数，排课数。开发实现方式，后台计算这个线下班级某个单元总共有多少上课数、排课数，前台再去分成小班。这个时候，开发觉得计算不出每个小班的总排课数是多少。
   • how：提出都在后台计算，前端加载速度也能提升，但是开发量比较大。方案二，不要根据排课的数据来计算，而是根据课本的配置数据来显示，数据中会有某个单元是多少个课程。