我正在尝试确定一些指示资源有限项目的标记。
以我的经验,一个项目变成了一个“资源有限”的项目,因为有人急于向客户出售解决方案。结果是预算紧张,功能被剔除,SDLC 流程被削减到最低限度。这些捷径被采用,因此公司有一定的机会获利甚至收支平衡。
这是我看到的与资源有限的项目齐头并进的事情清单:
- 分配给 QA 的最少时间
- 不合规格工作的严格官僚程序
- 变更请求预算可能很小或不存在
- 正式的流程被放弃,有利于利用时间进行开发
- 没有时间进行内容检查等增值质量检查(例如文本中的语法或拼写错误)。
- 不能为客户做任何内容管理或数据输入
- 必须寻求“足够好”的编码解决方案
- 走廊可用性测试没有时间限制。
- 没有编写用户文档或手册的预算。
- 编码前一般没有时间进行技术研究
- 没有时间制作风险分析文件
- 可以使用生产清单代替项目进度表。
- 程序员没有时间在项目进度表中填写他们的“实际”时间与估计时间。
- 提供给客户的进度更新可能不那么频繁或非常基本
- 可用于了解客户业务领域的时间更少
- 程序员可能不得不无偿加班。
- 没有时间分配给项目事后分析
有限资源项目还有哪些其他确定的迹象?
===
编辑
我会尝试用一个例子来消除一些混乱。这就是我的意思:给客户一份提案/报价,说他们的项目将花费 2 万美元。然后客户回来说“对不起,我的预算最高为 16,000 美元”。老板说“让提案 16,000 美元——我们想要这项工作”。
所以,实际上,你必须用比它应该有的更少的预算来做一个项目。有一些界限变得荒谬 - 如果客户说“我的预算是 4,000 美元”,那么你不可能做到。
是的,有时紧张的预算会变得如此愚蠢,以至于一开始就接受这个项目是一个糟糕的商业决定(即注定失败的项目)。
我知道没有预算不受限制的项目。业务人员通常会决定是否应开展项目(业务人员通常不是项目经理)。