[Day25] Scrum失败经验谈 – 与需求单位之间的断层

使用者意识

真为基础、善为核心、美为极致

承[Day24] Scrum失败经验谈 – 壁垒分明的职务配置中提到的壁垒分明,或从其他篇文章中,也可嗅到一丝讯息,壁垒分明也存在於开发团队与需求单位之间。新时代的工程师不论是身处在新创或大公司,「使用者意识」是一个让工程结果更为杰出的重要思维,我相信厉害的工程师,以演算法或工程作品的角度,都能打造出不错的成果,然而,就像前篇有提到的建立教堂的故事一样,让这个作品可以增添光亮的是,为使用作品的人带来的意义与感受。创办人那时来鼓励工程团队的时候,他分享了在工作上工程的「真善美」,从工程个人与使用者的角度定义了工程师追求的3种层次,「真」,意在打造能正确运行的功能,让使用者使用时,不会问题百出,能实际解决使用者的痛点,「真」最入门也最基础的第一件事,是一般工程师在工作上的基本要求;「善」,是以使用者为中心打造使用者良善且便利的功能,在「真」成为我们基础能力後,能为使用者设想的心,会影响工程作品的效益,能打动使用者作品会触动使用者发自内人的WOW;「美」,是追求工程领域的最大值,不论是以最短时间将程序完成、让程序以最有效率的方式运行或发展出令人惊叹的演算法,让工程作品成为受过使用者满意与工程的高技术认可的成就。在失败经验分享上,等到这一刻才分享这之间的断层,主要的原因在於我们整个系列在分享如何打造一个企业内的软件文化,拥有使用者意识无法很明确地被衡量,而且每个人对於具备使用者意识的程度不同,透过一个良好的机制与文化构筑成桥梁,让使用者和工程团队有机会彼此了解更为重要。

渴望知道使用者的为什麽

不强行让使用者接受很炫的技术解方

身为一个产品经理,做为需求单位和工程团队之间的夹心饼乾,可以很清楚感受到理解工程团队的需求单位和渴望为需求单位解决问题的工程团队的样貌,我很幸运可以感受到不同的样貌,先说需求单位,需求单位除非有工程背景,要一步想到一个可以和工程团队可以沟通的需求或是想法,是不可能的,一个好的需求单位,我觉得绝对要具备2个重点:尊重工程团队给予的评估与工作模式、对於自己的需求负起全责,如果不信任或不尊重工程团队的评估与工作方式,基本上合作就是破局的,也同时是提出运用工程团队的一方,需求的价值与资讯的提供要负起全责,其实也是尊重的一环。而工程团队,要渴望知道使用者的为什麽,而非强行推销很炫的工程解方给使用者,放弃技术的多元可能性,同样为工程出身的我会和工程师这样说,「我们共同所受的工程训练,包含逻辑、程序技巧等,这些耗上我们多年的时间,即便现在,我们依旧觉得技术仍无止尽,更遑论要使用者单位提出我们理想中工程答案的需求」既然如此,身为团队一份子的工程团队,不就是最佳角色去引领使用者了解技术解方的最佳代言人吗?不用教会他们资讯工程,只要以「一起解决问题」的同理心去体会使用者,因此,非工程出身的需求单位,需要的是能解决痛点方案,而非技术完美的工程技巧,简单的一句:「都是需求单位需求开的不好」并不能改变任何事情,身为产品经理的我们,当然肩负起弭平断层的责任,但相信我,工程师是否具备使用者意识,沟通的结果与所需耗费的成本,会截然不同,只有具备使用者意识的工程师,才能让对话前进,找到一个好的结果(这里补充一下,这里是需求单位没有其他特殊的大议题,如果有,就是另外一件要处理的事了)。


<<:  【Day 27】迁移学习(Transfer Learning)(下)

>>:  Day 25 - redux-saga 文件范例

【Day14】浅谈系统入侵System Hacking(一)

哈罗, 我们在前面几天学习了以下这些主题: 资讯蒐集(Footprinting) 网路扫描(Scan...

DAY5 Python基础教学(二)

DAY5 Python基础教学-List 前言 List结构非常重要,它跟C语言中的array很像,...

TypeOrm | Repository APIs 用法纪录 3

https://typeorm.io/#/repository-api 关於 save() \ de...

【Day 19】Shellcode 与他的快乐夥伴 (下) - Shellcode Loader

环境 Windows 10 21H1 Visual Studio 2019 前情提要 在上一篇【Da...

Day 29 - 一秒使用 Tailwind

一般来说,要使用 Tailwind,不管套件也好,Tailwind CLI 也好,除了 Tailwi...