我在微博上丟擲了乙個問題：敏捷開發，在沒有專案經理的前提下，如何協調產品經理、互動設計師、開發工程師在乙個需求或互動上的不同看法？得到了好友們的關注，現在在這裡做乙個小結。
移動應用開發團隊，共有以下五種角色：
在這樣的團隊中，經常會遇到如下情況：
pm定義了產品需求，出發點自然是滿足使用者在特定場景下的功能需要，希望功能明確，操作方便，簡捷易用。
然後ue進行了互設計，作為設計的產物，雖然也會本著簡單清晰的思路，但往往又會加入一些純的「設計」因素，比如乙個滑動的操作，乙個漂亮的動效等等。
當pm和ue在一起碰設計方案時，pm會意識到額外新增的設計元素不太符合當初的設想，但又沒有充分的理由能說服ue，畢竟ue在這方面是專家，是經過「設計」的，會有一堆顏色理論、使用者心理、體驗資料來支撐他的觀點，所以經過pm和ue的討論以後形成的結論，實際上是二者平衡後的產物，某些設計元素還是會被保留下來。
然後，正式的評審會開始了，參會的有pm、ue、rd、ui、qa。pm和ue要把需求和互動給大家講清楚，然後大家反饋問題，最後確定乙個可供rd編碼、ui構圖和qa測試的依據。在這個會上，pm和ue之前平衡後的方案往往還是會被大家提出各種意見。顯然，與pm和ue的討論如出一轍，rd、ui、qa這三個角色也無力削減或過多的調整ue的方案，原來pm可能還會寄希望於大家一起評審時能把不太理想的地方加以修正，或者寄望於rd能說出某某互動不能實現。但現實情況是rd會說「那就這樣吧，實現是能實現，等到分配迭代任務時看具體的排期吧！」這樣下來，評審會的結果只是大家對方案達成了共識，但方案中一些沒想到的和不合適的地方還是會存在。如此下去，每乙個迭代中的那一點不和諧，最後就會被累積起來，對產品的整體一致性帶來不好的影響。
就這樣的案例來看，有一些不同的處理方法。
微博使用者@快樂的滿神_odi說：互動問題，還是產品經理的工作。
微博使用者@yangyuan的微博說：老大說了算。
也有人說這要看哪個角色的承載人強勢，如果是ue強勢，那pm只好委曲求全，如果是rd強勢，沒準只看哪種方式的編碼成本低就用哪種，其他的點綴可能都免談了。
微博使用者@elya妞提到了另乙個方案：解決方法是pm頭、rd頭和ue頭三個人拍，10分鐘還無定論的，需求和互動由pm拍，ui由ue拍。
這些方法都可以解決問題，下面我也說說我的想法。
在這種無專案經理的團隊中，我的想法是將溝通前置，即多用非正式溝通。當pm提出需求時，先與ue溝通，ue不用急於畫正式的互動圖，而是用最快速的手繪稿來解決問題，看看主線流程是否能滿足pm的需求，經過二者的初步溝通，在主線流程上盡快達成初步意向。此時rd的負責人可以參與溝通，提出自己的看法，並就程式實現上成本高、難度大的地方進行再討論。有rd介入了以後，pm和ue都可以獲得與編碼實現相關的重要資訊，便於在初期調整需求和互動，減少空中樓閣的發生概率。
在三者的平衡過程中，互動應該能更好的與pm的需求吻合，也能將高成本的實現方案進行變通處理，在主線上就基本可以保證共識的達成了。這時ue的設計元素往往還不多，而且是手繪的草圖，是易於調整的。需求也可以在討論的過程中進一步細化和完善。rd也可以提前了解到pm、ue的想法，並保障在現有的框架下合理成本的實現。
在最後的評審會上，如果能用手繪稿評審也可以用手繪稿，便於修改。人都有這樣的心理：我好不容易繪製出來的互動設計方案不能說改就改，所以會上用正式的互動稿的時候，大家就很難說服ue。對pm也是同樣，會上發現需求有問題時pm也不太會改正式稿。
如果再極端一點，真的是pm、ue、rd爭論不休，倒是可以採用@elya妞的建議：10分鐘還無定論的，需求和互動由pm拍，ui由ue拍。武斷是武斷了點，但至少按照這個結論可以先開發了。
總之，解決的方法肯定還有很多種，而且在不同的條件下可能都有比較好的效果，但是無論如何，強調早期的、及時的非正式溝通我覺得都是很有幫助的，便於在早期討論清楚問題，也便於相互了解對方的思想。手繪稿也是不錯的方法，使用非正式的輸出物可以降低修改的門檻兒，使工作更敏捷的進行下去。
IT團隊之非正式溝通
溝通能力是一種能證明和讓對方發現你具有社會工作能力的能力。從表面上看來，它只是一種能說會道的能力,可實際上它卻包羅了乙個人從穿衣打扮到言談舉止等一切行為的能力。從大體上,我將溝通分為正式溝通和非正式溝通兩類。我們工作中通常會有一些正式的溝通比如會議，郵件。但實際上正式會議之前的大量的線下溝通才是起到...
IT團隊之非正式溝通
溝通能力是一種能證明和讓對方發現你具有社會工作能力的能力。從表面上看來，它只是一種能說會道的能力,可實際上它卻包羅了乙個人從穿衣打扮到言談舉止等一切行為的能力。從大體上,我將溝通分為正式溝通和非正式溝通兩類。我們工作中通常會有一些正式的溝通比如會議，郵件。但實際上正式會議之前的大量的線下溝通才是起到...
非正式專案管理
最近在思考自己前乙個專案所做的過程,專案管理遠遠不是書本上所講的那麼簡單,所以,在實際中去體會,在實際中去提高.就象打仗,必須自己先要有過硬的武功,在戰爭中殺出血路,才可能逐漸成長成將軍或統帥.把這幾天思考和參考別人的經驗總結一下 1.明確專案的目的與建設目標 2.專案中牽扯的人之間的關係 投資方 ...