快捷搜索:

您的位置:环球彩票登陆 > 环球彩票登陆 > 1 产物手艺联系之道,怎样与手艺人士高效联系(

1 产物手艺联系之道,怎样与手艺人士高效联系(

发布时间:2019-11-03 18:27编辑:环球彩票登陆浏览(57)

    笔者一直在强调后端开发。不是因为前端开发不重要,而是后端犹如高楼大厦的地基,如果地基不稳或者地基打的不深,那么哪怕装修的再漂亮,也不稳不高。

    产品经理主导沟通方向,实际工作中讨论往往从原本的产品讨论很容易陷入技术细节讨论。应该避免陷入技术细节讨论,从场景和用户体验出发。对实现方案的讨论,非技术产品经理是无法参与的。技术人员找产品经理讨论,往往是确认产品需求但最终就成了讨论技术问题。如何解决这个问题:1)从场景出发,2)从用户体验出发。

    环球彩票登陆 1

    系统逻辑是指:与开发人员就当前产品和未来产品可能存在的延展性,进行讨论,得出的一套系统流程图。

    【很重要,非技术产品经理90%都会遇到】

    看着移动端的小伙伴把项目提交到应用商店后,我便回到自己的工位上,回想起整个项目从需求到这一刻,经历的“风风雨雨”,着实令人难忘。在这个项目中,印象最深的不是产品、需求方面的工作,而是整个项目的推进工作,也让我明白了在一个创业团队中,在团队资源有限的情况下,产品负责人项目推进能力的重要性。

    这里稍稍总结一下,业务逻辑的目的在于:开始需求评审前,以生动形象的方式向大家描述业务场景,帮助大家更好的理解本次开发的需求和产品可能的延展性。

    系统运维:服务器管理与整体维护,应用发布。如服务器数量是否够等。

    项目规划的粒度

    其实这部分是属于项目经理的工作,但是由于项目的初期阶段我们还没有项目经理,所以这部分工作也就由产品经理来负责了。当时是开发人员通过功能列表各自评估一下每个功能需要的开发时间,并商讨确定出主要核心模块大概的前后端联调时间,然后我这边就根据大家反馈的时间来汇总,按照MVP模式来制定以功能为粒度的项目开发计划,以周为一个里程碑,然后每周按照功能的优先级完成开发,并且每天会通过每日早会以及日报来把控项目的进度。

    当时按照上面的规划进行了两周的开发后,其弊端慢慢浮现。对于每周需要完成的功能,开发人员都会存在一个或两个功能未能完成,或是所有功能都做了,但流程却跑不通。

    当时对于这个情况很困惑,问题出在哪里?是不是当前项目规划存在问题?

    如果我是开发人员,这样的安排我能不能完成?进行了换位思考后,我发现当时的项目规划执行起来不好下手,虽然每周的目标、优先级都很明确,但是每天的任务却是不确定的。也就是说,出现问题的关键是任务安排的粒度太粗了,需要开发人员有很好的执行力。但是团队在这方面尚有欠缺,所有才出现的这样的情况。

    既然问题确定了,那就做优化方案,目标是:通过把任务粒度细化来对项目进行推进,从而使项目能按时顺利完成。那么该如何细化任务?虽然自身有技术背景,但没有接触过后台开发,所以无法对开发那边做出很细的任务安排。正在此时,一个在《今日头条》做项目经理大牛加入了我们团队,与我共同推进项目。

    项目经理的加入,恰恰弥补了我在技术统筹方面的不足。所以项目经理加入后的第一周,我们就针对团队的当下情况做了一个优化方案,在大的方向上按照之前的安排,就是项目规划以及以周作为里程碑,而优化的地方就是把每周的目标细化并指定到每天、每人手上,然后通过每日早会来统筹安排当天的工作来把控、推进项目的进度。

    虽然每周的进度还是会因为一些不可控的因素导致一些功能的延期,但总体是可控的,整个团队的工作流程也顺畅了很多。

    从这件事中也让我明白了:

    • 产品经理在未了解技术管理的情况下进行项目推进时存在一定难度的。需要加强对开发流程的了解。
    • 在项目推进时,任务安排要根据每个人的能力来制定粒度的粗细,这很重要,会直接影响项目的开发进度。

    那么,如何才能深刻了解业务呢?

    1. URL:地址。

    2. html/css:web网页使用的布局语言、装饰表

    3. 数据库:存储数据,数据查询,检索

    首先,就是产品需求评审会。

    我之前从事一家仓储物流公司,负责前后台所有产品线的设计。

    2. Json/xml:属于数据协议。eg:登录名/密码。实际就是通过json这个承载体,可以理解为打包文件,把用户名和密码放到里面,然后通过API这个协议传送给服务器。

    下面将会通过在这个过程中踩过的坑,以及如何从坑中跳出来,来说明产品经理该如何根据团队的情况来进行项目推进。

    PS:系统逻辑的决定权在于开发设计;底层数据库,表结构的搭建也在于开发设计。

    真正用户能用的产品。

    • 产品需求评审会
    • 项目规划
    • 每日早会
    • 测试
    • 上线
    • 阶段总结会

    后台系统就像是建筑根基,假如根基打不稳,装修得再漂亮也都是徒劳。所以,所有的后端开发和优化都应当摆在前端之前,产品经理也应当在产品开发设计之前就完善后端逻辑,为前端产品设计做好“后勤工作”。

    最终我们所创造的用户价值,才是最终能带来实际效果的,才能造福用户,被这个行业和市场所接受,我们应该为这个行业创造价值,为这个行业改变一些事情,为这个世界做一些事情。

    下面我就项目推进分为以下6个阶段:

    所以,真正在开始一场评审会前,产品经理需要为在场所有人,清晰地描述本次开发需求的业务场景和业务逻辑。

    后端开发:服务端开发,包括数据库设计与开发,应用接口开发。

    每日早会

    每日早会,敏捷开发的一个重要环节。

    每日早会的主要形式是把团队成员都组织在一起,然后根据由产品经理或项目经理来组织,每个成员过一下昨日工作完成的情况(如果未完成,那未完成的原因是什么?),遇到了什么问题以及今日的任务安排,通过这种方式来把控一下当先的项目进度。

    每日早会几乎贯穿了整个项目开发阶段,如果把项目开发阶段比作一条链条的话,那么每日早会就是链条中的节点。每日早会不仅可以让产品经理更好的把控项目的情况以及当前的进度,而且还可以尽早发现问题,对问题进行分析解决。

    每日早会是项目推进的有效手段:

    • 注重3个方向,昨日完成情况、是否存在问题、今日任务安排
    • 早会的时间控制在15分钟内,不占用大家过多的时间

    我个人观点:产品经理需要会写代码,需要懂技术,但切忌精通。

    实现代言人:技术人员

    总结

    从产品需求评审会、项目规划、每日项目推进、测试以及阶段总结会,整个项目的推进工作很好体现了产品经理的执行能力,虽然在大部分公司中这个阶段的工作是由项目经理负责的,但是产品经理也需要有把控产品的质量和进程能力,真正做到产品的主人,从需求和项目推进的过程中中,做到对产品负责。

    就此可以看出,系统逻辑讨论和讲述的对象更偏向于开发人员。

    其他:技术人员往往不具备同理心,及换位思考的能力(产品方面,生活其他角度除外)。但是产品经理必须同理心及换位思考的能力。这是产品经理必须具备的一种必备素质。所以产品经理需要内心强大。来抵抗一些来自程序员方面的压力。但最终产品经理任然需要站在产品角度,用户角度去完成产品设计。也是基于此方面(思维方式及心理能力)产品经理和技术人员是不同的,所以这也是产生分歧的根本原因。

    产品需求评审会

    几乎每个产品在正式开发前的必经环节。项目的相关人员通过需求评审会对产品经理输出的需求和解决方案进行合理性、可行性分析,而且还可以通过需求评审会来理解功能逻辑以及业务逻辑。

    由于当时项目时间比较紧,会议后没有给大家太多的时间去理解和思考业务上的逻辑,大家当时也表示没有明显的问题,便根据项目规划进行正式进行开发了。

    到了项目的后半段才发现,在项目推进时遗漏了两个重点,第一是我们当时的团队刚成立没多久,大家的关注点都在乎自己的工作;第二是技术小伙伴们不爱看产品需求文档。这样就导致了对产品业务和需求理解不透彻,进而导致开发期间效率低下。

    这是项目延期很大的原因。不过经过这件事深刻的认识到,产品经理在产品需求评审会(评审前、评审时、评审后)阶段,需要重视一下3点:

    • 首先是确保需求、业务通过评审,并没有明显错误
    • 确保开发人员对产品需求和业务逻辑有深刻的理解
    • 深刻理解产品的需求、业务和功能后,要对项目开发时间做一个精确的评估,并对这个时间负责

    产品评审之后就进行项目规划。

    从理论角度上说,信息的传递成功率大致在60%,那么另外的40%就需要通过会后反复确认和沟通中弥补。

    产生上述原因可能有产品需求文档里面没写,或者技术人员觉得这个重新做成本太大。实现不了,或者技术人员直接告诉你只是后端的问题。

    提Bug的方式

    项目开发到了后期,便进入测试阶段。

    从现在来看,当时我们的整个测试模块安排的不太规范,主要反映在两个问题上,首先是测试安排的粒度过大,是以MVP中的小版本为单位;第二个问题是我们团队前期没有测试人员,只有产品经理进行辅助测试,所以造成测试的深度不够,后期的版本质量不过关,出现很多细节问题,甚至是流程性的问题。

    在项目的后期,我们加入的测试人员,开始着重对产品的第一个版本进行集中测试。对于整个测试的过程,总结下过程中需要注意的地方。

    • 项目后期,后台方面的工作量较少,所以测试出现的bug,如果不是明显的前端后题,应先把bug指派给后台,排除是后台的问题之后再指派给前台。
    • 测试提交的Bug应该置于一个Bug池中,然后由产品经理设置Bug解决的优先级并指派人进行跟进。
    • Bug池中的Bug修复后,需要让测试再次确认后没问题,才能算正式解决,防止开发因为遗漏,误以为解决的Bug,导致后期再次出现同样的问题。
    • 移动端每天下班前把Bug修复后,需要发一个新的测试版本到内测管理平台中,并更新内测版本号以及修复的内容,这个很重要。在我们项目推进时Android开发小哥就没有这种习惯,导致测试妹子还要去一个个Bug对定位,大大增加了测试的工作量。

    但是产品经理务必在开发设计前找开发人员,至少是后端开发,详细的讨论清楚产品往后的推演路径和发展的可能性,以便开发人员获取可能遗漏的信息,完善后端逻辑。

    目的:高效与技术人员沟通

    阶段总结会议

    经过一个月的开发时间,我们完成了第一个版本的开发,但是仅限于完成开发而已,功能流程勉强跑通,依然存在着很多问题,这时进行阶段总结会议尤为重要。

    会议首先要明确会议的目的:

    • 说明当前情况
    • 暴露问题
    • 找出问题原因
    • 解决问题

    然后通过当前版本与计划版本的对比,抛出问题的严重性。把当前存在的主要问题暴露出来,比如说:

    • iOS上线审核问题
    • xxx模块未跑通
    • xxx功能存在问题
      ...

    接着引申出:为什么会出现现在这种状况?
    产品经理作为负责人把目前每个模块存在的问题罗列出来,如下图,是我在阶段总结会议上针对目前团队列出来的部分模块问题,并附上一些从产品经理角度出发的建议:

    环球彩票登陆 2

    模块问题

    针对每个存在的问题,大家在会议上进行针对性的讨论,并寻找出解决的方案,然后在后面的工作中进行优化。接着就着重强调优化方案的执行力(因为经历过很多,解决方案仅出现在会议上而已),如果遇到同样的问题,大家就需要马上反应,不然就需要项目经理、产品经理去辅助执行。

    对于阶段总结会,最主要的明确几点:

    • 会议目的
    • 说明当前情况
    • 暴露问题
    • 找出问题原因
    • 解决问题
    • 落实执行
    1. 逻辑

    用户:需要一个更快的马

    这是为了帮助开发更深刻地理解业务和未来可能存在的技术瓶颈,将底层框架想的更全面,满足往后更多的业务需求。

    ListView:其实就是app里面经常能看到的列表,例如微信里面的聊天页面就是个列表。

    讲完了业务的重要性,千万别觉得假大空。这的的确确是我从事产品经理以来,最为深刻的认知,希望大家能够细细品味。

    真正用户能用的产品。

    这里推荐大家使用,情景化描述:以角色扮演为表达形式,配以肢体语言和日常化情境比拟作为加深理解

    【很重要,非技术产品经理90%都会遇到】

    1. 业务

    Activity:每一个屏幕展示的页就是这个,这个界面上所有的逻辑,所有的展示

    本文关键词:业务场景串联,逻辑串联,模块化设计。

    【要站在用户思维,否则以技术思维可能最后做出来产品过于生硬,偏工具】

    主要步骤分为:单人或多人角色扮演:你可以单人多角色,也可以邀请在场人一起参与,这有点像自导自演的一场戏份。你需要将单调的业务,通过场景化的演绎,让在场的人身临其境,仿佛在共同参与收货入库的操作。动态地表达:在表演过程中,你不能原地杵着不动,光靠说是不行的,你需要动态地表达——一般通过手舞足蹈的表演和写黑板两种方式结合阐述。代入式的情境比拟:如果业务场景比较罕见,大多数人不太多见,那么,就需要产品经理通过代入式的情境比拟,向在场的人描述一种比较常见的业务场景。

    第三部分 常用技术术语

    本文先阐述:业务和逻辑,模块化会以大量的对比图文,来生动的向大家展示。

    技术思维

    将已知和未知的产品发展可能性告知开发:

    第四部分 如何与技术人员沟通

    举个例子:

    最后送给大家

    在后台系统摸爬滚打的这几年里,我总结了三个要点:业务、逻辑、模块化。

    1. 功能实现

    2. 开发难易

    3. 后期维护

    4. 改动成本

    环球彩票登陆 3

    懂用户比懂产品重要,懂产品比懂技术重要

    想必很多产品同学都碰到过这种场景:产品在不断迭代过程中发现,原本的架构无法支撑未来发展的可能。

    最后送给大家:

    环球彩票登陆 4

    第二个“这是后端的问题”:当我们使用产品时发现了一个bug,可能第一时间直接问开发同学或测试,问怎么解决,技术人人员往往告诉你是后端的问题。那么你应该找谁,是找前端是找后端,正确的方式是不应该直接找后端,而是需要问前端:你是如何排查这个问题的,我们应该怎么解决这个问题,如果要解决这个问题,我能为你做什么,一起探讨这个问题的解决方案。

    那么,有多少产品经理是直接跑上来就丢出PRD文档或交互原型图,侃侃而谈的呢?

    对象:非技术人员

    环球彩票登陆 5

    1. API:服务器端的应用接口。应用接口类似于服务器端定义好的一个协议,这个协议有一些的数据结构,会有一个固定的标识。前端同学需要访问这个协议,通过这个协议将具体的数据传送给服务器端,服务器端基于这个固定好的协议接受数据,实现前后端互联互通。API就是协议,前后端共同遵从的协议。

    系统逻辑与业务逻辑的侧重点不同。

    技术思维

    本篇文章开始,笔者会带着大家从0到1,搭建一套完完整整的营销中心(集业务、营销、结算为一体)。

    总结:

    希望能帮助新晋产品经理快速上手,少走冤枉路。

    CTO:技术部门leader或产品

    写代码(这里强调至少会写简单的SQL语言)能够帮助产品经理自助查询某些数据,便于数据统计和分析。但是切忌精通,是因为有很多职场上从技术转产品的同学,会非常纠结于产品实现的难易度和可能性,抑制了对产品本身价值体现的思考和创新思维。

    后端开发:服务端开发,包括数据库设计与开发,应用接口开发。

    本文由 @小鸡腿 原创发布于人人都是产品经理,未经许可,禁止转载

    lib:eg:用百度地图的sdk,可直接使用这项服务第三方库帮助我们做复杂的事情

    要想做好后台系统,最重要的的就是了解整个业务流程和体系。甚至要比其他所有人都要更清晰,能做到各业务线之间的业务场景串联。

    前端开发:分为网页前端、移动客户端前端,移动客户端又分为Android、ios、Windows Phone【安卓设计和ios有不同的开发设计规范】

    业务逻辑刚刚讲过,在评审会开始前需要向大家阐释清楚,那么会后为什么还要找开发人员确认呢?

    掌握技能包含主要3点:

    众所周知,产品经理都会组织需求评审会,向业务、开发(前后端、测试、运维等)、运营等部门的人讲解本次开发的需求。

    产品思维:更加符合场景,贴合用户使用习惯,遵从人性。

    从产品角度解决问题或提出建议:在与开发讨论完所有产品可能后,并不是将问题全部留给开发同学,而是需要从产品的角度出发,想想是否可以从产品设计上帮助共同解决。

    1. 技术职能划分了解

    2. 常用技术术语了解

    3. 理解开发人员思维(技术思维vs产品思维)

    题图来自 Unsplash,基于 CC0 协议

    ViewController:每一个屏幕展示的页就是这个。同上,只是一个是ios一个是安卓。

    假设我把业务线拆分成:仓储、物流、订单,那么就需要3名前台产品经理和3名后台产品经理(不纠结人员配置,仅作为举例)。

    如下图为技术人员经常会对产品经理说的话,你是不是很有同感?

    至少笔者做产品之处就是如此,这显然是不对的。因为对于开发和运营等非业务层的人来说,他们不了解业务场景,更别提业务逻辑了。

    前端术语:

    每个主题大约会拆分成三大块:规划阶段、设计阶段、开发阶段。

    备注:以上的微信通讯录及会话设计操作路径示例,本人按照上面操作实操时却发现回退到的是上一个页面,而非作者说的返回第一个tab“微信”,可能是新版本的微信改了吧,作者当时是旧版本吧。不过实际中确实很多类似这种例子。尤其是用户使用习惯。

    说完了业务逻辑,我们来说说系统逻辑。

    掌握技能包含主要3点:

    好了,扯的有点远了,我们继续说回系统逻辑。

    3. 学会讲故事。讲故事能力非常重要,往往都说产品经理就是ceo的学前班,这个我很认同。产品经理需要面向运营、市场、财务、法务等等。产品经理要让这个故事讲得精彩,让大家一起把事情做好。这个故事的引导者和制造者就是产品经理。并且产品经理需要有广度思维。

    评审会后,与开发人员再次确认业务逻辑:

    第一部分 技术思维vs产品思维

    业务逻辑更强调场景和流程,而系统逻辑更强调开发视角的底层逻辑和数据库的关系。

    第五部分 非技术背景产品经理学习指南

    道理就在于沟通过程中,信息传递和理解的递减效应。我们无法保证评审会上,所有人精神都高度集中,所有人的理解都完全相同。

    不想改变世界的产品经理不是好的产品经理,产品经理要有一颗创造、改变和实现一些东西的初衷和想法。不然产品经理就沦为了功能型产品经理。什么是创造型产品经理,什么是功能型产品经理,相信大家都有自己心里面的一些思考。

    我继续举个例子:假设本次评审的是这个功能点,我们需要将仓库收货入库的这个场景形象生动地描述给在场人看,那么,如何形象生动?如何确保大家都能理解呢?

    如何解决上述问题,举两个例子:

    业务逻辑就是指:在了解完业务场景后,能够将业务场景转换为流程图,从而将业务层的流转关系清晰地表达出来。

    目的:高效与技术人员沟通

    全篇会分为三大主题,分别是:认识后台系统、手把手搭建营销中心、收银结算平台。

    产品思维vs技术思维实例:

    关键词:业务场景串联

    备注:以上的微信通讯录及会话设计操作路径示例,本人按照上面操作实操时却发现回退到的是上一个页面,而非作者说的返回第一个tab“微信”,可能是新版本的微信改了吧,作者当时是旧版本吧。不过实际中确实很多类似这种例子。尤其是用户使用习惯。

    PS:代入式的情境比拟不到万不得已时,慎用。因为,新的情境或者不恰当的情境可能会带来更多的困惑和费解,从而钻进死胡同无法自拔。

    技术思维:堆栈式设计,即从哪里进入,就返回到哪里。(路径为1-2-3 / 回退路径即为3-2-1)

    笔者从小白至今,基本都在接触后台系统,大到日GMV上亿的供应链系统、小到内部人员使用的信息维护系统。所以,我会尽可能将自己所知所晓一并奉上。

    最终我们所创造的用户价值,才是最终能带来实际效果的,才能造福用户,被这个行业和市场所接受,我们应该为这个行业创造价值,为这个行业改变一些事情,为这个世界做一些事情。

    此时,作为仓储后台系统的产品经理,不仅需要了解仓储的业务逻辑,还需要清晰的了解物流和订单的业务逻辑,并且要做到将三者的业务逻辑无缝串联,甚至连财务都需要了如指掌。

    懂用户比懂产品重要,懂产品比懂技术重要

    逻辑是个很宽泛的词汇,这里为大家拆分为两点:业务逻辑和系统逻辑。

    1. URL:地址。

    2. html/css:web网页使用的布局语言、装饰表

    3. 数据库:存储数据,数据查询,检索

    笔者很严肃的说:没有任何捷径,只有亲自到一线业务场景中实际操作,才会有最完整的认知。

    非技术人员

    在会后沟通过程中,除了再次描述业务逻辑外,更重要的是将已知和未知的产品可能性告知开发,比如:公司既定的业务发展和脑暴的发展可能性。

    几点:周为节点进行产品迭代。高保真的demo。这块是作者公司需要做的。根据笔者经历而言,有的创业公司需要做代码可运行的高保真demo,如需要用demo和投资人沟通融资。大部分公司只需要评审非代码层面的原型及需求文档即可。

    比如:大家对仓库收货的场景不熟悉,你就可以通过类比【在家收快递,收完快递将快递分门别类整理好】这一场景,来帮助大家转化理解。

    如果遇到以上问题:产品经理是改产品设计还是改需求。

    给大家几点建议:

    产品思维vs技术思维实例:

    后台系统的三要点

    其他:技术人员往往不具备同理心,及换位思考的能力(产品方面,生活其他角度除外)。但是产品经理必须同理心及换位思考的能力。这是产品经理必须具备的一种必备素质。所以产品经理需要内心强大。来抵抗一些来自程序员方面的压力。但最终产品经理任然需要站在产品角度,用户角度去完成产品设计。也是基于此方面(思维方式及心理能力)产品经理和技术人员是不同的,所以这也是产生分歧的根本原因。

    环球彩票登陆 6

    ListView:其实就是app里面经常能看到的列表,例如微信里面的聊天页面就是个列表。

    对于产品经理来说:懂技术能够帮助自己了解开发的设计逻辑,不至于提出离谱的需求。并且可以通过开发设计逻辑,优化自己的产品思维,在产品初期的MVP设计,尤为重要。

    前端术语

    举个简单的例子:在做仓储系统时,如果前期开发没有考虑到总分仓和之间的业务逻辑关系,那么往后如果公司发展需要总分仓时,底层逻辑的改动量会比较大,甚至可能大量返工。

    几点:周为节点进行产品迭代。高保真的demo。这块是作者公司需要做的。根据笔者经历而言,有的创业公司需要做代码可运行的高保真demo,如需要用demo和投资人沟通融资。大部分公司只需要评审非代码层面的原型及需求文档即可。

    很多人在讨论:产品经理到底应不应该懂技术?需不需要会写代码?

    设计一款产品:最先考虑的不应该是技术,而应该是用户,需要我们在什么场景下位他们解决什么问题。这样才能更好的设计,呈现给用户。产品本身不能过于流程化和机械化。设计一款符合用户使用习惯的产品。

    那么,作为产品经理,应该如何与开发讨论,得出一套比较完整的系统逻辑呢?

    第一部分 技术思维vs产品思维

    能够做到以上,才算是踏入了后台系统设计的最低门槛。

    分析技术人员的需求:Want or Need。需求的本质。

    产品经理主导沟通方向,实际工作中讨论往往从原本的产品讨论很容易陷入技术细节讨论。应该避免陷入技术细节讨论,从场景和用户体验出发。对实现方案的讨论,非技术产品经理是无法参与的。技术人员找产品经理讨论,往往是确认产品需求但最终就成了讨论技术问题。如何解决这个问题:1)从场景出发,2)从用户体验出发。

    如何解决上述问题,举两个例子:

    第二部分:技术职能划分

    第二部分:技术职能划分

    1. 产品定位

    2. 需求场景

    3. 用户体验

    4. 业务目标

    环球彩票登陆 7图片发自简书App

    技术思维:堆栈式设计,即从哪里进入,就返回到哪里。(路径为1-2-3 / 回退路径即为3-2-1)

    产品思维:更加符合场景,贴合用户使用习惯,遵从人性。

    【要站在用户思维,否则以技术思维可能最后做出来产品过于生硬,偏工具】

    1. 发挥非实现模式思维的优势,理解并思考场景

    2. 多与技术人员沟通,理解实现模型思维

    【引导型沟通,有序的沟通】

    1. 技术职能划分了解

    2. 常用技术术语了解

    3. 理解开发人员思维(技术思维vs产品思维)

    上图为作者的创业公司的一个工作流程。具体公司可能不太一样,但大同小异。

    架构师:负责系统整体技术架构和技术选型仅次于CTO。

    1. 发挥非实现模式思维的优势,理解并思考场景

    2. 多与技术人员沟通,理解实现模型思维

    【引导型沟通,有序的沟通】

    用户代言人:产品经理

    eg:登陆功能:后端定义好需要用户名和密码,前端需要将用户名和密码传送给服务器端,服务器端验证成功就好了。

    1. 产品定位

    2. 需求场景

    3. 用户体验

    4. 业务目标

    实现代言人:技术人员

    6. Git/SVN:管理代码,代码存储的服务。实现多分支管理,远程和本地的开发。不同的代码同学共同协作。

    View:基础组件都是一个view,如一个按钮,一个选择框,一个复选框都是一个view,甚至一段文字的展示都是一个view。指的是具体前端页面展示的一个具体的组件。

    2. Json/xml:属于数据协议。eg:登录名/密码。实际就是通过json这个承载体,可以理解为打包文件,把用户名和密码放到里面,然后通过API这个协议传送给服务器。

    福特:提供了一个汽车

    前端开发:分为网页前端、移动客户端前端,移动客户端又分为Android、ios、Windows Phone【安卓设计和ios有不同的开发设计规范】

    【此处需要划重点,着重记忆,对你以后和技术沟通和理解技术有很大帮助】

    如果遇到以上问题:产品经理是改产品设计还是改需求。

    产品经理说白话,技术人员说黑话。产品经理需要自己翻译给自己听,给用户听。

    产生上述原因可能有产品需求文档里面没写,或者技术人员觉得这个重新做成本太大。实现不了,或者技术人员直接告诉你只是后端的问题。

    第一个“这个实现不了”:不要被技术所限制,但要在技术边界之内。产品是需要衡量投入产出比。挖掘技术人员背后的初衷,是因为时间不够(讲清楚紧急程度,就改为可实现了),还是技术难度(技术人员也是需要技术调研),另一种是确实技术实现不了。一定要搞清楚是哪一种,不要随意更改需求,不然是对用户的不负责,是对产品的不负责。

    福特:提供了一个汽车

    用户代言人:产品经理

    TableView:同上。

    View:基础组件都是一个view,如一个按钮,一个选择框,一个复选框都是一个view,甚至一段文字的展示都是一个view。指的是具体前端页面展示的一个具体的组件。

    环球彩票登陆 8图片发自简书App

    Activity:每一个屏幕展示的页就是这个,这个界面上所有的逻辑,所有的展示

    TableView:同上。

    微信通讯录及会话设计:

    总结

    产品思维

    系统运维:服务器管理与整体维护,应用发布。如服务器数量是否够等。

    从微信第二个“tab”进去,点击好友主页,点击“发消息”,点击左上角“返回”,却退回了第一个tab“微信”

    第二个“这是后端的问题”:当我们使用产品时发现了一个bug,可能第一时间直接问开发同学或测试,问怎么解决,技术人人员往往告诉你是后端的问题。那么你应该找谁,是找前端是找后端,正确的方式是不应该直接找后端,而是需要问前端:你是如何排查这个问题的,我们应该怎么解决这个问题,如果要解决这个问题,我能为你做什么,一起探讨这个问题的解决方案。

    第四部分 如何与技术人员沟通

    产品经理说白话,技术人员说黑话。产品经理需要自己翻译给自己听,给用户听。

    1. 功能实现

    2. 开发难易

    3. 后期维护

    4. 改动成本

    第三部分 常用技术术语

    个人总结:利用用户思维去跟开发解释更符合用户场景。而不是技术实现。这也是我在工作中经常遇到的。有时候可能太过于同理心了【比如特别“同情”技术人员】就会把一些“不易”开发的省却成简单的,这其实很多时候是不正确的做法。这样往往设计的产品过于机械化、工具化。产品经理应该站在用户思维,不要走偏记得!

    微信通讯录及会话设计:

    设计一款产品:最先考虑的不应该是技术,而应该是用户,需要我们在什么场景下位他们解决什么问题。这样才能更好的设计,呈现给用户。产品本身不能过于流程化和机械化。设计一款符合用户使用习惯的产品。

    因此产品经理与开发人员沟通的过程中要把握沟通的方向,要知道聊的是什么,每一次沟通要有目的和结论。沟通要往哪个方向引导。一切以用户场景和用户体验为主。否则讨论就会走向偏题的状态。这也不是自己擅长的。

    ViewController:每一个屏幕展示的页就是这个。同上,只是一个是ios一个是安卓。

    用户:需要一个更快的马

    第五部分 非技术背景产品经理学习指南

    上图为作者的创业公司的一个工作流程。具体公司可能不太一样,但大同小异。

    如下图为技术人员经常会对产品经理说的话,你是不是很有同感?

    分析技术人员的需求:Want or Need。需求的本质。

    产品思维

    1. API:服务器端的应用接口。应用接口类似于服务器端定义好的一个协议,这个协议有一些的数据结构,会有一个固定的标识。前端同学需要访问这个协议,通过这个协议将具体的数据传送给服务器端,服务器端基于这个固定好的协议接受数据,实现前后端互联互通。API就是协议,前后端共同遵从的协议。

    3. 学会讲故事。讲故事能力非常重要,往往都说产品经理就是ceo的学前班,这个我很认同。产品经理需要面向运营、市场、财务、法务等等。产品经理要让这个故事讲得精彩,让大家一起把事情做好。这个故事的引导者和制造者就是产品经理。并且产品经理需要有广度思维。

    eg:登陆功能:后端定义好需要用户名和密码,前端需要将用户名和密码传送给服务器端,服务器端验证成功就好了。

    6. Git/SVN:管理代码,代码存储的服务。实现多分支管理,远程和本地的开发。不同的代码同学共同协作。

    因此产品经理与开发人员沟通的过程中要把握沟通的方向,要知道聊的是什么,每一次沟通要有目的和结论。沟通要往哪个方向引导。一切以用户场景和用户体验为主。否则讨论就会走向偏题的状态。这也不是自己擅长的。

    架构师:负责系统整体技术架构和技术选型仅次于CTO。

    不想改变世界的产品经理不是好的产品经理,产品经理要有一颗创造、改变和实现一些东西的初衷和想法。不然产品经理就沦为了功能型产品经理。什么是创造型产品经理,什么是功能型产品经理,相信大家都有自己心里面的一些思考。

    环球彩票登陆 9图片发自简书App

    CTO:技术部门leader或产品

    第一个“这个实现不了”:不要被技术所限制,但要在技术边界之内。产品是需要衡量投入产出比。挖掘技术人员背后的初衷,是因为时间不够(讲清楚紧急程度,就改为可实现了),还是技术难度(技术人员也是需要技术调研),另一种是确实技术实现不了。一定要搞清楚是哪一种,不要随意更改需求,不然是对用户的不负责,是对产品的不负责。

    lib:eg:用百度地图的sdk,可直接使用这项服务第三方库帮助我们做复杂的事情

    从微信第二个“tab”进去,点击好友主页,点击“发消息”,点击左上角“返回”,却退回了第一个tab“微信”

    个人总结:利用用户思维去跟开发解释更符合用户场景。而不是技术实现。这也是我在工作中经常遇到的。有时候可能太过于同理心了【比如特别“同情”技术人员】就会把一些“不易”开发的省却成简单的,这其实很多时候是不正确的做法。这样往往设计的产品过于机械化、工具化。产品经理应该站在用户思维,不要走偏记得!

    【此处需要划重点,着重记忆,对你以后和技术沟通和理解技术有很大帮助】

    本文由环球彩票登陆发布于环球彩票登陆,转载请注明出处:1 产物手艺联系之道,怎样与手艺人士高效联系(

    关键词: 高效 中心 系统 后台