您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 开发技术 > 正文

我们一起聊聊管理产品和技术

发表于:2023-05-31 作者:连边 来源:连边

大家好,我是连边,这是我的第48篇原创文章。

今天说一说产品和技术,以及对应的人员组织架构。

产品直接决定着项目的成败,技术虽没有直接决定成败,但是它的架构和储备积累决定了后期的研发、工作效率。

如果要长期走下去,管理者要产品和技术同样的重视与发展。

产品

产品一般是说最终呈现出来的项目,而在我们平常工作中,它以更零散的名称存在着,就是我们所说的业务。

对零散的业务进行归集、整理,最后形成我们的模块功能,模块功能组成我们的产品。

业务的搜集,大体可以分为两个方式进行收集,主动搜集和被动搜集;

主动收集业务,即产品人员去一线观摩,主动了解业务,挖掘需求,解决痛点;

被动收集业务,即一线人员有明确的反馈渠道,可以是工作群、电子表格任何形式的反馈都算。

一般的团队是两种方式都存在,只是两种方式占比的多与少。

主动搜集方式占比高的团队,会带来诸多好处,对我们产品有着主动权,有着优先定义产品的权利,能够从这些主动信息里面去思考、抽象出自己的产品,而不是变成业务堆积出来的产品;

被动搜集方式占比高的团队,会带来诸多坏处,比如一线人员觉得我们不专业,有时候被动搜集上来的业务很少,更多的时候,是反馈急需解决的问题,没有足够的时间去思考、调研业务、挖掘需求、解决问题,最后上线的产品的业务质量、技术质量都可想而知。

所以,真正做得好的团队,应该团队内形成共识,采取主动搜集的方式,绞尽脑汁的提高主动搜集业务的占比。

这样就能提前做好规划,掌握产品规划的主动权,与研发团队进行更高效的协同工作;减少从业务源头对后续环节产生影响,很多时候被动反馈的业务,是急需解决的,首先会打乱研发团队的研发节奏,后续每个环节多少都有影响,久而久之,给产品使用方的感受就是研发产品团队不专业。

好的产品应该是被定义出来的,思考出来的,而不是靠功能堆积出来的。

技术

这里说的技术,是说技术规划与架构。

技术和其他的事物一样,要聚齐一群人,就要让其有目标感,每天徒劳的搬砖没啥很大的意思。

选择一门合适的编程语言,挑选一款合适的中间件,使用一种合适的服务框架,合理的规划项目层级,等等都可以归为技术架构。

技术规划是否合理,还有一些技术架构的选型是否合适的判断依据,还是来自产品的定义,所以应该是先有产品规划,然后才有技术规划与技术架构。

比如研发的产品的呈现形式是B/S架构,是做移动App,还是小程序?

是做平台,还是做产品微服务,一开始大的方向还是需要定下来的。

定义好大的规划之后,也找出技术积累点进行业务的积累。

像做工业控制软件,上位机与设备打交道就非常频繁,我们是不是要抽取一层驱动层,来专门沉淀解决与设备打交道的系列问题,不要每个上位机都为了设备打交道而折腾得死去活来;而涉及到大数据储存,我们就要整理出一套成熟的大数据储存方案,真有大数据使用的情况,就有开箱即用的方案。

还有服务之间相互依赖调度,是不是一开始就定义为整体项目是微服务体系架构,而不是通过各种curl满天飞?

通过产品对项目的定义,分析清楚项目之间的界限与依赖关系,决定好项目的层级,然后定好基本的开发路径,这个是一开始就要定下来的,而且在很长一段时间内也不会去进行变更调整的,后续根据该规划进行相应的人员组织架构,沉淀相关的技术。

人员组织架构

前面说了产品和技术,接下来说一说人员的组织架构。人员组织架构是与产品规划和技术架构相结合,然后一一对应的,需要注意两点:一个是各司其职,一个是责任到人。这样子有利于管理者对项目进行跟进,不然团队大了,无法协同工作。

如果项目涉及多个部门,要注意部门内部的事情或者需求要把握住从一个口径来,一般该口径为项目经理,不然团队内部事情优先级会无法排,整个团队的节奏就会不稳定。

总结

最后总结一下,还有一个注意点,不要让做技术的去同步做产品,一个是人都有惰性,二是技术人员不能从整体出发,很多时候只了解自己模块的业务,对整个项目的业务没有一个全局的认识;

还有就是产品业务不是一蹴而就的,是在技术工程师的实现的过程中会有变化的,其中就涉及到各种交涉问题,而普遍的技术人员在沟通上有明显的不足,而且容易打断技术工程师有整块的开发时间,从而导致降低工作效率。

但是可以让技术工程师在某个整段的时间内负责某个产品调研,调研之后出具PRD文档。

最后,不管是对产品还是技术,重要的还是要有产品规划和技术架构让其有使命感、目标感、责任感,然后保护好他们的整块研发时间,相信你就能打造出一支战斗力和凝聚力非常不错的团队。