研發的問題及解決方法

㈠ 程序員獨立研發的時候，遇到問題了你們都怎麼解決啊

1.技術問題：網路，bing，SCDN，請教前輩
先網路，網路是個好老師。
網路解決不了的再bing搜索一下，我遇到很多次都是在bing上找到的。
當搜索引擎搞不定的時候，這時候需要論壇了，去CSDN找找相關的技術貼，總會有點思路。
最後就是找公司的同事，這個有些時候需要花一些代價，畢竟大家都很忙。
2.邏輯問題：有些時候會遇到很惡心的邏輯
當想不明白或者想不通的時候，我會試著一步一步把邏輯寫在紙上，這樣就會很清晰，如果在某一步被卡住了，那麼問題的關鍵也找到了。當然有些時候或許一開始就走入了一個誤區，從而導致了一個錯誤的思路，這個時候我一般會睡上一會，或者做些完全和開發不相關的事，目的是忘記剛剛所有的東西，然後從新審視問題，換個角度去考慮。
（個人經驗，純手打！）

㈡ 2.演算法設計或項目開發中,你碰到哪些問題或困難,如何解決的

開發過程中遇到具體的技術問題，解決方案如下：自己查閱官網，看官方文檔，還有就是自己平時的積累（包括看書、資料、博客等等）。
遇到問題不要害怕，也不要煩躁，靜下心來，想想問題出現的原因以及該怎麼去解決，每解決一個問題都是對自己能力的提升。而且每解決一個難以搞定的問題，我相信大部分人都是很高興的。
平時多看技術資料、博客、書，看重對自己知識的積累，才能有實質性的能力提升。掌握解決問題的方式，謙虛的向別人請教，日復一日，相信你一定可以解決掉所有的困難。

㈢ 常見的研發管理

其實這題問的是產品的研發管理，我僅從IT研運一體化的角度去談，那麼該題目可等同於項目管理制和產品管理制的區別與痛點，按照如今IT的發展路徑，未來企業的IT業務，應該是通過項目制轉型到產品制，來實現真正的端到端和業技融合：

一、項目制到產品制的起由

想要知道項目制到產品制的轉變起因，我們需要先了解需求分析方法轉變的三個階段：

第一階段：

來自於20世紀90年代之前的信息自動化時代。在當時，企業只要有單機系統，可以把所有手工工單操作自動化，極大地提升研發效能，當時供小於求，強調用最快的速度做出最多的功能。

第二階段：

1990—2010年的互聯網時代。敏捷方法和精益方法在IT領域開始得到應用，更多的企業開始強調怎樣才能在高效交付的同時適應需求的變化，如何讓IT方案解決業務問題。

第三階段：

2010年後的數字經濟時代。在2013年前，譬如證券企業，其所有系統都是外部企業采購的，產品企業的產品經理都是從證券公司出來的，他們了解客戶想要什麼，甚至在賣產品的時候會出現供不應求的情況。但到2010年後，產品企業再給企業做交易系統等證券系統時，當時的產品經理和客戶經理已經跟不上時代的變化了，同時就算是從證券公司找一個人過來，也是懂之前的系統，時代變化太快了。所以最懂業務知識的一定是企業業務自身，今時今日再給企業做開發時，就一定要考慮如何調動客戶資源來做精益需求管理，通過與客戶共創精益需求來助力企業快速發展。

嘉為藍鯨DevOps將作為企業IT轉型的內驅力，從作業規范、工具體繫到運營服務進行多維度落地，持續助力企業的數字化轉型。

㈣ TRIZ創新研發理論體系解決問題有哪些流程如何分析

TRIZ作為一套方法體系，為企業提供了統一的解決問題的步驟和思路，就是將特殊的問題轉化為TRIZ的標准問題模型，然後運用相應的工具去求解，得解決方案模型，在此基礎上形成問題的具體方案。對於問題模型的構建，同樣的問題可以描述成不同的問題模型，一個復雜的問題，可以嘗試各種問題模型和工具。

1、問題分析
對於一個工程技術問題的解決，分析問題往往是個很關鍵的部分，通過層層分析，可以透過問題現象找到問題產生的根本原因，也就是解決問題的著手點。在運用TRIZ來解決問題時
①第一步，要對問題進行描述與定義，說明問題所在系統的組成、工作原理、問題發生的條件；
②第二步，建立功能模型，分析工程系統和超系統組件的功能、組件間的作用關系，分析哪些作用是有害的、不足的，找出造成系統問題的關系因素；
③第三步，根據前兩步分析出造成系統的關鍵因素，選擇進行組件價值分析、因果分析或資源分析。

組件價值分析，根據理想度公式計算出系統中各個組件的功能價值，對於理想度低的組件採用裁剪的方法進行系統有用功能的重新分配，同時將問題轉化為關鍵問題。因果分析，可以通過對問題的層層深入，找到問題產生的根本原因，尋找解決問題的著手點。資源指的是問題所處環境中存在的物體、信息、能源、或者材料的屬性。資源分析，幫助我們找出解決問題所缺乏的資源，可以轉化為待解決的問題點，資源分析還幫助我們找出系統內外各種可用的資源，在後續解決問題的過程中，往往可以起到至關重要的作用。

2、問題解決
TRIZ解決問題的模式是將初始問題轉化為標准問題模型，通過對標准問題運用TRIZ工具，得到解決方案模型，然後轉化為工程方案。TRIZ提供了四種問題模型以及相應工具和方案模型：
①技術矛盾，將待解決的具體問題轉化為用39個通用工程參數描述的技術矛盾，通過查找矛盾矩陣，找到針對問題的創新原理，即解決方案模型；
②物理矛盾，將待解決的問題准確描述和定義為物理矛盾，解決物理矛盾的核心思想是實現矛盾雙方的分離，運用分離原理作為工具來解決物理矛盾，得到解決方案模型；
③功能模型，通過分析待解決問題系統中組件及組件間的相互作用關系，建立功能模型，運用知識效應庫，產生解決方案模型；
④物場模型，將待解決的具體問題轉化為利用物質和場來描述的標准物場模型，分析物場模型中不足、過度、有害的作用，查找對應的76種標准解法，得到解決方案模型。

3、方案驗證
運用TRIZ對問題分析、求解，得到的通常是解決方案模型，工程技術人員還需要運用自身的專業知識、工程經驗等將解決方案模型轉化為實際的工程方案，並進行評估、驗證，形成最終的解決方案。

㈤ 如何提高軟體研發的效率

1、提高代碼的規范性。編碼規范 可以提高代碼的可讀性，並且在代碼修改的時候很容易。
2.對功能進行分類，並拆分。分析出幾種處理邏輯。編寫代碼時，部分代碼可以。可以提編碼速度。
3.對功能進行分類，並合並。提出共通類。
4.不同的package對應不同的功能。

簡單的說，每天寫幾百行代碼。堅持半年或者1年，就知道什麼方式是適合你的了。 不寫代碼，光想，十年也還是那個水平。每個人的邏輯思維是不一樣的，寫代碼的方式也是不一樣的。有時間問，還不如多寫寫。或者，自己模擬現實個場景（或公司管理制度之類的），然後實現。寫幾個，很自然的就知道自己該怎麼寫了。

㈥ 如何解決研發人員績效考核難的問題

解決研發人員績效考核難的問題：
一、研發人員績效考核需要建立的原則
1、研發人員的績效考核應以結果考核為主，能力考核和行為考核為輔
2、研發人員績效考核體系的建立必須具有時效性和實操性，易於執行
3、績效考核系統的設計盡量客觀
4、以對員工的績效改進和提升為目的，不以獎懲為考核目的
二、研發型公司績效管理體系的解決方案
1、基於研發人員勝任能力的考核
2、基於研發業績的績效管理體系設計
3、研發人員項目提成的積分制

具體如下：
一、研發人員績效考核需要建立的原則
1、研發人員的績效考核應以結果考核為主，能力考核和行為考核為輔
在研發人員的績效考核指標設計過程中，如果過於強調結果，往往會使研發類人員忽視公司的組織紀律和秩序；如果過於強調行為，則使研發類人員關注能力，會引導員工只注重做事的方式，而忽視研發的成果。在研發人員實際的考核中，應該以結果考核為主，以行為考核為輔。

2、研發人員績效考核體系的建立必須具有時效性和實操性，易於執行
在設計研發人員的績效考核體系時要簡單，表格不要太多，績效指標設置數量合理，具有實操性，易於執行，同時績效考核目標對於研發人員的工作要明確。

3、績效考核系統的設計盡量客觀
盡量避免主管評價（主要包括行為、態度等方面），規避因人為評價而挫傷優秀研發人員的工作積極性，助長研發人員因績效考核而形成的內部不公平競爭現象，應以事實說話，用數據考核。

4、以對員工的績效改進和提升為目的，不以獎懲為考核目的
在實施績效管理時應以促進員工的工作績效改進和效率提升為目的，而不是以獎懲為考核目的，使員工對績效考核產生抵觸情緒。

二、研發型公司績效管理體系的解決方案
1、基於研發人員勝任能力的考核
針對研發人員的關鍵職位序列，提取關鍵勝任素質，如研發知識、新產品設計能力、創新能力、項目管理能力、成就導向和思維能力等。根據提取的研發人員的關鍵能力素質，對能體現關鍵能力素質的關鍵行為設計評估問卷和方式，從行為的角度去評估研發人員的能力。

2、基於研發業績的績效管理體系設計
緊跟企業的發展戰略緊密結合，根據公司的研發策略，從企業的戰略進行層層分解，形成對企業戰略的支撐，確保公司以市場需求為導向研發新品，同時，平衡好長期指標與短期指標之間的關系。

3、研發人員項目提成的積分制
在研發人員績效評估的過程中，許多公司將每個研發項目變成虛擬的團隊和虛擬的工程，採取項目總額提成制，根據不同項目的不同發展模塊或階段、所需花費的工程師人員數量和工作天數進行總額核算，同時，企業鼓勵員工多做跟項目有關的工作，如發表的論文、技術支持、客戶拜訪等。

㈦ 新葯研發過程要注意哪些問題

一、市場因素

市場是決定產品生命的最終裁判。因此，對一個項目論證，必須首先對其進行市場論證。這就需要有專門的市場調研人員去做出切實的分析對比數據。還要考慮的就是新葯開發出來時，在3-5年的時間里市場變化預測等情況。

流行病學調研－－流行病學調研是對市場容量的調研，主要了解葯物主治疾病的發病情況。發病率高，市場容量就大，如糖尿病、心腦血管病、老年痴呆症、老年骨質疏鬆、病毒性疾病、惡性腫瘤、老年人尿失禁等都是發病率很高的疾病，這類葯物市場前景較好。當然，對某些小病種（如帶狀皰疹、胰腺炎等）具有特效的治療葯，也有較穩定的市場。

同類產品的調研－－科學技術發展到今天，可以說沒有哪種病的治療僅依靠一種葯物。市場的競爭要求新產品必須具有獨特之處。同類品種的銷售數據的增長趨勢，由此一般可以判斷該品種是處於發展中的那一個階段，如成長期，成熟期，還是衰退期。因此，要盡可能全面地進行同類產品的資料收集和比較。在對待開發品種和上市的同類產品比較時，應注意以下幾個方面的問題：一、療效是不是更好；二、毒副作用是不是更低；三、劑型和劑量是不是更便於使用；四、包裝是不是便於病人攜帶；五、市場價格是不是更便宜等等。

成長性市場：選擇可用於預防治療新疾病譜的葯物作為研究課題。作為臨床上緊缺甚至空白的葯物必然有很強競爭優勢。比如：用於治療因社會節奏加快引起的功能紊亂如抑鬱、內分泌失調、性功能障礙等葯物自上個世紀90年代開始成為研究的熱點，在臨床上陸續得到了廣泛使用，市場前景持續看好；又如：部分疾病如中風、更年期綜合症等攜病症群不斷趨於年輕化，開發預防和治療此類疾病的葯物應該有不錯的市場前景。

成熟性市場：選擇開發採用新工藝、新制劑、新給葯途徑、新質控方法、新作用機理的葯物作為研究課題。即使是市場上趨於飽和，競爭過度的產品，只要我們能將其進行技術優化處理，也能重新贏得競爭力。比如市場泛濫的」板藍根顆粒「經過指紋圖譜技術控制其質量標准後，提升了產品競爭力和市場增長點；「霍香正氣水」經劑型改革成「霍香正氣軟膠囊」後，大大增加了使用人群，提高了市場佔有率；「（右旋）氧氟沙星」 經改變手性結構成「左旋氧氟沙星」後，使臨床療效大為增強，毒副作用也明顯降低，成為當時市場銷售額增長最快的葯品之一

隱性市場：選擇開發社會效益好的葯物作為研究課題。此類項目能更多地得到政府組織的資助，並能更多地引起公眾關注，促進提升經濟效益。

1、開發防治毒品成癮、艾滋病、感染性疾病等社會性問題疾病的葯物

2、開發防治老幼婦孺等弱勢症群疾病的葯物；

3、開發能增加當地政府經濟收入的葯材資源，並進行深度研究和項目轉化；

4、開發珍稀名貴葯材的代用品。

二、技術因素

技術可行性決定了開發的難易程度和投入大小，這是規避風險的另一個重要方面，對項目的技術性論證應包括以下幾個方面：

（1）原輔料來源－－中葯應了解：①有無非標准化葯材，如果屬無標準的葯材，要先建立葯材標准，這樣工作量會很大。②有無使用毒性葯材，這牽涉到質量標准及臨床方面的難易程度。③有無國家保護品種如穿山甲等，這個問題直接影響到大生產的供應。④原料的來源是否充裕，這關繫到葯物可持續生產的問題，須引起足夠重視，尤其是使用野生植物葯涉及到資源再生問題。西葯應了解：原料供應是否能否國產化和工藝的難易程度，否則，輔料也會影響項目進度。

（2）葯學部分－－主要包括工藝、質量標准及穩定性研究。首先是工藝的可行性、實用性和先進性。工藝的改進必須堅持先進性、實用性與可行性相結合的原則。質量控制指標及方法的建立，也要反復論證。有些成分含量雖高，但穩定性差，波動太大，都不可作為指標成分；另外，檢測方法對檢測儀器的要求，直接牽涉到項目開發的投入和企業的承受能力。產品採用劑型的穩定性，也是很重要的，它既影響療效，也影響市場。這一點必須了解清楚，以免給後期工作帶來不必要的麻煩。具體分述如下：

1．合成路線

①分析合成路線：判斷合成路線是難，還是容易，或是不可能的；

②分析合成原料的來源：判斷起始原料或中間體是不容易獲得，還是易得，或是不可能得到；並對外聯系各原料或中間體；

③對合成設備的分析：對每步驟所需的設備進行分析，若無此設備，則查詢生產此設備的多個廠家，並聯系；

④對合成成本的分析：判斷合成該產品是否值得。

2． 制劑

① 分析制劑處方工藝：判斷處方工藝的難易，或是否可能制備；

② 分析制劑工藝的各原輔料：判斷原料及輔料是否可能獲得，並對外聯系各原輔料；

③ 對制劑設備的分析：對該制劑所用的設備進行分析，對照現有設備，不足的設備對外聯系，對特殊設備則作詳細考察後，再作決定；

④ 對制劑成本的分析：判斷生產該產品的費用。

3． 質量研究

① 對質量研究資料進行分析：判斷該分析方法的可行性；

② 對檢測儀器進行分析：判斷是否需購買新儀器；並對外進行聯系；

③ 對質量研究所需的化學試劑進行分析：判斷所需的化學試劑是否可以獲得，並與各試劑商聯系；

④ 對對照品進行分析：包括兩方面內容，即正式需要的對照品及6號資料所需的對照品；

（3）葯理毒理部分－－論證時應了解葯效研究有無規范的動物模型。新葯指導原則中無法包括提供所有疾病的研究模型。如果待開發項目沒有已知模型，重新建立模型難度又很大，這樣的項目最好緩上。毒理研究對動物有無特殊要求，例如治療艾滋病的葯物是很有前景的項目，但對實驗動物的要求較高，所以介入單位較小。

（4）臨床部分－－葯物的用法用量、療程和臨床周期與投入有直接關系，對這些問題應有清晰的了解。另外，研究單位提供的臨床研究方案是否可行，指導原則有無現成的方案等等，均要進行論證。

（5）對於仿製和該劑型的開發時，還應該注意查詢原標准及其相關的注冊申報情況。在設計新的劑型時，還需要考察原劑型的用法用量，以保證開發的劑型不但新穎，而且更安全有效。

三、療效和安全因素

葯品是一種特殊的商品，其特殊性在於：特定人群在特定時間及周期性內使用；具有治病救人的特點；使用不當可以引起身體損害的特點；必須在指定的地方購買，如葯店或醫院，不能隨意渠道流通等。

所以以上特點界定了葯品必須有效，沒有效果患者不會使用或者重復使用，即使開發出來，也不會有市場前景。

所以立項的新葯必須療效要確切，療效比目前臨床上主要產品療效還優越最好，在對比時包括中、西葯。

葯品安全性也是如此。在立項前，應對同類產品的不良反應進行跟蹤調研，有的不良反應對設計的劑型是有限制的。葯物制劑的設計研究對發揮葯物療效、減少不良反應關系極大，如氟喹諾酮類葯物中光毒性最強的沙星類葯物作成滴眼劑，據報道，美國全身用葯臨床試驗1585例中就有126例（7.9%）發生光毒性反應，有的口服一次即可發生，為此FDA已向醫生發出警告，並在說明書中註明本品限用於：① 院外獲得性肺炎感染；② 慢性支氣管炎急性發作，並註明在用葯期間及停葯後5 d內避免接觸日光、陽光及紫外光，且發生光毒性反應的患者在症狀未恢復及症狀消失後5 d之內仍不能接觸日光、陽光及紫外光，以免光毒性再次發作。鑒於以上原因，該品作成滴眼劑局部使用，安全性是無法保證的。

四、知識產權因素

項目論證時，應密切關注相關專利情況，應通過權威機構進行專利、行政保護及保密品種的檢索，以免侵權。特別是合成路線的專利、制劑工藝的專利等。除專利因素外，還應該關注葯品監測期和中葯保護品種等情況。可以有效規避開發品種的產權糾紛，亦可以在開發新產品時及時申請產權保護，以增加新產品的競爭力和獨家性的產權壁壘。

有一種可能是在立項時查不到相關的專利，項目進展了一定程度人家的專利出來了，這里不要輕易放棄，要看如何能避開，做全面分析。

五、成品成本因素

做為項目負責人必須全面考慮各種成本，拿出預算，並對開發成功後的葯物可能上市價格做一個相關成本核算。改劑型葯和仿製葯要尤其注意。

六、國家行政政策因素

一個葯品要順利完成注冊過程，必須符合國家相關法規，以及《葯品注冊管理辦法》為基礎制定的葯品注冊程序、葯品形式審查要點、葯品審評要點、葯品注冊受理要求以及日前國家局頒布的化葯的一些指導原則等等，建議：除此之外，應及時查看了解國家食品葯品監督管理局局主頁上，有無該葯品的一些新的注意信息；檢索有審評中心對該葯品、該注冊分類、該類葯品的審評要求以及審評發現的問題等。以准確把握國家的注冊評審政策動態，明確該品種應該注意那些問題，特別是產品歸屬及注冊類別的判斷一定要准確！應密切關注新葯研究和開發注冊申請動態，以免撞車。

七、 企業自身因素

企業實際情況，研發新品種不能脫離企業實際。企業的實際包括：

（1）生產范圍：有沒有通過GMP認證的該類葯品生產線，如果進行擴項，擴項帶來的風險都應在考慮問題之列；

（2）營銷網路：長期做抗生素的，該領域網路健全，渠道通暢，然後再改做心腦血管產品，怎麼搭建網路，擴展渠道？搞不好等到費時、費力、費錢搭建好網路，市場已經變化了；

（3）資本實力：不顧企業自身的資本情況，盲目投資新品，或者上大項目，最終導致資金鏈斷裂，現金流枯竭，企業難以為繼，只好被兼並、破產、關門。

八、其他因素

有的項目是別的單位提供的，這些單位多數是已做過文獻檢索，或走通了合成路線、制劑工藝及質量標准研究等前期基礎工作。作為合作夥伴，要特別了解該單位的合成力量及工作質量。工藝的研究是基礎的基礎，這里出問題會影響整個項目的進度，甚至導致項目的失敗。

二是有的項目是委託別的研究單位進行開發，新葯開發是一項復雜的系統工程，需要多學科協作。特別是葯理毒理及臨術研究，它必須由指定單位完成，應認真了解委託研究方的實力，是否具有研究資格，有沒有進行過新葯開發的成功案例，學科帶頭人在該領域的經驗狀況，整體研究實力如何，這些都是很重要的。在與委託方簽訂《新葯開發委託協議書》時，還應對合同的開發周期、分期付款以及違約處罰等都要做詳細的規定。

對於一個產品而言，要想成功，除了具備以上的特點還不行，也必須具有明顯的特色，這種特色可以是產品本身具有的，也可以是在市場的特定環境下產生的，如填補了市場空白，這不是產品自身的，而是相關市場所造就的，但是最好不要是人為的特點，如產品的外包裝等。產品的特色不在於多，而在於精，在於具有明顯區別於其他品種的明顯特徵，並且這種特色最好是實用性的。只有具有了區別於其他品種的特色，才能在市場上具有明顯的競爭力。沒有特色的項目最好不上，以免重復投資。

㈧ 關於軟體開發會遇到什麼問題及對策

軟體開發的過程中遇到的問題有很多，主要的會有以下問題：
1、調研的時候分析不到位帶來的問題
在軟體開發過程中，你需要做的很基礎的就是調研工作，在這個時候你得跟客戶進行直接的交流，掌握其需求並且針對性的分析，以確保客戶所表達的需求能夠充分的實現。但事實上，在於客戶的交流中，可能會因為對需求表達不夠明確，以及不斷的更換需求，還有就是分析人員自身在理解上有所偏差，這就會造成軟體開發進展變得比較有難度。
2、前期對功能的梳理不可能一蹴而就
在具體到軟體開發過程的時候，工程師都會簡單的梳理下可能需要達到的功能，但是並不能做到完美的梳理工作。而真的在執行的時候，可能經常會出現一些細微的變動，但是這些變動你又不得不重視，有可能根本就沒辦法控制。只要你的軟體沒有真正的開發出來，中途可能面臨的各種更改就會是持續不斷的。
3、測試階段不是工作完成而是繼續改進
可能在進入到測試階段的時候，你會以為軟體開發過程走到了終點，但其實這個時候的測試只是為了要找出更多的錯誤，而不是說你的程序就已經是完美的了。通常這個測試都是在公司內部來進行的，再把各種調試工作和模塊介面處理等工作做完之後，還要等待客戶的試用，知道真的萬無一失才可以提交報告。
以上就是對於軟體開發過程中可能會遇到哪些問題的簡單介紹，我們啟雲時代就是做軟體開發定製的，多年來積累下的經驗都分享啦希望能都幫助你。

㈨ 如何有效管理研發工作

研發部門如何提高工作效率的管理探討

第一、幾個基本的工作準則

一、 組織協同，避免缺乏組織，讓事情放任自流，一盤散沙，這是產品日常管理責任人、項目負責人的責任。

二、 難點問題即時支援攻克，避免員工工作粘滯影響進度。

三、 經驗不斷總結並標准化，避免低水平重復工作。

四、 立項嚴謹，避免折騰。

五、
我們需要一支有原則的隊伍，「我要什麼時間完成這個工作，你必須何時提供這個東西給我，有問題請你和你的上司商量，這個問題請盡快辦!」避免老好人、避免漫無目的、避免無原則，到頭來才說是別人沒按時給你。

六、 有困難立即找上級協助解決，面談、打電話、郵件都可以。

七、
「舉手制」——變更必須溝通協調，避免不溝通導致的失誤和損失，我們就像一架奔跑的四馬拉的戰車，任何一匹馬要改變方向或者速度，都會帶來其餘三匹馬的問題。

八、 我們必須是一個全能型的精靈，我們處在一個高度講求效率和快速反應的行業里，反應要快，要能堅持。

九、 產品風險大，必須嚴謹、再嚴謹，防呆、放錯、多方驗證必須是每個工程師的基本認識。

十、
「我們是一夥的」——我們還處在需要快速成長的階段，我們的產品積累不夠，產品線不完善，還不能完全覆蓋所有客戶的各種需求，應客戶需求進行開發的事情較多，一邊溝通了解、一邊設計、一邊生產，交貨時間緊迫。這類特徵要求我們必須是一個高度講求效率、高度講求溝通協調，高度講求工作質量、高度講求一次就盡力把事情做好的組織。

十一、 持續改善提高，不斷完善和總結。

第二、組織協同的重要性：

1、什麼是組織協同，就是需要安排什麼人做?何時完成?誰的工作會影響誰?出現問題該如何溝通和解決?每個人上下游關系是誰?有問題時該即時和誰溝通?有困難時該找誰?

2、誰來組織?怎樣組織?沒有有效組織就無法談協同。

誰來組織，是一切的關鍵。

為說清楚這個問題，我先講幾個基本邏輯：

⑴、兩點之間，直線最短;

⑵、溝通事情，問直接當事人，問最了解情況的人最快。

⑶、我們是一個更強調服務的企業，為什麼?我們只有用自己真誠的服務打動客戶，這就必然導致我們不能教條，必須靈活。

⑷、技術難度高，專家型特點突出。

正是這幾個基本邏輯，導致我們的信息分散，管理難度大，為什麼?該怎樣解決?——決策重心下移，加強溝通和檢查是唯一的解決辦法。

①、產品日常管理責任人是各類項目、任務分解落實的組織者

②、部門管理人員是各類項目任務落實到本部門具體人員時的保障完成者，是任務、項目僅僅分配到本部門的工作分解落實者。

③、所有幹部是自己管轄范圍內的所有工作按時完成的促進者、保障者、教練、檢查著、引導者、指導者。

④、研發管理辦：

A、所有交到研發管理辦的工作計劃的系統推進者，各產品日常管理責任人或項目負責人、部門負責人，把各自組織落實分解的跨部門協同工作推進計劃可以交由研發管理辦組織檢查推進，每天督促檢查的工作量大，僅僅依靠部門推進的難度大，這時就可以交由研發管理辦按各部門提供的工作計劃推進檢查，研發管理辦必須把檢查情況及時反饋給任務交待者。

B、各類任務、項目匯集成一張總計劃，把運行在研發部門的全部任務和項目匯制一張全局運行圖，《研發總計劃》可以看到各個任務、項目的計劃完成時間和進展情況，以及各類資源的運用情況。

C、研發人員任務分布分析，也就是資源運用情況分析，可以分析出每個人的任務情況，工作量是否過於集中在某幾個人，他們的工作量過大時該如何支援?

D、PM專員：研發還沒完全量產或者說沒正式轉產的產品系統跟進者，是研發和生產的銜接者，研發與生產混合階段的計劃執行推進檢查者，運作差異即時發現者，系統監控這一階段的運行情況並即時上報信息給決策人員。沒有正式量產或者說沒正式轉生產，代表著研發可能還存在著很多不確定性因素，需要加強研發和生產、采購等各方面的溝通和協調。PM專員必須強化這方面的溝通組織和總結經驗，因為這方面的不確定性和快速反應要求更多。研發投產申請流經PM，PM會根據投產申請編制推進計劃跟進，並將意外事情及時反饋給當事人，把重大事情匯報領導。

㈩ 如何解決軟體研發團隊管理的問題

高效軟體開發團隊的特徵

高效的軟體開發團隊是建立在合理的開發流程及團隊成員密切的合作的基礎之上的，成員共同的迎接挑戰、有效的計劃、協調和管理各自的工作以至完成明確的目標，高效的開發團隊具有如下特徵：

1、 具有明確且有挑戰性的共同目標

一個具有明確的而且有挑戰性目標的團隊比目標不明確或不具有很大的挑戰性目標的團隊效率高得多，通常技術人員往往會因為完成了某個明確的任務，而且這個任務的完成具有挑戰性的意義而感到自豪，反過來團隊成員為了獲取這種自豪的感覺而更加積極的工作從而帶來團隊開發的高效率，如作為系統設計人員很清楚的知道在什麼時候要做到什麼，什麼時候開始做，什麼時候必須完成，為了完成工作必須面臨哪些挑戰，怎麼解決這些困難等為設計出一個高質量的軟體項目提供了重要保證，而模模糊糊的去設計一個系統或模模糊糊的就去編寫代碼是非常危險的，而且會為此付出高昂代價，因此高效的軟體開發團隊具有挑戰性的共同目標。

2、 團隊具有很強的凝聚力

在一個高效的軟體開發團隊中，成員們凝聚為一個整體共同進行工作，他們是相互支持、互相交流、互相尊重的，而不是相互推卸責任、保守、相互指責的，在一些散亂的開發團隊中往往存在這樣的問題，一些程序員是比較保守的，明明知道另外的模塊中需要用到一段與自己已經編寫完成但有些難度的程序代碼，他也不願拿出來給其它程序員共享，不願與系統設計人員交流，這樣給項目的進度造成了些不可度量的因素。

3、 具有融洽的交流環境

在一個開發團隊中，每個人行使自己的職責，如需求分析人員制定需求規格說明、系統設計人員做系統概要設計和詳細設計、項目經理配置項目開發環境並且制定項目計劃等，但每個人的工作不可能做到完美的，如系統概要設計的文檔可能有個別地方詞不達意，做詳細設計的時候就可能會造成誤解，項目經理制定計劃時可能忽略了某種風險的存在而造成執行者過於緊張的壓力等等情況都需要大家通過交流、反饋的手段然後協商解決的，因此高效的軟體開發團隊是具有融洽的交流環境的，而不是那種簡單的命令執行式的。

4、 具有共同的工作規范和框架

高效軟體開發團隊具有規范性及共同框架的工作，對於項目管理具有規范的項目開發計劃，對於分析設計具有規范和統一框架的文檔及審評標准，對於代碼具有程序規范條例，對於測試有規范且可推理的測試計劃及測試報告等等。並且所有成員都明白自己的職責，知道必須完成什麼計劃?由誰來完成?什麼時候開始?什麼時候結束?按什麼順序?等，總之一個高效的開發團隊無論是工作內容還是工作流程都具有不同程度的規范性和標准風格的框架。

5、 採用合理的開發過程

軟體的開發不同於一般商品的研發和生產，開發過程中會面臨著各種難以預測的風險，比如需求的變化、人員的異動、技術的瓶頸、同行的競爭等，高效的軟體開發團隊往往是採用了合理的開發過程去控制開發過程中的風險、提高軟體的質量、降低開發費用，這樣的團隊會根據自身的必要程度決定要執行哪些工作?如配置管理、資源管理、版本控制、代碼控制等，團隊還合理的分劃並定義開發過程的里程碑，決定每項活動內容的底線和審評標准，決定各項活動的先後關系或迭代的關系等。總之高效的軟體開發團隊的開發過程的原則是高效率、高質量、低成本。