客户产品经理程序员漫画

㈠ 干货！程序员需要掌握的几种图

随着互联网寒冬的的到来，程序员就业环境越来越严峻，这就要求我们必须要不断提高自己，来应对高压的工作环境。下面介绍的这几种图是我在工作中经常使用的，所谓的图，都是为了辅助思考的，辅助开发的，比文字描述的更清晰，更有逻辑。
前些年，网上有一个口号喊得很响： “人人都是产品经理” 。这就要求我们需要学习认图、画图的技巧，能从需求文档里快速的抽象出我们想要的东西。最近，网上曝出的程序员和产品经理之间的矛盾，大都是需求不清晰产生的，作为程序员的我们如果掌握的产品经理所必须的技能，那我们以后就可以吊打产品经理了，哈哈哈哈。。。

流程图 是对过程、算法、流程的一种图像表示，在技术设计、交流及商业简报等领域有广泛的应用。

计算机语言只是一种工具。光学习语言的规则还不够，最重要的是学会针对各种类型的问题，拟定出有效的解决方法和步骤即算法。有了正确而有效的算法，可以利用任何一种计算机高级语言编写程序，使计算机进行工作。因此，设计算法是程序设计的核心。

对同一个问题，可以有不同的解题方法和步骤。

例如，求1+2+3+…+100，可以先进行1+2，再加3，再加4，一直加到100，也可采取100+(1+99)+(2+98)+…+(49+51)+50＝100+50+49×100＝5050。

还可以有其它的方法。当然，方法有优劣之分。有的方法只需进行很少的步骤，而有些方法则需要较多的步骤。一般说，希望采用方法简单，运算步骤少的方法。因此，为了有效地进行解题，不仅需要保证算法正确，还要考虑算法的质量，选择合适的算法。

一个计算问题的解决过程通常包含下面几步:

传统流程图

用图表示的算法就是流程图。流程图是用一些图框来表示各种类型的操作，在框内写出各个步骤，然后用带箭头的线把它们连接起来，以表示执行的先后顺序。用图形表示算法，直观形象，易于理解。

美国国家标准化协会ANSI曾规定了一些常用的流程图符号，为世界各国程序工作者普遍采用。最常用的流程图符号见图。

流程图不仅可以指导编写程序，而且可以在调试程序中用来检查程序的正确性。如果框图是正确的而结果不对，则按照框图逐步检查程序是很容易发现其错误的。流程图还能作为程序说明书的一部分提供给别人，以便帮助别人理解你编写程序的思路和结构。

PS：墙裂推荐大家使用ProcessOn，画流程图的神器！！！

心智图 （Mind Map），又称 脑图 、 心智地图 、 脑力激荡图 、 思维导图 、 灵感触发图 、 概念地图 、 树状图 、 树枝图 或 思维地图 ，是一种图像式思维的工具以及一种利用图像式思考辅助工具来表达思维的工具。

心智图是由英国的托尼·博赞（托尼·布詹）于1970年代提出的一种辅助思考工具。心智图通过在平面上的一个主题出发画出相关联的对象，像一个心脏及其周边的血管图，故称为“心智图”。由于这种表现方式比单纯的文本更加接近人思考时的空间性想象，所以越来越为大家用于创造性思维过程中。

ps:我一般都是用的网络脑图，在线的比较方便

拓扑学（TOPOLOGY）是一种研究与大小、距离无关的几何图形特性的方法。 网络拓扑是由网络节点设备和通信介质构成的网络结构图。

拓扑学是数学中一个重要的、基础的分支。起初它是几何学的一支，研究几何图形在连续变形下保持不变的性质(所谓连续变形，形象地说就是允许伸缩和扭曲等变形，但不许割断和粘合) 拓扑图用于计算机网络示意，也就是不考虑计算机实际的位置，只表示网络中每台计算机以及网络设备之间的相互关系。

节点，节点就是网络单元。网络单元是网络系统中的各种数据处理设备、数据通信控制设备和数据终端设备。

链路，链路是两个节点间的连线。链路分“物理链路”和“逻辑链路”两种，前者是指实际存在的通信连线，后者是指在逻辑上起作用的网络通路。链路容量是指每个链路在单位时间内可接纳的最大信息量。

通路，通路是从发出信息的节点到接收信息的节点之间的一串节点和链路。

星型结构的优点是结构简单、建网容易、控制相对简单。其缺点是属集中控制，主节点负载过重，可靠性低，通信线路利用率低。

总线结构的优点是信道利用率较高，结构简单，价格相对便宜。缺点是同一时刻只能有两个网络节点相互通信，网络延伸距离有限，网络容纳节点数有限。在总线上只要有一个点出现连接问题，会影响整个网络的正常运行。目前在局域网中多采用此种结构。

环型结构的优点是一次通信信息在网中传输的最大传输延迟是固定的；每个网上节点只与其他两个节点有物理链路直接互连，因此，传输控制机制较为简单，实时性强。缺点是一个节点出现故障可能会终止全网运行，因此可靠性较差。

树型结构实际上是星型结构的一种变形，它将原来用单独链路直接连接的节点通过多级处理主机进行分级连接。

这种结构与星型结构相比降低了通信线路的成本，但增加了网络复杂性。网络中除最低层节点及其连线外，任一节点或连线的故障均影响其所在支路网络的正常工作。

UML是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。

功能模型， 从用户的角度展示系统的功能，包括用例图。

对象模型， 采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类别图。

动态模型， 展现系统的内部行为。包括序列图，活动图，状态图。

实体关系图，简记E-R图是指以实体、关系、属性三个基本概念概括数据的基本结构，从而描述静态数据结构的概念模式。

㈡ 为何大多数程序猿会转行做产品经理的背后的原因有哪些

㈢ 产品经理和程序员,如何避免矛盾

产品实现是你的目的，为了这个目的不必太讲究。

做了一阵子之后我有了自己对于与程序员相处的方法论，对这句话并不苟同，我还是倾向于把事做好的同时也能把话说好，虽然我现在也能深刻的领会到当时leader的核心意思是产品本身是第一位的。

接下来我就阐述下自己的一些心得：

• 产品经理与程序员最大的矛盾在于——改需求。这牵涉两个问题，一个是如何尽量地做足前期工作，尽量把需求细化，需求做的足够扎实就会大大减少改需求的次数，这是产品本职工作，不属于沟通问题；另一个问题就涉及如何沟通了，就是需求无论如何确实要改。这个时候有一点很重要就是努力与程序员（或者开发经理）达成共识，比如“我们的目的是要做最好的xxAPP”、“这个功能对于我们的目的来说是必不可少的”等，然后再来谈详细的需求点，程序员也就会逐步认可改需求这件事情。（还有一点很重要的就是，如果无论如何也达不成一致，也有必要反思这个需求是否真的有改的必要？）

• 用数据和客户来帮你增加底气。在谈论某项功能实现的时候，产品经理经常会碰见程序员消极被动不愿意做，或者质疑这么做有没有道理的时候，采取需求依据的数据和真实的客户需求是能有效推进的好办法。比如“80%的同类产品都有这个功能”、“每周都能收到几个客户对某某问题的反馈”，一般来说程序员是能够接受这种说服的。

• 试着多用询问的语气。让程序员感到他是专业的，他是能够解决这个问题的，要依仗他才能做的更好。这会无形中赋予他一种责任感（因为你把问题抛给了他，他就隐形中负有解决这个问题的责任），在传达出意愿的同时也避免了话语的生硬，让程序员感受到对其职业技能的尊重。

• 注重日常交往。日常生活中交个朋友，比如一起打球、打游戏，聊聊电影和漫画，实在是没有共同语言就经常冲他卖个萌、搅个基、撒个娇、讲个笑话。这样，大家都是朋友了，不看工作职责的那一半看交情的那一半，沟通起来也会顺畅很多。

总结：有很多时候产品的产生不完全是靠严格的流程和规章制度诞生的，也需要很多沟通的润滑。能够开开心心地把产品做出来最好，但是最终我们还是不能离开产品实现这个 标的物。