通常，在自定义Web开发领域中，所有代理商都只梦想着其项目的年营业额增长两倍的客户，定期交付您可以自夸的案例，并获得代理商的个人资料评级奖项。 这些客户是行业领导者。 这些公司要么是业务建立在网络上的公司，要么是大型脱机网络，这要归功于惊人的投资，从而成为网络渠道的领导者。
似乎有几个这样的客户，您可以放心地桂冠-停止销售，只控制不断增长的任务流。 但是实际上，随着项目的发展，它将给您带来新的挑战，以应对和挽救客户，同时要以经济高效的方式工作，这将是一项非常艰巨的任务。
项目发展及相关挑战
及时采取积极措施并承担与扩展相关的额外成本非常重要。 起初，这可能会对获利能力产生不利影响，但是当达到一定数量时，很明显初始投资是合理的。
以下是代理商在此类项目中可能面临的主要挑战：
- 规模问题是随着数量的增加而重组团队结构。
- 需要了解产品和业务任务-没有强大的产品分析功能，就不可能在大型项目上有效地工作。
- 复杂的软件和服务器架构-随着项目下产量的增长，参与人数也随之增加，从而导致架构更加复杂，并需要使用高负载解决方案。
- 高质量的要求。
- 需要确保不间断的24×7运行和对事件的高速响应，包括非工作时间。
- 停止销售的高度责任感。
- 监视和控制业务指标。
并非市场上所有的代理机构都具有应对所有这些挑战所必需的能力。 今天，我们将讨论团队规模的问题-我认为，这是处理不断增长的项目中最困难的方面。
我有机会参与了几个具有爆炸性增长的项目，包括最大的儿童用品在线商店和领先的保险公司。
我首先以经理的身份参加了这些项目，然后以管理团队的负责人的身份参加了这些项目，我想分享获得的经验。
小型项目中的角色以及为什么需要扩展
一般情况下，角色方案如下所示：
在AGIMA，我们采用三阶段管理，即在项目团队内部的互动框架内确定所有战术问题，并将战略问题纳入客户总监和客户服务部门负责人的级别。 在项目团队中建立了一个层次结构，具体取决于项目的规模，下面我将进行讨论。
这是一个小型项目的项目团队内部的典型角色图：
该项目具有两个关键角色：项目经理（RP）和团队负责人。
公司与客户沟通，形式化任务，拟定积压，确定优先级，制定计划并控制任务，以符合业务逻辑。 此外，RP在工作的各个阶段都与设计，设计，分析，系统管理部门进行沟通。
Timlid执行任务的技术形式化，定义所使用的技术/工具，进行代码审查，执行发布，监视项目的架构完整性，并协调开发团队。
其余资源可以根据需要连接到项目，并且可以高度互换。
在无法将所有信息都掌握在同一时刻的情况下，项目发展和重要的模式转变发生了重要的里程碑。 由于项目团队发展太快，因此一个团队领导实际上无法控制项目的整个体系结构。 一位经理没有时间投入所有任务并控制所有工作。
需要分离和重复雇员的职责，并且标准角色方案扩展并且变得更加复杂。
管理团队结构
RP是最难扩展的单位之一。
随着项目的发展，当一个RP负责客户服务（包括产品问题），而另一个RP负责组织公司内部的生产过程时，实施经典的配对客户经理-项目经理计划是很有意义的。
但是，这种方案在随后的增长中陷入僵局。 在一个项目的框架内，最多可以有数十种产品，从业务流程的角度来看，每种产品都需要密切关注。 在这种情况下，当不同产品的并行开发导致Web应用程序体系结构或业务逻辑框架内的逻辑冲突时，会周期性地出现情况，这带来了极大的风险。
因此，从进一步扩展的角度来看，理想的方案如下：
集团负责人（GH）管理项目的管理人员，负责控制预算，盈利能力，团队组成（管理人员和直接执行人员）和资源分配，并解决项目管理的战略问题。 他还负责产品控制并监视并行流程中是否存在冲突。 他没有将时间花在运营活动和监视每个特定任务的执行上。
由于引入了该角色，因此消除了并行执行多个大型任务并在最后阶段显示矛盾和逻辑冲突的情况，在最不成功的情况下，这会导致完全重构。
如有必要，可以连接一个附加的产品负责人角色，GH可以将部分产品职责委派给该角色。 通常，此员工基于客户端，以形式化任务的形式传达企业的所有希望，以执行任务。
团队中的每个RP负责其项目的“一部分”，控制许多产品的所有当前任务（理想情况下，这些应该是相关领域）。 他的职责包括在负责任产品开发的框架内安排所有任务的时间和质量。
该方案易于扩展，并且具有相对较低的入门门槛，因为当连接新的RP时，它不需要同时覆盖项目的整个知识库，因此足以理解“您的”产品的操作原理。
每个RP不仅要负责生产过程，而且还要精通其产品的业务逻辑，这一点很重要。 因此，所有管理决策不仅从项目管理的角度是正确的，而且对业务和架构验证也很有用。
在某些情况下，项目经理的角色应单独列出-该员工不会沉浸于产品组件或生产过程中，而是参与报告的编写，负责文档管理，还扮演着“第一线”的角色，从而确保沟通的连续性并迅速回答所有客户和合作伙伴的要求。
同时，整个管理团队首先包括与管理客户期望相关的集体动力-进入项目时机。
- 在每个月的开始前10个工作日，每个RP都会在下个月分配三到五个主要任务。
- GH在每月开始前5个工作日为每个经理选择其中的两个或四个，并设置截止日期：1-客户任期（50％），2-内部任期（100％）并将其输入表中。
奖励条件（根据当月结果）：
- 如果经理的所有任务均在内部期限内完成，则经理将获得100％的奖金。
- 如果经理的至少一项任务离开内部任期但在客户任期内完成，则经理将获得50％的奖金。
- 如果总客户名单中的至少一项任务未在客户的时间内完成，则任何经理都不会获得奖金。
该方案使整个管理团队能够有效地工作并正确管理客户的期望。
不仅测试最终代码-QA命令
随着项目的发展，扎实的知识库不断积累，细微差别和功能的数量不断增加，逻辑关系变得更加复杂和多样化。 在某些时候，这些因素开始产生巨大的影响，以至于预发行调试花费的时间与开发相称，并且占用了相同数量的资源。
为了避免这种情况，我们提出了基于测试团队创建完整的质量检查团队的想法。 主要区别在于测试不仅在开发调试发布阶段进行，而且在项目的所有阶段进行：
- 质量检查负责产品的质量及其与其他产品的风格和逻辑一致性，并在项目规则中普遍接受。
- 质量检查负责检查项目中出现的所有工件：任务的初始形式化，原型，规格，设计，当然还要测试代码和布局，编写测试用例，并通过自动测试网格覆盖现有功能和新功能。
- 未经质量检查团队对材料的确认，RP将无权启动下一阶段或将材料发送给客户接受。
这种方法可以大大降低长时间调试和延迟发布日期的风险。
Timlids-效率或互换性？
一旦将第二个团队负责人介绍给该项目，就会立即出现问题-应该采用哪种责任分配方案？
有几种选择：或者按活动类型划分项目，例如，团队A专注于体系结构，代码审查和任务的技术形式化，而团队B管理开发团队并发布构建，则负责连续性和安全性。 第二种选择是产品细分，其中每个团队负责人应对项目中的所有产品负责。
两种选择在资源利用方面都不错，但在互换性方面却带来很大的风险。
例如，如果团队负责人之一生病，休假或辞职怎么办？ 由于要沉浸在这一角色中的时间非常长，因此很难将新的团队领导者纳入流程。
因此，在项目上使用混合方案是值得的，每个团队负责人都从事自己的任务，但是在许多活动中，所有或至少两个团队负责人都投入了精力。
此类活动包括风险最高的活动，例如：项目架构，连续性，安全性，占最活跃销售的关键产品，其性能在SLA中指定。
当然，该方案降低了劳动生产率，但消除了大多数风险。 有必要在效率和互换性之间找到平衡，概述了最关键的时刻。
另外，将团队负责人与疏远的活动联系起来是有意义的：在架构上与项目主要部分脱节的产品，或者可以并行进行的活动。 例如，完全有可能挑选出一个团队负责人布局，该团队负责人将完全控制所有前线业务。 团队领导质量保证，设计和分析的角色分别得到区分。
团队成员的互换性
参与项目的人员越多，您就越需要使用工具降低新员工的入职门槛，他们还可以简化现有团队成员的互换性并减少总线系数。
这里有一些在几乎所有项目上都能很好运行的工具。
设计系统该设计系统是资源库中一个全面且最新的设计套件和组件库。 它反映了项目中的全套标准元素，并允许您从这些块中收集新页面。 设计系统不仅包含一组元素，还描述了它们的交互作用，还包含代码示例。
设计系统的使用可以极大地简化新员工（无论是经理，设计师还是程序员）对项目视觉规则的理解，并应用现有解决方案而不是不断发明新的解决方案。
使用此类工具需要大量资源用于开发和支持。 此外，通常需要花费大量的道德努力来向客户解释为什么必须遵守此系统，并且由于什么原因，诸如“在此页面上添加一个新的绿色按钮，如站点N上看起来很漂亮”的提议将被拒绝。
该文件项目越大，对每个产品和每个功能的记录就越仔细，否则，专家将花费越来越多的时间来调试和弄清楚一个或另一个功能应该如何工作。
项目文档可以分为4种类型：
- 界面规范-对已实现功能的行为的描述（工作逻辑，现场验证，屏幕集）。
- 测试用例（用户场景的描述及其通过的结果），如有必要，可以基于它们开发自动测试。
- 服务规范（与Web服务交互的描述，测试数据，请求-响应示例）。
- 代码文档（组件，类及其层次结构，模板的描述）。
所有文档应汇总在在线知识库（Wiki）中并保持最新。
吉特为了加快新开发人员与公司其他项目的联系，正在引入一种标准的GitFlow方法。 在AGIMA，我们使用“与两个主要分支一起工作”的方法。
代替使用master分支，而是使用项目历史记录的两个主要分支：master用于发行版，而development用于合并来自功能分支的已开发功能。
工作流程规范和标准化所有团队成员工作的另一种工具是按星期几进行的工作流。
每个星期都是一个标准的生产周期：发布严格在星期二和星期四进行； 星期三-评估日； 新货的追溯和计划在本周末-周四和周五进行。 这是来自其中一个项目的工作流的示例，对于每种特定情况，都应开发一种方法。
客户也必须参与工作流程-这样的系统不能单方面工作。
任务状态的工作流同样重要，它简化了项目之间员工的过渡。 在公司的所有项目上都应该相同。 在AGIMA中，它看起来像这样：
通知团队成员
即使文档是在项目上完美组织的，并且所有过程都像发条一样工作，也无法预见与每个特定艺术家的意识不足有关的所有风险。 为此，组织了各种形式的定期活动。
1.产品会议在这样的会议上，更有经验的员工向团队介绍特定产品。 重点介绍了业务逻辑，技术实现和体系结构。 每个员工对产品主要细微差别的意识有助于提出有用的想法，并在实施的所有阶段做出正确的决定。
2.基础设施部分该项目正在动态增长，这需要基础设施的不断发展和扩展。 在常规部分中，讨论了基础结构开发中的当前问题和任务，并讨论了每个问题和实施的进度。
3.回顾和工作计划有必要召开每周会议，讨论在过去一周中执行的任务，突出显示错误并计划下一个会计期间的工作。
结论
考虑周全地应用上述所有工具和方法将有助于建立一个连贯而富有弹性的团队，随着项目的进一步发展，该团队将轻松扩展。
毫无疑问，这样一个系统的组织会遇到很多困难，既需要代理机构的深厚能力，也需要客户投资于这样的决定的意愿，这在我们发展中的市场上可能是困难的，但是这样的努力是有回报的，并导致长期有效的合作并允许发行市场真的是优质的产品。