对象:非技术人员
目的:高效与技术人员沟通
掌握技能包含主要3点:
1. 技术职能划分了解
2. 常用技术术语了解
3. 理解开发人员思维(技术思维vs产品思维)
用户代言人:产品经理
实现代言人:技术人员
第一部分 技术思维vs产品思维
技术思维(程序员)
1. 功能实现
2. 开发难易
3. 后期维护
4. 改动成本
产品思维(产品经理)
【要站在用户思维,否则以技术思维可能最后做出来产品过于生硬,偏工具】
1. 产品定位
2. 需求场景
3. 用户体验
4. 业务目标
产品思维vs技术思维实例:
微信通讯录及会话设计:
从微信第二个“tab”进去,点击好友主页,点击“发消息”,点击左上角“返回”,却退回了第一个tab“微信”
技术思维:堆栈式设计,即从哪里进入,就返回到哪里。(路径为1-2-3 / 回退路径即为3-2-1)
产品思维:更加符合场景,贴合用户使用习惯,遵从人性。
备注:以上的微信通讯录及会话设计操作路径示例,本人按照上面操作实操时却发现回退到的是上一个页面,而非作者说的返回第一个tab“微信”,可能是新版本的微信改了吧,作者当时是旧版本吧。不过实际中确实很多类似这种例子。尤其是用户使用习惯。
1 产品技术沟通之道,如何与技术人员高效沟通(Ryan)-学习分享其他:技术人员往往不具备同理心,及换位思考的能力(产品方面,生活其他角度除外)。但是产品经理必须同理心及换位思考的能力。这是产品经理必须具备的一种必备素质。所以产品经理需要内心强大。来抵抗一些来自程序员方面的压力。但最终产品经理任然需要站在产品角度,用户角度去完成产品设计。也是基于此方面(思维方式及心理能力)产品经理和技术人员是不同的,所以这也是产生分歧的根本原因。
第二部分:技术职能划分
CTO:技术部门leader或产品
架构师:负责系统整体技术架构和技术选型(技术角色)仅次于CTO。
前端开发:分为网页前端(web)、移动客户端前端(native),移动客户端又分为Android、ios、Windows Phone【安卓设计和ios有不同的开发设计规范】
后端开发:服务端开发,包括数据库设计与开发,应用接口开发。
系统运维:服务器管理与整体维护,应用发布。如服务器数量是否够等。
1 产品技术沟通之道,如何与技术人员高效沟通(Ryan)-学习分享上图为作者的创业公司的一个工作流程。具体公司可能不太一样,但大同小异。
几点:周为节点进行产品迭代。高保真的demo。这块是作者公司需要做的。根据笔者经历而言,有的创业公司需要做代码可运行的高保真demo,如需要用demo和投资人沟通融资。大部分公司只需要评审非代码层面的原型及需求文档即可。
个人总结:利用用户思维去跟开发解释更符合用户场景。而不是技术实现。这也是我在工作中经常遇到的。有时候可能太过于同理心了【比如特别“同情”技术人员】就会把一些“不易”开发的省却成简单的,这其实很多时候是不正确的做法。这样往往设计的产品过于机械化、工具化。产品经理应该站在用户思维,不要走偏记得!
第三部分 常用技术术语
【此处需要划重点,着重记忆,对你以后和技术沟通和理解技术有很大帮助】
1. API:服务器端的应用接口。应用接口类似于服务器端定义好的一个协议,这个协议有一些的数据结构,会有一个固定的标识。前端同学需要访问这个协议,通过这个协议将具体的数据传送给服务器端,服务器端基于这个固定好的协议接受数据,实现前后端互联互通。API就是协议,前后端共同遵从的协议。
eg:登陆功能:后端定义好需要用户名和密码,前端需要将用户名和密码传送给服务器端,服务器端验证成功就好了。
2. Json/xml:属于数据协议。eg:登录名/密码。实际就是通过json这个承载体,可以理解为打包文件,把用户名和密码放到里面,然后通过API这个协议传送给服务器。
3. URL:地址。
4. html/css:web网页使用的布局语言、装饰表
5. 数据库(DB):存储数据,数据查询,检索
6. Git/SVN:管理代码,代码存储的服务。实现多分支管理,远程和本地的开发。【代码仓库】不同的代码同学共同协作。
前端术语:
Activity(Android):每一个屏幕展示的页就是这个,这个界面上所有的逻辑,所有的展示
ViewController(IOS):每一个屏幕展示的页就是这个。同上,只是一个是ios一个是安卓。
lib(第三方库):eg:用百度地图的sdk,可直接使用这项服务(定位服务)第三方库帮助我们做复杂的事情
ListView(Android):其实就是app里面经常能看到的列表,例如微信里面的聊天页面就是个列表。
TableView(iOS):同上。
View:基础组件都是一个view,如一个按钮,一个选择框,一个复选框都是一个view,甚至一段文字的展示都是一个view。指的是具体前端页面展示的一个具体的组件。
第四部分 如何与技术人员沟通
【翻译】【很重要,非技术产品经理90%都会遇到】
产品经理说白话,技术人员说黑话。产品经理需要自己翻译给自己听,给用户听。(哈哈)
产品经理主导沟通方向,实际工作中讨论往往从原本的产品讨论很容易陷入技术细节讨论。应该避免陷入技术细节讨论,从场景和用户体验出发。对实现方案的讨论,非技术产品经理是无法参与的。技术人员找产品经理讨论,往往是确认产品需求但最终就成了讨论技术问题。如何解决这个问题:1)从场景出发,2)从用户体验出发。
真正用户能用的产品。
因此产品经理与开发人员沟通的过程中要把握沟通的方向,要知道聊的是什么,每一次沟通要有目的和结论。沟通要往哪个方向引导。一切以用户场景和用户体验为主。否则讨论就会走向偏题的状态。这也不是自己擅长的。
如下图为技术人员经常会对产品经理说的话,你是不是很有同感?
如果遇到以上问题:产品经理是改产品设计还是改需求。
1 产品技术沟通之道,如何与技术人员高效沟通(Ryan)-学习分享产生上述原因可能有产品需求文档里面没写,或者技术人员觉得这个重新做成本太大。实现不了,或者技术人员直接告诉你只是后端的问题。
如何解决上述问题,举两个例子:
【引导型沟通,有序的沟通】
第一个“这个实现不了”:不要被技术所限制,但要在技术边界之内。产品是需要衡量投入产出比。挖掘技术人员背后的初衷,是因为时间不够(讲清楚紧急程度,就改为可实现了),还是技术难度(技术人员也是需要技术调研),另一种是确实技术实现不了。一定要搞清楚是哪一种,不要随意更改需求,不然是对用户的不负责,是对产品的不负责。
第二个“这是后端的问题”:当我们使用产品时发现了一个bug,可能第一时间直接问开发同学或测试,问怎么解决,技术人人员往往告诉你是后端的问题。那么你应该找谁,是找前端是找后端,正确的方式是不应该直接找后端,而是需要问前端:你是如何排查这个问题的,我们应该怎么解决这个问题,如果要解决这个问题,我能为你做什么,一起探讨这个问题的解决方案。
分析技术人员的需求:Want or Need。需求的本质。
用户:需要一个更快的马
福特:提供了一个汽车
第五部分 非技术背景产品经理学习指南
懂用户比懂产品重要,懂产品比懂技术重要
设计一款产品:最先考虑的不应该是技术,而应该是用户,需要我们在什么场景下位他们解决什么问题。这样才能更好的设计,呈现给用户。产品本身不能过于流程化和机械化。设计一款符合用户使用习惯的产品。
总结:
1. 发挥非实现模式思维的优势,理解并思考场景
2. 多与技术人员沟通,理解实现模型思维
3. 学会讲故事。讲故事能力非常重要,往往都说产品经理就是ceo的学前班,这个我很认同。产品经理需要面向运营、市场、财务、法务等等。产品经理要让这个故事讲得精彩,让大家一起把事情做好。这个故事的引导者和制造者就是产品经理。并且产品经理需要有广度思维。
最终我们所创造的用户价值,才是最终能带来实际效果的,才能造福用户,被这个行业和市场所接受,我们应该为这个行业创造价值,为这个行业改变一些事情,为这个世界做一些事情。
最后送给大家:
不想改变世界的产品经理不是好的产品经理,产品经理要有一颗创造、改变和实现一些东西的初衷和想法。不然产品经理就沦为了功能型产品经理。什么是创造型产品经理,什么是功能型产品经理,相信大家都有自己心里面的一些思考。
非技术人员
目的:高效与技术人员沟通
掌握技能包含主要3点:
1. 技术职能划分了解
2. 常用技术术语了解
3. 理解开发人员思维(技术思维vs产品思维)
用户代言人:产品经理
实现代言人:技术人员
第一部分 技术思维vs产品思维
技术思维(程序员)
1. 功能实现
2. 开发难易
3. 后期维护
4. 改动成本
产品思维(产品经理)
【要站在用户思维,否则以技术思维可能最后做出来产品过于生硬,偏工具】
1. 产品定位
2. 需求场景
3. 用户体验
4. 业务目标
产品思维vs技术思维实例:
微信通讯录及会话设计:
从微信第二个“tab”进去,点击好友主页,点击“发消息”,点击左上角“返回”,却退回了第一个tab“微信”
技术思维:堆栈式设计,即从哪里进入,就返回到哪里。(路径为1-2-3 / 回退路径即为3-2-1)
产品思维:更加符合场景,贴合用户使用习惯,遵从人性。
备注:以上的微信通讯录及会话设计操作路径示例,本人按照上面操作实操时却发现回退到的是上一个页面,而非作者说的返回第一个tab“微信”,可能是新版本的微信改了吧,作者当时是旧版本吧。不过实际中确实很多类似这种例子。尤其是用户使用习惯。
其他:技术人员往往不具备同理心,及换位思考的能力(产品方面,生活其他角度除外)。但是产品经理必须同理心及换位思考的能力。这是产品经理必须具备的一种必备素质。所以产品经理需要内心强大。来抵抗一些来自程序员方面的压力。但最终产品经理任然需要站在产品角度,用户角度去完成产品设计。也是基于此方面(思维方式及心理能力)产品经理和技术人员是不同的,所以这也是产生分歧的根本原因。
第二部分:技术职能划分
CTO:技术部门leader或产品
架构师:负责系统整体技术架构和技术选型(技术角色)仅次于CTO。
前端开发:分为网页前端(web)、移动客户端前端(native),移动客户端又分为Android、ios、Windows Phone【安卓设计和ios有不同的开发设计规范】
后端开发:服务端开发,包括数据库设计与开发,应用接口开发。
系统运维:服务器管理与整体维护,应用发布。如服务器数量是否够等。
上图为作者的创业公司的一个工作流程。具体公司可能不太一样,但大同小异。
几点:周为节点进行产品迭代。高保真的demo。这块是作者公司需要做的。根据笔者经历而言,有的创业公司需要做代码可运行的高保真demo,如需要用demo和投资人沟通融资。大部分公司只需要评审非代码层面的原型及需求文档即可。
个人总结:利用用户思维去跟开发解释更符合用户场景。而不是技术实现。这也是我在工作中经常遇到的。有时候可能太过于同理心了【比如特别“同情”技术人员】就会把一些“不易”开发的省却成简单的,这其实很多时候是不正确的做法。这样往往设计的产品过于机械化、工具化。产品经理应该站在用户思维,不要走偏记得!
第三部分 常用技术术语
【此处需要划重点,着重记忆,对你以后和技术沟通和理解技术有很大帮助】
1. API:服务器端的应用接口。应用接口类似于服务器端定义好的一个协议,这个协议有一些的数据结构,会有一个固定的标识。前端同学需要访问这个协议,通过这个协议将具体的数据传送给服务器端,服务器端基于这个固定好的协议接受数据,实现前后端互联互通。API就是协议,前后端共同遵从的协议。
eg:登陆功能:后端定义好需要用户名和密码,前端需要将用户名和密码传送给服务器端,服务器端验证成功就好了。
2. Json/xml:属于数据协议。eg:登录名/密码。实际就是通过json这个承载体,可以理解为打包文件,把用户名和密码放到里面,然后通过API这个协议传送给服务器。
3. URL:地址。
4. html/css:web网页使用的布局语言、装饰表
5. 数据库(DB):存储数据,数据查询,检索
6. Git/SVN:管理代码,代码存储的服务。实现多分支管理,远程和本地的开发。【代码仓库】不同的代码同学共同协作。
前端术语:
Activity(Android):每一个屏幕展示的页就是这个,这个界面上所有的逻辑,所有的展示
ViewController(IOS):每一个屏幕展示的页就是这个。同上,只是一个是ios一个是安卓。
lib(第三方库):eg:用百度地图的sdk,可直接使用这项服务(定位服务)第三方库帮助我们做复杂的事情
ListView(Android):其实就是app里面经常能看到的列表,例如微信里面的聊天页面就是个列表。
TableView(iOS):同上。
View:基础组件都是一个view,如一个按钮,一个选择框,一个复选框都是一个view,甚至一段文字的展示都是一个view。指的是具体前端页面展示的一个具体的组件。
第四部分 如何与技术人员沟通
【翻译】【很重要,非技术产品经理90%都会遇到】
产品经理说白话,技术人员说黑话。产品经理需要自己翻译给自己听,给用户听。(哈哈)
产品经理主导沟通方向,实际工作中讨论往往从原本的产品讨论很容易陷入技术细节讨论。应该避免陷入技术细节讨论,从场景和用户体验出发。对实现方案的讨论,非技术产品经理是无法参与的。技术人员找产品经理讨论,往往是确认产品需求但最终就成了讨论技术问题。如何解决这个问题:1)从场景出发,2)从用户体验出发。
真正用户能用的产品。
因此产品经理与开发人员沟通的过程中要把握沟通的方向,要知道聊的是什么,每一次沟通要有目的和结论。沟通要往哪个方向引导。一切以用户场景和用户体验为主。否则讨论就会走向偏题的状态。这也不是自己擅长的。
如下图为技术人员经常会对产品经理说的话,你是不是很有同感?
如果遇到以上问题:产品经理是改产品设计还是改需求。
产生上述原因可能有产品需求文档里面没写,或者技术人员觉得这个重新做成本太大。实现不了,或者技术人员直接告诉你只是后端的问题。
如何解决上述问题,举两个例子:
【引导型沟通,有序的沟通】
第一个“这个实现不了”:不要被技术所限制,但要在技术边界之内。产品是需要衡量投入产出比。挖掘技术人员背后的初衷,是因为时间不够(讲清楚紧急程度,就改为可实现了),还是技术难度(技术人员也是需要技术调研),另一种是确实技术实现不了。一定要搞清楚是哪一种,不要随意更改需求,不然是对用户的不负责,是对产品的不负责。
第二个“这是后端的问题”:当我们使用产品时发现了一个bug,可能第一时间直接问开发同学或测试,问怎么解决,技术人人员往往告诉你是后端的问题。那么你应该找谁,是找前端是找后端,正确的方式是不应该直接找后端,而是需要问前端:你是如何排查这个问题的,我们应该怎么解决这个问题,如果要解决这个问题,我能为你做什么,一起探讨这个问题的解决方案。
分析技术人员的需求:Want or Need。需求的本质。
用户:需要一个更快的马
福特:提供了一个汽车
第五部分 非技术背景产品经理学习指南
懂用户比懂产品重要,懂产品比懂技术重要
设计一款产品:最先考虑的不应该是技术,而应该是用户,需要我们在什么场景下位他们解决什么问题。这样才能更好的设计,呈现给用户。产品本身不能过于流程化和机械化。设计一款符合用户使用习惯的产品。
总结:
1. 发挥非实现模式思维的优势,理解并思考场景
2. 多与技术人员沟通,理解实现模型思维
3. 学会讲故事。讲故事能力非常重要,往往都说产品经理就是ceo的学前班,这个我很认同。产品经理需要面向运营、市场、财务、法务等等。产品经理要让这个故事讲得精彩,让大家一起把事情做好。这个故事的引导者和制造者就是产品经理。并且产品经理需要有广度思维。
最终我们所创造的用户价值,才是最终能带来实际效果的,才能造福用户,被这个行业和市场所接受,我们应该为这个行业创造价值,为这个行业改变一些事情,为这个世界做一些事情。
最后送给大家:
不想改变世界的产品经理不是好的产品经理,产品经理要有一颗创造、改变和实现一些东西的初衷和想法。不然产品经理就沦为了功能型产品经理。什么是创造型产品经理,什么是功能型产品经理,相信大家都有自己心里面的一些思考。
网友评论