提問回顧與個人總結

首先我在整個團隊負責的是pm的工作，儘管有負責過開發的工作，但是我想更多地以乙個pm的角度來看待問題。

通過一定的軟體流程，在預計的時間內發布「足夠好」的軟體。

現在我打算從三個方面來徹底考慮這個問題。

·從開發者的角度來看，好的軟體是完成了其承諾的所有功能，修復了測試發現的所有bug。

·從測試者的角度來看，好的軟體是在經過測試之後，是健壯的，滿足了效能的要求。

·從pm的角度來看，好的軟體應該是適應使用者環境的，對比競爭對手的產品是要有明顯的優勢的。

綜合考慮這三個方面，我覺得評判乙個軟體的好壞，是由開發規範，測試程度，市場調研，使用者體驗等多方面來決定的。pm需要時刻了解市場狀況，競爭對手的產品特點，依據使用者的反饋資訊來進行需求分析。開發成員則需要制定相應的規範，保證**質量。測試人員則需要制定好嚴密的測試計畫，保證軟體的效能，健壯性。最終再交付給使用者手中，這樣才能成為乙個「足夠好」的軟體。

分析麻痺：一種極端情況是想弄清楚所有細節，所有依賴關係之後再動手，心理上過於悲觀。分析太多，腿都麻了，沒法起步前進。

當初完成程式作業時，我是乙個人獨立完成開發任務。現在在實際的軟體工程專案中，是多人合作完成任務，環環相扣。

在軟體工程專案中，依賴關係並不僅僅指的是**塊，各個函式之間的呼叫依賴關係。這個依賴關係包括前、後端之間的依賴，開發與測試之間的依賴，需求與開發之間的依賴，pm與使用者的依賴等等。而我們要做的，就是在起步之前，確定軟體的最小功能集——即軟體的核心功能。這個核心功能是由pm在經過市場調研，使用者調研，分析競爭對手產品之後獲得的，它是整個軟體工程的重中之重。

在需求分析中，殺手功能其實就是能夠把使用者從競爭對手那邊吸引過來的關鍵功能。在整個團隊專案中，我們組的殺手功能有2：其一是訪問速度，我們公客**的訪問速度比友商快許多。其二是移動端的適配，這是友商沒有做過的。其他功能比如課程評價，課程評分，課程查詢等功能也很重要，但是他們相對前倆功能來說都是「外圍」的。

構建完典型使用者和場景之後，還需要和這些典型使用者的代表去交流，理解使用者的工作方式和需要，然後再去修改，細化典型使用者。在確定這些內容之後，首先需要定義好相關功能的概念，規範相應的假設，界定邊界條件，然後依據典型使用者和場景，模擬、描述主流的使用者和軟體的互動步驟，並且說明***，最後需要說明服務質量。

至於技術說明書，則應該把整個軟體當成乙個透明的箱子，我們整個團隊在完成專案的時候，通過石墨文件，github wiki等置頂了一系列規範，包括介面規範，報錯資訊等等，同時前、後端、測試、ui進行了分離，大家在互相完成自己的任務的同時也互相溝通交流，通過撰寫相應文件的方式補充整個專案的技術說明書。

在確定需求階段，學會了如何去構建典型使用者和場景，並且如何將其轉化成功能說明書。

整體來說，在設計方面主要是學會了實體關係圖和思維導圖的應用。

在實現方面，學會了前、後端之間的聯絡，前端與ui之間的合作，通過這些方式使軟體變得更好。

測試這塊，主要是學會了如何和測試人員溝通，通過壓力測試，相容性測試等方面讓軟體在效能和健壯性方面變得更好。

在發布之時，學會的是如何在短時間內向使用者展示本專案的「殺手功能」以便第一時間吸引使用者~

身為pm，在維護階段主要的任務就是收集使用者反饋，處理使用者痛點，並且將其反饋給開發測試成員並且監督修復這些問題。

其實計算機學院的學生，在接觸軟體工程這門課之前，所有的專案都是個人獨立開發、測試的。因此導致大家都希望成為乙個技術人員，在管理、領導、協同這方面的能力比較薄弱。結對程式設計是我第一次和他人一起完成乙個專案。整體來說，由於時間安排不合理，設計的時候也不是很到位，所以遇到了許多困難。在團隊專案的時候，團隊中有幾個技術很強的同學，我在考慮之後，決定成為pm。大家可能都是奔著提公升自己的技術水平而選的軟體工程課，而我希望自己能在管理、領導這塊有所能力提公升，所以成為了pm。事實證明，乙個好的pm，在整個軟體工程專案的進展中有著舉足輕重的作用。儘管我的技術水平並沒有組內開發、測試人員那麼優秀，但是他們都十分願意聽從我的安排，專案雖然有起伏，但是最終還是完成的很好，甚至超乎我的預期。總體來說吧，軟體工程課雖然事情多，但是我是實實在在地體驗到了乙個軟體從需求分析到最後發布的完整過程，提公升很大！

最後，我不敢說我是乙個十分優秀的pm，但是，我能保證的是，我們整個團隊合作愉快，大家各司其職，對最後的貢獻分也沒有任何異議。

注：這是當時助教說轉會期必須要有人轉出的時候。

提問回顧與個人總結

提問回顧與個人總結

提問回顧與個人總結

提問回顧與個人總結

相關推薦