Hai dự án, 50% effort và product

1. Hoàn cảnh

Dự án hiện tại KH chỉ thuê 50% effort (hiểu đơn giản là chỉ trả tiền để làm 4h/8h/ngày). Việc trong giai đoạn này thường ít hơn kha khá so với giai đoạn 100% effort. Nên việc ngồi “tự nghiên cứu thêm kiến thức” với mình thường hay xảy ra.

Tầm vài tháng ngồi vậy, tuy cũng đã làm self-app nhưng chán và lại làm remote nữa. Nghĩ mình cần thêm nhiều trải nghiệm thực tế hơn nữa, nên một ngày đẹp trời mình xin thêm một dự án nữa để làm.

Khoảng 2 tuần sau mình được join dự án mới, khá hớn hở nhưng cũng lo lo nhiều cái. Vào dự án để thay bạn dev cũ sắp nghỉ.

Mới vào thì có vài hôm được đọc tài liệu như spec, xem design, đọc code app, quy trình code, git flow, … các thứ, các thứ như một dự án thông thường thôi. Dự án mới này mình cũng 50% effort. Tính ra là đã full effort của một ngày, hết “tự nghiên cứu thêm kiến thức” :D. Vậy giờ mình đã làm hai dự án.

2. Mô hình phát triển của dự án

Hai dự án mình tham gia đều theo mô hình Agile-scrum. Tuy theo nhưng các dự án mình đã tham gia chỉ tuân thủ một phần thôi. Riêng dự án này thì quy trình nó chuẩn Agile-scrum hơn.

Quy trình thực tế sẽ thế này

• Một Sprint kéo dài 2 tuần, làm đầy đủ các bước nghiên cứu yêu cầu, code, test, release

• Có một bản danh sách các tính năng, yêu cầu (Product backlog) được đánh độ ưu tiên(High/Medium/Low), bên Brse/KH sẽ trao đổi để gửi một số yêu cầu về cho bên dev. Hoặc sẽ gửi một số yêu cầu kèm độ ưu tiên về cho bên dev chọn.
• Có một buổi họp đầu Sprint (Sprint Planning) để Brse phổ biến yêu cầu cho Sprint. Bên phát triển sẽ nghiên cứu yêu cầu, trao đổi vs bên Brse. Sau đó phần nào thấy chưa rõ thì sẽ có Q/A để hỏi lại KH.
• Khách hàng trả lời các Q/A. Nếu ổn thì design (giao diện) nếu cần sẽ được lên. Xong thì gửi KH để confirm.
• Việc tạo Sprint backlog cũng được thực hiện. Các task mà bên phát triển đã chọn sẽ được thêm vào, đồng thời sẽ tự lên lịch làm task.
• Trong quá trình làm task, nếu thấy có phát sinh vấn đề, thắc mắc thì có thể confirm vs KH thêm.
• Bên dev code xong thì đẩy sang Tester. Tester xong đẩy cho KH test. KH test xong không lỗi thì hết sprint.
• Hết Sprint có buổi Sprint Review để nhìn nhận, đánh giá lại những gì đã làm ở Sprint.

Tổng quan là vậy. Cụ thể về Agile-scrum mình sẽ để link ở mục Tham khảo cho các bạn nhé

Dự án còn theo hướng Product nữa. Vâng một dự án mang hướng Product ở một cty Outsource. Mình sẽ nói về điều này ở dưới nhé 😀

3. Làm dự án

Mới vào dự án thì tuần đầu mình đọc trước spec, đọc code, hỏi về quy trình hiện tại của dự án. Mấy sprint đầu ít task, task đơn giản nên mình làm ngon, quen dần với code, quy trình của dự án. Được cái code xong thì không có bug – vâng zero bug : )

Tưởng vậy là ổn, cho đến một sprint mà giờ mình cũng ko muốn nhắc lại với 20 con bugs, những buổi tối code tới 12h, thứ 7, cn mà vẫn phải mò lên code.

a. Bối cảnh sprint

Bạn dev cũ đã nghỉ, giờ cân team. Sau mấy sprint làm task ngon ăn thì mình khá tự tin khi vào Sprint mới. Buổi Sprint Planning thì bên Android có 2 yêu cầu mới, nghe bảo khá gấp, cần hoàn thành trong sprint này.

Về nội dung yêu cầu thì mình sẽ không nói cụ thể được. Nhưng nội dung yêu cầu ban đầu thì cũng không quá phức tạp, tổng quan là gửi thông tin cho bên web. Sau đó nếu bên web có phản hồi thì bên app hiển thị lên.

Đọc qua thấy khá easy nên mình estimate khá ít time, không có Q/A nào thêm cả. Lại dự án kia bận nữa nên ko tập trung code được bên này. Gần đến cuối hạn làm task mình mới thực sự tập trung vào làm.

b. Phát sinh

Code xong và đẩy sang cho tester, tưởng ngon ai dè:

– Giao diện bị vỡ trên thiết bị của tester: đi confirm và phải sửa lại design mấy lần liền

– Phát sinh thêm một tính năng mà thấy cần phải làm thêm: không biết code nên phải tốn thời gian tự tìm hiểu thêm. Bên server cũng phải tốn effort sửa thêm.

– Cách trả về dữ liệu của api không phù hợp vs app hiện tại. Giờ sửa sẽ phải đổi lại hướng làm, lên lại design. Rất tốn thời gian nên phải đưa ra giải pháp tạm thời.

Và điều mà chẳng dev nào muốn đó là “Bug”. Bug từ đơn giản như UI đến logic loằng ngoằng. Những điều ở cũng gây ra bug.

F5 là nút ở trên bàn phím để … “Refresh” trang, và mình ước không có tính năng này:

• F5 cái mình lại có thêm bug mới, tính ra tổng 20 con bug lận
• F5 cái bug vừa sửa lại bị Reopened
• F5 cái list bug lại dài thêm, bug do bị impact, do liên quan tới các vấn đề chưa confirm cụ thể khá nhiều

Và còn gì nữa, phải … tự cover thôi. Mình nhớ là liên tục từ thứ 4 tuần trước đến thứ 2 tuần sau

• Bình thường thì tầm 5h là nghỉ rồi, tối thì nghỉ ngơi. Nhưng 6h, thậm chí những hôm cuối tầm 7h mới nghỉ. Ăn xong, tắm rửa nghỉ ngơi 9h30 lên code tiếp. Tận 12h đêm mới nghỉ.
• Sáng thì do làm remote nên toàn tầm 7h30 mình mới dậy. Tuy nhiên giờ tầm 6h30 mình đã dậy rồi. Ăn sáng cho nhanh, xong và lên code tiếp còn đẩy bug cho tester.
• Cuối tuần thứ 7, chủ nhật buổi chiều mò lên tầng code, trong khi bình thường thì chơi. Chưa xong thì tối lên làm tiếp.
• Bên Tester ping liên tục để trao đổi, hỏi tiến độ bug.
• Dự án kia cũng có task cần nghiên cứu. Vậy là phải làm cả hai bên. Lúc làm bên này, lúc làm bên kia. Bận quá nên thậm chí mình còn đẩy lại task cho bên IOS nghiên cứu – vì chung cho 2 bên được. Brse bên dự án mới này sau cũng phải xin effort lên cho 100% để tập trung làm.

Bực, chán, buồn, nhiều lúc tự hỏi tại sao mình lại đang ngồi đây, đang code gì ấy nhỉ ? Đây là đâu, tôi là ai ?? Mà remote nên ko thể trực tiếp thấy cảm xúc của bên tester. Chắc họ cũng bực, chán lắm.

Nhưng buồn, chán thì cũng không thể giải quyết được vấn đề. Việc vẫn còn đó, deadline vẫn còn đó, làm thì vẫn phải làm thôi.

Tập trung làm cho xong, tích cực trao đổi với bên BE, bên Tester để hoàn thành task. Cuối cùng vẫn release được với một số bug lặt vặt ko ảnh hưởng lắm thì sang sprint sau fix tiếp. Và đến Sprint Review thì bị nói cho sấp mặt : )

c. Nguyên nhân

Vậy nguyên nhân ở đây là gì ?

Cũng phải hết sprint này mình mới có thời gian để xem xét lại những gì đã xảy ra. Và mình rút ra một số điều sau:

• Chưa hiểu rõ spec, code dự án

Nhớ lại thì công nhận code, spec dự án nhiều chỗ mình vẫn chưa hiểu hết, như logic xử lý ở màn hình, gọi api, sự liên quan giữa các màn với nhau. Ở các sprint sau này mình vẫn phải hỏi rất nhiều.

==> Nên lúc code sẽ phải tốn thời gian đọc, tìm hiểu hơn.

• Chưa quen với cách dự án hoạt động

Như mình đã nói, dự án hoạt động theo hướng product. Và những gì bạn cần là sự chủ động, linh hoạt, ý tưởng và … ý tưởng

Ở buổi Sprint Planning, yêu cầu được đưa ra để thảo luận. KH họ chỉ tập trung đưa ra yêu cầu của họ, cái đích họ muốn. Còn những thứ như:

• Làm thế nào cho hợp lý, phù hợp
• Ảnh hưởng của yêu cầu tới các tính năng hiện tại.
• Làm hướng nào là tiện nhất cho bên phát triển

Thì bên dev hãy thảo luận rồi gửi lại cho khách. Họ thấy hợp lý thì triển. Là mới trong dự án và spec vẫn còn khá lơ mơ nên mình chủ yếu là chỉ ngồi nghe, bảo sao biết vậy : )

Đương nhiên là vẫn sẽ có câu hỏi nhưng chủ yếu chỉ là về chức năng mới, những phần thêm mới. Cái mình thiếu, và đã tạo ra các phát sinh chính là đã không chủ động, tích cực hơn trong việc tìm hiểu, đóng góp vào thảo luận hơn từ đầu.

• Khá chủ quan trong việc code

Đây có lẽ là cái sai lớn nhất của mình.

Bên Tester có làm Test View Point – kiểu như Testcase của tester để bên dev có thể self-test. Nhưng mình làm khá qua loa, nhiều chỗ ko hiểu nhưng cũng ko hỏi lại, nhiều case đọc và bỏ qua luôn. Số lượng bug đáng lẽ ra có thể giảm đi nhiều nếu mình làm cẩn thận.

Ngoài ra, code nhưng mình check impact thiếu rất nhiều. Fix bug nhưng ko check kĩ impact. Có thể do fix bug khá căng + code nhiều chỗ chưa hiểu nhưng mình “bỏ qua” luôn 🙁

Làm hai dự án, dự án kia thì do được làm từ đầu, spec, code đã ngấm nên thực sự những lỗi trên thời điểm này không xảy ra với mình. Vào giữa một dự án khác, nhiều thứ phải tìm hiểu, quy trình lại khác nữa và lỗi đã xảy ra.

d. Giải pháp

Sau một Sprint “toang” thực sự, và bug sang tận sprint sau vẫn còn thì mình nghiêm túc “đánh giá” lại những gì đã sai.

Vì đã hiểu hơn với cách dự án hoạt động, nên mình đã

• Chủ động đọc kĩ yêu cầu mới trước buổi Sprint Planning. Xem có gì lạ không, luồng thông chưa, đọc cả code xem nó thế nào luôn.
• Tập trung hơn lúc cả team trao đổi. Không hiểu cần hỏi lại ngay. Và ngẫm lại xem những gì mình đã biết về dự án, xem có áp dụng được gì vào tính năng hiện tại không, nó ảnh hưởng gì đến nhau
• Bắt đầu làm thì xem lại tổng quan một thể yêu cầu. Tách từng ý, từng câu ra để check xem mình hiểu chưa, code, API có vấn đề gì không. Có vấn đề thì raise lên để xử lý luôn, tránh để đến cuối mới raise lên.

Về spec, code

• Dự án thì sau sprint căng đét này thì nhiều luồng mình đã thông hơn.
• Việc estimate mình cũng estimate to hơn một chút những phần cảm thấy chưa rõ. Thời gian thêm dành cho việc đọc kĩ luồng code, check impact, làm Test View Point.
• Spec mình vẫn còn nhiều điểm chưa biết, nhưng quan trọng mình hỏi nhiều hơn, trao đổi nhiều hơn.

• Lúc làm thì spec mình tự tách ra từng ý, từng câu nhỏ để check. Note spec này tương ứng đoạn nào trong code, làm thì xử lý code đó thế nào, thêm gì vào, …

• Việc self-test giờ đã phải cẩn thận hơn. Mình giành nhiều thời gian làm kĩ Test View Point. Check từng dòng, đọc từng câu, từng chữ. Không hiểu ping luôn cho bên Tester.

e. Kết quả

Và con tim đã vui trở lại:

– Hai sprint sau đó mình ko có một con bug nào – vâng ko có con bug nào

– Sprint sau đó mới có bug, nhưng chủ yếu là về UI, fix đơn giản

– Nhẹ nhàng công việc, ko còn những hôm làm tới 7h tối, xong 12h đêm 🙁

– Xong có thời gian lại “tự nghiên cứu thêm” 😀

Kết quả quan trọng nhất mình thấy là mình đã “được toang 1 lần” để thấy mình còn nhiều thứ cần cải thiện

4. Một dự án hướng Product, ở cty outsource

Bài dài quá rồi mình không định viết nữa. Nhưng thôi cố nốt, như tự tổng hợp lại cho mình. Ngoài những yếu tố mình đã nói ở trên, ngoài ra còn có một số cái của một dự án product như:

• Bạn có thể tự suggest thêm tính năng cho yêu cầu. Hoặc suggest thêm yêu cầu để cải thiện thêm app. Suggest từ những cái đơn giản như màu nào là thuận mắt, vị trí item sao cho hợp lý, … đến nên hiển thị cái này, ko nên làm cái này cái kia.
• Được nhận feedback trực tiếp của yêu cầu mình làm trước đó, từ đó có thể nêu ý kiến cải thiện
• Thường xuyên được biết sản phẩm làm ra có nhiều người dùng không, một tuần, một tháng có bao người sử dụng app.
• Đánh giá một tính năng nên làm thế nào, hướng giải quyết ra sao dựa vào thực tế người dùng sử dụng app.
• Mọi người đều chủ động, đặt cái tâm, nhiệt huyết của mình đóng góp cho dự án.

Tổng kết

Đi xa hơn, ra khỏi vòng an toàn của mình để học thêm, khám phá thêm những điều mới. Đó là một người có thể nói là khá “cầu toàn” như mình đã làm.

Có những va vấp, có những cái sai, có những nhọc nhằn. Nhưng quan trọng là khám phá bản thân, xem mình làm được những gì, thiếu những gì. Tuổi trẻ thì cứ trải nghiệm đi 😀

Tham khảo

1. Sự khác nhau giữa Công ty Outsourcing và Product (viblo.asia)
2. Công ty Outsource và Công ty Product – Đâu là những điểm khác biệt giữa hai dạng công ty? (jobstack.vn)
3. What is Scrum?
4. Scrum – what it is, how it works, and why it’s awesome (atlassian.com)
5. Agile là gì? Scrum là gì? Các công cụ quản lý dự án theo Agile mà bạn nên biết | TopDev