做对
一句话，按照需求文档和复用已有的通用逻辑，既不多做功能，也不少做功能，那就可以把这个任务做对。
作为软件开发人员，基于产品交付的需求文档以及设计提供的视觉交互（静态）进行开发。一般来说，需求文档中包括该项功能的核心功能点，而其他的辅助功能以及交互是一笔带过，没有详细说明的必要。
在具体开发时，针对产品没有提到的部分，如果类似场景在其他业务中有出现过，那么，保持与其他的业务流程一致即可，这样，可以保证做对。
做好
一句话，做好是根据自己对该需求的理解，针对已有设计中不合理的地方提出建议，以及对需求中其他场景的优化提出合理建议，并经过同事一致讨论通过后，再继续开发工作。
做好是有代价的，由于好坏，可以从产品层面出发，也可以从开发层面出发，可以说，这两类改进是没有止境的，只要你肯下心思，总有地方可以改进的。但不能太过于钻牛角尖，为了改进而改进，存在有改进的地方，不代表就要马上动手去改进，也不代表要在这次修改中进行改进，要克制住写更多代码来证明自己的心态，代码不是越多越好，产品和工程的重构改进需要循序渐进。
当在新需求中未提及到的地方，当复用其他可复用的业务流程发现有更精简的流程，有就此向产品提出修改建议，将此建议抛到交流群中，由其他人来决定是否采纳这个建议，如果没有采纳，那么继续沿用旧的业务流程即可，不必对此太过上心，你没有最终决定权，提出建议就可以，不必为最后的冗余负责，完成功能，提出建议即可。
测试注意
在开发工作中，有修改的坑，掉进去很多次，在此总结下：
任何代码的修改，都要有依据，不管是产品的需求文档，还是基于软件优化的重构文档，保证业务代码改动的合理性和可追溯性，如果是底层代码修改，那更加要慎之又慎，这会牵一发而动全身，需要多次评审才能动手开发。
大部分公司还是业务驱动性的，测试是按照需求来对软件进行测试，不要少做需求里面要求的功能，更不能多做需求里面没提到的功能。只做必须要做的业务功能即可。
具体例子
下面举一个例子来说明产品需求对现有框架有影响时的做法：
当产品提出需要定制化颜色需求，而现有UI框架不能仅通过增加配置的方式来实现时，请问，你该怎么办？
方案一：现有UI框架支持固定几种模式的颜色配置，不支持其他模式下的配置，如果硬要支持产品此次的要求，需要修改部分框架代码和配置才行。技术可以以此为理由，不建议（拒绝）这个需求，要求产品按照现有框架配置模式来配置颜色。
方案二：技术通过分析发现，可以通过抽离出颜色配置接口，自定义关联关系的方式来实现该需求，修改部分框架代码来支持。
但就这个问题来说，方案一和方案二都是可行的。
但在具体实施时，要考虑到妥协了产品一次，后续产品可能还会提出其他定制化颜色的需求，而现有修改的灵活性不可能满足未来各种可能的变化，后续还是会有修改框架的情况，为了减少后续框架的改动，就此次修改后，开发需要已有框架能够支持的定制化方案，输出一份详细的配置方案出来，要求产品，以后的修改范围都圈定在此方案中，不要跳出之外，进行一些天马行空的需求。
在上述例子中，方案一和方案二，都是可以采取，后续对产品的约束，则是做好的例子。