SELF - REFLECTION
Trong hai tuần vừa rồi, tui đã trải qua một giai đoạn áp lực và căng thẳng, mọi thứ trong cuộc sống dường như xoay quanh deadline, đi ngủ mà con mơ bị dí nữa. Một tình trạng mà lâu lắm rồi không gặp phải. Tui là người có xu hướng hoàn thành công việc trước hẹn và việc phải xin lỗi vì sự trễ hẹn của bản thân lần thứ hai thật sự khiến tui cảm thấy xấu hổ.
Trong khoảng thời gian này, tui đã phải xin lỗi cô tui vì trễ deadline 3 lần liên tiếp, và các task trên công ty đều không hoàn thành đúng mục tiêu bản thân đã đặt. Thực ra, không phải là tui lười biếng hay gì, càng không phải miss công việc. 2 tuần rồi tui siêu nhơn lắm, làm việc tại công ty từ 8 giờ sáng đến 19h hơn. Sau khi về nhà, tiếp tục lôi laptop ra làm. Thứ bảy tối, tui còn cắm đêm từ 6 giờ chiều đến 6 giờ sáng ở quán cà phê và chẳng có ngày nghỉ vào vào chủ nhật.
Hôm nay, tui quyết định xin cô off 1 bữa để dành thời gian reflect, tìm root cause và đưa ra hướng cứu chữa :v. Công việc trong 2 tuần này bị double lên và từ đó tui cảm thấy bản thân mình có nhiều vấn đề trong cách tổ chức công việc, thấy được nhiều điểm yếu cần phải cải thiện ngay.
1: Công việc Tester
Trước khi test một tính năng, test luồng nào đấy, thì cần hiểu về tính năng đó để biết về thực trạng, nó hoạt động như thế nào và nó có liên quan tới các tính năng nào khác, đọc BRD để xem đang muốn thay đổi những thứ gì. Từ đó lên một bộ test case và setup mọi thứ để test. Thì tui cũng nắm quy trình làm, cũng đi theo quy trình, nhưng lại hời hợt, làm không tới nơi tới chốn, mỗi bước chỉ làm được 60% và kết quả là đi đến bước 3 lại lùi về bước 1, tiến tới và lùi lại. Dù đây là cái task thứ 7+ về test rồi nhưng tui vẫn tắm 2 lần trên một dòng sông.
2: Viết BRD
Trước khi nhận một task về cải thiện tính năng, điều đầu tiên không phải là đi tìm hiểu, nghiên cứu thị trường để xem người ta đang làm như thế nào, mà là tìm hiểu về luồng hiện tại nó đang hoạt động ra sao, vấn đề đang gặp phải là gì, phân tích số liệu để xác định cái gì là must do, should do. Xác định scope, cái này nhiều user xài không, làm tốn workload của công ty không, làm ra thì nhận được value gì, công ty có đang đầu tư cho tính năng này không => có đáng để làm không, làm to hay làm tí tẹo là được rồi :v? Done các bước đó rồi, xác định đối tượng người dùng, tìm tính năng đó của các công ty cùng lĩnh vực, đối tượng người dùng như mình xem họ đang làm như thế nào, tham khảo và chắt lọc những thứ hay ho, phù hợp để đem về làm tính năng của mình.
Đó là những thứ tui nghĩ mình nên làm, và đây là cách tui làm. Lướt sơ qua cái luồng đi, không tìm hiểu kĩ các trường hợp nào sẽ báo lỗi, lỗi báo ra sao, không nắm được unhappy case. Tui đã đi khảo sát 10+ cái ngân hàng và đem về làm BRD. Cuối cùng thì khi đi trình bày với BA, FE, BE, fail ngay từ phút ban đầu. Viết lại BRD tính đến hiện tại có lẽ là lần thứ 10 :v. Tính năng đi đến đâu đều bị reject đến đó và buộc phải làm đơn giản lại. Một lần, 2 lần tui còn nhiệt huyết, đấu tranh để mấy ảnh tìm giải pháp để làm theo ý tưởng của bản thân, làm thế này mới tiện cho user, nhưng tui quên rằng nhiệm vụ của PO không phải làm mọi thứ hoàn hảo nhất có thể.
3: Mockup design
Để bắt tay vào mockup thì đầu tiên phải nắm được process flow, vẽ sketch để phát thảo ý tưởng, vẽ wireframe để biết được bố cục rồi mới đi tới mockup. Tui lại không làm thế, trộn lại làm chúng cùng lúc. Đáng lẽ ra tui nên đi hỏi sếp xem process flow như này đã okela chưa, tiếp đó là sketch/wireframe oke hết rồi tới mới bắt tay vô mockup. Thực sự ngồi vẽ cực kỳ lâu, mất hơn 20 tiếng để ngồi vẽ luồng chuyển tiền định kỳ, đó còn không phải vẽ từ đầu mà là có bộ component sẵn và có nguồn tham khảo mà đã take time đến như thế. Và trong quá trình làm, không ít lần tui xóa vẽ rồi vẽ lại từ đầu. OMG, cái này mới đáng nói là sếp góp ý process flow cần phải thay đổi vài chỗ. Và thế là, …….. quay về vạch xuất phát nào.
4: Ngoài đi tìm bug thì bug nó cũng đi tìm tui
Mỗi lần làm cái gì thì nên thao tác từ từ từng bước, bước nào bị lỗi thì báo IT xử lý. Mô tả lại các bước để họ biết đường mà fix bug. Mình thì làm nhanh làu làu, ẩu tả, bị lỗi xong chẳng biết lỗi chỗ nào, thế là phải thực hiện lại lần 2, lần 3 xem bị sai chỗ nào còn để báo lại, có khi xuất phát từ cái tính hay quy về lỗi của bản thân, nghĩ mình sai chứ không phải hệ thống gặp sai, ngồi thử đi thử lại quài, bị lỗi quài. Và mỗi lần gặp sự cố như thế, tui đều mất khá nhiều thời gian để ngồi đó chờ và hỗ trợ ngta trong quá trình fix bug. Thay vì thế, sao tui không tạm để nó sang 1 bên, để chuyên gia làm việc của chuyên gia, khi nào xong thì hú, tui back lại sau chứ mắc gì ngồi đợi chi dậy trời ...??
Khi mà có nhiều task cùng một lúc, càng khiến tui càng nhận ra khả năng multitask của bản thân kém, thường thì tui chỉ tập trung một thứ duy nhất, làm xong và qua cái khác. Nhưng bây giờ môi trường, khối lượng công việc và làm việc với nhiều bên khác nhau khiến mình không thể cứng nhắc cách làm việc như từ trước đây được. Tại vì nếu làm thế thì sẽ không phối hợp với các bên khác để hoàn thành công việc => teamwork tệ, và cái nào cần ưu tiên trước thì mình làm trước. Giải pháp hiện tại có thể là cuối tuần nên lên kế hoạch cho tuần mới và đầu ngày nên liệt kê những việc cần làm, cập nhật tình hình lên đó. Giả dụ, mentor yêu cầu cập nhật tiến độ thì cũng biết mà nói ngay, nếu mà bị task mới chèn vào thì không bị stuff, còn đang làm mà gặp lỗi thì cũng biết next step là làm gì.
Túm cái váy lại là sang tuần mới làm việc có tổ chức, có quy trình từng bước và smart hơn chứ k có sờ tu pịt nữa.
