后台产品,需要做整体信息架构:
之前的工作状态:
业务提一个需求,产品跟进一个,开发做一个,整体状态,以及后台架构较为混乱。那么应该要做的是:
给业务人员,多交流,记录需求点,分析高频低频操作,主次需求;然后把需求分级、排期。后台业务人员通常种类繁多:比如现在的系统来讲:运营,客服,审核人员,管理员,不同的人权限不同。权限管理相对来说,开发量还比较大。那么尤其是在产品上线前期,权限操作可以放到下一个版本来做。
近期做了一段时间后台系统,有以下两点心得
一、与开发的协调合作:
在产品上线前期,整体后台开发相比较于客户端,优先级低;并且开发人员工作是并行的(即他可能同时负责客户端和后台),所以造成我:不太好意思催他们。因为一旦他们说在赶客户端bug,这时候我就毫无理由的退后了,而且还会感觉自己催的不是时候?这样到后来,我不去跟进度,需求也没有限制他们完成的时间;程序猿的时间就不好把控,造成了节奏感断截,可能有时候特忙有时候闲。后台的工作虽然优先级不是最高,但也是一定要用上的,不少工作离开他没法进行。那如果后台没按时完成,阻碍了其它工作,产品负责人下来也会很郁闷。开发可能还会觉得产品把任务安排的不合理。
现在客户端的迭代情况:客户端是一个大的团队,每次一些细小的更新都会邮件通知给所有人,其中有承担任务和没承担任务的人,这样给有任务的人一种无形的压力(比如,大家都知道这个事情要两天搞完,搞不完就是自己的问题了)。后台我现在的做法却是给相关的两个人对需求,发邮件,这样造成他们没有紧迫感,其它人也不清楚我们在忙啥。
但是PM一定要记住:项目或者产品没有按时完成,你应该是负最大责任的那个人。这时候你去说研发效率低,测试没有仔细测什么的都不能影响到你的产品项目失败的结果。
所以比较好的做法是:后台安排任务也可以和客户端一样:切分任务,估计工时,优先级定位;这样开发可以在不忙的时候做后台,客户端有任务先搞客户端;然后,产品按时间验收后台系统和客户端。
二、给有性格的开发如何沟通
有个性的开发通常技术也NB,他逻辑清晰,思维敏捷,爱代码,经验丰富;同时,他可能很高傲,高冷。假如产品在给这样的人对需求时,场景经常想不全,逻辑矛盾。ps:逻辑有遗漏其实可以理解吧,毕竟评审就是要发现遗漏的。但绝不能总是遗漏显而易见的大逻辑。
这样的大神应该很讨厌强势的PM,个人感觉。
对待他们,1,产品要放低态度,比如后台出选方案时,不确定用哪个,可以用请教的方式,请他们从开发角度提出建议,他们的建议可能会避免你掉坑里;2、私下里多交流吧;3、PM要注意,做事要专业,不是关系好糊弄糊弄就行了,这样下去,最后糊弄的一定是自己。逻辑多想,场景多考虑。评审的时候,调整状态佳,论据、论点准备充足。