软件开发部门的新形式

从一开始,我们将解决软件开发中现有的问题,存在的问题以及需要解决的问题。



该部门的经典计划如下-人们坐在办公室(好吧,或者现在是偏远的地方)中,以便进行基于时间的付款(每天8小时)或每小时一次的修理厂。在30-120分钟内上班。一个人是通过hh或类似的站点雇用的,候选人要经历hr'a(技术安全),在那里他们试图制定一个能力矩阵。莫斯科有许多知识水平各异的候选人,在该地区,这是一个问题。如果附近没有技术大学,但您想经营一家企业,请去最近的百万富翁那里,并支付当地工资。后者对于初创公司特别不愉快。最好是在有人的项目上存在并且有解决方案的文档,其中描述了数据流方案等,但是我从未遇到过。有残篇,混乱的记录,会议记录以及做出决定的原因,但是系统的开发文档就像月食一样。为什么需要带有图表和说明的文档?当一位建筑师为未来的项目设计模型时,他就是一个独一无二的知识的承载者,而这是其他人所没有的。这是一个严重的问题,如果专家生病,死亡,离开,那么他的能力也会消失。在没有文档和知识载体的情况下恢复能力是一项艰巨的任务,以至于重新编写所有内容都容易(两者都是大笔钱)。将一个新的战斗机或旧的战斗机从另一个项目引入该项目需要六个月的时间来指导和分散已经在工作中的人们的注意力。同时,新装置总体上也具有有限的功能。问题陈述系统可以分支,拆分为子任务,然后从意外位置合并回去。该任务可能无法通过主管或架构师,这会增加垃圾和狂热,以尝试扩展体系结构或将其推向不可阻挡的境地。同时,新装置总体上也具有有限的功能。问题陈述系统可以分支,拆分为子任务,然后从意外位置合并回去。该任务可能无法通过主管或架构师,这会增加垃圾和狂热,以尝试扩展架构或在无法阻挡的地方塞满东西。同时,新装置总体上也具有有限的功能。问题陈述系统可以分支,拆分为子任务,然后从意外的地方合并回去。该任务可能无法通过主管或架构师,这会增加垃圾和狂热,以尝试扩展体系结构或将其推向不可阻挡的境地。



经典方案的问题



人力资源的可用性有限,实际上不适合进行业务变更。因此出现了停机和加班的问题。



聘请狭窄的专家是无利可图的。这样的专家是唯一的知识来源,但是维护成本很高,而且任务很少。因此,停机时间和能力停滞的问题。



团队中的人专长于当前的任务,如果他们不努力或不强迫自己,就会开始退化。



对于所分配的金钱和时间,找到具有必要能力的人是困难的,甚至是不可能的。



缺少描述该项目的文档,以便初学者快速入门。

需要导师。



在没有深入分析这种可能性的情况下扩展功能的问题,而这种分析只有由项目中具有广泛能力的人(建筑师)才能实现。



放弃拥有该项目独特知识的人的问题。



团队中的道德氛围问题和影响重要决策采用的个人关系。



客户和表演者的薪酬财务不透明的问题



增加执行者的状态和执行的任务类型的问题。



是否可以在不更改开发管理范例(模型)的情况下以某种方式解决这些问题?最简洁的答案是不!将来,这种模型将减慢工作速度,并且随着业务和流程官僚化的增加,通常会迫使开发转移到外包。外包开发好吗?-简短的答案是肯定的,如果它可以加快并促进产品开发!外包可以是公司内部的吗?- 简单。和外部?-这里很难,对,安全就可以了,但是可能!内部和外部又如何呢?-您可以,这是操作方法。



该服务是



  • 客户与表演者的交流系统。
  • 提供具有所需能力的专家动态联系。
  • 与客户和承包商进行结算。
  • 快速显示项目状态和任务进度。
  • .
  • .
  • .
  • .
  • .




  • . , , , .
  • . . “, , , ” — . “ ” — , , , , . “” — , , , . “” — . “ ” — , , . “ ” — , , , .
  • . . , . .
  • . . , , .


每个较高级别的角色形成一个用于较低级别的子任务的分解子任务池,指定执行条件和完成任务的成本。上级角色无法指令性地分配执行程序或将自身分配给子任务。



分解任务时,较低级别的角色必须从设置原始任务的较高级别的角色收到对其解决方案的确认。



下属角色在收到问题后,可以将其发送给主任,以查明所发现的错误或不正确之处,或者通过仲裁和投票解决争议。



如果不是其(任务)主管,则上级角色可以承担任何下属任务。



已完成的任务位于特殊的池中,以供审核和批准。可以通过当前角色(而不是执行者)或更高和更低的角色来审查任务。



对于已完成并已批准的任务,将向执行者收取任务中指定的付款(减去​​交易的服务佣金)和评分点。



对于具有合理指示错误或偏离审阅标准的完整审阅,将授予分数,并将其从审阅人员中注销。基于评审结果的争议将通过参与评审的角色的一般投票自动解决。



表演者达到一定数量的分数后,便会自动过渡到上级角色。因此,您可以遍历整个层次结构直至经理,而无需解决单个问题,但是可以在检查其他人的问题时获得要点。



每个任务和任务分解树都伴随着一组文档的创建,这些文档证明了对解决方案的选择并对其进行了简短描述。每个任务都不是现有任务的分支,即扩展功能,应该从经理的批准开始,然后通过角色的批准直到最终执行者。



如果该任务已投入工作,则会自动视为未完成,但是截止日期已结束,承包商也没有发送任何理由延长该截止日期。

未完成的任务被放回到任务池中执行,执行者以记分注销的形式被罚款。



一定程度的负分集会导致表演者针对所选能力的自动阻止。



在一定时间内缺少完成的任务或检查会导致总分自动降低。



当分数低于角色的阈值水平时,表演者的状态将转移到较低的角色。



从客户到成品的订单转移方案



客户在服务中启动一个描述业务任务的项目(这是主要信息)。为服务中的帐户捐款,以获取经济和营销专业知识(如果已经存在)或由领导(开发人员,架构师)准备技术任务所需的最小资金。经济专业知识和技术依据包括有关此产品经济可行性的专家意见。经济可行性是对类似物,需求,可用资源和实际可行性的研究,以带有建议的文件形式提出。当服务中的客户帐户上有足够的资金时,任务将转到下一个阶段。客户可以提供其专业知识或TK(技术规范,项目架构)以供批准。如果未通过协议,这样就无法将任务(项目)用于开发。客户可以在任何步骤退出服务,也可以将其冻结在服务中(收费)。客户对项目的所有文档和源代码,应用程序包或资源的组件,项目和任务的进度以及执行者的工资单具有读取权限。



按照项目开始时制定的规则进行开发,这涉及到文档和描述的编写语言,代码格式的协议和自文档注释。编写类和函数的优先级是最简单,最简洁的代码。在每种情况下,只要有可能,代码都将包含在单元测试中。在开发中,应该有专家来确保版本控制,自动组装,执行者与服务或客户方面的必要设备的远程连接等工作。



在收到能力矩阵后,可以将表演者引入服务中。可以在专门以自动化模式进行测试的服务中获得能力矩阵。认可的服务提供了一个API,您可以使用它获得申请人的矩阵。根据获得的结果,将为执行者的帐户设置将显示特殊任务的起始角色和能力。总之,执行者在服务中注册并接收到能力测试服务的链接并将其传递。测试结果将填写能力矩阵,并为客户提供执行任务,进行审查,阅读有关其角色的可用文档的机会。



建议在第一阶段将已执行的执行者根据“办公室”的现有基础引入服务中。在实际项目中检查与客户的合作。通过以下方式在专业社区和社交网络中开展广告活动:“完全透明,诚实,没有秘密。在所需的内容,所需的位置以及所需的时间进行工作。没人命令你。尽可能多地赚取收入,每个人永远都没有限制。



需要单独研究的问题



  • 安全。
  • 与客户和承包商的付款和结算。
  • 与客户签订合同之前的法律问题以及向表演者支付计件工资,跨境转移。
  • 版权保护。



All Articles