挨踢部落故事匯(10):技術晉升管理的心聲

Leon畢業於醫學院醫學信息學專業，自進入這個專業起，他就基本明確從此要從事醫療信息化行業相關的工做。畢業後他邊工做邊參加培訓班學習.NET編程，並順利進入醫療軟件公司。從普通程序猿慢慢作到技術經理，後又作產品經理，工做無不圍繞醫療信息化相關。參與開發和設計過EMR、HIS、RIS等醫院內相關業務系統，經過PMP和信息系統項目管理師的考試，對項目管理的知識體系有一些認識。目前研究某市的我的健康檔案數據以及慢病數據，勵志服務於市民，以及衛計委相關職能部門。

Leon·.NET開發

堅持.NET開發，逐步晉升

Leon的職業生涯大體分爲四個階段，技術學習階段、軟件工程師、技術經理、產品經理。

一、技術學習，打下編程基礎

大學期間Leon基本沒有不少的技術積累，只是閱讀了《C#入門經典》這本書，僅僅是閱讀，沒有跟隨書寫相應的代碼，因此基本收穫不多。.NET的正式入門主要是靠將近200個夜晚的培訓班學習積累的。培訓班的學習使他對.NET有了一個初步的認識。該學習過程主要是幫Leon打下了基礎，對於WinForm的各種控件、HTML各種標籤、SQL語句的各種寫法有了瞭解。但如今回過頭來想一想，當時的學習徹底沒法達到企業級開發的要求。

二、軟件工程師，技術細節的深刻

基於大學對醫學知識的積累和.NET培訓這2塊敲門磚，Leon順利進入了醫療軟件行業。進入項目組後，組長告訴他產品的開發使用的是WPF，而他卻從沒有接觸過WPF。因而買了一門《WPF編程寶典》，他Coding了裏面全部的代碼，對WPF的體系結構有了基本認識。再結合項目上的代碼，他的WPF技術有了很大的提升。閒暇時Leon會逛逛技術論壇，學習別人的實現方式。做爲軟件工程師，他認爲經常會copy別人的代碼，但copy只是第一步，要想提升，須要進一步去理解別人代碼背後的意義，並作一些擴展。

影響Leon比較深入的是當時對護理體溫單繪製的實現，一個比較複雜的繪製操做，原先有個簡單的版本，用C#寫的，但領導要他根據新需求從新編寫一套，主要是業務的升級，以及設計思路的變化。項目框架是傳統的三層架構，業務系統沒有太多的技術架構。核心技術點是對XmlDocument類和Graphics類的應用，原有版本中有一些相關代碼，再加上他查找了這兩個類的大部分方法和屬性知識，以致於他在着手開發相應功能時，內心的底氣就足了不少。後來又學習了《C#高級編程》這本書籍，對面向對象的思想有了更深的認識。

三、技術經理，技術團隊的全方面打造

技術經理職位不是一蹴而就的，隨着工做年限和技術能力的提升，Leon開始帶新人。他老是很耐心的指導新人，由於他知道本身畢業的時候還不如他們。好比代碼規範，這個是技術新人基本都須要遵循的，Leon他們有個內部的代碼規範。對於應屆生新人，Leon會根據項目所須要的技術定一個學習計劃，時間大約在1-2個月，內容精確到周，幫助他們提升自身能力。技術經理身份的他不能着眼於眼前，一個功能他實現也許只須要1周，讓新人實現也許須要2周甚至更久，同時還須要Leon不按期指導。但這些投入都是值得的，由於當新人獨擋一面的時候，Leon就會騰出手來作技術架構、功能設計方面的使用，Leon會根據項目長期發展的規劃，讓他們在完成相應功能的同時，去作一些技術預研，這些技術預研不少是Leon本身也不瞭解的。此時技術經理崗位的他更多的是考慮怎樣讓項目不失控，團隊人員的可更換。

做爲技術經理的時候Leon是在一家不算太大的公司，各種軟件研發和管理均不是太正規，內心常常對項目把控、團隊管理有不少疑問。因爲心理的這些問題，他自學了CMMI認證體系內容，第一次閱讀時，他感受收穫頗豐，從中挑選了一些合適的模板運用到團隊中來，如需求說明書、功能設計書等，初見成效。Leon一直對本身要求很高，工做的同時也不斷增長自身閱歷，他前後經過了PMP和信息系統項目管理師的考試，再結合本身遇到的問題，對項目管理有了比較深刻的理解。

四、產品經理，立足產品設計和進度把控

16年跳槽，Leon正式作產品經理的工做，主要涉及醫療軟件的功能設計。他所在部門的產品經理和互聯網產品經理有些差異，Leon更多的是關心需求、產品設計以及進度把控。他須要作各類文檔，需求列表、功能列表、原型圖、ER圖、業務流程圖、詳細設計、軟件使用手冊、進度列表等。這些文檔能夠幫助項目組人員更好的理解項目、同時保證項目不失控。需求是產品的基礎，需求調研須要全面細緻，除了對客戶的調研，也須要調研競爭對手產品，最終生成需求列表。功能設計應由抽象到具體，由簡單到豐富。功能設計的核心目的是讓開發和測試能理解功能，同時留有存證，方便新入項目的同事能快速進入項目。

職位能夠多變，但方向只有一個：深耕醫療信息化。

對於產品經理的工做，Leon總結了幾點經驗：

A、idea的產生和初步的需求調研

這個idea每每是領導的，也許是通過深思熟慮亦或未通過深思熟慮。但銷售每每能拿下相應的市場。領導任命你做爲項目經理兼產品經理推進該產品的研發，並最終上線。此時須要作初步的需求調研，核心目的是弄清楚該idea目前在市場上的實現狀況和實現難度，肯定本身以及公司是否有能力完成該項目。

B、詳細的需求調研和分析

需求調研要儘可能全面，包括軟件可能的使用者、目前業務流程狀況、市場上存在競品的實現狀況等。列出全部的需求點，進一步分析軟件須要完成哪些需求點。此時能夠將需求點分紅基本需求點（軟件中必須實現的）、閃光需求點（完成能夠提升軟件競爭力）、個性需求點（個別客戶要求非共性的）。此時須要輸出需求說明書文檔，記錄全部需求，並分類，建議用Excel來實現。需求文檔要作到條目清晰，只要調研到的或者本身思考到的均應列進去，便於後期功能出來後作一一匹配。

C、功能設計，功能架構要清晰，模塊耦合度要低

功能設計主要包括概要設計和詳細設計。概要設計主要產出功能列表、原型圖以及ER圖。此時的大功能點應該都出來了，頁面的基本佈局也能夠肯定了。原型圖上的各個功能須要和需求列表對應一下，用來判斷哪些需求是包含在功能中的。此時的功能設計須要考慮低耦合，以知足後期的迭代改變。ER圖設計時要將面向對象的思想放在心中，肯定是各個實體的實際意義和實體關係的正確關聯。詳細設計階段主要是產生詳細設計文檔，文檔格式多種多樣，主要是讓開發人員明白他開發功能的各個細節。通常包括以下幾個方面：畫面字段、錄入校驗狀況、畫面的處理流程、畫面列表和字段查詢的表結構關聯等等。詳細設計可繁可簡，以開發人員和測試人員能理解爲原則。在整個功能設計中會產生進一步的需求，須要記錄到需求列表中。功能設計完成後須要和相關干係人肯定，主要包括開發、測試以及客戶表明，以發現問題肯定版本。

D、軟件開發、測試、上線

此時產品經理須要跟蹤相應進度、及時發現開發內容和設計內容的誤差予以糾正。這期間可能會產生較多的需求變動，須要將其記錄下來進行分析，從而判斷是否在開發途中進行功能的修改迭代。開發框架的搭建、代碼的管理、代碼質量的把控、測試等此處不作過多討論。

如上看上去是一個比較典型的瀑布模型，但一套軟件的開發，能夠分紅N個迭代，一個小迭代也遵循如上的原則，軟件上線前也能夠經過N個迭代來一步一步完善軟件。

在整個軟件開發過程當中的注意事項

一、功能狀況和項目進度狀況放心中

軟件從需求階段到最終上線階段都應該有詳盡的進度計劃，比較近的時間節點進度計劃須要詳細和準確點，比較遠一點的時間點能夠粗略點，記錄計劃開始結束時間和實際開始結束時間。進度計劃的羅列是項目管理中的一個重要部分，理論上要越詳盡越好。將工做任務進行分解，對各個任務肯定相應的時間節點，如發生變動須要及時記錄。項目進度文檔不是一成不變的文檔，須要在項目推動的過程當中及時修改，刪除不合理的地方，添加未想到或者未細化的地方。

二、對於原先沒有相關需求文檔和相關設計文檔軟件的一些建議。

a)以項目管理的思想作指導，創建改進計劃，讓軟件產品逐步走向正軌。

b)從如今開始，就應該創建需求列表文檔和功能列表文檔，記錄軟件產品的變動。

c)若是時間容許，應該從新整理相應的功能邏輯關係以及ER圖等。

三、擁抱變化，重構重構再重構

靜止是相對的，變化是絕對的。每一個人都在工做中成長，你的產品也是。使用的人愈來愈多，纔會發現之前沒有發現的問題。任何一個問題的產生都是提高產品的一次機會。人非完人，產品經理也好，技術開發也好，所作出來的東西並非一蹴而就的。技術人員幫助實現軟件產品，軟件產品也幫助技術人員提高技能。一個好產品的產生，須要通過無數次的迭代。咱們在整個產品設計和開發過程當中都應該認識到這一點。

最後，用Leon的座右銘送給全部的開發者：在人生的道路上砥礪前行，無懼風雨。但願與每一位IT人共勉。

若是你也願意分享你的故事，請加51CTO開發者QQ交流羣 370892523聯繫羣主小官，期待你的精彩故事！