本篇主要描述产品开发落地的过程中存在的一些问题，从产品向开发人员交付产品、产品开发、开发管理、开发人员职业晋升等角度展开。希望产品人员和开发人员可以更好的相互理解，彼此携手确保产品的落地成功。
在一个软件开发团队中，产品人员与开发人员打交道最多，却也最容易导致关系紧张。
产品人员研究的是人，开发人员研究的是计算机，这导致了两者在思维认知、沟通语言、表达技巧、价值观念、专业素养（职业发展）、冲突解决方式等层面都存在很大的差异，如果对这种差异没有很好的认知，就无法有效的解决产品开发落地过程中可能产生的冲突，极有可能会对产品开发带来极坏的影响。
为了有效的解决产品开发落地过程中可能产生的冲突，有必要对产品与开发人员的差异进行系统的研究。
1.1思维认知
开发人员构建程序代码的过程是一个不断训练自己发现问题解决问题能力的过程，开发人员按照产品经理给的功能需求寻找可以完成该功能的程式表达方式并对写出的程式反复的调试，确保输出的结果能满足功能需求。
开发人员在实际工作场景中需要不断的思考为什么会存在这个问题以及如何解决这个问题？在思维方式不断的被训练的过程中，绝大部分开发人员会成为实用主义者，而且越是优秀的开发人员越是优秀的实用主义者。刨根问题、追根溯源、解决问题是他们这类实用主义者的典型特征。
而产品经理的核心是挖掘用户的需求，为用户创造富有价值的产品。基于这样的职业理念，在不断的训练自己思维方式的过程中，有些产品经理会成为理想主义（可以称之为情怀）者。
绝大部分实用主义者常常考量的是能用就行、能实现功能就好等；而理想主义者考虑的则考虑的是必须完美的呈现给用户，表现的不完美是不能接受的。理想主义者要想实现自己的想法只有不断地推动实用主义者，在这样的场景下一群实用主义者和一群理想主义者杀得天昏地暗貌似没有什么惊奇的。
1.2沟通语言
开发人员最常用到的语言是计算机程序语言，计算机程序语言是强逻辑关联的，在使用程序语言的过程中不断地训练着逻辑关联思维，开发人员在这种不停的训练过程中成为一群逻辑思维极度发达的聪明人。
他们在表达自己的语言时，充满了逻辑关联其中，他们潜意识里会很难接受没有逻辑关联的表达。产品经理说做这个功能，当他们知道自己为何而做和不知道，知道他们做的东西之间的逻辑关联和不知道，他们的战斗激情是不一样的。
而非开发类的其他人员，绝大部分我们会陈述一个事实或现象，很少会深入思考其背后存在的逻辑关联或者问题的根源是什么。在实际沟通场景中，当开发人员刨根问底的追问一个，我们从来没有考虑过的问题时，很少有人能长时间控制的住自己一点情绪也没有。
要从沟通语言上达成关联，作为产品人员来说，一方面在产品构建的时候应该深入思考为什么要做某个功能，另外一方面要深入思考功能背后之间的内在关联和逻辑关系，再一方面可以学习或了解一些开发方面的专业词汇。
如果产品经理能有以上的种种准备，则一方面做好了应对开发人员挑战时的被动场景，另外一方面又可以使用开发人员可以理解的语言进行沟通，通过有效沟通必然可以避免很多问题。
1.3表达技巧
因为开发人员绝大部分打交道的是计算机，开发经验越久的人和人打交道的时间越少，所以绝大部分开发人员心思比较单纯，不太擅长和人打交道，甚至不懂得什么是委婉的表达，他们比较喜欢直来直去。
在实用主义者的世界中，有啥说啥、直来直去只是为了更高效的、更好的解决问题，他们很少会意识到他们表达的方式或者他们说话的内容伤害到了心思细腻而敏感的人，比如某些产品经理。
这种缺乏技巧的表达是这个群体普遍存在的问题，因此在实际工作场景中如果遇到了类似的问题，作为非开发人员应该尝试着去理解他们的这种行为，并且不用太往心里去。
怀着上述开放包容的心态和产品开发人员接触，并且真正意义上解决他们的疑惑，说服他们实现产品需要实现的功能并不是一件特别困难的事儿，并且会发现和他们融为一体也是如此的轻而易举。
1.4价值观念
人的价值观是有差异的，也正是因为这些差异的存在而让社会丰富多彩。开发人员和产品人员难免也会存在很多差异的价值观念，在团队组建初期应该尽量选择认同相同价值观的人，允许在基于共同认同的价值观的基础上存在差异，但是价值观从本质上就是存在差异的情况还是应该尽量避免。
从产品层面来说，不同的产品对开发成员的价值观要求是不同的。从团队的层面来说，不同的团队其对开发成员的价值观要求也是不同的。把具备相同价值观的人组织在一起是确保团队内部不会出现什么大问题的必要元素。
具备相同价值观的人，在行为方式上也会有很大的差异，团队成员应该尊重和理解这种差异的存在。这种差异的存在固然会增加一些沟通达成一致的时间成本，但是也同时增加了团队自身的活力。
认同相同价值观念的人与不认同相同价值观念的人相比，认同相同价值观念的人通过沟通达成一致显然更为容易。
1.5专业素养
产品开发是一件需要专业技能和职业素养才能完成的一项工作，根据开发人员掌握技能的专业程度和深入程度不同，其实际工作场景中解决问题的能力不同，划分出不同的能力等级用以区分。
专业技能是指开发人员理解产品需求、搭建系统架构、开发产品功能、寻找问题根源、解决开发问题的技能能力，专业技能的强弱直接影响到产品构建方案的好坏，也直接影响到产品未来的性能表现。
职业素养是指开发人员职业道德、时间管理、与人沟通、情绪控制等方面的能力，职业素养的高低可能会影响到产品未来安全性，并且对团队效率的影响巨大。
在现实工作场景中，很多优秀的开发人员具备很强的自我反思和自我调整能力，这些人通过自我分析会发现自己身上存在的一些弊端，并且会去思考如何避免自身上的这些缺点。
这类开发人员的可成长性和可塑造性，以及这类开发人员未来的成长空间都是巨大的，因此在团队构建时选择开发人员就应该选择具备更高专业技能和职业素素养的成员。
1.6冲突解决方式
冷对抗、排斥、抗拒、拒绝等是开发人员在遇到冲突时通常会表现出来的行为方式，如果不能有效的帮开发人员把心结解开，开发人员有可能将长久的处于这种情绪当中，而且会让人感觉到无法沟通和交流。
开发人员之所以会采取这种方式，一方面是职业从业环境会让他们形成这种行为方式，另外一方面是中国文化中本身比较内敛的文化因子的深层次影响。
产品开发人员在实际工作场景中遇到类似的问题时，可以充分分析开发人员在某种情境下采取这种方式的原因，发现开发人员背后深层次的需求，根据发现的深层次需求构建对应的解决方案。
产品开发是一个系统工程，了解产品的使用场景、确定产品终端、明确产品运行环境、选择开发语言、构建产品架构、组建研发团队、确立开发方式、管理开发过程、确保开发结果。
从上述角度来分析，以便非开发人员对产品开发有个初步的了解，产品开发以外的人员可以更好的理解产品开发。
2.1使用场景
产品的使用场景根据用户的类别可以划分为组织需求场景和个人需求场景。
面向组织需求场景使用的又可以分为商业需求场景和非商业需求场景，商业需求场景根据使用场景的不同又可以分为金融、财务、采购、生产、仓储、运输、人力资源、通讯、交通、电力、能源、资源、保险等等，非商业需求场景政府公示、税务、交通等等。
面向个人需求场景使用的又可以分为购物、阅读、新闻、视频、旅游、工具、社交、音乐、美化、摄影、理财、系统、生活、出行、安全、教育、健康、娱乐、儿童、办公、通讯等等。
作为产品开发人员来说，了解产品的使用场景是非常有必要的，用户的需求场景不同用到的终端载体不同、可以承载的产品不同、运行的环境也不同、所需的开发语言也有很大不同、技术构建方案也有很大不同。
不同的使用场景用户基数是不同的，不同的用户基数对产品开发的要求也是不同的。不同的使用场景下用户对某种层面的需求可能更为敏感，在产品开发过程中和结果上都要充分满足用户的需求。
2.2产品终端
互联网产品面向用户最终还是要通过终端载体来实现的，随着科学技术的进步，为了满足人们不同的需求场景，越来越丰富的终端载体走入人们日常生活之中。
日常生活中常用的终端载体有手机、pad、电子阅读器、手提电脑、台式电脑、大型计算机等等，面向不同的终端载体开发过程、开发方式、开发人员所需的技能均有所不同。
因此在进行产品开发时确实需要明确承载产品的终端载体是什么，产品需要满足的需求场景是什么，在该需求场景下使用终端载体的便利性。
2.3运行环境
开发出来的形形色色的产品需要在不同的系统环境（操作系统）上运行，可以运行产品的系统环境有windows、Mac os、Ios、Linux、Ubuntu、Android、BSD(Unix)等等。
在不同的操作系统上运行的产品，其开发人员所需掌握的技能、开发的方式、包括开发过程等都会有所不同。不同的系统其开发背景不同，所能适用的场景不同，面向的用户群体不同，用户群体规模也不同。根据产品面向的用户群体以及产品的使用场景的不同，选择产品运行的操作系统。
2.4开发语言
为了让计算机能更好的按照人的命令执行，计算机科学家开发了各种各样的指令，指令的出现极大地提升了人向计算机传达命令的效率。因为早期的计算机指令学习成本高，可识别性较低，科学家在早期指令的基础上开发了更为高级的编程语言，使用编程语言编辑的指令经过对应的编程解析器解析为计算机可以直接执行的指令。
常用的编程语言有：Java、ios、php、C#、C++、JS、JSP、ASP、HTML、shell、xml等等。不同的编程语言其设计背景不同，可以满足的应用场景有所不同。但是随着时间的推移，编程语言版本自身的迭代，其语言可以适用的应用场景也在扩展。
2.5产品架构
一个完整的产品一般可以分为前台、后台、服务器端三大部分，前台主要是指面向最终用户使用的、可视化的部分，后台主要是指用于满足系统运营人员管理、维护、分析等工作的部分，服务器端是指用于对数据进行逻辑处理、管理（增删改查）、实现前后台信息通信的部分。
前台和后台的表现手段主要有浏览器应用、客户端应用，而服务器端则根据不同的系统环境构建不同的服务器端应用。
浏览器应用主要是指以浏览器作为产品面向用户的内容载体产品，其产品表现形式是一堆存储在服务器端的前端代码，当用户在浏览器中输入网址后，通过访问服务器把网页内容拉到本地然后通过浏览器渲染显示。
客户端应用是指以各种运行于操作系统上的软件作为产品面向用户的内容载体产品，根据软件运行操作系统的不同可以分为windows客户端、Mac OS客户端、Android客户端（APP）、ios客户端（APP）等。
服务器端应用是指以各种运行于操作系统上的程序作为产品数据处理、存储、管理（增删改查），满足前台和后台获取信息、存储信息、处理信息需求的综合处理中心。
2.6研发团队
在充分了解了产品的使用场景、确定产品的终端、明确产品运行环境、选择开发语言、构建产品架构之后，可以确定要完成产品开发需要搭配具备哪种技能的人来构成开发团队。
在组建开发团队时，团队的管理人员除了对开发团队人员的技能有要求之外，还应该重点考察开发人员的价值取向是否符合产品的要求，不同的产品在研发阶段对研发的要求可能有所不同。
比如金融类产品牵涉到资金安全的，对研发人员的从业素养、价值取向、个人保密能力等各方面都有很高的要求；比如针对军方的一些特殊应用系统，对研发人员的保密能力要求就会特别突出等。
无论研发怎样的产品，一些基本的价值取向都是相通的，研发人员具备基本的沟通能力、时间管理能力、任务管理能力、承担责任的能力、做事儿有始有终、追求自我的提升、工作具备热情等。
2.7开发方式
不同的产品可以采取不同的开发方式，目前主流的开发方式有瀑布模型、快速原型模型、迭代模型、螺旋模型、W模型、V模型等，不同的开发模型适用的场景不同，但是在现实工作场景中很少采用一种开发方式来满足产品开发的需求，在产品的整个生命周期过程中往往会采用多种开发方式相结合的方式来满足开发方式的选择。
精益创业模式是一种可以使用到产品开发场景中的一种综合产品开发方式，其强调的通过“最小可用品”、“客户反馈”、“快速迭代”三个工具来验证产品满足用户需求场景的价值假设、实现最简可实行产品。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分为多个子项目，每个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。
2.8开发过程
开发过程管理是在确定的开发方式下，根据产品开发的范围、时间和成本约束，制定计划、分解任务、分配任务、跟踪进度、发现异常、处理异常、控制风险的过程，通过产品开发过程的有效管理和管控确保产品按时保质的上线。
范围是指为了满足某种需求场景所需要的产品功能范围，时间是指必须在怎样的时间周期内完成所需要实现的产品功能范围，成本是指在规定的时间内完成对应的功能团队所需要投入的总的成本（资金等）。
从理论上来说范围、时间、成本三个要素都满足要求，产品开发的过程才是成功的。但是在现实开发场景中，很多时候三个要素同时满足很难达到，因此在执行层面上会根据实际情况做一些妥协，选择其中的两个要素满足而调整另外一个要素。
分解任务的过程是根据对产品功能范围内包含的功能拆分为子功能的过程，有些产品功能复杂度太高可能需要对子功能进行多次拆分；在任务分解过程中根据产品功能所需技能的种类和专业程度的不同进行拆分是常见的拆分方式，在对复杂功能拆分时会考虑其工作量的可评估性（也即是说：如果功能过渡复杂无法准确评估其工作量，则可以经过多次拆分，直到可以准确评估工作量的子功能为止）。
任务分配的过程是根据团队内开发成员的人员配置情况、个人能力大小、完成任务的效率高低、任务完成的质量、人员手头任务现状、任务与人员的适配性等情况进行综合分析，把分解的任务分配给开发人员的过程。
跟踪进度的过程是完成任务分配后及时跟进任务的开展情况、推进进度、完成情况，为了防止任务的进度严重滞后或者超前完成人员闲置，不同的研发团队会有不同的方式来及时的跟进任务的推进情况。
发现异常的过程是在跟踪进度的过程中发现开发人员负责的任务无法按时和保质的完成，或者开发人员负责的功能偏离了需求，或者是需求发生了变更需要及时调整等等。
处理异常的过程更是在发现异常后，针对异常类型及时的采取对应的有效手段解决异常的过程，常采用的手段有重新分配任务、再次明确和重生需求、及时调整项目时间投入、停止个别任务或项目等等。
控制风险可以市场风险控制和内部风险控制，市场风险主要指市场环境变化、竞品变化、行业变化、政策变化、法律变化、敏感事件等，内部风险主要指人员变动、资金流动、时间周期、无法有效处理的异常、公司战略变动、公司组织结构变动、公司经营状况变动等。不同类型的风险发生的概率是不同的，无论概率大小，及时的关注这些风险的存在是避免风险和减少风险损失的有效方法。
产品开发的核心目的是要确保产品按时保质的上线，充分理解开发的过程，团队全体成员充分了解开发过程，有助于提高达成共识的效率，降低达成共识的成本，增加团队的相互理解，提升团队开发的效率，降低开发过程中的风险，最终实现产品按时保质的上线。
2.9开发结果
开发结果由具备某种需求场景解决方案的功能集合组成的产品，开发结果也即是产品是否能满足需求场景、解决方案是否能解决用户的问题、产品体验是否是与设计一致等均需要进行有效的校验。
对开发结果进行校验的方式常用的手段是测试，具体内容详见产品测试章节。
向最终用户交付的产品应该是经过严格校验、确保产品质量的产品，用户使用的产品应该是一个完善的、稳定的、体验不错的综合版本。
