对项目规划有何建议？
这本身不是一个编程问题，但它就是这样。我是一名计算机科学本科生，今年夏天我开始在一家中型软件公司实习。我以前做过一些自由职业，但这是我第一次正式（或多或少）受聘担任软件开发人员。
我被要求从头开始编写一个内部网站，以供公司中的不同团队使用，并且在设计它时我被赋予了很大的灵活性。问题就在这里：我们举行了几次会议和设计审查，每个人似乎都对新功能有自己的想法，甚至对于事情应该如何运作也存在相互冲突的想法。
到目前为止，我最初的原型已经度过了这一切，这是我被告知不要期望的事情 - 但我知道我有一个可靠的设计。虽然我没有落后于计划，但工作进展比我预期的要慢得多。这很大程度上与宽松的规格和不断的功能请求和变化有关。
我将在几周内部署一个阿尔法，我认为这不会是一个问题，但事情的进展方式我不确定这将如何进行。
有人有什么想法吗？ 提前致谢
This is not a programming question per se, but here it goes. I am a senior CS undergrad, and I started an internship this summer for a mid-sized software company. I've done a few freelancing jobs before, but it's the first time I've been officially (more or less) employed as a software developer.
I've been asked to code an internal website from scratch to be used by separate teams in the company, and I've been given a lot of flexibility in designing it. And therein lies the problem: we've had several meetings and design reviews and everyone seems to have an idea on a new feature, and even conflicting ideas on how things should work.
So far my initial prototype has survived all of this, which is something I was told not to expect - but I knew I had a solid design. While I am not behind schedule, the work is progressing significantly slower than I had predicted. A lot of this has to do with loose specs and constant features requests and changes.
I am to deploy an alpha in a couple of weeks, which I thought wouldn't be a problem, but the way things are going I am not sure how that's going to work out.
Does anyone have any ideas?
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您在问一个关于（软件）项目管理的永恒问题。有些人以撰写有关该主题的书籍为职业。
在这一点上我基本上同意 rockinthesixstring 的观点。
如果您没有一位有效的项目经理来过滤客户的请求并管理他们的期望，然后说“不”，那么这将必须成为您工作的一部分。
有时候，不说“不”是一门艺术。有时你可以这样说：“正如你在时间表中看到的，版本 1.1 将于下周进入 alpha。版本 1.2 的功能列表已经设置。我会将你的新功能添加到 1.3 列表的顶部。但是如果您愿意，我可以与其他团队召开会议，看看我们是否可以重新调整 1.2 功能的优先级。”
至于相互冲突的想法，如果没有其他“决定者”，那么这也成为你工作的一部分。
要明白，并不是每个人都会如愿以偿。
如果没有解决此类问题的方法，无论以何种标准衡量，您都不会取得成功。
You are asking a timeless question about (software) project management. There are careers made writing books on the subject.
I agree generally with rockinthesixstring on this.
If you don't have an effective project manager who can filter the customters' requests and manage their expectations, and say "no", then that will have to be part of your job.
Sometimes there is an art to not saying "no". Sometimes you can say it more like "As you see in the schedule, version 1.1 is going alpha next week. The feature list for version 1.2 is already set. I'll add your new feature to the top of the list for 1.3. But if you like, I can call a meeting with the other teams to see if we can reprioritize the 1.2 features."
As to conflicting ideas, if there is no other "decider", than that becomes part of your job as well.
Understand that not everyone will get their way.
Without an approach that addresses these sorts of issues you simply won't succeed by any measure.
我首先锁定已商定的功能，并将所有功能请求放入某种项目规划软件中（也许）。然后推出具有商定规格的 Alpha 版本，然后再转向“我们想要的”和“附加功能”。
I'd start by locking into the features that have been agreed upon and place all feature requests into some sort of project planning software (OnTime Perhaps). Then roll out the Alpha release with the agreed upon specs before moving onto the "we'd like" and the "bells and whistles".
您需要对功能请求进行优先级排序和分类，甚至可能是您已经同意的一些请求。
You need to prioritize and triage feature requests, possibly even some of the ones you have already agreed too.
听起来产品所有权并不明确（正如具有多个团队的内部项目所预期的那样）。您可能应该运行某种形式的计划游戏。如果您有多个利益相关者，您可以给他们每人 50 分，以便对迭代中的所有功能进行投票。
作为开发人员，您可以决定每个功能的大小。具有最多点/大小的特征进入迭代。如果某些球队更重要，就给他们更多的分数。您也应该自己花费一些积分。
It sounds like product ownership is not clear (as can be expected with internal projects with multiple teams). You should probably run some form of planning game. If you have multiple stakeholders, you might give them each 50 points to vote on all the features in an iteration.
You, as developer, decide how large each feature is. The features with most points/size get into the iteration. If some teams are more important, give them more points. You should also spend some points yourself.
我想表达我对詹姆斯·麦克劳德帖子的认可。任何人想要某个功能所需的唯一理由是“用户 x 可能会尝试......”。困难在于解决他们的观点与其他人的观点之间的矛盾。项目管理流程分配的具有较高“优先级”的功能将得到实施，必要时会牺牲其竞争对手的利益。让建议删除功能的人在纸上写下一些内容，解释该功能背后的原因以及他们认为可能会阻止其包含的情况。让其他人了解他们认为自己的方法有哪些局限性可以帮助打破决策僵局。案例描述得更彻底的功能“获胜”。
I would like to express my approval of James McLeod's post. The only justification anybody needs for wanting a feature is "user x might try to...". The difficulty is resolving contradictions between their opinions and somebody else's. The feature with a higher 'priority' as assigned by your project management process is the one that gets implemented, at the expense of its competitors if necessary. Ask the people suggesting features to go away and put something down on paper explaining the reasoning behind the feature and the circumstances they think might preclude its inclusion. Letting everybody else see what limitations they think their approach has could help break a decision deadlock. The feature whose case is stated more thoroughly 'wins'.