您似乎在混淆兩件事：

• 他們工作了幾個小時才能遇到意外或計劃外的問題。

• 他們負責並以可預測的方式提供高質量的工作。

所有權並不意味著團隊要整夜工作以兌現您對客戶的承諾。所有權是關於了解代碼中的內容，代碼的工作方式，制定計劃並能夠告訴您如何以及何時完成工作。所有權是指開發人員做出正確的決定，因此代碼不僅在今晚而且在未來的幾年內都保持正確性。您的帖子。經常導致以下情況：

• 缺乏明確的任務授權
• 不斷變化的需求
• 短期關注
• 持續的緊迫性

請您詳細說明一下，作為經理，您為準備發布這些版本，增強您的團隊能力以及如何聽取他們的反饋意見做了哪些工作？然後我們可以談談所有權。

甚至當我告訴他我現在需要它時，他說他還有其他事情要做，當我不在那裡時就偷偷溜走了。傢伙又說了同樣的話-“我今天做不完。我和朋友開會，我得走了。”然後在我和經理談話時他偷偷溜走了。去做這項工作，然後再不做。偷偷摸摸暗示他在欺騙或不誠實，但這聽起來像他在透明，你應該認識到這一點。我曾與那些說他們會處理事情然後消失的人一起工作，那些人應該被解僱。告訴您帶寬的人然後跟著走的人完全不同。這個人的誠信不是問題。

上週，我在一次團隊會議上告訴他們我期望更高的主人翁意識。如果他們答應某事，他們應該這樣做。如果存在嚴重的錯誤，即使必須待到很晚也必須修復。

1. 嚴重錯誤實際上必須是嚴重的。例如，在我自己的職業生涯中，我遲到了一些修復“關鍵”錯誤的工作，這些錯誤隨後兩個月都沒有部署到生產中。在那種情況下，那是經理瘋狂地想要一些東西，而不是一個嚴重的錯誤。當然，實際上也存在一些關鍵問題。
2. 人員配備水平通常必須足夠。滿足發布日期和解決問題很重要，但是如果我們總是遲到，因為我們有3個人從事4個人以上的工作，那就是另外一種情況。
ol>

處理這樣的問題？

某些開發方法具有內置的方法來管理這些問題。例如，在敏捷開發中，衝刺是保證將交付哪些工作的方式。它還包括測量速度（完成的工作量）的內置方法，並且通常與軟件（JIRA是我認為最受歡迎的軟件）一起使用，該軟件可以確定團隊或個人是否實現了這些目標。在敏捷開發中，如果您需要更改過程的中間衝刺（例如花一些時間來修復關鍵錯誤），則表明您正在固有地更改範圍。通常，您將東西取出以添加必須添加的內容。這個過程非常容易評估“我今天不能實現”是因為他正在努力實現其他重要目標還是因為他很難。

IMO，這是一種出色的方法不幸的是，幾乎從來沒有正確完成過軟件開發。

更新：針對問題編輯，此錯誤本質上是絕對關鍵的（在大多數公司中，其名稱為使用showtopper（而非關鍵），應立即修復。我將遵循上面描述的技術-從他的盤子上取走東西，以換取他現在就開始工作。這使得90％的用戶無法登錄值得一夜。您需要評估該員工是否已經完全簽出（在這種情況下，您必須幫助他轉職到其他工作上）或該項目是否使他感到疲倦並且需要休息一下。

在我的辦公室中，我們經常引用以下內容：

“您方面的計劃不周全無須緊急應對。”

根據我的經驗，開發人員通常會主動幫助解決由於自己的錯誤或無法預料的事情而出現的問題。

但是，經常發生的所有問題不僅令人驚訝在決定給開發人員最後通and並可能使他找一份新工作之前，您應該問自己以下幾點：

• 您是否做了足夠的工作以避免“關鍵” ”首先是bug？您是否給開發人員足夠的時間來執行測試，代碼審查，重構和監視？

• 您是否確保在有足夠的時間修復新功能時激活它們？ （而不是傍晚或星期五）。

• 如果常見的重大錯誤，您是否支付足夠的加班費或值班時間？

• 您要擁有所有權的開發人員是否“擁有”發布過程？如果他們認為功能有問題，他們是否能夠停止發布功能？

• 您的截止日期是否切合實際並與開發團隊達成了共識？

如果所有問題都可以明確回答“是”，那麼您可能必須放開高級開發人員。

如果任何答案是“否”。或“我不確定”，那麼我將開始在管理中尋找問題並首先解決這些問題。

您聲稱團隊缺乏所有權。開發人員構建的所有內容均歸公司所有，而不是公司所有。當您說員工應該“擁有”工作成果時，是否還意味著他們將獲得這些成果為公司帶來的利潤？如果不是那樣的話，那麼他們就不會真正擁有該作品，也無法向他們要求所有權。

如果存在嚴重的錯誤，即使他們有錯誤，也必須對其進行修復

您的解決方案通過使您的員工遲到來解決關鍵問題，這對於公司來說很方便，員工也可以為此付出代價。同樣，如果他們也能分享利潤，那將是可以的。是嗎？

在此特定示例中，該錯誤阻止90％以上的用戶登錄系統。平均來說，這是今年一次，而去年是兩次。

這種情況經常發生，並且您無需安裝組織程序來減少這些錯誤的影響，

實際上，您當前用於解決“關鍵”問題的方法以及對員工的解僱計劃都可以視為功能失調的組織的標誌。您員工的行為可能是他對此做出反應的方式。您對原始問題的更新中列出了您認為自己在做的事情正確（而不是認為自己在做的事情錯誤），這也表明您可能有一個

在要求員工遲到之前，管理人員可以採取許多措施來提高質量並減少緊迫性：

1. 無論您認為有多專注於質量，結果都表明您沒有。您必須認真提高開發過程的質量，這可能意味著諸如審查，檢查，結對編程，增加測試，重新設計關鍵組件，改進體系結構和設計等措施。您最好開始分析引起這些問題的組織問題寫下您已經實施的措施清單。顯然，它們無法正常工作。
2. 為什麼您的員工必須遲到才能解決錯誤？您可以在清晨發布版本以使開發人員在整個工作日內解決問題嗎？
3. 您是否考慮過使用功能切換或其他措施來快速恢復到該功能的先前版本您的團隊時間來解決問題？
4. 您不能責怪您的員工在晚上突然出現問題時制定了計劃。您可以在關鍵版本發布之日安裝備用系統。然後人們會事先知道他們可能必須待到很晚才能做好相應的準備。
ol>

這在軟件工作中很常見。

您將員工視為專業人員。您說的是所有權，但隨後提出了必須立即修復“嚴重”錯誤的要求。

該錯誤實際上是“嚴重”錯誤嗎？是要求不明確的結果嗎？我們的老朋友“範圍緩慢” '？

在每個方面，您（作為經理）都需要管理期望。並非每個錯誤都是“嚴重的”。要求可以吸。項目範圍發生了變化。

他們並沒有要求他們將所有精力投入到與團隊進行“關鍵”合作的工作中，直到何時解決。

我一直將“關鍵”用引號引起來，因為在該領域工作了30多年（我很老）之後，這個詞就被濫用了。一切都不是“關鍵的”。

有了更新的問題，現在很明顯，您正在嘗試解決錯誤的問題。高級工程師的行為是軟件開發過程根本中斷和/或公司運作不正常的徵兆。

如果您每個月都有重要的缺陷投入生產，那麼您至少會遇到以下問題之一：

• 不稱職的工程師
• 代碼庫無法維護
• 測試不足

您需要更深入地研究並解決潛在的問題，這些問題導致人們需要不斷地工作至深夜。說服一位工程師經常工作到更長的時間並不能幫助我們了解全局。

現在，該怎麼做...

步驟1：找出原因測試未捕獲到這些關鍵錯誤

您絕對需要做的第一件事就是阻止這些關鍵錯誤進入生產環境。到達生產環境的每個錯誤都是測試過程中的失敗。

回顧一下在生產環境中發現的每個關鍵錯誤，並確切確定為什麼未在測試中捕獲該錯誤。添加更多自動測試範圍，手動測試範圍或必要的測試資源。

步驟2：確定每個嚴重錯誤的根本原因

對於每個嚴重的錯誤，找出來：

• 創建錯誤的人
• 創建錯誤的時間
• 為什麼要修改代碼
• 代碼中引入了錯誤的地方

通過進行此分析，您將發現一些模式。也許有一兩個開發人員不斷引入這些錯誤。也許有一個很難修改而又不會引起問題的代碼模塊。或者整個代碼可能很難使用。

我想補充一點。趕出錯誤修復程序通常會導致技術負擔。如果您的高級開發人員質疑今晚將如何測試它，那麼高級開發人員應該問這個好問題！我在緊急情況優先於質量的地方工作，這對長期產生負面影響。最終，您的團隊的能力將下降，因為它總是在撲朔迷離。

聽起來您有一個巨大的測試問題。您問為什麼每個人都不會放棄所有外部承諾去滅火，但真正的問題是為什麼每個月都開始發生火災？

您有任何質量檢查/測試人員嗎？為什麼他們沒有發現第一步和最基本的步驟（登錄）不起作用。完全無法正常工作的東西如何被推到生產環境。

為什麼您對用戶無法登錄以使每個人都呆在後面而又急於解決“緊急”補丁而不是擁有系統的回應管理員還原了該更新，並且在解決問題之後，可以稍後再次嘗試更新。

“今晚我們將如何測試該更新？”這是正確的答案。當存在關鍵問題並且您現在被迫要解決此問題時，開發人員將如何留出時間來適當地檢查更改是否正確/高質量，質量檢查意味著檢查更改後其他所有內容是否仍在正常工作。聽起來好像您還在每個人都累了的一天結束時要求這些更改，而他們的思維能力卻處於最低水平，這使得其他問題更有可能潛入此關鍵修復程序中。

什麼時候人們最有生產力？團隊何時最有能力處理關鍵錯誤？已經有研究回答了有關何時人類最有能力執行某些任務的問題。

您有一個嚴重的錯誤，並且您想要a）換個思路，b）拿起一個新的“關鍵”任務，c）“直到任何時候都可以修復”。您希望這個關鍵補丁能夠正常工作嗎？老實說，您對產品，團隊，團隊成員的期望是什麼？

放開您的自我和您的非理性的信念。

您要查找的術語是自主努力，而不是所有權。

我假設您的員工正在履行合同義務（否則，

您無權期望自行決定的努力。這就是定義。從根本上講，這不是您可以與他們談論並期望有所改變的事情。您可能會得到相反的響應。他們沒有義務給予它。解僱他們的威脅可能會引起壓倒性的反響，而且是違法的。

對於如何改進事情，我沒有任何好的建議。您可以依靠某些人的酌處努力這一事實向我表明，這種文化並不一定會被破壞。

解決此問題需要花費時間，因此，我可以提供權宜之計： / p>

固定1的總線係數

為什麼只有一個員工才能解決此問題？

請啟用呼叫名冊

根據與個人員工達成的報銷協議，而不是您認為值得的費用。

在更好的時間發布更新 >

這也許是不可能的，但是在更好的時機推出它可以增加有人提供幫助的機會。

軟件的價值取決於軟件的性能支持，因此您不應該將酌情處理權用作拐杖。如果您希望軟件得到一定程度的支持，則需要確保已準備就緒。

因此，您希望您的員工為解決問題而放棄社會生活和/或家庭生活嗎？

他們真的那麼重要嗎？

strong>

經理們似乎總是認為一切都很關鍵，因為拒絕很難。這是您的首席開發人員後退的強大潛在原因。他們試圖保護自己的疆界，因為你不會。他們會保護您的團隊，因為您不會這麼做。

如果他們確實如此關鍵，那麼出什麼問題了，這些問題就發生了嗎？

如果您的產品質量很差，那麼您需要轉移並讓開發人員制定計劃以使產品恢復正常。質量差不僅是錯誤。質量差會破壞可預測性。如果您由於質量太差而一貫不按計劃進行，請修正質量。而且，您不會通過要求開發人員在自己的時間內進行修復來解決此問題。如果這是您設定的期望，那麼您就是在告訴開發人員該業務不關心質量，因此不重視可預測性。如果您不重視可預測性，那麼就不要抱怨。

如果它們確實很關鍵，那麼為什麼不計劃進行輪班？

這不僅可以保護員工的個人時間並保護企業的需求，還可以激勵開發人員解決導致他們大打折扣的系統性問題。 （也許您需要更多或更好的測試，也許您的舊代碼有問題，等等。）

您為什麼不遲到並修復問題？

您抱怨有人沒有整夜努力解決問題。您為什麼不整夜工作呢？我想您會得出與團隊負責人相同的結論。

您的行為

您揚言要解僱您的員工，因為他們沒有做自己拒絕做的事情。您抱怨這種情況經常發生，但您並未計劃通過輪換或償還技術債務來進行計劃。

在閱讀計劃發行的步驟清單時，對我而言最突出的是頻繁使用“我告訴他們...”以及從頭到尾進行規劃的粒度。您計劃了易於更改的次要細節，但不會計劃產品的支持流程。

這是您100％的問題。

您的團隊

在我看來，您有一群聰明，誠實，專業的人士，他們知道如何製作出色的軟件，但是他們的經理喜歡向他們指示如何做工作以及何時採取這種方法會導致問題，迫使他們工作更多小時。您是否問過您的團隊，他們認為他們應該如何應對意外的關鍵問題？

您的團隊領導正確地推遲了您的期望。我很高興聽到他鼓勵他的團隊對事情說不。

在我作為團隊負責人的那段時間裡，我可以告訴你，最難但最重要的課程之一就是學習如何拒絕。也許您可以從您的這個員工那裡學到一些東西。

您不能強迫某人加班（取決於國家/地區以及法律規定的潛在極端情況）

如果該人不能或不願意因此，如果任務很重要並且需要立即關注，找到願意的員工或僱用外部幫助是您的責任。

請您所在轄區的職業律師進行澄清。

關於所有權以及完成已分配或已承諾的任務，您將一直擁有紀律處分庫，直至終止僱傭合同。

此外，還有什麼塞菲說...

回答更新的問題：

您的大問題不是缺乏所有權，就是。。相反，這似乎是一個更深層的，潛在的問題的徵兆：開發過程似乎已基本中斷。

從理論上講，您的過程（即自動測試&測試覆蓋率，衝刺計劃，沒有突然發生）需求變更）應該可以避免您看到的大多數問題。

根據您自己的陳述，即使在部署到客戶時，您也遇到了程序的多個“ Showstopper”問題，其中有些甚至是回歸問題。衝刺未按時完成（測試是衝刺的一部分）。即使編寫測試，也無法提供足夠的覆蓋範圍來捕獲這些錯誤。您還說過您已經處於“熬夜”的情況（事後請假幾天）。

您需要找出問題所在。只有找到並解決根本問題，您才有望解決問題。

如果90％的用戶無法登錄，並且用戶無法進行購買（即銷售丟失），則需要立即將更新還原到以前的工作版本。與簡單地恢復到以前的版本相比，等待開發人員進行故障排除和修復錯誤可能會花費更長的時間，並給用戶帶來更多負面影響。

更重要的是，開發人員不太可能希望繼續工作如果您有更好的解決方案，他們將被迫加班。如果您珍視員工，則應該尊重他們的工作時間。

回答更新的問題

似乎遵循了良好的工作習慣：

1. sprints
2. 功能已鎖定，即將部署 li>開發人員的時間估算
3. 自動化測試
ol>

我部分同意存在一種積極的文化，可以修復關鍵的錯誤，但這種文化也需要反映沒有代碼是完美的，除非您花了很多錢，否則就有一個古老的樓層說 NASA每行代碼花了大約1,000美元！。我不會在文化方面發表過多評論，因為其他方面已經對此進行了討論，而是提出了一些方法論建議：

目前時尚界的一個團隊結構是擁有全力以赴的特長隊。最終交付和他們對孤立垂直行業的運營責任。如果出了問題，那是晚上醒來的人，但是我會謹慎地在遺留環境中引入它，因為如果團隊沒有機會從一開始就引入他們想要的質量，它將引起不適。 -走。而且具有合同/薪水的傳統Ops角色可能更適合隨叫隨到的工作方式。

一個更好的主意是在團隊中引入質量檢查冠軍的想法，並引入“ 3個好友”產品，開發人員和QA成員都共同編寫功能規範（行為驅動設計）。這確保了從一開始就考慮了“質量保證成員將如何破壞它”，並且它應該足夠詳細，即以示例方式進行說明。質量檢查成員不必是編寫自動化程序的人，但他們應該對其進行代碼審查。正如人們在上文中提到的那樣，代碼編寫者不應該獨自負責認證代碼的質量，並在過程中儘早引入第三者是積極的舉措。

也許還需要增強生產環境和發布管理。 “藍/綠部署”和“生產中的測試”是常見的做法，只有在指標證明自己的情況下，才將更改逐步推廣到越來越多的受眾。理想情況下，您的登台環境應該捕獲關鍵的錯誤，但是生產總是存在一些 差異，因此它永遠都不應該是一個大爆炸版本。典型的發布節奏，您不妨考慮更頻繁地發布。如果結合良好的測試和發布自動化，則更頻繁的較小發行版可以降低風險。可以將其與功能開關配對使用，以便在撰寫用戶故事完成時可以完全打開功能。

我閱讀了您的更新。您的問題是您運送了損壞的產品。而已。這就是您需要進行的工作-不要運送損壞的產品。

您的投訴很荒謬。您決定在產品損壞時發貨。那就是您止步不前的地方。

然後您犯了兩個錯誤：首先，似乎發佈時間如此，以至於下午4點被告知。在開發人員上班前半小時發布。非常簡單的解決方案，這是您的工作。其次，員工似乎沒有動力加班。支付加班費通常效果很好。不允許您定期發布破損代碼的環境。

鑑於更新後的問題，我建議您雖然可能會遇到僱員的態度 ，但實際上您遇到的是 軟件質量 問題：

1. 沒有獨立於正在編寫這些功能的開發人員的質量保證流程。眾所周知，開發人員在測試自己的代碼方面很糟糕，主要是因為他們自然而然地開始假設他們編寫的任何東西都應該做，並且應該按照他們的意圖 工作，而不是最終用戶期望。

2. 您擁有的任何測試環境都不足以重現客戶發現的問題。您確定了在該過程的多個階段阻止登錄的錯誤，但是最終檢查並未發現此問題。

3. 高級開發人員願意忽略其實很關鍵。 “ Dude，我和我的朋友今晚要做一些很酷的事情”不是 的反應，因為“沒人可以登錄，因此我們的業務損失了100％的產品使用收入”要支付薪水”。如果這是他對緊急情況的反應，您認為他如何處理小事？還是更注重細節？

ol>

您更新後的故事中有一個特定部分對我提出了更多問題，我認為您需要詳細調查：研究小組指出，在這一過程中，有一點是他們編寫了所有測試，沒有任何問題。然後您再說，發現並非所有測試都寫完了，沒有發現登錄錯誤，並且您花了更多時間編寫這些測試和解決登錄問題，後來在生產中進行了演示。不固定。

1. 您說的測試畢竟不是寫的，為什麼為什麼沒有寫？是該案件是一個疏忽，還是團隊誤解了他們的工作完成情況？前者有合理的期望會偶爾發生，後者是您需要明確的不可接受的行為，將來您不會再容忍（除非您誤會）。

2. 一旦編寫了測試，您怎麼知道這些測試是正確的？您是否檢查過測試？顯然，它們不起作用；他們都通過了，但是經過明確測試並認為已解決的問題仍使它投入生產。不道德的人編寫測試以使其始終通過的情況並不少見，特別是在有最後期限壓力的情況下。如果您自己無法審查測試，則應該找其他團隊的技術人員來為您審查測試。

ol>

您還寫了一些其他文章，關鍵錯誤的數量現在每月最多一次，但是在此之前，每年至少一次或兩次。這是為什麼？您是否已經調查了為什麼會發生這種情況？在這段時間內產品或團隊是否發生了重大變化？聽起來質量好像在下降。獨立的質量檢查測試（您應該在整個公司範圍內進行此測試，但是由於質量下降，該團隊尤其需要它）。

3. 查看測試環境並與生產進行比較，以確保測試環境仍然可以反映生產。

4. 與您當前相比，定期檢查您的團隊為確保質量和正確性而編寫的測試和代碼。

   >
ol>

您可能在與高級管理人員的團隊中存在態度問題，但是您 肯定 有質量問題。態度問題很難解決，但是質量問題更容易解決，而且如果您做對的話，會使團隊中一個人的態度變得無關緊要。

我自己是一名高級團隊成員，不得不一次又一次地應對這種情況，我只能說，一個您一直可以依靠的人也需要一些動力。這個人肯定是誠實的，並有權在下班後享有個人生活，但如果有更好的動力，或者您設法為他創造一個友好的環境，他將留下並修復錯誤。

思考反過來說：如果這個人生病或離職或有緊急情況，必須離開辦公室一段時間。目前，他和朋友在一起的時間對您來說似乎是個問題，但即使在上班時間，他也可以滿足所有合法的離開辦公室的要求（下班後與朋友共度時光也是合法的需要）。

一種非常普遍的管理態度是始終對有能力做到這一點的人進行培訓。現在，這因人而異，但作為一名僱員，這可能會導致挫敗感，當僱員開始對您說否時，就會出現這種情況。

所以我認為您需要做兩件事：

1：），您應該為下屬員工創建一個學習平台，並逐步委派工作，這樣在有緊急需求時您不必去看每次都是同一個人。

2：），只要該人在辦公時間內完成了他應該做的事情並達到了他的KPI，他就很好了，需要友好地對待方式。

在我看來，他對離開辦公室的重視程度遠高於在辦公室。

原因很多，一個好的經理不能簡單地承擔最壞的打算。也許他在家裡有個人問題，無論是人際關係，疾病還是其他壓力。

也許他對工作感到不滿，根本不在乎。

他之所以會表現出自己的行為，有很多原因。我建議您在過度折磨他或對他進行訓練之前，先看看是否有想要給予額外恩惠的東西。

歡迎來到WorkPlace，這一切都是經理的錯。 一切。

我看著它，因為他們說產品已經準備好了，但還沒有，所以他們需要保持言行一致。 –代碼項目

以不同的方式提出問題。
您有一位高級工程師，他被指派負責一項功能，負責測試並通過了最終產品。綠燈亮的產品存在嚴重的質量問題。 （並且我同意您的定義非常關鍵！）
換句話說，您有一個表現不佳的高級工程師，他不想為了糾正自己的錯誤（或者按照您的說法，實現自己的錯誤）而加班。承諾）。

但是這裡的關鍵不是工程師不會加班-從評論中可以看到您有一個移動應用，因此您不可以發布修復程序
關鍵問題是高級工程師首先要為這些壞掉的產品開綠燈。

這裡的期望/法律很大程度上取決於您所在的位置位於，但以個人名義，我從未在一家公司（美國或日本）工作過，在該公司中您的高級工程師缺乏所有權是可以接受的。無論是否有過失，都必須盡快解決嚴重錯誤。幸運的是，我也沒有在一家公司工作過，因為我至少沒有（在合理的範圍內）為自己的努力付出報酬。我自己的錯誤。

這裡的下一步是查看並找出為什麼發生這些錯誤。這裡的大多數答案都表明問題是系統性的-我要說的是，多個團隊中只有一個存在問題，這表明事實並非如此。

仍然，您應該進行檢查，找出原因並嘗試要解決這個問題。如果這只是表現不佳的高級工程師，則需要採取措施使該工程師達到標準，或者讓另一名能夠正確完成工作的工程師。

似乎是時候讓這整個團隊引起注意了。如果他們沒有開始遵守準則，請清除準則，它們將被終止。

您可以通過針對據報告所支持的錯誤/問題建立準則來實現這一目標。例如，優先級為1的bug必須在1小時內開始工作，然後每小時將進度報告給管理層（您），直到bug被修復或滿意的解決方案為止。令您滿意的關鍵是，當工作超過正常工作時間時，您必須在場或自己隨時待命，以支持他們和其他團隊完成工作。

當他們出差回家時，那麼他們就無法滿足您的要求來解決此問題並每小時進行檢查。現在可以測量了。這些準則也必須由其他團隊來滿足。

現在，一旦他們一次不滿足這些要求，便會繼續發出通知，正式書面通知，向您的經理和人力資源部抄送他們未達到要求的通知他們的義務。第二次，您再次報告，通知團隊第三次事件是終止的理由。第三次被解僱。

現在，我猜這名高級開發人員具有一些關鍵知識，他/她認為這些知識會使它們變得無價。沒有人那麼有價值，這發送了這個信息。他們不支持公司，公司將不再支持他們。

如果要終止合同，請期待一些影響。他們確實確實擁有需要付出一些努力才能跟上他人的知識。確保Jr.開發人員了解這些策略，即使他們對Sr.保ba，即使他們能夠開始承擔重擔，那麼當您終止麻煩製造者時，他們將能夠保持進展。