• 项目过程中出现的突出问题


    一、时间规划不合理

    1、问题描述
    ​    团队未就开发计划达成一致,领导层经常压缩开发时间,且在版本开发中,业务方及产品频繁变更需求,插入紧急需求,需求未形成闭环等情况频发,导致团队开发节奏紊乱,测试及验收时间紧张,质量不佳,导致项目经常处于失控边缘,不是延期就是带着问题硬上线,此外针对技术人员未尊重其专业意见,导致研发时间紧,任务重,进而引发研发抱怨加班多,为了写代码而写代码,质量极其低下,离职率高等一系列连锁反应。

    2、解决方案
    ​    坚持以人为本的软件研发理念,尊重专业技术人员意见,合理规划产品需求,杜绝版本内需求变更及需求未闭环等情况发生,适当鼓励研发优化重构代码的行为以及为其提供时间及空间。

    二、代码分支管理混乱

    1、问题描述
    ​    由于存在多个项目并行或同一个项目的不同版本等情况,经常出现代码相互覆盖情况,导致提测环节、验收环节,因代码遗漏,缺失、覆盖等情况而阻塞,因而使得研发花费大量时间处理代码问题,未将时间用到修复bug上,大大影响测试及产品验收进度。

    2、解决方案
    ​    进行代码提交及合并请求管控,不得随意频繁提交或合并代码,同一个项目团队应有专人兼职负责代码管理,确保本项目代码得到有效管理,确保主干代码稳定可用。若存在同一个项目的不同版本,应另起分支,进行专门管理和维护,待测试验收通过且相关问题全部修复后,合并到主分支进行对外发布。

    三、有规范但未落实执行

    1、问题描述
    ​    项目部输出各种流程标准,小部分流程已执行,绝大多数流程下发不落实,即使落地执行时也是大打折扣,阻力重重,导致项目过程规范化变革举步维艰;
    2、解决方案
    ​    项目规范变更需领导层大力支持才能推行落地,需给覆盖人员进行培训宣讲,讲明白该规范的意义所在,如何操作,流程怎么执行等事项,然后在具体过程中给予指导。监督流程规范落地执行情况,收集反馈并持续优化调整。

    四、缺乏有效沟通

    1、问题描述
    ​    在项目执行过程中缺乏有效的沟通机制,导致信息在各部门间流动不通畅,且在执行过程中召开过多耗时长的且无效的会议,会议结束常常缺乏明确结论,缺少具体方案。即使会议结束明确具体解决方案,但会后执行不到位,造成一拖再拖,未及时有效执行。产品需求变更,未通知相关人员,且未更新原型,导致在进入测试阶段,验收阶段时才发现实际成果与设计不一致等情况出现。
    2、解决方案
    ​    做好项目沟通计划,在什么样的情况下进行什么样的沟通,沟通频次等,每次沟通时想好沟通主题及需要达到的要求或目的等,进行结构化的直面问题的沟通,当设计或需求发生变更时需及时更新原型和告知相关研发、测试、业务方等人员,项目执行过程中需要开会,但不需要经常性的开会,当出现天天开会就需要当心了,需要思考开会是否真正的达成解决问题的目标了。

    五、版本规划混乱无原则

    1、问题描述
    ​    版本规划大小不一,版本不是过大就是过小,甚至存在一个需求一个版本,导致版本管理及划分混乱,团队无稳定的开发节奏,团队产出无法预测及估量,产品经理对产品无规划能力,针对业务需求来一个做一个,经常性插入紧急需求,干扰正常版本开发。管理层针对版本延期不分析原因,不组织技术力量进行攻坚,随意按下版本暂停键,转而投入新版本开发,无法做到有始有终,且项目团队经常出现人员调走支持其他项目,出现人员不稳定等现象,导致项目团队对版本失去信心,严重打击大家积极性。

    2、解决方案
    ​    合理规划版本大小,尽量版本中需求数量相差较小,需产品经理针对系统现状以及通过业务调研,最终形成合理的迭代版本,每个版本有针对性的解决或优化某些问题,使得产品更加好用且贴合业务场景,达到为业务赋能的目的。在一个版本内开发时,尽量保持人员的稳定性,不随意换人及将人调走支援其他项目,出现问题需组织团队进行攻坚,以及总结经验教训,而不是随意暂停本版本开发而转去做新版本开发,需让团队通过该版本形成内聚力稳定的成果输出,从而提升团队的能力,不断的实现其价值,为业务目标更好持续的提供技术支撑。

    六、原型不清不楚

    1、问题描述
    ​    产品将业务需要进行产品需求化时,存在无法准确描述或定义不清等情况,设计原型时存在较多问题,原型描述不清不楚,且无修改记录,缺少交互,需求变更但原型未及时更新,或原型更新未及时同步给相关方等问题突出,导致经常性的来回沟通,产生了大量不必要的沟通成本,导致出现研发出来的产品与原型不一致,导致测试、验收不通过,出现各方扯皮等情况。

    2、解决方案
    ​    需做好原型设计规范,将需求及字段定义描述清楚,不提前预设别人知道而忽略不写清楚,原型至少需做到:修订记录、版本号及版本内容列表、基础的交互、更新列表清单。产品原型至少需经过两次评审之后才进入正式的开发评审阶段,即:第一次业务原型评审,第二次产品部门内部原型评审,第三次正式需求原型评审。若原型存在更新、改动、删减等情况需及时通知到相关人员,保持相关人员信息同步。

    七、人员流动性高

    1、问题描述
    ​    “核心骨干留不住,新同事不稳定”,来一个没待几天就离职且此情况频发,领导层面对此情况不分析、不总结,不反思项目,团队深层次原因,因此导致某些项目严重逾期,人员离职后超一个月无人接手,无人能胜任,严重影响项目进度且投入成本与实际项目价值不成正比。

    2、解决方案
    ​    根据具体情况具体分析,离职无非两种原因:第一是钱没给到位,第二是心受委屈了。无规则无节制的加班,频繁砍时间,需求量大,人手不够,导致研发压力过大,出现大批人员离职,且离职未进行工作知识移交,新人无法接手。因此需从领导层进行观念改革,需充分认识到软件开发的独特性,软件开发需要开放的环境,轻松的氛围,让研发有发挥主观创造性的机会和自由,不应天天盯着工时,研发应以结果为导向,给研发充分的自由去寻找最佳的解决方案。

    八、新人入职

    1、问题描述
    ​    研发新人多,入职未做业务培训,未做研发流程培训,直接上手接项目写代码,导致因业务不熟悉,编写的功能存在较多问题,质量、进度均得不到保证,导致项目不断延期、线上问题频发。
    2、解决方案
    ​    公司及团队应做好新人入职培训,搭建人才梯队培养制度,为公司及项目所需人才提供必要的培训培养,禁止在不熟悉业务的情况下直接接手项目动手写代码,新人入职应先熟悉环境和了解业务,并积极融入所在团队,了解团队的工作方式,能力情况等,采取传帮带的形式,老员工带动新员工,形成良好的人才培养体系等。

  • 相关阅读:
    Centos 7安装python3(PY3.6)
    linux仅修改文件夹权限 分别批量修改文件和文件夹权限
    【工作手札】Nginx接口代理可跨域
    微信自定义分享链接信息(标题,图片和内容)实现过程
    ios 等保 删除 uiwebview
    postman 接口批量测试
    uniapp之 页面滑动 组件
    uniapp之 点击图片跳转详情 组件
    安装 node.js
    创建一个mpvue的小程序
  • 原文地址:https://www.cnblogs.com/jasonboren/p/16195709.html
Copyright © 2020-2023  润新知