汪·课
github-circle-white-transparent
作者:
汪志成
发表:
2020年5月18日
收录:
技术原创

产品研发是怎样的体验?

做项目难,做产品更难。产品最终会落地于一个个的项目,但是与单纯的项目相比却有很多额外工作。而即使同样的工作,往往也有一些显著的不同。

作为 BeeArt 的早期开发者之一,我将从一个研发人员的角度,分享一下我对产品开发的理解,希望能给有志于孵化一个产品的小伙伴们一些启发。

立项前

俗话说,好的开端是成功的一半儿。作为产品的开发人员,不能被动的等待别人进行工作安排,而应该尽可能早点介入。而我作为有产品经理背景的开发人员,对此更是深有体会。

那么,在立项前作为开发人员应该做什么呢?首先是和 PO 一起做 SWOT (强项、弱项、竞品、威胁)分析。对于像 BeeArt 这样和技术领域紧密相关的产品,更是如此。

如果你在我们公司待得比较久,可能知道当初金数据就是我们公司孵化出来的。金数据固然是个很好的产品,但最终也还是忍痛卖掉了,因为它无法和我们的主航道产生协同效应,通俗点说就是 1+1 无法大于 2。而要做好 BeeArt 的定位,就必须结合我们公司的业务特点来进行 SWOT 分析。

强项 - BeeArt 是孵化自咨询 BU 的产品。我们的管理咨询师可以深刻理解客户在业务规划等方面的战略痛点,而我们的技术咨询师则理解客户在技术落地等方面的战术痛点。两相结合,可以形成相对竞争对手的优势。同时,我们擅长开发可维护的软件,这在产品长跑中,也同样是无可替代的优势。

弱项 - 在客户心目中,我们 TWer 都是专门攻坚克难的特种兵,精英化的人才结构就会导致我们的开发成本很高。同时,大部分人喜欢新鲜的挑战,却没有耐心沉下心来打磨产品,因为细节打磨往往是缺乏技术挑战的。但产品制胜的关键恰恰在于细节的打磨。因此,我们必须有意识的去建立相应的文化,来弥补这些缺点。

竞品 - 我们评估了 Miro 等一系列竞品或准竞品软件,从商业到技术都进行了评估。仅以技术角度为例,这些软件最初开发时的技术条件和我们现在的技术条件,已经无法同日而语:有些当初成本很高的技术,现在可能已经变得很廉价;有些当初需要花费很大精力去做的事情,可能已经有现成的开源软件;有些在别人看来很难的事情,可能我们公司的兄弟团队可以帮我们轻松解决。所以,我们既要学习他们的技术方案,也要通过创新来提高质量、降低成本。

威胁 - 《礼记》上说“凡事预则立,不预则废”。我们肯定不希望个人的努力输给历史的进程,因此,我们要尽可能预测短中长期的威胁,走对手的路,让对手无路可走。从技术角度看,BeeArt 的长期威胁在于头部企业的软件会形成工具链。如果现在的某些头部公司,将其产品连接起来,形成一个从需求到运营的全周期工具体系,并且完美衔接,那么我们将无路可走。所以,我们要提前规划,最终让自己的软件尽早形成闭环。形成闭环之后,凭借我们的软件质量优势和全面的软件能力(咨询、交付、DevOps、AI 等),我们将进可攻退可守,即使面对微软这样的头部企业,也至少有一战之力。

POC

出师未捷身先死,长使英雄泪满襟。凄美也是美,但我可不想当主角。要想避免这种结局,就要用尽可能短的时间和尽可能低的成本,给出一个可行性证明。我们 ThoughtWorks 是务实的公司,显然,靠一吨文档是起不到作用的。Talk is cheap, show me the code. 程序员的世界就是这么简单。迅速、低成本的完成一个 POC 应用,就是作为技术人员在早期所能给产品的最有力支持。

要想做好 POC,就要时刻提醒自己是在做原型。要站在客户的视角看问题,把整个开发代入到一个演示场景当中。要先描绘一个完整的用户故事,然后把这个故事中的关键节点进行代码实现。一些不重要或者性价比太低的环节,可以跳过。这个阶段不怕有 BUG,只要不影响演示就可以接受,重心在于先把整个场景串起来,能够让客户把自己代入其中进行想象。至于单元测试,除非在某些局部场景下能帮你显著加速,否则忽略即可。

对于一些技术实力不是很强的团队,用纸原型也未尝不可,但是可运行的软件更容易吸引人,也可以顺便秀一下肌肉,更有利于获得长久的支持。

MVP

POC 固然能争取到一些天使投资,但更重要的还是自己的造血能力。因此,从这个阶段开始,就要商机导向了。

在只有 POC 的阶段谈商机,差不多相当于赌博。所以要多和销售们谈一谈,但这可不是 PO 自己的事,技术人员一定要参与。因为,MVP 中做什么不做什么,要基于目标价值、成单概率、技术风险、技术成本等进行综合评估。而我们公司的优势在于没有部门墙,这些角色可以畅所欲言,可以得出一个相对较好的结论。

但这个结论并不是给客户的 SOW,也不是给公司的承诺,只是团队的当前共识。外部环境千变万化,商机此起彼伏,没准哪一个就突然走到台前了。这就需要我们足够敏捷 —— 既要敏锐的察觉到环境的变化,捕捉商机,也要足够敏捷的实现它,不要改个需求就动一大片代码,或者改一下就出一大堆 BUG。这个时候,要格外注重敏捷实践,特别是 Code Review 和 Retro,这两个怎么强调都不为过。但是,如果一项实践很占时间却无法带来成比例的价值,那么也要果断舍弃,不要在上面浪费时间和精力。因为做产品不是做学术,纯粹为了感动自己是没有价值的,MVP 阶段没有任何客户愿意替你埋单。所以,一切决策都要首先考虑成单。

当然,MVP 与 POC 不同,不能遗留大量的技术债,特别是架构方面的技术债,否则后面的利息会非常高。这就需要开发人员对产品的后续发展有远见。经验固然有用,但更重要的是对产品长远发展路线的理解和规划。然而,如果做不到,也不要强求,这个阶段开发速度仍然是非常重要的,因为有些商机稍纵即逝。在完美和迅速之间,不存在一个标准的平衡点,只能靠不断的思考、讨论、试错才能找到。所以,做产品其实是很累的,特别是对于一些关键角色,即使拿出 996 的时间去思考可能都是不够的。对于 TL 来说,这个阶段最重要的技能叫做 Develop Others,要不断把不是“非你不可”的任务分配给别人,自己则留出更多的时间去思考,来避免架构级技术债。

Alpha

当 MVP 或正式产品开发到一定节点,就要开展内测了。

这个阶段至关重要。一方面,在能够自己造血之前,产品开发实际上消耗的是公司的资源,团队需要向全公司证明这些投资是值得的,而内测是最简单粗暴的方式。另一方面,闭门造车是出不来好产品的,我们需要开放的接受各种各样的输入,特别是 BeeArt 的目标受众之一就是我们的一线咨询师,来自他们的意见可以让我们及时调整产品方向,避免无用功,并尽早成长为杀手级应用。

Alpha 阶段不要求无 BUG,但是至少要能达到质量基线,没有不可容忍的 BUG。还要建立起顺畅的反馈机制,以谦虚的态度接受任何批评。甚至,因为是内测,有时候还需要刻意鼓励内测用户提意见,以免因为面子问题而错过重要反馈。

对于开发人员来说,Alpha 阶段最重要的事情是及时响应,包括改 BUG 以及参与评估需求变更。日常的工作则是进行后续开发。与项目团队不同,产品团队是没有什么间歇期的,即使 Alpha 发布了也不能放松。当然,每个团队成员是必须进行轮休的,产品开发是一场马拉松,团队要保持长久的战斗力才能迎来最终的胜利。

Beta

Beta 阶段会把产品直接给外部客户使用。BeeArt 目前正在向 Beta 阶段冲刺。

这个阶段对开发人员最大的挑战就是……被怼!Beta 阶段可能会收到大量的负面意见,甚至非常尖锐的负面意见。等将来用户规模大了,被怼更是家常便饭,这需要一颗强大的心脏。但是,仅仅“不生气”是远远不够的,重要的是要过滤掉各种强烈的语气,发现用户真正的诉求是什么、有多大的普遍价值。与内测用户不同,外部用户通常不够专业,他所描述的问题,未必真是他遇到的问题。他希望的解决方案,也可能完全没有道理。但是,能否在沙子中淘金,却决定着产品最终的成败。

在这方面,我们有一些天然的优势,那就是“直言不讳的文化”。只要在 ThoughtWorks 被怼惯了,外面那些都是毛毛雨。

但是,客服人员的缺乏,可能会成为我们的短板,而我们目前的人才结构可能不足以支撑大量的客服人员。要如何解决呢?AI 化、外包,还是组织结构调整?我们要未雨绸缪。技术的创新,归根结底只是商业模式创新中的一环,从根本上看,还是要靠商业模式的创新。

展望

产品之路,荆棘丛生。一个好的产品可以支撑起一个公司,很美好,但我们尚且没有成功案例。

在我们公司做产品,相当不容易,因为我们确实还没有做产品的成功经验。但我们都相信“没有伤痕累累,哪来皮糙肉厚,英雄自古多磨难”,所以,一起努力吧!我们终将走通这条产品之路!什么是产品基因?是你、是我、是他/她,是每一个有产品梦的人。

共勉。