互聯網時代，分工非常細緻，靠一個人的力量很難成事。在團隊沒有UI和測試的情況下，產品和開發更應該統一戰線，攜手解決問題。
前段時間看到很多小伙伴在群里討論，由於特殊時期，公司預算縮水，所以有的把UI省去，有的把測試省去，以此來節約成本壓力。
看到有位同學說其實這沒啥，因為自己所在的公司目前除了產品經理和程序員外，沒有UI和測試，很多人都對此很好奇，其實這在很多公司很常見。
01
由移動互聯網的迅速發展帶來了互聯網行業崗位的細分，原本的鏈條順序是產品-UI-開發-測試-上線，而有的公司如果是內部員工使用的產品往往會省去UI，以能用為主。外加內部用戶容錯率通常比較高，所以從成本考慮可能不會單獨招個測試人員，因為普通的測試很多角色都能做。
兩年前的那波所謂寒冬，一個之前同事就說他們公司已經把測試優化掉了，所以這項工作自然就落到了產品經理的身上。
正常來說，產品經理可能是最熟悉這個產品的人，所以常規測試階段也會由產品經理做一些覆核，而從節省成本，同時沒有太多用戶壓力的情況下，測試很容易被替代。
02
沒有測試或者UI對公司來說是節省了成本，可對產品經理自身而言則是被拽去了更多精力。比如我之前帶過一條產品線，麻雀雖小，五臟俱全，產品設計完成後，UI出圖，測試則準備測試用例，開發進行技術搭建。
開發到可以測試的階段，UI負責驗收交互和樣式，測試負責驗收功能和需求，產品也會隨機測一測，然後統一到測試那邊進行修複跟進。
所以開發後期直到上線前，產品經理已經能差不多抽出身來去思考新的產品內容，而不必陷在開發和bug解決的跟進上。
因此，公司崗位的缺失有利也有弊，雖然職責不全會讓產品經理一人乾三人的活兒，但同時也讓產品經理陷入到瑣碎里難以有更多精力規劃大局。
03
作坊式的開發不規範，但卻一直存在。其實沒有UI和測試的團隊我也經歷過，這個時期如果團隊價值觀不統一就會引發很多問題，比如產品經理和開發的矛盾。沒有了UI去畫頁面以及覆核樣式，沒有了測試去驗證bug的修複，所有這些都是產品經理一人多擔，所以開發會覺得可能是產品要求太高，故意為難。
現在回想這個階段，每次開發說可以測試時，我打開頁面內心都會有巨大落差，是的，是巨大。
對於樣式問題，完整的流程是產品-UI-前端，沒有UI，所以既需要產品往下做一步也需要前端往上做一步，共同把UI方面補全。
比如產品經理需要把原型做得高保真一些，而開發沒有現成的東西可用，就需要自己找一些控件並且細調樣式問題。
很多時候樣式問題開發不願意改嫌麻煩，但正如那句話所說，沒有人願意通過醜陋的外在去瞭解你的內涵，既然有達到優秀的實力，就不要設定止步及格的預期。
04
除了樣式和測試之外，比較常見的還有開發過程中對需求的遺漏，比如開發完後的產品，常常會發現很多需求細節的遺漏，對照需求文檔發現很多漏掉的內容，這就說明開發沒有逐步對照自檢。我個人比較不能同意“明明知道這個問題存在但就是不想改，等用的過程中被用戶發現然後吐槽”。如果是產品思考層面的缺陷被吐槽我可以接受，但由於不自律所產生的問題我不能接受。
很多時候如果研發過程中嚴格按照需求文檔去做，問題出現的數量會少一半，而沒按需求去做的結果就是測試問題增多，修複時間變長，開發完再改動使得修複更複雜，從而整體時間拖長。
對於產品和開發的關係，有人戲謔是天敵，但我覺得應該從不同的角度去看。產品不能沒有開發，否則就是一堆圖紙，開發也不能沒有產品，否則難以發揮效用。
產品從各處調研來的需求形成產品設計，不能開發的時候打點折扣，修複bug的時候打點折扣，最終都沒達到產品的預期，更別說超越用戶期待了，相反，產品要通過開發賦予生命力，形成可用好用並且超越預期滿足需求的產品，對用戶產生切實的價值。
產品和開發，可以相輔相成，但不相愛相殺。
一起加油，共勉！
#專欄作家#
慕斯姑娘，微信號：musiguniang，公眾號：產品那些年，人人都是產品經理專欄作家。關註金融科技和大數據領域，擅長產品規劃和落地。
本文原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議