經營社群不是一夜情,千萬別讓這5個錯誤毀掉你的數位人脈

經營社群不是一夜情,千萬別讓這5個錯誤毀掉你的數位人脈
Photo Credit: herbalife CC0

我們想讓你知道的是

當建立智慧共享所需的社群人脈,記得別只抱持三分鐘熱度。你該建立的關係是細水長流,不是一夜激情,既不該莽莽撞撞,也不要咄咄逼人。

文:李爾.羅瑞夫(Lior Zoref)

真正的人際關係要花時間與力氣來維持,你跟群眾的關係也是如此。所有關係都要找到平衡點。如果你花全副心力靠智慧共享來研究為人父母之道,卻忘記真正花時間在孩子身上,就是忽略平衡。

健康關係一○一

為求有效共享智慧,我們必須跟群眾建立健康的數位人際關係,亦即學會如何妥善管理數位世界的人、事、時、地、物。

如果你是運用外部平臺(例如:Quora和LinkedIn)的社群人脈,不必花太多時間與精力經營關係,只要貼出問題(但願是個有效的好問題),接著就好好靜候佳音。如果你是運用內部平臺(例如:臉書和推特),則必須跟群眾維持好關係,正如跟人生中各個重要對象也必須如此。

白俄羅斯創業家蓋瑞.范納洽(Gary Vaynerchuk)是社群網站界的一大意見領袖,在推特有超過一百萬名跟隨者,是靠數位工具建立社群的高手,定期在部落格新增影片,擅長跟群眾與粉絲互動。

我單刀直入地請范納洽舉出建立數位人際關係的最大重點,他的回答十分簡單:努力。要怎麼收穫,先怎麼栽,跟一個人往來是如此,跟一百萬個人往來亦然。

別像一夜情,事後就不理

當建立智慧共享所需的社群人脈,記得別只抱持三分鐘熱度。你該建立的關係是細水長流,不是一夜激情,既不該莽莽撞撞,也不要咄咄逼人。換言之,你該先跑過每個壘包,全壘打才有意義。你要認識群眾,群眾要認識你,如此才能建立親密互信。如果你想不勞而獲,那就只在大型外部平臺運用智慧共享,這類地方的群眾不必知道你是何方神聖,你甚至不必秀出真名,只要提出問題,獲得解答,然後拍拍屁股走人。這是智慧共享的「事後不理」版本,不算多令人滿意的關係,但能達到目的。

相較之下,經營內部平臺需要耐著性子付出時間精力。你不會一夜之間出現一萬名樂意幫你解決大小難題的追蹤者,但要是你跟群眾互動,跟群眾「約會」,好好尊重,終將建立雙方滿意的密切關係,足以延續一生。也許你要花幾個月,甚至一年,才能跟群眾建立「互相投入」的關係;或者也許你已經結識一大群人,準備邁向下一個階段。不過無論你是要一個一個從頭建立人脈,還是已經有一大堆後盾,經營數位關係的訣竅都如出一轍。

經營社群人脈的祕方

我剛開始寫部落格時感覺非常寂寞,很想問有人在嗎?有人在讀我寫的東西嗎?我值得投入這樣的時間精力嗎?我想獲得一大群人的愛戴,卻不知從何下手。

後來,我決定表現得真誠,不要為了吸引大批讀者而違背良知,而是只寫真正感興趣與受啟發的東西:科技、社群網站帶來的市場創新、替生活帶來便利的酷炫新產品,還有我女兒在數位時代的成長點滴。此外,當時部落格是個我認為別具潛力的較新概念,因此我也分享對寫部落格的熱忱。

慢慢下來,我發現大家最喜歡看我描寫各類生活點滴,還有描寫女兒跟家人的小故事。由此可見,「說故事」不只在面對面的日常生活很重要,在數位世界亦然。

大家最不喜歡看的則是無趣瑣事,還有無法傳達出意義的生活紀錄。「意義」不代表要多深刻奧妙與饒富哲理,重點貴在真實。你可以貼貓的影片,因為這類影片很受歡迎,能激發回應;或者你可以拍下自家愛貓的身影,描述你是怎樣開始養這隻貓,牠對你有何意義。兩支影片也許都很有趣,但只有一支代表真實。

經營社群人脈絕對要力求真實,畢竟大家一向能看穿背後意圖。起初我沒多少讀者,但我不願放下堅持,選擇堅持到底,結果讀者一點一滴漸漸增加,從我的部落格發現價值,開始跟朋友分享。

價值當然是個主觀認定,但當你替自己與群眾界定價值之際,不妨捫心自問:什麼能刺激我的思考?什麼能引起我的好奇?什麼能啟發我?什麼能讓我哈哈大笑?什麼能讓我將心比心?什麼能讓我快樂?什麼能讓我成為一個比昨天更好的人?你怎麼回答,你的價值就在其中。

在此提供一個不妨嘗試的小實驗,那就是花十五到二十分鐘瀏覽臉書上的動態消息,讀每位朋友發的動態,每讀到一則就問自己:這有帶給我什麼價值嗎?我得說我很喜歡臉書上的朋友,相當珍惜他們,但當我做這項實驗,多數發文都沒有多少價值,例如:以下發文對我即價值不大:「我剛起床」、「心情不太美妙」或「今天好開心」。許多人喜歡分享手邊在做或剛才碰到的日常瑣事,儘管(有時)內容不差,但分享對他人具意義的內容還是更好。

問題在於,如果你盯著食物的照片不具意義,什麼才具意義?也許你熱中於美食與烹飪,夢想有一天當上大廚,錄製專屬烹飪節目。若是如此,分享對烹飪的熱情就能替群眾帶來價值,所以快跟他們分享你從飲食學到的精采心得吧。

但別分享你今天吃什麼晚餐。

而是分享食譜的連結,分享你大膽探索廚藝的故事,分享厲害名廚的影片,或者分享你學烹飪時的趣事,這些才有價值,群眾會樂意回應,看見箇中意義。

現在我提供一個實例。假設你對下廚很有興趣,想讓群眾參與並提供價值,而且才剛辦完一場晚宴,親手做的蘋果派贏得滿堂采。

你能發的五種動態如下,價值由低到高:

  1. 「我做了超讚的蘋果派。」
  2. 「這是我今晚烤的蘋果派,朋友說真是好吃極了!」
  3. 「製作美味蘋果派的祕訣是OOXX。」
  4. 「我剛邀朋友過來用完晚餐,這是我做的蘋果派,兩分鐘內被大家吃得精光(附上照片)。我在此公布食譜,做出美味蘋果派的祕訣是OOXX。」
  5. 「我剛邀朋友過來用完晚餐,這是我做的蘋果派,兩分鐘內被大家吃得精光。這是我個人部落格的連結,上面有製作蘋果派的食譜跟影片,你不妨試試看,順便告訴我成果如何!」

如你所見,第一則動態只陳述事實,對群眾沒有價值,無法激起迴響,無法帶來啟發,大家沒必要分享或回應。

第五則動態不然,對群眾也許甚具價值。我不是說你的每位朋友看了都會立刻動手做蘋果派,但他們也許會想知道你的祕訣,跟喜愛烘焙的友人分享,那些友人因此光顧你的部落格,也許見識到你的下廚點滴與烹飪夢想。

無論你對哪方面有熱情,這個例子都適用,舉凡法律、稅改、健保或軟體動物的性行為皆然。經營數位關係的祕方就是持續提供價值:日復一日,每則動態皆然。你會吸引到志趣相投的群眾。社群人脈於焉建立。

懂得即時感謝、經常感謝

你付出心力,提供價值,讓群眾成為社群人脈,接下來你一定要表示感謝。所有人際關係都在感謝中成長茁壯。感謝雖小,益處很大。

我講完TED演講回家以後,想感謝所有讓我順利講完並完成夢想的人,於是在我任教的大學舉辦感謝會,邀請我的群眾參加,盡量具體感謝每個人的貢獻,展現我有多珍惜他們的價值。

貢獻最大的是歐爾.薩吉,那個建議我請牛上臺的十六歲少年。先前我造訪離好萊塢不遠的長灘,買了一座奧斯卡小金人的複製品,在感謝會場上,我請薩吉上臺,把獎座交給他,大家紛紛起身喝采。那個時刻無比美妙,大家明白我有多感謝他們的貢獻。

你從群眾得到精采點子以後,不必租借大型場地頒獎給他們,但務必表達感謝之意,謝謝他們撥冗幫忙。如果人數太多,你無法一一感謝,但只要你傳達對大家的謝意,每個人看到都會明白。沒人想跟不知感謝的傢伙來往。你該跟群眾即時感謝,經常感謝,謝謝他們給的意見、點子、時間與心力。

這些錯誤毀掉社群人脈,你犯幾個?

如果你對建立與經營群眾不熟,你終究會犯錯。沒人天生知道如何妥善經營人際關係,往往只能從錯誤中記取教訓。

然而數位世界不同於真實世界,要絕交實在輕鬆方便——按個鍵就能從朋友名單移除。如果親戚長輩在我放假時說了不中聽的話,我不能隨意跟他們絕交,從此走自己的陽關道;如果好友跟我意見不合,我不能輕易「封鎖」他們,假裝他們從未存在。

然而你的群眾隨時能點一下滑鼠,從此消失無蹤。這種事你實在不樂見。

現在來檢視最容易毀掉社群人脈的常見錯誤:

推銷商品

如果你老想賣東西給群眾,他們沒多久會一個個消失不見。大家會在門口掛「謝絕推銷」告示牌自有道理,沒人想老是被推銷員或廣告疲勞轟炸。趕走群眾的最快方法就是讓他們認為你別有所圖。

不理不睬

如果你不迅速回應或表達謝意,群眾會很快灰心。如果有人問你問題,你該趕快答覆,畢竟社群人脈該雙向互動。如同先前所述,如果你不付出心力或表達感謝,群眾(至少)會覺得沒趣,轉移陣地或從此閉嘴。沒人喜歡被利用的感覺。

亂搞失蹤

想像你長期交往的對象突然不見人影,不回電話,不回簡訊,打過去始終手機不通,你會做何感想?我想你大概不會多開心。群眾也是如此。離開數位世界很容易,有時根本太過容易。無論你要找個地方安靜十天、不上線一個月,或者到沒有無線網路的偏遠熱帶小島度假,你都必須讓大家知道你會消失一陣子。別一聲不吭就搞失蹤,否則回來後會發現大家也失蹤了。

說話無禮

別忘記行事準則,平時怎麼做,在網路上就怎麼做。別人不在你面前,但不代表你可以隨便出口傷人,安然躲在螢幕後面大放厥詞。你先尊重別人,別人才尊重你,如果確實冒犯到別人(這在所難免)就立刻道歉。人人會犯錯,但也人人能認錯,好好道歉並保證絕不再犯。我曾誤闖一個只准女性加入的臉書社團,那時我就必須道歉,從此記取教訓。

代問,就像出借廉價的玩具

想像有人走過來跟你說:「嘿!我很喜歡你老婆,她看起來很能幹,事情處理得很好,很像有幫夫運,所以我想說能不能借她來幫我做一件事?」借用群眾也是這樣。

我開始懂得智慧共享的藝術以後,許多朋友跟同事想請我示範,替他們向我的群眾問個問題。起初我沉浸於社群人脈的成功,樂於跟人分享,因此替朋友動用我的社群人脈,把他們像十元商店的廉價玩具般借出去。

但他們覺得不滿。

沒人喜歡這樣。

臉友開始抱怨說我很煩。他們說我提出太多問題,其中有些顯然是幫人代問,搞得他們彷彿被利用了。

我感到羞恥。

我立刻停止不當做法。現在誰說要「借用」社群人脈,我會堅決婉拒。我怎麼對待生命中的重要對象,就怎麼對待我的社群人脈,善加珍惜,悉心呵護,確保我的付出多於回報,從不做貶低他們的行為,從不浪費他們的時間。

尊重是互相的,在現實世界與數位世界皆然。如果你把社群人脈當作珍惜的對象般好好對待,他們會在你需要之際挺身而出,否則你只好眼睜睜看著他們離你而去。

書籍介紹:

《智慧共享的社群人脈學:如何利用互聯網集思廣益,解決工作、生活、健康、愛情難題,實現夢想?》三采文化出版

微軟前營銷副總李爾.羅瑞夫(Lior Zoref)指出,只要你懂得運用智慧共享的威力,
就能靠群眾智慧,做出最佳決策。

作者介紹:

李爾.羅瑞夫(Lior Zoref) 群眾智慧研究者、國際演講家與顧問,曾在微軟任職達14年,最後的職位為消費者暨線上服務行銷部副總監。

1001_10030

責任編輯:楊士範
核稿編輯:楊之瑜


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡