何同学犯的错,是每个产品经理都会碰见的“抉择”

     分类 [产品经理]
2024/11/22 9:39:36 浏览量  1080 喜欢  54
导读:,一个好的产品绝对不是来源第一个版本,可能是在第N个版本之后才逐步被用户知道,因此想要一蹴而就做一款产品,是不可能的

何同学犯的错,是每个产品经理都会碰见的“抉择”

 

最近,何同学的一个视频《我用36万行备忘录做了个动画》,因为想为四年前致敬,将1万行跑马灯做成了36万行,并且声称:“我们专门做了一个软件”。

而视频播出后,画面追溯视频的代码画面,有网友就查询到了源代码的内容来源于github开源项目,发现何同学将其开源源代码的作者名称出处进行抹去,在视频里放出。

何同学犯的错,是每个产品经理都会碰见的“抉择”

加上这一期视频是内容包含了广告厂家,因此这个也被称之为:“恰饭真难吃”。

作为产品经理,源代码搬用其实这个已经是:“软件行业的普遍现象了”

你做产品经理期间会调研开源代码吗?

 

几乎每个产品经理都会选择:“开原方案”

回顾我们做产品经理的时候,一个ideal或者来自领导的业务需求。

因为刚开始并不知道这个产品会带来多少的用户,考虑到研发进度与成本,以及第一时间实现需求,我们都会选择开源项目作为其基础支撑。

这也就传出了行业里面说的那句话:“初级的程序员都在control+C 和control+V”。

举个例子,我曾经在做iPhone雷达激光APP,也会选择在早期用开源的3D建模算法来完成MVP的产品谁家方案。

所以选择开源方案,大大提升研发效率。

何同学犯的错,是每个产品经理都会碰见的“抉择”

lidar 3d scanner

还有基于医学的3D建模相关算法,也有大量的开源工具,如下面的3d slicer也是用这个工具,快速将Dicom文件建模。

何同学犯的错,是每个产品经理都会碰见的“抉择”

3d slicer 开源项目

产品从MVP成长后,就会推倒重构

由于早期产品没有盈利,并且还不知道产品的商业化可行性,因此早期开源项目都会直接投入使用,最多稍微调整参数即可。

产品从MVP成长后,有了用户数甚至是付费用户,就会进入到资本扩张阶段,等到新资本进来了之后,研发团队就可以开始推进“代码重构了”,这里的重构不是指的是功能全部不要,而是底层逻辑代码结构重写。

何同学犯的错,是每个产品经理都会碰见的“抉择”

图片来自网络

即使没有资本加入,本身产品在线上持续的用户量增加,考虑到数据加载速度、代码维护、结构优化,很多开发就会选择在一定量进行重写,并且将开源代码也重写了。

所以这个时候就会把开源的内容推倒重做,变成了“自研化”。

因此这也是大多数产品迭代的过程,从开源品拼凑的MVP再到全部自研

这也是大多数产品迭代过程中,背后的研发规划

何同学应该坚持做一个产品,而不是“一蹴而就”

像何同学这样的视频工作室,很难做一个坚持做产品的初心。因为视频的主题每一期不同,所需要的产品也不同。

自然就不可能有产品迭代的需求,一切低成本的研发、与高效的研发速度,选择开源自然是最小化成本,甚至才能解决问题。

可是,一个好的产品绝对不是来源第一个版本,可能是在第N个版本之后才逐步被用户知道,因此想要一蹴而就做一款产品,是不可能的。

无论多厉害的研发团队或工程师,在碰到一个需求都会面临新技术、算法的调研,都需要调研新技术,不是谁都是可以从0到1,而且也没必要浪费那个时间与精力。

何同学,忘了开源项目也有收费的分类!

相较于其他同学,何同学账户下的用户画像包含了相当多的程序员、产品经理,这些在一线工作的同学,看到了代码截图都会比较敏感甚至是能看懂。

并且现在已经有代码的原作者来回应了:“相信我不是第一个”

而开源项目不等于就是都可以免费用,开源项目也分为3个类型,分别是

  • 商业式开源(收版权费),本质是通过开源这种方式,让大家使用,形成生态后,通过技术服务的方式获得收益。

  • 纯粹的技术分享型,比如GITHUB上的项目,或者以GPL协议开放的项目。他们是从技术分享的角度,把自己的软件和技术分享给大家使用。

  • 结合了二者特点的开源项目授权开源,只有授权后才能够兼容老版本比如LINUX,

以上3个开源类型,只有收费的开源往往是可以持续的,因为这样就可能有收入给到团队,团队才有动力持续的迭代项目与维护。

很多完全免费公开的开源项目要是找不到维护人员,就会年久失修,你需要花费大量的时间解读源代码,也没有被使用的价值。

所以一般产品经理都会选择有人维护的。

今天的分享就在这里

 

标签

微信扫一扫,分享到朋友圈

微信公众号

相关推荐