java 新达达_互联网的众包模式是怎么产生和兴起的,这种模式应用到不同的业务上会有哪些问题?...
受職業限制,我更多的是站在眾包團隊運營角度而言。純屬個人經驗。
先綜述一下:眾包模式是外包的繁衍和補充。
一般情況是,一級需求方自身管理成本過高(或為了擺脫某種風險)會把項目外包給供應商,供應商綜合分析之后做的運營管理策略,依據需求環節與指標、工具平臺、技能工種等把項目拆解為一個個獨立的過程控制與質量驗收任務(任務包),在眾包平臺(供應商的眾包組織)分發任務包給獨立員工,員工完成任務的方式可以靈活多樣,全職坐班、兼職坐班、或者干脆互聯網在線辦公(全國各地一起在線協同辦公)。多個同類型的任務包可屬于一個任務組,員工可以在任務組中接受技能培訓、任務包計劃安排與工作驗收等;所有任務包的工作結果都是指向最高一級的客戶需求。
眾包的興起是因為它有幾個顯著優勢: 1 )眾包模式基本上不受到地域限制,最終也會跳出實體環境的限制。
故而招聘范圍廣,隨之而來的優勢是,可選勞動薪酬較低的區域人群,以降低人力成本,相應的維護員工關系與促進員工積極性也容易很多。
故而專業人才多,隨之而來的優勢是,可選技術經驗匹配度更好的人,以降低培訓成本,技術的通用性與標準化也更容易,當然技術也會逐漸變得普遍而便宜。
----------------
以上兩點,前者對應人力成本的節約,后者對應技術人才的普遍。或許有些人會說眾包讓人力和技術都變得廉價了這樣好不好,我只能說確實會!但好不好不以部分人立場做論斷!因為這個廉價本身也是階段性錯覺!!長期以來傳統的資源分配不均&地域經濟環境影響,一線城市技術員與三四線城市技術員即使干著差不多技術難度和工作強度的工作,他們的日薪/月薪都有幾倍的差距;如果放在眾包去解決,一個IT開發任務包,北京java開發工程師開價1W,廣州的開價1.5W,湖北的開價8K,如果這三個人技術上都能滿足這個任務,發包方無疑會選擇湖北的那個工程師,當然可能有其他地區開價更實惠。
我只是舉例說明,眾包成功的借助人力的資源廣泛優勢,跳開了雇傭關系里面的地域經濟與人才供求限制,放眼全國去選擇性價比更高的,逐漸拉平技術或人力的全國平均價格。這里面受益最大的是原本處于劣勢的二三四五線城市的(但有一定學習能力和技術經驗)的人,一個是經濟受益(眾包的平均報酬水平高于自己所在城市的平均報酬),一個技能和眼界的受益(參與高級別的項目,學習新知識、和一線城市人才進行交流)。單憑這點而言,眾包對全國人力人才市場的貢獻和潛力也是巨大的,甚至可以構想,在眾包項目管理平臺和工具高度發達的時候,當越來越多人選擇眾包這種工作模式的時候,人們對技術的使用會更加標準嚴謹,對協同辦公會更加積極認真。也許當二三四線城市的人憑借眾包都可以月薪過萬,一二線城市的打工仔們就會被吸引回到故鄉發展了,也就沒有什么北漂和買房壓力了。
----------------------
2)眾包模式可以把節約的成本投入達到更高級的產品/技術質量控制中去。(此部分包含“眾包模式應用到不同的業務上會有哪些問題”)
眾包成本的節約并非只是為了利潤,人力組織和工作結果的驗收模式也需要變化,這個變化里面需要投入額外的成本。進度保障、質量控制,驗收模式的設計及可能產生的風險成本都需要納入眾包運營管理體系中來。為了確保一級需求得到充分滿足和保障(不能有半點紕漏),眾包運營在質量環節投入的成本也許比傳統的要大,舉個例子,一條句子的英譯中的翻譯,傳統的模式可能是1個人翻譯1次,然后另外1個人審核加校驗,可能還有一個二次抽檢員,專門來抽檢校驗員的工作,這3個人可能都是全職坐班,每天就做這一項翻譯或校驗工作;但在眾包里面,為了讓翻譯的結果更好,錯誤率更小,可能采取1個人翻譯,同時有3個人審核,其中有1個審核不通過,這條翻譯就被打回去重新翻譯,或者換另外1個人翻譯,只有當3個人同時審核通過,這條翻譯才算正確,這個例子里面談到的多人審核、結果擬合、數據返工等都屬于眾包通常的質量保障策略,這里面的成本構成、如何做到設計合理、節約有效也挺復雜,規則的制定和維護是成本,層層質保環節的消耗也是成本,這些成本要從之前談到的人力成本節流里面扣除,所以人力省錢很大程度也是為了養眾包的質量體系,打造眾包品質。
-----------------------
眾包模式應用到不同的業務上會有哪些問題?!
借著我本段所說的,粗略的回答下,因為接觸行業不算多,所以無法太細致展開,只能就經驗而談。目前而言,適合眾包的業務有很多,內業外業均有,但能把眾包做好的不多,很多我們看到了是在試圖用眾包去做,但不溫不火(或者說努力培育市場),因為眾包需要“養”,能從人力、質量、工具、管理組織上養活一個眾包環境的項目不多,求一個理解眾包發展規律的大客戶也很難。
現實情況往往是,需求方很急切,比如“我們產品火了、需求量暴增,同時需要300個人工在線提供服務,但是我們怕需求量不穩定所以不打算用自己雇傭全職,那樣風險太大”,所以找到眾包供應商,以為眾包供應商底下都是人,“你們人那么多組織起來不是很快速的事情嗎”,所以“希望你們一周內組織起來,10天內培訓完畢,當然報價不能高于我們自己雇傭實習生的價格,然后還要達到各項KPI指標,哦,還有我們不能保證我們的需求量一直都有,但希望你們提供彈性的人力服務”,如果不是一個大的長期的合作客戶,沒有1年的業務磨合默契,這樣的業務眾包是做不下去的,這樣的需求方也是談不下去的。因為他們對眾包不了解,只對表面人數感興趣,認為眾包在于人多,就是來幫他們低價高效解決人的問題。但其實顯然不是,正確的認知是,眾包是一個解決方案,我們提供的是關于人力組織的質量服務,而因為我們的組織方式和策略的不同,我們的成本計算也完全不同,我們的服務結果的精細化程度也不同,一條數據也許被N個人做了N次提交了,在需求方那里就是一條數據+合格,在眾包這里就是一條數據+99%正確率保障(質量組織不同),一個在線服務也許后臺有N個人同時提供不同地域的支持,在客戶那里就是一個本地化響應,在眾包這里就是一次響應+協同辦公(人力組織不同)。
如果需求方意識不到這些不同,眾包供應商很難把業務做下去,做到最后可能雙方出現討價還價或驗收矛盾,當然是雙方受損。但如果眾包方自己也意識不到業務架構上的特殊性,計算成本的時候過于樂觀,最終也會出現攤子大了但只賠不賺或者倉惶收場。
所以,在我看來,不管哪類業務,即使可以眾包化,未必非要眾包化:
1 人力成本不減反增,不能只考慮核心技術或人才的人力支出,需要綜合考慮,尤其把風險成本都考慮進去,過于樂觀是大忌
2 人力資源或質量環節的設計不成熟,未經完整的測試驗證,僅僅小范圍估測量就整出一套眾包方案的, 往往正式做起項目才發現原來對口的人力這么少,有或者人力很多,質量設計不嚴謹,產生很多不合格產品或數據,需要逐層更新標準,這期間不僅無有效產出,還墊付了錯誤成本,對于有些項目就會致命打擊。
3 方案成熟,執行效果也可以,但眾包組織運營能力弱。如果一個項目方的成長性極好,給出的需求迭代很快,那么需要在前期溝通之后,設計一套符合項目發展的彈性組織和符合項目素質的管理人員,眾包運營人員需要明確知道項目階段性的變化,以調整自己的工作模式和補充知識,但其實很多運營組織其實是不具備的太強的轉化和抗壓能力的(這會錯失很多機會,甚至導致團隊發展掣肘),想表達的重點是,目前階段,真正的職場精英還在企業內部默默奉獻,眾包尤其是在線眾包合格的管理人才太少、優秀的運營團隊也不多。
大企業把內部需求給企業下屬眾包團隊來做也是一個增進信任降低風險的可行嘗試。
天時地利人和很重要,每個眾包團隊都有自己的一技之長,在擅長的領域順勢而為吧。
----------------
3)眾包模式可以用眾人碎片化時間達到實時在線服務效果,以及快速處理海量業務。
這點也是眾包最突出的優勢,如果說1)談的是人力成本優勢,這里說的就是勞動強度和效果上的優勢。舉個例子,如果有日均1-20萬不等的業務量,需要24小時在線處理,如果用傳統方式,首先會有個經理或主管去算清楚到底雇傭多少個全職,進行幾個班次的輪值班才最合理,最終的結果可能是采取幾個全職+N個兼職坐班的方式,然后排班、績效、時間段報酬就成了問題,我們只能靠經驗估算解決,永遠會有額外支出或業務損失,因為不是人力多了就是人力少了,人力剛剛好是極少的情況,這里說的人力不等于人數,是指的實際工作量折算的,假設實際工作量今晚需要1.5個人力,那么最少今晚要2個人坐班值班。但是換做眾包就不同,如果一個業務對眾包員工開放了接口,眾包的業務管理人員能看到實時愿意提供服務的在線人數,可以把業務派給具體的員工,或者由員工自己在線申請業務,這樣永遠也不會有多余的人力,也可以按照服務次數和反饋評價來計件報酬,而單筆價格成為眾包運營管理人員的調控策略,當發現某個時間段在線服務的人力偏少或偏多的時候可以提高或降低單筆業務的處理報酬。比如:打車軟件,是司機接活兒的眾包平臺。
以上是我作答,謝謝邀請。幾年沒有上知乎回答問題了。
總結
以上是生活随笔為你收集整理的java 新达达_互联网的众包模式是怎么产生和兴起的,这种模式应用到不同的业务上会有哪些问题?...的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 计算机记账软件毕设论文,基于ios移动平
- 下一篇: 您安心的走吧——5.17晚一夜天降小雨祭