blocks|key|433020|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|433021|开发人员通常应该进行初步估计。管理者应该能够根据实施人员的不同向其添加风险因素。(例如:如果实现它的开发人员比给出估计的开发人员有更好的知识，风险将会更低)。开发人员也可能对项目的其他开发领域没有概念(假设其规模巨大)。这就是管理者的估计出现在画面中的地方。如果项目很小，那么开发人员的估计就足够好了。|ordered-list-item|433022|433023|entityMap^0|0|0|0^^$0|@$1|2|3|-4|4|5|6|G|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|H|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|I|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|J|7|@]|8|@]|9|$]]]|F|$]]

<ol>
<li>Developers generally should make the initial estimate. The Manager should be able to add a risk factor to it depending on who implements it. (for example : If the developer implementing it has a better knowledge than the one who gave the estimate, the risk would be lower).
The developer also may not have an idea on the other development areas of the project(assuming its huge). This is where a Manager's estimate comes into picture. IF the project is small then a developer estimate is good enough.</li>
</ol>

blocks|key|433131|text|负责签署评估的人实际上应该是项目经理。这是他们的利基。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|433132|然而，我并不是说PM应该弥补这些估计。|433133|我的意思是，项目经理将需要从各种来源--技术、业务等--对项目的不同部分进行评估。在任何项目中，都会有大量的非技术性部分。|433134|任何技术性的东西都应该由技术人员来评估。|433135|但是，出于同样的原因，任何非技术性的东西都应该由适当的专家来估计(注册会计师类型将这些中小企业称为主题专家)。架构师可以评估技术解决方案。A+BA差距分析。经理可以执行业务流程实现。诸若此类。|433136|但是，PM确实需要将所有这些结合在一起，形成一个高级别的估计，特别是在资源分配和确定相互依赖关系和关键路径方面。|433137|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

The person responsible for signing off of an estimate should really be the project manager. That's their niche.

I'm not saying that PMs should make up the estimates however.

I'm saying that the PMs will need to take estimates from a variety of sources--technical, business, etc--for different parts of the project. In any project there'll be large parts that aren't technical.

Anything technical should be estimated by someone technical.

But, by the same token, anything non-technical should be estimated by an appropriate expert (CPA types call these SMEs--subject matter experts). An architect could estimate the technical solution. A BA the gap analysis. A manager could do the business process implementation. And so on.

But a PM is really needed to tie all those together into a high level estimate, particularly in terms of resourcing and working out the interdependencies and the critical path.

blocks|key|433181|text|我认为这取决于作品的内容。很多时候，项目经理非常有能力估计需要多长时间，比如在屏幕上添加一些额外的数据、更改布局等等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|433182|然而，有时事情会变得更加复杂，特别是当它们深入到系统架构的时候。在这种情况下，项目经理应该咨询开发人员、架构师或两者，以了解他们的估计，以及为什么要花费特定的时间来实现。|433183|此外，我认为项目经理应该使用开发人员的估计来获得最终估计，就像schar说的那样。他们应该添加一定百分比的开销、测试时间、风险因素等。|433184|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I think it depends on the piece of work. A lot of times the project manager is more than capable to estimate how long it would cost to say, add some additional data on screen, change layout, you name it. 

However, there are times when things are more complicated, especially if they deeply touch the architecture of the system. In that case, the project manager should consult the developer, architect, or both for their estimate, and exactly why it takes that particular time to implement.

Moreover, I think project managers should use a developer's estimate to get to the final estimate, like schar says. They should add a percentage of overhead, test time, risk factors, etcetera.

blocks|key|3653198|text|我以管理者(现在)和开发者(过去)的身份回答这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3653199|高级评估应该来自团队/项目负责人，但要有来自开发人员的输入。它们也应该以范围的形式给出-最有可能是最坏的情况，并指示每种情况的置信度。|3653200|团队领导不可能充分深入地了解项目的所有内容，因此他们需要开发人员的一些输入，但这样做的危险在于，您在过程的早期就陷入了细节的泥潭。同样，单个开发人员也不会对项目有足够广泛的了解(除非它真的很小)，无法给出对所有项目的估计。|3653201|然后，经理整合这些估计，并寻找冲突和协同效应，以获得“大图景”-毕竟这就是我们获得报酬的原因。|3653202|作为一名开发人员，我不会信任一个没有与开发人员核实就给出估计的经理，但同样，我也不会信任一个只是询问开发人员并将信息传递出去而没有以某种方式“编辑”它的人。|3653203|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I'm answering this as both manager (present) and developer (past).

High level estimates should come from the team/project leader, but with input from the developers. They should also be given in the form of a range - most likely to worst case with an indication of the confidence level of each.

There's no way the team lead can know everything about the project in sufficient depth so they will need some input from the developers, but the danger with this is that you get bogged down in the details too early in the process. Equally, individual developers will not have a broad enough knowledge of the project (unless it's really small) to be able to give estimates on everything.

The manager then integrates these estimates and looks for conflicts and synergies to get the "big picture" - after all that's what we're paid for.

As a developer I wouldn't trust a manager who gave estimates without checking with the developers, but equally I wouldn't trust one who just asked the developers and passed that information on without "editing" it in some way.

blocks|key|3653281|text|每个人都应该给项目经理一个估计:功能分析师，测试分析师和高级开发人员。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3653282|项目经理的任务是确保它们在某种程度上是现实的，并对它们进行总结。|3653283|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Everyone should give an estimate to the project manager: functional analysts, test analysts and the senior developers.

It's the PM's task to make sure they are somewhat realistic and to sum them up.

blocks|key|3653312|text|我以管理者(现在)和开发者(过去)的身份回答这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3653313|在我们公司，开发人员总是参与进行评估。我们对业务顾问创建的用户故事进行高级评估。|3653314|业务顾问将用户故事传达给我(技术团队经理)和开发人员。|3653315|我们安排一个评估会议来讨论用户故事和项目的上下文(三个人，业务顾问，开发人员，技术经理)。在会议中，我和开发人员都会做笔记，并记下每个用户故事所需的时间。|3653316|会议结束后，开发人员填写了一份估算表，我们确保双方都同意这个估计表。完成后，评估表将返回给业务顾问。|3653317|通常，高级估计将在x到x乘以3天的范围内给出。|3653318|例如:+40到120天。|3653319|显然，我们只估算了所需的开发/测试/部署时间。项目管理和技术管理、风险和间接费用将增加X百分比。|3653320|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

I'm answering this as both manager (present) and developer (past).

In our company developers are always involved in making estimations. We do high-level estimates on user-stories created by a business consultant.

The business consultant communicates the user-stories to me (technical teammanager) and a developer. 

We schedule an estimation meeting to discuss the user-stories and the context of the project (three people, business consultant, developer, technical manager). Within the meeting both me and the developer make notes and write down needed hours per user-story.

After the meeting the developer fills out an estimation form and we make sure we both agree on that estimation. When finished the estimation form goes back to the business consultant.

Usually a high level estimation will be given in a range from x to x times 3 days.

For example: 40 to 120 days.

Obviously we only estimate development/test/deployment time which is needed. X percentage will be added for project management and technical management, risks and overhead.

blocks|key|4498705|text|敏捷的半开玩笑的回答是:没有人应该这样做，因为它无论如何都是大错特错的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4498706|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The tongue-in-cheek Agile answer is: nobody should, because it will be wildly wrong anyway.

I've just come from a discussion about who is best placed to give estimates on a given piece of work.

At a detailed level I'd always say that the best estimate comes from the person who actually has to do the work as they have the full understanding and this gives them complete buy-in to the , however at a higher level of abstraction (i.e. at overall project level) I'm not so sure.

I'm reminded of chapter 5 in Peopleware which gives the results of an Australian study from 1985 - best link I could find is <a href="http://javatroopers.com/Peopleware.html#Chapter_5" rel="nofollow noreferrer">here</a>.

I'm particularly interested in your focus here - are you answering as a developer, architect, prject manager or whatever?

Who should give high-level project estimates?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我刚刚参加了一次讨论，讨论谁最适合对一项给定的工作进行评估。在详细的层面上，我总是说，最好的估计来自于实际必须做工作的人，因为他们有充分的理解，这让他们完全接受，但是在更高的抽象层面(即在整体项目层面)，我不是很确定。我想起了Peopleware中的第五章，其中给出了1985年一项澳大利亚研究的结果--我能找到的最好的...

问谁应该给出高级别的项目评估？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问谁应该给出高级别的项目评估？EN