本文主要是用于有上门的客户找到我时，方便说明我的计费模式和思路。

TL；DR

我的计费模式为按时间计费，我会使用 Clockify 为你的项目进行时间记录，并由 Clockify 来完成费用的计算。我目前的每小时的单价是 $300/h（按时价折合人民币）。

完成一个项目或项目累计时间超过 10 个小时后，我会想你发送计费清单（计费清单参考下方文件），你需要按照计费清单支付我的费用（如果计费清单中的某一项你任务有问题，我们可以重新讨论 & 评估）

为什么不做计件计费？

计件计费的好处是项目从开始的时候，预算就是明确的，你的支出是明确的。但在我看来，计件计费的问题是将你我放在了一个对立面。

可以简单思考，如果某个项目按计时制是 10 小时，那么按计件计费的情况下会出现三种情况：

1. 我预估时报了超出 10 小时的计件报价：这个时候你会觉得我是不是在咋唬你，这个事情为什么会这么贵。而对于我来说，时间超出，剩下的都是赚的。你不满意，我满意。
2. 我预估时报了刚好 10 小时的计价报价：这个时候是最完美的情况，你不会觉得我白嫖，对我来说，没有多花时间， 也可以接受。你满意，我满意。
3. 我预估时报了不足 10 小时的计价报价：这个时候对于你来说是划算的，但对于我来说，我会觉得自己亏了。这个时候可能会在一些可有可无的细节上选择干脆不搞。或随便搞搞就行。你觉得你赚了？但你真的赚了么？你满意，我不满意。

可以看到，按计价计费的时候，有三分之一的概率让你我双方都满意。三分之二的概率让你我中有一方不满意。

此外，这里还有两个隐含的前提 ：

1. 项目的需求不做改动。但不做改动并不是一件好事，如果我们在项目开发过程中发现前期的需求设计有问题，需要加功能，做就要另外加钱，不做，产品无法满足要求。
2. 项目的时间预估十分准确：项目的时间预估是需要配合着一个非常完善的 PRD 来进行的。但你应该不是那种十分完善的 PRD （完善是指考虑到所有可能的情况，一个 PRD 可能十几二十页 PDF 的那种）。在 PRD 不完善的情况下，预估时间是无法做到准确的。只能按照超出项目时间来评估（延展阅读：侯世达定律）。

计时计费对你我的好处

前面说了计件计费的劣势，那我们来聊聊计时计费对你我的好处：

1. 计费透明：我在做每一项工作的时候，都会记录在 Clockify 当中，让你明确每一个步骤我在哪一天花费了多少时间。你可以根据我所花费的时间来支付费用，而不是支付一个固定的价格。对于你、我来说，都不是一件坏事。
2. 为项目好的方向进发：因为我们不再是对立面，那么我们可以向着项目最优解的方向进发。如果某个细节可以让你的产品得到更好的体验，我就会选择帮你加上这个细节。让你的项目体验做到最好。

当然，计时计费也有坏处：

1. 预算不明确：计时计费只是给出一个大致的预算，实际计费是按照所消耗的时间来计费的，因此，对于强预算需求的项目来说，这可能是个问题。

总结

如果你希望计件计费，那可以不用受累联系我，对于计件计费的项目，我一概是拒绝的。而如果是计时计费，且可以接受我的报价，那么欢迎你通过微信、邮箱等方式联系我。

我自己其实不太了解 ASoul，也没有特别的关注，毕竟作为一个社牛，不太会通过虚拟人来获取情绪价值。但我确实之前听说过 VTuber，在我的下意识以为，VTuber 的声音应该是由 AI 来完成生成，工程师建模，PM/运营来负责脚本的产出（类似微软小冰）。

不过，现实可能是 ASoul 这样的项目其实是由中之人来完成声音的录制，更接近于传统的声优的角色。对于资本来说，中之人就是一个耗材，但对于喜爱 VTuber 的人来说，中之人是非常重要的。

当一个 VTuber 之后是一个独立的人的时候，其实能贡献的当然不只是声音的问题，还可以贡献出更多的情绪价值。而这些情绪价值，正是一个 VTuber 的独特的价值。

这些东西是完全无法通过 AI 生成的么？可能是可以生成的，但暂时可能无法生成。随着技术的进步，逐步拆解出人的各种情绪和诉求，再由 AI 来完成生成，实现真正意义上的 VTuber

钉钉账号是个人所有的么？

答案是「否」，钉钉账号表面上是你自己的账号，但在企业的逻辑当中，这是「企业授权给你使用的」，本质上，这些都是企业的资产，企业是有权处置这些资源的。你所说的、所看的、所做的，都是企业提供的资产，企业可以根据自己的需求来调整这些资源的所在位置。

为什么钉钉和我们使用的微信、QQ 不同？

这是钉钉的不同的一点，在钉钉当中，任何一个账号，都是有对应的租户的（除了你的个人租户）。租户才是资源的所有者，我们只不过是使用者。 而我们使用的微信、QQ 其实也不是我们的，在微信的用户协议当中写明了，我们所拥有的不过是微信账号的使用权。只不过，因为腾讯离我们很远，我们可以认为不会对我们执行任何操作（当然，实际上如果你发一些不和谐的内容，也会被设置为内容自见），但在钉钉中，租户的管理员可能就是我们身边的同事，在这种情况会更有「隐私」和企业所有的对比。

7.1.2 微信帐号的所有权归腾讯公司所有，用户完成申请注册手续后，仅获得微信帐号的使用权，且该使用权仅属于初始申请注册人。同时，初始申请注册人不得赠与、借用、租用、转让或售卖微信帐号或者以其他方式许可非初始申请注册人使用微信帐号。非初始申请注册人不得通过受赠、继承、承租、受让或者其他任何方式使用微信帐号。

综上所述，你的账号，并不属于你。

一直以来，创业圈都有 To B 和 To C 的两个赛道。而对于我目前所从事的事情来说，我愿意将之称之为 To Dev 业务（简称 To D）。

为什么是 To D？

在过去，很多时候企业的产品要么是针对 C 端用户，直接卖用户给广告商，我们称之为 To C；也有很多企业是通过为其他企业提供资源，来获取收益，我们称之为 To B 。

To Dev 的业务本质上都是 To B 的生意，因为 To Dev 本质上是在要求开发者背后的企业来进行相应的费用支付。

但 To B 往往会让人误以为这个场景很大，所以我常说 To Dev（或者是 To 小B）。

To B 走的是上层建设的路线，产品往往是由上层确认，下发至业务团队，业务团队直接使用。举个例子来说，小米使用的是阿里云，原因是从集团层面看到阿里云很好用，所以我们批量采购，大家直接使用。

To Dev（To 小B）则是一个相反的路线，走的是农村包围城市。通过提供优质的产品，来促使开发者使用产品、离不开产品、为产品付费。

为什么会是这个路线？

过去，我们看到大量的大企业在使用 To B 产品。但随着 To B 时长的不断发展，越来越多的企业已经完成了 To B 的业务的采购，在这个时候，再想通过 To B 的方式来完成资源的购买，是十分困难的，因为已经被占位了。

在这种情况下，我们就要开始去观察那些还在成长的市场，比如初创团队、新产品团队。对于这些团队来说，他们一方面依然可以采用之前采购的资源。但同时，之前采购的资源可能有着这样或者那样的问题，让团队成员困扰。而新的解决方案可以更加简单的解决问题之时，这样的团队便有动力去试用这样的产品。

而这样的团队注定是如繁星一遍，遍布各个地区，传统 To B 场景下的销售就不适用了， ROI 太高。则需要在产品体验方面做到极致，让开发者可以更愿意选择自己的产品。

在做软件产品时，我们会无限的追求极致，希望将产品的体验、用法等各个方面全部做到最好，因为软件的交付成本低于硬件的交付成本，我们只需要一个命令，就可以将旧版的软件升级到新版。因此，我们可以通过不断的软件迭代，来将一个不完美的软件，迭代到完美的状态下。 而硬件则不同，硬件涉及到两个问题：

1. 硬件存在供应链和备货的问题：这就会要求你必须提前采购物料，并进行研发。物料是实体的，必然会存在出问题的可能，因而会让我们的硬件设备出现各种各样奇奇怪怪的问题，天然就不太可能完美。
2. 硬件存在升级成本的问题：硬件和软件的一个很不同的是，硬件往往是很难做到很好的升级的，想要升级，就不得不重新购买，而购买是需要花费金钱的。不是每个人都能购买新的设备的。而从厂商的角度来看，假设他做了一款完美的产品，他就无法再继续售卖同类型的产品，自然也没有动力去推出一款「完美」的产品

上述两个原因，导致我们永远不可能买到完美的硬件产品。

我以产品经理的角色参加了一个 Hackthon，整体下来体验一般。

我并不是一个一般意义上的产品经理，可以帮助你把产品细节做到极致（毕竟研发出身，满脑子都是代码）。我更擅长的是产品的流程的确定和推进。这些优势在 Hackathon 其实没有用，原因是 Hackathon 对于这个并不在意。

Hackathon 更在意的是产品的创意以及创意最终的实现。前者需要的是创意的提出者，由他来进行进一步的头脑风暴，推广。后者需要项目经理和全体团队的配合，快速推进。

唯独不需要一个单独的产品经理，来进行具体的产品需求策划。