惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Y
Y Combinator Blog
The GitHub Blog
The GitHub Blog
Vercel News
Vercel News
D
DataBreaches.Net
MongoDB | Blog
MongoDB | Blog
H
Help Net Security
小众软件
小众软件
美团技术团队
T
The Blog of Author Tim Ferriss
爱范儿
爱范儿
D
Docker
Martin Fowler
Martin Fowler
大猫的无限游戏
大猫的无限游戏
博客园 - 聂微东
Blog — PlanetScale
Blog — PlanetScale
H
Hackread – Cybersecurity News, Data Breaches, AI and More
罗磊的独立博客
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
S
SegmentFault 最新的问题
云风的 BLOG
云风的 BLOG
B
Blog
雷峰网
雷峰网
The Cloudflare Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
浅聊项目交付过程中的风险因素
老猫爱闲谈 · 2024-01-29 · via 人人都是产品经理

任何事情都有风险,就是看如何避免和控制风险。在项目交付过程中,其实有很多都是可以避免的。比如正文进行分析的这些,很具有普适性。

近期我们在信息化建设项目过程中,遇到了一个比较神奇的问题:原本计划二周可以完成交付的功能,延迟至二个月才能完成。这个过程暴露了很多问题,而这些问题往往有很多都是中小型软件开发企业存在的普遍问题。我想通过本次的文章,将我所思考和分析的问题分享给各位读者,希望各位即将或已经在建设信息化系统项目的过程中能有所帮助与收获。

一、交付过程概述

从10月16日开始收到现场实施人员提出的需求,至12月15日完成功能交付,历时两个月。

  • 10月17日至19日:产品设计人员完成原型设计并经过评审确认。
  • 10月20日:研发负责人指派研发任务。
  • 10月25日:研发人员开始执需求开发,至10月30日完成开发,并提交测试人员验证;测试人员提出Bug,设计人员进行设计优化,开发人员进行Bug修复。
  • 11月3日:研发人员完成功能开发,并交付现场实施人员。
  • 11月6日至17日:由于网络故障或其他原因,项目经理和现场实施人员未能推进该功能的用户现场测试和试用。
  • 11月20日:产品设计人员收到现场实施人员再次反馈的扩展需求。
  • 11月21日:产品设计人员完成扩展需求的原型设计并经过评审确认。
  • 11月22日至27日:研发人员进行扩展需求功能开发。
  • 11月28日至29日:测试人员完成功能验证并交付功能给现场实施人员。
  • 11月30日:现场人员进行功能验证收并反馈修复意见。
  • 12月1日至14日:产品设计人员针对反馈修复意见进行优化设计,研发人员进行Bug修复。
  • 12月15日,简化版报告最终完成交付现场实施人员。

二、存在的问题和原因

由于项目建设涉及设计、产品开发、测试、实施和项目管理等环节。

下面我们将分析一下存在的问题:

1. 需求分析

  • 由于需求收集不够完整,需求分析不够深入,导致同一需求的功能段段续续的提出,从而影响项目的开发周期。例如,10月中旬第一次提出的需求,到11月中旬又提出扩展需求。主要原因是产品人员无法亲临现场进行调研,用户需求由现场人员代为收集,而产品人员也没有重视并及时对现场人员收集回来的需求进行认真分析。
  • 由于用户单据资料变更没有及时同步和确认,导致开发完成后还要对功能进行修改。例如,报告文件原先是5月份提供的,而10月份我们使用时,文件已经进行了更新。主要原因是文件使用的时间跨度太长,而且使用时也没有再跟客户做进行一步的资料确认。

2. 产品设计

  • 在功能规划时,由于没有分析需求的应用背景,也没有从开发团队实际情况出发,导致开发和实施难度变大。比如:设计这个临时功能时,关联了其它的设备、人员、报告等各个功能模块,使得原本只要上线一个模块的功能,现在还要关联其它模块一起上线,延长了开发和实施的周期。这是因为功能规划时,没有考虑到快速推广应用的目的,而是忽略了实际情况。
  • 在功能设计时,也没有充分考虑客户的应用场景,比如:在设计用户编制报告功能时,除了考虑常规的新增报告,还应当考虑编制同类报告时,可以进行快速复制的功能,以及对于一段时间内需要集中编制大量报告时,可以考虑导入报告的功能。完善这些功能的设计,除了依赖前期的需求收集外,也需要设计人员充分的分析和思考。
  • 控件定义时,也没有从数据实际应用角度考虑,导致开发完成后还要对控件进行修改。比如:涉及到客户保密和安全的字段的展示方式,原先我们定义为下拉选择的方式(暴露所有的数据信息),后面我们又调整成文件输入的方式,这是因为设计时不仅要考虑到用户使用与操作的便捷性,也需要考虑客户所属行业关联的数据安全性。

3. 系统开发

  • 由于开发团队负责人在分配完研发任务后没有及时跟进和推动任务的执行,以及没有明确任务的优先级和完成日期,导致任务执行的时间滞后,比如20号指派的任务,25号才开始接收执行,这主要是由于开发人员存在并行处理的任务。
  • 由于开发团队内部按模块对应固定人员分工,以及开发的资源不足,内部分工机制不够完善,导致一个模块新需求和bug过多或着对应模块的开发人员请假时,无法按时完成任务,比如报告管理由一个人开发人员开发,由于前面的需求和设计的变动,以及开发人员的请假,导致任务一直在延期。
  • 开发与产品团队人员之间缺少必要的沟通,导致开发完成后的功能与实际设计的功能有偏差,比如报告管理原先设计是放在一个租户下,而实际开发出来的是放在另一个租户下,这主要是由于前期没有需求详讲,开发过程中遇到疑问没有保持沟通。
  • 开发完成后,由于没有进行单元测试和集成测试,因此在测试阶段出现了大量的Bug,其中有很多是比较低级和明显的错误,比如:填写的时间格式不正确,展示信息的取值不准确。这主要是因为前期需求和Bug的工作量很大,以至于精力不足以进行自测,就提交测试了。
  • 在功能部署升级时,由于没有将生产环境和测试环境做好同步,导致出现了在测试环境中没有出现的问题,比如:生产环境首次新建报告时,模板是空的;报告内容中的基础数据为空等。这主要是因为没有实施测试与生产环境同步的要求和机制,同时也缺少对生产环境的验证要求。

4. 系统测试

测试对提测版本没有要求,导致交付测试版本质量较低,发现的 Bug 数量较多,需要测试人员与开发人员之间反复沟通,影响项目交付的周期。比如:目前测试人员测试的时间都是由开发负责人通知的,通知开始测试就直接上测试环境测试。

测试发现问题后,目前仅提交 Bug 到禅道,缺乏后续的问题跟进处理,导致 Bug 量较多,但验证和解决的少,影响项目交付的质量。比如:每日仅统计 Bug 的发现量,但没有统计 Bug 的验证情况和未解决的 Bug 目前处理情况,延期的 Bug 依然延期,而且越积越多。主要原因除了测试人员跟进不及时外,开发人员解决效率也是一方面的主要因素。

5. 实施

实施人员没有制定详细且可落地执行的实施计划,导致在现场发现问题时,对设计、开发和测试团队没有时间上的要求,从而使项目的实施工作变得不可控。比如,没有对客户提出的报告需求进行任务分解,也没有明确要求任务的执行人、执行时间和相应的配合资源。

实施人员对分配的实施任务没有按要求执行到位,也导致了项目周期的延长。比如,基础数据配置的工作原计划一周完成,但拖拖拉拉延迟了两周,客户使用发现问题后,又需要调整配置一周。这主要是因为对实施人员的岗位职责和管理要求没有明确。

6. 项目管理

项目管理人员未能将该功能列入项目计划,也没有及时跟进并发现该功能执行过程中的问题,从而导致功能的进度被不断拖延,从10月16至12月15整个功能开发历时2个月,而回头看再排期时,本可以只要1个月左右时间便可完成。这其中,主要原因是项目管理人员没有足够的管理意识,没有给予该功能足够的重视,比如:站会跟进、人员协调等,计划也未能及时发现问题并及时跟进。

此外,项目管理人员身兼数职,需要配合项目售前相关工作,还要需求调研设计等工作,没有更多时间投入到项目管理工作,比如:在11月份,项目管理人员被抽调进行二期项目的招投标工作一周,这主要是因为公司资源有限,往往一人多岗,在多项目并行时,管理人员就力不从心。因此,公司应当集中一人,专岗从事项目管理工作,以提高效率。

三、问题分析与改进措失

1. 需求分析

对于安装部署后的项目,进入系统功能优化迭代阶段后,出于成本等各原因的考虑,用户的需求往往由现场实施人员收集。此时,产品设计人员更多的是通过现场人员收集和反馈的信息进行系统的设计,也因为产品设计人员没有第一手的沟通信息,会导致设计上存在偏差和缺陷。要避免存在这种情况,个人觉的要注意做到以下三点:

  • 将需要现场人员收集的用户需求制定成模板,让现场人员按模板要求填写用户需求。这样就可以将设计所需要了解的客户需求要素收集完整。当然前提是产品人员清楚自己设计时需要涉及到哪些要素。比如:现在我们制定了用户需求反馈跟踪记录表,将用户需求完整记录到清单中,同时也利用现场人员跟用户进行反馈。
  • 对于反馈记录单表中的需求描述不明确或不完整时,要及时跟现场人员或需求提出用户及时进行沟通确认,避免需求出现偏差。比如:现在我们逐条对用户需求进行分析并描述需求的系统实现方式,有不明确的地方会及时进行沟通。
  • 对于用户提供的单据资料要及时做确认,特别是提供较长时间(比如1~3个月及以上)的资料要明确是否有最新版本。

2. 系统设计

设计人员进行功能规划时,要先明确本次项目(功能)的建设目标,建设周期,再结合前面收集的需求进行功能规划。设计产品时,需要根据用户的实际场景出发,功能能够满足和覆盖各种应用场景,当然从功能规划角度要定义好功能的优先级。定义产品控件时,需要考虑每个数据实际应用的情况,再进行控件的定义,以避免实施过程中遇到问题再去调整。

3. 系统开发

  • 通过管理工具进行任务分配管理时,开发管理人员要利用工具做好及时任务提醒,同时也需要开发管理人员养成每日定时任务分配的习惯,避免任务未能及时安排导致任务延迟。另外,尽量避免开发管理人员既要管理开发团队又要进行项目开发,两头都要顾及时,往往开发与管理工作都不能做好。
  • 应保障项目开发团队的人员有一定的冗余度。在项目开发过程中,若有人员因故无法完成任务时,可以有资源能够调配,保障项目的进度。
  • 设计与开发人员应保持沟通。从设计交付至开发人员的需求详讲,开发过程中的问题澄清,再到最后的开发功能交付产品验证。开发人员与产品应保持沟通,有疑问就要即时的提出和解决。过程中的沟通与人员的主动极积性密切相关。
  • 开发人员应当做好自测工作,避免交付的功能存在重大、明显的缺陷。同时,开发管理人员也根据项目的进度安排好开发任务的优先级,避免任务的过渡集中导致任务过多而导致开发人员无法自测或自测效果不理想的情况。
  • 利用和做好开发外的基础性工作,提高开发的效率和质量。比如通过代码走查工具提升代码质量;通过同步测试和生产环境的基础数据,提高功能测试和验证的准确性。

4. 测试

建立起测试流程规范,通过学习与培训提高测试人员的能力。同时,也要建设好测试管理制度,对测试的结果进行考评。

5. 实施

实施人员需要根据现场的实际情况制定好实施计划,并与客户及研发团队达成一致,保障实施计划能够逐项落实到位。

6. 项目管理

项目管理人员需要将每项工作列入项目计划,通过站会跟进项目的进度与质量,在项目出现问题时,需要及时的调配资源保障项目完成。若存在管理人员身兼数职情况下,可以增加项目助理,辅助完成日常操作性工作,让项目管理人员集中精力完成重要的工作事项。

四、总结

以上问题可见,需要完成一个项目,先依据实际情况制定好项目计划,计划中涉及的人力资源要有保障,同时项目过程中的各个环节要有规范和制度,对于项目过程中的存在的风险要提前做好防范措施,才能保证项目保质保量的完成。

作者:refurbish ; 公众号:Bruce林奋进频道

本文由 @refurbish 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。