弱小从来不是灭绝的理由，傲慢才是。
华为手机，会不会从这里就开始衰落了。
ods的商业模式，得想清楚。
第一种，强势的甲方，提各种要求，平台上活跃的设计单元构成乙方，平台负责牵线搭桥，设计完毕，验收完毕，结算完毕，知识产权按合约确定归甲方或乙方。
第二种，没有甲方，全是乙方，把一个点子孵化成产品，乙方可以成立一个公司来运营这个产品；或者把设计资料交给平台，平台运营产品产生利润，按合约比例回馈原始设计单元（乙方）。
第三种，平台的公益项目，没有甲方，没有乙方，秉承开源理念，所有设计资料全部公开，人人皆可参与，人人皆可贡献，人人皆可获取，项目开发中的所有细节全都一览无余，从项目经理到开发者全都是自愿的，但项目的质量要求并不意味着下降。这是一个互相交流，学习成长的地方，是理想的试验田。
我是做平台的，只有在我平台上真正获得回报的设计单元越来越多，平台才能成长，才能设计出更好的产品，继而可以改变目前的这种雇佣制度，每个设计单元不隶属于任何公司，是自由的，通过提供自己擅长的设计，来获取回报。能干着自己喜欢的活，还能赚钱，这就是我的思路。
所有设计单元，按照秩数来定等级，等级越高，越有资格接到项目。秩数必须来自Issue，Issue必须挂靠项目，且默认情况下，秩数每天都会掉。
所以，对于初学者，为了保持自己的秩数，必须要接Issue，Issue可以挂靠在公益项目上，每个Issue按照难易分等级，等级越高，秩数回报越高，所以，新手可以通过完成公益项目的简单Issue来积攒秩数和经验，等能力提升后，可以完成高级别的Issue。
新项目在点子发现阶段立项后，在资源聚合阶段需要建立团队，建立方式是通过竞标，根据项目的类别，设立竞标门槛，比如C类结构设计，秩数不低于1000，所有秩数在1000以上的结构设计单元都可以竞标，但最终谁能中标，需要结合其秩数和报价。项目经理通过查询潜在竞标者的秩数来源细节，可以大致了解其技术水平和做事情的特点。比如A设计单元，报价1500，秩数1980，其增长的秩数主要来自公益项目S，其中致命Issue解决3个，严重Issue解决10个，证明技术水平足够，看其解决的所有Issue中没有delay等标签，说明其不是个拖沓的人，把这样的人招进团队应该是可行的。
在平台上，项目经理是一个比较特殊的设计单元，可以说，所有的秩数都从他这里产生。有项目才有项目经理，他通过委派Issue或审批Issue的方式使得Issue挂靠到项目上，但无论是委派还是审批，都必须以他自己的秩数做抵押，就是说他要给别人提个严重Issue，就必须自耗4个秩数，别人完成Issue，项目Issue增长，别人的Issue也增长，最终一旦过点，项目经理的秩数是其消耗秩数的一倍，比如把项目从立项带到CDCP，共消耗了1000点，那么一旦过了CDCP点，项目经理的秩数就会在当前基础上净增加2000点。一旦无法过点，最着急的就是项目经理，他不但损失秩数，还留下不好的记录，所以他会尽力避免出现这种事情，而避免这种事情最好的办法就是提正确的Issue，而这就是他的工作。
Categories