Re: [討論] 想請問當技術主管該做的事
敘述一些自己公司的狀況供你參考
: 1.task review
: 我的想法是每週開例會來讓大家報告做的事項
: 但又覺得好像沒必要,因為PM都會知道RD們做的事情
若已有以專案為單位的例會,那可有可無
PM知道RD在做的事,但RD們可能會相互不知道對方的工作或細節
有時不知道功能會互相交互或已做過類似的而做了很多白工
或其他人可以在例會上提點過去做過的功能與坑
: 2.公司未來技術方向
: 因為程式人生是需要不斷學習的
: 公司也是,不然也會被業界淘汰
: 我是希望可以帶著每個RD成長
: 這個倒是沒有什麼異議
: 但如果決定了某個方向也是會和RD們討論
: 看是不是有盲點
我想這是RD都需要做的,但技術主管需要統整這些,選出可能未來可以使用的
以及親自試試看效果如何
: 3.提升RD工作效率
: 這點應該就是會想破頭的XD
: 因為公司的PM有些是非本科的
: 客戶如果發問,他們不懂的話就會pass給RD
: 有時候就是一些基本問題,然後RD工作就會被打斷
這邊可以建立一個問題收集的機制吧,知識庫、操作手冊或RD統一回答問題的群組
來讓RD可以控制自己回答的時間
除非這些問題需要馬上被回答?
: 4.統一coding style
: 這點主要是防止人員臨時請假或是離職,交接時痛苦指數會比較低
: 當然還有如果多人合作時就較不會有違和感
訂定團隊規範,git流程、各種linter、專案說明文件等等知識庫
這些東西都需要有個人做裁定,那只有技術主管的角色比較適合了
確保團隊經驗可以持續累積、進化後,人員流動、新人要上手才會有依據可以遵循
除了以上提到這些,還需要定期(例如每季)給RD檢視自己、互相檢視的機會,
深度聊聊他們需要什麼、對現狀有沒有意見、對其他隊員的想法、對未來的想像等
預先發現有沒有隱藏的炸彈
協助確認規格或需求是否合理、花時間做code review、找出需要重構的code
剩下的就是一些確保行政工作流暢吧
--
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯,且有兩份重覆的code (沒有unit test保護,而且年久失修 要加入unit test會需要更多時程) 現在要加入C,也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來17
Re: [討論] 怎麼跟自以為是的同事相處^^^^^^^^^^^^^^ 不要做這種假設,很多programmer 選擇這行就是因為他們對人技巧不好、但好死不死又 適合寫程式 除非你觀察到產品A一直找不到其他前端,或者新加入的前端離職率很高,否則我們沒有 客觀事實10
[心得] 進入陌生專案這些討論實在是太無聊了, 繼續來開不同話題, 討論點有內涵的東西不是比較有意思嗎? 這篇來講講怎麼進入一個陌生專案,所謂的陌生專案有很多種形式, 但不管什麼形式, 這裡的前提都是 source code 還在, source code 都不見的逆向模式特別複雜, 這裡先不論.10
[心得] 面試分享:橡樹網路科技有限公司(前端作品自介: 有漫畫站開發經驗,用vue及laravel開發的有搭載ci/cd自動deploy到serve上去 公司是在菲律賓的有牌博弈公司,104履歷投遞後會人資先初面 人資初面: 請你自我介紹及做過什麼產品,初步瞭解後會安排二面7
[面試] 帆擎/和盛/叡揚/達暉/凱發### 1。資料庫管理師,帆擎網路服務有限公司,台北市松山區 一間博弈公司。辦公室很遠,在松山區吳興街深處,公司位於最高樓。 事先完成公司格式的人事資料,到達後不用再填寫。 由台灣團隊的技術主管面談,問了一些過去經驗、以及做過的東西。 公司有一個位於菲律賓的中國團隊,現階段是把核心技術轉移到台灣,故人員擴編中。5
[請益] 請問如何做工作項目與品質確認?各位大大好, 小弟最近帶了小組, 在之前因為公司沒有技術主管, 沒有人管, 我和組員們 是各做各的. 但有2位 [資深組員] 負責的項目, 產出品質一直有問題,3
Re: [心得] 如果可以, 真的建議不要再去創業公司了最近公司的狀況讓我有點理解原po的想法 但這應該都是個案啦 只是剛好近期也遇過兩位這樣的人 都是在新創工作&後來新創都收了&一人開發 有時候這種新創就真的不是要做多大的東西2
Re: [請益] 這種情況要怎麼重構如果專案有deadline的壓力建議是先各自發展以不相互影響為前提,最後再用剩餘時間開 一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人,沒有定義從系統 到功能的分工,導致代碼重工,而且缺乏溝通。 真的建議未來有機會在主導你還是要自己學會定義好工作,先學習不寫code就可以訂出功 能以及架構。我自己工作後常常遇到工程師很喜歡自幹,還沒開始就急著寫code,而不是