目前我在 Crypto.com 擔任全端工程師，負責的部分是後台系統，面對的目標群眾是公司內各個部門的員工。所以幾乎每個新的功能上線時，我所在的小組都會有事情需要做，小至顯示資訊給相關部門觀看，大至與App或者website團隊合作，讓後台系統可以操作使用者的資訊。

當有一個新的功能需要開發時，PM會先集結各個相關的部門，進行 Kick off Meeting，基本上是簡述新功能的功用，需要注意的點，以及期望的上線時間。這個部分通常談論到技術的百分比會比較低，所以Tech Team 會在Kick off meeting 之後自己集結起來，討論如何實作新功能。

首先：

1. 釐清新功能的技術難度。
2. 需要哪幾個部門的工程師。
3. 需要多少個工程師一起實作。

在有結論之後，就交由各個 Team 自己安排開發時程。

我們組是使用 ASANA 來紀錄小組的進度，而 ticket 的部分則是自由認領居多。比較特別的點是，通常我們的小組，在實作一個比較複雜的功能時，都會希望有至少兩個工程師可以加入，這樣在debug或者出事的時候，如果一個工程師剛好休假，另外一個也可以馬上接手，查看到底哪裡出了問題。

另外由於我們組是面對內部員工，而其他部門的員工比較多都在歐洲的辦公室，所以也會需要有英文溝通的能力（英文能力上升！）

基本上PM 會一個禮拜確認一次每個部門的進度，另外自己的小組也可能會有Daily Standup或者其他不同的措施來確認進度，確保不會拖延到預定的時程。所以大部分的專案都能夠如期完成。

但有時候如果發生突發意外（一個系統突然發生異常），或者跟其他第三方的合作尚未談妥，這時就有可能會拖延到既定的時程（基本上不關技術部門的事情，在這邊就不討論）

覺得比較可惜的是在專案或者功能完成之後，公司比較在意的是開發另外一個新的功能，而比較沒有時間回頭檢討實作出的功能是否可以做得更佳好（至少對技術部門來說，我們很少時間花在重構程式碼），所以也累積了一定量的程式債。