構(gòu)建高效軟件開發(fā)流程和團(tuán)隊(duì)
?
?
1.
????
前言
...
2
2.
????
項(xiàng)目計(jì)劃
???
2
3.
????
開發(fā)文檔
???
3
4.
????
編寫代碼
???
4
5.
????
代碼管理
???
4
6.
????
測試
...
4
7.
????
BUG管理
???
5
8.
????
Code Freeze
..
6
9.
????
Tech Talk
??
6
10.
??????
Code Review
...
6
11.
??????
溝通與交流
???
7
12.
??????
后記
...
7
本人曾就職于多家公司，但留給我印象最深刻、開發(fā)管理最規(guī)范的公司是
I
公司。該公司總部位于美國硅谷，其開發(fā)的產(chǎn)品
曾獲得
PC Magazine
的
最高五星級(jí)的優(yōu)秀好評(píng)?，F(xiàn)我根據(jù)在此公司中所感受到的經(jīng)歷及自身的一些感想寫出來，希望能給大家和其它公司有所借鑒。
?
在一個(gè)產(chǎn)品發(fā)布并使用之后，其中肯定有許多地方不如意和值得改進(jìn)的地方。客戶在使用的過程中會(huì)發(fā)現(xiàn)一些問題，提出更高的需求，市場也在發(fā)生變化，我們的競爭對(duì)手也在發(fā)展，新的技術(shù)不斷地產(chǎn)生，這些因素推動(dòng)著我們的產(chǎn)品不斷地向前發(fā)展，使它的版本不停地往上增長。這些發(fā)展的需求不是一下子提出來的，在客戶使用的過程中發(fā)現(xiàn)某些不如意不方便的地方，他們會(huì)向我們的技術(shù)支持人員提意見，而技術(shù)支持人員會(huì)把這些需求以
BUG
的形式存入
BUG
數(shù)據(jù)庫中，其級(jí)別一般定義為下一個(gè)版本的
Feature
。有些上一個(gè)版本未解決的
BUG
也可能需要在本版本中來解決。因此當(dāng)我們來開發(fā)下一個(gè)版本時(shí)，其許多特性已經(jīng)存在于
BUG
數(shù)據(jù)庫中了。當(dāng)然新版本的特性不是只從
BUG
中獲得，管理層可能從市場的角度來提出新的特性以求領(lǐng)先競爭對(duì)手，開發(fā)人員本身也可提出某些要求來納入新版本開發(fā)的計(jì)劃中，如要求對(duì)某部分代碼進(jìn)行重構(gòu)以使其結(jié)構(gòu)更清晰更容易維護(hù)，執(zhí)行效率更高。
每個(gè)人把同自己相關(guān)的功能模塊收集起來，同時(shí)預(yù)估時(shí)間，其中主要包括寫文檔的時(shí)間、開發(fā)時(shí)間和單元測試的時(shí)間，一般要求精確到工作日。這些信息發(fā)送給組長，組長再把本小組人員的任務(wù)和預(yù)估時(shí)間發(fā)送給管理層，由管理層對(duì)此任務(wù)及進(jìn)度進(jìn)行評(píng)估審核，管理層會(huì)根據(jù)產(chǎn)品發(fā)布時(shí)間及客戶需求、市場因素等方面作出選擇，可能某些功能由于時(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)度表的情況我們曾經(jīng)發(fā)生過，有一次在按照原先的進(jìn)度執(zhí)行到將要完成的狀態(tài)時(shí)突然接到通知由于市場及客戶的原因要求加入另一項(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í)的情況。
在項(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
整理出一份用戶手冊，告訴用戶此版本中新增了哪些功能，各功能模塊有什么作用，如何使用等信息。因此在我們的開發(fā)過程中
Function Spec
是很重要的文檔，此文檔完成后會(huì)抽出一段時(shí)間同相關(guān)人員及
QA
一起
review
這個(gè)文檔，讓
QA
了解設(shè)計(jì)者的意圖，同時(shí)熟悉新的功能模塊，為接下來的測試作準(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)代碼的人，幫助人們理解代碼。在某些功能模塊比較簡單的程序中，此文檔所描述的信息會(huì)比較少。此文檔不象
Function Spec
要在開始寫代碼前就編寫完成，它可以隨著代碼編寫的進(jìn)行而增加，但基本上遵循文檔先行原則，也就是要增加新的代碼或修改代碼前若有涉及到文檔部分的應(yīng)先修改文檔，然后再修改代碼。
由于我們用
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ī)則中的測試驅(qū)動(dòng)原則，當(dāng)所有的單元測試代碼通過時(shí)，此功能也就基本上完成了。
?
我們采用
VSS+SourceOffsite
進(jìn)行版本控制，其中存放了此產(chǎn)品的所有源代碼、庫文件、文檔及
release
時(shí)的安裝程序，各個(gè)部分存放在不同的目錄中。每天早上要求開發(fā)人員從
VSS
中
get 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
）測試通不過，因?yàn)橛行┐a沒有完全完成，而之前的代碼能使
BVT
測試通過，而且這些代碼基本上不會(huì)涉及到他人，在這種情況下可以不
check in
進(jìn)去，直到全部代碼完成能提交
BVT
測試時(shí)再一起
check in
進(jìn)去。
每天我們都會(huì)做
daily build
，一般是在凌晨
4
點(diǎn)進(jìn)行，那時(shí)有個(gè)程序會(huì)自動(dòng)從
VSS
中拉下最新的代碼并進(jìn)行編譯。因?yàn)槲覀兺绹M(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)生安裝包，測試部門將會(huì)對(duì)這些代碼進(jìn)行
BVT
測試，同時(shí)對(duì)
VSS
中開發(fā)庫打上
label
，如果發(fā)現(xiàn)了什么
BUG
就能根據(jù)這個(gè)
label
知道是哪個(gè)時(shí)候開始出現(xiàn)這個(gè)
BUG
的。
BVT
是指
Build Verify Test
，是對(duì)組件中基本功能的測試。這個(gè)測試每天都會(huì)進(jìn)行，看新加入的代碼或修改是否會(huì)影響系統(tǒng)的基本功能，便于及早發(fā)現(xiàn)錯(cuò)誤。
在開發(fā)人員完成了
Function Spec
后，測試部門開始了測試規(guī)劃，確定需要測試哪些方面，如何測試及進(jìn)度安排。測試人員需要寫許多測試代碼，有些測試代碼需要集成進(jìn)
BVT
測試，有些可能需要進(jìn)行單獨(dú)的測試，目的都是為了使產(chǎn)品符合要求，使開發(fā)人員容易找出問題所在并改正。產(chǎn)品功能是否符合了要求，是否能被發(fā)布是由測試人員決定的，因此測試人員也比較辛苦，責(zé)任重大。通過了每天的
BVT
測試，還有一些性能測試、兼容性測試、災(zāi)難測試等需要在產(chǎn)品發(fā)布前進(jìn)行。在完成這些測試之后由測試人員決定本產(chǎn)品是否能
release
出去了，如果沒有什么問題則會(huì)給某些關(guān)系較好的用戶進(jìn)行
β
測試，之后再最終
release
出去。
由于我們每天進(jìn)行著測試，因此經(jīng)常有
BUG
被測試部門發(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
組長報(bào)告
BUG
的狀況，主要是新增
BUG
數(shù)，
fix
掉多少，還有多少處于
open
狀態(tài)，有多少處于等待
verify
的狀態(tài)，據(jù)此可以了解開發(fā)及測試情況。有時(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)，但總體趨勢一般是前期
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ù)支持人員、市場人員甚至開發(fā)人員本身。關(guān)于開發(fā)人員本身，因?yàn)樗赡軙?huì)找出一些
BUG
，有些是其他開發(fā)者的，有些可能是此開發(fā)者本身的，把這個(gè)
BUG
添加進(jìn)
BUG
庫中可以幫助開發(fā)人員在以后產(chǎn)生新問題時(shí)或類似的
BUG
時(shí)有一個(gè)借鑒和思路，但此
BUG
的
verify
必須要讓測試本模塊的測試人員來
verify
。
當(dāng)
P5
之前的
BUG
都被修復(fù)了，這時(shí)離產(chǎn)品發(fā)布日期也就不遠(yuǎn)了，一般是
2
個(gè)星期后就能
release
產(chǎn)品，這時(shí)要對(duì)
VSS
中的代碼進(jìn)行
freeze
，以保證代碼庫的穩(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
階段，測試部門在緊張地進(jìn)行著各種測試，得出各種數(shù)據(jù)，并決定本版本是否可以
release
了。
?
計(jì)算機(jī)知識(shí)更新速度非?？?，經(jīng)常有一些新的術(shù)語、新的名詞、新的思想、新的技術(shù)所產(chǎn)生，如過離開此行業(yè)幾個(gè)月后重新回來就會(huì)對(duì)這些新的事物不解，而我們平時(shí)為了自己的項(xiàng)目埋頭苦干可能忘了周圍的世界發(fā)生了什么。
Tech Talk
就提供了一個(gè)讓我們了解新知識(shí)和最新發(fā)展趨勢的機(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)，如研究一下競爭對(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é)人需要闡述此模塊的方方面面，讓大家來了解并回答問題。
?
當(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í)間不要太長，但可以分多次進(jìn)行。
Code Review
中大家會(huì)提出問題和建議，集思廣益，多個(gè)人共同出主意，有些可能一個(gè)人沒有想到的問題會(huì)被大家發(fā)現(xiàn)，互相學(xué)習(xí)，共同進(jìn)步。
大部分員工的大部分時(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)系，建立一種融洽的工作氛圍。我們在平時(shí)吃飯的時(shí)候飯桌上大家互相聊天溝通。我們建立了
happy
郵件列表，其中會(huì)發(fā)一些幽默笑話之類的郵件，給我們緊張的工作增加點(diǎn)輕松的氛圍。在下班后大家可以組織一下活動(dòng)，增加了公司的凝聚力。一個(gè)產(chǎn)品發(fā)布后組織一下旅游，讓繃緊的神經(jīng)松弛一下，更好地迎接下一個(gè)挑戰(zhàn)。
不同公司有不同的做法，我只是把我認(rèn)為比較好的流程與管理方式呈現(xiàn)出來，讓大家有個(gè)借鑒，當(dāng)然它也不是十全十美的，也不是放之四海而皆準(zhǔn)的，如果你覺得某些地方對(duì)你有所幫助或值得推廣，這是本文最想達(dá)到的效果。非常感謝
I
公司給了我這么美好的經(jīng)歷，也非常感謝
I
公司的同事們曾給我的巨大幫助，在此衷心地祝福
I公司
越來越壯大，逐步走向成功！也衷心地祝福我的同事們幸福快樂！