在一家小公司里开发一个大系统

Question

我是匿名做的。

我们公司生产一些机器，也有一个软件部门，我是其中的一员。我们的理念主要是有内部的软件和组件的机器，而不是第三方在合理的地方，以便我们可以迅速实现客户的要求。

最近，有人决定实施一个小型制造资源规划系统(包括物料清单、材料需求计划、容量规划等)，所有这些都与我们的机器集成在一起。

简而言之，客户将输入他的所有工人时间表、不同的制造作业及其能力、它们之间的运输能力、按制造某一物品或装配所需的顺序和时间、内部订单的截止日期等，然后系统会告诉客户一个生产计划--任何mfg的经营者。post应该这样做，报告容量过大和不足，时间估计，等等。

我想也有一个愿景，我们将使这个软件的通用性，以适应不同的客户需求，所以我们将出售很多。

我们正在努力增加机器的价值，所以客户只需要从我们那里购买这些东西，而不需要为真正的ERP支付几十万甚至几十万的费用。我们主要是把这个卖给小公司(数十名员工)，这些公司负担不起真正的ERP，而且只需一小部分成本就能享受自动化生产计划的全部好处。

但我有一种令人沮丧的感觉，那就是为什么这类软件的成本如此之高，而不是供应商普遍的贪婪--这是一个复杂的、需要时间开发的原因。我还担心“垃圾输入，垃圾输出”的因素--除非输入几乎完全正确，否则系统将无法产生任何合理的输出。我不确定你能否在较小的公司中实施这种程度的官僚作风和间接管理。

人们认为这个系统的所有部分都是可管理的(并且已经为屏幕绘制了用户界面模型)，这是没有问题的。也许我是高估的人，但我不知道.我们已经实施了其中的一小部分，大约花了两年时间才达到可以接受的水平。

我最关心的是低估了这种系统的开发时间。在现实中，我们有大约3个开发人员，其中一个是兼职合同，我们可能会再雇佣一个全职开发人员，所以总共大约有3个半人。没有人有这种规模的经验，我们会有更多的数据，我们需要更多的定制选项，更大的数据库和更好的算法，这样到处都会有陷阱在等待。

难道这些都不合理吗？我该如何向上级表达我的关切呢？反对这样的计划会不会让我看起来不情愿或者害怕？

Answer 1

首先，您可以尝试在头脑风暴研讨会中收集所有涉众的不同需求。通常，这是一个很好的起点，可以初步了解所有不同的期望和用例。有了这一点，您就可以开始开发该系统的第一个全局图像。当您了解更多关于您应该构建的系统的事实时，讨论您的关注点就容易多了。

尽量避免瀑布模型。尽可能多地了解敏捷开发、测试驱动开发和持续集成.为什么？

1. 使用像Scrum这样的敏捷方法将迫使您使用固定的时间线进行迭代(例如，我们使用了3周时间)。
2. 三周后，你必须向你的客户展示你的结果，希望他们对结果感到高兴。
3. 对利益相关者的新需求做出反应要容易得多，因为您将在每次冲刺之后满足它们(在3周后要比半年后更容易改变您的关注点)。
4. 当你的利益相关者改变主意(通常他们会改变主意)时，你可以很快地从他们那里得到反馈。
5. 在这样做的时候，测试会给出一个答案，在实现新的需求/用户故事之后，系统的哪一部分被破坏了。
6. 持续集成方法可以帮助您查看构建是否中断、单元测试是否是红色的，或者在每次提交/基线之后发生了其他错误。
7. 这使您的系统更加稳定，您将不会害怕改变事情。
8. 所有这些都能帮助你始终拥有一个有效的系统。即使您必须部署一些您知道您的系统已经有价值的东西。