如何做好一名移動部門的開發經理？

01-28

目前本人初擔任一個Android/iOS項目的開發經理. 需要怎麼樣的相關知識才能算一個合格的開發經理。

我一般會做三樣.1.需求;2.了解需求以後,評估項目時間及計劃,並且需要團隊同事認可.3.測試

當然有時候,我也會切入項目的開發和架構層面,以防止有些糊途蛋在開發的時候,把後面的需求功能,或者把預留的架構設計給堵死了.

1.需要理解,並且是對整個的需求做了解,並且保證我的團隊理解都一致.最終結果是設計效果圖,每一個界面的.通用界面的提示,所有界面的操控方式,返回方式等都會在這個一塊解決.

2.需求控制,因為常常和客戶溝通,有時候很多需求只是客戶一時興起,其實功能的作用不大,投入的人力,物力太大.有些則是對現有的項目重構太大.在判斷這些需求以後,我會和甲方或者產品經理溝通,確保正確理解意圖的情況下,減少些類需求的出現.(如果可能,下放到UE/UI層面解決)

3.項目同事去評估項目中可能碰到的難題,難點.對可能出現的技術難點做了解以後,再做時間評估.(下放到各技術人員,技術能力不夠的,結解決方案,解決案例,技術專家支持)

4.架構,有比沒有好.有很多問題驗證豐富的同事,比初級同事高太多,提前確認好後期可能出現的需求和功能,綜合現有的功能,進行項目的構架,預留介面與升級界面或者介面.(下放到各技術人員,但是我一般會評審,對這個構架說個所以然出來,以及兼容等思考,如果能力不夠,會和技術人員一起討論架構)

5.先做出來,再完善.

6.也是我願意花最多時間的,就是測試驗收.並且設置簡單的高中低BUG分級,嚴格團隊對各BUG級別響應的時間.

上面的測試驗收里,也包含了每天的進度跟進.

跟進的方式就多了,每天晚上的統一版本會歸屬到機器上,一個一個的看.

甚至會統一代碼提交數量,要求各同事講解今天完成的任務,做的事.如果代碼少的,說做架構去了,架構是否複雜,是否需要這麼多時間.代碼多的,主要實現功能了.一目了然,偷懶的傢伙嘴上不說,升職加薪自然就少.

大家都一窩裡的,誰忽誰呢?

以上,如果有專業測試人員,那就好了.要求測試人員先過大家已經完成的了,差不多穩定的版本才會到我手裡.如果現在測試人員測試的出現非常多的Bug,還是幾天前的,完成沒有按照Bug級別修復來,那就和測試人員聊聊加強Bug修復時間跟進,如果開發人員不配合,你得去協調了解,甚至運用資源來支持,再不行就是獎金等了.

一句話,我會把從UI/UE的需求與產品人員對接,再以產品人員驗收為一個閉環來打造,我協調好這個閉環能高效的運轉起來,在這裡建立合理的規章,制度,獎懲.

一般大家碰到的客戶端開發團隊可能沒有我碰到的人員角色這麼齊,但是方法差不多.你可以按這樣的角色來配置,一人身兼多職.

如果大的客戶端團隊,目前我的經驗里,行之有效的方法是一定要按職能或者項目(功能),或者二者重合來角色來切分團隊,以保持團隊溝通的高效.

一般一個小團隊成員我會盡量控制在6名以內.以TL溝通為主.

吹牛:

閉環建立起來以後,沒事就去看看各個環節,要求相應的TL能有人員備份意識,要求各團隊成員能自己提供優化環節,並且團隊能自我進化.如果可能再備份一個項目經理,自己就偷偷樂會兒,看看公司有沒有其他的項目,再複製以上方法,多個項目同時跟進...

兵無常形,水無常勢,希望樓主可以根據自己團隊的情況,建立一套符合的方法.

不要自以為是，不要以為懂的別的技術原理或方案（後台，其它語言），可以拿到移動中去，很多是不通用的或者效果不大的。

獎懲激勵一般制定下來最終還是要看高層能否去落實執行才行，不然到頭來還是一場空。