这是正常的发展程序吗?

每个组织都是不同的。如果他们以这种能力运作,那么你应该适应并充分利用这种情况。这要么是因为事情就是这样做的,而且他们知道,要么他们不知道更聪明,要么不想投资来改进交付战略/战术项目的过程。

在一个完美的世界里,每个人都将拥有一个强大的质量方法论,它将为项目交付和系统实现提供一个框架。这不是现实。

以下是一些帮助您更有效地操作的提示:

• 确定你的赞助人(拥有产品的人),并确定他们寻求解决的业务问题的高级利益和驱动目标。
• 确定你的利益相关者(谁有影响力,谁有兴趣),让他们尽可能地传达他们的需求。
• 尽可能或尽可能多地让赞助商和利益相关者参与这一过程。
• 通过书面形式(电子邮件)获取您可以从中获得的需求
• 提供机会让他们了解交付情况并提供反馈

你所描述的肯定性不是最佳的,但它非常常见,尤其是在小商店。有些人认为在这种环境下工作是值得的。这不是软件工程书籍所教的,但这就是为什么有这么多软件工程书籍的原因。

如果你想继续在这样的环境中工作,你必须提供所有你正确认识到的纪律,那就是失去你自己。写一个规格。制定一个时间表。与你的管理层分享这些。坚持到最后期限。

与你的管理层分享你的顾虑;不要害羞。他们很有可能认识到这种情况。你老板不检查你的进度?向他公布你的进展。告诉他你需要去哪里,你走了多远,什么阻碍了你。

毫无疑问,这会很混乱,但你会学到很多。

从你老板的角度看,你的项目很可能会失败。因为我相信你开发的程序不适合他。但你不会感到内疚。这是你老板的痛苦。(因为你是个好程序员)。对不起,这么黑的帖子:—)。

项目经理的角色不在于了解技术,但可以说,他们绝对应该掌握项目的脉搏。真正的项目管理工作不是控制项目,而是 使可能 它。不管怎样,从你的描述来看,你的工作做得不太好。

另一个极端是一个过程繁重的组织,会议和委员会决定一切,所有真正的交流,如果有的话,都是通过边渠道进行的。

理想世界介于两者之间。

你的项目经理不应该 太 关心你在做什么。因为他们没有资格,他们能做的最好的就是把你和一个有资格的人联系起来。当他们不能证实你是在正确地建造它时,他们至少应该确保你是在建造正确的东西。即使是内部使用,你仍然有一个客户,没有与客户的沟通对我来说是坏消息。:)

如果你的首相不关心这个问题,你可以试着自己做点什么。例如,请PM将您与应用程序的最终用户连接起来。提取应用程序中的一些片段,并将它们交给用户使用——只需确保您提供的片段不会看起来或感觉太过完整。

如果你不能改变,就把这当作一次学习经历。确保下次你开始一个项目的时候,你知道上次出了什么问题,并且从一开始就试着减轻它们。

最后,如果你的老板告诉你这是一种“更敏捷的工作方式”,那就给他们一拳。敏捷是 应该 是,与纪律同义,不是完全缺乏纪律。

祝你好运!

这是一个艰难的处境。只有你才能真正确定最佳的继续方法。然而,我确实认为,对进度和同时缺乏文档(需求、期望、用例场景文档等)的关注是一个等待发生的火车事故。即使是最敏锐和最有经验的开发团队也会遇到同样的问题。

“什么时候做?”通过定期提供小的部分功能构建,您可以使用它们从移动目标(即您的客户)中获取有用的信息,从而最好地缓解问题。令人惊讶的是,当某人(你的老板/客户/最终用户)能够在他们面前“玩弄”一些东西并重新考虑他们真正想要的东西时,交流能发生多少。