Explain the situation to the manager, let him decide. That's why he's there.
If you're in charge, then you need to consider all possibilities. I'd say, focus on what the customer will need in the first turn, and complete the second-priority functionality afterward. If possible, talk to them, explain and try to reach an agreement. The customer may have a different opinion on what he will need the most and give you direction to focus your efforts in.
Whichever is better for a customer/business. If it's possible to have all 7 "feature" in semi-complete state -- then go for it. If they prefer 3 polished "features", go this way.
Are the modules really independent? Are they really needed in full, or can they provide value even if implemented partially?
A useful strategy is to implement vertical slices accross the system or even a module, not horizontal layers of modules. Implement one end-to-end feature/use case/user story at a time. It is these features that bring value to your customer, not modules (unless the customer is an odd one valuing modules and not features). This way you get something useful ready for testing and release, and your time is not spent on writing code that is not used by anyone. However, when adding new features, you need to keep on refactoring the codebase in order to avoid the stovepipe system anti-pattern.
In any case, implementing the 7 modules only halfway there is not the answer. Whatever you do, do it right the first time. ("Right" being of course context-dependent: different standards apply for throwaway prototypes, life-critical production code and everything in between.)
That very much depends on your development model and the customer requirements. In an agile environment I'd rather show the complete product (even with unfinished/mocked parts), so the customer gets an impression of it in its entirety and can give you early feedback on the unfinished modules.
If there are clear, precise specs however, then delivering the 3 finished modules is probably a better idea.
Client has a clear picture of exactly what he wants, and my job is to show him something that will attract his attention and give me additional time to complete the project. Each module requires one month of work, but after three months the client decides whether to continue the cooperation or not. The user interface is the only thing that interests him. I can not explain to him that I spent two months making engine if he does not see it on the screen.
发布评论
评论（6）
向经理说明情况，让他决定。这就是他在那里的原因。
如果你是负责人，那么你需要考虑所有的可能性。我想说的是，首先关注客户需要什么，然后完成第二优先的功能。如果可能的话，与他们交谈、解释并尝试达成协议。客户可能对他最需要的东西有不同的看法，并为您提供集中精力的方向。
Explain the situation to the manager, let him decide. That's why he's there.
If you're in charge, then you need to consider all possibilities. I'd say, focus on what the customer will need in the first turn, and complete the second-priority functionality afterward. If possible, talk to them, explain and try to reach an agreement. The customer may have a different opinion on what he will need the most and give you direction to focus your efforts in.
无论哪一个对客户/企业更好。如果有可能让所有 7 个“功能”处于半完整状态——那就去做吧。如果他们更喜欢 3 个精美的“功能”，就走这条路。
Whichever is better for a customer/business. If it's possible to have all 7 "feature" in semi-complete state -- then go for it. If they prefer 3 polished "features", go this way.
这取决于您的客户的价值观。
模块真的是独立的吗？它们真的需要全部，还是即使部分实施也能提供价值？
一个有用的策略是在整个系统甚至一个模块中实现垂直切片，而不是模块的水平层。一次实现一个端到端功能/用例/用户故事。正是这些功能为您的客户带来了价值，而不是模块（除非客户是一个重视模块而不是功能的奇怪客户）。这样，您就可以为测试和发布做好准备，并且您的时间不会花在编写不被任何人使用的代码上。然而，在添加新功能时，您需要不断重构代码库，以避免stovepipe系统反-模式。
无论如何，仅仅半途而废地实施这 7 个模块并不是解决问题的办法。无论你做什么，第一次就做对。 （“正确”当然取决于上下文：不同的标准适用于一次性原型、至关重要的生产代码以及介于两者之间的所有内容。）
It depends on what your customer values.
Are the modules really independent? Are they really needed in full, or can they provide value even if implemented partially?
A useful strategy is to implement vertical slices accross the system or even a module, not horizontal layers of modules. Implement one end-to-end feature/use case/user story at a time. It is these features that bring value to your customer, not modules (unless the customer is an odd one valuing modules and not features). This way you get something useful ready for testing and release, and your time is not spent on writing code that is not used by anyone. However, when adding new features, you need to keep on refactoring the codebase in order to avoid the stovepipe system anti-pattern.
In any case, implementing the 7 modules only halfway there is not the answer. Whatever you do, do it right the first time. ("Right" being of course context-dependent: different standards apply for throwaway prototypes, life-critical production code and everything in between.)
完成 3 项。
然后可以将它们发布给客户端进行测试，然后您可以开始处理其他 4 项。
Complete the 3.
Then they can be released for testing to the client, and you can get to work on the other 4.
这在很大程度上取决于您的开发模型和客户需求。在敏捷环境中，我宁愿展示完整的产品（即使有未完成/模拟的部件），以便客户对其有完整的印象，并可以为您提供有关未完成模块的早期反馈。
然而，如果有明确、精确的规格，那么交付 3 个成品模块可能是一个更好的主意。
That very much depends on your development model and the customer requirements. In an agile environment I'd rather show the complete product (even with unfinished/mocked parts), so the customer gets an impression of it in its entirety and can give you early feedback on the unfinished modules.
If there are clear, precise specs however, then delivering the 3 finished modules is probably a better idea.
客户清楚地知道他想要什么，而我的工作就是向他展示一些能够吸引他注意力的东西，并给我更多的时间来完成项目。
每个模块需要一个月的工作时间，三个月后客户决定是否继续合作。
用户界面是他唯一感兴趣的东西。如果他没有在屏幕上看到它，我无法向他解释我花了两个月的时间制作引擎。
Client has a clear picture of exactly what he wants, and my job is to show him something that will attract his attention and give me additional time to complete the project.
Each module requires one month of work, but after three months the client decides whether to continue the cooperation or not.
The user interface is the only thing that interests him. I can not explain to him that I spent two months making engine if he does not see it on the screen.