第一篇：幾個軟件研發管理的問題

幾個軟件研發團隊管理的小問題

最近在與一位總經理交流的時候，他談到他們公司的軟件研發管理，說：“我們公司最大的問題是項目不能按時完成，總要一拖再拖。”他問我有什么辦法能改變這個境況。從這樣一個問題開始，在隨后的交談中，又引出他一連串在軟件研發管理中的遇到的問題，包括：

.現有代碼質量不高，新來的開發人員接手時寧愿重寫，也不愿意看別人留下的“爛”代碼，怎么辦？

.重構會造成回退，怎樣避免？

.有些開發人員水平相對不高，如何保證他們的代碼質量？

.軟件研發到底需不需要文檔？

.要求提交代碼前做Code Review，而開發人員不做，或敷衍了事，怎么辦？.當有開發人員在開發過程中遇到難題，工作無法繼續，因而拖延進度，怎么解決？.如何提高開發人員的主觀能動性？

其實，每個軟件研發團隊的管理者都面臨著或曾經面臨過這些問題，也都有著自己的管理“套路”來應對這些問題。我把我的“套路”再此絮叨絮叨。

1.項目不能按時完成，總要一拖再拖，怎么改變？

找解決辦法前，當然要先知道問題為什么會出現。這位總經理說：“總會不斷地有需求要改變和新需求提出來，使原來的開發計劃不得不延長。”原來如此。知道根源，當然解決辦法也就有了，那就是“敏捷”。敏捷開發因其迭代（Iterative）和增量（Incremental）的思想與實踐，正好適合“需求經常變化和增加”的項目和產品。在我講述了敏捷的一些概念，特別是Scrum的框架后，總經理也表示了對“敏捷”的認同。

其實仔細想想，這里面還有一個非常普遍的問題。對于產品的交付時間或項目的完成時間，往往由高級管理層根據市場情況決策和確定。在很多軟件企業中，這些決策者在決策時往往忽略了一個重要的參數，那就是團隊的生產率（Velocity）。生產率需要量化，而不是“拍腦門子”感覺出來的。敏捷開發中有關于如何估算生產率的方法。所以使用敏捷，在估算產品交付時間或項目完成時間時，是相對較準確的。Scrum創始人之一的Jeff Sutherland說，他在一個風險投資團隊做敏捷教練時，團隊中的資深合伙人會向所有的待投資企業問同一個問題：“你們是否清楚團隊的生產率？”而這些企業都很難做出明確的答復。軟件企業要想給產品定一個較實際的交付日期，就首先要弄清楚自己的軟件生產率。

2.現有代碼質量不高，新來的開發人員接手時寧愿重寫，也不愿意看別人留下的“爛”代碼，怎么辦？

這可能是很多軟件開發工程師都有過的體驗，在接手別人的代碼時，看不懂、無法加新功能，讀代碼讀的頭疼。這說明什么？排除接手人個人水平的因素，這說明舊代碼可讀

性、可擴展性比較差。怎么辦？這時，也許重構是一種兩全其美的辦法。接手人重構代碼，既能改善舊代碼的可讀性和可擴展性，又不至于因重寫代碼帶來的時間上的風險。從接手人心理的角度看，重構還有一個好的副作用，就是代碼重構之后，接手人覺得那些原來的“爛”代碼被修改成為自己引以自豪的新成就。《Scrum敏捷軟件開發》的作者Mike Cohn寫到過：“我的女兒們畫了一幅特別令人贊嘆的杰作后，她們會將它從學校帶回家，并想把它展示在一個明顯的位置，也就是冰箱上面。有一天，在工作中，我用C++代碼實現了某個特別有用的策略模式的程序。因為我認定冰箱門適合展示我們引以為豪的任何東西，所以我就將它放上去了。如果我們一直對自己工作的質量特別自豪，可以驕傲地將它和孩子的藝術品一樣展示在冰箱上，那不是很好嗎？”所以這個積極的促進作用，將使得接手人感覺修改的代碼是自己的了，而且期望能夠找到更多的可以重構的東西。

3.重構會造成回退，怎樣避免？

重構確實很容易造成回退（Regression）。這時，重構會起到與其初衷相反的作用。所以我們應該盡可能多地增加單元測試。有些老產品，舊代碼，可能沒有或者沒有那么多的單元測試。但我們至少要在重構前，增加對要重構部分代碼的單元測試。基于重構目的的單元測試，應該遵循以下的原則（見《重構》第4章：構筑測試體系）：

-編寫未臻完善的測試并實際運行，好過對完美測試的無盡等待。測試應該是一種風險驅動行為，所以不要去測試那些僅僅讀寫一個值域的訪問函數，應為它們太簡單了，不大可能出錯。

-考慮可能出錯的邊界條件，把測試火力集中在哪兒。扮演“程序公敵”，縱容你心智中比較促狹的那一部分，積極思考如何破壞代碼。

-當事情被公認應該會出錯時，別忘了檢查是否有異常如期被拋出。

-不要因為“測試無法捕捉所有Bug”，就不撰寫測試代碼，因為測試的確可以捕捉到大多數Bug。

-“花合理時間抓出大多數Bug”要好過“窮盡一生抓出所有Bug”。因為當測試數量達到一定程度之后，測試效益就會呈現遞減態勢，而非持續遞增。

說到《重構》這本書，其實在每個重構方法中都有“作法（Mechanics）”一段，在重構的實踐中按照上面所述的步驟進行是比較穩妥的，同時也能避免很多不經意間制造的回退出現。

4.要求提交代碼前做Code Review，而開發人員不做，或敷衍了事，怎么辦？ 如果每個開發人員都是積極主動的，Code Review的作用能落到實處。但如果不是呢？團隊管理者需要一些手段促使其有效地進行Code Review。首先，我們采用的Code Review有2種形式，一是Over-the-shoulder，也就是2個人座在一起，一個人講，另一個人審查。二是用工具Code Collaborator來進行。無論哪種形式，在提交代碼時，必須注明關于審查的信息，比如：審查者（Reviewer）的名字或審查號（Review ID，Code Collaborator自動生成），每天由一名專職人員來檢查Checklist中的每一條，看是否有人漏寫這些信息，如果發現會提醒提交的人補上。另外，某段提交的代碼出問題，提交者和審查者都要一起來解決出現的問題，以最大限度避免審查過程敷衍了事。

博主Inovy在某個評論說的很形象：“木（沒）有賞罰的制度，就是帶到廁所的報紙，看完就可以用來擦屁股了。”沒有獎懲制度作保證，當然上面的要求沒有什么效力。所以，當有人經常不審查就提交，或審查時不負責任，它的績效評定就會因此低一點，而績效的評分是跟每年工資漲落掛鉤的。說白了，可能某個人會因為多次被查出沒有做Code Review就提交代碼，而到年底加薪時比別人少漲500塊錢。

5.軟件研發到底需不需要文檔？

軟件研發需要文檔的起原可能有2種，一是比較原始的，需要文檔是為了當開發人員離職后，企業需要接手的人能根據文檔了解他所接手的代碼或模塊的設計。二是較高層次的，企業遵從ISO9001質量管理體系或CMMI。

對于第一種，根源可能來自于兩個方面：

-原開發人員設計編碼水平不高，其代碼可讀性較差。

-設計思想和代碼只有一個人了解，此人一旦離職，無人知道其細節。

在編碼前寫一些簡單的設計文檔，有助于理清思路，尤其是輔以一些UML圖，在交流時也是有好處的。但同時，我們也應該提高開發人員的編碼水平增加其代碼的可讀性，比如增強其變量命名的可讀性、用一些被大家所了解的設計模式來替代按自己某些獨特思路編寫的代碼、增加和改進注釋等等，以減少不必要的文檔。另外推行代碼的集體所有權（Collective Ownership），避免某些代碼只被一個人了解，這樣可以減少以此為目的而編寫的文檔。

對于第二種，情況有些復雜。接觸過敏捷開發的人都知道《敏捷宣言》中的“可以工作的軟件勝于面面俱到的文檔”。接觸過CMMI開發或者ISO9001質量管理體系的人知道它們對文檔的要求是多么的高。它們看起來水火不相容。但是，它們的宗旨是一致的，即：構建高質量的產品。

對于敏捷，使用手寫用戶故事來記錄需求和優先級的方法，以及在白板上寫畫的非正式設計，是不能通過ISO9001的審核的，但當把它們復印、拍照、增加序號、保存后，可以通過審核。每次都是成功的Daily Build和Auto Test報告無法證明它們是否真正被執行并真正成功，所以不能通過ISO9001的審核。但添加一個斷言失敗（類似assert(false)的斷言）的測試后，則可以通過審核。

CMMI與敏捷也是互補的，前者告訴組織在總體條款上做什么，但是沒有說如何去做，后者是一套最佳實踐。SCRUM之類的敏捷方法也被引入過那些已通過CMMI5級評估的組織。很多企業忘記了最終目標是改進他們構建軟件及遞交產品的方式，相反，它們關注于填寫按照CMMI文檔描述的假想的缺陷，卻不關心這些變化是否能改進過程或產品。

所以敏捷開發在過程中只編寫夠用的文檔，和以“信息的溝通、符合性的證據以及知識共享”作為主要目標的質量體系文檔要求并不矛盾。在實踐中，我們可以按以下方法做，在實現SCRUM的同時，符合審核和評估的要求：

-制作格式良好的、被細化的、被保存的和能跟蹤的Backlog。復印和照片同樣有效。-將監管需要的文檔工作也放入Backlog。除了可以確保它們不被忘記，還能使監管要求的成本是可見的。

-使用檢查列表，以向審核員或評估員證明活動已執行。團隊對“完成”的定義(Definition of “Done”)可以很容易轉變為一份檢查列表。

-使用敏捷項目管理工具。它其實就是開發程序和記錄的電子呈現方式。

總而言之，軟件研發需要文檔（但文檔的形式可以是多種多樣的，用Word寫的文字式的文件是文檔，用Visio畫的UML圖也是文檔，保存在Quality Center中的測試用例也是文檔），同時我們只需寫夠用的文檔。

6.當有開發人員在開發過程中遇到難題，工作無法繼續，因而拖延進度，怎么解決？ 這也是個常遇到的問題。如果管理者對于某個工程師的具體問題進行指導，就會陷入過度微觀管理的境地。我們需要找到宏觀解決辦法。一，我們基于Scrum的“團隊有共同的目標”這一規則，利用前面提到的集體所有權，當出現這些問題時，用團隊中所有可以使用的力量來幫助其擺脫困境，而不是任其他人袖手旁觀。當然這里會牽扯到績效評定的問題，比如：提供幫助的人會覺得，他的幫助無助于自己績效評定的提高，為什么要提供幫助。這需要人力資源部門在使用Scrum開發的團隊的績效評估中，盡量消除那些傾向個人的因素，還要包含團隊協作的因素，廣泛聽取個方面的意見，更頻繁地評估績效等等。

二，即使動用所有可以使用的力量，如果某個難題真的無法逾越，為了減少不能按時交付的風險，產品負責人應當站出來，并有所作為。要么重新評估Backlog的優先級，使無法繼續的Backlog遲一點交付，先做一些相對較低優先級的Backlog，以保證整體交付時間不至于延長；要么減少部分功能，給出更多的時間去攻克難題。總之逾越技術上難關會使團隊的生產率下降，產品負責人必須作出取舍。

7.有些開發人員水平相對不高，如何保證他們的代碼質量？

當然首先讓較有經驗的人Review其要提交的代碼，這幾乎是所有管理者會做的事。除此之外，管理者有責任幫助這些人（也包括水平較高的人）提高水平，他們可以看一些書，上網看資料，讀別人的代碼等等，途經還是很多的。但問題是你如何去衡量其是否真正有所收獲。我們的經驗是，在每年大約3月份為每個工程師制定整個年度的目標，每個人的目標包括產品上的，技術上的，個人能力上的等4到5項。半年后和一年后，要做兩次Performance Review，目標是否實現，也會跟績效評定掛鉤。我們在制定目標時，遵循SMART原則，即：

Specific（明確的）：目標應該按照明確的結果和成效表述。

Measurable（可衡量的）：目標的完成情況應該可以衡量和驗證。

Aligned（結盟的）：目標應該與公司的商業策略保持一致。

Realistic（現實的）：目標雖然應具挑戰性，但更應該能在給定的條件和環境下實現。Time-Bound（有時限的）：目標應該包括一個實現的具體時間。

比如：某個人制定了“初步掌握本地化技術”的目標，他要確定實現時間，要描述學習的途經和步驟，要通過將技術施加到公司現有的產品中，為公司產品的本地化/國際化/全球化作一些探索，并制作Presentation給團隊演示他的成果，并準備回答其他人提出的問題。團隊還為了配合其實現目標，組織Tech Talk的活動，供大家分享每個人的學習成果。通過這些手段，提高開發人員的自學興趣，并逐步提高開發人員的技術水平。

8.如何提高開發人員的主觀能動性？

提高開發人員的主觀能動性，少不了激勵機制。不能讓開發人員感到，5年以后的他和現在比不會有什么進步。你要讓他感到他所從事的是一個職業（Career），而不只是一份工作（Job）。否則，他們是不會主動投入到工作中的。我們的經驗是提供一套職業發展的框架。框架制定了2類發展道路，管理類（Managerial Path）和技術類（Technical Path），6個職業級別（1-3級是Entry/Associate，Intermediate，Senior。4級管理類是Manager/Senior Manager，技術類是Principal/Senior Principal。5級管理類是Director/Senior Director，技術類是Fellow/Architect。6級是Executive Management）。每個級別都有13個方面的具體要求，包括：范圍（Scope）、跨職能（Cross Functional）、層次（Level）、知識（Knowledge）、指導（Guidance）、問題解決（Problem Solving）、遞交成果（Delivering Result）、責任感（Responsbility）、導師（Mentoring）、交流（Communication）、自學（Self-Learning），運作監督（Operational Oversight），客戶響應（Customer Responsiveness）。每年有2次提高級別的機會，開發人員一旦具備了升級的條件，他的Supervisor將會提出申請，一旦批準，他的頭銜隨之提高，薪水也會有相對較大提高。從而使每個開發人員覺得“有奔頭”，自然他們的主觀能動性也就提高了。

上面的“套路”涉及了軟件研發團隊管理中的研發過程、技術實踐、文檔管理、激勵機制等一些方面。但只是九牛一毛，研發團隊管理涵蓋的內容還有很多很多，還需要管理者在不斷探索和實踐的道路上學習和掌握。

第二篇：機房管理、軟件研發

機房管理、軟件研發工作總結

一年來，本人認真做好本職的工作，不斷學習新的技術，擴展了自己的知識面，并通過項目實踐，提高了自身的動手操作能力。下面我將從思想、工作和學習三大方面總結一下2011年本人所取得的成績、經驗，以及存在的不足。

在思想上，本人始終堅持以一個黨員的標準來嚴格要求自己，加強理論學習，不斷提高自身的理論水平和政治覺悟，始終以“愛崗敬業，為人師表，嚴謹篤學，與時俱進”來督促自己的言行，以“以德為行，以學為上”的教育思想作為自己的行為準則，努力把“全心全意為人民服務”的宗旨體現在平常的工作中。

在工作上，本人時刻牢記自己是一名光榮的共產黨員，能夠愛崗敬業，不怕辛苦，以高度熱情和責任感做好本職工作。作為一名實驗室管理員，本人認真做好“微機七室”的機房管理工作，同時協助其他實驗室管理員進行機房電腦的維護和升級工作。而作為我校數字化校園建設的一員，本人不斷提高自己的理論水平，以實踐項目來鞏固自己的理論知識，努力為完善我校數字化建設而努力。在此期間，我參與了以下實踐項目：

① 完善和維護“教工信息平臺”，增加“學校實驗室項目進度管理系統”

② 完善和維護“網絡教學平臺”、“助學系統”和“公文系統”；

③ 開發和維護“研究生處網站”、“學院關工委網站”；

④ 參與開發“學校資源平臺”、“省中職教學資源平臺”、“省中職信息化大賽網站”； ⑤ 為配合學校參與省質量工程檢查，開發了“省質量工程項目申報展示平臺”網站，并創建“會計學”、“旅游管理與服務教育”、“工商管理”等校級特色名牌專業網站； ⑥ 管理“中職云平臺”上的虛擬主機，并在平臺上部署各類應用及為各中職院校開設虛擬機。同時為了方便管理各虛擬機信息，開發了“中職信息云在線體驗平臺”；

⑦ 維護學校網站服務器，解決學校和各院系網站、各信息系統運行不正常的各類問題。在學習上，由于本人的主要工作是軟件研發，因此在這一年中，我不斷學習各種編程技術，如Struts，Spring，Hibernate等框架，并對之前搭建的開發框架進行了重構，以提高開發的效率。同時，不斷學習其它新興的技術，并將該技術運用到工作中，以提高工作效率。以上是我這一年的工作總結，雖然在思想、工作和學習上都取得了很大的進步，但也存在一些不足，如政治理論水平的欠缺；工作經驗不足；網絡水平不高，這些不足都是在新的一年中需要彌補回來的，我也相信，經過我的努力，一定會有所突破，有所成功的。

2012年即將來臨，我為自己制定了以下的工作計劃：

① 繼續完善和維護現有的系統；

② 學習Android開發技術，嘗試開發網絡教學平臺和中職教學資源平臺客戶端軟件； ③ 學習AIX小型機和Oracle數據庫，嘗試將網絡教學平臺移植到Oracle數據庫，并

部署到小型機上；

④ 在鞏固現有的技術上學習一些新的技術，提高自身的專業水平。

第三篇：軟件研發崗位職責

根據網上的一些資料以及公司實際的情況而制定：

1、負責部門人員的引進及本部門人員的績效考評管理工作；

2、制訂部門內部的改造計劃，組織審定部門各項技術標準，編制、完善軟件開發流程，并組織部門人員進行研究討論；

3、抓好本部門項目組總結分析報告工作，定期進行項目分析、總結經驗、找出存在的問題，提出改進工作的意見和建議，為公司領導決策提供專題分析報告或綜合分析資料。

4、組織本部門人員的培訓、技術指導以及技術難點突破工作；

5、配合市場部門開展工作，向市場部門提供必要的技術支持；

6、在需求調研中，配合項目組長進行需求調研工作，并對需求調研報告進行審核評定；

7、同項目組長組織設計開發工作，控制開發進度；

8、負責組織軟件項目的測試工作，對軟件產品的質量負責；

9、對項目組文檔進行質量、數量和時間控制，并組織召開評審會；

10、對部門下面人員的日報、周報檢查，了解每一個開發人員的工作情況以及工作狀態；

11、規范部門內部管理，提高員工整體技術水平，把握技術發展方向，使得技術發展方向與主流技術合拍；

12、熱情接待客戶，并妥善處理客戶的抱怨、投訴以及突發性事件；

13、視下屬為兄弟姐妹，在工作生活中給予最多的關愛。

第四篇：研發經費管理辦法(軟件)

研發資金管理辦法

1.目的

為切實加強公司研發投入的財務管理，確保項目資金的合理使用，充分發揮財務核算、監督管理的職能作用，確保項目研發專項資金的安全、有效，提高資金效率和研發效率，根據公司財務制度，結合公司項目管理的特點，制定本制度。2.實施范圍及執行

2.1 本制度規定了公司技術研發部(中心)開展項目研發的資金使用管理要求。2.2 本制度規定了專項研發經費的使用范圍。2.3 本制度自總經理簽發批準之日起正式施行。3.原則

3.1 專款專用、逐級審批、逐項使用的原則； 3.2 勤儉辦事、精細籌算、力求節約的原則；

3.3 保證經費申請、使用暢通，為產品研發提供可靠的資金保障為原則。4.相關部門職責

建立和健全科研經費管理責任制和監管機制，明確相關職能部門和項目負責人的職責和權限，加強對研發經費的監督和檢查。

4.1 公司主管副總經理：負責研發項目經費預算的審核、劃撥和有關支出的審批，負責科研經費使用的監督和檢查工作。

4.2 研發中心：項目負責人負責編制研發項目經費的預算和決算，嚴格按照項目任務書或合同書規定的開支范圍和標準使用項目經費，自覺控制經費的各項支出，對研發經費使用的真實性、有效性承擔責任。

4.3 財務部：負責研發經費的財務管理和會計核算，指導項目負責人編制項目經費預算，審核項目經費決算，監督和指導項目負責人按照項目經費管理規定使用研發經費。5.項目研發經費范籌：

項目研發經費是指項目研究與開發過程中所發生的直接費用和間接費用。一般包括人員費、儀器設備費、能源材料費、試驗外協費、差旅費、會議費和其他相關費用。

5.1 設備費：是指在項目研發過程中購置或試制專用儀器設備，對現有儀器設備進行升級改造，以及租賃外單位儀器設備而發生的費用。

5.2 材料費：是指在項目研發過程中消耗的各種原材料、輔助材料以及低值易耗品的采購及運輸、裝卸、整理等費用。

5.3 檢測試驗費：是指在項目研發過程中支付給外單位的檢測、試驗、測試等費用。5.4 燃料動力費：是指在項目研發過程中相關大型儀器設備、專用科學裝置等運行發生的可以單獨計量的水、電、氣、燃料消耗費用等。

5.5 差旅費：是指在項目研發過程中開展科學實驗（試驗）、科學考察、業務調研、學術交流等所發生的外埠差旅費、市內交通費用等。差旅費的開支標準應當按照國家有關規定執行。

5.6 會議費：是指在項目研發過程中為組織開展學術研討、咨詢、檢查、項目驗收或鑒定等活動而發生的會議費用。舉辦會議前，須向主管副總提出會議申請并編制會議用款計劃，財務部按主管副總審批的限額報銷會議費。

5.7 合作、協作研究與交流費：是指在項目研究開發過程中與國際、國內科研機構合作、協作研究支付給合作、協作單位的費用，項目研究人員出國及外國專家來公司工作的費用。

5.8 出版/文獻/信息傳播/知識產權事務費：是指在項目研究開發過程中，需要支付的出版費、資料費、專用軟件購買費、文獻檢索費、專業通信網絡費、專利申請及其他知識產權事務等費用。

5.9 勞務費：是指在項目研究開發過程中支付給項目組成員、沒有工資性收入的相關人員和項目組臨時聘用人員等的勞務性費用。明確規定在編人員不得列支人員費的項目，按規定執行。

5.10 專家咨詢費：是指在項目研究開發過程中支付給臨時聘請的咨詢專家的費用。5.11 業務招待費：是指在項目研究開發過程中發生的一定標準的業務招待費用。5.12 車輛使用費：是指項目研究過程中使用自備車輛所發生的費用。汽油費、過路費、停車費可在科研經費中支出。

5.13 其它費用：指與項目研究直接有關的其他支出。6.研發項目經費的審批管理

6.1 研發項目經費一經公司批準，必須專款專用，任何部門不得任意截留、挪用或擠占他用。

6.2 產品研發經費經公司批準后，由公司財務部門按單項預算撥給項目承擔部門，由項目組按項目研發計劃支配使用，不得挪作它用。財務部門單列帳戶，進行核算監督。

6.3 計劃內的支出，由項目負責人審簽，可根據研發工作進展和器材供應情況調整用款計劃。但調整過的用款，須經所在部門領導審批。如改變用途，須報請總經理審批。

6.4 項目承擔部門申請現金開支，按公司財務制度審批程序，并按項目計劃和實施階段分期申請，由各項目負責人和技術副總逐級審批。

6.5 使用研發經費的項目承擔部門，須在研發中心領導和財務、技術主管領導的監督管理下，循序投入，合理開支。財務部門按設置的獨立賬戶進行核算，年終按規定報送決算，并于項目結束后按批復的決算核銷經費。7.研發階段工作報告

獲得項目撥款后，須定期向公司提交研發工作報告。

7.1 研發進度正常的，按《經費開支計劃》中相應的用款額撥款；

7.2 研發進度不正常或經費使用不當時，財務部將減少或暫停撥款，以至撤消經費投入；

7.3 不按時提交研發工作進展情況報告的，財務有權暫不撥款。8.研發項目經費的結算管理

8.1 研發項目經費的使用、管理，以方便科研，有利于發揮研發人員的積極性為前提。研發項目因故中止或撤銷，項目負責人必須向研發中心領導和主管技術副總提出《研發項目中止報告》，并及時清理帳目，將余款和已購器材處理收入，悉數交回公司財務部。經公司財務部審查后核銷。

8.2 研發項目計劃實施結束后，項目承擔部門應配合財務抓緊清理收支帳目，在一個月內編制完成《研發項目經費決算表》，連同其它總結材料，一式兩份報公司財務部，經審查簽署意見后，批復所在部門核銷。已撥經費結余，退回財務后用。

8.3 研發中心對項目經費的使用情況，應接受公司財務部的定期審計或專項審計。編報《研發項目經費決算表》，應經財務部簽署審計意見。

8.4 項目負責人應按項目計劃書規定的時間及時結題，原則上應在研發項目結束或

通過驗收后六個月內辦理結帳手續。對無正當理由逾期不辦理結帳手續的，財務部有權暫時凍結項目經費的使用，待結帳后才能繼續使用。9.監督與違紀處理

8.1.研發中心應加強經費使用的管理和監督。總經辦應進行抽查，項目負責人和所在部門應積極配合，如實反映情況。

8.2.研發項目組成員應嚴格遵守財務制度和本辦法規定，如有弄虛作假、截留挪用或擠占經費等違紀行為，財務部有權抵制和越級反映，并視情節輕重，采取通報批評、撤銷資格、賠償損失、罰款等處理，嚴重者追究法律責任。

總經理批準： 發布實施日期：

第五篇：轉正申請(軟件研發)

尊敬的領導：

我于2010 年5月18日成為公司的試用員工，到今天3個月試用期已滿，根據公司的規章制度，現申請轉為公司正式員工。

初來公司，曾經很擔心不知該怎么與人共處，該如何做好工作；但是公司寬松融洽的工作氛圍、團結向上的企業文化，讓我很快融入到了工作當中。

在此之前從未接觸到有關高速公路的軟件開發，還擔心會拖延項目時間，給大家增加麻煩。經過這一段時間，發現在組長及同事的帶領之下，能快速跟上公司的節奏。

本部門的工作中，我一直嚴格要求自己，認真及時做好組長布置的每一項任務，同時主動為組長分憂；專業和非專業上不懂的問題虛心向同事學習請教，不斷提高充實自己，希望能盡早獨當一面，為公司做出更大的貢獻。當然，剛入公司，難免出現一些小差小錯需領導指正；但前事之鑒，后事之師，這些經歷也讓我不斷成熟，在處理各種問題時考慮得更全面，杜絕類似失誤的發生。在此，我要特地感謝部門的領導和同事對我的入職指引和幫助，感謝他們對我工作中出現的失誤的提醒和指正。

經過這三個月，我現在已經能夠獨立處理項目中出現的問題，整理項目內容的詳細設計文檔，進行項目BUG的修改，與數據中心的業務人員討論業務，采集需求變化中產生的新的業務。當然我還有很多不足，處理問題的經驗方面有待提高，團隊協作能力也需要進一步增強，需要不斷繼續學習以提高自己業務能力。

這半年來我學到了很多，感悟了很多；看到公司的迅速發展，我深深地感到驕傲和自豪，也更加迫切的希望以一名正式員工的身份進入開發團隊，實現自己的奮斗目標，體現自己的人生價值，和公司一起成長。在此我提出轉正申請，懇請領導給我繼續鍛煉自己、實現理想的機會。我會用謙虛的態度和飽滿的熱情做好我的本職工作，為公司創造價值，同公司一起展望美好的未來！

2010年8月25日申請人：xxx