一早起來想了半天決定寫這篇文章來清理一下思緒兼抱怨，內容是我目前工作上碰到的難題，就是一股阿雜的感覺。
剛到新公司兩個月（製造業IT），進來之前面試我的主管就有強調這份工作是從需求訪談，系統分析到程式實作都要一人負責的工作，簡單說就是PM兼SA兼SD兼PG兼QA的工作一條龍全包。更詳細的說，工作內容包括與使用者開會了解使用者的需求，將使用者的需求轉換程商業邏輯流程，規格文件撰寫，資料表schema開立，操作流程規劃，操作頁面prototype設計，軟體架構設計，功能模組規劃，功能實作，功能驗證測試，使用者說明書撰寫等。
在之前的工作都是專職在PG，偶爾兼著寫寫SD文件而已，所以當初這工作吸引我的一點，除了離家近，工作時間彈性之外，就是能參與系統設計這點，畢竟我到目前兩年快三年的Java工程師生涯，覺得是開始累積系統分析與設計的經驗了。
一進來開始主管分派了一個與公司核心業務不相干的小案子給我做，而這個專案在我進來之前已先有另一位同事A與使用者開過會並取得了基本的使用者需求，基本的資料庫Table schema，不含邏輯的頁面檔，及由另一位技術資深同事B設計好的Web應用程式基礎技術框架，包含使用的framework技術及主頁面框架，登入及功能選單等。然後在我進來後幾天就由A"交接"給我，主管說就讓我和A一起合作完成這個專案。
一開始我以為所謂的合作是，基於以上給定的東西來開始實作，有不懂得地方就問A，因為需求是由A和使用者訪談得出的，所以A最清楚使用者要什麼。但當我開啟Eclipse執行了svn checkout下來的應用程式，看了看頁面，再看一看資料表的關聯，再看一看使用者需求，天阿我完全對不起來，我認為原本的資料庫設計無法達到使用者需求的，所以我必須重新設計一個新的才有辦法。（我也希望有人打我臉證明是可用的，這樣我就不用重新設計了。）
談談原本的資料庫設計，前幾天和主管討論到這件事，因為主管後來發現我是重新另外設計一個，而不是用原來的設計。主管說當初的設計其實也是可以用，原本的設計是由A規劃並由他和技術資深同事B review過的，但當下我很直接回說原本的設計無法滿足使用者需求，當時是我和主管在私下非正式的聊天聊到的，所以也是沒個結論。我主管給我很大的空間去做這個專案，沒要求我一定要怎麼弄，所以他覺得我有我自己的想法也可以。我知道了解清楚"設計"這種東西本來就沒有絕對的好壞（基於可用的前提下，好的設計用起來方便順手，壞的設計讓你幹聲連連，但皆能達到目的。然而錯誤的設計是無法達到目的滿足需求的。），我也不覺得自己設計有多好，或說別人設計有多爛，問題在於如果原來的設計實作起來邏輯沒問題，其實我也不用花精神去重新設計一個。只是我盯了原本的設計琢磨了一天，#越想越不對勁，發現按照原本的設計是無法滿足需求（甚至有邏輯上的衝突），所以才重新設計。
另外還有一個問題是原本的頁面表單設計，就是靜態的標記語言檔，這是集眾人（我看svn log是由其他同事C，D，E提交）完成的，因為原本的資料庫模型有問題，理所當然頁面設計當然無法直接拿來用了，也是打掉重練（不過就算原本的資料庫設計是對的，頁面設計依舊有問題，因為原本的頁面邏輯也是缺了很多東西），能用的就只有技術資深同事B做的登入和主頁面的選單而已。
以上在軟體開發都是很正常的，本來就很難一次把所有細節都想清楚，增補修改在所難免，問題是他們好像認為那些東西都可以用，我再改是在浪費時間。
而以上的東西，包含使用者需求是已經和使用者demo過一次並經使用者認可的，主管並安排下一次的demo，大概有三個禮拜的時間吧。我不知道第一次demo到底認可了什麼，因為上述的東西不能用，很多細節都沒談清楚，都要重新構思並設計，所以我也回覆主管說到時候只會demo頁面表單功能及操作畫面等，和使用者確認操作流程上是否接受而已，並不展示實際功能。
就在我再用prototype軟體（Axure RP）構思設計wireframe時，主管包含同事們都說我這樣很慢，告訴我應該直接用標記語言來做，這樣到時候就不用重做一次。但我很堅持說用這軟體做頁面拉一拉就好，可以很快的做一些操作互動，還可以產html，而且demo只是要跟使用者確認畫面功能頁面的操作，如果用html直接刻會比較慢，改起來更麻煩。不過以上的話他們聽不進去。
在設計資料庫時，A說我有考慮到什麼問題嗎？要可以有什麼什麼功能之類的新的feature，然後最近開始實作程式時使用者又說要可以幹嘛幹嘛，直到今天才知道我太嫩太蠢了，因為使用者需求從頭到尾根本沒有確認下來。什麼叫確認下來，我今天才知道就是要有一個規格文件，對，就是PM，SA要做的事，使用者需求文件，系統文件，功能文件等要寫好請使用者畫押，要不然一直加功能要做到什麼時候，嚴重的會影響到整個架構設計，真是要命。所以A是挖洞給我嗎。
到新的工作環境，新的組織，理所當然需要時間去磨合去適應，昨天和主管聊天他也說讓我撞牆幾次就學會了，只是我覺得很阿雜，從進到來到現在不時地鑽牛角尖，我知道我在鑽牛角尖，我一直在找個理由說服自己讓我接受一些情況，試著問題拆細逐一解決。
我現在想著是，是應該跟使用者重新開個幾次會確認所有需求細節，然後把煩人的文件寫好，然後才繼續實作？還是繼續我原本我認為快完成的實作，事後再回頭跟使用者確認？可以的話當然是需求規格先確認清楚，但又想者主管期望上線的時間，就覺得很煩。
主管當初說給我三個月的時間去完成這個專案並上線，在未仔細看過原本的設計並認定可用的情況下，覺得應該是沒問題，就算是重新設計也勉強可以，但想到如今要回頭跟使用者重新開個幾次會來確認需求規格這件事，就覺得根本不可能。
和主管私下聊天，他說團隊合作溝通很重要，當然我也知道很重要，但我不知道有沒有兩個工程師合寫一支單一功能的程式這種事（其實有啦，類似pair programming），或是合寫一份規格文件。當兵最常搬那種餐廳的大飯桌（從A點搬到B點，再從B點搬回A點），一個人搬不動一定要兩個人一前一後搬，兩人的步伐速度要協調一致才會順，這就是合作。但我目前的情況是，叫對方寫文件也不對，因為主管希望我學習寫文件，叫對方寫程式實作也不對，因為主管希望我寫程式，叫對方規劃資料庫也不對，因為當初已經規劃但是不能用。叫對方跟使用者訪談需求也不對，因為當初訪談的結果很多細節都沒談到。所以我要怎麼跟A合作？所以我目前想到的就是，我做好任何事請A review，或再請他多加點featur？。
主管在之前一直催促我可以開始動工了，但我進來的第一個月幾乎都在重新設計架構還有做prototype，這沒弄好我根本不敢動工，好不容易幾個關鍵Table設計好才動工，而實際上還缺了幾個Table。原因都出在規格沒確認好阿。
阿雜的點有：
- 主管說要我跟A合作完成這個專案，問題在於要怎麼合作，是我要求他幫我實作功能嗎，還是他要求我幫他實作功能？還是要我和他討論（爭論）資料庫設計上的對錯？和A討論的時候我就很負面，因為我認為他都沒思考過，東西都超出原本需求的範疇了，文件就一張手抄紙。如果他是使用者就算了，但他不是，但現在他彷彿似乎是另一個使用者。
- 干涉我習慣用的工具，我用自己認為這樣做比較快的方式做自己手頭的事，但他們認為那樣做比較快。就是在講wireframe prototype的事。那感覺就是你習慣用Chrome，但有人告訴你IE比較好用比較快。
- 要一直開會，然後都沒會議室。
- 我認為有些同事很蠢，原本並不覺得，直到他們試著將蠢想法壓在我身上的時候。我至今仍試著告訴自己要轉化這樣對溝通有害地想法。因為當想到溝通時還要爭論一堆事情的正確性就變得不想溝通，一想到溝通就想到衝突。
- 文件規格要寫多細？主管給我了幾份之前專案的範例文件參考，我昨天加班研讀了一下，文件裡面有的功能有貼程式碼，有的沒有只是單純幾行文字敘述，沒有規則。
- 需求規格沒確認並畫押，我東西做下去了到昨天才知道了解確定這件事還沒做而我必須做，這件事不怪他們，只能怪自己經驗不足犯蠢。
- 下一階段要學習的不是技術，而是溝通技巧和人際關係處理。不過我想到這歲數個性也定型了，只能聽天由命吧。
2年後也就是2020年回顧。好加在我最後撐了兩個月離職了，但還是晚了些浪費太多時間，應該第一個月 （最好第二個禮拜）覺得不對勁就要馬上離職。以我現在的五年的經驗回頭看以上發現當初的想法是正確的，那些人毫無軟體工程概念，而且工作可怕的包山包海一條龍，樣樣通樣樣鬆，更別提三個月上線這天方夜譚的要求。我的忠告是遠離製造業，製造也只把軟體開發當成本單位，不會放太多資源且得不到尊重，總是要遷就生產單位，還一堆毫無長進的老屁股。最後要相信自己的直覺與判斷。
沒有留言:
張貼留言