從畢業起在一家小公司不知不覺已經工作了兩年，從開始的懵懵懂懂逐漸的對產品交付過程有了一些瞭解，最近負責了一個專案的開發讓我感到在小公司要做好一個專案真的很難，也深知是自己目前的水平還不夠，以下僅僅是根據自己目前的知識背景所提出的見解，可能有很多是錯的但這是從我自身角度得出的結論希望能對讀者有所啟發。
對於我負責的專案從啟動到交付的過程包括確定產品方向、產品定義、使用者體驗設計、基本的專案管理及開發、測試、釋出，忘了說一點，我們公司一個專案的開發團隊就幾個人，這次專案也是隻有4個人，其中包括我們每個人還有其它任務在，多工並行對於一個專案開發而言也是一種風險。
前期準備
不像大公司有產品部門、設計團隊、使用者體驗師等，從一開始的產品方向、產品定義、使用者體驗設計都是用研發負責的，對於這些我可能還是門外行，基本的前期準備我也是參考《使用者體驗要素》後憑藉我們研發幾個人的主觀臆測決定的，由於這個專案中競爭對手的產品已經比較成熟在市場已經經過多輪的驗證，我們從《使用者體驗要素》中定義的五個層次對競爭對手做了詳細的分析，為了得出我們的產品樣貌包括得出亮點功能。在這個階段我們花費了比較多的時間，我深怕做出來的產品不能獲得客戶的認可。
專案管理及開發
在這個階段會引入適當的專案管理方法以及開發，正如《大道至簡》中提到的不管是瀑布式還是敏捷式開發過程都是根據適當的場景選擇的適當的開發方式，不同公司還會有不同的變形。對於我們而言顯然敏捷更適合，因為所有的前期準備都是我們的主觀臆測，需要儘快完成給客戶的迭代版本獲取反饋驗證我們的主觀臆測是否正確。
我們公司很多流程都不規範，一開始沒敢引入太多的流程，老實說，在我引入站會、單元測試、評審等制度時就已經和大家做了非常多的溝通才達到共識得以實施，可能對於一些讀者看來這不太可能但這是真實發生的。我們的研發人員在使用面嚮物件語言設計時對於設計模式是沒有了解過，當然他們懂設計只是沒有給這些設計起了相應的名稱而已，當然也有一些設計模式他們沒有用到的但巨人已經總結過並取了相應的名字，我們應該去了解它們以完成更好的設計。
在專案管理的實施過程中我深刻體會到對於一個專案負責人來說威信力的重要性，你必須具備讓他們信服的技術，原因你們懂的。
小結
對於測試和釋出目前沒有什麼比較想表述的想法，可能後面會參考《谷歌和亞馬遜如何做產品》書中提到的措施進行更改實施，可能我們公司研發的水平真的是比較薄弱包括我自己，最近公司來了兩個大牛，我老闆的創業以前公司的同事，希望可以跟他們交請假一下對於我們公司而言怎樣做才能完成一次好的專案交付，我感覺在一家小公司負責一個專案做好它真的是一件很難的事情，時刻不忘工匠之心，晚安。