这篇文章是软件工程系列知识总结的第三篇,前面的两篇文章聊了软件工程的重要性以及相关的基础知识。这篇文章,我会将软件工程中关于项目规划和管理的重点知识进行总结梳理,并以自己理解的方式进行阐述。
可行性研究的本质:基于问题和解决方案进行分析,评估投入产出,以供决策。可行性研究的考虑点:
经济可行性:即成本问题,包含人力成本、时间成本、软硬件资源成本、引流拉新成本等;
技术可行性:技术方案的实现难易程度、开发速度、结束难题如何解决规避、以及后期的维护成本等;
社会可行性:可以理解为业务可行性,即项目投产后能否带来预期的收益,市场和竞品分析以及可能涉及到的法律道德和社会影响等因素;
当然,由于软件项目很多时候前期是没有特别明确的需求时,可以考虑小范围做一个mvp(最小化可行产品)进行验证,等需求比较明确,可行性较高时再逐步加大投入。
以我自身的职场成长经历来看,从技术转型为管理岗的过渡过程,管理项目是必不可少的一个经历。这里的管理项目不是说单纯的PMO(项目经理)角色及职能,而是你既要做项目主要的技术决策者,又要关注过程,协调团队里不同的人解决不同的问题,最终保障项目的保质按期交付,拿到好的结果。
项目管理最重要的一点是大局观,要脱离具体的技术细节,从整个项目和团队维度去考虑。具体可分为下面几个部分:
确定方向:明确团队和项目的发展方向,目标是什么,达到目标需要做哪些事情;
识别风险:项目的整个生命周期中哪里可能出现问题,出现问题有哪些应对方案(事前预防大于事后解决);
创造环境:为项目能按照计划交付尽可能创造好的条件,解决资源问题、沟通问题,让专业的人做专业的事情;
调整能力:项目研发过程中遇到问题或业务规划变更,要及时评估并对接下来的动作进行调整,平衡投入产出比;
项目管理也有自己的“道法术器”,而项目管理的道就是管好人,管好事。想明白本质,掌握好方法就能做到较好的项目管理。具体的如何管好人管好事,可以看下面这张图:
我们日常工作中最熟悉的项目计划,应该都是从需求评审到线上发布这一套了,当然,大家更愿意称之为版本迭代。
项目计划的本质是明确什么时间由什么人做什么事达到什么效果。如果没有计划,软件研发可能会陷入混乱,问题不知道找谁解决,无法按时交付。就像开车上路的导航地图一样,在每段道路行驶中都提醒我们该走哪条车道,做哪些动作。如果不按照导航提醒驾车,就很可能走错路甚至违反交通规则。
制定项目计划,一般主要分为如下几个步骤:
任务拆解:将项目完成所需做的事情按照层级逐层拆解,一直拆解到最小单元(具体的可量化可交付的事项);
估算时间:这个大家都很熟悉,需求评审完,研发测试都会进行工时评估,哪些环节大概需要多少时间,多少人力;
任务路径:根据任务之间的依赖关系和预期的资源占用,排出合适的顺序。比如:
研发编码阶段测试可以编写测试计划、测试case并评审(这是并行的任务路径);
做接口测试的前提是研发已经写好了API并自测通过,否则接口测试无法开展(这是串行的任务路径);
当然,有了项目计划后,还要设置不同阶段的里程碑。比如我们日常的版本迭代中,会规定什么时间提测,什么时候验收,什么时候线上发布,这些环节的交付产出物需要满足哪些条件。
还有一点比较重要的是制定好计划之后,需要时时的跟进整体进度,并且要根据具体情况进行及时的调整。常见的有研发同学生病请长假、临时插入了很多紧急需求等,这种时候资源不足又需求变多,就需要调整整体的研发交付进度。要么砍需求,要么加人,或者项目延期上线。
关于流程规范的目的,我在前面的文章介绍过很多次,这里再次重申下我的观点:
流程是什么?
流程是保障团队目标达成的最佳实践,因人/团队/业务类型/迭代速度/资源紧张程度而异。
为什么要有流程?
没有流程会导致团队中的个体各自为战,目标不统一,进度不协调,资源配给失衡而导致交付质量下降。
流程能解决什么问题?
流程能保障团队或者群体在大方向上保持协调一致,尽可能降低由于团队人员能力、认知水平、资源不足、意外情况导致的项目延期或者质量下降。
流程能带来什么保障?
风险可识别+问题可追踪+结果可验证+数据可量化!
其实制定流程规范的目的主要是如下几点:
提升团队整体效率(原因参见上文);
流程是解决问题最佳实践的标准化产物,起到经验共享的作用(可以理解为赋能);
流程规范让项目管理从人治到“法治”(人会成为人治的瓶颈,人也有其自身的局限性);
软件项目的研发过程中,跟进计划和任务的进度是最繁琐的事情。
任务要拆解成可具体的可量化可交付的单元,但衡量任务的完成度和状态变更是最大的难点。
因此借助工具或技术手段来解决任务追踪和量化,是提高项目管理效率很好的手段。
这就是上一篇文章中提到的研发过程管理部分,各种管理模型的迭代和进化目的。
业务、市场、技术在不断变化,大家追求的永远是质量和效率,而工具发明出来的目的就是为了提高效率。
有句话叫做“流程工具化,工具自动化”,意思就是好的流程规范要尽可能转变为工具,脱离人治,升华“法治”,不断寻找新的更好的可以提高效率的工具和技术。
近几年敏捷的火爆,一部分原因也是由于传统的软件研发管理方法效率太低,而敏捷所包含的的Sprint、Ticket跟踪和看板可视化任务管理,就是为了解决效率问题。
软件研发过程中或多或少会遇到一些预料之外的事情,比如工时评估太乐观导致后期交付延期、关键岗位的人员离职导致项目进度停滞、采用了新框架新技术导致上下游兼容出了问题等等。这些都是软件项目研发过程中的风险。
风险是不可逆的,但提前评估风险,做好应对准备,可以有效的降低风险造成的损失和影响。
风险管理一般分为如下四步来进行:
识别风险:在项目开展前期就尽可能评估可能出现的风险,比如核心员工离职;
风险量化:评估不同的风险会造成的影响和损失,主要考虑损失大小和发生几率;
制定策略:针对风险发生的概率和损失大小制定优先级,并制定对应的备份方案;
风险监控:对风险进行监控,设定监控告警机制和风险处理流程(类似SRE中提到的noc团队所做的事情);
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码,朋友们如果需要可以自行免费领取 【保证100%免费】