合理的用户业务研发团队搭配

1、前言

用户业务指的就是面向用户的产品展示及用户操作入口,简单点说就是APP,微信,H5活动页等一系列前端展现入口的集合。用户是多变的,用户是神秘的,没有任何产品能从一开始就把握住用户的需求,任何好的产品和功能都是不断试错,不断调整出来的,所以我们需要一个能快速反应的用户业务开发团队,新需求快速上线,已有业务快速调整,响应越快才越有可能在竞争中走到别人前面,产品才有胜出的可能。 用户业务业务研发团队可以称为广义上的前端团队。

2、团队意义

用户业务研发团队(后文如无特殊说明,用前端团队简称),负责完成用户侧APP,微信公众号,和用户活动的工作。

3、团队组成及承担的责任

前端团队,属于研发体系的一环,同时又与市场,运营团队关系密切。前端团队从技术上可以分成以下几个团队:

- APP团队,(Android、IOS、windows phone)

-H5 团队,

-中间层研发团队

详细说一下每个团队的组成及技术需求点

1)APP团队,主要是Android开发和IOS开发,这两种开发差距很大,下面我会详细的列下这两种开发所需要的技能点及使用场景,在组成团队的时候一定要参考自身会出现的场景来寻找合适的人,做到开发人员的技能点能hold住开发需求,免得出现问题再去寻求外部帮助。

a、Android团队的技能点

i:   常规功能开发,熟悉Android的基本控件,能编写代码,能实现功能

ii:  签名机制自动化打包,对Android打包机制比较了解,能用ant或者maven或者gradle 批量打包 和定时打包,这一点对有多渠道推广和标准测试接入的情况帮助很大,能省很多的时间,如果产品属于前期或者团队较小,可以有开发人员手动导出包来就可以

iii:  第三方组件开发,程序里常用的联合登陆,分享,支付,IM,甚至更新机制都可以用市面上已有的第三方来开发,有相关的开发经验便于快速接入新的组件,提升开发效率

iv:  Android与H5混合开发, 经常会用H5来实现比较新颖的活动或者探索新的业务模式,有过混合开发的经验有利于避免类似开发中的坑

v:  BI 数据埋点开发, 数据才能真实反应产品的运营情况,能分析需求的真正有效性,数据埋点开发对业务理解和应用基础开发(网络,线程,存储)要求比较高,数据埋点的工作越早做越好,

vi: 内存处理,线程优化,网络优化,这属于比较基础化,但又比较重要的技能点,需要的技术功力比较深,基本能处理这些问题的人都会对上面的技能点有所涉及

vii: 摄像头,蓝牙,话筒等硬件相关的开发,这个要看应用的具体功能

具备以上技能点,基本可以开发出一个完整可用的单业务型APP,如果你的APP已经大到了一定程度,甚至做成了平台型应用,需要的技能点又有所不同,那时候的APP开发完全就是另外一番天地,会另有介绍。

b、IOS团队技能点

i:  常规功能开发,熟悉IOS常用的开发组件,熟悉OC语法

ii: 苹果签名机制熟悉, 设计开发者账户申请,打包发布流程,账号管理

iii: push机制开发,有push开发相关经验,方便应用程序开发,这一项与上一项有很大关系

iv: 第三方组件开发经验,基本与Anroid的第三方经验类似,但这里需要了解IOS配置的特殊性,scheme配置,账号生效时机

v:  混合开发,IOS的混合开发比Android混合开发坑更多,方法调用极其麻烦

vi: BI数据埋点开发,同Android的埋点开发,但由于IOS应用进程生命周期不同有所区别。

vii: 内存处理,线程优化,网络优化等 同Android

viii:硬件相关,同Android

ix: swift 相关, swift是趋势,但目前开来普及程度没那么多,

IOS的优点就是基本上手机配置比较高,UI适配性比较好,但开发和发布受限制太多,趟过一遍雷的开发人员都是无价之宝。

2)H5团队,H5团队主要负责微信公众号开发,活动页开发维护等工作,做微信公众号开发和页面开发技能点有些许不同,下面详细说下

a、微信公众号开发

i: 基本的html,css,js的开发和维护,通用技能,这是必备的

ii: 微信的公众号开发经验, 主要是微信的JS-SDK的开发和应用经验,微信的文档很让人头疼,大小写能错,参数能掉,有的原理根本不解释,趟过坑的程序员都伤痕累累,令你开发起来事半功倍

iii: 前端工程化发布, 文件压缩,js混淆。代码工程化发布保证你不会在开发流程上因为代码的反复出现问题,让上线可控,为质

量提供保证。

iv: 数据统计开发, 为活动效果分析提供数据,

v: 本地化数据,cookie,storage是不常用但是非常重要的技能。

b、活动页开发

活动页开发分两种,单活动页开发和APP内置页面开发,但活动页开发相对简单,APP内置页面比较麻烦,所需技能点如下:

i: 基本技能,同微信i

ii: 代码优化,静态文件压缩,逻辑代码混淆,提升加载速度,保证代码安全

iii: 适配,不同平台不同型号的手机对不同特性的支持是不一样的,

iv: H5与原生通信,要了解H5同原生应用沟通的方法,还要对原生的webview加载机制有所了解,

v: 工程化发布,可以用世面上常用的控件,如果自己能写脚本的就更好了。

vi: 数据统计,内置的H5页基本用原生的BI统计机制来发送数据,需要对业务了解比较重要。

H5的开发目前比较火,框架非常之多,上面所说的技能点可以保证你的功能完成开发,但不够系统化,后期维护成本比较高,开发效率比较低。如果人员足够可以上大框架,但如果不够,也可以保证功能完成。

3)中间层研发

中间层研发指的是在服务接口和前端请求的中间层,主要功能是对后台服务接口的封装,承接前端的请求,来分别调用后端的服务组织数据,这个团队从技能点上来说,也可以归到后端研发,之所以归到前台好处有三,一、方便与前端开发制定接口,提升开发速度。二、小的配置性的功能开发,小功能不需要依赖后端服务开发,降低团队间的沟通成本,在一个团队里面,沟通起来快速,少费很多口舍,减少了来回扯皮,三、是对业务的梳理和总结,便于前端团队了解业务。

中间层的主要功能除了是对服务的封装和调用外,还有日志统计,流量分级等作用,细说起来很多,后续会单独介绍。

4、不同时期

公司不同阶段,资金量不同,业务大小不同,对团队的要求也不一样,后续会单独介绍。

总结一下:

欠账两篇,《前向业务中间层的作用,架构及技能要求》,《公司不同阶段,用户侧业务开发团队的工作重点及要求》下周写。

面向用户的业务,首要要求是要快速响应,体验顺畅,上面主要列了团队需要的技能点,招人的时候尽量做到范围的全覆盖,能避免掉很多开发过程中的坑,对快速开发很有帮助。当然,招的人越牛,技能点越全,开发越省心,薪水也越高,尽力平衡吧。

时间: 2024-08-05 18:54:05

合理的用户业务研发团队搭配的相关文章

让传统行业研发团队插上用户思维的翅膀

共计 5469 字|建议阅读时间 15 分钟 本文是top100 summit 2016主题演讲的整理文稿,演讲主体分三部分内容: 2015年罗辑思维跨年演讲说的“互联网恐慌”,其根本原因是什么? 什么是传统行业的最大痛点? 通过三个实际案例来讲述传统的研发团队如何理解并获得用户思维. 01“互联网恐慌”的根本原因   互联网企业如今吸引了大量的资源和目光,让传统行业的企业显得无所适从,感觉现在已经完全是互联网企业的天下,传统行业已经日薄西山,正在“混吃等死”了. 但其实我们来看一组2015年的

对话巨杉核心研发团队:分布式数据库自研之路

一直以来,数据库的核心研发团队都十分神秘,作为隐藏在幕后的隐士高人,他们对数据库发展以及数据库研发团队的看法是什么呢?本文我们就由巨杉数据库核心技术研发团队的"老司机",向大家分享他分布式数据库的自研之路. Q:作为数据库行业的"老司机",您能否先介绍一下自己?A:我叫Danny,是巨杉数据库核心研发团队的成员,是一名数据库资深工程师和架构师,有超过20年的数据库核心研发经验,曾经作为DB2 内核研发团队成员参与了DB2 ,DPF等产品的架构设计和研发工作.目前,我

中小型研发团队架构实践三要点--转

来自微信公众号聊聊架构 作者|张辉清 编辑|雨多田光 如果你正好处在中小型研发团队…… 中小型研发团队很多,而社区在中小型研发团队架构实践方面的探讨却很少.中小型研发团队特别是 50 至 200 人的研发团队,在早期的业务探索阶段,更多关注业务逻辑,快速迭代以验证商业模式,很少去关注技术架构. 这时如果继续按照原有的架构及研发模式,会出现大量的问题,再也无法玩下去了.能不能有一套可直接落地.基于开源.成本低,可快速搭建的中间件及架构升级方案呢? 我是一个有十多年经验的 IT 老兵,曾主导了两家公

中小型研发团队对于架构技术的选择与思考

如果你正好处在中小型研发团队-- 中小型研发团队很多,而社区在中小型研发团队架构实践方面的探讨却很少.中小型研发团队特别是 50 至 200 人的研发团队,在早期的业务探索阶段,更多关注业务逻辑,快速迭代以验证商业模式,很少去关注技术架构. 这时如果继续按照原有的架构及研发模式,会出现大量的问题,再也无法玩下去了.能不能有一套可直接落地.基于开源.成本低,可快速搭建的中间件及架构升级方案呢? 在接下来的一段时间里,我会陆续推出此系列文章. 本系列文章涉及内容清单如下(并不按这顺序发布),其中有感

中小研发团队架构实践之系列大纲

以下是中小研发团队架构实践系列的大纲,部分已链接,未链接部分我也会持续的更新和发布,期待你的支持与互动. 第一篇 开篇--照着做,你也能成为架构师 第1章 中小研发团队架构实践,附案例和代码 一.框架篇--工欲善其事,必先利其器 二.架构篇--思想提升 三.公共应用篇--业务与技术的结合 四.进阶篇--从架构到管理 五.案例参考和Demo下载 第二篇 架构篇--思想提升第2章 企业总体架构规划 一.企业商务模型 二.架构现状 2.1 功能架构 2.2 应用架构 2.3 数据设计 2.4 物理架构

微软中国的相关研发团队 交流平台

1. 微软中国研发集团服务器与开发工具事业部: http://blogs.msdn.com/stbcblog 作为微软中国研发集团的核心研发部门之一,服务器与开发工具事业部在上海和北京与总部及世界各地产品研发机构紧密配合,致力于为微软用户提供安全与访问.管理与服务.互连系统.数据平台.Windows服务器解决方案.商业在网服务和开发工具等核心产品与技术的研发和孵化. 服务器与开发工具事业部还积极与本土合作伙伴展开战略合作,分享研发管理和产品开发的经验,将创新成果带给广大用户.此外,事业部还在中国

Oracle 裁掉北京研发团队,相应职位撤回美国(收购了NetSuite,LogFire,Dyn)

根据中国日报报道,2017年1月14日上午9点09分,甲骨文北京研发团队的同事收到了来自BU老大的一封邮件.邮件上提及,由于市场变化,甲骨文开始整合各研发中心资源公司在云计算方向发力,文末单独提出了甲骨文在中国将会裁员,裁掉的员工必须在2017年3月31日之前离开.实际上,在一个月之前甲骨文就裁掉了大约十几个北京员工,当时大家都以为仅仅是因为人员冗余公司才进行精简.但是没想到这一次北京研发中心有200多人受到了这封措辞严谨的公开信,这意味着甲骨文为了整合研发业务,要裁掉云计算存储相关的整个北京研

国内研发团队普遍常见问题

下面是国内研发团队普遍常见问题,大家说说各个岗位怎么提高质量和效率吧. 一.产品设计 1.业务没啥清晰的战略核心主干与目标.业务需求不会解构洞察.客户提什么就做什么,业务需求和软件功能要求混在一起 2.不会建立业务模型和产品模型.客户提什么就做什么 3.不会理性需求排级,不做数据度量论证/也没有数据可度量/也不知道度量哪些合理数据.客户谁权力大谁态度恶劣谁叫的声大.就先满足谁的需求,研发团队疲于奔命赶快应付完工匆忙上线再重复填坑 4.不会增量设计.仅仅会撕开个口子强塞进去 5.场景不会分离,各种

如何组建一个合理的研发团队?

背景:不管您的公司是以产品为导向还是以项目为导向总需要一支团队去完成任务.这个团队有可能是一个研发部门,也有可能是由多个研发部门的成员混合组成,甚至有可能还包含研发部门之外的其他的组织成员,比如产品部门.运维部门.这些都依赖于你们的研发体系究竟采用了何种组织结构. 几种常见划分组织结构的方式 1.项目型/产品型 在这种组织架构中是依据所负责的产品来划分部门.比如现在要开发一套综合管理平台,在这个部门中往往会有前台开发者,比如web前端,手机app开发...,后台开发者,比如java后台,C++后