客戶產品經理程序員漫畫

㈠ 干貨！程序員需要掌握的幾種圖

隨著互聯網寒冬的的到來，程序員就業環境越來越嚴峻，這就要求我們必須要不斷提高自己，來應對高壓的工作環境。下面介紹的這幾種圖是我在工作中經常使用的，所謂的圖，都是為了輔助思考的，輔助開發的，比文字描述的更清晰，更有邏輯。
前些年，網上有一個口號喊得很響： 「人人都是產品經理」 。這就要求我們需要學習認圖、畫圖的技巧，能從需求文檔里快速的抽象出我們想要的東西。最近，網上曝出的程序員和產品經理之間的矛盾，大都是需求不清晰產生的，作為程序員的我們如果掌握的產品經理所必須的技能，那我們以後就可以吊打產品經理了，哈哈哈哈。。。

流程圖 是對過程、演算法、流程的一種圖像表示，在技術設計、交流及商業簡報等領域有廣泛的應用。

計算機語言只是一種工具。光學習語言的規則還不夠，最重要的是學會針對各種類型的問題，擬定出有效的解決方法和步驟即演算法。有了正確而有效的演算法，可以利用任何一種計算機高級語言編寫程序，使計算機進行工作。因此，設計演算法是程序設計的核心。

對同一個問題，可以有不同的解題方法和步驟。

例如，求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%的同類產品都有這個功能」、「每周都能收到幾個客戶對某某問題的反饋」，一般來說程序員是能夠接受這種說服的。

• 試著多用詢問的語氣。讓程序員感到他是專業的，他是能夠解決這個問題的，要依仗他才能做的更好。這會無形中賦予他一種責任感（因為你把問題拋給了他，他就隱形中負有解決這個問題的責任），在傳達出意願的同時也避免了話語的生硬，讓程序員感受到對其職業技能的尊重。

• 注重日常交往。日常生活中交個朋友，比如一起打球、打游戲，聊聊電影和漫畫，實在是沒有共同語言就經常沖他賣個萌、攪個基、撒個嬌、講個笑話。這樣，大家都是朋友了，不看工作職責的那一半看交情的那一半，溝通起來也會順暢很多。

總結：有很多時候產品的產生不完全是靠嚴格的流程和規章制度誕生的，也需要很多溝通的潤滑。能夠開開心心地把產品做出來最好，但是最終我們還是不能離開產品實現這個 標的物。