产品的负债（设计/技术负债）及解决思路

       在负责多个功能模块及接手一个业务线以后，开始发现一些状况而且发现这种问题不是只有我这有，而是整个公司，各个业务线都存在的共同问题。简单描述下发现的问题：

       A、旧的功能模块须要人工去运营，可是又没有专门的内部系统运营团队，结果作越多功能模块，这种运营维护工做量（业务/技术咨询、推广使用等运营工做）就越多，致使新的项目开展效率降下来；

       B、旧的功能模块设计存在缺陷或者不完善，而后新的项目又不断开始，结果旧的功能产生问题时占用新项目的资源去修复维护，功能模块越多这种维护工做量越大，最终陷入维护工做里面，没有时间再去作新的功能，明明作了不少东西，可是产出却没有。

       分析过产生以上两种问题，陷入这种“陷阱”里面的缘由，主要有如下：

       A、产品设计质量问题：设计存在不灵活存在比较多特殊逻辑、场景/业务流程不完善、没有考虑运营工做的问题、角色界定不清晰（管理与普通角色混在一块儿），产品设计自己就须要比较大的运营工做量在里面，主要是这些问题致使；

       B、业务部门的压力问题：业务部门有业务部门自身的压力，他们必然须要将这种压力转移到研发部门来承受，因此就会压研发部门的研发周期，甚至控制研发部门的项目等；

       C、研发质量问题：当时接手业务线后不久，发现团队的开发人员存在问题，开发人员只是将问题掩盖而已，没有从根本上去解决问题，因此问题反反复复发生，同时也反反复复占用资源，这种问题最为严重；

       D、项目实施质量问题：当时接手那业务线，一来没有比较完善的工做制度流程，工做很随意，想作就作不想作就不作，需求评审不深，技术监督也少，测试跟进也不足；

       项目或者产品存在问题，不管是谁的问题，最终问题都是产品，由于设计是产品（该公司没有独立的需求分析师），与业务部门沟通是产品，主导项目进程质量也是产品（该公司没有独立的项目经理），带领团队也是产品经理该作的事情，因此上面的问题深层次是产品对整个项目的把控问题。

       因此解决方案也是很是明显：

       A、逐步创建规范的项目管理制度：该评审的仍是要评审，经过工具在线上管理项目过程，以文档为主要沟通及承载工具而不是口头，避免推卸责任；

       B、提升产品人员的要求：当时我接手那组，我是负责整组的统筹工做，下面还有几位产品专员，提升产品人员对细节、质量的要求，要求产品人员亲自去测试作出来的东西，而且提出优化意见，监控产品完成质量，减小问题产生；

       C、规范业务部门的提需求工做：当时业务部门很深度介入到研发的工做里面，直接对开发人员进行工做安排，当时我打断这种沟通而且根据每季度能完成的工做量，跟业务部门肯定季度工做计划，计划内的咱们会按计划作，计划外的，请排队；

       D、梳理旧系统问题，腾空资源优化严重问题：由于规范了与业务部门的工做对接，能够腾空必定量的资源出来对旧有功能进行优化，对产生比较多人工介入、维护的问题，进行优化，像增长运营后台、修复系统漏洞减小问题产生；

       E、对有问题的开发人员进行沟通并监控工做完成状况，若是多次不改，则辞退、更换新的成员：这个问题无法妥协，由于一旦妥协了，整个团队都会跨了，并且实在是占用太多资源去修正他埋下的问题，他作越多，问题就越多，还不如处理掉这种员工；

       F、工做从新划分：以前他们的工做习惯是一个团队所有人作一个项目，后来我将模块、负责团队划分了下，虽然人很少，可是划分红2批，一批负责完善旧系统，一批负责新项目。这样能够确保完成业务部门需求，同时修正旧功能，而后每一个团队新旧项目交替进行，这样避免一个团队老是作旧的功能，对此产生不满。

       从上面的工做安排，其实都是对于人的工做进行从新的划分，这个须要产品经理牵头去作，由于产品人员自己就是负责整个团队的牵头做用。

       最后大概花了一个季度，基本处理干净一些浅层的问题，而后大概花了一个季度去规范工做、处理深层次历史问题，一共花了2个季度的时间，才能完全让整个团队的工做氛围、文化改变过来，而后后面就很是顺畅的产出新的项目，新的功能模块，整个团队再也不像之前每天在那修bug处理数据，都作这些事情的目的在哪。