Heidi格物志

不苛求完美,不停止进步。不懂数据的交互设计师不是好的产品经理。

© Heidi格物志 | Powered by LOFTER

【三言两语】满足期望很容易,多想一步才能超出期望


很容易区分是任务型的开发工程师还是合作人类型的开发工程师。任务型的开发,就照着需求文档干活,如果你需求文档没有注明的,即使他觉得属于人为遗漏,但也不会来和你进行确认进行补充,而是会继续把已经注明得很清楚的完成掉。如果你发现上线后,原本应该实现的没有实现,提出时,任务型的开发同学会拿出你的需求文档,指出是你当时没有注明,所以你应该承担这个责任,此时,白纸黑字,做为需求方,你确实没有任何可以抱怨的。

但是你也会认为他满足了期望。

但是下次合作时,会在需求文档上花费更多的时间,认真去标注每个细节,认真去确认每个细节,生怕又遗漏掉。其实,这在快速迭代的项目里,也未必是好事。

但是合作伙伴型的开发工程师,需求文档要有,但是在执行中,甚至会帮你去补充场景,如果能够来得及去和你确认就确认后补充,如果来不及确认,靠Commen sense也会直接执行掉。所以上线时,往往给你更多惊喜。

还有一个故事,比如,有某老大叫住你,说希望你让分析师给他一份按部门罗列的关键指标数据。完了之后你照着这句简单的需求转交给分析师。分析师同学问你,某某指标要不要?你说,如果有的话,你也附上吧。一会分析师又问你,除了这些部门,还有一些外包的部门要不要?

你沉思了一下,说,如果有的话,最好一起附上,但是给分类清楚。

分析师很痛苦了,说,到底需求是什么,能不能描述清楚一些。

这个时候,你可能会告诉分析师,老大的一句话,未必讲得那么清楚,或许他在下达命令时,压根还没想到有外包部门也有数据,如果你能提供,顺便提供给他做对比不是更好?

满足期望,就是原原本本地去实现,从一句话需求里,多想一些,顺手多提供一些,才能够超出期望。

说这句话的时候,想到,自己做为传达者,也是可以直接传达超出期望的需求的。

评论 ( 4 )
热度 ( 11 )