題:
如何在工作中平衡質量和速度?
Jett
2020-07-03 08:24:38 UTC
view on stackexchange narkive permalink

我是一家大型投資銀行公司的軟件開發人員。

我工作的團隊有25人以上,並且我們有多個QA(質量保證)和Code Reviewers。

我的意思是用最謙虛的方式-我會盡力編寫最好的高質量代碼,並問代碼審查員,我認為他們對我所編寫的語言/應用程序最了解(我們的團隊處理多個應用程序,並非每個人都熟悉所有的應用程序)以獲取反饋,包括對我自己的改進和對應用程序的反饋-編寫無錯誤的代碼。

有時,這會使我自己的項目工作時間超出預期出於各種原因:

  • 有時候正確的方法比快速補丁需要的時間長(這是很常見的)
  • 我的項目與以前的項目有關(已解決),
  • Code Reviewer評論/拒絕我的代碼審閱請求,以使其更整潔,更高效, tc。(儘管我過去對此一直在喃喃自語,但我非常感謝他們為改進和解釋我的代碼為何不是最優而付出的努力。)

我是開始見到開發人員(我不確定他們是否總是或正在開始)-但他們將在項目上花費比預期少的時間(這對上層管理人員來說似乎很棒),但總是會發送給他們代碼審核給不熟悉該語言的團隊負責人/代碼審核員。我試圖給他們帶來疑問的好處,但是當我看到他們的代碼時,使用它令人沮喪,因為它顯然是“使它工作最快的方法”-這種風格。直言不諱,它非常脆弱並且容易出現錯誤。我認為他們正在將其發送給特定的審閱者,以使他們的代碼盡快獲得批准並繼續進行下一步。


我開始對此產生疑問的原因是因為我的經理只是看到每個人的統計信息,並為此不斷讚美他們。

“某某某人在3天內完成了5天的工作項目,並且始終如一地完成。”我幾乎總是至少接受預期的(如果不是更多的話)(我們的團隊傾向於低估項目,但這是另一個問題)。 / p>

我發現自己要加班很多(我們沒有薪水,所以沒關係),以盡可能提高質量/消除錯誤,但總的來說,我覺得自己在努力未被注意到,我的統計數據還不如編寫快速/輕鬆代碼以使其現在工作的同事好。

我不確定如何表達我的觀點,而不會聽起來像'____正在編寫完全垃圾代碼。'。

我個人肯定我不想遵循他們的步驟來增加我的數據,但是我不確定如何

  • 相對於我的團隊和高層管理人員,我看起來還不錯
  • 獲得批准的優質代碼
您有指定的代碼審閱者嗎?
嗨,OP。這個問題似乎有點長。您能否刪除不必要的詳細信息,並在問題頂部添加“摘要:[...]”?
在確定您的代碼以後需要多少工作之前,即突出顯示您需要選擇的不良代碼:加入其樣式或看上去不良。
開發人員不應該至少支持自己的項目一段時間嗎?如果您要做的只是代碼和轉儲,那隻是愚蠢的。下次提交空白文件,然後讓下一個人“修復”程序。
*某人花了3天時間完成了5天的工作項目,並且一貫做到了。
有點離題,但:“首先,你變得好,然後你就變得很快”
您的組織顯然功能失調。我們都去過那裡。您要么學會忍受它。或者您將精力放在尋找更好的公司或創辦自己的企業上。
我認為您的問題不是真正地如何在速度和質量之間取得平衡,而是如何獲得(您認為正確的)認可,以值得上級的努力。這裡有一個疑問,即是否以及如何向您的上司警告您的同事繞過了審核過程。
作為領導者,這句話使我發瘋:“某某在3中完成了他們5天的努力項目,並且始終如一地完成。”當我看到領導能力差時。我看到的要么是英雄模式,就是人們被迫保持不切實際的生產力,要么是一個組織實際上並不了解他們面前的工作。您的組織對團隊/個人相互競爭的這種想法感到遺憾。
開發人員必須接受事實,這取決於管理層……但是,很少有管理層了解。 而不是像您這樣的開發人員上鍊詢問“這樣可以嗎?”管理層看不起需求“它符合設計規範嗎?” 如果以世界上最好的意願,開發人員的回答是“是的,但如果……更好”,或者“是的,並且它告訴我們該規格存在缺陷,因為……”,那麼為什麼Aggressive-Manager先生不會回來呢?接近“那不是我問你的。是否符合規格?” 這能解釋您的大部分要求嗎?
至少,在進入正式測試階段之前,必須獲得2個或更多的PR批准。我鼓勵要求您團隊中熟悉相關存儲庫特定技術堆棧的任何人作為默認審閱者之一,並請QA團隊和經理保持完整性。鼓勵在實施之前討論解決方案,使用PR來防止錯誤並共享域/系統知識。
八 答案:
bishop
2020-07-03 12:02:38 UTC
view on stackexchange narkive permalink

我的項目與以前的項目(已解決)有關,存在很多錯誤,我將它們與我的項目一起修復。

停止償還債務。當您遇到錯誤時,將其記錄下來。如果它不妨礙您的工作,請繼續。如果是這樣,請徵求管理層的許可以進行修復。

這有兩件事。

首先,管理層發現您的時間表有所擴展,因為您正在發現(有時需要修復)其他錯誤。 。與現在的情況相比,您會被視為普通客戶。

其次,它向管理層表明其他開發人員在進行偽劣工作,而不考慮其估計的維修費用。與現在看起來超級英雄的情況相對。

同意,提交問題單。我們發現的另一件事是只有一個審閱者並不總是確保良好代碼的最佳方法。它允許非正式的“是的,沒問題”,如果其他開發人員參與審閱,則不會發生。您針對發現問題的歸檔錯誤將導致決定改進評論,因為它顯然工作得最好。
要添加到此答案的一件事:始終為該錯誤製作票證。如果這是一個阻止您的任務的錯誤,並且管理層已批准您進行修復,請在錯誤單中進行操作。獲得經過審查和測試的錯誤憑單,然後繼續執行您的主要任務。這樣做有幾個方面的好處,可以跟踪錯誤,不能從主要任務中修復它,您將完成更多任務,並且為主要任務記錄的時間將與估計更好地吻合。前兩個對公司很重要,後兩個對您來說很重要。
Matthew Gaiser
2020-07-03 11:16:10 UTC
view on stackexchange narkive permalink

管理權決定了平衡,尤其是在銀行業。

許多人並不真正欣賞經過更精心製作的代碼具有更少的錯誤。對他們中的許多人而言,新錯誤只是突如其來的工作,它突然冒出,而不是應計的債務,現在必須償還。在他們看來,一個帶有大量bug的快速實施方案的預算應為原始項目5天,而不是意外工作的預算為2天,而不是良好計劃的5天,因為另一個計劃很差。

您還必須記住,即使您的經理了解,他們的經理也會了解嗎?當您的經理面臨來自老闆的類似時間表壓力時。在這種情況下,有朋友在團隊中。團隊中的每個人都知道他們只是將票變成了錯誤。但是對於經理的經理來說,團隊似乎正在瘋狂地完成所有工作,這對他來說意味著他們的工作效率達到了頂峰。

我不確定如何表達自己的意見因此,聽起來好像“ ____完全是在編寫垃圾代碼”。有很多開發團隊在其中,垃圾獲得了獎勵,健壯的代碼獲得了性能改進計劃。

相對於我的團隊,對於上層管理人員而言,讓自己看起來並不糟糕

獲得批准的高質量代碼

我認為這些目標是不兼容的,除非您是一個比其他目標更好的開發人員,只是因為它們會(合理地)發布糟糕的代碼,這是管理層的回報。我知道為您的工作感到自豪,但您在這裡也將自己搞砸了。

銀行傾向於根據對結果進行數字評估的方式來關心結果。銀行員工傾向於做各種各樣的短視操作,以符合有關銀行的數字標準,這些標準就是一切,無論是開設賬戶(像富國銀行一樣很少關注同意),出售衍生品(雷曼兄弟,都不太關心)風險),推出信用卡(無論管理多少資產(如CIBC))或完成代碼分配(如在您的銀行)。

您正在嘗試與這裡的銀行文化作鬥爭。

我不知道,“您正在努力與這裡的銀行文化作鬥爭。”我不知道,金融業中的某些領域非常關注代碼的安全性和質量-沒有人願意發布可讓黑客從您的客戶那裡竊取數百萬美元的代碼, 畢竟。
如果從更廣泛的角度看待這個答案,那麼它的重點就很重要。管理層可能需要最初的高質量或快速設計,然後進行更長的質量保證審查。通過預先提高軟件質量,Question Asker可能會將第二小組的某些預期工作量轉移到您的時間表中。儘管一方面聽起來可能令人欽佩,但這可能意味著問題提問者正在將計劃工作的分配與管理層的想法有所不同,這實際上會使管理變得更加複雜,而不是最有幫助。
在銀行文化中,如果要引起人們的關注,請不要談論質量;談論風險。
Gregory Currie
2020-07-03 09:35:10 UTC
view on stackexchange narkive permalink

所有工作都是一系列妥協。俗話說:“好,快,便宜。選兩個”。

有時候,“最佳”工人是那些能夠平衡工作的人。這可能包括運送質量差的作品,這些作品以後可能會再次咬住您。話雖這麼說,很多時候,經理們認為他們有平衡的權利,只是因為將來某個項目會崩潰,而糟糕的質量又會重新咬下去。

對我來說這很明顯您所說的是有些人不贊成的工作正在得到批准。但是,您也建議這樣做會持續一段時間。

這意味著高級人員完全不了解您歸類為問題的內容,或者他們對提交的工作質量感到滿意。如果審稿人對他們幾乎不了解的工作給予認可,那麼不僅是梯子底部的那些人無法保證質量與您相同。

坦率地說,在這個階段,您似乎需要做出決定,如果您想成為理想主義者或被雇用。當別人似乎對現狀感到滿意時,晃動船將不是一個好辦法。

我會做什麼

首先,我會確保我的工作與管理層保持一致。這可能包括犧牲質量以提高速度。

然後,我將開始與審稿人和團隊負責人建立聯繫。盡一切努力確保最好的人正在審查工作。如果建立了這些標準,那麼所有其他問題都應該浮出水面。

如果我覺得這是一場艱難的艱難戰鬥,我會嘗試評估我是否可以在其他地方更好地工作。 / p>

俗話說:“好,快,便宜。選兩個”。說,實際數據可以證明這是錯誤的:https://youtu.be/8z2Ki9e5OV8?t=825
-1
-1
Patrick McElhaney
2020-07-05 19:20:13 UTC
view on stackexchange narkive permalink

我是一個存在類似問題的小組中的銀行業經理。我要假裝像您向我報告並告訴您我需要什麼:

  • 實現業務目標的緊迫感。
  • 如果您不知道目標是什麼,請詢問。 (是什麼驅動我們的經濟引擎,什麼是我們的使命宣言?)
  • 始終保持溝通。讓我知道是什麼讓您放慢腳步,以及它如何影響業務目標。
  • 如果發現問題,請解決此問題。不用擔心職稱,也不必等待許可,但請告訴我您正在做什麼,這樣我就可以在必要時重定向您。
  • 不要擔心快速而骯髒的解決方案。記錄假設和風險並將其完成。
  • 首先檢查您自己的代碼,以幫助代碼檢查人員。指出危害/風險,解釋替代方案和您的決策過程。
  • 不要讓代碼審閱者重複自己的動作。了解這些標準,預測它們的含義,並確保您的代碼達到預期的水平。
  • 擁抱錯誤並迅速失敗。如果您不確定,請堅持到底,繼續前進並繼續學習。
  • 儘早尋求反饋。有時候寫一個快速的技術設計並說“我打算解決問題的方法”會有所幫助。如果您在同一間辦公室,白板非常有用。
  • 小批量編寫代碼。在通過代碼審閱開始獲得反饋之前,不必“完成”代碼。只需在註釋中清楚說明代碼尚未完成以及您在哪裡尋求反饋即可。
  • 至少每天一次進行狀態通報,包括接下來的幾個步驟,完成這些步驟所需的ETA和阻止程序
  • 絕對編寫單元測試。如果您沒有大量的單元測試經驗,請不要陷入複雜的設置中。我希望您只測試易於測試的代碼,同時學習如何使代碼易於測試。
  • 抵制您知道的損壞的運輸代碼,但不要太難。記錄下發生的問題,包括解決問題的方法,並讓利益相關者打電話。

簡而言之,我需要您在提供我和其他信息的同時不斷提高輸出。這使我可以去找老闆說:看,我的團隊正在努力工作,他們專注於正確的事情。我們不會通過加大努力來提高生產力。但是,當我們著眼於質量和效率時,有很多改進的機會,並且它們有一些很棒的想法。特別是Jett,是我要帶領我們擺脫困境的人。

有人評論說,正確地做這些事情說起來容易做起來難。我同意!我是一名開發人員已有20年,並且在管理部門工作不到一年。為了增加影響力,我不得不“放手”做事,這確實很辛苦,並表明我願意為完成工作付出一切。從我的新觀點,我可以看到個人對“適當”的含義有不同的看法。每個開發人員都是本地優化。
“如果發現問題,請解決。”不,您不能吃蛋糕(“完成功能”)也不能吃東西(“清理爛攤子”)。您的工作是管理工作負載,確定工作的優先級,以便有序的隊列。要求您的報告解決問題,只是減輕了他們的責任。在他們走出去之前先停下來。
@bishop感謝您的反饋。我要說的是,如果您渴望解決問題,請繼續進行。如果我不重定向您,我會從您的工作中脫穎而出,即優先處理工作,並確保獲得應有的榮譽。我將有關如何確定優先事項的決定的一部分轉移給受該決定最直接影響的人們,這些人通常比受災地區的知識淵博。
@bishop Re:吃蛋糕並吃東西,清理垃圾的目的是什麼?如果解決問題並不能使我們在每個工作單元中為客戶提供更多價值,那真的是問題嗎?我的工作是減少工作量,同時提高生產率。很難,成功在這個行業中是罕見的,這是我們在此站點上尋求改進的原因之一。聽起來更好還是我仍在啟動BS檢測器?
@bishop如果該功能仍然混亂,則說明此操作尚未完成。
Bloke Down The Pub
2020-07-04 15:16:49 UTC
view on stackexchange narkive permalink

很明顯,您與一群牛仔一起工作,您不會改變這一點。他們的座右銘應該是“我們沒有時間做正確的事,但是我們有時間做兩次。”然後必須確保將其記錄在某處。

ky-chan
2020-07-03 10:35:50 UTC
view on stackexchange narkive permalink

問題取決於以下原因:

相對於我的團隊,對於我的高層管理人員來說,讓自己看上去並不糟糕

  • 項目交付,如果項目/任務已經按時或提前交付,即使它多麼容易發生錯誤,對於不了解後端流程的高級管理層來說,這對於他們來說都是一件非常好的工作。管理層將始終看到輸出,而不是質量。並且為了不讓自己的團隊看起來不好,除非您掌權或他們是一個開放的人,否則不要向他們施加理想。

獲得批准的優質代碼

  • 這些快速/快速代碼通過該漏洞的主要原因之一是這些代碼審閱者,他們對適當的編碼標準有些了解。例如,在我的案例中,有一個開發人員被分配給我們作為自動化測試人員,以便在推送我們的代碼時對其進行檢查,但是該開發人員並不真正理解如何製作一個非常好的工作代碼,所以發生了什麼,我的其他同事(相同的自動化測試人員,但第一次這樣做)的代碼我認為以後不會很好,因此被接受了。不久之後,這些代碼成為問題,但是該代碼審閱者對他批准的內容不承擔任何責任。我的觀點是,只要不會給他們帶來錯誤,他們通常會批准它,特別是在有時間限制的情況下。除非您將成為代碼審閱者或有能力推送內容,否則很難將自己的意見提交給他們。

我發現自己要加班很多(我們薪水無所謂),以盡可能地提高質量/消除錯誤,但歸根結底,我的統計數據不如編寫快速/輕鬆代碼以使其現在起作用的同事好。

  • 我認為您會做這些事而沒有人告訴您,因為您的統計數據不如編寫您的同事的數據好。採取主動是很好的,但是如果從長遠來看不知道這些代碼不好,那麼沒人會意識到。因此,停止您正在做的事情,然後嘗試將精力更多地集中在您的任務上。嘗試提高它,但是除非被告知,否則不要對其進行改進。他們不會看到需要提高質量的需求,除非您的應用程序因此而中斷。不好,但是建議,您需要讓他們意識到以便他們開始關心。
Oleg Lobachev
2020-07-04 04:54:49 UTC
view on stackexchange narkive permalink

人們在這裡談論管理層可能想要什麼,這是您當前工作的合適答案。我想在這個問題上有所作為,談論您的個人評估以及可能想要的,尤其是。幾年後。從我的角度來看,這是我的人生觀,就像我一生中做過很多編程一樣。

查找您的類型

有很多類型的程序員。有些喜歡原型。有些人喜歡充實一些次要的細節並加以修飾。我們大多數人都能做任何事情。實際上,在較小的項目(或寵物項目)中,您可能會發現自己在做從架構到維護的所有工作。

但是,找到自己最擅長的工作符合您自己的利益。通常,它與您最喜歡的是相吻合的。了解自己的優勢後,您可以在將來的項目中甚至在當前的工作中朝著它前進。嘗試更改您的角色,以便您可以做更多自己喜歡的事情。

是的,我知道,這聽起來微不足道。

但是請再考慮一下。您喜歡編寫高質量的代碼,而不喜歡嚴格的時間限制。它可能更適合您轉移到一些核心後端任務,而這些任務對質量的影響更大。例如,如果您喜歡原型設計,但不喜歡打磨東西,那麼某種R&D更適合您。說,評估不同的方法,原型,沒有。如果您喜歡修復錯誤並且不喜歡編寫新東西,請請求移至維護團隊並與測試人員結伴。您明白了。

基本上,您的問題是“如何平衡我喜歡做的事情和如何減少我不喜歡的事情,但是需要做的事情”。同樣,我的建議是“嘗試做更多自己喜歡的事情,少做一些自己不喜歡的事情”。它可能對您當前的工作場所無濟於事,所以您可能希望將其保存以備下一次求職之用。

Ian Kemp
2020-07-03 19:07:08 UTC
view on stackexchange narkive permalink

核心問題是您的經理不關心代碼質量,因為他們沒有動力這樣做。因此,第一個問題必須是:您是否可以激勵他們進行護理,例如通過跟踪浪費大量的時間來重新編寫快速的開發人員的錯誤代碼?

不幸的是,我想答案是“否”。我還要猜測您的經理是非技術性的丑角,他使用開發人員估算作為向經理提供的指標,而較小=更好。換句話說,他們沒有理由關心代碼質量,因為質量快但質量差的代碼會對他們產生積極的影響。因此,管理者也沒有零動機來改變那些表現不佳的開發者的行為,因為這種行為會給他/她帶來積極的好處。阻止您嘗試提高代碼質量。因為他們是一個政治上強大的團體,所以您將無法通過他們。你必須四處走走。您不太可能獨自做到這一點,因此問題就變成了:您是否能夠並願意建立自己的團隊,使質量優先於速度,並且擁有比您經理更大的政治資本

如果答案是否定的,您需要在屈服並成為快速團隊中的一員之間進行選擇,或者找到另一份工作。

如果答案是肯定的,然後組建團隊,並開始在自己之間收集證據,以證明快速開發者所具有的效果(浪費時間和金錢)。一旦有了足夠的證據(政治資本),就將其提交給您的經理。當您的經理忽略它時(因為他們當然會),將其與被忽略的信息一起呈現給上級。假設上級實際上在乎不浪費金錢,那之後事情可能會很快改變。

是的,這是極端建議;但是從經驗上來講,這是您正在考慮的極其艱鉅的戰鬥。像您的經理這樣的人,總會很快選擇好於正確的人,因此,讓那些人願意選擇正確(質量)的選擇幾乎是不可能的。如果您不打算參加此類鬥爭,那麼您的選擇還是會再次-接受現狀,或者繼續前進。

是的,他公司的流程已中斷。“我認為他們正在將其發送給特定的審閱者,以使他們的代碼盡快得到批准,然後再進行下一步。”


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...