产品研发是怎样的体验？
做项目难，做产品更难。产品最终会落地于一个个的项目，但是与单纯的项目相比却有很多额外工作。而即使同样的工作，往往也有一些显著的不同。
作为 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 化、外包，还是组织结构调整？我们要未雨绸缪。技术的创新，归根结底只是商业模式创新中的一环，从根本上看，还是要靠商业模式的创新。
展望
产品之路，荆棘丛生。一个好的产品可以支撑起一个公司，很美好，但我们尚且没有成功案例。
在我们公司做产品，相当不容易，因为我们确实还没有做产品的成功经验。但我们都相信“没有伤痕累累，哪来皮糙肉厚，英雄自古多磨难”，所以，一起努力吧！我们终将走通这条产品之路！什么是产品基因？是你、是我、是他/她，是每一个有产品梦的人。
共勉。