團隊學習 - APP分享會
我們公司，我們APP是個Team，是個小Team，為了幫助我們的APP找尋新的方向、新的功能、新的優化，每一個月或每兩個禮拜輪流分享
一開始我們是一個月一個人找個主題分享
一開始我排斥這種分享會，因為要找主題、要主席、要記錄(為什麼要把這種國小、國中的開會搬到這種地方呢？）
後來逐漸發展到，可以跟APP無關、主席、記錄如同虛設的狀況下或不曾設定。就變得讓人比較少的排斥感，能夠不嚴肅與歡樂的感覺。自由的暢所欲言。
覺得能夠讓團隊自由的暢所欲言，才能把真正想講的事情講出來，哪怕對制度不滿意、把使用者的心聲講出來、把做這種事很腦殘的想法說出來。
才能避免許多上架後的民怨與不滿。
設計、企劃、行銷、工程師，都是不同的專業，但如果能將這群專業整合起來，互相交流，
總有幾個是屬於跨領域的人才，工程師難道就沒有行銷、企劃思維嗎？當然有，當工程師參加了行銷、企劃，他就有機會提出特別的方法，
如「分享到FB」做一些記錄，工程師可以做行為追蹤，必要時用行為追蹤取得的數據，做事件觸發，分享送什麼之類的。
行銷忙於要做的事，或忙於要推新功能、賺錢的功能，企劃也根本不想這些好用的功能，變成行銷企劃就是行銷企劃，企劃是跟著行銷面走的。
產品經理應該更重視的是使用者的需求，而非行銷面的需求，不然就要分兩者，行銷企劃與產品企劃兩種。
而工程師，依著行銷企劃與產品企劃的需要而開發，但我覺得工程師的特質，應該是比較偏產品企劃。
對於產品，我比較偏向，活躍使用者的提升，愛好、形象的提升，而非績效、其它數據的提升。
喜愛產品，其它面向只會是自然的增長（購買、消費、行為）
離題了，我再來打一次悲情牌，我們是1～3人的工程師團隊，維護公司的Android及ios六隻APP。
團隊有設計、工程師、行銷、企劃，當然很多身兼N職，大部分都是去做Web的事，我們APP，就1~3人小團隊在努力不懈的為使用者們服務。
工程師在有APP分享會後，開始尋找可能是技術相關、使用者介面相關，更想到破頭了，不知道做什麼，開始有講敏捷式開發、開始說明什麼叫成長駭客、開始講什麼是讓使用者上癮的APP
我是一個來亂的心態，把這種僵硬文化改成歡樂文化的引導者，我講始講使用者介面(UX/UI)、勾癮模式(Hook Model)、法格行為模式、成長駭客等拿來講，
逐漸讓團隊僵硬的腦袋，有了一種新的突破，成長駭客有點像創意思考，思考的升級版，不再僅限於技術、設計，更深入使用者的心理與行為、數據分析。
所以才有我這次的「團隊學習」的主題，一切使於突破舊有APP分享會的呆板模式往溝通、學習的分享會模式。
分享與實作，分開，分享會，就是學習一個新的思維、實作則是針對公司未來目標與現有問題做改善提出解決方針，大家可以提出各自的想法，覺得哪種比較好。
當然我覺得提出各自想法，雖然是一個很公平的可互相溝通的圓桌會議，但你瞭解的是賈伯斯的腦袋，跟其它的人的腦袋是不一樣的，如果他只算一票，而其它人比他更多票，那他的idea不就要被埋沒了。
如果諸葛亮在執行一個計劃，沒有主夠的權限，劉備就提出他的見解、馬謖也有他的見解，何況是關羽、張飛也來參一腳，如果不是諸葛亮料事如神的讓人信任，這場圓桌會議，不就是偏向劉備、關羽、張飛了。
當然以現代，是數據可以說明一些決策是否正確，結果就是怎樣，就容易明白，但怕的是只想好的數據，不願意承認問題，而美化問題，或認為他不太可能是個問題，或問題是顯然是正常的。
現代是還有辦法所謂的試錯，但需要立即的迭代，但古代，要讓你試試用背水一戰可不可行，不同人不同的結果，韓信成功了，另一個人就失敗了。
不是學別人怎麼做就可以都做對，適情況而定，以前失敗就是人頭落地，現在能試錯還算不錯，但試錯要有試錯的成本，用MVP只是小額的試錯、試驗，畢竟不花太多錢能知道需求導向，攻略正不正確。
你也可以稱這為系統模擬，這個系統丟下去，得到的數據什麼，調整哪些可以得到什麼結果。
好了，又離題了。
從APP分享會→分享會、行前會議兩者兼備，若有個像諸葛亮的決策者，那當然非常好，但可能就這樣，若後繼無人，反而就產生了未來的隱憂
覺得若公司有個諸葛亮，而在團隊學習的過程中，諸葛亮提出見解，其它人在溝通學習的過程中，也能產生其後人，姜維或王平、廖化、趙雲之類的副將(雖然他培養了一個搞砸的馬謖……)
結果：
透過導入外界的思維，如用讀書會的方式，分享書中的內容，讓人發現書中的一些智慧與奧義（雖然我不是諸葛亮，但有諸葛亮的書可以分享吸收呀），其它同事聽了，就是一種Level Up的狀況。
這時就會想，原來別人的成功是因為……。數據會說話，連行銷、營運都張開嘴喊……哇（反正瞪大眼看別人怎麼做，就不會做個井底之挖，以為目前自己打造出來的成就有多高）
下回靈感來，再分享其它實戰經驗，下回見。
(靈感來自，第五項修練，系統思考，其實是學習型組織的團隊學習)