江苏龙网

  1. 首页 > 人文 > >

辛先森科技说|懂程序员的产品经理是什么样子？( 二 )


但如果你的视野更大 ， 格局更高 ， 就会发现 ， 如果以「投入产出比」角度来切入 ， 双方不但都能理解 ， 而且很容达成共识 ， 毕竟花最小的成本干价值最大的活 ， 是个正常人都能理解和认可不是么 。
所以 ， 可以在日常工作中不断的强化这个共识 。 一旦出现争执 ， 就从这个角度来做最终决定 ， 甚至基于这慢慢地还能建立起相互的信任 ， 程序员真正拥有了产品思维 ， 产品经理真正懂了程序员的难处 。
02
将产品经理范畴内的事情做到极致 。
所谓术业有专攻 ， 与其相互吐槽 ， 不如多花点时间把对方吐槽的地方做到极致 。
03
有时候你虽然做的很好 ， 想的也很仔细 ， 但是还是会出现无法说服程序员认可你方案的情况 。 这是因为我们每个人本身都会存在「确认偏误」现象 。
确认偏误是指搜寻 ， 解释 ， 偏爱和回想确认或支持一个人先前信念或价值观的信息的倾向 。 会导致对个人信念的过度自信 ， 并且在面对相反的证据时可以保持或加强信念 。
——维基百科
所以 ， 运用一些沟通技巧显得至关重要 。 只要一件事不是单凭一个人就能完成 ， 你就得考虑如何提高协作效率 。 而产品经理和程序员的协作中 ， 沟通又是最重要的 。
下面展开说说具体可以做的一些事 。 主要是思路中的2和3 。
01提高专业性
我观察过一个现象 ， 需求变更比较多的产品经理 ， 他们的工作习惯往往是直接抄起原型工具就画原型 ， 或者有很多工作时间在原型工具里 。
这样非常容易陷入到一个思维惯性里面去 ， 就是过于关注交互层面的事情 ， 而轻视了背后业务流程的设计 ， 甚至是业务的合理性 。
我认为产品经理做事的时候一定要以UserStory为核心来展开 ， 先构思好一个UserStory ， 然后就是把它真实发生的各种细节阐述清楚 。 做这事的过程先后分为以下四步：
定义UserStory定义交付标准提供低保真原型编写UseCase这里面最费时费力的就是第四环节 。 并且 ， 你想把UserStory阐述清楚离不开一个专业的UseCase编写 。 我之前收藏了一个非常专业的UseCase模版 ， 是从知乎上的张恂老师那看到的 ， 你感受一下 。
用例名称：提问
层次：!（用户目标层）
范围：问答网站（以下简称系统）
主用角：注册用户（以下简称用户）
其他干系者：...
后态：
前态：用户已登录 。
触发事件：用户选择提问 。
基本流：1.系统显示新建问题框 。
输入问题{
2.用户输入问题陈述（字数限制？）；系统即时验证输入的有效性 ， 并提示已有答案的类似问题（数量？）以免重复提问 。
3.用户设定该问题的相关话题 。
4.可选项
用户可补充输入问题说明（背景、条件等详细信息） 。
5.可选项
……
6.用户提交问题 。
}
7.系统验证该问题的有效性 。
8.系统发布该问题 ， 并显示该问题页面 。
扩展流：用户放弃提问：...
作为产品经理的你 ， 如果想要减少被程序员吐槽需求不够细 ， 或者降低开发过程中变更需求的频次 ， 把usecase用心做好是必不可少的 。
02沟通方面
与程序员的沟通方面 ， 我总结了五动作 ， 分别是「齐、拉、捧、说、谦」 ， 可以根据情况组合出击 。
「齐」就是视角对齐的意思 。 在聊需求之前 ， 先交代需求的背景、意义 。 特别在中途需求变更的时候 ， 这点非常重要 。
继续搬出之前用过好几次的图 。
辛先森科技说|懂程序员的产品经理是什么样子？
文章图片
如果视角不同 ， 你说接下去还怎么聊？
「拉」是拉拢的意思 。 亚里士多德说过：
我们无法通过智力去影响别人 ， 而情感却能做到这一点 。
所以 ， 在沟通的时候要把程序员当作自己人看待 ， 而不是敌对 。 比如 ， 可以多用“我们” ， “一起”等词语 ， 进入一个协商的氛围 。 举个例子：“我们一起来看下这个问题” 。 少用”我觉得“、”我认为“；


推荐阅读


上一篇：Xr糊说8道|红米k30至尊纪念版；堪称性价比机皇，小米十周年

下一篇：深圳市|这座被低估的城市，或成下一个深圳？华为、阿里、京东都争相投资