国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

請不要怪罪流程

MiracleWong / 3024人閱讀

摘要:但流程不是死的,尤其在互聯網公司,只要有助于我們的目標達成,那么流程只是一陣東風。工作中并不是所有事情都可以依賴流程去保證萬無一失。所以不要怪罪流程,這并不是流程的問題,而是人的問題。所以請不要再怪罪流程啦,以人為本,才是長久之計。

本文由作者周巧芬授權網易云社區發布。

筆者所在的團隊這段時間正在兩個版本的交接期,前一個版本馬上要上線了,但后一個版本的需求早在三周前就已經啟動,卻遲遲沒見到交互稿。作為開發前置的視覺跳腳了:為什么交互稿還沒有,回頭開發時間緊了又怨視覺稿沒及時給!而交互呢,雙手一攤:沒有人找我們要交互稿啊,需求owner產品策劃都沒主動來問需求的交互進度啊。于是大家都開始面面相覷,流程上沒有定這個環節啊,流程默默的背上了這個“鍋”。

再有一個例子,某模塊的功能需要依賴另外一個組的開發,這個問題直接溝通到開發,開發就默默的修改好了,等到臨上線,大家都在催促這個依賴代碼怎么還沒上線,找到開發,對方說:我只知道要開發,找不到測試的人,我自己測了下沒問題,還在本地庫里。然后就沒有然后了。于是大家又開始說:這個流程有問題,blabla…..流程再次默默的背上了這個“鍋”。

可是真的是流程的錯嗎?嚴密的流程真的可以解決問題嗎?

回到我們為什么要有流程?

一般來說流程是為了梳理我們的工作程序,讓大家遵守并有效的銜接各部門以及各環節的工作,同時知會到相應的人員。但流程不是死的,尤其在互聯網公司,只要有助于我們的目標達成,那么流程只是一陣東風。而在真實的工作場景中,往往碰到跨部門的合作需要有一定的流程規范。這個原因多半是因為,跨部門之間的不是特別熟悉,大家有各自的工作方式和KPI目標,或者說個體并不在意其他部門的工作,而只要保證你給我的輸入按時保質即可。

好吧,既然現實如此,于是我們制定流程來約束大家按時保質的做輸入輸出,公司的巨輪慢慢的啟動起來。但似乎這個流程也如同巨輪的枷鎖,當流程的某一環節出現問題,巨輪要么停滯,要么部門間友誼的小船說翻就翻了。于是去制定更細致的流程去避免另外流程的環節不出問題,越來越多的流程束縛住了巨輪的前行,巨輪變得很笨重。大家的工作也開始應付各種流程中的細節。當然這是極端情況,卻也反應了流程是把雙刃劍。工作中并不是所有事情都可以依賴流程去保證萬無一失。

其實流程約束的是人。

一味的將責任推脫到流程的頭上,似乎讓大家都忽略了團隊中人才是主體。真正的去發揮人的主觀能動性。如果每一個成員都有自己強烈的ownership,那么上面我提出的兩個例子是否可以避免?比如交互稿完成了,交互主動的將稿件交付給產品做確認,同時在設計交互稿的時候就與視覺開始溝通視覺風格。而視覺同學,在已知該任務的安排下能主動的去詢問下交互的進度,并主動的提出前期與交互溝通開始設計工作。對于產品來說,關注自己own的需求,在交互設計過程中就不斷的與交互溝通確認,并關注交互視覺的進度。三個環節環環相扣,跨越鴻溝,相互的溝通之間也可以碰撞出更多的火花,更好的去打磨我們的產品,這并不是流程可以事無巨細的去定義到,而是流程以外我們作為人這個主體的發揮。比如開發在接到需求的時候能找對應的需求再次做個確認,寫完代碼自測完成后能主動找到測試,并且將代碼交付給需求方,那也就不會臨上線了,大家還在追究這件事到底是怎么回事?我們可以約定工作的環節和交付,但我們改變不了人的工作方式。所以不要怪罪流程,這并不是流程的問題,而是人的問題。

激發團隊成員的ownership,培養積極主動的工作方式?

這似乎是個很難解決的問題。筆者從自己理解的角度粗淺的寫了幾點看法。希望能得到更多的探討。

1、 發揮leader的影響力。

Leader作為團隊最有影響力的人,要有正確的引導。從工作方式及態度上做積極的引導,多和團隊成員溝通,了解團隊的想法,去解除大家的顧慮和疑惑。真正發揮好一個leader的作用。

2、 信息透明+參與感

在團隊做事的時候大家一起溝通:我們為什么要做這件事?做這件事我們期望得到什么?我們以什么樣的標準來衡量這件事?開發不僅僅只是寫代碼,他需要了解需求的背景,他也希望自己的產品受人喜愛。而產品策劃也不僅僅是產品策劃,他要知道這個需求的開發實現性和測試復雜性。只有信息透明,大家相互之間才能更好的理解彼此。同時對于產品也更有主人翁意識。每個環節大家都有意識的去主動“插一腳“,這也會使得自己做的本職工作更加出彩。

3、 以產品目標導向而非KPI考核

大家是一個團隊,我們的目標是產品成功,對于開發來說并不是代碼完成才是他的目標,而對于交互視覺來說也并不是設計完成才是他的目標。大家有共同的目標。而不是劃分好二畝三分地只在自己的地塊耕耘好。建設美麗地球,人人有責,難道不是嗎?

  流程是個利器,我們要用好這個工具,但不能完全的依賴流程。發生問題的時候多想想,怎樣從自身的工作方式出發去改進。所以請不要再“怪罪”流程啦,以人為本,才是長久之計。




免費領取驗證碼、內容安全、短信發送、直播點播體驗包及云服務器等套餐

更多網易技術、產品、運營經驗分享請訪問網易云社區。

文章來源: 網易云社區

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/25338.html

相關文章

  • 得救之道,就在其中——關于這次的 kik,left-pad,和 npm 事件

    摘要:是的,就是這樣的錯很快就發布了修正。各種擔憂質疑指向社區一直提倡和推動的和理念。得救之道,就在其中在的里回復說不要依賴于其他人,附了關于的鏈接,并且最后再次強調依然是合理的哲學。解除了用戶為你的代碼打包的負擔。 前情提要 今天 npm 圈子雞犬不寧,原因是一個不過 11 行的工具函數 left-pad 被作者從 npm 上撤下,所有直接和間接依賴它的包就這么齊刷刷掛了,包括 babel...

    gaara 評論0 收藏0
  • [譯]你并不知道Node

    摘要:問題什么是調用棧并且它是的一部分么調用棧當然是的一部分。為什么理解是重要的因為你在每個進程中只能獲取一個調用棧。它是一個從事件隊列中跳去事件的循環并且將它們的回調壓入到調用棧中。當調用棧為空的時候,事件循環可以決定下一步執行哪一個。 你并不知道Node 原文:You don’t know Node 譯者:neal1991 welcome to star my articles-tra...

    miqt 評論0 收藏0
  • 醒來或者吃飽又是一年

    摘要:這一年,生活上過的不溫不火,工作上忙忙碌碌,思想上渾渾噩噩。想想還有幾個小時就要結束了,難免有點小激動,不知道是想著趕緊結束這毫無作為的一年還是想趕快迎來新的一年好大干一番手腳。 終章 距離6月26日凌晨12點半的時候寫下序篇,到現在已經是2017年12月21日了,電腦上時鐘剛好跳到12點30分,心情與外面陽光一樣正好。 這一年,偶爾聽起民謠時也會晃一晃神兒,想想以前喜歡聽的歌手的歌,...

    wenshi11019 評論0 收藏0
  • 拜托!面試不要再問我Spring Cloud底層原理!

    摘要:不過大多數講解還停留在對功能使用的層面,其底層的很多原理,很多人可能并不知曉。每個線程池里的線程就僅僅用于請求那個服務。 歡迎關注微信公眾號:石杉的架構筆記(id:shishan100) 每日更新!精品技術文章準時送上! 目錄 一、業務場景介紹 二、Spring Cloud核心組件:Eureka 三、Spring Cloud核心組件:Feign 四、Spring Cloud核心組件:R...

    wums 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<