关于暂停donate3项目开发的讨论

donate3当前项目状态
proposal投票通过:2022.9.23
截至2022.11.25完成度:MVP版本70%左右。
正式进入开发时间:2022.9.26
人力资源投入:先后投入4个开发,1个产品&设计,1个PM&开发。

提议暂停开发原因:

  1. 现有开发资源无法支撑项目mvp版本完成,并且还需要大量时间优化细节,已超出原有期望。
  2. MVP版本与现有产品功能设计存在大的差异。
  3. 当前项目投入资源与产生效益不匹配。

项目后续:

  1. PM发起暂停提案。
  2. 原PM组织项目复盘。(时间待定)
  3. 社区讨论和提案,重新开启项目。

可供参考的项目调整方案:

  1. 配合lxdao战略目标,将捐赠解决方案融合到profile、支付解决方案等项目中。
  2. 重新调整donate3 roadmap,从0.1版本开始做起,根据投入资源和产生的收益随时调整目标,而不是一开始1.0版本,投入较多资源。

这次项目暂停,也暴露了当前lxdao不少问题,不一定是坏事,希望大家可以多发言讨论,以供后续复盘。

原proposal
Proposal:New Project Donate3 - Proposals - LXDAO

我将临时接任 Donate3 的 PM,以下是我对于新技术方案和产品实现路径简介:

  1. 研究 gitcoin 等捐赠场景以及现实世界捐赠证书数据格式。设计类似 erc721 这样的规范,提交 eip issue。三天
  2. 实现 eth 的合约,支持 donate 方法,支持传入对方地址(以及协议规定的字段值?还是前端渲染时集成 ens 服务?)返回 sbt 展示相关信息。 三天-五天上测试网。
  3. 编写文章和资料介绍这个产品,开始设计前端产品。URL 拼接收款方地址和链即可生成页面,包括链接钱包付款和捐赠过这个地址的 sbt 列表(同时尝试读取地址对应 ens profile 渲染的更好看。)对外有个图片服务,同样 URL 拼接一个地址,可以生成一个 svg + 二维码。mvp 完成。大概十天。
  4. 开始宣传接入使用 + 叙事包装,开始准备多链。
  5. dao 里合约开发者每人一个链把这个合约实现部署,然后前端服务支持对应链数据读取。这样可以申请对应基金会的赞助,变成捐赠基建,全部符合捐赠 eip 协议。
  6. p2 支持多链聚合,认领某些地址合并成一个合集(一个项目),mint 自定义 id 来创建短链,任何人能在这个聚合页面上选择自己愿意用的钱包捐款。
  7. p2 捐赠数据开放 api 和数据分析服务。
  8. p3 跨链桥,支持法币捐赠,承接大型捐赠活动,变成正式 erc。
  9. 可以对捐赠者返回 token,来 donate to earn,要求被捐助者要给予一些回报到 donate3 dao

我们最早的产品设计相当于直接做到 6、7 的阶段,过于贪心,导致开发成本和风险较高,也缺乏有效的 roadmap 设计和项目管理,这些问题在复盘的时候讨论吧,需要研究一些机制来优化和解决。

1 Like

我是负责这次 Donate3 的前端,对于这次 MVP 版本的 Delay 负有主要责任

实际前端投入时间是 2022.10.23 开始提交代码,先后有 BPC 和 Axtlive 两位前端同学参与共同开发,BPC 和 Axtlive 都是中途加入的,对于业务背景和 Web3 的一些信息也不是特别熟悉,所以只能参与一些模块开发,整体的逻辑串联主要是我这边负责,我这边在11月只能零星的投入一些碎片时间进行开发,直接导致了项目受限于前端进度

一些问题:

  • 主力开发时间投入不足,后期补人解决不了核心问题
  • 部分成员参与感较弱
  • 整体目标比较模糊,最终 MVP 的形态不太确定
  • 功能细节不确定,比如 Donate Avatar Wall 以及 Gas Fee 和 Token Exchange 这些

建议:

  • Project proposals 通过后,组建团队最好一次性成型,关键人员要有 Backup
  • MVP 目标明确,且整体开发周期控制在2-4周的时间维度
  • 项目内部进度可以同步的更频繁一些
  • PM 要把控时间点和项目卡点,协助团队成员解决问题
1 Like

所有参与项目的人员都会得到积分,具体分配规则会记录在暂停项目的proposal里面。

我看到的存在的问题:

  1. PM 和 PD 对产品的设计缺乏讨论,前期等待 PD 设计时间过长,之后直接出来了定稿,拿到了完全精细定稿的设计稿就直接开始开发。缺少渐进式迭代的设计,MVP 应该是聚焦最核心功能,是非常简陋但是可以快速在 1-2 周一个人就可以完成的。细节增加了大量工作量,不得已还需要砍掉。
  2. 技术选型使用了风险较大的技术方案(Ceramic + 多链等),在 MVP 没有出来之前,过度追求去中心化设计,带来了较大技术风险,体验也不佳。技术调研、测试和对接产生了大量工作量。
  3. PM 没有做 roadmap 的设计和管理,出现阻塞问题之后采取了催促 + 顺延下周的做法直到社区和项目组成员热情消失需要暂停项目。
  4. 核心前端参与人员没有投入承诺的精力来完成承诺的目标,加重了第三个问题。如果没有足够时间精力可以不用承诺,及时安排其他人员。

建议:

  1. 产品设计时,需要考虑渐进式升级,MVP 版本需要专注核心,小而精,简陋。可以做到一个人 1-2 周能完成开发的进展。除核心功能之外,不应当过度追求新技术,应当以快为重。每个项目成立之后,在 MVP review 阶段,都需要询问这个功能能否在 1-2 周内完成。
  2. PM 需要有培训。建议设置一个新的 role:Intern Project Manager,除以前带出过项目的 PM 之外,都应该是 Intern 实习 PM,然后作为辅助参与到带出过项目的 PM 的工作中。等熟悉了流程和处理方法之后,才可以从 Intern 开始独立对接或者管理项目。
  3. 积极参与对外交流和黑客松、外部 grants 申请。完成 MVP 就应该进行一些产品、概念的宣发,招募感兴趣的潜在用户和投资人,而非完全上线后才推出。这是每个 PM 都需要具备的意识和能力。
  4. 项目终止或者换方向、团队的流程需要补全。

我的一些建议

  1. 一个项目,初期应由idea提出者负责。idea提出者应始终留在项目组里,不要让项目走向偏离初衷。

  2. 单人或者小团队快速开发出原型,可以很粗陋,但要快、能用,这样可以不断增加信心。

  3. 目前项目与builders匹配较弱,建议尽快虑梳理一下LXDAO现有项目和LXDAO builders技能,由导师们将 builders 匹配到现有各项目中,增加builders 归属感,每周或者月底由项目负责人提出积分分配,有贡献了就给LX分。

  4. Onboarding这一块,除了coder外,可以多引进类似体验官、测试人员、运维人员和推广人员等,我感觉各项目明显缺这些人,如果产品开发后就摆在那撂荒了,太可惜了。Onboarding之后可以先将该builder放到某一两个项目中,产品经理负责安排任务。

2 Likes

技术能做什么和不能做什么前期应该讨论充分,产品应该配合当前团队具备的技术能力做产品上的策划和包装。控制在2-4周内完成,慢慢迭代。

不要过度追求所谓去中心化,就我目前了解到的,但凡稍微涉及到一点点去中心化的东西,从架构和技术实现相比中心化其成本都是陡升的。

区分实现和愿景。实现可以只实现10分,但是我还是认为叙事和实际能够解决的问题还是得80分以上的项目才有做的意义,这需要前期做到充分讨论和共识,否则立项的缺乏挑战和意义。

岗位建议分成:产品负责人、技术负责人,运营负责人。
1、产品负责人 负责产品需求、产品设计、统筹产品进度,负责与技术负责人对接
2、技术负责人 负责把控技术细节和架构、落实产品、技术实现,负责与研发和产品对接
3、运营负责人 负责 文宣 以及 同步外部团队、黑客松等建立链接,侧面保证项目落地能够受到外部的正向反馈激励团队

1 Like

我的一些想法,在做之前,把核心功能拆出来,将产品的核心功能尽量快速的实现出来,先成为一个小产品
把产品做的小而快,然后拿去参加黑客松或者各类 Demo 演示会,吸收外部的反馈,这样做的好处是

  1. 吸收外部经验,快速迭代,避免闭门造车
  2. 同类产品相互比较,取长补短
  3. 扩展行业资源,容易拿到一些潜在的投资机会和资源
1 Like

本人参与不多,除了自身比较忙以的原因外,感觉整个开发过程中沟通成本过高,有点打击参与积极性。

  1. MVP版本太大, 细节过多。
  2. Ticket 拆分和描述都不够详细。
  3. 兼职和远程放大了以上两点对沟通成本的影响。
1 Like

作为一个LXDAO爱好者与项目观察者(站着说话不腰疼的人),建议大家先不要用传统公司的惯性来思考与总结,先尝试跳出来,比如从下面三个角度来结合自己从合作中感受到的实际体会想一想,聊一聊:

  1. ideaer 与 owner是什么关系?
  2. owner与LXDAO是什么关系?
  3. builder与team member是什么关系?
1 Like
你是否支持暂停donate3项目开发?
  • 支持
  • 反对
  • 不清楚项目状况

0 voters

项目复盘会议时间:2022.12.2 9:00 pm,discrod。