經驗分享-20天輕鬆搞定一個6000的小專案

喬巴小王子發表於2017-10-19

經過20天的溝通與開發,在雲沃客上接的第一個專案終於成功交付了。目前產品執行良好,與客戶的遠端合作還算順利,進度把握的也很好,算是比較成功的一次接包經歷。現在給大家把從平臺接包、開發、溝通、測試部署到最終的專案交付過程分享出來,供大家參考,如有需要改進的地方,也歡迎大家指正。

接包

以前做的專案都是通過熟人介紹或者自己跑的,偶爾線上接一些小的專案,但是沒怎麼用過類似這種自由開發平臺或者眾包平臺,有次在網上找專案的過程中,偶然間發現了雲沃客,上邊專案不少,觀察了幾天發現專案更新的也挺快,當即決定在上面試一試。翻了一會終於找到一個適合自己的了,是實現一個小遊戲的後臺管理系統,其中附帶了一個功能模組描述文件,看過之後感覺工作量適中,前臺頁面,後臺服務以及資料庫的設計一個人就能搞定,難度不大,6000元20天感覺還行,果斷就投標了。

投標的時候要根據自己的心理價以及發包方的預算定一個專案報價,不惡意壓價也不天馬行空,再選擇一個合適的工期,然後在留言中寫了一些自己的相關技能,以及提供一些我之前參與過的與標的類似的專案案例,網址或者下載連結,供客戶參考從而提高自己的中標率。

投完後就可以靜待對方的回覆了,建議安裝官方的雲沃客APP,如果客戶打算和你進一步詳談,通過APP能及時收到訊息。這時的溝通主要是一個相互瞭解和熟悉的過程,為以後的合作打好基礎,要讓客戶放心把專案交給你,估計是人品爆發,談了一會客戶就決定讓我做了。接下來就是針對當前的需求進行一下簡單的梳理,做到心中有數,如果有比較大的坑或者一些明顯的問題及時提出來,以免做的過程中又扯皮。最後就是對專案價格和工期進行再次確認,一次確定好或者根據最後的專案交付情況靈活處理,具體情況具體分析。待這些準備工作做好後就可以開工了。

技術

我接的這個專案因為是一個後臺管理系統,因此客戶對於UI設計沒有嚴格規定,只要不難看滿足功能要求就行,這個省了不少事,本人自認為開發還行,設計完全是個二把刀,不過審美能力和需求把握能力還行,知道客戶想要個什麼樣子的系統。因為工期短,要快速出東西,同時客戶對於技術這塊也沒有要求,經過短暫的思考後就確定好了技術方案。

  • 前端:Vue+ElementUI
  • 後端:nodejs+thinkjs
  • 資料庫:mysql

這樣搭配有個好處就是前後端開發效率都很高,並且能同時進行,打包部署也很方便。前端的ElementUI就是為後臺管理而生,豐富的介面元件和優雅的主題幾乎能滿足所有需要,同時有強大的社群支援,這樣媽媽再也不用擔心我掉進坑裡而不能自拔了。此項神器再配以天生高效並且功能強大的Vue,簡直了都。因為專案本身並不大,因此後端選用輕量級的node服務就夠用了,再搭配thinkjs這種經過業界考驗的MVC框架寫起API來簡直是得心應手。沒用express或者koa這種輕量級框架完全出於個人喜好,就是懶得找外掛。

話說開源社群真的是一個好東西,雖然以上這些框架都有腳手架支援,能快速搭建專案,但是你能在開源社群裡找到更棒的,並且更省時省力的乾貨,不管是GitHub還是OSChina都能發掘些能拿來直接用的程式碼或者原始碼,很是方便,這次就幫我不少忙。

專案管理

之前做專案時用的比較多的專案管理工具是teambition,很好用,不管是人員管理還是任務分配都很便捷,但是自從部分功能收費後就不怎麼用了。現在幾乎所有專案都用tower來進行管理和跟蹤,小巧而靈活,因此這個專案我也選擇了tower,不過聽說雲沃客也在開發自己的專案管理工具,而且馬上就要上線了,到時可以嘗試一下。在tower上建好專案後把客戶也加進來,讓客戶可以在以後的開發過程中能清楚當前的專案進度以及遺留的問題。明確哪些是待處理的功能,哪些是進行中的功能以及哪些是已完成的功能,這樣持續性的分階段測試和交付更能保證專案進度和質量。

首先在tower上建立好專案後,根據專案的功能需求分階段建立任務,每個階段的任務應該有優先順序之分,最關鍵的永遠在最前面。一開始的時候,任務粒度可以稍微大一些,在後續的溝通和開發過程中可以慢慢調整和細化,任務處理和更新要及時,做到每日一更,遇到問題做好備註和記錄,方便稍後處理,這樣在體現自己工作量的同時也能讓客戶心理有底。同時在tower上,可以讓客戶在系統的測試過程中提交bug,早發現早處理,儘量做到,一次過去,寸草不生。

時間管理

我不是完全的自由開發者,還有自己的工作,因此如何平衡本職工作和這個兼職工作的時間也是比較關鍵的,如果處理不好,就很容易翻車,兩頭不討好。還好,在這之前,公司的一個專案成功上線,現在只是進行bug修復和功能上的維護,處於一個平穩期,因此每天可以保證一定時間的開發工作。

每天一到公司,先把本職工作中的緊急事情處理完,這樣白天就不會有人打擾了,剩下的時間就可以完全投入外包專案的開發,那段時間,白天上班期間可以投入3個小時,晚上回去根據情況再做2個小時,如果白天時間被擠壓的不夠,那就相應的延長晚上的工作時間,儘量做到互不干擾。總而言之,每天時間就那麼多,所以提高工作效率才是王道。

溝通

由於是遠端開發,因此少不了頻繁的線上溝通,有效且及時的溝通是專案成功的第一步。白天在公司接電話和語音都不方便,因此主要通過微信來進行交流討論,雖然配有tower神器,畢竟不是很及時,因此很多時候就讓客戶直接在微信裡貼圖,我也能及時分析和回覆。白天通過文字溝通畢竟不方便,有些問題描述不清楚,因此每天晚上就和客戶約好時間通過語音溝通,總結專案問題,討論專案進度。

溝通的時間成本是很高的,尤其在需求討論階段,但是這個階段也是很關鍵的,如果理解不到位,就很容易在後期的開發過程中跑偏。這個專案客戶只提供了一個excel表格,將各個功能需求大致描述了一下,沒有設計圖也沒有流程圖,因為要做WBS,一開始我跟客戶通過微信逐個功能的討論細化,發現不但效率低而且很容易造成理解上的不一致。後來,就用了另一個神器—百度腦圖,將我細化的功能點畫了一個思維導圖,然後教客戶怎麼用,讓他根據他想要的在上邊改,這樣反覆幾次需求立馬成型了,然後在根據這個圖把任務加到tower上,大大緩解了遠端溝通的不便以及提高了溝通效率。以後如果有問題可以先迭代思維導圖,然後更新任務,做到需求上全面跟蹤,這樣對自己是一個保障,也能很好的婉拒客戶要求的改改改。

開發

前期工作準備充足後就可以安安穩穩寫程式碼了,還是這個最在行。由於專案不是很大,因此我就把前後端放到一個工程下,這樣開發起來很便捷,不用切來切去。雖然是一個人全權處理,程式碼規範也要做好,以免自己給自己挖坑。一個人也要把程式碼的版本控制工具用上,做好程式碼跟蹤,我比較青睞git,不僅開發時方便,而且部署也方便。

程式碼做好把控後,對於開發週期也要做好規劃,不能從第一天一直埋著頭做到最後一天,然後給客戶說好了,做完了。這樣不但客戶會炸,自己也很可能白忙一場。我這個專案就分了三個階段,剛好一週一個階段,第一階段主要是基礎架構搭建和前端靜態頁面展示,完了能讓客戶看看大致效果,有問題及時更正,第二階段主要是API的開發和主要功能的整合,第三階段就是剩餘服務的整合,測試和問題處理,給每個階段儘可能的留出一些時間處理客戶發現的bug以及做一些小的改進,儘量做到不緊不慢,收放自如。如果在中間某個階段客戶突然腦門一熱要求大改,那就要仔細評估風險了,和他聊聊人生,談談美好的事物,如果還是無法讓他滿足,那就要麼加錢要麼加時間再加錢,就這麼簡單。

部署與測試

就像之前提到的,要分階段開發,因此完成一個階段的任務就應該讓客戶能看到東西,並進行相關的測試。這樣也不用把前邊的問題壓到後邊,給自己製造混亂。客戶的伺服器是阿里雲的linux伺服器,已經用慣了,所以很順手,兩三下把環境搭建好,手動使用git遠端拉程式碼和打包,還沒嘗試過自動部署,始終覺得自己親力親為才讓人放心,以後可以試試。不過儘量不要本地SSH上傳,因為很容易出現人為錯誤,再處理這個問題就有些得不償失了。伺服器環境處理好後,再配置反向代理,然後啟動服務,客戶就能隨時隨地進行專案測試了,發現問題及時通過微信反饋給我或者放到tower上,待我後續處理,井然有序。

交付

待所有功能開發完成,並且測試無誤後,就可以結項交付了。如果需要質保的話這個一開始要談清楚,包括時間和價格,要是有改動的話,那就是另外一碼事了。待客戶確認好後就可以提交最終的里程碑檔案,然後結賬付款,讓客戶在雲沃客上給個評價,結束合同,至此,一個專案的週期正式結束了。

總結

一個人接包和開發有時是很孤獨的,所有問題得自己全部扛著,所以前期工作要做充分,能幹就幹,幹不了及時提出來,大家時間都很寶貴。對於有本職工作在身的開發者而言,專案管理和時間管理要做好規劃,處理不好不但會影響本職工作還可能還會影響自己的生活,一定要謹慎。這種畢竟是遠端開發,很難和客戶面對面交流,所以在溝通上要認真和高效,說問題不扯淡,要做到相互信任。這些都是我的真實體會,有感而發,希望幫助到大家。第一次在雲沃客上接的專案還算順利,下次繼續。

相關文章