【避坑】初次接項目的血與淚,扎坑了老鐵


談起外包經歷,我的第一次外包源自前兩年某天陪着女友逛商場時,接到一個朋友的電話,朋友興高采烈地跟我介紹一個大項目:需求不多、錢不少,難度不大、口氣不小,我一聽心動了,原以為要賺一筆 easy money,后面再看看,這次外包踩了大大小小不少的坑,遂想好好記錄一下。

前期溝通

電話的第二天,和外包項目需求方簡單溝通后,他們發來十幾張 App 界面的樣例,大概是些軟硬件結合、通過 App 界面展示硬件信息和數據統計,以及相關信息的 CRUDDemo,功能不多不過開發時間也有限,要求在月底前做完 App Demo 與后台系統,趕着參加一個會議展示。對方多次強調項目的優勢:正處於風口、資源配置各方面都齊備,除了...沒有軟件技術團隊,目前只有硬件團隊,軟件這邊只有零星的兩三個,但不堪重用。

Tips:

這里我犯下了第一個錯誤,我以為只是一個Demo完事,但這背后是一個完整龐大的項目,項目大小、類型和復雜度的錯誤評估,使我沒有很好地把控全局和考慮整個項目的細節,導致后面引發了很多問題。

在評估一個項目時,我們通常會低估項目的復雜度,而高估自己處理某些瑣碎細節的能力。

組建團隊

項目要進行,一個人是搞不定的,因為涉及到 各端 App、Web以及后台,於是我首先找了一個靠譜的后台開發朋友,然后等項目快正式開始前,再一起尋找和確定其它小伙伴。

Tips:

外包合作過程中,優先找靠譜、技術扎實、有責任心的人,外包項目大多技術不復雜,但因為協作方式的特殊性,大多是異地異步辦公,需要有強烈責任心的人。不然項目開發時,經常找不到人,或者溝通缺乏反饋就很被動了。

項目報價

談到項目必然會談到錢,關於報價這塊,對方很開放的有兩種合作方式,一種是技術入股的形式,另一種是按照外包的方式報價。我想着因為是第一次合作,采用第二種方式最為保險,畢竟落袋為安嘛。

由於是第一次接外包沒有經驗,心里很忐忑,趕忙去網上查一些外包報價的方式和注意事項,最終決定根據團隊人員工作的日薪,乘以一個系數,報給了他們。不出所料,他們覺得貴了,整個合作就僵持在那里。介紹項目的朋友答應去斡旋,然后...沒了下文。

Tips:

不同外包項目的公司、項目背景不同,遇到技術入股這事得慎之又慎。當然現在外包平台很多,一切都基本流程化、正規化了,直接是項目與錢的交易,這種問題也會越來越少。

按照故事的正常節奏,我的外包初體驗夭折了。大概兩周后,事情出了轉機,對方的負責人打來電話說要當面溝通一下。然后技術負責人和老總一並趕了過來,扯了半天介紹了項目的背景、公司及技術團隊的情況,我意識到了這個項目不只是一個 Demo 這么簡單。最后約定另找時間詳細溝通需求,以及評估報價。

等到溝通完需求要報價的時候,對方想要一個打包價格,而不管每人每天的算法,又扯到這個項目很大,會分幾期開發交付,第一期想讓雙方以磨合的姿態來合作。意思是你們也別想着開高價了,我們第一次合作先便宜點,磨合一下摸摸底,覺得不錯的話后面合作再談。

因為我也是第一次接外包,缺乏經驗,在這個磨價的過程中,腦子一熱不小心就答應了對方的要求。等到協商完畢確定好報價,發現只有第一次給出的每人每天報價的一半,才意識到我們還是圖樣圖森破。

Tips:

這里是第二個錯誤,報價過程中要盡可能堅持自己的報價條件和底限,如果對方說出最低價格這種話,絕不能給出一個自以為的最低報價,不然就容易弄成菜市場的討價還價,最終會被磨的和自己預期差距很遠,可以跟對方認真溝通,談錢一定不能圖省事。價格貴也是質量的保證,可以象征性地少一些,但務必控制范圍。

簽訂合同

不管怎么說,既然給出了報價,本着學習漲姿勢的態度,咱就干吧。需要擬訂合同時,沒看到合適的,最終在網上找了一個軟件外包開發合同模板,大致改了一下,將就用着。

關於外包合同有很多需要注意的地方,這里就只簡單說一點:合同的條款一定要一條條地過,確保自己能完全掌握和理解每一條的內容及背后的含義,確保不要對自己埋有坑,當然也最好不要坑對方。

Tips:

當然現在外包行業發展越來越成熟,外包流程和項目也越來越規范,也誕生了像雲沃客這種成熟的眾包平台,甚至不再需要合作雙方私下簽訂協議,服務方和需求方都能把精力專注於項目上,而把背后的一些瑣碎之事和問題交由平台來規范管理,省心很多。

簽合同遠赴對方公司,中午正熱時坐了個順風車過去,下了車一看太陽都快下山了,高樓不見了,眼見之處都是低矮的民房,大爺大媽懶洋洋地支起了小吃攤,第一感覺是從深圳到縣城了。對方是一個傳統的公司/工廠,這意味着什么互聯網、軟件開發等等都可能是對牛彈琴,如果對方沒有一個專業懂行的對接人員,這個項目的進展將會非常艱難,后面的事情也正出乎我所料。

Tips:

盡可能詳細地了解對方公司、項目情況及相關人員背景,如果出現對接人員素質與項目不相符的情況,盡早向合作方提出疑問,把問題拋向對方,不要讓這種問題影響項目的進度和后續工作的開展。

合同簽完,需要再次詳細溝通需求和評估開發計划,我和團隊同伴遠赴對方公司開會。溝通需求的過程中對方少不了加需求,甚至是一個獨立的模塊,相當於工作量莫名就多了幾分之一。對方含糊其詞,說這是一個非常重要的模塊,沒有這個模塊就不是一個完整的系統,當初以為這是默認大家知道的事情雲雲。好在先前擬訂合同的時候,我把主要功能和相關模塊都寫在了合同的開發內容一款里面,趕忙把合同拿給對方看,對方啞口無言,后面繼續溝通是加時間、加人力還是精簡功能。

Tips:

擬訂合同時,一定要寫清楚開發內容和主要功能,盡可能詳細准確,避免后續因為添功能、改功能扯皮,畢竟口說無憑、白紙黑字才是硬道理。

項目開始

合同簽完,按照合同約定對方需要先支付 30% 的項目款作為一期款,因為這些都是明確寫到合同里,整個付款過程中很利索,唯一的問題是對方需要提供發票,后面找了朋友公司代開搞定。

軟件增值稅票稅點一般是 6%,稅費也會是一筆不小的支出。最好在報價時溝通好稅費及發票相關事宜。

Tips:

最好等到預付款 or 第一期項目款到賬后再啟動項目,避免不必要的麻煩。

報價時將稅費和發票考慮進去。現在眾包平台也大多解決了這個問題,用戶不必再操心這個。

項目准備

等到相關流程都走完,需要對方提供產品原型的時候,對方硬是石滾碾不出個屁來,憋了很久什么東西也提供不出來,我們艱難地跟他們普及了設計稿和原型稿的區別后,他們疑惑地表示:這種東西不是應該由你們來搞定嗎。只好邊跟他們說清楚,邊給對方提供幾個原型示例和原型工具。

回過頭看看,整個項目過程中對方除了給出一個非常粗糙的概念需求文檔,任何文檔輸出都沒有,在前面溝通需求時提出讓對方把相關需求文檔整理給我們,他們表示這種東西都在自己腦子里沒有時間整理。

沒有輸出的文檔,后續的工作便沒有了依據,而所有的依據,也只是在詳細溝通需求的時候,我們自己整理的需求列表文檔。

Tips:

文檔的輸出非常重要,詳細的需求文檔與設計文檔是后續項目開發中的必備利器,沒有這些,整個項目成了巧婦難為無米之炊,而且這些也會是項目開發完畢驗收的標准之一。

項目前期

項目還沒正式開始,對方又出幺蛾子了,對方對接人員由技術主管變更為另一個下級技術負責人,估計他們內部都沒有仔細溝通過,就直接讓我們和他對接,上來第一句便是找個時間溝通下需求,這邊不太清楚細節。拜托,細節都在你們老大那里了,求我們心理陰影面積...

所有的輸出文檔只有在我和第一任對接人溝通需求時,整理的需求列表文檔,這意味着它是經過第一任對接人陳述並由我們消化整理的,而第二任對接人如果再以它為參照的話,這里面的需求理解因人而異,項目變數更多、前景堪憂。想到這些,我們只好再次奔赴過去詳細溝通需求。

Tips:

項目對接人的變更算是一個意料之外的問題,也更顯前面所述的文檔的重要性。越快越早地形成詳細清晰的文檔直接決定了項目后續的走勢和進度。

在等原型的這段時間,風雨飄搖的項目又出了新紕漏:原本協商好的我們只需要負責軟件系統開發(包含各端 App、Web 管理系統、后台系統),對方負責硬件生產及硬件系統開發,后來他們硬件開發人員離職,想把硬件系統開發這一塊也交由我們。我們想都沒想,就直接拒絕了。

Tips:

盡管接下硬件這塊又有錢賺了,但這不是我們團隊的強項,需要另找專業人員,相當於給團隊和項目增加風險和不確定性。專注於做自己擅長的一面,不為團隊和項目累加風險和不確定性,也是一種責任心。

寫在最后

還沒寫到項目正式開始,就已經羅羅嗦嗦一大篇了,后續記錄一下項目開發過程中的坑和教訓,未完待續,歡迎交流。

本文出自 “13397554” 博客,轉載請與作者聯系!


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com