Re: [討論] 我怎麼在一個 Startup 中擔任 Tech Lead

看板Soft_Job作者AmosYang (泛用人型編碼器)時間11年前 (2015/02/01 03:45)推噓3(3推 0噓 8→)

留言11則, 4人參與討論串2/3 (看更多)

一些個人心得小補充... :) ※ 引述《Ageis (Ageis)》之銘言： : #持續集成、定期發佈 ^^^^^^^^ lolwut 大漢化時代 XD orz : 題外話，我一直覺得純粹用時間管理軟體人員是很愚蠢的事，很遺憾的，在找到更好的方法之前，這類 metrics 是必要之惡。 1. 所謂隔行如隔山，技術領域之外的世界是以錢在衡量事情。在那個世界裡的通用語言是 ROI, KPI, throughput, predictability 2. 在這個星球上，「技術人員需要錢」多於「錢需要技術人員」 1+2 => 技術世界必須照著錢的世界的規則運行 => 乖乖作 burn down chart 、各種無理的 metrics 吧 XD : #溝通、和更多的溝通 : 一個團隊，特別是 Project Team 是包含各種不同功能的成員， : 身為 Tech lead 應該盡量耐心擔下溝通的工作。個人心得: 溝通除了「說出的話」還有更重要的「沒說出的話」；「收到的訊息」的重要性遠大於「放出的訊息」例如: 明言「有問題或改善方案可以提出」，但若真實中卻是把這些問題往 backlog 裡塞，或著 *總是* 拿著 ROI 的旗號 shut down 這些提案，那麼，真正被收到的訊息會是 "We don't fucking care." 易言之，身為領導者要作到讓屬下隨時隨地都願意與你說真話 : 呼應上一段，這也可以避免你的技術人員經常被無意義的打斷。 : 雖然溝通很重要，但不代表你的工作也是可以被隨意打斷的，在 hacker news 上讀過一篇文章，其宣稱: programmer 厭惡的是「無聊的中斷」，例如上級單位、 sales, PM 來吹法螺 programmer 之間的「有趣的中斷」則沒那麼令人厭惡, 例如各種技術問題 (尤其是拜估狗也沒答案的問題), vi(m) vs. emacs, Java vs. .NET, etc. : 應該盡早使整個團隊建立溝通管理的原則， : 以同樣的準則分辨這個問題的重要性及緊急性。個人心得如果決策者本人不須天天 dogfood 此原則 / 流程 / SOP 那他就不該是決策者，句點。除非他是出資者 :| 許多「流程」在紙上看起來很美好，實際作起來卻有太多 overhead, 唯有讓決策者本人也天天嚐受 overhead 的痛苦，才有改善的可能 XD : Tech Lead 必須及早建立起團隊文化，文件化執行細項及原則， : 讓每個團隊成員按照團隊準則行事。個人心得: 以身作則 A leader is followed, not made. : → alphadog: 這樣的TL好像對團隊成員沒有收入或技能上的幫助 01/31 23:02 : 方便給我進一步的建議嗎？ : → alphadog: 建議不敢只是主觀偏見私以為TL還應該考量團隊/成員的 01/31 23:27 : → alphadog: career 不然說什麼都是表面做做樣子大家演演戲而已 01/31 23:28 這中間有個平衡點。 http://en.wikipedia.org/wiki/70/20/10_Model 員工拿錢作事兼學習是好的，主管視員工個人特質，給予適當的引導與機會也是好的，例如, MBTI, MVP, 以及其他我在舊文裡提過的各項原則; 教學相長，這是互相的。然而，最後，現實是: 這是個「領薪水的工作」，員工是「成年人」，每個人自己要為自己的人生與職業生涯負 100.00% 的責任。 *如果* 想要依賴別人的引導，那麼, 請自己出錢，去買別人的時間來教你。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 68.4.199.75 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1422733543.A.F87.html

→

alan3100

02/01 09:45, , 1^F

02/01 09:45, 1^F

→

alan3100

02/01 09:46, , 2^F

02/01 09:46, 2^F

只能找機會塊陶

推

GenghisKhan

02/01 16:17, , 3^F