很顯然，是沒有的。但是，有些身居高位且急於求成的人，會對自己的屬下去提這樣的要求。
他們要求的內容是：要總結出一種管理辦法，非常詳細地，就像工藝規程指導工作作業一樣，使新來的員工能像螺絲釘一樣在管理辦法的效用下被擰在項目上。我想很多程序員或者軟件開發的管理人員都被要求或者本身也期望有這么一種方式，那么我就根據自己讀的書，並結合已有的實踐去談一談。
如果我們把符合需求或真實提高了業務效率的軟件系統定義為成功的系統，那么大多數成功的系統都具有如下的特點：是演進式的，具有良好的設計，具有良好的測試。
除了少數投資巨大、幾乎可以稱為不計成本的項目，大多數系統的建設和開發應是演進式的，通過不斷的迭代反饋，持續校正系統和需求的偏離。這種方式的規律雖然一直，但是每一次迭代的范圍、周期，都是要結合具體項目情況去判斷的，判斷失誤將產生極為惡劣的后果。如果應該在早起迭代進系統的功能沒能及時添加，后期迭代的很多功能都將受到不同程度的影響。
作為IBM著名的項目經理，布魯克斯博士發表《人月神話》三十年后，又寫了《設計原本》。他同樣將成功系統的重要因素推在了一個非常微妙的事情上，那就是設計。架構師、設計師在業務需求和計算機技術中得尋找到一個平衡的點，但很明顯，一般想要找到“銀彈”的人或公司大概是難以擁有足夠這樣水平的架構師、設計師的。
作為響當當的程序員，鮑勃大叔比布魯克斯博士遇到過更多和外包項目性質更類似的工作。由於是一線的程序員，鮑勃大叔解決問題的方式是從自己工作出發的。現在很多程序員自己都認為IT行業加班多是普遍現象，幾乎已變為“正常”。鮑勃大叔認為，工作中大多數時間都被浪費在閱讀代碼和測試上了，理解才能修改，測試才能保證修改正確，這兩件事一定並不可少，但是如果我們將測試本身變為自動，而且自動化的測試代碼可以間接去解釋、幫助我們理解業務代碼，那么我們將有更多的時間和資源去迭代軟件。
以上是三種軟件開發領域自己提供的解決方案。而在其他領域，則有這樣一些方法：
今井正明所撰寫的《現場管理》中，有一些用於運維系統、改善系統的方式，簡稱PCDA和SCDA，這兩種的含義就不詳解了，主要意思就是混亂的階段首先要確定標准和制度。制定標准和制度后通過對現場的觀察和權力決策的下放，不斷改善已有做法。
但是，制度和標准，是很多單位根本就無力去編制的。而這些單位做事的人少，發言的人卻多，需求調研時有很多人的發言觀點都是矛盾的，但有一些特殊場景下，這些觀點可能也不大好反駁。這個問題布魯克斯博士提到過，可惜沒有提解決辦法，只說在這種狀態下項目幾乎是不可能成功，大概言下之意是奉勸大家如果遇上了，盡量離開這樣的項目。而你如果想讓自己成為可以隨時離開某個項目加入其它項目的人，那么就得好好在水平上下功夫了。