工做的思考十八：對團隊的一些想法 我的文章目錄索引

這篇文章是我思考了好久才寫出來，是好是壞也是我本身搗鼓出來，記錄一下，也但願你們多提點本身的想法。

一丶現象

　　開發人員：天天都須要填不少文檔，包括QA，QC，Plan等四五個文檔，並且有的開發人員下班以前還會發不少報告郵件。

　　　　　　   咱們團隊中前段時間來了一個新人，過了一個月就讓他負責天天下班以前發報告。

　　　　　　   天天光整理文檔都要兩個小時，最後天天都是十點左右纔回家，看在眼裏很心疼啊。

　　Leader：天天大部分時間都在維護文檔，都在檢查文檔，若是哪一個人填的很差，就會走過來告訴你趕忙修改等等。

 

二丶問題

　　開發人員：花了不少時間在填寫和維護文檔，轉移了開發人員的注意力，不能集中注意力在編碼上

　　　　　　   咱們團隊中的開發人員平均天天都會花1-2小時左右在維護和整理文檔。

　　Leader：花了不少時間在檢查和維護文檔，忘了最根本的責任 - 控制開發進度，提高軟件產品的代碼質量，解決開發中遇到的技術難題

 

三丶團隊和敏捷

　　什麼是團隊：你們都有一個共同的目標 - 創造一個世界級的產品

　　敏捷：在一個高度協做的環境下，經過每一個隊員自身的自我反饋，及時調整和完善

　　雖然我對敏捷仍是沒有不少的認識，可是一些好的點子仍是會引發共鳴的，咱們應該要去學習敏捷，並運用它，雖然會困難重重，但要有信心。

 

四丶自我反饋

　　填文檔爲了是什麼，我想大部分都是爲了統計計劃進度，任務作的怎麼樣了，Bug解決了多少等等，本質上就是一種反饋的體現。

　　反饋的途徑：①經過填文檔來反饋（死的） ②經過自身反饋，並由Leader彙總（活的）

　　怎麼解決反饋：立會

　　① 一天一小會(小組)，一週一中會(大組)，一月一大會(整個項目組)

　　② 立會時間半個小時最適宜，會中不要討論過細的東西

　　③ 天天上班以後半個小時後開會，讓你們有一個緩衝的時間而且能夠有時間統計本身什麼任務完成了，還有哪些任務沒完成，以及遇到什麼困難了等等

　　④ 天天的立會由Leader來發動，Leader作好了反饋記錄，這個特別重要

　　⑤ Leader收集反饋以後彙總並作出相應的計劃調整以及彙報給上級

　　這樣帶來的好處是把反饋的時間都放在早上立會的半個小時中去了，不在須要開發人員再花額外時間去作這件事，他們能夠更專心的作編碼工做了。

　　Leader也不須要每時每刻去催促開發人員填文檔，也不須要再去檢查文檔了，他只須要在立會中收集到隊員們的反饋就行了，並在會後進行彙總，分析以及調整。

　　這邊想說點激動的話：向那些該死的文檔說去死吧。

　　用好立會將會帶來不少好處，Leader應該善於從反饋中收集到更多有用的信息，而後作出調整。

 

五丶Leader不只要把控進度也要提升產品的代碼質量

　　首先我想說作Leader會很辛苦，雖然我沒有作過Leader，如今仍是一名小兵，但我能感覺每上升一個層次都會帶來更大的壓力和挑戰。

　　從廣義上說：對外接受任務，並擋住外部一切壓力，對內安排任務並檢查任務進度等等。

　　從狹義上說：除了安排和檢查任務，應該更注重產品的代碼質量，注重開發人員的提高。

　　在如今公司的團隊中我發現全部Leader的工做重心都放在檢查任務進度，文檔這些事情上面，但我想說的是這些都是最低要求，咱們是否要注重咱們產品的質量呢？

　　後端開發一直是我一我的在作，不論是代碼規範，性能，重構我都會按期執行，從維護和擴展方面都是良性發展的。

　　前端開發人員有七八個，前端不論是從代碼規範，性能，重構等方面一直都是沒有規定，一直都是我行我素，各寫各的。

　　雖然任務完成了，可是從後期維護角度上來說都是一個最大的挑戰，那麼我以爲Leader的做用就體現了，制定規範代碼，按期重構，按期CodeReview等等。

　　我想這些是Leader除了分配任務以外又一重要的職責了。。

 

六丶優秀人才

　　不少時候公司想找優秀人才，而優秀人才又不多，從而就會形成社會上就業壓力大，而公司也招不到優秀的人。

　　那麼不少公司找不到人怎麼辦？我想說 - 先招一個能夠培養成一個優秀的人，那麼我認爲這樣的人要符合三點：

　　① 用老闆的思惟來的工做

　　② 不只是一個能幹的人，還以一個肯幹的人

　　③ 渴望進步，渴望成長，渴望成功

　　其實上面三點也是我從一些文章中看到的，只是通過了一些我的思考寫在這裏的。

　　優秀的人不必定是很聰明的人，但若是他具有了上面三點的一點我想他都會成爲一位優秀的人才。

　　如今的團隊就缺乏這樣的人，能夠不斷爲項目作持續改進的人，能夠從整個項目看待問題的人，爲項目作強而努力的人，可能說的有點過激了。

　　最起碼我是這樣想的.......

　　至少如今我一直保持着一位碼農應有的素質，並努力向這三點靠攏，也一直在努力着。

 

七丶用戶，PD(Product Design)，開發

　　<高效程序員的45個習慣>一書提過讓用戶，PD，開發三者加入到整個軟件開發生命週期中去。

　　這樣能夠不斷聽取用戶的需求，從而來改進產品或調整方法，讓開發者能夠自由的發表對軟件的建議，從而改變軟件質量，讓PD根據用戶的需求進行設計軟件產品。

　　但在咱們的團隊中用戶，PD，開發這三者的關係卻沒有任何聯繫。

　　① PD沒有去認真聽取用戶須要什麼，而是憑藉他們的經驗和想法來設計需求

　　② 而開發人員也是有什麼需求就作什麼，沒有什麼建議提出來，就是有建議PD也基本是不理睬

　　③ 就這樣咱們各自爲政，當一有什麼問題就會推來推去的公司

　　在個人腦海裏我我一直堅信作一個產品，若是沒有把用戶，PD，開發這三者有效的結合起來，那麼總會在一方面有缺陷。

　　好比：沒有重視用戶的感覺，那麼這個產品就會沒人用；若是不重視開發者，那麼後期的維護，性能將會是一團糟，若是不重視PD，那麼用戶體驗就會不好。

 

這些都是這段時間思考的想法，九月底就要辭職了，十月份去外面轉轉，十一月份開始去上海找工做，開始一個新的人生階段，加油。

以同步至：我的文章目錄索引