软件定制化需求到底该不该做？

    一直以来，市场端的软硬件定制化需求一直是较多的，除非你的产品足够强势，而往往很多细分行业，特别对口的软件产品，有，但是不一定多，因此定制化就来了。很多细分的行业的现状，懂业务的不懂软件开发，懂开发的不懂业务，当然不能一并而论，而是说大部分情况。因此基于项目型的业务容易出现以下共性的问题。

    1、客户的需求，往往概括的比较笼统。

    2、各种原因急于成交，希望做出更适合于客户的解决方案，在售前阶段就需要评估。

    3、无法去到现场进行深入调研。

    基于这种艺术和科学并存的背景，我们的项目经理或者产品经理很难理想化的根据项目范围和产品定位简单的答应或拒绝，也没有很明确的衡量标准，因此基于一些资料收集，以及从项目管理的角度，引发的对“该不该做”，“怎么做”的思考，希望能对后续定制化问题的讨论有所帮助。

    1、评估

    对于任何需求，存在即有存在的道理，因此我们应该先秉持从客户的角度来思考该需求，从以下几方面进行客观的评估

        战略契合：需求是否与产品战略冲突、是否符合规划？

        商业价值：通过落地需求方案，能直接、间接为公司带来多少增量收入？讲人话就是钱到位，且对产品不构成中长期负面影响，是否也可以做。

        覆盖人群：我们的客户群体，考虑有同样需求的用户，到底是什么量级？

        学习成本：提供的方案，对用户来说，是否能快速学会和易于上手；以及实现的效果是否满足大部分场景？

        研发成本：一个需求开发落地，所需要花费的时间、人力等成本？

        客户角度：如果需求跨方向，是否有更合适的方案？

    2、决策（做不做）

        做：其实基于前面的评估，我想应该是可以有个大概的结论。针对符合产品战略规划，又认为有商业价值等等积极的因素，那毋庸置疑。

        不做：作为产品研发相关人员，我们需要把评估的原则、不做的理由、事实依据等整理出来，以及该需求点是否有其他更合适、成本更低等也更好的方案？这样，我想，从客户、市场人员和产品研发 三方而言，都应该是一个相对合适的处理方式。

    3、怎么做？

        在确定做的前提下，可以简单分3种情况

        完全符合产品自身业务功能的完善，可以简单处理，定计划，基于优先级实现就好！

        对于部分符合的情况，拿我们近期一个定制需求来举例
        背景：是产品本身包含员工管理，人脸晨检数据
        需求：客户希望通过晨检做考勤
        这种情况下，我们的产品定位不是给人事、行政相关角色来使用，其次做考勤功能，客户会认为，不是改改就可以了吗？而实际上，一方面我们不是专业做考勤系统，术业有专攻，很难把这部分做的很优秀。另一方面，客户今天说统计考勤就好，下次基于此功能点衍生请假、审批、节假日设置、工资报表等等，就很容易出现需求蔓延，最终导致项目范围不可控而失败，得不偿失。因此，这种部分符合的需求，我们需要和客户明确需求范围，严格控制好范围才能承接。否则，应该建议客户使用专业考勤软件，才是最佳方案。    

        对于完全不符合的情况，那也简单，客户预算足够的情况，也能给到公司足够多的商业价值，那么和产品独立开来，做私有化的部署和开发即可，切记不要和产品线混为一谈就好，不能影响产品线。

    对于上述思考和表达，也还有很多考虑不全的地方，希望大家能够多批评指正，多提建议，让我们能够考虑的更完善，最终能够制定适合于自身情况的评估标准。