1. 前言
本人曾就職于多家公司，但留給我印象最深刻、開發(fā)管理最規(guī)范的公司是I公司。該公司總部位于美國(guó)硅谷，其開發(fā)的產(chǎn)品曾獲得PC Magazine的最高五星級(jí)的優(yōu)秀好評(píng)?，F(xiàn)我根據(jù)在此公司中所感受到的經(jīng)歷及自身的一些感想寫出來，希望能給大家和其它公司有所借鑒。
2. 項(xiàng)目計(jì)劃
在一個(gè)產(chǎn)品發(fā)布并使用之后，其中肯定有許多地方不如意和值得改進(jìn)的地方?？蛻粼谑褂玫倪^程中會(huì)發(fā)現(xiàn)一些問題，提出更高的需求，市場(chǎng)也在發(fā)生變化，我們的競(jìng)爭(zhēng)對(duì)手也在發(fā)展，新的技術(shù)不斷地產(chǎn)生，這些因素推動(dòng)著我們的產(chǎn)品不斷地向前發(fā)展，使它的版本不停地往上增長(zhǎng)。這些發(fā)展的需求不是一下子提出來的，在客戶使用的過程中發(fā)現(xiàn)某些不如意不方便的地方，他們會(huì)向我們的技術(shù)支持人員提意見，而技術(shù)支持人員會(huì)把這些需求以BUG的形式存入BUG數(shù)據(jù)庫(kù)中，其級(jí)別一般定義為下一個(gè)版本的Feature。有些上一個(gè)版本未解決的BUG也可能需要在本版本中來解決。因此當(dāng)我們來開發(fā)下一個(gè)版本時(shí)，其許多特性已經(jīng)存在于BUG數(shù)據(jù)庫(kù)中了。當(dāng)然新版本的特性不是只從BUG中獲得，管理層可能從市場(chǎng)的角度來提出新的特性以求領(lǐng)先競(jìng)爭(zhēng)對(duì)手，開發(fā)人員本身也可提出某些要求來納入新版本開發(fā)的計(jì)劃中，如要求對(duì)某部分代碼進(jìn)行重構(gòu)以使其結(jié)構(gòu)更清晰更容易維護(hù)，執(zhí)行效率更高。
每個(gè)人把同自己相關(guān)的功能模塊收集起來，同時(shí)預(yù)估時(shí)間，其中主要包括寫文檔的時(shí)間、開發(fā)時(shí)間和單元測(cè)試的時(shí)間，一般要求精確到工作日。這些信息發(fā)送給組長(zhǎng)，組長(zhǎng)再把本小組人員的任務(wù)和預(yù)估時(shí)間發(fā)送給管理層，由管理層對(duì)此任務(wù)及進(jìn)度進(jìn)行評(píng)估審核，管理層會(huì)根據(jù)產(chǎn)品發(fā)布時(shí)間及客戶需求、市場(chǎng)因素等方面作出選擇，可能某些功能由于時(shí)間緊急會(huì)被推遲到下一個(gè)版本中去。若預(yù)估出來的時(shí)間同預(yù)計(jì)的產(chǎn)品發(fā)布時(shí)間有較大沖突，而且此功能是本版本中必須得做的，則開發(fā)小組會(huì)被要求重新預(yù)估時(shí)間，加快開發(fā)速度來達(dá)到這個(gè)要求。
雖然這個(gè)開發(fā)進(jìn)度時(shí)間是一個(gè)大概的估計(jì)時(shí)間，但我們要盡力按照這個(gè)開發(fā)進(jìn)度來執(zhí)行。每個(gè)星期五下午我們有一個(gè)Status Meeting（一般那時(shí)工作效率較低，適合開會(huì)），在此會(huì)議上我們會(huì)根據(jù)這個(gè)進(jìn)度來review我們的工作，每個(gè)人手上的工作是否按照這個(gè)進(jìn)度在走，是否有人延后了，是否block住別人的工作了。在此會(huì)議上每個(gè)人都要報(bào)告自己的進(jìn)度，同時(shí)還要報(bào)告上個(gè)星期做了什么，正在做什么，以及下個(gè)星期打算做什么。通過這個(gè)會(huì)議，會(huì)讓你覺得有人在監(jiān)督你，無形之中迫使你不斷地督促自己不要使任務(wù)延后，如果有延后的跡象也會(huì)盡早發(fā)現(xiàn)而趕上。若某些經(jīng)過努力不能趕上，那也沒有辦法，只能修改原先的進(jìn)度表，因?yàn)槟鞘俏覀兊墓烙?jì)與現(xiàn)實(shí)發(fā)生了偏差，我們必須使我們的進(jìn)度表符合實(shí)際情況，這可以避免許多項(xiàng)目發(fā)生最后的20%的工作量會(huì)占據(jù)80%甚至一直拖后的情況。修改進(jìn)度表的情況我們?cè)?jīng)發(fā)生過，有一次在按照原先的進(jìn)度執(zhí)行到將要完成的狀態(tài)時(shí)突然接到通知由于市場(chǎng)及客戶的原因要求加入另一項(xiàng)重大的功能，這個(gè)功能對(duì)我們程序的結(jié)構(gòu)有非常大的影響，因此我們就要重新制定一個(gè)進(jìn)度來滿足需求。在這種情況下，產(chǎn)品原先的開發(fā)進(jìn)度被打亂，發(fā)布時(shí)間也因此推遲。當(dāng)然這種情況應(yīng)當(dāng)盡力避免，尤其在項(xiàng)目后期產(chǎn)生新的需求，若不得已也應(yīng)重新規(guī)劃進(jìn)度，而不是仍舊依照原先的進(jìn)度去執(zhí)行，因?yàn)槔系倪M(jìn)度已不能反映現(xiàn)實(shí)的情況。
3. 開發(fā)文檔
在項(xiàng)目進(jìn)度安排中我們已經(jīng)把寫文檔的時(shí)間也規(guī)劃進(jìn)去了，這里雖然是寫文檔，其實(shí)是設(shè)計(jì)程序，整理一下思路與架構(gòu)，磨刀不誤砍柴工，這樣在實(shí)際寫代碼時(shí)會(huì)流暢很多，節(jié)省時(shí)間，因此可以說真正有思想性的東西都在寫文檔這段時(shí)間內(nèi)完成了。當(dāng)然我們這里的文檔格式不象ISO那樣規(guī)定了條條框框，我們的文檔格式相對(duì)自由，基本上能隨意發(fā)揮，但對(duì)于幾個(gè)主要點(diǎn)一般來說是需要說明的。要求寫的文檔能讓他人比較容易地看明白，能把問題講清楚，能反映你的設(shè)計(jì)思想。文檔的數(shù)量也不多，開發(fā)文檔有兩類，一類是function Spec，另一類是Design Document。
function Spec中需要寫明的是本模塊完成的任務(wù)，解決什么問題，有什么作用，為什么要這些功能，此外我們還會(huì)添加進(jìn)適用范圍，有什么不足，注意點(diǎn)是什么，還有哪些地方在以后可以進(jìn)行改進(jìn)。在這個(gè)function Spec中不涉及到任何非常詳細(xì)的算法。此文檔不光給開發(fā)人員看，還讓QA及其他成員以及后來的新人能根據(jù)此文檔來了解此模塊的大致功能，同時(shí)也會(huì)給文檔編寫者看，他們會(huì)根據(jù)這些function Spec整理出一份用戶手冊(cè)，告訴用戶此版本中新增了哪些功能，各功能模塊有什么作用，如何使用等信息。因此在我們的開發(fā)過程中function Spec是很重要的文檔，此文檔完成后會(huì)抽出一段時(shí)間同相關(guān)人員及QA一起review這個(gè)文檔，讓QA了解設(shè)計(jì)者的意圖，同時(shí)熟悉新的功能模塊，為接下來的測(cè)試作準(zhǔn)備。如果其中有誤解或不明之處，大家會(huì)提出來探討并由開發(fā)者修正。
Design Document中主要描述實(shí)現(xiàn)此模塊所涉及到的主要算法、數(shù)據(jù)結(jié)構(gòu)、類的層次結(jié)構(gòu)及調(diào)用關(guān)系。這個(gè)文檔的閱讀者主要是開發(fā)人員，包括任何想了解詳細(xì)實(shí)現(xiàn)代碼的人，幫助人們理解代碼。在某些功能模塊比較簡(jiǎn)單的程序中，此文檔所描述的信息會(huì)比較少。此文檔不象function Spec要在開始寫代碼前就編寫完成，它可以隨著代碼編寫的進(jìn)行而增加，但基本上遵循文檔先行原則，也就是要增加新的代碼或修改代碼前若有涉及到文檔部分的應(yīng)先修改文檔，然后再修改代碼。
4. 編寫代碼
由于我們用JAVA語言進(jìn)行開發(fā)，因此我們借助了Jbuilder IDE工具。關(guān)于代碼風(fēng)格，我們基本上套用Jbuilder中自動(dòng)的代碼格式編排，但其中需要改變的是縮進(jìn)是4個(gè)字符，類與類之間間隔2行，方法與方法之間間隔2行，import類時(shí)用完整的類名。寫代碼時(shí)要對(duì)類及函數(shù)提供詳細(xì)的注釋及說明，基本做到看它們的說明就能知道這個(gè)類或函數(shù)的功能以及主要算法的實(shí)現(xiàn)原理。在開發(fā)過程中對(duì)主要的模塊要編寫UnitTest，同時(shí)要UnitTest先行，也就是遵循XP規(guī)則中的測(cè)試驅(qū)動(dòng)原則，當(dāng)所有的單元測(cè)試代碼通過時(shí)，此功能也就基本上完成了。
5. 代碼管理
我們采用VSS+SourceOffsite進(jìn)行版本控制，其中存放了此產(chǎn)品的所有源代碼、庫(kù)文件、文檔及release時(shí)的安裝程序，各個(gè)部分存放在不同的目錄中。每天早上要求開發(fā)人員從VSS中g(shù)et latest version的源代碼，然后進(jìn)行編譯并開始一天的工作。在下班之前理論上要求員工check in所有當(dāng)天修改的代碼，在check in之前要保證編譯是能通過的。若有誰check in的代碼導(dǎo)致daily build失敗則會(huì)被要求某些懲罰措施或警告，象微軟公司要負(fù)責(zé)照看當(dāng)日的每日構(gòu)建。有時(shí)我們編寫的代碼涉及到多個(gè)文件，而且此改動(dòng)是比較復(fù)雜需要花費(fèi)多天的工作量，如果現(xiàn)在check in進(jìn)去可能會(huì)導(dǎo)致BVT（Build Verify Test）測(cè)試通不過，因?yàn)橛行┐a沒有完全完成，而之前的代碼能使BVT測(cè)試通過，而且這些代碼基本上不會(huì)涉及到他人，在這種情況下可以不check in進(jìn)去，直到全部代碼完成能提交BVT測(cè)試時(shí)再一起check in進(jìn)去。
每天我們都會(huì)做daily build，一般是在凌晨4點(diǎn)進(jìn)行，那時(shí)有個(gè)程序會(huì)自動(dòng)從VSS中拉下最新的代碼并進(jìn)行編譯。因?yàn)槲覀兺绹?guó)進(jìn)行同步開發(fā)，因此如果想要把修改的代碼進(jìn)入到這個(gè)build中去那就需要在凌晨4點(diǎn)之前把相應(yīng)的代碼check in進(jìn)去。若有人check in進(jìn)去的代碼導(dǎo)致編譯通不過則會(huì)在本步驟中被發(fā)現(xiàn)。當(dāng)編譯完成之后自動(dòng)產(chǎn)生安裝包，測(cè)試部門將會(huì)對(duì)這些代碼進(jìn)行BVT測(cè)試，同時(shí)對(duì)VSS中開發(fā)庫(kù)打上label，如果發(fā)現(xiàn)了什么BUG就能根據(jù)這個(gè)label知道是哪個(gè)時(shí)候開始出現(xiàn)這個(gè)BUG的。BVT是指Build Verify Test，是對(duì)組件中基本功能的測(cè)試。這個(gè)測(cè)試每天都會(huì)進(jìn)行，看新加入的代碼或修改是否會(huì)影響系統(tǒng)的基本功能，便于及早發(fā)現(xiàn)錯(cuò)誤。
6. 測(cè)試
在開發(fā)人員完成了function Spec后，測(cè)試部門開始了測(cè)試規(guī)劃，確定需要測(cè)試哪些方面，如何測(cè)試及進(jìn)度安排。測(cè)試人員需要寫許多測(cè)試代碼，有些測(cè)試代碼需要集成進(jìn)BVT測(cè)試，有些可能需要進(jìn)行單獨(dú)的測(cè)試，目的都是為了使產(chǎn)品符合要求，使開發(fā)人員容易找出問題所在并改正。產(chǎn)品功能是否符合了要求，是否能被發(fā)布是由測(cè)試人員決定的，因此測(cè)試人員也比較辛苦，責(zé)任重大。通過了每天的BVT測(cè)試，還有一些性能測(cè)試、兼容性測(cè)試、災(zāi)難測(cè)試等需要在產(chǎn)品發(fā)布前進(jìn)行。在完成這些測(cè)試之后由測(cè)試人員決定本產(chǎn)品是否能release出去了，如果沒有什么問題則會(huì)給某些關(guān)系較好的用戶進(jìn)行β測(cè)試，之后再最終release出去。
7. BUG管理
由于我們每天進(jìn)行著測(cè)試，因此經(jīng)常有BUG被測(cè)試部門發(fā)現(xiàn)，一旦發(fā)現(xiàn)了新的BUG，就會(huì)被添加進(jìn)BUG Tracking System中。目前較流行的BUG Tracking System有TestTrack、ClearQuest、Bugzilla等。BUG tracking system是開發(fā)人員和QA之間的紐帶，開發(fā)人員和QA通過BUG tracking system聯(lián)系著。每個(gè)BUG有其類型和級(jí)別，預(yù)定的類型有Crash-Data Loss, Crash-No Data Loss, Incorrect functionality, Cosmetic, Feature request等, 級(jí)別有P1、P2一直到P6，它們分別代表了重要性及緊急程度，P1的BUG需要很快fix，P5之前的BUG在本版本release之前必須fix掉，若真的不能或不重要?jiǎng)t由QA確定并降低優(yōu)先級(jí)進(jìn)入到下一個(gè)版本中去fix。QA發(fā)現(xiàn)一個(gè)BUG后在BUG Track中增加一個(gè)BUG，同時(shí)填入相關(guān)信息并assign給相應(yīng)的開發(fā)人員，開發(fā)人員收到BUG分析并fix后assign給QA去verify，其中要填上分析的結(jié)果以及如何解決的詳細(xì)說明。若QA對(duì)此BUG verify通過則close BUG，否則verify failed并重新assign給開發(fā)人員并等待其fix。每星期在Status Meeting上會(huì)進(jìn)行BUG狀況報(bào)告，主要由QA組長(zhǎng)報(bào)告BUG的狀況，主要是新增BUG數(shù)，fix掉多少，還有多少處于open狀態(tài)，有多少處于等待verify的狀態(tài)，據(jù)此可以了解開發(fā)及測(cè)試情況。有時(shí)在Status Meeting上我們也會(huì)進(jìn)行BUG Review，BUG Review有時(shí)是單獨(dú)一個(gè)小組內(nèi)進(jìn)行，其主要作用是重新明確每個(gè)人頭上的BUG以及了解每個(gè)BUG的狀況，如開發(fā)人員對(duì)此BUG將作何處理等，以此來了解開發(fā)中是否有碰到比較棘手的問題，增加了產(chǎn)品發(fā)布風(fēng)險(xiǎn)。在QA增加BUG和開發(fā)人員fix BUG的游戲中，BUG的數(shù)量曲線圖會(huì)象股市曲線一樣上下波動(dòng)，但總體趨勢(shì)一般是前期BUG放量攀升，后期震蕩下挫，若到了后期新open的BUG數(shù)量一直上升則說明風(fēng)險(xiǎn)在增大，有可能無法控制，也就是說fix了一個(gè)BUG導(dǎo)致了多個(gè)新的BUG產(chǎn)生。在量化開發(fā)進(jìn)度中也可以用代碼數(shù)量的曲線圖來粗略的呈現(xiàn)。在有大量新功能增加時(shí)可能代碼量的增加會(huì)較快，當(dāng)在fix bug階段，代碼的修改較多，因此代碼數(shù)量的增幅會(huì)降低，依據(jù)代碼量可以看出開發(fā)的狀況處于何種階段。
需要指出的是我們對(duì)BUG的定義比較廣泛，一些新功能也可以作為BUG被提出，只不過這些BUG級(jí)別比較低，讓它們進(jìn)入到下一個(gè)版本中去實(shí)現(xiàn)。因此BUG的創(chuàng)建者也可以是技術(shù)支持人員、市場(chǎng)人員甚至開發(fā)人員本身。關(guān)于開發(fā)人員本身，因?yàn)樗赡軙?huì)找出一些BUG，有些是其他開發(fā)者的，有些可能是此開發(fā)者本身的，把這個(gè)BUG添加進(jìn)BUG庫(kù)中可以幫助開發(fā)人員在以后產(chǎn)生新問題時(shí)或類似的BUG時(shí)有一個(gè)借鑒和思路，但此BUG的verify必須要讓測(cè)試本模塊的測(cè)試人員來verify。
8. Code Freeze
當(dāng)P5之前的BUG都被修復(fù)了，這時(shí)離產(chǎn)品發(fā)布日期也就不遠(yuǎn)了，一般是2個(gè)星期后就能release產(chǎn)品，這時(shí)要對(duì)VSS中的代碼進(jìn)行freeze，以保證代碼庫(kù)的穩(wěn)定性。Code freeze階段一般會(huì)把各開發(fā)人員的check in和check out的權(quán)限關(guān)閉，若在這時(shí)仍有BUG報(bào)告上來并經(jīng)討論確定是重大的且必須在本版本中fix的，則需要經(jīng)管理層同意并特殊地授予權(quán)限，在修改完成后修改者要把修改了哪些文件，影響了哪些文檔等信息上報(bào)給各部門如QA、build人員、文檔編寫者等。在code freeze階段，測(cè)試部門在緊張地進(jìn)行著各種測(cè)試，得出各種數(shù)據(jù)，并決定本版本是否可以release了。
9. Tech Talk
計(jì)算機(jī)知識(shí)更新速度非?？?，經(jīng)常有一些新的術(shù)語、新的名詞、新的思想、新的技術(shù)所產(chǎn)生，如過離開此行業(yè)幾個(gè)月后重新回來就會(huì)對(duì)這些新的事物不解，而我們平時(shí)為了自己的項(xiàng)目埋頭苦干可能忘了周圍的世界發(fā)生了什么。Tech Talk就提供了一個(gè)讓我們了解新知識(shí)和最新發(fā)展趨勢(shì)的機(jī)會(huì)，讓大家把知識(shí)共享，共同提高。Tech Talk一般會(huì)在項(xiàng)目不是太忙碌的時(shí)候進(jìn)行，主持人會(huì)提前一個(gè)星期指定某個(gè)人去準(zhǔn)備一下Tech Talk，一般此人可能對(duì)某方面比較感興趣，然后他會(huì)花一些時(shí)間去了解這方面的情況，寫成一個(gè)文檔如PowerPoint并上傳到局域網(wǎng)內(nèi)，同時(shí)通知大家可以先去瀏覽。Tech Talk的內(nèi)容非常廣泛，不一定同我們的項(xiàng)目緊密相關(guān)，任何新的思想、新的知識(shí)（當(dāng)然一般是限在計(jì)算機(jī)領(lǐng)域內(nèi)）都可作為Tech Talk的內(nèi)容，而在主講人講完之后還有一段時(shí)間被大家提問，共同對(duì)這個(gè)話題進(jìn)行討論，答疑解惑。當(dāng)然Tech Talk也可同我們的項(xiàng)目相關(guān)，如研究一下競(jìng)爭(zhēng)對(duì)手的產(chǎn)品技術(shù)，本公司產(chǎn)品的架構(gòu)等。研究本公司的產(chǎn)品架構(gòu)可以使大家對(duì)本公司的產(chǎn)品有一個(gè)全局的概念，從整體上來看自己的產(chǎn)品，順便整理一下產(chǎn)品的架構(gòu)使之更加清晰有條理。平時(shí)大家都只注重于自己負(fù)責(zé)的其中的一小塊，在Tech Talk中可以跳出自己的小框框來了解全局，同時(shí)這也是新員工了解公司核心技術(shù)整體框架的好機(jī)會(huì)。每個(gè)模塊的負(fù)責(zé)人需要闡述此模塊的方方面面，讓大家來了解并回答問題。
10. Code Review
當(dāng)進(jìn)行工作移交時(shí)我們會(huì)進(jìn)行Code Review，在碰到棘手的BUG時(shí)也會(huì)進(jìn)行Code Review，Code Review是大家了解其詳細(xì)實(shí)現(xiàn)的一個(gè)好機(jī)會(huì)。在Code Review之后會(huì)對(duì)此代碼產(chǎn)生親切感而不是陌生懼怕感，相信很多人在讀他人代碼時(shí)會(huì)有非常痛苦的經(jīng)歷，Code Review是減少此痛苦感的好藥方。在進(jìn)行Code Review前，主講人會(huì)提前發(fā)出一個(gè)通知告訴相關(guān)人員要review哪些代碼，這樣參與者可以抽出時(shí)間提前了解相關(guān)代碼，對(duì)不懂的地方做個(gè)筆記以便在Code Review進(jìn)行中提出疑問。在我們碰到比較棘手的BUG沒有什么思路或大惑不解時(shí)，這時(shí)找?guī)讉€(gè)相關(guān)人員或?qū)Υ舜a也熟悉的人進(jìn)行一次Code Review，這時(shí)形式比較隨意，大家可以臨時(shí)提出問題，讓主講人解答，在這個(gè)過程中可能聽的人并不會(huì)非常快地了解其中的詳細(xì)過程，但是講的人在這個(gè)過程中重新理了一下思路，對(duì)所寫的代碼被迫重新審視了一遍，在其中可能就會(huì)發(fā)現(xiàn)出解決問題的辦法。在Code Review時(shí)有時(shí)代碼非常多，但可以一個(gè)功能模塊一個(gè)功能模塊地從總體到局部，由淺入深層層遞進(jìn)的方式進(jìn)行。一次Code Review的時(shí)間不要太長(zhǎng)，但可以分多次進(jìn)行。Code Review中大家會(huì)提出問題和建議，集思廣益，多個(gè)人共同出主意，有些可能一個(gè)人沒有想到的問題會(huì)被大家發(fā)現(xiàn)，互相學(xué)習(xí)，共同進(jìn)步。
11. 溝通與交流
大部分員工的大部分時(shí)間是在公司里度過的，因此公司的生活成了大家主要組成部分。員工之間關(guān)系的融洽，交流的暢通顯得非常重要，同時(shí)大家也不想自己的生活這樣枯燥乏味，一直同機(jī)器打交道。溝通無處不在，交流隨時(shí)發(fā)生，有許多關(guān)系是在工作之外建立起來的。軟件公司內(nèi)是很容易產(chǎn)生各種矛盾的，因?yàn)檫@是由你的工作性質(zhì)所決定的，比如QA或用戶會(huì)對(duì)你的實(shí)現(xiàn)不滿意，提出各種要求時(shí)，我相信你有時(shí)會(huì)有所抱怨的，無形之中就產(chǎn)生了對(duì)立，發(fā)展到后來會(huì)有抵觸心理。我相信大部分人都會(huì)有此感受，這不是你的錯(cuò)，這主要是由我們的工作性質(zhì)決定的。如果你的工作是把財(cái)富帶給對(duì)方，則對(duì)方會(huì)非常歡迎你的到來，把你奉為財(cái)神爺來對(duì)待，同你的關(guān)系會(huì)非常融洽友好。因此我們需要在工作之外來消除這種對(duì)立矛盾的關(guān)系，建立一種融洽的工作氛圍。我們?cè)谄綍r(shí)吃飯的時(shí)候飯桌上大家互相聊天溝通。我們建立了happy郵件列表，其中會(huì)發(fā)一些幽默笑話之類的郵件，給我們緊張的工作增加點(diǎn)輕松的氛圍。在下班后大家可以組織一下活動(dòng)，增加了公司的凝聚力。一個(gè)產(chǎn)品發(fā)布后組織一下旅游，讓繃緊的神經(jīng)松弛一下，更好地迎接下一個(gè)挑戰(zhàn)。
12. 后記
不同公司有不同的做法，我只是把我認(rèn)為比較好的流程與管理方式呈現(xiàn)出來，讓大家有個(gè)借鑒，當(dāng)然它也不是十全十美的，也不是放之四海而皆準(zhǔn)的，如果你覺得某些地方對(duì)你有所幫助或值得推廣，這是本文最想達(dá)到的效果。非常感謝I公司給了我這么美好的經(jīng)歷，也非常感謝I公司的同事們?cè)o我的巨大幫助，在此衷心地祝福I公司越來越壯大，逐步走向成功！也衷心地祝福我的同事們幸?？鞓?！
本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)
點(diǎn)擊舉報(bào)。
