关于做产品的几点思考

一、战略失误

我做的第一款产品在今天看来,绝对是属于战略失误的典型。从整个市场来看,这款产品的领域已经存在太多的典型和优秀的产品,和绝大多数领域和绝大多数产品经理一样,在产品层面上都不会有创新,做的事情只是“复制”一份产品方案,就是一种“重造轮子”的复制一份市面上的解决方案服务商的产品或竞品的功能。时至今日细细思考,这款产品的特色和功能价值不突出,功能不稳定,交互体验差。耗时耗力、费尽心思不断地做大量相关浏览、梳理、归纳、总结综合而成的产品,设计奇葩,交互奇怪。通过观察,这类型的领域很多,比如在线教育、电商、知识付费等领域。对于这类型领域的产品,实际上是不值得这样花费的,这些领域在市面上有很多产品解决方案的服务商,几千或者一两万就能够购买到一套成熟的产品方案,但是如果自己研发,时间成本+人力成本,一年至少百万以上。最为重要的是时间成本,很有可能让公司错失了关键的或最佳的运营窗口期。

在同类型产品领域市场已经存在太多的典型产品的情况下,我们应该通过“运营”的角度来设计产品功能。不同领域不同产品,真正的创新是在“运营”层面上的,根据不同的“运营场景”来设计产品功能,考虑产品需求的市场背景和运营场景。而这款产品在设计之初,就过多的对标了竞品的功能和设计,导致花费大量研发时间和人力在产品的功能上,反而应该是产品本身的特色和附加值的基本盘和核心竞争力,均没有时间进行集成和开发。试错成本很高,我要感谢公司给我的宽容及成长。

二、战术失误

此外,在第一款产品上,战术同样失误。由于产品的功能和现有市场领域产品的功能相似,在研发力量不足的情况下,耗费太长周期“重造轮子”,没有充分利用开源的力量。产品实现的功能,在GitHub这样的技术社区也能找出N多个来,类似功能控件等模块化的方案,在许可允许的条件下我们都可以引用于产品中,这样可以加速我们的产品功能实现。将钱和研发力量花在运营层面上,才是最高回报率的投入。

实质上产品本身仅仅只是一个内容的承载平台,而我们却花费了一年多的时间在产品本身的功能实现上,内容运营本身还未来得及投入研发力量着手解决,业务需求已经开始推着我们不得不投入力量进行内容运营的开发工作。这就导致我们的工作越做越多,一旦有突发事件和应急事宜,项目成员都会手忙脚乱。完全打乱之前的节奏,等应急事宜忙完回来,项目又得重新开始进行梳理。

三、管理失误

从项目管理角度上来看,也是存在着很明显的失误。包括每天代码的提交,最开始项目的构建完全是程序员本地进行开发,项目成员之间通过相互拷贝代码的方式进行代码合并和代码版本管理。导致每次版本的合并及更新都会出现问题,有时甚至分不清楚主次版本,甚至还会导致部分代码丢失。这完全是属于代码管理上的严重失误,在影响效率的同时,也造成项目开发的混乱。后续采用git等工具进行代码版本管理,情况稍微得到改善,由于我本人并没有进入开发,仅管控进度,项目成员之间的代码质量属于放养式管理,项目开发人员没有定期进行Code Review,代码质量出现不可控因素,也导致后续一系列的功能优化和修改均费时费力。

我在项目中给予了他们非常充分的信任,信任他们可以把一切事情都做好。但我没有在正确的时候给予他们正确的指引,项目中出现的困难点,我也没有帮助他们解决,甚至于没有给出思路。所有的一切,都靠他们自己完成。我在这个项目里做的,就是对接需求,催进度。再无第三件事。

基于以上原因,我掉以轻心,没有在项目初期进行项目的设计和规划,未指定任何开发规范。仅仅告诉开发的同事要多复用,也未检查他们是否真的复用了。

项目开发中的需求变更,需求反馈意见,我都仅仅是告知他们一声,未做详细的修改规划,所有事情都靠嘴说,所有变动都放在了我和他们的脑子里。

对项目上心程度不够,未对需求变更做控制和管理。所有变更都压给了开发的同事。

整个项目以及其不规范的方式在运行,我也未在其中起到控制作用,项目开发一团乱麻。

项目开发过程中,也未让开发间互相进行代码review,也没有进行代码评审会。其实代码中出现了很多问题,最后检查代码的时候,发现各种命名不规范、代码复用不到位、简单逻辑复杂写等等。而这些问题,很大一部分都是早期未做规定,未指定人负责项目、未进行早期code review造成的。开发各自为战,难免造成代码问题。代码质量的问题,淋漓尽致的体现的在项目中,项目中的诸多bug,都是因为代码不规范引起的。甚至于开发人员自己对自己写过的东西,都有些拎不清了。

综上,导致这款产品的特色和功能价值不突出,功能不稳定,交互体验差。现在还在投入研发力量进行修补和优化。

猜你喜欢

转载自blog.51cto.com/tasnrh/2308242