什么是启动项目的最佳方法,或者如何使其不致于造成极大痛苦的项目

每天都很好。 轮到谈论设计项目了。 根据我自己的经验,我知道有时候从头开始创建项目要比整理已经存在的项目更加困难。 这很大程度上是由于您或您留下的遗产。 在本文中,我将尝试告诉您值得特别注意的地方,并提出一个简短的后续计划。


对项目的了解


在计划之前,您需要了解需要实施的项目。 对于我自己,我已经确定了几类项目,例如:

  • 一次性工艺品是一个旨在创造某种图形概念并将其进一步出售给投资者的项目。 此类项目的显着特征是:

    1. 疯狂的文档。 基本思路很明确,但是业务案例完全混乱,没有逻辑上的漏洞可以考虑。
    2. 截止日期。 从编写文档到原型,最多需要3个月的时间。
    3. 没有开发计划,也没有计划进一步的支持。
    4. 小团队。 通常最多5人,包括设计师。
    5. 缺乏业务流程。 所有的互动都是混乱的,基于人际交流,关键点的澄清和/或旅途中的发明。
    6. 角色模糊。 权力和责任范围没有明确划分。
    7. 没有真实数据。 所有数据都是为“美观”而生成的,并经过了量身定制以达到最佳显示效果。
    8. 为了加快开发速度,完全使用了外部依赖项。

  • 启动是一个配置为实施特定想法并随后进行开发的项目。 通常,这些项目是根据螺旋模型开发的,因此,它具有与第一种类型(一次性飞行器)几乎相同的独特功能:

    1. 明确分解为各个阶段。 最低要求:术语和必须在给定时间内实施的功能列表。
    2. 相对合理的文档。 进行分析,为完成阶段设定基准,在冲刺阶段进行改进。 尽管敏捷声称拥有事实,但大多数人还是使用瀑布。
    3. 主要功能的平均期限。 平均6到12个月。
    4. 在初始阶段,将使用外部依赖关系,最终将其更改为自己的实现。
    5. 小团队。 通常最多7-10人。
    6. 角色是分开的,但责任是模糊的。
    7. 一个项目可以变异。 在一个阶段,实施的概念或方法可能会改变。 通常这是由于投资者的要求,最初失败的想法或体系结构中的错误所致。
    8. 有条件的实时数据。 在焦点组中运行或从第三方资源解析实时数据。 没错,这并不总是会发生...

  • 信息系统是一个实施想法并计划集成到第三方服务中的项目。

    1. 有一个发展计划。
    2. 书面文件清楚。 最低要求:已记录API描述。
    3. 您可能需要与第三方服务集成,安装拐杖或重建系统的各个部分。
    4. 有中间版本,修补程序。
    5. 中型团队。 通常从10到20-30人。
    6. 明确职责分工。
    7. 安全要求:分析之后,会创建案例,这些案例可能导致系统崩溃。
    8. 时间用于测试。
    9. 由敏捷使用。
    10. 几乎总是积压。
    11. 仅使用昂贵的外部依赖关系。 它的实践与专有技术相提并论。

  • 封闭系统是一个庞大的项目,旨在满足客户的特定需求,并进行进一步完善。

    1. 特定客户。
    2. 有一个发展计划。
    3. 开发设计文档。 为了帮助用户,应客户要求编写了单独的文档。
    4. 用户权限的区分。
    5. 几乎总是积压。
    6. 团队规模通常大于平均水平。 通常,从10个人到心率丧失。
    7. 由敏捷使用。 有时还会出现必须不惜一切代价执行的其他任务。
    8. 意外的示威。 需求是在高级管理层的要求下发生的,因此,可行的测试电路将永远不会多余。

  • Saas解决方案是一个庞大的项目,具有灵活的配置和针对特定客户的进一步定制。

    1. 多模块系统。 该系统分为几个部分。 即使在特定项目的范围之外,也可以单独使用。
    2. 明确的计划。 最低:为实现功能而估计的人工成本。 为现代化和重构奠定了时间。
    3. 体积文件。 通常,几乎所有内容都被描述,包括测试用例。
    4. 通常,不存在外部依赖关系,并且将编写其自己的系统部分实现。 即使有第三方实现。
    5. 几个开发团队。 每个人都应对自己的开发负责,无论是支持还是开发。
    6. 测试所有内容的覆盖范围。 使用自动,单元,回归和集成测试。

所有等级都是有条件的,并且流动类型最常见。 我想指出的是,所有类型都可以相互变异,唯一的细微差别在于现代化的成本。 例如,该项目最初是“一次性工艺”,然后演变为“封闭系统”。 通常,这会导致对系统或其重构的完全或几乎完全的重写。 如您所知,这在经济上是不可行的。 出于同样的原因,建议您了解您需要从头开始创建哪种项目,并尝试确定其未来的命运。


为了确定项目的类型,下面我给出了一些问题,收到答案后,您就会清楚地知道他们想要从您那里得到什么:


  • 该项目的目的?
  • 需要实施哪些内容的完整列表?
  • 有文件吗?
  • 截止日期是几点? 准确的日期是可取的。
  • 是计划与第三方系统进行外部交互,还是该项目具有外部API
  • 有什么进展吗?
  • 团队规模?
  • 谁负责什么? 谁设定任务,谁接受,谁拥有否决权。
  • 有没有什么发展计划,它们是什么?
  • 谁是客户?
  • 购买交钥匙解决方案有预算吗?
  • 您打算采用哪种方法
  • 有类似物吗?

如您所见,列表并不是很大。 但是,由于某些未知的原因,很少有人在开始做任何事情之前会问这样的问题。 您问我为什么要了解项目的类型? 您始终必须使该项目永远存在吗? 总的来说,您是对的,但有一些细微差别,例如在一个热闹的笑话中。 这些细微差别是资源和时间表。 不要忘记我们为企业的利益而努力并执行任务。 当您知道项目的类型时,您可以牺牲一些良心而达成目标。


技术选择


选择时最好遵循规则:该技术不应该是超新星,但也应该过时。 如果该技术或框架是新技术,则可能导致以下问题:


  • 寻找合格人员
  • 发展前景:在早期阶段,开发可能会消亡,或者相反,如果技术过时,则必须由我们自己解决错误。
  • 缺乏新解决方案的交钥匙解决方案,而旧解决方案没有更新。

问题清单不仅与技术有关,而且与第三方依赖性也有关。 以上所有内容都可以将项目埋在萌芽状态。


在选择特定的东西之前,请三思。 创建一个臭名昭著的收益表,列出项目的重要因素。

这个例子是一个虚构的项目:


项目功能的名称。


项目重要性比


处理表格


3


路由选择


1个


轻松编写动画


0.3



从表中可以看出,选择的重要标准是“处理表单”和“路由”。 为此项目创建动画的简单性并不重要。 接下来,我们将通过添加新技术列来升级表。 在我们的情况下,将有两个。


项目功能的名称。


项目重要性比


技术1


技术2


处理表格


3


+


±


路由选择


1个


+


±


轻松编写动画


0.3


+


--



根据表中的数据,我们了解到“技术2”在表单和路由方面的工作是la脚的,创建动画就像调用Satan。 结果,该技术的比重为2。您问为什么2? 一切都很简单! 如果设置为±,则在该技术中将实现特定功能,但会带有某种“拐杖”,或者劳动强度更大。 在我们的比较中,“技术1”的总利润将更高,达到4.3。 我认为没有必要对金额的形成进行解释。 该表不仅适用于技术,还适用于需要从列表中进行比较和选择的所有内容。 重要的是不要忘记,您编写的标准越多,选择就越容易。


建筑学


当前,可以从提供建筑设计工具的各种不同服务中进行选择。 的确,它们中的任何一个都有缺点,某些缺点很关键,但对于某些人却没有。 因为我是“ oldfag”,所以我更喜欢一张纸和一支笔或一块板子和一个标记笔。


为了首先了解要掌握的内容,您需要概述系统的主要部分,然后选择构建体系结构的方式。 通常,实际上只使用三种:


下降 -开发人员从系统的大型节点推送到较小的节点。 体系结构的含义是,优先级组件是包含较小节点的大型节点。


升序 -开发人员从小零件推到更大的零件。 体系结构的含义是,首先创建了许多小组件,而大型组件已经由它们组装而成。


整体是不可分割的体系结构,通常称为“传统”。 实际上,这是一个刚性结构,要改变它,就需要没有“拐杖”的解决方案。 这是最糟糕的选择,但是,就像我们世界上的所有事物一样,它有权存在。 整体用于实现特定功能,并且将来不打算对其进行维护。 与其他方法相比,此方法的速度要快许多倍。 好吧,因为您可以闭上眼睛。


体系结构的选择取决于项目的目标和开发速度。 通常,当截止日期没有用完并且大型模块的数量很少时,使用第一种方法。 其特点是可以准确表示特定模块之间的关系。 在缺点中,我可以注意到与一系列动作相关的开发时间很长。

当需要较高的开发速度并且不了解顶层体系结构时,首选第二种方法。 一个功能是有时会在不同的大型单元中使用的许多小型组件。 值得注意的是,几乎所有开发都可以并行执行,而无需考虑其他任务。 这种方法的缺点是组件不能满足上层架构的要求,因此,必须重写它们或创建自定义的可能性。

如实践所示,所有开发技术都简化为螺旋式方法,其特征是功能的逐步积累。 我认为在本文的框架内考虑它是不合适的。


规划中


所谓的“路线图”将帮助您更有效地完成工作。 实际上,这是一个时间表,有条件地交付特定功能。 可以推迟日期,但是,根据实践,如果正确执行以上几点,则修正案最多可以达到30%。 实际上,这通常是10-15%。 通过计划,您可以跟踪项目进度,查看进度,以资源的形式进行调整或更改截止日期等。


以后他们会感谢你的


任何项目都始于文档,而且内容越多越好! 因此,不要偷懒-我们记录一切。 是的,这将需要一些时间,但是如果出了问题,这可以使您免于领导的愤怒,而不是您的错。 同样,不要忘记,在您出现在项目中之后,人们将不得不了解您所创建的内容。 没有文件,这将不容易。


结论


本文介绍了如何采取行动以及在启动项目时要寻找什么。 这些阶段对于正面,背面,测试或所有阶段都是通用的。 我故意避免使用技术细节,以免引起误解。


如果可以选择要使用的技术堆栈,体系结构,并且需要确定项目的时间范围,则下表可以为您提供帮助:


项目类型/功能


一次性工艺


创业公司


资讯系统


封闭系统


Saas解决方案


其他一些项目


5岁以下的人数


X
X
X
X

人数从7到10


人数从10到30


X

数量超过30


X
X

完成日期长达3个月


X
X
X
X

交货期6至12个月


期限超过12个月


X

该文件


与其他系统的集成要求


特定客户已知


计划进一步的支持


规划中


角色已明确划分


允许外部依赖


有用于测试和分析的实时数据。


安全要求


需要测试


需要产品文档或说明


需要模块化实施


几个开发团队


合计


我想每个人都已经猜到了如何使用表格,但以防万一-与上一个表格完全相同,只是以填充单元格的形式添加了少量内容。 这意味着该值不能用于该项目。 另外,请注意该表可能不完整,请添加您认为必要的行。

Source: https://habr.com/ru/post/zh-CN447366/


All Articles