不懂技術，一個好的想法如何讓他實現？

常常聽到不少人說「我有一個很好的idea」，就差一個技術合夥人了。下面就產品的整個服務流程給不懂技術的創業者分享一下一款好的產品的打造流程。程序員客棧3.0昨日剛剛上線，仍是以遠程工做爲切入點，作互聯網企業的技術遠程中心，作好程序員的經紀人，爲程序員和需求方服務，特別是此次3.0版本的短時間僱傭服務，完全解決產品需求方和程序員的溝通障礙，讓程序員駐場到企業提供服務，完美解決項目開發過程當中可能遇到的問題。

　　一個項目的開發流程通常是『想法』『原型』『設計』『開發』『測試』。

　　通常剛開始創業的人，沒有產品研發經驗的公司負責人，他們提供的word、ppt都是屬於『想法』，不管描述再詳細再怎麼高大上都屬於想法。不少這樣的創始人或者產品負責人，就這樣拿着本身的『想法』滿世界的去找人作開發，就差一個靠譜程序員了，一些程序員自誇技術能力好，樂呵呵的接了項目，而後就是項目爛尾了。程序員客棧剛開始作外包分發也嚴重面臨這個問題。以前一直搞不明白爲何會這樣，如今才慢慢想清楚就是由於項目沒有流程，介入的人越多結果越亂。項目一開始定位模糊，沒有原型就找設計，沒有靜態設計和流程圖就直接作開發，開發想趕進度就增長人手，開發完成不留文檔擺出不再想管了姿態。大家感覺下，這些都是很是糟糕的作法，這樣折騰產品質量能好纔怪。作產品搞開發毫不是找包工頭建房子的那種野路子。

　　因此能作好產品必定須要對『想法』『原型』『設計』『開發』『測試』這個流程有深入的認知和實踐。即便不徹底按這個來，也要有相似的本身有效的套路，保證產品模塊化有流程可依。要知道如今的產品開發絕大多數不是一我的能作完的，因此團結協同這麼多人作開發，須要流程和進度規劃兩手抓。這樣才能保證項目質量，作出優秀的產品。下面就對以上咱們理解的每一個流程以及下一個流程的啓動條件作一個簡單說明，讓你們有個總體的即視感。

　　『想法』

　　所謂想法就是一切的口頭描述、會議溝通、word ppt excel文字描述。不管描述得多麼詳細，講的多麼讓你懂，都只是屬於想法。以前和一些非技術行業要跨界到互聯網的老闆溝通時，他們常常這樣描述本身的產品：對，這裏就是和微信同樣。吧啦吧啦，你懂了沒？沒懂是吧，要不我再給你講一遍。而後程序員竟然就懵懵懂懂的懂了，接着就去悲劇的搞開發了。當我走訪到不少創業團隊也正在這樣操做時，瞬間整我的都很差了好嗎。千萬不要相信一個處於『想法』階段的產品經過不斷的多講幾遍能變成『原型』，即便你聽懂了，那也不叫原型。其實咱們知道程序員內心苦，只是程序員不說。

　　那又爲何，不少企業的官方網站交給豬八戒、地方建站團隊、甚至老師學生團隊也能作好呢？他們也沒有什麼流程。你必定要相信，豬八戒、地方通常的建站公司也只能作好企業展現網站了（或者修改代理軟件）。由於這一塊是比較標準化的東西，一個後臺，成百上千種前端風格，足以知足你的各類需求。而須要改造世界的偉大創業者，就不要把本身的產品寄託在這樣的公司平臺了，仍是本身搭團隊作產品靠譜。互聯網企業產品是核心，核心都外包了，你還作什麼啊。重要的是外包基本都是爛尾的，這卻是很現實的有木有。

　　『原型』

　　原型是對『想法』的中流程、產品佈局等的詳細描述。通常的原型圖能夠用Axure、Sketch或者如今新出來的一些移動原型工具來畫。畫出來基本就能看到產品什麼樣子了。從『想法』到『原型』這是產品經理須要作的事情，他要理順產品邏輯，找到重點，創建流程。因此不要逢人就說：咱們沒有產品經理，我本身就是產品經理，即便你必定要是產品經理相信也遠遠沒有那樣的專業內涵深沉。在這個大衆創業萬衆創新的時代，一些很草莽原始的開發團隊中，若是有一個很是能被折騰設計師，固然也是能夠不須要原型的，直接把想法告訴給設計師好了，這樣好炫酷有木有，而後作幾個版本挑一個，巨大的溝通成本加上不斷的修改，也是能作出來，起碼產品外表好看了。爲了更好的理解『原型』是什麼玩意，這裏挑了程序員客棧（www.proginn.com）的原型放出來給看看

     『設計』

　　有了原型，後面纔是『設計』。不要原型就能一鼓作氣設計好一款產品的設計師不必定是好設計師。固然你也能夠認爲，牛逼的設計師不須要原型，就像牛逼的程序員不須要設計同樣：某個大學導師的學生可牛了，他一我的能把全部的作完，是牛飛起來的全棧工程師，吧啦吧啦，你就信吧。『設計』部分就是咱們能看到的產品外觀了。交付給程序員的『設計』不只包含「視覺」，還有「源文件」、「標註」和「切圖」。設計能夠分得更細，就像有UI了，還能夠有UE（用戶體驗）。好的設計師能在設計中能照顧到UE，看你產品設計須要深刻的程度了。

　　『開發』

　　前面搞了這麼久，終於輪到程序員上場了，這裏的重點就是須要找到靠譜程序員，程序員水平不同，開發出來的東西就是一個天上一個地下，靠譜程序員和不靠譜程序員氣質水平差得不是一星半點。必定不要期望一個菜鳥程序員能完美的按照靜態設計把產品完美的作出來，他會告訴你一些普通功能的各類不可能實現的緣由。拿到靜態設計圖和原型，後端程序員就能夠設計架構開發後端（這又是一個尤爲重要並深刻的方向，這裏就不深刻了），前端程序員（web、iOS、Android）再根據後端接口和靜態設計快速開發出來產品。中間的具體疑惑隨時找產品經理，進度問題項目經理負責。通常一些團隊會有本身的進度前後原則。好比：原型先出來，再是作設計和後端，設計和後端領先前端開發一週左右。這樣配合起來，一個好的產品模塊化的一步步的完成，而後就走完了產品中最重要的開發環節。

　　『測試』

　　好啦！產品終於作完了，程序員commit了最後部分的代碼，而後給你說：咱們作好了。這個叫作內測版，因此是不能發佈用的。產品只有通過嚴格的測試，單元測試，公測後才能上線。千萬不要相信一個程序員說：「我作的開發不須要測試」，即便他再牛。固然我相信一些好的程序員在開發的過程當中不多留坑，而且邊開發邊寫測試，因此作出來產品質量很高，可是這樣的產品也是須要測試的，由於bug無處不在。咱們須要理解產品不正常是正常狀態。因此才須要「運維工做師」嘛，這種職業的存在也讓一些非互聯網行業的人沒法理解。我賣你一套軟件和系統，還給你配我的維護，那就說明產品開發出來就是爲出問題作好準備的了。

　　最後提醒下，以上過程當中必定要知道程序員的水平高低以及他們的習慣都足以影響你的產品質量，甚至生死。這裏給那些開發不作版本管理，代碼就放程序員本身電腦上；接口文檔word提供，沒有版本控制；產品不按模塊化開發；沒有產品經理和設計，產品開發程序員就按創始人口述；沒有任何服務器備份機制...寫不下去了，大家感覺下。這樣的作法遲到要掉大坑裏的，沒有爲何！若是大家必定要抱着僥倖心理，不kao慮各類意外來開發產品，那也是能夠的，兵法有說「勝可知而不可爲」。就是長期的勝利必定是創建在排除各類失敗緣由的基礎上的，而後等待勝利的機會。

　　通過以上一步步的努力，而後你的產品就能夠上線了，普大喜奔~~~燒香求保佑無bug，而後小宇宙爆發~~~一切都交給運營汪吧。