失敗與湊合–畢業一年

0 評論 2958 瀏覽 2 收藏 6 分鐘

今天下班在公交車上,突然想到我畢業工作將滿一年,我覺得該寫點什么,然后我決定寫我在上家公司兩個項目。

首先說說這兩個項目,一個是網絡化功能,另一個是一個ios app。前者失敗,后者上線使用但也只能湊合。

我這四年的大學期間,給我影響最深的是快遞和互聯網的發展。上家公司在怎么使用網絡提升客戶滿意度和產品質量上希望做一些探索,這就是第一個項目。

當時我剛被分到公司最早的產品組,開始做產品功能的客戶定制。突然一天研發經理讓我和一個員工開始參與這個項目,其實就我們兩個人,但是給我們的資料只有一個設計說明書,在看了技術線路之后,我反映給研發經理,我希望使用開源的技術堆棧而不是我們自己從零開始搞,然后研發經理答應了,我也出乎意料。

項目匆匆上馬,對于一個探索性的項目,需求這塊可想而知,高層說網絡是趨勢,要搞,對于一個對公司產品應用場景都沒去過的剛畢業的愣頭青可想,需求完全是一頭霧水,我們組的產品經理對這個很不看好,他跟我說過,車床沒幾個連網的,需求注定了這個項目只能爛尾。

項目開始提出的需求都是基本的更新,廣告提示,系統信息上傳。這些功能對于現在的軟件都是基本的,可是對于一個10多年時間,開始并沒有考慮網絡功能的軟件添加這些功能難度可想而知。而我對當時產品架構可以說是完全不熟,而這些是設計說明書里面沒有的,那個說明書更多的是服務器端的,客戶端這塊的詳細設計一點沒有,這就導致了在編碼實現時的設計局限性,也為項目失敗添加了一筆。

項目的規格說明也沒有,不知道做什么樣,導致了在項目開啟后的中期檢查,做出來的功能根本不能使用,只是一個實現功能的原型而已,沒有驗收標準,這會導致項目實現要求一直在變。

我已經不記得是在那里看到的:“在項目開發中,頻繁的修改需求和規格標準,會導致項目延期,更甚者導致項目失敗,在沒有導致產品不能用的情況下,不需要修改需求和規格?!?/p>

最后這個項目的功能大部分被閹割,在服務器搭起來后,在進行了一個小規模的上線測試后,不了了之。然后下面開始了第二個項目。

第二個項目是一個公司軟件的注冊驗證app,算法什么的放在公司服務器,破解的難度就加大了,這是很實際的一個產品,需求很明確,需要完成什么樣,也很明白,這個項目的服務器是我負責,app外包給了其他公司,我的大部分時間都是與前端開發人員溝通。

項目進展還比較順利,在1個月后,第一版產品出來,開始在公司內部測試,這時領導的需求又開始來了,不過這次有些需求被我打了回去,還有一些需求都是在與前端人員討論之后才修改的。對不合理的產品要求,我也堅持了自己。最后app上線了,算個湊合。

這兩個項目讓我這個新人,體會了良多,以下為我的一些總結:

  1. 需求很重要,連自己做什么都不清楚,那肯定是做不成了。
  2. 半路加需求請確定對現設計的影響程度,不然就放到下個版本。
  3. 規格要求不能總是變,不然產品無限期推延,最后你自己都不知道會怎么樣,客戶還能用就不要改,要改也是下個版本。
  4. 項目進度是要每天盯了,以便做出調整,給自己留條后路。
  5. 在項目中的溝通盡量找到一個都合適大家的溝通風格。

 

本文由 @zhouxiang?原創授權發表,并經人人都是產品經理編輯。轉載此文章須經作者同意,并請附上出處(人人都是產品經理)及本頁鏈接。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!