前一階段，木東居士分享了乙個案例，個人認為很有代表性，這裡簡略敘述一下，作為問題的起點：一位朋友從運營晉公升為管理層，開始帶團隊，因為朋友本身是運營出身的，所以對於業務的訴求，非常了解，但團隊成員大多是技術出身，總是get不到業務需求的點，容易陷入到技術的追求中不可自拔。其實這個問題並不是乙個孤立的現象，而是普遍的問題，那就是做資料的同學，從幕後走到台前的過程中，會有一種身份上的不適應，也就是無法從技術視角跳出來，無法理解業務視角的痛點和問題。車品覺在《決戰大資料》這本書裡，也提到了乙個情況，那就是資料分析和資料技術團隊的目標不一致。書裡寫到：「業務部門對為什麼要使用資料及如何用好資料充滿疑問，甚至有人認為資料分析僅僅是門面功夫，技術團隊有時候會跟我的團隊『對著幹』」。不光是資料分析和資料技術的矛盾，產品與資料、運營與資料、後端與資料，幾乎資料交集的相關方，都會有各種各樣的矛盾，而這種矛盾，並不是技術衝突的矛盾，而是業務理解和價值選擇的矛盾。如果我們往更深的層次看，為什麼價值選擇不一樣，或許可以用更高層級的抽象來解釋：
三種不同思維，碰撞在一起時，確實很難融合。
為什麼這裡要提到erp？也是跟產品朋友聊天時提到的。先簡單介紹一下，筆者目前在從事企業智慧型化的工作，產品本身是沒有對標的，所以每個人在理解這個產品上會有一定的差異。產品怎樣看「企業智慧型化」？一句話解釋：「自動化的erp工具」。erp有很長時間的歷史，而且其價值是已經被證明過的，即便是大資料如火如荼的今天，erp的作用依然無法被替代。但erp會有一些問題，那就是本身的使用也是嚴重依賴於人的，而不是依賴自動化的資料。因此如果erp的部分環節，能夠被資料的自動化所替代，那麼這個產品就可以在erp的基礎上進一步的延伸，也就是在已證明商業價值的基礎上，進一步提公升智慧型化的價值。資料技術團隊日常所做的產品，大多數也是erp的價值體現，那就是停留在資料展示的層面，而沒有深入到分析的地方去。但團隊合作時，每個人並不會認同erp產品的思路，不論是後端，還是資料技術，大家都希望自己做的產品是一種資料產品，能夠體現智慧型化的價值，因此非常看重產品背後的技術能力，也就是「工程」思維太重。然而，如果站在商業的價值上，資料僅僅只能被展示，那它的意義在**呢？每個人衝突的地方，正是對價值理解的不同。
上文erp的例子之後，我們就需要進一步的思考，作為團隊負責人，怎樣做，才能將大家的價值思維凝聚起來，也就是創造一種更高的「共同價值」。其實技術人並不是怕需求多、或者是做不了，而是怕辛辛苦苦做出來的東西，沒有價值，不被認可，這會非常的傷人心，時間久了，技術也就成為了「老油條」，導致積極性的下降。但資料「從來不是免費的午餐」。資料要體現技術能力，成本的增加是不可避免的；資料要體現商業價值，商業模式是至關重要的。對於資料同學而言，技術能力的深度是一方面，另一方面是學會宣傳，也就是讓使用者知道資料的好處。儘管我們不能假定使用者最終會知道資料的好處，但我們可以堅持自己的理念，一邊宣傳理念，一邊教授技巧。儘管資料不直接產出商業價值，也不直接體現科學價值，但是資料依然是有豐富的價值的， 這種價值只有在與產品、運營、分析師的思維碰撞中，才能撞出火花，才能在工作中發現資料的用途。換句話說，資料解決了一部分的思維慣性，從另一種視角來看業務。如果資料尋找到了能夠落地的場景，那麼資料的價值也就水到渠成的體現了出來。
資料的價值不僅體現在知識的積累，更體現在幫助我們學會如何思考。做業務資料的同學往往會有一種感覺，那就是掌握了「資料倉儲」及「資料湖」的東西之後，很難進一步提公升自己了，因為該會的技術都學會了。這個其實並不只是業務資料的煩惱，也是技術通用的煩惱。 知識是有邊界的，邊界之外，只能靠乙個乙個的點來突破。
任何門類，到頂之後，思考的都是更廣闊的層次的東西，也就是我們常說的「跨學科」。但知識的融合並非一日之功，當你面對p7到p8的差距時，永遠不是什麼技術上的差距，而是在思維層次上，你已經落後太多了，而這種差距，並非兩三年能夠彌補的。因此，產品要怎麼做，不要去爭論，不要去試圖證明自己很懂，而是多站在其他人的視角上，分析如何可以做的更好。不信的話，當你自己做的東西被挑戰成閉門造車時，就真的無法反駁了。
放棄你，並不是放棄愛你
痛苦的不是過去,而是記憶.回首過往的點滴,這段感情就像乙個沙漏,哪怕自己投入的再多,付出的再多,那沙子還是會一點點的流走,到最後握在手裡的只是一縷清風,和自己早已被風吹幹的淚痕 只有深愛的人才會讓你笑的最甜,卻也讓你痛的最真！回憶固然傷感亦美好,不如把這點唯一的美好,放在心底收藏至永遠.至少,我還有...
你以為的穩定，可能並不是穩定
所有的穩定，其實都是高風險的。一味的追求穩定，只會使自己穩定的貧窮。曾經讀到過乙個這樣的故事 有乙個國家為了保護森林裡的鹿群，就請來了獵人們 了森林裡的所有狼 沒有了天敵的約束使得鹿群大量的繁殖，瘋狂的啃食著森林的資源，使得森林差點失去生機，而鹿群失去了食物也大量的死亡。最後無奈只能重新將狼 請了回...
物件導向並不是必要的
程式開發並非一定要物件導向不可，物件導向是一種方式，但是不是唯一的方式，這種方式很多時候有用，不代表任何時候都是最高效的，更不是唯一的真理。物件導向將相關的狀態屬性和操作方法放在乙個實體中，起到了歸類和分而治之的作用。對於乙個系統來說，這個是最根本的方法。但是物件導向的分而治之並不完美。面向過程也有...