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

[[184479]]

Leon·.NET開發

堅持.NET開發，逐步晉升

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

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

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

2、軟件工程師，技術細節的深入

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、功能情況和項目進度情況放心中

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

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

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

b)從現在開始，就應該建立需求列表文檔和功能列表文檔，記錄軟件產品的變更。

c)如果時間允許，應該重新整理相應的功能邏輯關系以及ER圖等。

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

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

最后，用Leon的座右銘送給所有的開發者：在人生的道路上砥礪前行，無懼風雨。希望與每一位IT人共勉。

如果你也愿意分享你的故事，請加51CTO開發者QQ交流群 370892523聯系群主小官，期待你的精彩故事！

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】

【編輯推薦】