在收集需求之前估计增强请求
我在软件开发部门工作，该部门为我们所属的组织开发和维护内部软件。
有一个流程，业务用户可以提交对任何内部开发的解决方案进行增强的请求。用户填写模板并将其提交到电子邮件组以进行估算。
我遇到的问题是我们需要根据用户提供的信息提供估计。这些请求中包含的细节通常非常简单。这些请求在到达“估算论坛”之前没有经过任何过滤，也没有对其进行质量控制。负责提供估算的人员是所有致力于当前项目和增强功能的开发人员。
我的问题是其他内部软件开发部门如何处理增强请求？或者，有谁知道解决这个问题的“最佳实践”方法？
I work in a software development department that develops and maintains in house software for the organisation we are part of.
There is a process where business users can submit requests for enhancements to any of in-house developed solutions. The user fills in a template and submits it to email group for an estimate to be done.
The problem I have is that we are expected to provide an estimate based on the information supplied by the user. The level of detail contained in these requests is usually very light. There is no filtering of these requests before they reach the "Estimates Forum", and there is no quality control on them either. The people responsible for providing estimates are developers who are all working on current projects and enhancements.
My question is how are enhancement requests handled at other internal software development departments? Or, does anyone know of a "best practice" approach for this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您能做的最好的事情就是向他们提供最小和最大范围，您可以在获得更多信息后对其进行修改。确保范围足够大以包含最终估计。
The best you can do is to provide them with a minimum and maximum range which you revise as you get more information. Make sure the range is large enough to include the final estimate though.
保留 2 次迭代。
第一个具有 +/- 20% 方差（几乎总是 + ），然后根据反馈或最终要求、进一步分析等，您需要更多时间才能获得更准确的最终估计。
如果是开发人员估计，一般趋势是低估（总是 2 天的时间） - 所以然后在顶部添加一个缓冲区。
Keep 2 iterations.
The first one with a +/- 20% variance (almost always + ) and then based on feedback or final requirements, further analysis etc you take more time to get back with the final estimates which are more accurate.
If it's developers estimating, the general tendency is to under estimate (it's always 2 days time) - so then add a buffer on top.