【仅供内部供应商使用,不提供对外解答和培训】

Page tree

【仅供内部供应商使用,不提供对外解答和培训】

Skip to end of metadata
Go to start of metadata

1.由于官方指定了每个需求的唯一责任人,所以所有关于需求的细节和疑问的确认均由开发者跟责任人在指定的交流群组内对接完成(减少对接的入口和资源的浪费)。

每个需求都会有一个讨论组,成员由 官方二开管理者、官方二开监督者、官方指定的该需求责任人、以及对应的二开外包开发者组成(二开管理者可能跟责任人为同一人);若最终需要认责,最终认责只看 音视频记录和有管理者和监督者确认过的文字信息(也就是这个讨论组的聊天记录和抄送了管理者和监督者的邮件),其他跟任何私下的聊天确认的信息均不作为判定的依据。所以外部开发者一定不要轻信非责任人给你说的该需求的确认细节/技术方案方法/开发技巧 ,所有关于此需求的疑问均直接跟对应的责任人确认沟通(第三方技术如何实现,方案如何设计,代码细节如何编写不在此沟通范围内)!若责任人支持态度消极,开发者可以向管理者和监督者投诉,管理者和监督者会根据实际情况进行认责。再次强调(责任人跟开发者交流的一定是需求的细节确认和FR产品的接口/API/非保密的代码段,任何第三方技术和方案不在责任人需要责任支持的范围内)

若因开发者自身因素导致的需求延期或无法完成,管理者和监督者有权要求开发者在规定时限内完成此需求,对开发者拒不执行或执行无果的,将按失信处理,记录到个人综合能力档案中。造成严重后果者将进行降级或解除签约处理。


2.外包开发者禁止在未取得责任人允许的情况下向任何非官方人员组织透露所开发的需求的任何技术细节和资料!

此项违规属于严重的开发事故!一经认定【具备不可抵赖性的证据】、将按失信处理,记录到个人综合能力档案中!造成严重后果者将进行降级或解约处理!


3.对于超过4个外包人天的开发任务,每隔一天(每两个自然日)需要将当前开发的成果【还没成果也可以不需要】/代码(这个必须要有)/相关文档【没有文档就不需要】 发送给管理者并抄送监督者,以配合官方监督开发进度(为了你的知识产权安全!任何时候完整的源码不要发送给这两个人之外的第三方!对责任人在咨询时可以发送需要咨询问题相关的代码片段)

此项违规不做佣金处罚,但会作为个人服务行为违规,录入个人综合能力评分档案中。


4.对于外包开发者争对某需求所报工作量,责任人可提出质疑,由管理者和监督者进行裁定。管理者和监督者也可发起质疑,并对认定为明显有较大偏差的工作量进行调整。调整后会与责任人和开发者进行再次确认。若大家均无异议,则按修正后的工作量进行。若有异议可进行再次讨论确认,若最终达成一致,则按最终所定工作量执行,若无法达成一致则终止此次外包任务(重新招标或由责任人自行完成,这个决定权在责任人自己手上)(PS:考虑到外部开发者的能力问题,原则上不超过官方内部评估工作量的100%,均不算异常【官方评估不会公开】)。

       此项违规,将按失信处理。将严重影响开发者今后的投标(原则上不会采用信用有瑕疵的开发者的方案,除非所有投标者都是失信开发者。若签约开发者失信,则所签合约自动失效),此项违规不会通知到违规的开发者,所以希望大家评估工作量时尽可能不要出现太大的水分(已经允许比官方评估时间多100%了~再贪心那就没必要合作了)。


5.开发者有义务配合责任人对已开发的成果进行验收(提交设计文档【如果需要的话】、成果安装使用文档、维护说明【如果需要的话】),对责任人关于验收提出的任何关于成果的安装、使用、限制、维护相关的问题进行解答。若开发者消极配合,则责任人可以提出质疑,由管理者和监督者进行裁定。

此项违规会作为个人服务行为违规,录入个人综合能力评分档案中。对于造成严重后果的(比如客户投诉),将被取消半年内的投标机会和任何FR承诺的权益。


6.每个开发任务都有一定的维护期,若无特殊说明均为自开发当日起的1个自然年。在维护期内,开发者需要对责任人提出的开发成果与需求文档、设计文档、验收文档不符的部分进行无条件的维护。

此项违规会扣除一定比例佣金的尾款,若尾款已结清的将从下次任务的佣金中扣除(比例为此次任务佣金的30%),且记录到个人综合能力评分档案中。造成严重后果者将进行降级或解除签约处理。


7.从需求确认(已定方案和工作量)到开始开发期间,若需求出现变更,允许开发者重订工作量,但需在《变更需求说明书》(责任人编写)给出后最迟3个自然日给出答复。若变更需求无法实现或新定工作量责任人(代表客户)、管理者、监督者任何一方或多方无法接受,且最终无法达成一致,则终止此次任务(重新招标或由责任人自行完成,这个决定权在责任人自己手上)。


8.从需求开始开发到验收完成期间,允许少量的需求变更,不超过总工作量15%或1天的需求,需要无条件服务,但要先记录到JSD任务中,经过负责人同意后进行开发,并且提交相应的代码和变更材料;当变更工作量较大时(超出1人天或者15%)则需要对变更部分内容重新进行有偿开发。在技术可实现的情况下工作量的判定以开发者的意见为主,但如果偏差太大,管理者和监督者会进行质疑。对于大量变更需求的场景若开发者跟管理者和监督者无法达成一致,则按原需求和任务执行,变更部分将在验收后交由责任人自行处理(若招标则原开发者无权投标)。


9.为了保证尽可能对每一位外包开发者的公平,所有发布的任务在流标前,都不允许内部官方人员接任务。流标后由原责任人自行处理!为了进行身份验证,会对开发者进行实名认证和不定期的视频验收验证,如果存在内部人员直接或间接接取任务的情况,一经查出直接交由人事处理(屡教不改者,取消当年全部奖金,并取消来年的职级评定申请资格,造成严重后果者直接开除处理,欺诈行为在哪个公司都是严令禁止的!),并对已发出的全部佣金进行追缴。对于内部人员同伙的外部人员,一律从开发者资格中除名!(做人诚信一定是第一位的!),欢迎大家一起监督,共同创造良好的生态建设环境。


10.维护期间若有需求变更,则通过新的需求流程执行。且优先考虑原开发者。


11.对每一个开发任务,从招标开始责任人均会对开发者的各项能力和态度进行考量。最终录入到当次的综合能力评分表中并入个人综合能力评分档案中,对于其中的扣分项会告知开发者,若有不实开发者可提出申诉(感性评分部分无法申诉,让别人欣赏你也是一种能力),申诉成功可取消此项减分。

  • No labels