資訊專欄INFORMATION COLUMN
摘要：但流程不是死的，尤其在互聯(lián)網(wǎng)公司，只要有助于我們的目標(biāo)達成，那么流程只是一陣東風(fēng)。工作中并不是所有事情都可以依賴流程去保證萬無一失。所以不要怪罪流程，這并不是流程的問題，而是人的問題。所以請不要再怪罪流程啦，以人為本，才是長久之計。
本文由作者周巧芬授權(quán)網(wǎng)易云社區(qū)發(fā)布。
筆者所在的團隊這段時間正在兩個版本的交接期，前一個版本馬上要上線了，但后一個版本的需求早在三周前就已經(jīng)啟動，卻遲遲沒見到交互稿。作為開發(fā)前置的視覺跳腳了：為什么交互稿還沒有，回頭開發(fā)時間緊了又怨視覺稿沒及時給！而交互呢，雙手一攤：沒有人找我們要交互稿啊，需求owner產(chǎn)品策劃都沒主動來問需求的交互進度啊。于是大家都開始面面相覷，流程上沒有定這個環(huán)節(jié)啊，流程默默的背上了這個“鍋”。
再有一個例子，某模塊的功能需要依賴另外一個組的開發(fā)，這個問題直接溝通到開發(fā)，開發(fā)就默默的修改好了，等到臨上線，大家都在催促這個依賴代碼怎么還沒上線，找到開發(fā)，對方說：我只知道要開發(fā)，找不到測試的人，我自己測了下沒問題，還在本地庫里。然后就沒有然后了。于是大家又開始說：這個流程有問題，blabla…..流程再次默默的背上了這個“鍋”。
可是真的是流程的錯嗎？嚴(yán)密的流程真的可以解決問題嗎？
回到我們?yōu)槭裁匆辛鞒蹋?/p>
一般來說流程是為了梳理我們的工作程序，讓大家遵守并有效的銜接各部門以及各環(huán)節(jié)的工作，同時知會到相應(yīng)的人員。但流程不是死的，尤其在互聯(lián)網(wǎng)公司，只要有助于我們的目標(biāo)達成，那么流程只是一陣東風(fēng)。而在真實的工作場景中，往往碰到跨部門的合作需要有一定的流程規(guī)范。這個原因多半是因為，跨部門之間的不是特別熟悉，大家有各自的工作方式和KPI目標(biāo)，或者說個體并不在意其他部門的工作，而只要保證你給我的輸入按時保質(zhì)即可。
好吧，既然現(xiàn)實如此，于是我們制定流程來約束大家按時保質(zhì)的做輸入輸出，公司的巨輪慢慢的啟動起來。但似乎這個流程也如同巨輪的枷鎖，當(dāng)流程的某一環(huán)節(jié)出現(xiàn)問題，巨輪要么停滯，要么部門間友誼的小船說翻就翻了。于是去制定更細致的流程去避免另外流程的環(huán)節(jié)不出問題，越來越多的流程束縛住了巨輪的前行，巨輪變得很笨重。大家的工作也開始應(yīng)付各種流程中的細節(jié)。當(dāng)然這是極端情況，卻也反應(yīng)了流程是把雙刃劍。工作中并不是所有事情都可以依賴流程去保證萬無一失。
其實流程約束的是人。
一味的將責(zé)任推脫到流程的頭上，似乎讓大家都忽略了團隊中人才是主體。真正的去發(fā)揮人的主觀能動性。如果每一個成員都有自己強烈的ownership，那么上面我提出的兩個例子是否可以避免？比如交互稿完成了，交互主動的將稿件交付給產(chǎn)品做確認(rèn)，同時在設(shè)計交互稿的時候就與視覺開始溝通視覺風(fēng)格。而視覺同學(xué)，在已知該任務(wù)的安排下能主動的去詢問下交互的進度，并主動的提出前期與交互溝通開始設(shè)計工作。對于產(chǎn)品來說，關(guān)注自己own的需求，在交互設(shè)計過程中就不斷的與交互溝通確認(rèn)，并關(guān)注交互視覺的進度。三個環(huán)節(jié)環(huán)環(huán)相扣，跨越鴻溝，相互的溝通之間也可以碰撞出更多的火花，更好的去打磨我們的產(chǎn)品，這并不是流程可以事無巨細的去定義到，而是流程以外我們作為人這個主體的發(fā)揮。比如開發(fā)在接到需求的時候能找對應(yīng)的需求再次做個確認(rèn)，寫完代碼自測完成后能主動找到測試，并且將代碼交付給需求方，那也就不會臨上線了，大家還在追究這件事到底是怎么回事？我們可以約定工作的環(huán)節(jié)和交付，但我們改變不了人的工作方式。所以不要怪罪流程，這并不是流程的問題，而是人的問題。
激發(fā)團隊成員的ownership，培養(yǎng)積極主動的工作方式？
這似乎是個很難解決的問題。筆者從自己理解的角度粗淺的寫了幾點看法。希望能得到更多的探討。
1、 發(fā)揮leader的影響力。
Leader作為團隊最有影響力的人，要有正確的引導(dǎo)。從工作方式及態(tài)度上做積極的引導(dǎo)，多和團隊成員溝通，了解團隊的想法，去解除大家的顧慮和疑惑。真正發(fā)揮好一個leader的作用。
2、 信息透明+參與感
在團隊做事的時候大家一起溝通：我們?yōu)槭裁匆鲞@件事？做這件事我們期望得到什么？我們以什么樣的標(biāo)準(zhǔn)來衡量這件事？開發(fā)不僅僅只是寫代碼，他需要了解需求的背景，他也希望自己的產(chǎn)品受人喜愛。而產(chǎn)品策劃也不僅僅是產(chǎn)品策劃，他要知道這個需求的開發(fā)實現(xiàn)性和測試復(fù)雜性。只有信息透明，大家相互之間才能更好的理解彼此。同時對于產(chǎn)品也更有主人翁意識。每個環(huán)節(jié)大家都有意識的去主動“插一腳“，這也會使得自己做的本職工作更加出彩。
3、 以產(chǎn)品目標(biāo)導(dǎo)向而非KPI考核
大家是一個團隊，我們的目標(biāo)是產(chǎn)品成功，對于開發(fā)來說并不是代碼完成才是他的目標(biāo)，而對于交互視覺來說也并不是設(shè)計完成才是他的目標(biāo)。大家有共同的目標(biāo)。而不是劃分好二畝三分地只在自己的地塊耕耘好。建設(shè)美麗地球，人人有責(zé)，難道不是嗎？
流程是個利器，我們要用好這個工具，但不能完全的依賴流程。發(fā)生問題的時候多想想，怎樣從自身的工作方式出發(fā)去改進。所以請不要再“怪罪”流程啦，以人為本，才是長久之計。
免費領(lǐng)取驗證碼、內(nèi)容安全、短信發(fā)送、直播點播體驗包及云服務(wù)器等套餐
更多網(wǎng)易技術(shù)、產(chǎn)品、運營經(jīng)驗分享請訪問網(wǎng)易云社區(qū)。
文章來源： 網(wǎng)易云社區(qū)
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/25338.html
摘要：是的，就是這樣的錯很快就發(fā)布了修正。各種擔(dān)憂質(zhì)疑指向社區(qū)一直提倡和推動的和理念。得救之道，就在其中在的里回復(fù)說不要依賴于其他人，附了關(guān)于的鏈接，并且最后再次強調(diào)依然是合理的哲學(xué)。解除了用戶為你的代碼打包的負(fù)擔(dān)。 前情提要 今天 npm 圈子雞犬不寧，原因是一個不過 11 行的工具函數(shù) left-pad 被作者從 npm 上撤下，所有直接和間接依賴它的包就這么齊刷刷掛了，包括 babel...
摘要：問題什么是調(diào)用棧并且它是的一部分么調(diào)用棧當(dāng)然是的一部分。為什么理解是重要的因為你在每個進程中只能獲取一個調(diào)用棧。它是一個從事件隊列中跳去事件的循環(huán)并且將它們的回調(diào)壓入到調(diào)用棧中。當(dāng)調(diào)用棧為空的時候，事件循環(huán)可以決定下一步執(zhí)行哪一個。 你并不知道Node 原文：You don’t know Node 譯者：neal1991 welcome to star my articles-tra...
摘要：這一年，生活上過的不溫不火，工作上忙忙碌碌，思想上渾渾噩噩。想想還有幾個小時就要結(jié)束了，難免有點小激動，不知道是想著趕緊結(jié)束這毫無作為的一年還是想趕快迎來新的一年好大干一番手腳。 終章 距離6月26日凌晨12點半的時候?qū)懴滦蚱浆F(xiàn)在已經(jīng)是2017年12月21日了，電腦上時鐘剛好跳到12點30分，心情與外面陽光一樣正好。 這一年，偶爾聽起民謠時也會晃一晃神兒，想想以前喜歡聽的歌手的歌，...
摘要：不過大多數(shù)講解還停留在對功能使用的層面，其底層的很多原理，很多人可能并不知曉。每個線程池里的線程就僅僅用于請求那個服務(wù)。 歡迎關(guān)注微信公眾號：石杉的架構(gòu)筆記（id：shishan100） 每日更新！精品技術(shù)文章準(zhǔn)時送上！ 目錄 一、業(yè)務(wù)場景介紹 二、Spring Cloud核心組件：Eureka 三、Spring Cloud核心組件：Feign 四、Spring Cloud核心組件：R...
閱讀 1410·2021-11-22 15:25
閱讀 3430·2021-10-21 09:38
閱讀 1634·2021-10-19 13:21
閱讀 1052·2021-09-06 15:00
閱讀 1746·2019-08-30 15:44
閱讀 2639·2019-08-29 15:40
閱讀 3583·2019-08-29 13:44
閱讀 2132·2019-08-26 16:56
