如何在稀缺规范的项目中竞争，以免团队死亡 [英] How to compete on a scarce spec'd project to avoid team death-march

问题描述

我要花费时间和成本来估算一个半复杂的软件解决方案，该解决方案在大约75％的功能中没有特定的要求。我仍然想通过从客户端获取其他数据来做出尽可能好的估算。由于对其他产品/技术的依赖过多以及缺乏定义，因此仍有某些部分最终可能无法开发。我也有一个很紧的时间表来产生这个估计。

I'm time+cost estimating a semi-complex software solution, that hasn't got specific requirements in about 75% of features. I would still like to make as good estimate as possible, by getting additional data from the client. There will still be parts that may end up not being able to develop, since there's too many dependencies with other products/technologies and lack of definition. I also have a very tight schedule to produce this estimate.

该项目还将有其他竞争者。客户期望 price + duration （可能还有功能），而且我知道每个人都会离开。我知道这是不可能的，但要告诉行销人员。另一个问题是，我是在与中间人交谈，而不是直接与客户交谈。 我只能对中间人有信心，而对决定性的客户则不能。这是一个完全不同的问题。

There will also be other contenders on this project. Client expects a price+duration (and probably also features) and I know everyone will be off. I know that's impossible, but tell that to marketing people. Another problem is that I'm talking to middle-man and not directly to the client. I can get confidence with middle-man only, but not with the deciding client. Which is a different problem altogether.

免责声明/信息我可以在这个计划中加入价格计划/合同而不是 kill 团队吗，所以当项目开始下滑时（就成本/时间/功能而言），我们将获得某种付款。我当然希望通过与时间有关的冲刺或发布来获得报酬，但是我怀疑客户是否可以相信这一点。我确定我们可以在截止日期之前完成此产品并创造出出色的产品，但是我如何劝服客户相信我？

What disclaimer/info can I put in my price plan/contract not to kill team with this project, so when project starts slipping (in terms of cost/time/features) we will be covered with some sort of payment. I would of course like to be paid by sprints or releases with relation to time, but I doubt client could be convinced in this. I'm sure we can finish this product before deadline and also create a great product, but how can I convice client to believe me?

我该怎么做才能获得这个项目并同时避免行军情况？

What can I do to get this project and avoid death march situation at the same time?

欢迎任何建议！

最后，我们（我和我的同事）说服了客户，我们至少需要一周的时间来评估产品。我们做到了。我们还推动（并安排了）与客户见面的时间长达数小时，以澄清任何未解决的需求问题。我们做到了。会议是在我们制定第一份估算草案之后进行的，因此我们确定我们有所有问题来指出那些被完全误解或过于模糊而无法估算的细节。我希望我们得到这个项目，因为这对我们意味着8个月的全职工作，加上合理的薪水。我们将在大约一周半的时间内知道。

In the end we (me and my co-worker) convinced the client we need at least a week to evaluate the product. So we did. We also pushed (and got) a slot for a few hours long meeting with the client to clarify any outstanding requirements' questions. So we did. Meeting was done after we made the first estimate draft, so we were sure we have all the questions to point out specifics that were either completely misunderstood or too vague to estimate. I hope we get the project, because it would mean 8 months of full time work for us, plus a reasonable pay. We'll know in about a week and a half.

当然，我也指出，我们交付该产品的方式将使他们准确地到达他们想要的地方与实际上将是他们想要的产品一起使用。而且我们只承诺价格和时间，而不承诺功能，因为它会并且随时可能更改。我认为我们给人留下了很好的印象。

Of course I also pointed out that the way we'll be delivering this product will get them exactly where they want to be with a product that will actually be what they wanted. And also that we only commit to price and time, but not functionality, because it is and will be subject to change. I think we made a good enough impression.

推荐答案

欢迎来到固定价格开发服务的世界：-）

Welcome to the world of fixed priced development services :-)

同时赢得该项目并避免死亡行军的技术：

Techniques for to win this project and avoid death march situation at the same time:

• Don没有承担一个项目。竞标您认为该项目将要采取的措施，并为可能出错的地方增加一些百分比。


• 如果您遗漏了75％的详细信息，则该项目与您当前期望的。在定义的工作大纲中记录一些合理的详细假设。当项目真正开始且细节与假设不符时，您就有机会就更改费用进行谈判。到那时，您可能还可以更好地了解自己的资产过高/不足，并尝试用此报价进行补偿。


• 您在SOW（工作陈述）中的目标应该是定义足够的详细信息，以便在您对项目有了更多了解时就可以重新谈判变更成本。尽可能多地将它们写成肯定的。请注意，真正了解项目的人不太可能会阅读或理解SOW ...我基于这一点给出的详细信息很少。这意味着这不是协商销售，而且任何一方都没有真正致力于构建正确的解决方案。


• 如果您能以T& M（时间和材料）的优势获得合同， 。我怀疑您是否会获得它或无法获得它而没有一些限制，这些限制实质上会破坏T& M的目的。您的潜在客户会接受此风险，因为他们接受了与您能力有关的所有风险。


• 希望您不是公司中第一个这样做的人。从历史上了解项目的进展情况和典型的成果率。许多软件开发小组收取的小时费率明显高于成本……但他们的报价往往较低，而不是实际小时数。客户通常会争论小时/天数而不是实际报价。企业通常习惯于支付高时薪。


• 计算出部门的预期利润率（您需要从工作中获得的利润）。这样可以帮助您了解项目滑坡时可能要面对的死亡大军。


• 在SOW中，在您指定规格之前需要详细的级别开始工作。尽管敏捷和其他以客户为中心的流程采用的是寻找最佳解决方案的方法，但它们的目的并不是在固定的出价环境中控制成本。您将需要采用瀑布式方法来满足需求，然后以敏捷的方式进行构建，以便您可以一路调整。像SOW一样，该规范将使您有机会为更改付费。尽管客户会不喜欢这样，但这将使与需求相关的负担和风险对他们而不是对您的团队。

• Don't underbid a project. Bid for what you think the project will take and add some percentage for things likely to go wrong.
• If you are missing 75% of the detail, odds are the project will be significantly different than you currently expect. Document some reasonable detail assumptions within the outline of the defined work. When the project actually starts and the details don't match the assumption, you have an opportunity to negotiate the costs for the changes. At that time, you may also be in a better position to know how much you are over/under and attempt to compensate with this quote.
• Your goal in an SOW (statement of work) should be to define enough details so that it gives you an opportunity to renegotiate the cost of changes when you know more about the project. Write these as positives, as much as possible. Note, it is unlikely that people that actually understand the project will read or understand the SOW...I base this on the point that you are given few details to quote. This means it isn't a consultative sale and neither party is really focused on building the 'right' solution.
• If you can get a contract as T&M (time and materials) great. I doubt you'll get it or unable to get it without some restrictions that essentially defeat the purpose of a T&M. Your potential customers look at this as them accepting all of the risks around your abilities.
• Hopefully, you aren't the first at your company to do this. Find out, historically, how projects have been and the typical result rates. Many software development groups charge an hourly rate that is significantly higher than cost...but their quotes tend to be lower and not actual hours. Customers often will argue more about the hours/days than the actual quote. Enterprises tend to be used to paying high hourly rates.
• Figure out your department's expected margin (profit you need to gain from the job). This may help you to understand how much of a 'death march' you may face when your project slips.
• In the SOW specify the level of detail that will be required in a specification before you begin work. While Agile and other customer focused processes take an approach that oriented at finding the best solution, they aren't designed to keep costs under control in a fixed bid environment. You will need to take a waterfall approach to requirements and then build in an agile fashion so that you can adjust along the way. The specification, like the SOW, will give you an opportunity to bill for changes. While the customer won't like this, it will put the burden and risks associated with requirements on them and not your team.

注意，要在这些谈判中取得成功，您需要一支支持管理，销售和项目管理团队。如果没有这些，那么您肯定会一直处于死亡征途。即使您放弃质量，过程，测试和其他项目，您也会发现没有足够的时间来进行项目。

Note, to be successful with these negotiations, you needs a supportive management, sales and project management team. If you don't have that, you are bound to always be on 'death marches.' Even if you forgo quality, process, testing and other items, you'll find there's never enough time for a project.

这篇关于如何在稀缺规范的项目中竞争，以免团队死亡的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！