在负责多个功能模块及接手一个业务线之后，开始发现一些情况并且发现这种问题不是只有我这有，而是整个公司，各个业务线都存在的共同问题。简单描述下发现的问题：
A、旧的功能模块需要人工去运营，但是又没有专门的内部系统运营团队，结果做越多功能模块，这种运营维护工作量（业务/技术咨询、推广使用等运营工作）就越多，导致新的项目开展效率降下来；
B、旧的功能模块设计存在缺陷或者不完善，然后新的项目又不断开始，结果旧的功能产生问题时占用新项目的资源去修复维护，功能模块越多这种维护工作量越大，最终陷入维护工作里面，没有时间再去做新的功能，明明做了很多东西，但是产出却没有。
分析过产生以上两种问题，陷入这种“陷阱”里面的原因，主要有以下：
A、产品设计质量问题：设计存在不灵活存在比较多特殊逻辑、场景/业务流程不完善、没有考虑运营工作的问题、角色界定不清晰（管理与普通角色混在一起），产品设计本身就需要比较大的运营工作量在里面，主要是这些问题导致；
B、业务部门的压力问题：业务部门有业务部门自身的压力，他们必然需要将这种压力转移到研发部门来承受，所以就会压研发部门的研发周期，甚至控制研发部门的项目等；
C、研发质量问题：当时接手业务线后不久，发现团队的开发人员存在问题，开发人员只是将问题掩盖而已，没有从根本上去解决问题，所以问题反反复复发生，同时也反反复复占用资源，这种问题最为严重；
D、项目实施质量问题：当时接手那业务线，一来没有比较完善的工作制度流程，工作很随意，想做就做不想做就不做，需求评审不深，技术监督也少，测试跟进也不足；
项目或者产品存在问题，无论是谁的问题，最终问题都是产品，因为设计是产品（该公司没有独立的需求分析师），与业务部门沟通是产品，主导项目进程质量也是产品（该公司没有独立的项目经理），带领团队也是产品经理该做的事情，所以上面的问题深层次是产品对整个项目的把控问题。
所以解决方案也是非常明显：
A、逐步建立规范的项目管理制度：该评审的还是要评审，通过工具在线上管理项目过程，以文档为主要沟通及承载工具而不是口头，避免推卸责任；
B、提高产品人员的要求：当时我接手那组，我是负责整组的统筹工作，下面还有几位产品专员，提高产品人员对细节、质量的要求，要求产品人员亲自去测试做出来的东西，并且提出优化意见，监控产品完成质量，减少问题产生；
C、规范业务部门的提需求工作：当时业务部门很深度介入到研发的工作里面，直接对开发人员进行工作安排，当时我打断这种沟通并且根据每季度能完成的工作量，跟业务部门确定季度工作计划，计划内的我们会按计划做，计划外的，请排队；
D、梳理旧系统问题，腾空资源优化严重问题：因为规范了与业务部门的工作对接，可以腾空一定量的资源出来对旧有功能进行优化，对产生比较多人工介入、维护的问题，进行优化，像增加运营后台、修复系统漏洞减少问题产生；
E、对有问题的开发人员进行沟通并监控工作完成情况，如果屡次不改，则辞退、更换新的成员：这个问题没法妥协，因为一旦妥协了，整个团队都会跨了，而且实在是占用太多资源去修正他埋下的问题，他做越多，问题就越多，还不如处理掉这种员工；
F、工作重新划分：之前他们的工作习惯是一个团队全部人做一个项目，后来我将模块、负责团队划分了下，虽然人不多，但是划分成2批，一批负责完善旧系统，一批负责新项目。这样可以确保完成业务部门需求，同时修正旧功能，然后每个团队新旧项目交替进行，这样避免一个团队总是做旧的功能，对此产生不满。
最后大概花了一个季度，基本处理干净一些浅层的问题，然后大概花了一个季度去规范工作、处理深层次历史问题，一共花了2个季度的时间，才能彻底让整个团队的工作氛围、文化改变过来，然后后面就非常顺畅的产出新的项目，新的功能模块，整个团队不再像以前天天在那修bug处理数据，都不知道在干嘛。
其实解决方案都是根据具体情况来定的，不过有个原则：从源头，产品人员身上去解决问题。从上面的工作安排，其实都是对于人的工作进行重新的划分，这个需要产品经理牵头去做，因为产品人员本身就是负责整个团队的牵头作用。
网友评论