风险把控–SuperSDK权限需求

一直在想个问题,为什么做产品或者项目管理的过程中,总是会出现那么多意料不到和欠考虑。

SuperSDK的权限系统,很简单的需求:让工作室的账号可以自动分配相应游戏。
细化一下需求:
①整理工作室下相关游戏/相应账户
②整理内部游戏所属的外部账号/非公司发行游戏
③将外部账号添加至工作室下
④工作室下继承旗下账户所有游戏
结果:可以给【公司内部/外部】账号添加相应游戏
风险:外部账号和内部账号添加的所有游戏,都继承到工作室下。

实际运作的时候,问题好多。
①权限是否要管理外部账号;
②外部账号的游戏,是否需要全部导入到工作室
③权限切换的时候,上线后不能自动添加而只能手动添加
④不同类型的账号全部流程/权限测试一遍:外部账号、内部账号
⑤测试管理员和非管理员权限问题/以及外部账号和内部账号

其实问题可以避免很多,如果前期把需求list清楚的话,确定好范围;问题都是可以规避的。
再细的事情,也要想明白并且想全面计划全面做全面,而不只是想想而已。

任务系统评审

14.3进公司的时候,公司没有任何项目管理和任务管理的工具,那个时候,纯粹靠excel排期。
后来在开放项目管理工具和定制化的工具之间选择,还是选择定制化,但是鉴于开发资源不足一直没有做起来;期间穿插着其他部门推广禅道,我们也用过一段时间,不过还是越用越退化了。
15.7重提任务系统,迅速开发并在9月份投入到各个协调部门使用,初见成效。
任务系统,服务各个部门:需求提出–>任务跟进–>工作量统计–>项目量总计;
但单从,导出的项目/工时耗费/工作完成量数据,看到的内容,还只是冰山一角。
广度任务系统解决的两个维度问题:
其一,饱和度。任务系统需要能够反馈出员工的工作饱和度;进一步通过工作量的衡量,反映部门的工作饱和量,合理规划部门资源。
其二,排期。各个项目组提出的需求,要合理排期,避免排队。虽然目前是通过人为排期,遇到人员饱和的时候通过加班完成;但是在系统中,体现的都是工作100%的饱和。需要通过项目量的计算,预估工作量及排期安排,为服务部门提供满意的服务支撑。
冰水底下沉淀的内容还有很多:
1、数据报告反馈出来的是100%的工作量,但是员工加班的很多,且超负荷情况很多。
2、已纳入排期的需求其实都是经过了部分排除项的,有很多为被提出来的需求,或者优先级较低的需求在需求方已经被压制住了;很多这样隐藏的需求,其实也应该纳入系统;或者作为排期的次级需求。–>发掘服务部门可能隐藏的一些需求和服务需求,并即时进行访谈和反馈询问,是否对服务支撑满意。对于内部系统及平台的工作量,也应该作为需求量计算。
3、变化多样的需求,虽然有时候工作量不大,但是沟通成本很高。–>鉴于如此,对每个工作室的需求制定一系列定制化的需求规范,要求工作室按照如此规则提出需求,减少成本。【项目治理的规范制定】
4、鉴于游戏发行在Q1和Q4量较高,这个时候存在工作量存在波峰波谷状态。–>为了合理利用资源,可以根据游戏评级,在波峰时期,将评级较低的游戏需求外包至其他供应商;波谷时期,所有需求自己完成。但是所有的节约原则都是较低支出公司成本。【对于外包,我方制定相应外包管理的统一规范,并且把控质量】

工作总结-平台方向规划

14.3月份平台产品部门,人员30。平台产品,定位是公司业务支撑部门,包括:游戏专题活动&官网等网站制作,手机游戏接入SDK支撑。

14年的 方向和实际执行情况:
基础业务中,专题&官网制作继续支撑[但是实际执行流程很繁杂,基本是没有负责人形式的流程]。还有一个就是现有业务的产品化: 手游接入SDK,由于之前SDK接入版本较为混乱.解决方法为:将所有SDK统一归集至一个版本,升级重组为S-SDK;并在SDK中嵌入其他SDK种类,解决后续各类SDK种类问题(但初期方向定位是服务于内外部,但由于内部资源问题尚未推广,只做内部服务内容使用)。

除此之外,外延方向则为新产品的开发。新产品较多,初期都是以游戏支撑为基础。
case1:积分墙。目标:在B商户中嵌入SDK,通过任务下载等方式进行刷积分,获取奖励。
【“积分墙”是在一个应用内展示各种积分任务(下载安装推荐的优质应用、注册、填表等),以供用户完成任务获得积分的页面。是除“广告条”、“插屏广告”外,第三方移动广告平台提供给应用开发者的另一新型移动广告盈利模式。】 有米、多盟等,都是国内很大的广告平台,他们有精确的广告渠道和推送机制。我们初期的想法是想在SDK中做广告SDK,但是,敌人太强,我方无背景也无发力点。
case2:游戏分发平台。目标:为长尾里面的80%的小游戏提供分发的平台。
起因:现在大的分发平台只对大游戏(背景较大,实力丰厚的公司,广告投入较大)有利处。小游戏在大平台上基本上没有任何好处。
痛点:游戏多少–平台流量。小游戏不会找小平台,因为小平台没有流量没有用户;小平台没有大的游戏,高质量的游戏,自然也拉不到较多流量。运营链转不起来了。
总结:2个产品初期都作出原型及一期产品,但都在运营时候出现问题,运营推广不下去了。作为产品部门,产品可以出来,但是推广是需要借助于外力的,最后无疾而终。

作为基础支撑,在14年暴露出很多问题。
外部:官网陈旧;用户的反馈没有做过实际改善;用户注册登录体系的陈旧以及劣质的用户体验;论坛功能不完善。
内部:游戏数目的增多,零预警和监控机制;内部;游戏接入增多,原有流程费时费力且流程和责任人不明确;网站制作流程职责不明确,负责人不清晰;海外化网站制作流程繁杂;

15年的产品方向。
外部:官网及论坛改版。用户反馈机制及积分商城的运营改版。
内部:
网站平台支撑:
1、支持游戏的预警监控体系完成;
2、网站制作流程的业务流程体系完成;
3、海外制作流程产品化;
游戏模块产品化:
1、H5-studio模板的完成,便捷后期移动H5各类活动的快速定制化需求,务须资源浪费。
2、聊天SDK的制定,为游戏定制化一个聊天插件,提升游戏内部SNS交流机制。
3、下载器SDK,支持自动进行速度判断、多CDN容灾,断点续传,降低下载失败率。
手游接入体系优化:
1、支持内部游戏的接入体系完成;形成一系列完善的wiki及说明。
新产品:
新产品计划依旧,通过appannie上面的产品调研分析爆红产品,再次基础总结归纳产品,并做产品分析及新产品规划调研。

作为一个大平台,这1年多,人数也达到60人。方向一致在不断的变化,当然,这是快速迭代的好变化。反看其他,大方向的改变,的确利于部门的换血和积极性。

工作-标签&分类

新产品中,用户搜索内容时候,一般会选择标签,也即是通过场景&状态进行搜索,然后搜索之后可能会选择直接分享或者在勾选相应的分类。
现在将分类和标签的区别总结下:

标签归属于分类
推荐使用:内容——标签——分类
任意创建内容,使用标签建立内联,概括为分类后推送给用户。分类做为对标签的归纳,不直接作用于内容。也就是说,能够大量聚集的标签组成分类,满足二八原则,其他不能聚集的形成长尾频道,通过显隐两条线来贯穿用户的所有内容需求。
如果成立,意义将远远大于纯粹的标签,同为多维结构,有序必然强过无序。

label是本身的,tag是附加的;
label强调是一种标志,tag强调是一种记号;
label标明信息之间的归属,tag区别信息之间的差异。
个人理解,拿一个人作为例子
首先你是人,你的 Category 是 “人”
其次,人有姓名,体重,身高,这些都是 “Label”
最后,这个人可以是好人,可以是 程序猿, 这些是 “Tag”

Tag,标签,一般包含一段内容的属性,可以是分类,可以是话题,也可以是作者,地理信息等。
Label,标记,是网页框架中一个区域的功能概括。比如知乎首页上的“浏览”、“问题”、“通知”就是label。选择不同的标记,相应区域的功能就会发生变化。
category,分类,可以理解为种属概念。一段内容有且只有一个种属的分类。和Tag不同的是一段内容可以有多个tag,并且tag是未预先设定的,一段内容可以有多个Tag,也可以没有Tag。但caterory在一个分类标准下只有一个。

新产品调研方式

做了快2个月的新产品调研,新产品倒是没有做,方法却自成一系。

展示一个思维导图:

目前产品调研和产出的步骤是:1、有一个新想法,基于想法全面考虑所有可以做的功能和内容;2、然后调研各类相关产品的功能点,以及各类突出点;3、最后,把想法缩减到最小。专注于做一个功能,做到能够为用户提供需要的内容。4、在规划其他内容。

不过以现在互联网产品同质化和各类垂直都已细化到不行的地方,有个新想法,就发现已经有人再做。从想到的通用积分、旅游位置标记、游戏排行、文章章节评论、照片日记、相册管理、游戏视频、到现在的SNS配图。而且,所有的产品:内容和质量是一个关键点,运营又是一个强关系的部分。