yongtree吐槽:互联网产品开发乱象

08083804_i84V.jpg

从工作几年后,自己慢慢的觉得自己喜欢互联网领域的开发,这个领域能让我保持对技术高度的警觉性,能给我带来很多的新鲜感,所以一直在研究互联网领域的开发模式和特点。从企业应用领域转到以互联网为主的领域也差不多两三年了吧,这几年我明显感觉到找到适合我的发展之路,因为有兴趣所以让我不知疲倦的学习,成长。但是这几年也深深的体会到,互联网领域的开发不是一帆风顺,总有一种怪怪的感觉,如鲠在喉不知所然,我认为最大的问题在开发过程中的理解不统一,新观念和旧传统存在着激烈的斗争,不同的思路难以融合。

作为大多数的管理者,即使和产品开发很近的产品经理、运营人员甚至开发人员,更别说企业高管,大家张口闭口商业模式,管理方式,人们总是盯着市场、“参与”运营,而真正去关注产品开发过程的又有多少呢?正是这种不关心,让整个产品团队没有统一的、正确的流程,没有一致的思路,在一个相互不理解,有隔阂的环境中,产品开发的过程自然不顺畅,没有好的产品,一切的努力都像无病呻吟。在这个时代,我可以很极端的认为产品决定一切,可惜大家都没有关心产品开发的过程,于是存在我发现的互联网产品开发的乱象。

1、根本没有一个以产品为中心的团队。

我们不能再像以前做项目一样,把团队按照需求团队,设计团队,开发团队,测试团队分割开来,各自利益不统一,权责过于独立,团队与团队之间是相互谈判的关系,讨价还价。也不能像项目团队那样,需求来了临时抓人,需求完成人也走了,需求再来又是新人。互联网产品永远都是beta版,要时刻不停的关注市场和用户的需求,需要不间断的升级,互联网产品开发没有维护阶段,永远都是开发、再开发,时刻不停的迭代前进,我们不认可这一点,我们就无法形成一个以产品为中心的团队,我们也无法创造出有生命力的产品。

2、人人都是产品经理

前几年淘宝团队的一个员工写过一本书叫《人人都是产品经理》,可能这本书被人们误解了,于是很多人自认为自己是产品经理,肆无忌惮的提需求,加功能,梦想着自己的想法可以改变世界,结果却改变了用户,让用户所唾弃。其实这本书前面少量两个字“希望”,希望每个人都有产品经理的思维和行为方式。关键是我们很多人有产品经理的素质吗?没有,但是还乐于干产品经理的事,结果做了一坨坨垃圾的产品。我曾经写过一篇文章《他们是提需求的,不是做产品的》,其实就是讽刺的这部分人。

一个好的产品经理的确能决定了产品的未来,就像张小龙之于微信一样,顶级的产品经理打造顶级的产品。

3、变异的用户体验

很多做产品的人经常把用户体验挂在嘴边,要求做极致的用户体验,甚至危言耸听的说体验做不好很难留住用户。什么是用户体验,长的漂亮?功能强大?好玩?新鲜?流行?不同的产品人员对于体验的理解不太一样,可以参考我以前写的一篇微信分享文章《我对产品经理的分类[微信分享20130623]》。我认为最好的用户体验就是抓住用户最核心的需求,解决用户面临的问题。这个体验做不好,其他的全是扯淡,一个好看的花瓶,不一定养出美丽的花朵,因为它缺少适合的土壤。土壤不好看但是这恰是花儿最需要的,而我们很多产品人员却往往忽视这些看似丑陋的东西。

4、没有迭代,升级太慢

做互联网产品的思路应该是小步快跑,快速迭代,不断的保持升级更新,不断的反馈需求,不断的满足需求,只有这样这个产品才有生命力。但是我们有很多产品人员,特别是传统领域做的太久的产品人员,根本不是这样的,要么不提需求,要提就是一筐筐的,说这是他想了很久的。而且功能繁多,难度很大,没有个一两个月很难搞定的。为什么不持续的提需求,持续的改进产品呢,从产品的角度来说,小而快才更容易变化,才更容易纠正错误,否则当我们付出太多发现不对,错误难以纠正,纠错成本太高;从管理的角度来看,频繁持续的开发才能将资源平均,资源利用最大化,否则紧一阵松一阵。我一直推崇web产品一周为一个迭代周期,三天开发,两天测试,一天发布。移动端开发可以半个月为一个周期,持续升级。

这些产品开发的乱象,我想归根结缔是我们没有关注产品开发过程,没有理解这个过程的特点,不同角色之间没有统一的流程和思考方式。您觉得呢?

 原文:http://www.yongtree.net/post/184f95_733b25

关注微信:yongtree_it,更多吐槽

转载于:https://my.oschina.net/yongtree/blog/143063

内容概要:该PPT详细介绍了企业架构设计的方法论,涵盖业务架构、数据架构、应用架构和技术架构四大核心模块。首先分析了企业架构现状,包括业务、数据、应用和技术四大架构的内容和关系,明确了企业架构设计的重要性。接着,阐述了新版企业架构总体框架(CSG-EAF 2.0)的形成过程,强调其融合了传统架构设计(TOGAF)和领域驱动设计(DDD)的优势,以适应数字化转型需求。业务架构部分通过梳理企业级和专业级价值流,细化业务能力、流程和对象,确保业务战略的有效落地。数据架构部分则遵循五大原则,确保数据的准确、一致和高效使用。应用架构方面,提出了分层解耦和服务化的设计原则,以提高灵活性和响应速度。最后,技术架构部分围绕技术框架、组件、平台和部署节点进行了详细设计,确保技术架构的稳定性和扩展性。 适合人群:适用于具有一定企业架构设计经验的IT架构师、项目经理和业务分析师,特别是那些希望深入了解如何将企业架构设计与数字化转型相结合的专业人士。 使用场景及目标:①帮助企业和组织梳理业务流程,优化业务能力,实现战略目标;②指导数据管理和应用开发,确保数据的一致性和应用的高效性;③为技术选型和系统部署提供科学依据,确保技术架构的稳定性和扩展性。 阅读建议:此资源内容详尽,涵盖企业架构设计的各个方面。建议读者在学习过程中,结合实际案例进行理解和实践,重点关注各架构模块之间的关联和协同,以便更好地应用于实际工作中。
资 源 简 介 独立分量分析(Independent Component Analysis,简称ICA)是近二十年来逐渐发展起来的一种盲信号分离方法。它是一种统计方法,其目的是从由传感器收集到的混合信号中分离相互独立的源信号,使得这些分离出来的源信号之间尽可能独立。它在语音识别、电信和医学信号处理等信号处理方面有着广泛的应用,目前已成为盲信号处理,人工神经网络等研究领域中的一个研究热点。本文简要的阐述了ICA的发展、应用和现状,详细地论述了ICA的原理及实现过程,系统地介绍了目前几种主要ICA算法以及它们之间的内在联系, 详 情 说 明 独立分量分析(Independent Component Analysis,简称ICA)是近二十年来逐渐发展起来的一种盲信号分离方法。它是一种统计方法,其目的是从由传感器收集到的混合信号中分离相互独立的源信号,使得这些分离出来的源信号之间尽可能独立。它在语音识别、电信和医学信号处理等信号处理方面有着广泛的应用,目前已成为盲信号处理,人工神经网络等研究领域中的一个研究热点。 本文简要的阐述了ICA的发展、应用和现状,详细地论述了ICA的原理及实现过程,系统地介绍了目前几种主要ICA算法以及它们之间的内在联系,在此基础上重点分析了一种快速ICA实现算法一FastICA。物质的非线性荧光谱信号可以看成是由多个相互独立的源信号组合成的混合信号,而这些独立的源信号可以看成是光谱的特征信号。为了更好的了解光谱信号的特征,本文利用独立分量分析的思想和方法,提出了利用FastICA算法提取光谱信号的特征的方案,并进行了详细的仿真实验。 此外,我们还进行了进一步的研究,探索了其他可能的ICA应用领域,如音乐信号处理、图像处理以及金融数据分析等。通过在这些领域中的实验和应用,我们发现ICA在提取信号特征、降噪和信号分离等方面具有广泛的潜力和应用前景。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值