在过去的部分
在
第一部分中，我宣布了一系列有关预项目中分析师工作的文章。 它列出了启动IT项目时需要记住的问题，解决方案和原则。
在
第二部分中，我谈到了前期项目的常见问题。
在
上一篇文章中，我们讨论了基本原理的第一部分：
- IT系统的设计和IT产品的分类。
- V模型级别和系统生命周期。
- 将系统视为金融资产。
在本说明中，我们将以“如何做”作为结尾，以进一步讨论如果无法正确解决该怎么办。
您将从本笔记中学到什么：
- 关于不确定性和设计阶段。
- 关于评估的工作方式。
- 关于预项目阶段任务的全部范围和同时实现的价值。
- 关于如何为预项目获取足够的资源。
如果不想等待周期的下一部分，可以
观看我的报告
的视频，以此为基础撰写本系列文章。
系统生命周期和不确定度
不确定性锥是设计和现代项目管理的中心概念之一。 概念的本质：我们拥有的信息越少，不确定性就越大，该不确定性可以通过项目条款和成本的价差形式来表示。
建立系统的每个阶段都会消除部分不确定性。 在进行项目的典型阶段时，不确定性呈指数下降：
- 当我们在半页的摘要中表达一个想法时，成本和收益的差异可以达到几个数量级。
- 有业务需求时，在制定业务计划或业务模型的同时，我们会降低成本/定单返回的价差。
- 为了进一步减少传播，您需要制定有关系统外观和设计的关键决策。 这项研究将价差降低到一半。 尽管分散程度仍然很大，但是对收益与成本之间的关系进行分析仍是主要决策-我们是建立系统还是寻找更有利可图的东西。
- 通过指定构建系统的条件（由谁进行构建以及在什么时间范围内构建），我们可以将成本分散降低到可以通过项目管理方法，储备金和处理风险来使用的值。 规定的条件记录在工作说明书中。
- 只有技术设计才能提供几乎准确的估计值，并且业务可接受的错误。
结果如下：
- 从资源分配的角度来看，如果项目不再能够盈利，那么我们必须有时间缩减项目，然后再花费很大一部分成本。 从简介到技术设计的各个阶段应只占系统总成本的一小部分。
- 您还需要了解，您无法想出一个主意并立即承担成本。 当您被告知这里有2000万，并且可以肯定的是，只有简短的-不相信，不是。
- 需要完成业务需求和概念开发，因为它们消除了不确定性，但是如果项目没有启动，则可能无法克服。 结果，这些阶段应该尽可能便宜，但是可以以质量的方式减轻不确定性。
评估如何工作？
有一个普遍的误解阻止了项目前工作的正常开展：如果我们不能迅速提供准确的评估，那么我们根本就不必理会需求。 这是不对的。 更准确地说，估计总数之和是概率论中的事实。
在这种情况下，预设计研究应将系统和工作计划划分为数十个可比较的部分，并且应通过类比或更准确的方法对每个部分进行评估。 评级的总和将比每个单独的评级具有较小的价差。
如果概念研究的质量不允许我们将系统划分为可接受的评估部分，那么我们就不会减少评估的分散性，因此没有必要进行此类研究。
从评估模式的角度来看，该项目的阶段如下：
- 如果在半页摘要中表达了一个想法，我们可以类推评估。
- 当我们制定了业务需求，业务计划或业务模型后，我们可以突出显示系统的关键参数，并使用大型因子进行类比评估。
- 该概念将工作分解为数十个部分，使您可以总结类推得出的估计并计算关键风险管理计划。
- 职权范围类似于按工作类型划分的供应商义务，代替了对系统各部分的评估。 通过类比得出的零件估算值将转换为专家估算值。 评估中的错误风险会转嫁给供应商。
- 技术设计允许将系统分为成百上千个部分，每个部分都经过专业评估或使用先前项目的实施统计数据进行评估。
如果上述本质不在预设计工作中，则最好不要这样做。 为了真正减少不确定性，不仅有必要增加系统文件包的厚度，而且还必须确保在那里制定了可测量和可行的要求和解决方案。
另一个常见的想法是：“业务需求不应衡量。” 记住-这是一个谎言！
您在预项目中需要实现的目标
在前面的部分中，是在问题方面提到过的。 现在，简短地重复在任何预项目中应设置和完成的任务：
- 了解时间和成本，以便计划成本并决定是否进行。 建议预测效果并返回以加快此决策。
- 出售系统：
- 向客户展示他的目标的理解。
- 向用户显示他们的问题的解决方案。
- 成功完成预算的出价（始终存在）。
- 为了建立接受的基础（关于结果的数量和质量的合同是一项技术任务），请不要忘记从各方合理期望的实际理由出发，将结果系统的验证放入计划中。
- 确定资源：类型，阶段，时间表，工作量和资源来源，以确定执行者的估计并确定系统成本。
如果未明确设置此类任务并且未计划解决方案，则最好不要浪费时间-该项目只有偶然发生才能成功。
为什么它可能不起作用（甚至不能起作用）
由于前面所有考虑，我们有3个矛盾的条件：
- 设计前分析需要快速完成。
- 设计前分析应廉价进行。
- 设计前的分析必须定性进行。
熟悉设计三角规则的人都知道不会发生这种情况。
还有其他一些困难：
- 项目前的分析可能表明所提出的解决方案的回报很低，这对客户和赞助商来说都不会引起兴趣。
- 相对于最初的假设，项目前的分析可能会增加项目的数量或总拥有成本，这将再次使客户和赞助商失去兴趣。
- 就初始假设而言，项目前的分析可以减少项目的数量，而这对于外部承包商而言通常并不有趣。
关于所有这些困难，我希望您和我能理解一件事：如果我们不与赞助方合作并且不将IT项目视为金融资产，那么前项目的问题就无法解决。
在对前一篇文章的评论中表达了意见：“必须尽早开放预项目，但应记住，预项目的范围受到其有效性的限制。 这样的前期项目被认为是有效的，之后将启动该项目。 这是预项目有效性的主要关键指标。” （c）
巫师IB这是项目经理之间相当普遍的观点，因为如果将某些事情委托给您，则您必须自杀，将团队挤到最后一滴，在断裂之前将您的胳膊转向供应商，强奸客户，但要实现目标。
另一方面，如果项目经理关闭自己的项目，他将减少自己的工作场所。
正确的方法是尽快清除不良资产。 预项目中的分析师和经理的任务就是这样做。
如何获得预项目的预算
为了走一条路，以建设性和一致的方式消除IT项目中的不确定性，有必要与客户和发起人明确有关将项目作为金融资产的态度的一般立场。
图为不确定性，投资和回报的正常比率。
只要不确定性很大，我们就必须少投资并减少它。
一旦投资收益率的不确定性变为可接受的水平，您就可以投入大量资源来获得回报。 在每个阶段的最后，必须做出诚实的决定：进行或结束项目。
为此，在每个阶段结束时，都应该以当前阶段自然的准确度评估投资和收益之比。
客户需要显示当前的不确定性水平，当前对收益和成本的合理评估。 如果收益超过成本，则有必要讨论进一步消除不确定性的问题。
言辞可能是这样的：“我们看到对收益的预测大大超过了系统的成本，让我们花费预测值或收益的一小部分来完善估计并决定系统的启动。”
我（非常平均）对前期项目各部分成本比例的建议：
- 施工前发生的一切费用都不应超过项目的10％至30％。
- 前期项目的成本应少一个数量级-这是系统预计成本的1-3％。
- 在早期阶段，只要没有业务需求，就可能没有预测值，需要从计算得出的收益中扣除-您可以在系统生命周期中将0.1-0.2％的预算用于创建业务需求（考虑到它不会启动）每个提议的项目）。
例如，如果我们出售的某个系统的成本约为1亿美元（以此类推）。 如果所有估算的准确性都较低，那么如果其运营回报至少约为300-500百万，这是有道理的。
在这种情况下，以下费用可以认为是正常的：
此处可能会出现任何方向的偏差。 但是总的原则是这样的：根据当前的不确定性水平，投资的资源应与预测的利润及其获得的可能性相关联。
简要总结
在这里，我们完成了对正确的预项目的审查，并重复了最重要的事情：
- 该项目必须被视为有风险的金融资产。
- 不确定程度应为所有人所知，并在所有有关方面之间进行讨论。
- 分析成本应与预期收益及其获得的可能性有关。
- 在开发过程中，有必要达到足以以当前阶段固有的准确性来评估成本和条款的需求质量。
- 特别是，业务需求应该已经可以测量。
- 必须记住项目前阶段任务的完整列表，每一项任务的省略都会使项目失败的可能性增加几个数量级。
生活表明，由于各种原因，并非总是可能遵守这些原则。 在某些情况下，可以保存或至少稍微改进一下在启动之前损坏的项目。 我们将在本系列的下一部分中讨论这一点。