频繁的需求变更让你痛苦过吗?
在需求分析、设计、评审阶段,对场景和解决方案的考虑不全面,对政策、市场调研不准确。或是某些功能缺失、或者业务逻辑不闭环;还有一些细节问题没有提前想到,导致在后期落地的时候发现了;
也可能有关联方需要配合改造的内容没有调研清楚,后期发现对方无法配合推进;或是系统内的关联功能改造范围评估不准确,后期发现这种方案会伤筋动骨,在落地过程中开发团队发现实现难度过大,周期或成本不可控等。
尤其是在评审过程中研发组、关联方、客户等角色没有认真听,仔细想。后面真正需要大家配合时才发现有问题。
掌握结构化思维能力(下个月会单独做结构化思维的总结)。在方案产出阶段,要先想,先想好,想全面之后,和关键人员碰撞之后,再落笔写文档。就像开发写代码时一样,一定要先做设计、评审通过之后再开撸。因为我们在写文档的过程中,容易陷入具体的功能逻辑里,而缺少了宏观的整体性考量,非常容易让产出物不严谨。
和关联系统充分沟通。不要不好意思,不要嫌麻烦,得不到的答案一定要追问,自己协调不了的一定要上报。现在多做一点,多确认一个问题,能给后面整体过程节省很多时间和成本。
和开发人员尤其是项目经理、技术经理之类的关键角色充分沟通。沟通方案可行性,沟通方案落地难度,同时考量他们提出的修改意见。当然在这个过程中可能会遇到两难境地,但既然我们是一个团队,总要内部协商出可行性方案。
保持与客户的及时互动。清晰客户的需求本质,并向客户整体介绍清楚我们方案的思路,最终评判此思路是否能得到客户的认可。这个过程中也会涉及到如何进行需求洞察、如何进行方案讲解等问题,可以直接点击查看往期推文。
让方案直观易懂,才能让“干系人”提出建设性意见。在向客户、项目组内讲解、探讨设计方案时,界面类的功能尽量用原型图、UI图等直观的表达模式,让大家更有概念;后台类的功能尽量用流程图、时序图、数据流图之类的表现形式进行讨论,从而保证大家理解达成一致。最不济,拿个白板或者厕纸快速画一画,总比干巴巴凭空讲解效果要好很多。
变更,也有多种变更方式。当真的遇到需求产生变化,或者领导要新增需求时,先看此需求的真实程度,是否是“伪需求”,现有功能是否可以“曲线救国”,从而引导不做。其次评估此需求的迫切程度,对现有需求的影响范围,再看能否基于现有需求最小化解决,同时还可以提出能否用新功能置换出一定比例的非关键功能从而保证进度及工作量不至于偏离过大。
ps:我们在日常工作中难免会发现身边人、身边团队的不足,这时我们要不要提醒呢?如果提醒要注意些什么呢?下一篇我将结合自己的经验和读书笔记来分享自己的想法