深圳APP開發公司需要敏捷開發嗎

深圳APP開發公司、軟件外包公司等等，都是以接項目的形式開發一個又一個項目，那么，敏捷開發適合APP開發公司、外包公司嗎？

敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對于“非敏捷”，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的作用。
在一個APP開發公司里，團隊還在生死線上奔波的時候，敏捷究竟帶給了我們什么。

市場的拓展要求的是客戶合作的精神，但是在合同談判的環節里，又得考慮很多自身利益的因素，敏捷宣言中強調了客戶合作 over 合同談判，可是現實之中，不得不去平衡這兩邊的關系。舉幾個簡單的場景，合同還沒簽署，客戶希望你能幫他們一起整理產品需求文檔；客戶撕毀合同，不履行合同條款，同時希望你可以理解；客戶在合同范圍之外提了一些需求，希望你可以滿足；從服務客戶的角度上來說，好像我們都應該想辦法滿足他們，但是回歸到自身，如果不懂得拒絕和選擇，結果只能是把自己累死。

很多時候我們誤以為客戶合作就是滿足客戶的一切需要，想辦法為客戶提供價值，可是往往卻發現，客戶也未必就是那個全知全能的上帝，堅持自我有時候往往會顯得更重要，客戶合作不是一味的遷就，也不是在任何時候去討好每一個人，理解客戶內心的愿望，然后找到一個可以使雙方都獲得收益的方案，用你的專業和影響力來引導客戶，以達成與客戶的合作。

市場中的外包合同，幾乎都以固定價格為主，對需求和時間都有了嚴格的限定，這也導致了傳統的外包項目多半都是以瀑布的模式進行管理，而我們則在固定價格合同的基礎之上，嘗試了一些新的交付模式和合作方法，把迭代的概念引入到外包項目的交付中，同時通過把一個合同分拆成多個小合同的方式，基本保證每個合同的交付時間不超過一個月，以此來實現對客戶需求變化的積極響應。

 

案例一：

2016年中，在和一個客戶進行了兩周的溝通之后，完成了合同的簽署，當我們在組織人員，準備進行交付的時間里，卻發現客戶的首款遲遲沒有到賬，大約在我和客戶繼續溝通了幾次之后，客戶的聯系人和我溝通，表示老板另外選擇了一家供應商，因此想終止和我們的合同，但是卻不想承擔合同里的違約責任，這件事情在后續的交涉過程中顯得異常艱難，而且最后我們也沒有收到違約款，事情也就此告一段落。

在隨后的過程中我自己也一直在反思，我們一直在提倡客戶合作，但是客戶并不僅僅只是你所對接的那個聯系人，一個企業客戶里有各類各樣的人，不同的人掌握了不同的話語權，也有不同的訴求，正如我們交涉的客戶，和我對接的聯系人很信任我們，希望由我們完成他們的軟件交付，但是客戶的老板卻希望以更低的價格來購買一套現成的系統。

當客戶并不是一個抽象的概念，而是一個個實際的個體的時候，客戶合作并不僅僅是給他們交付價值，而是需要了解客戶中每一個個體的訴求。

 

案例二：

今年年初在溝通的一個項目，客戶方是一個大公司里孵化的早期創業項目，產品還沒有上線，前前后后溝通了五六次，過程中我發現，每當我拿出一版原型的時候，總會激發出他新的想法，并且希望加入到原型和設計之中，這樣的場景想必很常見，如果接收客戶的想法，那么帶來了便是項目工期的延長，如果拒絕，則可能失去這個單子。在贏單和輸單的風險之中，我們平衡了很久，最終冒著風險，去和客戶溝通把項目做成多期的意向，因為我們不希望把一個可以兩個月快速交付的項目，變成一個半年的龐大的怪物。

在與客戶的溝通過程中，我們盡力的以快速迭代和交付價值所帶來的優勢進行解釋，并幫助客戶梳理了核心的業務流程和應該在早期建設的內容。在過程中我發現，當你在一個領域表現的專業的時候，你可以通過你的專業來贏得客戶的信任，并引導他們同意你的請求，很多時候客戶合作并不是一味的討好和遷就，而是給予你所在領域的幫助。

 

研發&交付

在敏捷中，最為適用的便是研發和交付的環節，一套完整的Scrum框架基本可以適應大部分的實際工作場景，我們嘗試過兩周的迭代、也試驗過一周的迭代，不管哪種方式，其本質的核心是用戶價值的交付，用更貼切的話來說，便是滿足當下客戶場景的可工作軟件。

很多時候，產品做成什么樣子往往是由產品經理來把控的，在敏捷中，我們經常會提到用戶價值，但是卻沒有人會解釋用戶價值到底是什么，很多時候，用戶嘴上說的很多時候未必是他真正想要的內容，“我們要做一個APP”可能只是老板開會時提到的一句話；“這個產品一定要功能強大”可能只是為了做出一些政績給老板看；“我們要做一個電商平臺”可能是因為公司剛剛投資了一個這樣的項目，當你真正了解了客戶需要的背后的上下文以后，你才知道用戶價值的本質是“用戶內心的渴望”，是內心深處的“我要…”。這個渴望可能是做好他的本職工作，可能是維護自己在公司的地位，可能是配合公司的戰略發展，當了解到用戶背后的愿望時，你才知道如何正確的幫助他實現最大的價值。

 

再聊聊看板，之前一直使用leangoo進行團隊的任務管理，但是發現大家除了同步一些文件以外都不愿意登陸，而當產品文檔比較少的時候，一個QQ群的文件共享就幾乎已經搞定了，于是在痛苦和糾結之中我猶豫了一段時間，終究還是順從了團隊的想法，選擇他們認為合適的工具去完成合適的工作就好。

 

有人會說，你們沒有站會、沒有看板、也沒有各種meeting，那還能算是敏捷么？我只能說，我們只是選擇了那些我們適用的流程和工具，而把更多的時間交給了頻繁的溝通與軟件的開發。

 

敏捷的核心是四句宣言：

個體和交互 over 流程和工具 。

可工作的軟件 over 面面俱到的文檔 。

客戶合作 over 合同談判 。

響應變化 over 遵循計劃 。

 

在敏捷宣言的基礎之上，我總結了一些更具體的內容：

 

個體和交互

客戶的訴求和客戶負責人的訴求很可能會不一樣。

 

了解客戶、市場、銷售、運營、研發、產品、設計、測試、財務的種種術語和他們思維的邏輯，對彼此領域的了解是建立良好溝通的基礎。

 

客戶合作

了解你的客戶內心真正的訴求，和他們做朋友。

堅持自己的立場，而不是被客戶牽著走。

平衡客戶和自己的利益，共贏才能持久。

 

響應變化

以迭代的方式快速交付產出。

頻繁的和每一個人溝通，了解他們的近況和思想的變化。

預先識別出一些會導致變化的風險，提前準備一些預案，別總想著見招拆招。

 

在小型的深圳APP開發創業團隊中，項目管理的過程幾乎無法以Scrum所設計的那樣順利進行，而場景的擴充和復雜化，導致很多時候我們不得不游離在Scrum之外，這時候唯一可以繼續指引著我們進行決策的，而與此同時，我們也不斷的調整自己的工作模式，以適應新的環境帶來的種種問題，樹木是自然生長出來的，而不是設計出來的，而最好的團隊也同樣如此。