開發軟體和項目經理如何對接

㈠ 軟體開發的程序員在完成當天的任務之後如何把自己的東西交到項目經理那裡

1. 不是所有任務都必須每天提交。提交的粒度可以自行選擇，以不影響工作效率為原則。
2. 代碼一般是提交到版本控制系統里，比如SVN，CVS，GIT，P4等。
3. 項目經理一般不會去review你的每個提交，他更關心的是你的進展情況。報告進展情況有很多種方式，比如可以用郵件，或者你們如果公司內部有類似jira的項目管理系統，則可以直接登錄到管理系統里更新任務進度，你的項目經理可以通過管理系統看到當前的進展情況。

㈡ 開發軟體時,碰到項目經理老是催開發進度,應該怎麼辦

首先要把問題分析清楚，了解項目各種關聯關系、代碼關系、風險等，結合自己的手頭工作給出最終完成的日期，在任務推進的過程中，要每天、每周把進度匯報給項目經理，遇到什麼問題、風險之類的要提醒項目經理，確保能有應對措施。

工作是勞動者通過勞動（包括體力勞動和腦力勞動）將生產資料，轉換為生活資料以滿足人們生存和繼續社會發展事業的過程。工作作為名詞用有工程、製作、業務、任務、職業、從事各種手藝的人等意思。

一個人從事什麼工作，由其所處社會環境和個人能力(包括認知)共同決定，因此不能用有色眼鏡去看一個人所從事的工作。人類社會是由不同的組織、團體、公司組成，而以上的組織、團體、公司都是許多個體構成，他們分工合作，向著既定目標行動，從而帶動了社會的前進發展。

人生如戲，戲中自有角色之分，您的角色選擇，取決與您所喜愛。能力可以提升、知識可以學習。工作對個人的意義，實現人生意義，以滿足人生需求。工作對社會的意義，社會的發展進步，與每個社會組成成員的選擇傾向是有密切關系的。

㈢ 軟體開發如何才能更好轉為項目經理 (咨詢專家：潘東) [已答]

軟體工程師到項目經理的轉換，也就是技術人員到管理角色的轉換，思維方式也要隨之變化，這個變化是沒有辦法一蹴而就的，只能是慢慢調整，讓自己從跑馬的角色抽出來，學著做進度規劃、成本預算、質量控制相關的通用知識，更重要的是溝通技巧，項目經理大部分的時間都要花在溝通上面，做好當夾心餅乾的心理准備，角色的轉換過程是痛苦的，前景是光明的。。。回復會員：wilehorse回復時間：2013-05-09 要實現這種轉變，最重要的是什麼？以及要如何才能更好的進入角色？——個人認為，管理最重要的是看問題的視野和高度都不同技術崗位，管理者要做的是對手中資源做好統籌規劃，與外界干係人做好及時溝通。由於軟體開發工具的模塊化和軟體開發的產業化，所以現在的IT項目經理要做好的工作之一是需求管理。回復會員：lily60回復時間：2013-05-01 1、項目經理需要專業資質證書，一級或二級建造師證書。 2、項目經理要有足夠的項目管理經驗，有專業資質證書不一定能幹項目經理，因為項目管理必需要充分了解你所管理項目，這才是項目管理的靈魂所在。 1、熟悉業務； 2、熟悉項目管理知識； 3、喜歡項目協調； 從軟體開發開始，從軟體開發結束。 1. PM方法論的學習。PMBOK 可以作為一個範本。 2. 軟技能的培養，做好IQ培養向EQ培養的轉變。做技術的人容易忽視軟技能如領導力、溝通力、影響力、語言能力等的培養，需要多閱讀這方面的書籍或參加這方面的培訓加以補充。 從開發轉到項目經理，從某種程度上相對比較容易，但重要的一點，需要認識自己，是否具有良好的溝通能力和協調管理能力。也就是說需要的軟技能是否具備？另外，是否做好了被「折磨」的心理准備和心理承受能力。呵呵，需要慢慢的有意識的轉吧。回復會員：gandy01回復時間：2013-02-26學習~~回復會員：surprise28回復時間：2013-02-26 技術轉為管理，個人覺得最重要的轉變就是意識的轉變了。 技術很多時候要求精益求精，但管理更多的要求整體目標的最優， 必要的時候，需要「犧牲」部分來「顧全」整體目標。 技術崗位要求能靜下心來思考，鑽研； 管理崗位則要求能多與人溝通，多做協調。 由技術轉為管理，有優勢，可以快速把握項目方向； 由技術轉為管理，也有劣勢，容易被以前的思維所桎梏。 但只要有意識的改變自己的思維角度，多思考， 軟體開發的項目經理，要在實際工作中掌握任務計劃、分工，及後期的驗收工作。 對開發團隊的管理也是對自己的一種提升。 建議：在軟體開發過程中，偏於管理方向的問題及時去解決，多查一些資料和文件。看一些管理方面的書。

㈣ 軟體項目經理帶一個團隊開發一個軟體，他在這個團隊中做那些事情呢

作為一個項目經理，其角色或者說職責體現在：

1、不斷地識別項目干係人，並管理好項目干係人的期望。
比如一個軟體產品開發項目，可能的干係人包括但不限於：
投資方希望通過產品賺錢
產品用戶希望產品好用、能給自己帶來使用價值和良好的使用體驗
項目團隊希望通過該產品體現自己的創造力、成就感，並收獲勞動回報和能力提升
政府機構希望該產品有著良好的社會效應
……
項目干係人不是一開始就能完全識別出來的，所以需要不斷識別
要管理好項目干係人的期望，需要良好的溝通技能，要能換位思考，充分從對方的角度去理解與認識

2、組建和建設一支強有力的項目團隊。
項目團隊是項目成功的關鍵要素，組建團隊、激勵並持續建設團隊、協調好團隊內部的關系和任務分配、充分溝通，是項目經理必須一直要做的事情。
建設項目團隊，包括了招募、培訓、調配、指導等各方面的工作。

3、做好項目管理計劃，充分管控項目的范圍、進度、成本、質量、風險等要素。
項目的范圍、進度、成本、質量、風險管控是項目管理的基本要素，也是項目經理要做的事情之一。當然，具體的需求調研及確認、系統架構設計、詳細設計、開發、測試、變更、風險、文檔、驗收、交付、培訓等等，甚至包括項目進度計劃，都可以分解給項目團隊成員來做，但項目經理要負責總體的管理和掌控，協調各方面的資源。

4、總結項目。
項目結束、產品驗收交付後，項目經理的一個重要工作就是總結和分析項目的成敗得失，尤其是充分總結經驗和教訓，作為自己、團隊、所在的企業組織以後項目的借鑒和參考。

軟體項目經理，如果過多地深入到產品設計、開發過程，而或多或少地忽略其真正應該專注和關注的職責，對項目有害無益。

㈤ 做軟體開發中介要怎麼干。我認識幾個項目經理能接私活。拉來業務跟他們說，他們不就直接簽合同不經過我這

我現在就在做這個，我現在自己創建了一個公司專門干這個了，我從一開始就是我自己對接需求乾的就是產品經理的事，至少幫產品經理幹了一半，客戶都是我自己直接對接的，客戶跟我簽合同，我跟做項目的簽合同，我以前就是技術所以基本很多東西懂點，遇到客戶需要自己先溝通需求，自己在和產品經理溝通。

㈥ 兩個軟體公司開發對接中存在的問題

摘要 一般而言，傳統的系統開發是項目經理給開發人員的指令，這個指令包含開發人員將要做什麼、工作完成後的效果等等，但實際中這種指令往往比較模糊，不具體，也不太明確，沒有把注意事項及對其它功能的影響明確出來，更嚴重者是不能理解任務所表述的含義，畢竟部分開發人員之間的水平還是存在差異，這種情況的存在往往造成開發人員工作效率低、代碼冗餘、做無用功等，另外一點項目經理對開發人員的了解也很重要，這樣可以避免本來開發人員半天可以完成的任務，給他分配一天的時間等，在任務的下達過程中出現的問題可以總結為一下幾點：

㈦ 一個公司接到一個項目後，是如何進行開發的

這個，看是大項目還是小項目
小項目的話，項目經理派人去做需求分析，需求回來了，美工做前台，程序員做後台。
大項目的話。。就復雜了。
先需要需求分析團隊去做需求，需求分析回來了交給架構師團隊設計架構，架構文檔下來了，分配任務後，各個程序員就按照類圖寫程序吧，程序員有問題就問架構師，美工就管設計頁面。
不論大項目和小項目都要把進度實時的反饋給用戶。
一般做項目經理的要麼是系統分析師，要麼是架構師。很少有隻分配任務不幹活的項目經理。

㈧ 開發一款軟體，從項目經理的角度，應該如何控制這款APP的開發

一般情況下，首先要進行需求分析，然後根據需求的類型和明晰程度來確定軟體的生命周期、開發模型，比如瀑布模型、V模型、螺旋模型、快速原型模型等等；然後進行架構設計，確定軟體的框架、包括技術框架、功能框架等等；接下來對各個功能進行分析、編程實現；然後要進行測試檢驗，可以使用各種測試理論，黑白盒、單元測試等等；測試通過之後，交付客戶使用，並提供相應的技術支持，比如安裝、調試、升級更新等等。整個項目過程中，根據各個階段的進行情況，編寫項目文檔，作為質量管理的依據。

以上只是一個通用的、大體上的軟體項目開發管理過程，具體參考軟體工程、軟體項目管理等相關理論。

㈨ 軟體開發的項目經理的日常工作是什麼

軟體開發的項目經理：
1、 基本職責就是確保項目目標的實現，領導項目團隊准時、優質地完成全部工作。
2、 與客戶溝通，了解項目的整體需求。並與客戶保持一定的聯系，即時反饋階段性的成果，和即時更改客戶提出的合理需求。
3、 制定項目開發計劃文檔，量化任務，並合理分配給相應的人員。
4、 跟蹤項目的進度，協調項目組成員之間的合作。
5、 監督產生項目進展各階段的文檔，並與QA即時溝通，保證文檔的完整和規范。
6、 開發過程中的需求變更，項目經理需要跟客戶了解需求，在無法判斷新的需求對項目的整理影響程度的情況下，需同項目組成員商量，最後決定是否接收客戶的需求，然後再跟客戶協商。確定要變更需求的情況下，需產生需求變更文檔，更改開發計劃，通知QA。
7、 項目提交測試後，項目經理需了解測試結果，根據測試的bug的嚴重程度來重新更改開發計劃。
8、 向上匯報。向上級匯報項目的進展情況，需求變更等所有項目信息。
9、 項目完成的時候需要項目總結，產生項目總結文檔。

㈩ 軟體外包開發如何管理和溝通

在交流的過程當中，刻意的統一了語言，會使得我們盡管是一個遠程團隊，但是在交流的時候，能夠很清楚的知道我們在對信息架構在哪一層進行反饋。這不但使得業務方可以反饋技術方，其實技術方也在引導業務方。語言的影響是雙向的。
在技術領域里，我們也選擇了隔離性更好的技術架構，使得MVP的代碼不會變成我們演進道路上必須長期背負的負累。而之所以在一篇聊「語言」的文章里提技術架構，是因為我們認為真正的架構不是紙上的，也不是代碼里的，而是每個團隊成員心裡的架構。實施一個架構必然也是要進行大量溝通，也需要統一語言。
而在交流業務的時候，我們刻意的劃分了各種不同的子領域，又在每個領域當中統一了名詞。統一名詞還是比較簡單的，最難的是劃分領域，我們為此投入了大量的工作，也犯了一些錯誤，但這些付出是值得的，這之後，我們的溝通變得非常流暢。
IT行業的人員流動率接近25%，這意味著每年技術團隊中至少有1/4的新人加入。即便想盡方法讓的團隊保持穩定，隨著敏捷和精益創業的相關思想慢慢成為我們的工作常識，每個項目存在的時間都不會太長，這使得IT團隊經常性的重組，有時是團隊被打散，有時是同一個系統從一個團隊交給了另一個團隊。如果缺乏一種有效的反饋機制，那麼無論是人員流動還是組織重組，所造成的切換成本都是一個很大的。盡管這個切換成本無法消除，但是盡量減少切換成本是我們每個專業人員應該追求的，尤其是團隊中的技術領導者。
技術領導者重音在「領導」，而不在「技術」。尤其在今天，技術就是業務。優秀的技術領導者更不能把自己變成一個救火隊員，只是被動的響應，盡管救火隊員常常因為很容易被人看到而獲得一些關注和贊揚，但在中國的文化里，我們都知道還有更高一層的境界，這個境界存在於很多典故中，比如上醫治未病，善戰者無赫赫之功。同理，軟體開發領域的技術領導者們也應該努力使大多數問題發生的基礎消滅於無形，這就需要我們走出舒適區，深入到軟體開發的第一現場，進行現場管理。