這篇文章 算是我在2015年的一個小結，2015年的經歷，是我過去工作5年的一個縮影，但是給我自己接帶來的思考缺遠遠大於過去5年。

在專案開發的過程中，

首先了解業務需求，在網際網路公司，對業務需求的理解提出了更多的要求，不僅僅是要了解要做什麼，更要關注為什麼做這個，能夠給客戶帶來什麼？客戶的真實的需求目的是什麼？客戶在使用功能的過程中，最關注什麼？

在業務實現過程中，

關注程式碼質量，單元測試。在編碼的過程中，加入codereview活動，提交程式碼時結對review。 這些活動，才是真正能夠提升產品質量的措施。

在之前的開發經歷中，個人比較偏重往前衝，完成更多的功能，讓更多的功能上線。這樣的思路，往往會導致問題多，並完全依賴開發的個人的素質，如果遇到一個開發能力不好的開發，往往提交的程式碼質量是不好的。

假定一個開發人員，具備編寫完整的單元測試的能力，那麼這樣開發出來的產品，是質量可靠的，並可以不需要測試來驗證功能。可以讓產品來體驗功能。

開發人員自身，在理解功能以後，編寫對應的單元測試用例，不僅能夠保證高質量的產品交付，同時也能夠有單元測試的積累。

單元測試，更多的帶來的是，長期的質量上的提升，同時也有益於程式碼的設計。

存在的疑問：在傳統公司裡，可以招聘一個開發，一個測試，花一個開發週期，一個測試周期來完成工作，但是，是不是可以招兩個開發，在兩個週期裡，完成這一個功能呢？產出更有效的產品。國外的很多公司都是這種模式，而且一個開發本身應該為自己的產出的質量負責，並不是寫完了，就交給測試。

在管理上，

技術管理，在大的專案上，我都會關注，發現其中的技術難點，詢問開發的想法，並提出自己的設計想法。最終執行開發。通常，一般的小的設計，都不會有太多的技術難點，所以我也忽視了這個問題。而開發人員的開發能力也遠未達到真正的工程師的開發水平。一味的在考慮趕進度，上了許多的功能，但是卻招致了很多的埋怨和指責。

總體上我們也是採用的Scrum方式，日常的開發工作包括以下幾種，

• 業務功能的分解
  • 這裡分解的粒度比較的重要，一個crud，基本可以作為一個功能點，一個技術難點，一個互動的介面。都需要拆分為單個的功能。
• 工作任務的分配
  • 在敏捷開發裡，這一點，是需要開發人員自己來選擇的，如果執行下去，好處是很明顯的。能夠提升開發人員的積極性。但是，目前來看，我們這個方式並不能取得好的成果。
  • 通常，我都會根據每個人的特點來安排任務，後臺的系統多，功能雜，我按照系統，劃分了系統的owner，按照人員特點，結成了編碼的pair，後期的專案質量提升明顯。
• 評估工作量並制定開發排期
  • 這裡需要考慮開發的能力，功能的難度，在結合測試的時間，如果你是開發leader，並且期望開發能夠交付高質量的產品，在這裡你需要預留出足夠的時間，讓開發能夠完成工作。
  • 如果你是專案經理，那麼，你需要儘量爭取多的時間來完成，當然，通常都不會給你太多時間，網際網路時間比拼的就是時間。誰最早上線功能，誰就能夠佔到先機。那麼在時間緊張的情況下，該怎麼辦？砍需求，這個就看你撕逼的本事了。這點上，我是做的比較弱，之前被灌輸的一個觀點是努力工作，覺得與人撕逼就是浪費時間，而事實上，甚至產品經理也會覺得需要開發多動腦筋來參與，而不僅僅只是編碼實現。
  • 其次，在開發的工作量已經比較飽和的情況下，不要著急去增加工作，或者加班完成什麼功能。往往有些需求，並不是很著急上的，只是產品YY了一下，覺得需求很急。在我們業務系統剛開始的時候，有一個業務功能，產品說很急，一定要上，但是由於開發沒時間，這個功能過了8個月了，還是沒上線，你覺得是一個重要的需求嗎？
  • 總之，在這個階段，你需要爭取足夠的時間。
• 每天瞭解開發進度 站立會議
  • 在任務安排好以後，每天都需要更新進度，最好有一個由開發自己來更新，就可以避免開發人員不給力。
  • 早上的站會，是互相瞭解彼此的工作內容的過程。在開早會的過程中，很多人都只關心自己的事，說完了就無所事事。實際早會也是一個提升自己的機會，有的人會說自己遇到的問題，和解決辦法。積極主動的人，就會提出自己的想法，提升自己在組內的影響力。
• 討論和跟進各種具體的技術問題
  • 在一般的業務需求層面，不太會有太多需要設計的內容，尤其是在專案搭建完成以後。大部分的開發都已經知道怎麼去使用redis，sql，mongo等。一般的開發最擅長的就是定義service，dao，需要和其他模組互動的地方，發個MQ訊息，或者是直接的RPC呼叫。在這個框架下面寫程式碼，不在考驗開發的設計能力，而只是業務的編碼實現能力，需要真正參與設計的地方並不多。
  • 然而，在一個不成熟的團隊裡，卻是不斷的需要了解他們的實現方案，否則極有可能做出一個上線就OOM，或者不能處理大量請求的功能。 這也是普通開發人員和高階開發人員的差別。 網際網路產品，遇到最多的是高併發的大量請求，一般的開發人員沒有經驗就容易犯錯。
• 協調一些產品需求變更
  • 我經常跟產品說，有需求變更不要緊，沒有人會一次就考慮到所有的功能。但是，剛好是這樣思維，讓我自己沒有去追求完美。我原來是一個追求完美的人，弄的別人會緊張，尤其是家裡人。後來放棄自己追求完美的個性，這個思維放到了工作中，卻讓我自己吃虧。
  • 我之前一直覺得，好的開發，應該在開發的過程中設計一個可擴充套件的架構，以方便後續產品的變動。但是，換到產品的角度想，他們卻希望，每個人都給他們提建議，這樣，他們做出的產品才會好用。換成你，可能也一樣。在需求一開始，就應該仔細的參與討論，讓產品需求能夠儘可能打磨精細。讓開發在後期的改動儘量少。
  • 但是變動總會有，我通常只會去協調他們找對應的開發。需求的變動，我並不總會去關心，有大的需求變化，開發自己也會跳出來說。
• 跟進相關功能上線
  • 功能完成上線後，在線上環境可能會出現一些問題，
  • 一些未覆蓋到的場景，由於提供的介面被多個模組呼叫，可能會出現一些問題。
  • 當這些線上問題出現後，開發人員需要迅速的定位。這個是比較考驗開發人員的技術能力的。

作為一個網際網路公司的技術團隊，我們應該還有能力直接響應市場、運營、客服或其他部門同事的業務需求。

因為產品部門有時考慮的只是怎麼來增加新功能，會忽視來自其他部門的真實的實時的需求。因為有些需求，在他們看來是不重要的。這個和組織結構相關，如果產品和技術是兩個獨立的部門，產品只關注產品部門自己的績效，並不一定需要實時的來響應其他部門的需求。

而技術，則並不應該期望自己只成為一個執行部門，需要擴充套件技術的影響力，這種情況下，積極的去主動了解其他部門的需求，並主動的改進到工作中。不要成為一個Code Machine。