对不真实任务的项目估计

Question

我是大型IT公司的开发人员，其核心是为客户提供服务(我的意思是开发部门是<20人，而不是组织的主要部分)。我正在解决与当前问题相关的不同任务，到目前为止，一切都很好，但管理层想出了实现一些应用程序的想法，该应用程序复制了业界获奖产品中的大部分功能，如MS的Visio或Autodesk的AutoCad。

他们希望使用我前面描述的可用资源来实现这一点。我的第一个回答是“即使在你最大胆的幻想中也是不可能的”，因为这种度量的项目是由几十个开发人员/架构师/测试人员组成的，花费数百万美元，从零开始的开发周期至少为1，5-2年。

他们认为这一点，但几乎没有反驳的理由，比如我们没有关于这个项目的任何最后期限(主题领域后面的立法尚未完成，也可能在未来几年内无法通过)，也没有详细的规范，因此每个实现的功能都可以被视为将交付客户端并在“实地”上测试的次要版本。当然，我们不需要1:1的Autocad，只是“很少的主要功能，如10%的整个产品的功能”。

这种论点对评估毫无帮助，相反，它意味着我们将有许多不确定的需求变化，比如“查看AutoCad的这个特性并实现它”，而由客户而不是专业的QA部门进行测试是(在政治上是白痴的同义词)。

有什么想法来解释和估计这样的任务吗？虽然有些数字会有所帮助，但大型项目的所有开发成本/细节都无法获得，但我只能在诸如Microsoft SDE的平均已知薪资和MS Office版本的时间表(即谈论Visio )等模棱两可的事实下操作。

Answer 1

这听起来像是一本书中的scrum方法论(http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf)的理想项目。

把这个项目想象成交付了一些小模块，每个模块都可以在它们完成后发布，并且每个模块都具有一定的商业价值。从业务中获得一个“产品所有者”，对模块进行优先级排序，并在您的团队中对它们进行评估。继续进行几次迭代；然后，当公司最终意识到这个项目是个坏主意时，他们实际上会有一些有用的东西，而不是有很多未完成的工作。

从迭代到迭代，您的估计将逐步改进，不久，您将对您的团队在每次迭代中能够完成多少任务有一个很好的感觉。