程序猿看產品開發

在接近三年的開發生涯中，作過了很多項目，但發現我的能力的成長上確沒有達到本身所指望的程度。不能說本身不夠努力，細細想來，天天都處於忙碌的狀態。可是是否處於一個高效的工做狀態，在開發中處於良性的循環？在產品開發的過程當中，注重的僅僅是完成開發任務，仍是關注產品的性能、架構以及代碼的質量？在這些方面，就作的至關差勁了。

固然，做爲程序員，這些方面都是咱們應該關注的，畢竟這對我的的職業發展是至關重要的。但這只是個空口的但願（這句有點奇怪），如今的互聯網行業中，產品的開發是處於快速迭代的時期，需求的不斷改動對開發工做帶來很大的影響，使咱們的效率大打折扣。怎樣使產品開發更加高效，質量更高，同時保證程序員對產品實現有着更深刻的思考？ 這即是做者思考嘗試解決的問題，應該從如下幾個方面作起：

1. 流程劃分

清晰流程，詳細的交互設計文檔以及後臺接口基本提供完善，纔可進入App開發的階段。咱們在App開發的開始，是須要針對設計交互文檔確認過，細至每一個細節的交互都瞭解；開發過程當中，可能產生的一些交互問題，都應該在交互文檔詳細地體現出來，作到一切有跡可循。程序員在開發過程當中再也不有模糊的交互，再也不有口頭上的交流，是咱們在文檔最終定稿應該達到的理想效果。需明白，在開發過程當中，口頭交流來肯定交互的實現，對開發效率都是大打折扣的，出了問題，咱們都是無法責任到人的。

這樣，就要求在前期設計交互文檔的人員的責任比較重，須要針對每一個細節的實現都要考慮清楚，產品經理在對一個新的迭代的開發的同時，須要明確說起到這個迭代中的會涉及到的交互的實現。人無完人，不能各個層面都涉及到，因此在這個期間，可讓程序員加入來討論，畢竟最後的實現是須要程序員來完成的嘛，有問題的過程再肯定從新造成方案，必要的時候，能夠給與程序員必定的調研時間，固然考慮地越多，意味着咱們的工做將可以更加地明確。

清晰地能夠看出一個版本的開發將會有兩個階段，階段一 需求的定義造成設計文檔，主要角色有產品經理、產品設計、產品交互； 階段二 程序員進入開發階段最後交付完整的產品。此時，咱們可讓下一個版本跟當前版本作一個簡單的交錯，即在階段二中，產品進入下一個版本的的需求設計階段，藉此來並行地保證各個部門的高效工做。

雖然看起來在操做過程當中，可能會遇到不可料想的麻煩，畢竟沒有一成不變地需求，這樣就須要產品經理權衡，儘可能將這些需求放在下個版本中，將是最好的方式。否則交錯地流程開發，帶來更多的是開發成本的上升，產品的迭代週期的延長。

2. 規範定義

界面設計、接口設計、App設計定義一些通用的規範。

• 接口設計須要對返回的數據進行統一格式。譬如：統一返回的是 JsonObject，其中包裝成功狀態result 以及錯誤的信息，真正的數據則統一放置在 data 字段中進行處理。

• 界面設計遵循設計規範。 Android 能夠選擇 Material Design，蘋果也有本身的設計規範。如果不採用這些，則須要對一些通用的樣式，作些統必定義，譬如常有的間距，彈出框樣式，經常使用的顏色值，字體大小等等。這樣客戶端也可針對這些定義，遇到的時候則可直接使用。

• App開發的規範。統一的命名、格式化文件標準、儘可能清晰的處理邏輯、類文件編寫。

定義規範，即多作約定，最直接的好處就是：多人員協做可以有一套的標準，不至於雜亂無章。

3. 角色明確

這一點在小公司可能不太清晰，常常出現一人兼多職的狀況，不太好定義。在成熟公司，這一點是至關重要的，由於角色到人，使得咱們能夠精確到單一問題該有何人負責。如果一個團隊中出現職責不清晰的狀況，使得咱們解決一個問題便會出現踢雪球的狀況，問題得不到解決，雪球還有變大的可能。

4. 產品至上

產品是最最最重要的。最終的成果都是拿產品來講話的，即便再牛逼的銷售團隊，再漂亮的設計到產品上，也經不住產品的不斷閃退，卡頓，高耗電，不人性化。而這最終的成果的展現都是在程序員身上，產品的優化又是一個任重道遠的過程，畢竟你產品經理還要加功能。因此應該以程序員的工做爲主，API設計以及UI團隊應配合甚至服務於程序員的工做，儘可能保證程序員可以高效地工做。遇到過App展現一個界面，要發送三個甚至更多的API請求，只想說真是夠了。因此這裏應當簡化App端的工做，能儘可能少在客戶端作的就少作，服務器端的改動確定比客戶端來的容易些。

總結

做者是站在一個程序員的角度上，以及要不斷迭代地去開發一款長週期的產品，來看待產品開發應該具備一個怎樣正確的姿式的，歡迎來拍磚討論。固然，若是你就只是想快速開發出一款產品，那我上面的都是瞎扯淡了。。