这个想法好，我觉得这些做项目管理软件的可以思考下这个东西。 反馈转需求池

我个人建议，目前这个项目的完成度，最好还是不要发布，把他废了也比做一个失败的商业产品好。如果我是开发者的话，我会考虑把这个项目开源作为项目经历，但不会实际运营这个平台。

@zhruith 根据我的调研，研发、设计基本上都是个人兼职服务或者工作室，而且这个市场大批量的都是想去接活儿但没活儿可接的状态。

这种情况下 技能提供者的 从业经历 和 项目经历 应该是获取项目方信任的强体现项，而不是一个人告诉你我能提供 XXX 的服务，反正我是不信他的。

如果让我觉得会比较信任，我觉得应该是就像 BOSS 直聘一样，我自己找这些人的简历看，看完我觉得合适就发邀请，这样我对这个项目的掌控感会很强。

不知道您有没有了解一个跟这个项目很类似的一个项目叫云队友( https://www.duiyou360.com/)，跟 PMCAFF 好像是同一人做的

我觉得你作为用户体验一下这个平台，现在这个项目做到比较完整的时候，跟这个平台现在的状态是比较相似的，我体验下来觉得完全没有信任感，如果我要做一个东西，这个平台我不会去。


下面是我在半个月以前关注到这个东西时做的一个思考，才刚开始做，肯定还不完善，我的想法是 符合远程兼职的“BOSS 直聘”，双向交流，技能方可以自己去找项目，项目方可以自己去找人，通过线下交易，线上签定合同的方式进行交易。


您说的脱离平台私下交易这个想法我也是认可的，一是出于运营考虑，除非做聊天 +人工客服等东西，不然无法保证交易纠纷能够很好的调解，二是出于税务考虑，钱从公司账上发到个人账上需要大概 20%的税，相当于即使你不赚钱，技能提供方也会认为你吃了 20%的钱。





跟我之前的想法有点类似 但不同的是 我认为人是 C2C 接单平台的主体，你认为项目是 C2C 接单平台的主体。

至少就我个人而言，我觉得项目方式充满了不确定性，我宁可直接找人来做

确实阿里云页面经常打不开 卡的一笔 什么原因清楚吗

@lijianqiang12 这个太过了 软件都是 mix 的这个是认的。 但其实作为产品狗来说 吸收完这个产品的设计思想 然后自己做 做出来可能功能需求满足的一致，但页面交互是不可能是一样的，这种就是对着抄了。

@sillydaddy 这大概不能叫简洁，应该叫简陋

有个建议就是，如果目前没有远程工作 /自己当老板的话，现在不要考虑去农村建别墅，房子不住人没有人味儿，一两个月不住人就得每次回来大扫除一遍，否则哪里一碰就是灰。

简单点 NUC 或者 ITX 吧 笔记本就当笔记本 别给他拓展那么多功能了

产品是约束条件下的效用组合，你细品

约束条件可能存在： 老板必须要做、公司要求短时间内出成果、公司没有产品价值观、PM 自己能力太差、团队内想靠这个升职 /积累经验、 团队专业 /审美水平差、目标用户审美水平差等任意多种条件的组合

这也就是一个需求让同样两个公司，甚至同一个公司的两个团队、同一个团队的两个 PM 做，他们的原型产出都不会一致。

举个例子： 拼多多、各类特价版、各类极速版 很糟糕，因为产品团队根本不 Care 用户体验，而且产品价值观低下，十八线城市用户就不配用好产品了吗？ 贪小便宜的哪都有，不去引导用户而是利用用户并且固化“18 线城市用户都是贪小便宜”这种思想，是极不道德的，没有一个用户用户不应该被这样羞辱，简单两个字 恶心

不要神话犬校 ，要我说产品就不应该混圈子 越混圈子越没独立思考能力

RBAC 只支持 [功能] 控制不支持 [资源] 控制，如果要既要支持功能控制又要支持资源控制的话，可以了解一下 ACL(Access Control List)，免得思考到最后再造了一遍 ACL

我理解 权限系统只能用于建立用户、角色和权限三者的关系，跟组织构架没有关系

权限系统(建立关系) +组织构架（扩展查询条件）二者加起来能够完成业务查询的要求

但两个不能混为一谈

@enki0423 能通过简单的一个循环日历事件激发每天锻炼的兴趣的人，也用不到跟别人一起玩儿这个啊。这个应用的使用场景一定是很娱乐的，是伴随不断的去交流互动的，im 交流互动方式比邮件更灵活，所以得做成小程序

来个核心问题：文章评论互动怎么实现？

用户发布博文后 是先上传到 ipelago 上储存起来 对吧？

还是说 用户发布博文后，实际上是开了一个 http 服务器，生成了一个 ipelago 的订阅链接。

订阅者是从 博主的机器上同步的博文 还是从 ipelago 上同步的？

Demo 有吗？ 比如你自己建的一个岛