从技术经理的角度算一算,怎么可以多快好省的做个app
【导读】前端时间,一篇“从产品经理的角度算一算,做个app需要多少钱”的文章在网上疯传,可见大家对互联网创业的热情!这次,从一名技术经理的角度再给大家分析一下,如何使用跨平台开发技术为你节省上百万的开发成本。所谓“跨平台”开发技术,就是使用一种语言和一种开发工具同时支持几种不同的手机/平板设备,这样做不仅仅省钱而且开发效率高,可以让你更快的推出新版本和新功能!
作为一名软件工程顾问,我曾参与过很多的项目,主要为软件团队进行开发工具和方法论方面的咨询/培训/指导,我接触过不下100个各种类型/大小的开发团队,有传统行业,有互联网,有不差钱的,也有刚起步的创业者;其中也不乏app开发项目。开发团队遇到的问题最大共性是每个人在一个团队中的位置很大程度上决定他的判断,简而言之:视野问题!而当大家问一名IT人士那个经典的“做个app要多少钱?”的问题时,他也仅仅能根据自己的技术背景和经验给你一个答案,更加倾向于推荐那些相对稳妥的方案;而不懂技术的人更加无从判断。我想说的是:虽然互联网创业是个技术活,但技术选型一定要业务先行,ROI(投入产出比)优先。这就是为什么你首先应该从成本角度进行分析,做出判断;而不要受制于技术!
在回答完那个经典的“做个APP多少钱?”的问题后,下面这些问题就会接踵而来:
- 应该开发iPhone版本还是Andrioid版本?
- 可能需要聘用掌握了不同开发语言(iPhone使用Xcode/Object-C,而Android使用Android SDK和Java)和技能的团队成员,研发成本几乎翻倍
- 产品的后台系统使用怎样的开发环境?
- 如何在新功能上线时保证iPhone/Android的APP与后台系统的同步?
- 从无到有开发这样一款APP到底需要多少成本?
- 如何了解用户的使用习惯,并通过数据分析来指导后续版本的开发?
对于当前所流行的“互联网+”的众多创业者来说,如何能够以最快的速度和最小的成本来开发/运营自己的产品是决定是否能够在早期快速取得客户,获取生存空间和赢得未来机会的决定性因素。其实对于任何的软件开发来说,多快好省永远是我们的追求,当前的创业大潮使得这一原则更加凸显,也让更多的人了解到了软件开发。
DevOps(研发运维一体化)也是最近几年在软件行业非常流行的做法,DevOps通过打通开发和运维这两个原本属于不同领域的团队来为我们运营产品提供更快的价值输出,其实也是多快好省地体现。从用户的角度,使用手机/平板等移动设备的用户已经超过了PC用户,而在移动设备领域又存在着iPhone/Android/Windows三分天下的状况,这使得上面所提到的快速推出产品变得更加困难,同时由于不同的设备所使用的操作系统,开发环境和运行环境都完全不一致,让我们的研发管理变得更加的复杂,实现DevOps也是难上加难。
本篇博客将使用MyShuttle.biz这个应用来为你展示一个“互联网+”时代的创业团队如何使用跨平台开发技术来多快好省地解决以上问题。
在2014年的 Visual Studio and Azure Connect() 在线发布会上,微软使用了一套名为 MyShuttle.biz的样例程序来展示Visual Studio 2015和Microsoft Azure所提供的DevOps能力,这套样例的源代码也被分享出来。其中使用了众多的技术来全面展示微软开发工具和云计算平台所提供的跨平台开发和DevOps能力。
全套样例代码可以通过以下地址下载:
https://code.msdn.microsoft.com/windowsapps/MyShuttle-demo-applications-1a4b68fe#content
跨平台移动开发白皮书 – MyShuttle.biz案例分析
这本白皮书将对当前2大主流跨平台开发技术进行详细的介绍,我将借助MyShuttle.biz这个案例,为你展示如何使用跨平台开发技术结合云计算完成一个典型“互联网+”产品的技术布局,团队组织,开发环境配置和开发流程管理,最终实现基于云的开发运维一体化(DevOps)环境。由于内容较多,我将按照以下顺序逐步发布;本系列的前一部分不会涉及过多的技术内容,适合创业者,技术管理者和普通大众阅读;后半部分会涉及较多深入的技术细节,适合对DevOps和跨平台移动开发技术本身感兴趣的朋友阅读。
- 案例背景:MyShuttle.biz的业务模型,应用架构
- 跨平台开发技术如何做到多快好省的?
- 跨平台开发技术的成熟度和不同方案优劣比较
- 跨平台开发环境配置和能力分析
- Apache Cordvoa HTML/JavaScript Hybrid APP 跨平台技术
- Xamarin 原生APP跨平台技术
- ASP.NET 5 跨平台开发技术
- 基于云端的DevOps环境配置和能力分析
案例背景
MyShuttle.biz是一套类似“滴滴出行”的互联网租车应用,可以为企业用户提供叫车,计费和后台管理能力,解决企业用户日常用车需求。虽然“滴滴出行”解决了普通民众的出行需求,但是企业用车市场仍然是空白。作为在公司中工作的人来说,有客户到访,公司团建,出游,甚至日常的跑业务,税务等活动都需要用车,而企业养车则是非常大的开销;MyShuttle.bizs就是在这样的大背景下诞生的,希望能够将租车公司的空闲车辆与企业用户相衔接,实现社会交通资源的优化和企业用车成本的降低。
大家可以通过以下视频来了解这个应用:
应用架构
MyShuttle.biz使用3套相互独立的系统来实现以上业务目标,后台系统通过云计算提供数据存储,业务逻辑处理和后台管理功能,并通过网页应用/Windows APP的形式提供给租车公司/用户企业的管理人员使用;用户APP通过各大应用市场给用户免费下载和使用,用户可以使用APP完成叫车,付费和订单管理功能;司机APP则提供给司机使用,完成叫车信息的推送,接受订单,跟踪里程等操作。
后台系统除了可以由用户通过浏览器完成各种操作外,还提供了流行的Restful接口供APP和其他第三方系统集成使用。
后台系统
- 使用SQL Azure 提供安全的高可用数据存储服务
- 使用ASP.NET 5 WebAPI和Azure Mobile Service 所提供的WebAPI提供数据访问服务
- 为租车公司提供基于浏览器的SPA应用(单页面应用)来进行车辆,司机和订单管理服务
- 为用车企业管理人员提供基于Windows APP的桌面应用来管理员工,车辆订单
用户APP
- 使用Xamarin跨平台开发工具提供原生的App体验,同时支持iPhone/Android/Windows Phone三大移动平台
司机APP
- 使用Apache Cordova跨平台开发工具提供基于HTML/Js的Hybrid App体验,同时支持iPhone/Android/Windows Phone三大移动平台
“跨平台”技术如何做到多快好省?
由于使用了跨平台开发技术,我们不必聘用同时具备Object-C/Java/C#能力的开发人员,只需要熟练使用C#语言和Visual Studio IDE的开发人员即可,我们的团队组成可以规划为:
– Team 1: 2名后台开发人员:
○ 熟练使用C#开发语言,ASP.NET MVC
○ 对Microsoft Azure云计算平台有所了解
○ 了解Restful接口开发
○ 负责后台系统中的数据库,WebAPI开发
– Team 2: 2名HTML/Javascript/Web/APP开发人员:
○ 熟练使用C#/HTML/JavaScript/CSS开发语言,前端框架如Jquery, AngularJS
○ 对Microsoft Azure云计算平台有所了解
○ 了解Restful接口开发
○ 负责Web SPA App及Apache Cordova Hybrid APP的开发(司机APP),同时支持iPhone/Android/Windows Phone移动平台
– Team 3: 2名原生APP开发人员
○ 熟练使用C#和Xamarin
○ 了解Restful接口开发
○ 负责原生APP开发(用户APP),同时支持iPhone/Android/Windows Phone移动平台
– Team 4: 1名设计人员
○ 熟悉移动APP和Web应用用户体验设计
○ 可以独立完成平面原型和元素切图,熟悉应用开发过程,具备与开发人员合作的经验
– 1名产品经理
○ 熟悉互联网产品和移动APP运营
○ 熟悉互联网产品开发,具备与研发团队合作经验
○ 可以独立完成用户故事的编写
○ 熟悉敏捷开发过程,熟练使用backlog来进行产品规划
○ 良好的沟通能力
– 1名技术经理
○ 熟练使用C#/ASP.NET MVC/HTML/JavaScript/CSS等开发语言
○ 熟悉主流前端开发框架和Restful接口
○ 熟悉Microsoft Azure云计算平台
○ 熟悉互联网开发,具备管理研发团队经验
○ 熟悉敏捷开发过程,数量使用backlog,sprint,burndown,kanban等工具来进行产品开发过程管理
○ 良好的沟通能力
当然,根据应用的复杂度和业务量的不同,我们也可以对以上团队结构进行简化或扩展;如果我们资源有限,可以按照以下思路简化团队
- 将Team 1和Team 2合并,节省2名开发人员;因为大家都使用C#语言,MVC架构和REST接口的实现与前台开发关系紧密,这样做不仅仅可以节约成本,还可以提高开发效率,节约团队间的沟通成本;当前,前提是工作量和进度的要求可以满足。
- 在Team 1/2合并的基础上,我们还可以考虑只使用一种跨平台技术(Apache Cordova或者Xamarin),这个案例中,为了能够展示不同跨平台技术的优劣而同时使用了2种技术;而在真实的项目中,我们完全可以只使用一种;这样,我们还可以考虑砍掉team 3,而由Team 1/2完成所有工作,这也是使用HTML/javascript作为统一的前端语言以及Apache Cordova提供的最大优势;让我们可以使用最少的团队实现最多的移动平台覆盖;当然,如果用户对于界面体验要求较高,使用Xamarin原生跨平台方案还是有其优势的。
随着业务的推进,我们也许需要扩展团队,使用跨平台开发技术前提下,无论简化或者扩展团队,我们的团队永远会和业务对齐,不会有多条业务线使用同一个技术团队的情况出现。在传统的开发模式下,如果你没有足够的资源给每个业务线(司机/租客等)配备独立的技术团队,而按照技术平台(iPhone/Android)来组建团队架构的话,就会出现不同的业务线需要同一个技术团队做不同的事情,这时候必然会造成资源冲突,造成内耗。而使用跨平台开发技术就很好的避免了这个问题,因为我们不必因为技术不同而割裂本应该跟随业务的团队结构。大型软件研发团队的管理中的首要原则就是团队应该和业务对齐,而不要受技术选型的影响;这样做的目的是为了我们可以根据业务线的需求,最小化外界因素对交付的影响,做到按照业务功能持续交付;而多条业务线使用同一个技术团队,不仅仅开发人员无所适从,也会大幅增加沟通成本,造成质量问题。
最后,对于团队建设和能力成长,采用跨平台技术的团队使用同样的语言,工具,开发环境;这使得团队成员的沟通变得容易,大家可以一起交流技术,互相帮助对方完成工作,这样更加有利于我们建立健康的团队氛围,培养大家互相协作的气氛。
按照以上团队能力,下表中我们看到研发成本的计算:
(以下开发人员工资的数据采集自****的2013年开发者薪资调查,根据这份调查的数据我大致估算了各个类别程序员的薪资中上位水平,同时乘以1.4的系数以考虑社保等因素来计算总体月成本。调查原文:http://www.****.net/article/2014-03-26/2818997/1 )
需要特别提一句,这里的团队配置中我们对每个技术岗位的职位都配置了2个开发人员,同时不同技术岗位因为所使用的技术非常相似,都具备互换性。岗位的互换性对于我们避免员工生病/请假/离职所带来的影响非常重要!而且我这里的平均工资达到了18000元/月,比产品经理的那个计算方式更高!这意味着你可以聘用更高水平的开发人员。
按照以上我们也可以推算出前3年的开发成本:
如果按照以上计算,单单使用跨平台移动开发技术,就可以在第一年为你节省将超过60万元的研发成本,随着团队的扩大(因为APP团队占研发成本的大部分),节省的比例和金额会变得更加惊人!请大家注意,在“产品经理”的计算中,他所使用的“第一版”成本是按照6个月计算的,大致100万的研发成本,和我这里的“传统”计算方式基本一致,而实用“跨平台”技术的“第一版”成本比“产品经理”的计算方式低20万元!
在现实中,我遇到的朋友很多都问我怎样多快好省地开发一款app,我常常告诉他们应该用跨平台技术;但最后的结果他们还是会选择传统的各平台独立开发的方式,希望以上的分析能够帮助这些朋友可以对“跨平台”技术的成本优势有所了解。当然,你心里关于这些技术的其他疑问,比如他们和传统原生app有哪些不同,各种不同的跨平台技术间有哪些优劣,在后续的文章中我都会一一解答……
更多内容,请关注公众微信号 DevOps
- 21楼小猪凯
- 看起来很美好,可是实际用起来就不知道有多少坑了。,,不过我想企业如果想开发企业应用,还是没问题的,,如果想开发面对整个互联网的产品的话,恐怕原生的才行吧。
- 20楼王传炜
- 这么多团队没选择Xamarin是有原因的,这个风险是需要技术经理考虑的。花更多的钱和项目风险的避免是要好好权衡的。
- 19楼午后的小睡
- 不接地气的DEMO方案,或者说楼主自己就没有互联网系统实施经验!甚至连基本的产品经验都没有!,,1.真正的核心账务、会计、支付、资源调配、地理2个人就搞不定,更别提那些复杂的积分奖励代金劵机制,想把前端团队和业务团队合并就不可能,现在的经验不但不是融合,而是彻底分离。,,2.Xamarin是个然并卵的方案,要求既会.net又会iOS和安卓原生开发,基本是全栈工程师了,精通的人才基本找不到,从未在互联网行业见过成功案例,天生缺陷,没法集成第三方库,所有调用都要转换一次,开发效率及其低下,根本没法满足互联网业快速迭代的需求。,,3.楼主确定开过车?车速60迈时一秒能撞死一票人, 用交互缓慢的hybrid来做司机端,这要害死多少人啊。,,总之,国内互联网业做到今天,所用的技术也好方案也好,是一步一坑一血泪积累出来的,不是微软弄了这么个空中楼阁的整合方案就能解决的,你的那些朋友选择是正确的,用你这个方案只会最后推倒重来!
- Re: 记忆
- @午后的小睡,引用不接地气的DEMO方案,或者说楼主自己就没有互联网系统实施经验!甚至连基本的产品经验都没有!,,1.真正的核心账务、会计、支付、资源调配、地理2个人就搞不定,更别提那些复杂的积分奖励代金劵机制,想把前端团队和业务团队合并就不可能,现在的经验不但不是融合,而是彻底分离。,,2.Xamarin是个然并卵的方案,要求既会.net又会iOS和安卓原生开发,基本是全栈工程师了,精通的人才基本找不到,从未在互联网行业见过成功案例,天生缺陷,没法集成第三方库,所有调用都要转换一次,开发效率及其低下,根本没法满足互联网业快速迭代的需求。,,3.楼主确定开过车?车速60迈时一秒能撞死一票人, 用交互缓慢的hyb...,,Xamarin是个然并卵的方案,要求既会.net又会iOS和安卓原生开发,基本是全栈工程师了,精通的人才基本找不到...,赞同!!
- Re: 北京的201个蓝天
- @午后的小睡,1. 这里说的是起步阶段的APP开发,2个人团队的情况非常普遍,2. 全栈的意思不是各个平台(水平)搞定,而已一个应用的前后端搞定(垂直)。全栈工程师需要的技能是和业务对其的,只要他的技术可以满足全部业务开发就已经是全栈了。用跨平台技术让程序员更有可能成为全栈,更可以帮助团队减少中间环节和沟通损耗,3. hybrid应用确有其性能问题,用它做什么类型的应用确实权衡(至少在现阶段),这个DEMO的目的是为了展示工具的能力,不完全是从真是场景出发的。,从为程序员提供好工具的角度,微软的方案是否是空中楼阁,自有评说~~~
- Re: 有一点难
- @午后的小睡,引用不接地气的DEMO方案,或者说楼主自己就没有互联网系统实施经验!甚至连基本的产品经验都没有!,,1.真正的核心账务、会计、支付、资源调配、地理2个人就搞不定,更别提那些复杂的积分奖励代金劵机制,想把前端团队和业务团队合并就不可能,现在的经验不但不是融合,而是彻底分离。,,2.Xamarin是个然并卵的方案,要求既会.net又会iOS和安卓原生开发,基本是全栈工程师了,精通的人才基本找不到,从未在互联网行业见过成功案例,天生缺陷,没法集成第三方库,所有调用都要转换一次,开发效率及其低下,根本没法满足互联网业快速迭代的需求。,,3.楼主确定开过车?车速60迈时一秒能撞死一票人, 用交互缓慢的hyb...,,,赞同。, 中国的事情,就是被所谓的专家搞坏的。哈哈。
- 18楼zhaojieTec
- 设想是美好的 道路是曲折的 http://www.cnblogs.com/zhaojietec/p/4887809.html
- Re: 北京的201个蓝天
- @zhaojieTec,问题确实不少,资料有限是个主要问题。回头补充一些成功案例给大家看。
- 17楼cwwhy
- 就目前来说,Xamarin成本会相当的高:,1.比较熟悉Xamarin的人员不好找,现学?你确定这个风险有多高不?,2.Xamarin使用的人太少,出了问题你就傻眼。,3.Xamarin,Mono等都有相当多个bug和坑,你确定你准备好了?当然,别的工具和平台也有坑,但是那些坑网上都有成熟的解决方案,Xamarin和Mono的坑就不好说了。,,如果团队没有比较成熟的项目经验,贸然使用一个新的工具或平台,一定要做好填坑的准备,工期要留有足够的余量。,,楼主保重!
- 16楼gw2010
- 看到这个工资分配觉得很牛B
- 15楼淡墨尘
- 曾经就是尼玛做的T1和T2的事,拿的买白菜的钱,然并暖,市场决定后台的钱多少,后台的态度决定app的实际质量多少,这个钱省不了的,当然,给客户做的就无所谓咯,前端客户端好是真的好,呵呵哒。
- 14楼kkun
- 徐总现在研究啥呢?
- Re: 北京的201个蓝天
- @kkun,还是开发工具,老本行 :),不过兴趣广泛,好玩的都研究。
- 13楼慕容小匹夫
- 运行效率并没有问题,针对ios平台,C#写的源代码可以直接编译为arm的机器码,因此可以省略掉所谓的“调用转换”,跟使用oc或swift的源代码没有什么区别。,至于安卓平台,由于xamarin开发的安卓应用实际上是在安卓设备上运行了自己的运行时,而不是安卓的ART或Dalvik。因此xamarin也有直接调用原生的能力,甚至比跑在ART或Dalvik中的java源代码要更好。当然,还是要用数据说话:http://stackoverflow.com/questions/17134522/does-anyone-have-benchmarks-code-results-comparing-performance-of-android-ap ,,很支持楼主的看法,也是我一直向往的开发模式。
- 12楼蚂蚁跳楼
- 说实话,还不如Qt来得方便
- 11楼红与黑
- 然后加班加成狗,哈哈哈哈.............
- 10楼深蓝医生
- 好像还有一个B4X方案,用basic语言开发,编译成不同平台的目标代码,没有运行时转换的问题。
- 9楼kingcomxu
- 我就想知道, xamarin这玩意能调用第三方开源库不能?,如果不能, 你们要实现像图像加载库这些基础功能, 岂不是又得加人手?还吃力不讨好?
- Re: 北京的201个蓝天
- @kingcomxu,可以 http://developer.xamarin.com/guides/ios/advanced_topics/binding_objective-c/
- Re: 北京的201个蓝天
- @kingcomxu,还有安卓的库 http://developer.xamarin.com/guides/android/advanced_topics/java_integration_overview/binding-a-java-library/
- 8楼liuzhenhua321
- 好文,以后项目报价也可以参考下,牛
- 7楼Ray.Yan.SZ
- 国内有几家公司用xamarin做过商用项目,这玩意授权费用太高,bug太多;既要懂c#也要懂android/ios系统;加上各种第三方库支持的缺失,你确定这玩意能降成本?,还有一些类似的js第三方的东西,像sencha touch;低端手机上性能太差,android上兼容性太差。,第三方跨平台,想法很好,等你自己去折腾一下你会苦不堪言。我是把xamarin还有js跨平台的折腾了一年多,现在老老实实原生开发。
- 6楼zzmsl
- Team 4: 1名设计人员,○ 熟悉移动APP和Web应用用户体验设计,……,好吧,系统设计的去哪了?难道后台的来做?
- 5楼cwwhy
- 前提是Xamarin等跨平台技术有和原生开发差不多的成本,,如果Xamarin成本比原生开发高的多,那你这个就不准确了。
- Re: 北京的201个蓝天
- @cwwhy,Xamarin需要购买授权(每年增加几千块的开发成本),使用Visual Studio的话现在有社区版,功能全部满足。会使用C#的开发人员都有能力掌握Xamarin的开发技术,这本身的成本与全队成本比较起来微不足道。
- 4楼xuanbg
- 跨平台是有一定局限性的,如果产品遇到跨平台工具的这个问题,会带来更多的成本。
- Re: 北京的201个蓝天
- @xuanbg,任何工具都有坑,趟坑就是开发者的日常工作而已。话说要比较开发工具,VS可定比Xcode好用一万倍!
- 3楼love24
- 后台就是个笑话。
- 2楼Ender.Lu
- 原生才是皇道,,hybird就是做些小玩意儿忽悠用的。以好看且快速完成为目标。
- 1楼speed123
- 后台这么不值钱?所有的业务逻辑,数据处理全交给后台去做,后台就这么点?看来我又要开始考虑转方向了,当初C#转PHP,现在PHP转前端去
- Re: 北京的201个蓝天
- @speed123,这是市场决定的,后台很重要,但是知识结构确实有差异。