先，呵呵，一下，
大概預估了一下，兩個月20w，乙個月10w，基本就是乙個高階ios，乙個高階android，乙個高階後台，基本不靠譜。
【乙個方案】
從技術的角度，想到乙個比較折中比較靠譜的方案，歡迎討論，
1.需求分析&資料庫設計
這個是重點，就像大廈的地基，所以建議，花重金請高手給理清需求設計好資料庫
3.後台**
這個不是重點，當資料庫設計好後，找個**生成器，生成基礎**，找個中級後台，花時間堆出業務**，
只要不涉及一些技術難點，只是時間問題。
6.成本分析
固定開支：需求分析&資料庫設計&ui設計
開發人員：乙個中級後台+乙個中級前端（hpp開發）
三方服務：配合三方免費服務，可以節省一大筆開始
【和高手配合的快感】
有幸和各方面的高手有過配合，確實有快感，事半功倍，溝通沒障礙，做完不返工，
1.高階架構，某cto
甲方外包了乙個專案，結果還剩乙個月的時候，外包說做不出來，然後找到我們公司，
乙個月，爛攤子，可想而知大家都不看好，都不抱什麼希望，
恰好這個時候，副總裁拉過來乙個cto，拉我們一幫人去封閉乙個月，
當時一起開會，讓各自說這個專案怎麼設計，
當時剛畢業，聽完需求後，一團亂，真覺得這是不可能的任務，直到專案交付的時候也沒明白怎麼執行，
後來跟著實施了一段時間，才明白整個過程，
簡單的就是，這位高階架構，從需求方不清不楚的需求中理出來兩個系統，相互配合，
不但想明白了需求方當時的需求，而且想明白了兩年後需求方會新增哪些需求，
之後兩年內，需求方提需求，架構不需要改，**稍微改改，
贊乙個，學到了很多，
需求分析，資料庫設計很重要，大廈的地基，做的好，以後沒有後顧之憂，
舉乙個反例，
在這個高階架構還沒來的時候，三個專案經理級別帶我們幾個小弟，也是去封閉，也是從頭開發乙個系統，
最終也勉強做出來了，但是後期碰到的問題很多，
資料庫設計不規範，不得不經常修改表，
有些需求沒辦法滿足，總要繞過來繞過去才能實現，
**各種堆，各種複製貼上，著實恐怖。
ps，需求分析，資料庫設計很重要，多花點錢找個靠譜的架構幫忙吧。
扯這麼遠，感官體驗下，使用者看到以下兩個登入頁面的心情：
ps，設計真的很重要，多花點錢找個靠譜的設計幫忙吧，另，定稿不要再改了。
【如何識別技術型技術人員】
創業初期，有個難點，容易被忽視，但是很重要，
就是當你非技術背景，或者沒有靠譜的技術合夥人的時候，如果想招技術人員，你怎麼判斷他是高手，
前提是你已經認為招技術高手很重要了，
市面上太多傳統企業轉型，太多非技術創業，也太多大公司鍍金比較能吹其實很水的所謂高手了，
請到這樣乙個高手，以前覺得無所謂，後來（身邊例項）覺得完全可以毀掉乙個企業，慎之，慎之，
那麼怎麼判斷呢，
看文憑？看公司背景？看以前的專案？聽他自己吹？做背調？
這些都不靠譜，最靠譜的是找乙個高階和他配合一兩天，高下立現，
是不是死迴圈了。。稍等，
等到下一階段，再優化重視後台為時不晚。
如何快速開發出乙個高質量的APP 創業談
先，呵呵，一下，大概預估了一下，兩個月20w，乙個月10w，基本就是乙個高階ios，乙個高階android，乙個高階後台，基本不靠譜。這樣問還算比較靠譜，如果是 我有乙個想法，就差乙個程式設計師 那就呵呵了。2.預算有限，不管外包還是自己組建團隊貌似都不靠譜 3.期限很緊，不能按部就班的去做 4.並...
如何評估乙個類是否是高質量的？
你是否把程式中的類都看做是抽象資料型別了？是否從這個角度評估了它們的介面了？類是否有乙個中心目的？類的命名是否恰當？其名字是否表達了其中心目的？類的介面是否展現了一致的抽象？類的介面是否足夠抽象，使你能不必考慮它是如何實現其服務的？你能把類看作是黑盒了嗎？類提供的服務是否完整，能讓其他類無須動用其內...
如何組織乙個高質量的解決方案 PROPOSAL
proposal，解決方案建議書，是一切專案的起點。銷售能力是現網際網路時代非常重要的能力，而乙個好的proposal是能否贏得目標群體，決策層的信任，獲得行動機會的重要載體。凱哥在過去的近二十年的諮詢實施過程中，包裝了眾多跨行業的解決方案並勝出。proposal的包裝不僅適用於投標，專案領域，同時...