首页>新闻资讯>行业资讯

关于软件产品生命周期中角色设置的思考

2020-01-20 00:00:00
18
来自:

项目管理,软件产品生命周期

其实每个角色都是应运各个环节的需求而产生的,对于参与产品生命周期的人员而言,不管您冠以何种角色,相应环节的事情总是要有人做,角色称呼可以变,事情却总要有人做。


对于小公司而言,可能一个人全包了所有角色;对于大公司而言,以用户为导向的系统更关注用户体验,而以业务为导向的系统则更关注业务逻辑在系统中的实现,就需要针对产品重点配置相应的角色。比如互联网产品,目的是流量,那么必须要有更好的用户体验从而吸引并留住更多的用户,正常要做好互联网产品,UIUE必须有专业的团队。然而那些偏后台支持业务运作的系统往往没有专门的UIUE团队,只要产出的东西能够满足业务部门的需要,业务部门对系统的用户体验容忍程度非常高,还有一个原因就是,不管他们是否喜欢,这个系统都是他们必须用的系统,也就是用户没有选择权。


所以对于一个系统的项目管理团队建设,往往要考虑多方面的因素来设立组织架构。个人认为以下都是考虑因素,但具体量化处理依赖于各系统日常的运转情况的考量,个人认为管理层要关注日常的运转数据、不断调整适配,才能确保系统能够顺利运营和发展。


1、系统的目标用户属性

如上所述,如果目标用户互联网用户,没有培训的可能性,那么这个系统要特别关注用户体验,一般应该要设立专门UI、UE团队,且要有专业的产品经理关注、统筹系统相关方方面面的事宜。


而如果目标用户是既定范围的公司内部用户,有培训的基础,那么这个系统的用户体验反而不是最高要求,而业务逻辑是最高要求,这个时候就必须要求有产品经理专门梳理业务流程、业务逻辑,且业务部门必须有业务运营经理角色可以负责用户培训、用户咨询等工作。


2、系统的用户量

如果系统的用户量会达到一定数量级,必须建立专门的运营经理和运营工程师角色,否则无法迅速应对大量用户在使用系统时碰到的各种问题。


3、系统所实施的业务流程和规则的复杂程度

如果系统的业务流程简单、且逻辑简单、功能单一,这样的系统很容易成熟稳定,即使用户量很大可能也不会有太多的使用问题,这个时候运营经理和运营工程师的人员相对可以很少或者跟其他角色合并。


4、系统投入产出比要求

如果对于该系统的投入产出有更高的要求,就要进行多方面的分析从而对角色进行合理的配置,否则很容易超标。


5、系统规划发展的要求

如果一个系统规划良好,不易发生变更,这样的系统,运营经理和维护工程师也可以相对少些,也即维护成本会少些。有个IT同事总结的一句话非常好,没有变更就没有伤害。系统的稳定有赖于良好的系统规划,而运维的成本有赖于系统的稳定。