Chuyện Nghề: Một Dự Án Nọ (1)

Hồi quý 2 - 2021, tui có tham gia một dự án nọ. Đại ý công việc của dự án là ingest crashlytics data của mobile apps vào data lake của công ty, từ đó thực hiện những truy vấn dữ liệu cần thiết phục vụ nhiều mục đích (vd. monitoring, troubleshoot crashes…). Như các bạn có thể hình dung, phẩn lớn công việc là về data engineering. Nhưng team làm dự án này không có data engineer hay những người đã từng kinh qua công việc tương tự. Điều này có nghĩa là tất cả mọi người tham gia dự án đều không có một cái sense ban đầu tốt về dự án, từ việc có những dependencies gì, cho đến có những cách tiếp cận khả dĩ nào.

1 Nói sơ về hoàn cảnh ra đời của dự án. Có một thực tế hơi buồn là tại thời điểm đó, team PAX (làm passenger app) và team DAX (làm driver app) có một sự khác biệt lớn về mặt công nghệ. Hai bên có những practices riêng và share chung khá ít công nghệ, frameworks, components. Chính vì vậy, các sếp lớn thúc giục ý tưởng chuẩn hoá công nghệ các bên. Ban đầu, các sáng kiến (initiatives) được kỹ sư đề xuất và chọn lọc. Sau đó, kỹ sư từ các tech families, các teams khác nhau tình nguyện đăng ký vào những sáng kiến mà mình hứng thú. Một dự án được các kỹ sư khởi xướng, dẫn dắt từ đầu đến cuối, với sứ mạng chuẩn hoá công nghệ như vậy gọi là consolidation project. Dòng đời đưa đẩy mình tham gia vào một cái consolidation project như vậy. Và “zui” hơn nữa là giữa chừng thì mình được bán cái làm engineering owner (EO) của dự án này.

2 Cái ý tưởng consolidation projects nghe thì rất hào nhoáng. Nếu thành công thì tạo được cross-tech-family impacts. Nhưng khi thực hiện thì cá nhân mình thấy có khá nhiều bất cập.

Thứ nhất, các thành viên đến từ nhiều team khác nhau nên sẽ tốn nhiều chi phí giao tiếp (communication cost) hơn bình thường. Như ở các bài lần trước tui có nhắc, khác team là khác process làm việc, dung hoà được cũng tốn calo không ít.

Thứ nhì, cũng vì đến từ nhiều team nên commitment và sự phân bố capacity của các kỹ sư là khác nhau. Chẳng hạn, nếu 1 kỹ sư nọ phụ trách phần mà 1 số người khác phụ thuộc vào, nhưng kỹ sư này chỉ có thể dành thời gian 2h cho riêng tuần đó vì bận với những dự án quan trọng hơn của team, của tech family. Lúc này, tiến độ dự án bị chậm lại một cách không cần thiết. Để yêu cầu điều chỉnh capacity, lại một lần nữa tốn communication cost của EO. Mà communication cost này không chỉ là nói chuyện với những kỹ sư đó, mà còn đi nói chuyện với sếp của các bạn đó. Điều này rất tốn thời gian và công sức. Đặc biệt, vị thế của bạn không bằng sếp họ thì khả năng cao sẽ rơi vào kết quả là không được chấp thuận thêm capacity. Nhiều lúc nghĩ, thay vì đi chuẩn bị một mớ thứ để hỏi xin capacity, rồi xin không được, nuốt một mớ ậm ực trong người, chi bằng tui làm mịe luôn phần người ta cho rồi, còn nhanh hơn. Một lần nữa, cái lý thuyết của tui về làm việc nhóm của kỹ sư lại ứng nghiệm: nếu 1 kỹ sư mất 1h để làm xong 1 công việc thì 2 kỹ sư làm công việc đó phải mất tới 2h mới xong… Bạn biết hông, lúc tui xin thêm capacity của bạn backend kia, sếp bển bày tỏ lập trường không chịu, bảo tui làm rõ một cách chi tiết ra là cần làm task gì task gì nhỏ ra, độ ưu tiên ra như thế nào, estimated effort ra sao… rồi mới xem xét lại. Với đặc thù dự án cần research nhiều, nếu mà tui chẻ nhỏ task ra tới mức 1-2 point như vậy thì hoá ra dự án đã chậm, nay sẽ còn chậm hơn hay sao… Trong meeting đó có sếp tui, sếp bển, và sếp của sếp (tức là head của tech family), thêm 1 vài kỹ sư khác… Cảm giác của tui lúc ấy, quả thực không khác gì cảm giác của mấy bị cáo bị công tố viên chất vấn đến cứng họng giữa phiên toà trong mấy bộ phim Hàn Xẻng. Ức!

Một bất cập khác của consolidation project là không có sàng lọc đầu vào của dự án. Vì kỹ sư đăng ký tham gia một cách tình nguyện, không có cơ cấu phân bổ chủ chốt, nên không có sự đảm bảo sẽ có những người có chuyên môn tham gia vào dự án. Đối với một số dự án chẳng hạn như chuẩn hoá coding practices, ít nhiều trong team cũng có những thành viên nòng cốt, đủ giỏi để đảm bảo chất lượng đầu ra. Nhưng đối với dự án của tui, ai cũng tham gia với tinh thần học hỏi là chính, ai cũng chưa từng kinh qua những công việc kiểu data engineering như vậy. Cho nên khi mới take over vai trò EO của dự án này, tui như ăn cái combo đắng chát nhất, xì chét hơi bị nhiều. Khi ấy, tui luôn bị “imposter syndrome” (hội chứng kẻ giả mạo), cho rằng bản thân mình không đủ năng lực để làm: không biết nửa chữ data engineering, sao dẫn dắt dự án được, sao ra quyết định kỹ thuật được. Thời điểm đó mà được đi hát karaoke là tui sẽ bấm bài “Nếu em được chọn lựa”, hát đi hát lại cho nhớ đời… “Nếu bây giờ được chọn lựa một lần nữa, thì chắc có lẽ… em sẽ không chọn như vậy đâu” 😏.

3 Không biết lúc ông trời nặn ra hình hài của tui có bỏ lố chất “cô đơn” gì vào hông mà nó ám tui quá, mần việc gì cũng toàn độc hành. Ban đầu dự án có 1 iOS dev, 1 Android dev, và 2 backend dev. Giữa chừng thì 2 bạn backend kia không tham gia nữa vì không đủ capacity. Còn lại 2 chàng mobile. Bạn Android kia thì chủ yếu tham gia viết queries thôi (tức là sau khi data được ingested). Còn tui thì lo phần lõi còn lại (vd. setup Airflow jobs, setup roles, optimize cost, backfill data…). Và một lần nữa, theo một cách không mong muốn, tui trở thành một single-point-of-failure… Đính chính là không phải tui phủ nhận công lao của 2 bạn backend đâu nha. Hai bản đóng góp lớn lúc research ban đầu. Nếu là dân data engineer thì nhìn vào sẽ biết là xài cái này cái nọ. Nhưng đối với một team ngoại đạo tụi tui thì nhờ 2 bản mà tụi tui biết là phải dùng cái gì, và có những bước setup nền nhất định.

…

4 Nói chung dự án này cho tui nhiều bài học. Một trong số đó là phải tiên lượng vấn đề kỹ càng để set kỳ vọng tốt hơn. Phần còn lại thì “có công mài sắt, có ngày đau tay”, ủa lộn, “có công mài sắt, có ngày nên miếng sắt nhẵn hơn”.

…

5 Nói chút về cơ duyên ra đời dự án này. Chuyện là ở app một team nọ, có 1 vài cái crash thần bí diễn ra trên một feature quan trọng sắp launch. Kỹ sư team đó đã bỏ ra nhiều nỗ lực debug trong một thời gian nhưng không có được kết quả như mong đợi. Cuối cùng, nhờ việc truy vấn dữ liệu crashlytics trên BigQuery, mấy bản có hướng đi đúng đắn và fix được issue, giúp unblock việc release của feature ấy. Sau sự kiện này, một câu hỏi đặt ra là làm thế nào để việc kết xuất, truy vấn thông tin crashlytics của mobile apps một cách phức tạp như vậy có thể accessible hơn cho các kỹ sư mobile… Câu hỏi đó đu theo làn sóng consolidation projects mà cho ra đời dự án này đây.

Cho đến nay, sau khi dự án này xong cả năm trời, tui vẫn thấy rất hiếm người thực sự dùng. Tức là kỹ sư, ai ai cũng chỉ xem trên Firebase crashlytics dashboard để debug/troubleshoot crash thôi. Nhiều lần trong weekly sync-up, khi bàn gì liên quan tới crash, tui hay lộ liễu PR cho cái “crashlytics data in data lake” này. Mà đồng nghiệp tui nghe xong chỉ cười thoy hà 😂. Crash app này đơn giản quá nên hông chịu xài, đúng hông mấy bạn đồng nghiệp thương mến?!