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