Instagram卖出10亿美金的启示

最近爆出最大IT新闻应该是Facebook以10亿美金收购Instagram，而Instagram只有13人，见报道：揭秘Instagram的13人团队和9位投资人)

分析其团队，发现如下有趣现象：老大是产品经理，老二是前端设计师，程序员老几？被产品经理兼职，这是成功网站的模子？

网站卖10亿美金，其核心是5千万用户，而程序员几乎不占据主要角色，关键还是得益于亚马逊等云计算平台，只要会编程，如何应付几千万访问量就不用考虑了，而这正是编程难点，这样，纯技术问题解决后，程序员位置就不是很重要，只要根据产品需求完成设计代码即可。

由此带来的启示是：

国内虽然没有稳定的公有云计算平台，但是管理方式能够参考这种模式，研发部门的普通程序员跟随产品经理(或项目经理)注重业务分析设计的实现，由产品经理(或项目经理)负责考核；专门的平台部门负责性能和可伸缩性Scalable设计直至云计算平台，由首席架构师或外聘顾问负责考核。

这种管理模式对程序员生涯也是有益的，如果对产品业务设计感兴趣，可以深入钻研领域建模等业务分析的方法，不是有一句话：如果程序员不注重业务，明天你的工作就会被自动化程序替代，其实云计算是向自动化编程迈出的第一步；

如果程序员对纯技术感兴趣，那么向架构师方向发展，性能微调直至分布式等Scalable可伸缩可扩展设计，最终研发或搭建出自己的云平台，现在云计算产品有很多开源，但是搭建后如何和自己的业务系统协调运行，做到成本和效率第一，因为不可能每个企业有亚马逊谷歌那样的实力，能够做到Twitter Facebook那样自己内部搞定Scalable问题就相当很好，当然租借公有云也不是什么丢人的事情，但是国内没有成熟的云平台，与其自己被别人当小白鼠试验，为什么不自己给自己试验呢？

国内很多公司没有清晰认识到这其中的区别，反正自己是软件公司，为别人提供解决方案，但是行业内软件公司和IBM这样通用解决方案公司定位又不一样，这三者关系如下：

业务客户 =>行业内软件公司(专用解决方案) ==>通用解决方案。

作为一个行业内软件公司，虽然实现的都是业务客户提出来的需求，但是这个行业也看什么行业，如果是成熟的企业管理行业，那么ERP 财务或保险金融等业务都很成熟，这时就要注重对这些客户需求模型的分解分析，这样DDD等一套分析设计模型能够派上用场，他们可能暂时对性能可扩展性要求不是很高。

但是有一类客户，不但需要软件公司提供软件解决方案，还需要帮助他们运营，面向的也是普通大众，这类客户也是产品经理，那么软件公司也要有产品经理意识，不是纯粹的项目经理，乔布斯说：用户其实并不真正知道他们需要什么，只有等你做出来，他们才觉得这是他们想要的，这句话同样适用于中国项目中的甲方，也就是中国国有系统的那些不爱动脑筋的垄断系统客户。

以Instagram网站为例，中国的软件客户，也就是甲方，应该等同于Instagram网站的用户，那些喜欢分享自己图片的普通用户，他们只喜欢有一个系统帮助他们快乐地工作就可以了，根本不会为这个系统初期提出如何深刻的产品模型，产品模型必须由Instagram的13团队来实现，不断快速迭代，倾听社区意见，也就是倾听甲方客户的要求，如果你把甲方"伺候"得愉快了，你的价值就来了。当然，不排除Oracle用1亿美金来收购你，哈哈。
[该贴被banq于2012-04-11 16:21修改过]

比较一下Instagram网站和企业软件行业的模式，这两类有显著的区别：

1.Instagram网站类似还有facebook twitter 淘宝网京东商城之类，他们直接面向普通大众，满足巨大的吞吐量是他们首要任务，以港口为例子，这个港口要让来自世界各地所有船能够立即停靠装卸，而不是让他们等待排队。

2.企业软件行业，为税务金融银行保险电信或制造业ERP等企业管理开发的软件，流程管理的灵活性以及数据可靠性是他们首要任务，特别是可靠性，可靠性常常和吞吐量是一对矛盾，就如日常饭店吃饭人一多，饭店服务质量就会下降，出错一样。

由于以上区别，导致架构技术侧重点不一样，但是我们不能说在研发管理上就可以不一样。

因为这两个行业的总体特点都是创新行业，企业软件不是说不需要创新，流程管理不需要发展，不是有一句话：不上ERP等死，上ERP找死，说明变化主导一切，唯有创新才能应付变化。

当然研发管理还会因为商业模式不同导致一些区别，第一种软件运营和研发是混为一体的，Instagram网站自己开发软件，自己运营供自己网站用户使用；而第二种，银行金融保险 ERP企业虽然也有自己的IT部门，但是软件基本都是外包开发，自己负责提出需求，也就是产品经理，交付第三方设计开发，然后验收后，再进行运营。

但是，我们细心地会发现，因为云计算的诞生，Instagram网站已经非常类似一个ERP企业的IT部门了。这也就是Instagram网站老大是产品经理，老二是用户体验师，唯独缺乏很强的程序员团队，因为他们把这部分借助云计算外包了。

同理，ERP企业的IT部门也会和Instagram网站老大一样做一个产品经理，注重用户体验，通过第三方云计算平台(私有云)解决可靠性问题，还能解决性能的可伸缩问题。

回到中国，中国实情是：ERP企业(包括金融保险)的IT部门实际是采购经理，体制僵化使他们无法做大合格的产品经理，因为IT部门非生产主要部门，不会像Instagram网站老大那样有一种责任感，产品设计不好企业(也就是网站)就要倒闭。

正是这种情况，所以，行业软件方案解决商，或者成为外包软件公司还是有生存余地的，他们就是与IT部门合作，一起进行产品设计，共同做好产品经理，当然，也负责可靠性以及性能和可伸缩性的解决。

当然类似 SAP和IBM Oracle的通用解决方案提供商会直接和企业IT部门合作，但是这种合作结果是，产品设计被严重忽略，SAP等只会把他们的设计好的业务建模模型(产品)强制塞给你，让你“找死”。

最终在中国软件行业应该是这样一个格局：

企业客户 ---> 外包软件/行业软件方案解决商 ----->云计算方案提供商。

也就是说：IBM Oracle SAP会重点转型到云计算方案提供商。这从JavaEE 7规划中增加弹性云功能可以预计到。而一些ERP咨询公司和外包软件公司会重点帮助企业研发业务模型(产品)，做好产品经理。

以上只是个人经验的预测，凭此预测进行择业或公司转型的，后果自负。

[该贴被banq于2012-04-12 08:12修改过]

看来我这个不懂业务的码农早晚要被淘汰了。。。

有同感。

大部分的程序员编码的价值正被大量的开源软件压低，压低，压到低一个组建工人的价值。（当然，我承认，有技术牛拿高薪的，如淘宝那些人。）

技术越来越复杂，新技术名词层出不穷，单单把java的基本lib以及j2ee的基本功能肯明白，至少一年时间吧。然后db后台调优，spring hibernate 中间层，web前端，js在笑着看你。等都啃明白了，云计算出来了，多core编程出来了，移动平台编程出来了。
这世界变化太快了。快的我跟不上。

换个角度，跟编码技术相比，我想往communication方向发展。

还是留在软件行业，重点转向外语，technical writing，业务讨论，需求分析软件工程这一块。

老大有何建议。

很精辟，特别是传统行业（金融、电信、物流等）的软件解决方案供应企业技术员的发展方向的这个观点特别认同！早几年走了不少歪路，现在更专注于被解决方企业（行业）的业务，而后基于业务去设计。在这个过程事也发现了不少问题：
1、这种传统行业的软件解决方案供应商的技术人员，特别是开发人员观注点很散，最终导致没有一个是真正了解熟悉整套系统进一步深入业务层面的。这样的人跳槽时的竞争力太小！
2、传业行业更注重数据稳定性，这也不可避免会更关注于后端数据库的设计；但是话说回来，这个数据库的设计同样要依赖于业务领域知识丰富的人员。
总结一句话，如bank所述，给自己在两个方向上定位，产品经理or架构师！

分析的真好，可是，“架构师”这个名词用在这里合适么？我一直以为架构师是需要精通业务的呢，您说的应该是“技术专家”吧？