对象：非技术人员
目的：高效与技术人员沟通
掌握技能包含主要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的学前班，这个我很认同。产品经理需要面向运营、市场、财务、法务等等。产品经理要让这个故事讲得精彩，让大家一起把事情做好。这个故事的引导者和制造者就是产品经理。并且产品经理需要有广度思维。
最终我们所创造的用户价值，才是最终能带来实际效果的，才能造福用户，被这个行业和市场所接受，我们应该为这个行业创造价值，为这个行业改变一些事情，为这个世界做一些事情。
最后送给大家：
不想改变世界的产品经理不是好的产品经理，产品经理要有一颗创造、改变和实现一些东西的初衷和想法。不然产品经理就沦为了功能型产品经理。什么是创造型产品经理，什么是功能型产品经理，相信大家都有自己心里面的一些思考。
非技术人员
目的：高效与技术人员沟通
掌握技能包含主要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的学前班，这个我很认同。产品经理需要面向运营、市场、财务、法务等等。产品经理要让这个故事讲得精彩，让大家一起把事情做好。这个故事的引导者和制造者就是产品经理。并且产品经理需要有广度思维。
最终我们所创造的用户价值，才是最终能带来实际效果的，才能造福用户，被这个行业和市场所接受，我们应该为这个行业创造价值，为这个行业改变一些事情，为这个世界做一些事情。
最后送给大家：
不想改变世界的产品经理不是好的产品经理，产品经理要有一颗创造、改变和实现一些东西的初衷和想法。不然产品经理就沦为了功能型产品经理。什么是创造型产品经理，什么是功能型产品经理，相信大家都有自己心里面的一些思考。
