Hoàng xuất phát là dân kỹ thuật phần mềm, tham gia mảng phát triển phần mềm từ 2017 đến nay. Mình muốn mang những trải nghiệm cá nhân chia sẻ đến anh em, từ đó anh em thấy gì hay thì có thể tham khảo sử dụng, mà dỡ thì anh em góp ý giúp nhé.
View all posts by hoangphan
Công cụ lao động không chỉ là những vật dụng, những dụng cụ hiện hữu giúp bạn làm việc tốt hơn. Mà trong thời đại ngày nay, đối với mình thì có một loại công cụ lao động không thể thay thế cho nguồn lao động chất lượng cao. Nếu không có nó, nguồn lao động này không còn là chính nó nữa. Đó chính là “Tri thức”.
2. Khái niệm
Theo như mình nhớ, lịch sử lớp 10 từng có dạy về khái niệm công cụ lao động, mình xin trích một phần định nghĩa từ wiki vào như sau:
Công cụ lao động là một bộ phận quan trọng của tư liệu lao động nó tác dụng trực tiếp vào đối tượng lao động, quy định trực tiếp năng suất lao động. Trình độ công cụ lao động là yếu tố phản ánh rõ nhất trình độ phát triển của lực lượng sản xuất.
3. Các thời kỳ của công cụ lao động
Xưa công cụ lao động được sắp xếp theo các kỷ nguyên từ thời kỳ đồ đá -> Đồ đồng -> Đồ sắt -> vậy thời nay, là thời kỳ đồ gì???? Theo mình nghĩ giờ là kỷ nguyên của nền tri thức.
Để mình giải thích cho các bạn vì sao mình nghĩ vậy nhé.
4. Kỷ nguyên nền tri thức
4.1 Việc không thiếu, thiếu là do thiếu tri thức
Gần đây mình có đọc được cuốn sách “Tôi tương lai và Thế giới” của tác giả Nguyễn Phi Vân. Cuốn sách có đề cập rất nhiều về vấn đề Robot đang dần thay thế con người trong công việc. Nhiều người trở nên thất nghiệp, vậy vấn đề có phải do robot đang dần chiếm lấy công việc của người lao động. Theo ý kiến cá nhân của mình thì không phải. Thỉnh thoảng mình lướt facebook, có rất nhiều tin tuyển dụng, HR hằng ngày đăng status than rằng không tìm được ứng viên phù hợp, không có CV nộp cho họ.
Vấn đề ở chỗ việc thì không thiếu, mà người than không có việc cũng không thiếu nốt. Trước ở trọ, nghe anh phòng kế bên than không có việc, tìm hoài không ra việc. Vậy sao người thiếu việc, việc thiếu người không chạm được với nhau. Đó có phải là do nguồn lao động chưa đủ kỹ năng, kiến thức để làm những công việc đó (bỏ qua một phần từ sự phù hợp nhé).
Kỹ năng và kiến thức có phải là trí thức không?
Câu chuyện xảy ra là robot đang thay thế dần những công việc tay chân, những công việc có thể lập trình cho nó tự hoạt động được. Còn rất nhiều khối công việc cần nguồn nhân lực tri thức, như ví dụ ở trên.
Để làm được những công việc khó hơn, những công việc mà robot hay cả những người lao động khác khó có thể thay thế. Thì việc nâng cao trí thức (một công cụ lao động) là điều không thể thiếu.
4.2 Học là chuyện suốt đời
Đừng nghĩ rằng việc nạp kiến thức chỉ thực hiện khi từ 5 tuổi đến hết 22 tuổi, rồi sau đó tập trung sáng đi làm, tối về nằm xem youtube, facebook, titok đến suốt hết cuộc đời. Mình thật sự thấy nhiều bạn thực sự phí tuổi trẻ của chính họ trong khi đó họ có thể nạp thêm kiến thức để trở thành một phiên bản tốt hơn của bản thân.
Để phát triển thêm, tồn tại dễ hơn trong thời đại hội nhập, công dân toàn cầu này thì mỗi người chúng ta cần phải học tập liên tục và không ngừng nghỉ. Như thế thì “tri thức” mới nâng cao được, công cụ lao động được rèn dũa tốt hơn, xịn xò hơn. Từ đó mà thăng tiến trong sự nghiệp và trở thành một nguồn lao động chất lượng cao, cực cao và rất rất cao cả khi bạn đi làm thuê, làm cho chính mình hay làm ông chủ.
4.3 Ngoại ngữ là thành phần không thể thiếu
Thêm vào đó để hội nhập tốt hơn, dễ dàng trở thành công dân toàn cầu thì ngoại ngữ là một trong những yếu tố quan trọng. Bạn có biết rằng 3 ngôn ngữ được dùng phổ biến nhất (tính theo số lượng người dùng, số quốc gia dùng và được sử dụng trên internet) là: Tiếng Anh, Tiếng Trung và Tiếng Tây Ban Nha (số liệu 2018).
Và Tiếng Anh là một ngôn ngữ được sử dụng phổ biến trong công việc ở Việt Nam và nhiều nước trên thế giới, do đó việc nâng cao trình độ Tiếng Anh là một điều thực sự nên làm của người trẻ Việt Nam.
Và mình cũng đang cung cấp dịch vụ kết nối việc học tiếng Anh giữa học viên ở Việt Nam và giáo viên Filipino, để giúp học viên trở nên tự tin và nói lưu loát hơn với các khóa học Giao tiếp, tiếng Anh trong công việc (học 1-1). Liên hệ mình để biết được thông tin nhé, giá từ 129K/60p học.
4.4 Ngẫm nghĩ thêm
Ngoài ra gần đây mình cũng nghe được 1 chia sẻ từ anh Viruss, nó thực sự thấm với mình nên cũng muốn chia sẻ lại cho các bạn.
Theo luật vận động của vũ trụ, nếu bạn không trao dồi kiến thức, bạn không trao đồi bản thân về mặt kiến thức. Thì bạn sẽ luôn luôn bị chững lại hoặc bị lún, phải trao đồi liên tục, vì cá nhân của chính bạn. Càng làm việc, thì càng ra nhiều thứ, và cách nhìn về cuộc sống sẽ đa dạng và theo nhiều chiều hướng khác nhau.
Mình chỉ để đây để bạn đọc và mình cùng suy ngẫm.
5. Tóm tắt
Tóm tắt lại bài viết, mình muốn truyền tải với các bạn:
Công cụ lao động thời nay chính là “tri thức”.
Nâng cao trình độ giúp bạn không bị thay thế bởi robot và những người khác.
Nạp kiến thức không chỉ từ 5->22 tuổi, mà nó nên đi theo suốt cuộc đời bạn.
Tiếng Anh là 1 trong 3 ngôn ngữ phổ biết nhất thế giới, học tiếng Anh giúp bạn dễ dàng hơn trong việc trở thành công dân toàn cầu.
Hãy luôn trao dồi kiến thức vì cứ qua mỗi giây thì kiến thực lại bị cũ đi 1 ít.
Bài blog này mình muốn chia sẻ rằng mình đã thực hiện UAT như thế nào ở công ty mình đã làm việc.
1. Giới thiệu
Ý tưởng bài viết này cũng xuất phát từ câu nói “UAT không phải là kêu BA tới rồi test trong vòng 2h là xong.” trong bài: UAT (User Acceptance Testing). Và vì mình cũng từng UAT với chỉ 2h là xong, do đó ngồi nhìn nhận lại những gì mình đã làm với UAT.
Qua bài của mình các bạn có thể biết được mình đã làm UAT ra sao, những cái gì mình đã làm được, những cái gì mình chưa làm được. Và các bạn có thể tự áp dụng vô chính bản thân và cho mình đôi lời nhận xét xem mình đã làm UAT đúng chưa nhé.
2. Khái niệm
Theo như nhiều tài liệu mình đọc được thì UAT (User Acceptance Testing – Kiểm thử chấp nhận) là một loại kiểm thử được thực hiện để xác nhận rằng cái sản phẩm/tính năng mình làm ra có đáp ứng nhu cầu của người dùng hay không? Và nó được thực hiện trước khi sản phẩm được release.
3. Sai lầm của bản thân
Mình từng thực hiện UAT theo 1 khái niệm mà mình tự thấy là chính mình đã từng hiểu chưa tường tận. Đó là mình làm 1 cái checklist những tính năng cần phải đáp ứng từ những requirement và check nó trong vòng vài tiếng. Và nhận ra rằng mình đã thiếu sót trong việc thực hiện UAT.
Sau vài lần làm như thế thì đọc được nhiều tài liệu hơn về UAT, cũng như được hướng dẫn thì mình áp dụng 1 số phương pháp khác, mà tự đó nhận ra được bầu trời của UAT.
4. Những điều mình đã làm với UAT
4.1 Khảo sát, phân tích và thảo luận về tính năng sẽ làm thật kỹ
Trước khi làm tính năng/dự án, mình, team lead/PM hay thường đặt ra vấn đề là tính năng này sẽ làm như thế nào, có cần thiết cho end-user hay không?
Nếu câu trả là không? Thì hỏi lại khách hàng, cũng như trao đổi về sự cần thiết của tính năng với khách hàng để tránh lãng phí thời gian cũng như cost dự án.
Vậy đây mình nghĩ nó đã là bước đầu tiên của UAT rồi. Xác định nhu cầu của end-user về tính năng/dự án thật kỹ.
4.2 Verify theo checklist
Tự mình kiểm tra xem là sản phẩm làm ra đúng tính năng như khách hàng mong muốn từ ban đầu hay không, vì mình làm việc trực tiếp với khách hàng, lấy yêu cầu từ họ và từ đó phân tích đưa ra cái họ mong muốn, và với sự confirm the last requirement của khách hàng=> Mình cũng hiểu về sản phẩm và tự test lại sản phẩm theo checklist và coi đạt yêu cầu theo requirement để đưa cho khách hàng chưa? Này theo mình được biết nó gọi là: Contract Acceptance Testing
Mình sẽ chỉ đi những flow đảm bảo luồng chính (primary testcase) mà mang lại benefit cho End-user vì mình khá tin tưởng team QC của mình làm khá tốt với những case theo tech hay doc, vì mình luôn review test case của QC dự án (dự án gần nhất mình làm) sau khi họ hoàn thành bộ test case.
4.3 Nhờ nhân viên trong công ty support test
Gửi cho những member trong công ty để support test kiểu dùng như 1 end user và nhận feedback từ họ. Mình thấy 1 thiếu sót đó là không thể quan sát hết được họ đã sử dụng phần mềm như thế nào, có gặp trouble gì khi dùng sản phẩm/tính năng không? Nhưng mình tự nhận thực hiện UAT như thế nào cũng xem là chấp nhận được vì cũng lấy được feedback từ họ.
Vì mình biết có một số sản phẩm, tính năng trước khi được ra mắt thị trường thì họ sẽ mời end-user thật để tới văn phòng và cùng dùng sản phẩm. Kiểu như trong game Liên Minh Huyền Thoại, khi ra 1 tướng mới hoặc có chỉnh sửa, sẽ mời các game thủ tới chơi thử để đánh giá nhân vật trong game, quay video quan sát hành động của họ, từ đó phân tích ra là nhân vật đã ok chưa.
4.4 Gửi khách hàng verify bước cuối
Gửi cho khách hàng, và PM của mình share cho họ về tính năng được làm ra, nhưng không quá chi tiết. Sau đó họ sẽ dùng, và lấy feedback từ họ, xem có bug gì ở đó hay không? Vấn đề gì về tính năng, cũng như vấn đề UI/UX, nội dung của sản phẩm không? Từ đó team mình chỉnh sửa cho phù hợp.
4.5 Gửi bạn bè dùng thử
Thỉnh thoảng nếu project kiểu release rồi, nhưng mình vẫn muốn check lại để kiểm tra lại thực sự sản phẩm có tốt hay không? thì mình gửi cho bạn bè mình xem và đánh giá. Một điều đáng buồn là project hùi trước mình làm, luôn nhận kiểu than phiền là website truy cập load còn chậm. :(((( buồn quá buồn. Nhưng không sao, team vẫn đang cố gắng khắc phục vụ web chậm, phải làm từng bước để cho sản phầm ổn định dần chứ, bùm 1 cái đâu thể nói phát là web nhanh liền được đâu.
Cách này mặc dù sản phẩm/tính năng đã golive rồi, nhưng mình vẫn nghĩ nó là 1 phần nhỏ trong UAT
4.6 Thực hiện A/B testing
Ngoài ra để đánh giá về việc sản phẩm/tính năng làm ra có thu hút của người dùng hay không thì mình có áp dụng A/B testing vào. Và đặt tracking lên web để xem hành vi người dùng, xem họ click vào đâu nhiều,… từ đó rút ra được kết luận từ sản phẩm/tính năng nào phù hợp hơn với người dùng. Nhưng hơi buồn vì mình rời dự án trước khi được rằng A/B testing được gắn xong chưa (do dev gắn), và xem được số liệu từ phân tích :(( buồn như con chuồn chuồn.
Cách này cũng sau release sản phẩm, nhưng nó là cần thiết để xác định rằng sản phẩm có phù hợp với nhu cầu của end-user hoặc loại nào của tính năng thì phù hợp hơn. Như facebook vẫn thường thực hiện khi ra một tính năng mới.
5. Những điều mình chưa được thực hiện khi UAT
Chưa có nhiều kinh nghiệm làm việc với End-User, chỉ làm việc với bên khách hàng. Và cũng chỉ là làm những cái liên quan đến phân tích gắn js để kiểm tra độ tương tác của User thôi. Chưa tổ chức được nhóm user để xem hành vi sử dụng sản phẩm như thế nào, hay quay video lại để xem họ sử dụng như thế nào.
Những loại thực hiện UAT khác mà mình chưa biết tới.
Mình chỉ mong là mình sẽ có cơ hội làm những task như thế này ở cty mới.
6. Kết luận
Mình thực hiện UAT không phải chỉ ở giai đoạn trước khi release sản phẩm, mà đã bắt đầu thực hiện nó khi feature được đưa ra để làm. Và cả sau khi sản phẩm được lên thớt. Và có thể trả lời được là BA/PO có phải là người thực hiện UAT hay không? hay còn những roles khác cùng thực hiện nữa.
Hi vọng nhận feedback từ mọi người về bài viết cũng như kiến thức về UAT.
Mình cũng vừa tiếp cận với vị trí BA trong thời gian cũng không quá lâu, khoảng hơn 7 tháng làm công ty và 2 tháng freelancer với vị trí front-end kết hợp BA.
Mình muốn chia sẻ những công cụ mà giúp ích mình trong công việc (BA), hi vọng qua bài này có thể giúp bạn đọc tìm hiểu thêm được 1 số công cụ mới, phù hợp với chính bạn.
Và đa số những tool này đều là free, nên rất dễ dàng cho các bạn sử dụng mà không tốn phí.
1. Tool quản lý task/document
1.1 Jira/Confluece:
Chắc cũng rất rất nhiều bạn đã biết về phương pháp phát triển phần mềm, framework Scrum hay là Agile rồi nhỉ? Thì Jira là một trong những công cụ không còn quá xa lạ, nó là ứng dụng theo dõi, quản lý lỗi/vấn đề trong dự án, theo mình thấy trong Jira hay gọi chung là Issue.
Mình khi vừa bắt đầu đi làm công ty đầu tiên, đã tiếp cận ngay với anh Jira này rồi, và cực kì thích cách hoạt động của ảnh.
Hình về Jira, mình chôm trên mạng, k dám chụp bậy bạ Jira của công ty đâu.
Thứ nhất, ảnh bám sát theo mô hình scrum, agile mà ra cái tool này, mà xu hướng hiện giờ đa số các công ty IT đều theo framework này, do đó mà được nhiều công ty ưa dùng, mình cũng ưa nữa =)). Ưa cả framework Scrum lẫn Jira.
Thứ high: Ảnh có support thay đổi workflow theo từng project, quá tuyệt vời luôn. Tùy thuộc vào team/dự án, mà workflow nó khác nhau. Do đó nhờ vào việc có thể dễ dàng thay đổi workflow mà mình custom cho mỗi dự án. Tuyệt vời ông mặt trời.
Thứ bar: Công cụ tìm kiếm cũng rất tốt, chỉ cần search theo bất kì từ nào nhớ về task, có thể tìm nó ra ngay lập tức luôn. Quên mất title của task => Search bằng description cũng ra nữa.
Search bằng description cũng ra được nè Có thứ born, … các kiểu nữa. Nếu quan tâm về nó thì tìm hiểu thêm nhoa.
Đi kèm với anh Jira, thì có anh Confluece, mình hay gọi ảnh là công cụ lưu trữ document, nhưng các chỗ khác thì gọi là tích hợp nội dung đa phương tiện. Anh này mình thấy tiện nhất đó là tích hợp với anh Jira phía trên. Khi mình gắn task Jira lên Confluece, thì từ Confluece, với 1 cú click là ảnh nhảy qua anh task Jira liền, và ngược lại cũng vậy.
Mình dùng công cụ này để tạo các trang trao đổi Q/A, document, guideline, ghi lại ticket đã làm trong tháng, một số lưu ý, các kiểu con đà điểu.
Đây là ví dụ về gắn ticket từ Jira qua confluence, khi click vô Search ticket, nó mở ngay trang ticket này trên Jira liền.
Nhưng hai anh Jira và Confluence muốn dùng phải trả phí nhá, có 2 phiên bản On Cloud và Hosted on your server. Muốn dùng hàng ngon thì phải trả phí thôi.
Anh Trello này mình hay dùng thời sinh viên, thời còn làm cho Hội sinh viên trường với làm ở Đội Công tác Xã hội. Ban đầu dùng nó để chủ yếu quản lý công việc, phân công, và mọi thứ lưu hết trên trello này, rất dễ sử dụng. Và đặc biệt là FREE.
Đây, 1 mớ board lúc trước mình dùng Trello
Trello là một công cụ để quản lý công việc một cách hiệu quả, giúp cho ta có thể dễ dàng nhìn vô là biết mình cần làm gì, ai đang làm, cái nào đã được hoàn thành. Có thể gọi ngắn gọn là một bản Kanban cũng được.
Cái mình thích ở Trello đó là có thể một công việc có rất nhiều cái công việc con trong đó. Giả sử đi chợ mua đồ, mình có thể list hết những thứ cần mua: Gạo, cá, rau muống, quần s, … khi mua xong nào thì check vô.
Ngoài ra còn thích cái pẹt pẹt của nó nữa. Cái pẹt pẹt này là khi xong task, hoặc cần kéo task đi đâu, thì kéo pẹt 1 phát, nó qua list khác liền.
Đây là 1 project MĐYT 2017 của Đội CTXH UIT thời đó làm, quản lý bằng công cụ Trello.
Mình mới biết đến Asana khi làm ở công ty Kyanon.digital thôi, mới vô công ty có tờ checklist, được add vô Asana của team, thế là mình biết Asana :)).
Cũng như trello, thì Asana là một trong những công cụ quản lý dự án khá là tốt, thiên về quản lý tiến trình.
Asana là gì??
Mình thấy cái hay của Asana đó là rất dễ dàng để tạo task, tự mình tạo hoặc tạo cho đồng đội cũng được luôn, quản lý công việc theo bảng, hoặc theo dạng như danh sách, có thể dùng tag để đính kèm thể hiện cho status của task. Và một cái rất rất hay đó là 1 task có thể gắn với nhiều project liên quan.
Asana cung cấp 1 phiên bản free với số lượng user không quá 15 người. Mình nghĩ số lượng này rất phù hợp cho 1 team. Còn nếu team nhiều người quá thì phải bỏ tiền ra mua để dùng thôi. 😀
1.4 Bộ công cụ của MS: Excel/Word/PP và bộ online của nó
Nhắc tới 3 cụ cậu này, thì đa số điều biết hết nhỉ.
Mình thì thường dùng Excel như một bộ quản lý issue, checklist khi thực hiện UAT, hay dùng xây dựng test-case. Thỉnh thoảng dùng như một bộ matrix để đánh giá, đặt question, đánh giá mức độ các kiểu….
Word viết document, release note, demo script,…
Còn anh PP thì note bug trên này luôn cũng khá tiện, làm slide trình bày, hoặc vẽ vời.
1.5 Công cụ quản lý khác
Ngoài những công cụ phía trên, thì mình cũng đã từng sử dụng 1 số tool khác như: TFS (ở công ty cũ), MindMeister (tự tìm hiểu), Ms Project, Bitrix. Các bạn có thể kham khảo thêm để sử dụng nhé.
2. Tools vẽ
2.1 Balsamiq Mockups
Đây là một công cụ mình cực kì hay dùng trong các dự án mình làm BA. Tên của phần mềm có chữ mockup, nhưng mình dùng chính vẫn là để vẽ wireframe. Còn để biết sự khác nhau giữa sketch, wireframe, mockup, prototype thì xem qua bài viết này nhé.
Dưới đây là một demo mình vẽ wireframe các version khác nhau cho tính năng share một bài viết qua email….
Share một bài viết thông qua email – mockup
Để tìm hiểu thêm về phần mềm này, liên hệ mình cho key dùng vài năm nè 😀
2.2 Adobe XD
Thường sau khi đã có phiên bản wireframe, mình lười nên hay bỏ qua bước vẽ mockup lắm, vọt luôn qua bên anh Adobe XD để vẽ luôn prototype mode.
Đây là một công cụ hoàn toàn free (trước kia phải mua), và nếu ai đã dùng qua các công cụ khác của Adobe, thì sử dụng công cụ XD cực kì đơn giản.
Trước mình hay vọc photoshop, AI, lightroom nên khi qua XD cũng không cần phải học gì để sử dụng cả. Vọc 1 buổi là biết dùng ngay.
Ngoài ra còn hỗ trợ rất nhiều bộ UI Kit khá là ngon để tạo một prototype một cách nhanh chóng. Ảnh có luôn phần điều hướng khá dễ sử dụng (gần giống như của Xcode), khi Dev xem qua prototype có thể biết được từng nút sẽ hoạt động như thế nào, click vô thì cái gì sẽ được xuất hiện. Còn nếu anh Dev không cài XD thì có thể mình record lại cách hoạt động (Workflow) của sản phẩm mình đang làm, và gửi video cho anh dev là được rồi.
Đây là 1 video lúc mình học năm 3, lúc đó còn code nên cũng vẽ prototype lấy loeeeeeeee.
Video demo cho ứng dụng hẹn hò – code bằng React Native, build bằng Xcode
Nhưng thực tế thì cái này mình chỉ dùng khi trước kia làm tự do, hoặc làm đồ án gì thôi. Chứ hiện tại team mình có 1 anh Designer, do đó mình chỉ vẽ wireframe, còn chuyển về prototype hay mockup thì ảnh cân tất. Ảnh dùng sketch trên MacOS với https://Invisionapp.com để mọi người trong team có thể xem được design trên cloud, cũng như workflow giữa các design.
Tìm hiểu và download XD tại đây nhé: https://www.adobe.com/products/xd.html
Ngoài ra các bạn có thể tìm hiểu thêm một số tool mình từng dùng liên quan đến vẽ như: Photoshop, AI, Sketch, Photoshop online khi vào đúng máy quên chưa cài pts.
2.3 Draw.io
Xong phần về design thì mình sẽ tém lại, và nhảy qua phần vẽ liên quan đến workflow, diagram, gọi chung là các sơ đồ. Phần các sơ đồ, thì mình sẽ viết một bài khác nhé.
Hầu như các sơ đồ liên quan đến BA mình hay vẽ, đều dùng tool này.
Trước kia thì có dùng StarUML khi còn là sinh viên năm 2, với các môn học phân tích thiết kế hệ thống thông tin, phương pháp mô hình hóa, đặc tả hình thức các kiểu.
Và cũng từng dùng qua MS Visio, nhưng khi biết đến anh Draw.io, thì mình quên luôn 2 công cụ kia.
Rất mạnh mẽ, hỗ trợ nhiều hình khối, kéo thả cũng rất lẹ.
Chạy online, không cần cài đặt j hết. Cứ mở draw.io trên browser và sử dụng thôi.
Hoàn toàn miễn phí
Có thể lưu xuống local để lúc khác sử dụng tiếp, hỗ trợ export dưới dạng xml, html, và image
Có thể vẽ đủ thể loại các sơ đồ thiết kế hệ thống, template cực kì phong phú.
Đây là 1 workflow mình vẽ chơi.
Workflow cho tính năng login/signup/forgot password. Sử dụng draw.io
2.4 Bizagi
Phần mềm này là một phần mềm thiên về vẽ các mô hình, tài liệu BPMN.
Khá là dễ sử dụng, cảm giác nó rất giống với các phần mềm office. Hỗ trợ xuất sang các tài liệu như word, PDF, Visio, và tool này được sử dụng free nha
Một ví dụ được vẽ từ BizAgi
Tìm hiểu thêm về BizAgi tại: https://www.bizagi.com/
2.5 Microsoft Visio
Ứng dụng này thì đến 2019 khi làm việc tại VNPAY mình mới sử dụng, và sài ẻm suốt 2 năm làm việc tại đây.
Đây là một ứng dụng giúp bạn xây dựng nên những bản vẽ vô cùng trực quan cùng với những bộ template có sẵn, do đó bạn sẽ không tốn quá nhiều thời gian để xây dựng nên những bảng vẽ Activity, Diagram, …
Hình chôm trên mạng về Visio
2.6 Giấy A4 và bút
Một trong những công cụ mình không thể thiếu để vẽ đó là Giấy A4 và bút, mình hay chôm giấy A4 từ máy in của công ty, sau đó dùng để phân tích, vẽ phát họa các idea, các sketch cơ bản, hoặc đơn giản là ghi ra những ý trong bộ checklist.
Mình nghĩ khi là 1 BA, thì đây là một công cụ cực kì cần thiết, bởi vì khi sử dụng giấy và bút, mình nghĩ gì là viết, vẽ ra liền… để có thêm thời gian nghĩ về những ý khác.
Một ví dụ về sử dụng giấy vẽ Sketch
3. Tool ghi idea/brainstorm
3.1 Gloomaps.com
Tool này mình mới lượm nhặt được cách đây 3-4 tháng, thực sự rất thích tool này vì nó thuộc dạng tool vẽ sitemaps cơ bản, chỉ cần ghi vài từ trên các thẻ card, xong nhấn Save thì sẽ xuất ra 1 URL, có thể share bất kì ai xem. Không cần tạo tài khoản, không cần đăng nhập, và hoàn toàn free. Và cực kì dễ dàng export ra pdf, png, xml
Mình hay dùng công cụ này dưới dạng là ghi các idea, các đại ý mà mình đang tập trung chú ý phân tích, từ đó dựa theo kiểu cây thư mục, phát triển thêm ý.
Và dễ dàng drag & drop các thẻ card sang vị trí khác.
Ví dụ đây là các ý, các loại tool mình chuẩn bị trước khi viết bài này.
Tìm hiểu tool tại: https://www.gloomaps.com
Ngoài tool này thì trước kia mình cũng có sử dụng các tool mindmap, nhưng vì phải tốn công đăng nhập, bị giới hạn như export file các kiểu thì mình từ bỏ, và chuyển sang sử dụng luôn gloomaps. Thấy tool nào tiện với bản thân thì sử dụng thôi. 😀
3.2 Giấy, bút:
Cũng là một trong những công cụ mình cực kì hay dùng để ghi các đại ý, idea để phân tích các tính năng trong phần mềm.
3.3 Google.com
Thỉnh thoảng bí ý tưởng, hay phân tích bị bí, hoặc gặp domain mới thì mình hay dùng anh Gu Gồ để tìm giải pháp.
3.4 Công cụ Sticky Note
Không cần phải cài đặt gì hết khi bạn đang dùng Windows 10, nhanh chóng để mở lên và ghi note thật nhanh vào, hoặc có thể ghi liền một thông tin gì được nghe. Hoàn toàn miễn phí, dễ sử dụng, linh hoạt với nhiều màu sắc khác nhau.
Ví dụ về Sticky notes mình lấy từ google image
4. Tool capture/record
4.1 FSCapture
Trước kia khi còn dùng MacOS thì mình hay dùng ScreenFlow, nhưng khi chuyển sang windows lại thì mình dùng FSCapture.
Cái mình thích ở tool này đó là công cụ hỗ trợ quay screen rất lẹ, có hỗ trợ tổ hợp phím để bật lên quay lẹ, và tool hoàn toàn free, có thể quay màn hình, thu âm từ Micro, hoặc thu âm từ trong desktop.
Và thường mình dùng công cụ này để ghi lại những bug xảy ra mà chỉ có quay lại màn hình mới thấy, chứ screenshot thì không thấy, do đó nhu cầu của mình chỉ quay và lưu lại thôi, nên tool này không có công cụ chỉnh sửa cũng là không có quá thiếu với mình.
Giao diện của tính năng screen recorder – FSCapture
Thực tế tool này cũng có hỗ trợ phần screenshot, nhưng mình có dùng 1 tool khác đã quen nên mình dùng đúng tính năng screen recorder của FScapture thôi.
4.2 Greenshot
Greenshot là công cụ tình cờ search trên google, và download về dùng thử. Nhưng mình cực kì ưa thích tool này.
Có thể tùy chỉnh bộ tổ hợp phím tắt để mở tính năng screenshot rất nhanh, từ đó khi gặp bug hay cần ghi lại 1 hình ảnh trên desktop, mình chỉ cần nhấn Alt + 3 là có thể kéo và ghi lại khu vực cần ghi.
Ngoài ra có những action ví dụ như hover vô button thì button đổi màu, thì kha khá nhiều tool screenshot khó có thể ghi lại được khoảnh khắc này, vì khi bật tool lên thì hiệu ứng hover bị mất. Nhưng tool này thì lại không bị mất, hoàn toàn có thể ghi lại nhanh chóng.
Ngoài ra các tính năng khác như vẽ hình ảnh tròn, chữ nhật, mũi tên, line, text cũng giống như những tool edit image khác.
Nhưng có hỗ trợ phần đánh số thứ tự rất nhanh, đặc biệt mình hay dùng để đánh thứ tự từng bước trong một hình ảnh khi xây dựng guideline hoặc demo script.
screenshot nhanh phần vừa viết phía trên
Tool này hoàn toàn free, có thể download tại đây: https://getgreenshot.org/
5. Tool testing
Thật ra để kể về tool testing thì khá là nhiều, tùy thuộc vào từng loại test mà dùng tool khác nhau, nhưng dưới đây là một số tool mình hay dùng và mình nghĩ là 1 BA cũng có thể dùng để hỗ trợ cho việc phân tích.
5.1 Email
Thường mình test các trang web mình sẽ không dùng email thật để test, mà sử dụng mailinator.com như là một nơi để nhận email.
Cái lợi của mailinator đó là không cần phải đăng ký tài khoản hay đăng nhập gì hết, mà còn free nữa chứ.
Chỉ đơn giản 3 bước. Truy cập mailinator.com, gõ phần mail muốn dùng, enter và check mail. Không cần đăng nhập, có thể dùng với hàng trăm/hằng ngàn email khác nhau mà không phải tốn phí.
Email ở mailinator sẽ bị xóa sau vài giờ, do đó ta không cần tốn công phải xóa những email đã được gửi đến để test.
Nhưng mailinator có thể sẽ bị 1 số nhà cung cấp lớn chặn, ví dụ như facebook, google,… do đó ta sẽ chuyển qua dùng email 10 phút. (search mail 10 phút trên gg là ra đầy)
Hoặc bị chặn luôn, thì mình lại dùng email với domain cá nhân và đăng ký thông qua zoho… ví dụ như email: [email protected] với phần đuôi phía sau là domain mình mua riêng. Hoặc mua mấy domain free 1 năm rồi tạo mail cá nhân bằng zoho cũng free nốt.
Tương tự đó, bạn cũng có thể sài sdt trên mạng free nếu cần nhận OTP qua sddt như cách sài email 10 phút nhé…
5.2 Audit của DevTool google chrome
Audit hay được gọi là tool Lighthouse, có sẵn trong chrome browser. Dùng để phân tích một trang web với performance, accessibility, SEO, PWA, Best Practices. Nhằm để biết được trang web mình đang phân tích như thế nào, từ đó lên được biện pháp, cũng như phân tích thêm về trang web để giúp cho chất lượng trang web tốt hơn.
Chỉ cần bật devtool lên (Inspect) => xong chọn tab audit => Chọn type cần analyst => click button analyst => là xem được kết quả.
5.3 Wappalyzer
Đây là một extension của google chrome, tool này là một công cụ có thể giúp mình biết được website mình đang xem thuộc nền tảng nào.
Như ở đây mình biết website mình đang sử dụng là làm từ wordpress và dùng hệ database MySQL
5.4 Chuyển file nhanh từ device này sang device khác.
Công cụ mình hay dùng đó là dropbox, mình cài app dropbox trên device, và khi có gì cần chuyển, mình đẩy lên thư mục ở dropbox, và tải xuống ở một nơi khác.
Mình thấy nhiều bạn hay dùng zalo, facebook để chuyển hình screenshot từ điện thoại qua desktop, nhưng hình ảnh dễ bị mất chất lượng.
Nhưng lưu ý khi dùng dropbox, tránh để chế độ tự động sync nha, không khéo hình nóng của bạn up lên dropbox chung của công ty hay sao đó thì lại cháy hết mắt của mọi người. 😀
Hoặc mình cũng hay up lên drive, và share bằng URL để cho người khác có thể xem file của mình.
6. Call/trao đổi công việc
Phần này chủ yếu là để share một số tool mình hay dùng, vì tool để trao đổi là một trong những công cụ buộc BA phải biết, tùy thuộc vào team, dự án, khách hàng mà sử dụng khác nhau.
Dưới đây là những tool mình hay dùng:
Zoom: Hỗ trợ call meeting, với tính năng share màn hình mạnh mẽ, hỗ trợ đa nền tảng.
Skype: Call meeting theo nhóm hoặc 1/1 khá tốt, share màn hình.
GG Meet
Facebook/workchat
Zalo: Chủ yếu là nhắn tin, call video 1/1
Slack: Chat trong công việc là nhiều, hỗ trợ tạo nhiều kênh nhỏ để trao đổi công việc lẹ.
Lời cảm ơn
Cảm ơn các bạn đã theo dõi hết bài viết của mình nhé. Có gì để lại comment để mình biết lời bình luận của các bạn với nhé.
Thời gian vừa rồi mình có tìm hiểu cách để nội dung của một trang web có thể tiếp cận với các đối tượng người dùng khuyết tật như bị khiếm thị, khiếm thính, suy giảm vận động…
Và chuyên mục này mình sẽ chia sẻ những kiến thức mình đã tìm hiểu được, làm sao người khuyết tật tiếp cận được với sản phẩm của bạn, cách bạn đưa trang web tiếp cận với các đối tượng khuyết tật.
Accessibility – Chôm từ google image 😀
TỔNG CHUNG CHUYÊN MỤC NÀY MÌNH SẼ CÓ 3 PHẦN
+ Phần 1: Hiểu về WCAG
+ Phần 2: Cách người khuyết tật tiếp cận với website của bạn
+ Phần 3: Lộ trình đưa website đến với người khuyết tật
PHẦN 1: HIỂU VỀ WCAG
1. WCAG là gì?
Để tìm hiểu về cách người khuyết tật tiếp cận với website, thì ta hãy tìm hiểu về bộ tiêu chuẩn WCAG để biết nó giúp gì cho việc tiếp cận nhé.
WCAG là một bộ tiêu chuẩn trong xây dựng website, được tổ chức W3C đưa ra nhằm xác định cách làm cho nội dung Web dễ tiếp cận hơn với người khuyết tật.
Tài liệu chính gốc của WCAG tại đây nha: https://www.w3.org/TR/WCAG21/
2. 4 Nguyên tắc
Nó có 4 nguyên tắc chính đó là: perceivable, operable, understandable, và robust.
1. Perceivable
Các thành phần thông tin và User Interface phải được trình bày sao cho người dùng không chỉ là đọc mà có thể thông qua các thiết bị khác, người khuyết tật có thể cảm nhận được nội dung của thông tin.
Khi một hình ảnh bị thiếu Alt text, thì các thiết bị/app reader screen không thể đọc được nội dung của hình ảnh. Người dùng (mù/khiếm thị) sẽ không biết hình ảnh này diễn tả về điều gì cả.
2. Operable
Các thành phần về giao diện và navigation có thể hoạt động tốt. Web của bạn phải làm sao đó để thông qua các thiết bị như keyboard, nút ấn, … mà vẫn điều khiển được web của bạn 1 cách dễ dàng. Như cách thay đổi focus, cấu trúc của page, thời gian đọc và sử dụng nội dung, di chuyển từ module này sang module khác trên cùng 1 page mà người dùng có thể cảm nhận rằng họ đang ở vị trí đó của trang web của bạn.
Các trang tự động redirect, thì nên có thời gian đủ để những người khuyết tật như mù lòa, thị lực kém, hạn chế về nhận thức có thể cần nhiều thời gian hơn để đọc nội dung. Do đó cần thiết kế lượng thời gian cho phù hợp.
3. Understandable
Các thông tin và operation của UI phải dễ hiểu, thiên về nội dung của trang web phải dễ đọc, dễ hiểu, điều hướng nhất quán, dễ đoán được hướng của điều hướng, giúp tránh lỗi hoặc có lỗi với các thông báo lỗi rõ ràng, …
tabindex cần đặt sao cho phù hợp, nhất quán, dễ đoán để người dùng dễ điều hướng khi sử dụng các thiệt bị như Single-switch access device, bàn phím, …
4. Robust
Các nội dung cung cấp phải đủ mạnh để diễn tả từng thành phần một cách đầy tin cậy đến với user agents và các công nghệ hỗ trợ. Thông qua parsing, cách đặt name, role, và value cho các thẻ html, cách truyền tải status message .
Với 1 popup (div), để đóng popup này thì thông qua element “X”. aria-lable=”Close” được sử dụng để cung cấp một name cho các công nghệ hỗ trợ có thể truy cập vào nút “X”.
3. Đánh giá qua 3 cấp độ
Và WCAG nó đánh giá các tiêu chuẩn (gọi là tiêu chí thành công) dựa vào 3 cấp độ (A-AA-AAA). Vì các tiêu chí thành công được tổ chức dựa trên tác động của chúng đối với thiết kế, cấp độ càng cao, thiết kế càng trở nên gò bó.
Cấp độ A – một số tác động đến thiết kế.
Cấp độ AA – tác động trung bình đến thiết kế
Cấp độ AAA – tác động cao đến thiết kế
Với 3 mức độ này, thì có thể cùng 1 thể loại tiêu chí, nhưng nó có 3 mức. Khi bạn vượt qua được cấp độ AA, nghĩa là cấp độ A của tiêu chí đã được đáp ứng. Và theo những tài liệu mình tìm hiểu được, thì khuyến nghị nên đạt đến level AA.
Để rõ hơn, thì xem thử ví dụ này nhé, trong Guideline 1.4 Distinguishable.
Tiêu chí thành công 1.4.1 – Use of Color – level A. Mục đích của Tiêu chí Thành công này là đảm bảo rằng tất cả người dùng có thể truy cập thông tin được truyền tải bởi sự khác biệt về màu sắc, nghĩa là bằng cách sử dụng màu sắc trong đó mỗi màu có một ý nghĩa được gán cho nó.
Tiêu chí thành công 1.4.3 – Contrast (Minimum) – level AA. Trình bày trực quan của văn bản và hình ảnh của văn bản có tỉ lệ tương phản ít nhất 4,5: 1
Tiêu chí thành công 1.4.6 – Contrast (Enhanced) – level AAA. Trình bày trực quan văn bản và hình ảnh của văn bản có tỷ lệ tương phản ít nhất là 7: 1
Hiện text #FFFFFF trên nền xanh #65A5BF chỉ đáp ứng là sự khác biệt về màu sắc, ratio =2,73 < 4.5. Do đó chỉ đáp ứng được tiêu chí thành công A (1.4.1)
Để đạt được tiêu chí AA thì phải thay đổi nền xanh thành #00819F để đạt ratio 4.53 khi đó nó sẽ đáp ứng luôn cả tiêu chí thành công A (1.4.1) Hoặc để đạt luôn tiêu chí AAA thì sẽ phải thay đổi nền xanh thành #006179 để ratio = 7.03.
Như ví dụ trên ta thấy chỉ đạt được level A, thì khi xem trang web này trên 1 device ở 1 môi trường quá sáng, thì có thể sẽ không đọc được chữ do tỉ lệ contrast quá thấp, hoặc những người bị khiếm thị hoặc thiên về bị bệnh về màu cũng khó mà đọc được những text #FFFFFF trên nền #65A6BF trong môi trường bình thường. Còn khi thay đổi đến level AAA sẽ ít còn bị các vấn đề về contrast, nhưng có thể thay đổi nguyên bộ thiết kế, cũng như bộ màu trên trang web.
Từ đó ta có thể thấy là level càng cao thì càng khó đáp ứng, và sẽ vượt qua được level cao hơn, thì level thấp sẽ được đáp ứng.
4. Vì sao áp dụng WCAG lại quan trọng?
Bình đẳng không gian mạng cho tất cả mọi người
Người khuyết tật dễ dàng sử dụng
Tạo ra sự khác biệt lớn cho người dùng của bạn và có thể giúp ngăn chặn các vấn đề hoàn toàn có thể tránh được.
Thu hút một lượng người đọc/tham gia khá lớn.
Giúp đáp ứng các nhu cầu và đảm bảo khách truy cập trang web có trải nghiệm tốt nhất có thể khi truy cập.
Khảo sát về người khuyết tật Canada báo cáo rằng hơn 80% người khuyết tật sử dụng ít nhất một thiết bị hỗ trợ. Do đó để các thiết bị hỗ trợ đọc được nội dung website của bạn, thì nên đảm bảo được các tiêu chí thành công của WCAG.
Cảm ơn bạn đã đọc hết phần này của mình, cùng đón xem 2 phần tiếp theo nhé.
Bài blog này được viết thời điểm mình gặp Khoa và Linh tại 1 quán CF ở quận 9 vào đầu tháng 4/2019. Được Niviki.com (Khoa) phỏng vấn và chia sẻ đến mọi người, nay mình đăng lại trên blog mình để mọi người cùng đọc nhé.
1. Giới thiệu
Hoàng Phan là bạn đại học của mình, hiện tại Hoàng đang là Business Analyst tại Kyanon Digital (2018-2019). Thực ra gọi là phỏng vấn nhưng đây cũng như buổi nói chuyện bình thường giữa mình với Hoàng thôi. Trong buổi nói chuyện còn có Linh Nguyễn nữa.
2. Nội dung
Khoa: Hoàng có thể giới thiệu bản thân với bạn đọc trên NIVIKI.COM được không?
Hoàng: Chào mọi người, mình là Hoàng hiện tại mình đang làm ở vị trí BA trong khoảng thời gian 6 tháng. Hết rồi 😀
Khoa: BA là công việc đầu tiên của Hoàng hay là trước đó Hoàng có làm gì không?
Hoàng: Trước đó mình có làm ở vị trí Quality Control (QC) khoảng 8 tháng, và có một thời gian mình làm freelance ở mảng frontend.
Khoa: Được biết Hoàng là Đội Trưởng đội Công tác Xã hội UIT có đúng không? Vậy thì kinh nghiệm làm Đội Trưởng đội Công tác Xã hội UIT có giúp ích gì cho công việc QC không?
Hoàng: Mình thấy rằng việc rèn luyện kỹ năng mềm, tham gia các tổ chức sự kiện thì nó giúp cho mình tự tin, trình bày nội dung rõ ràng và dễ hiểu hơn. Trước đó mình nói thì nó hơi bị vòng vòng. Sau khi mình tham gia các hoạt động dự án tình nguyện thì mình làm quen với việc trình bày nội dung của các buổi tình nguyện đến cho Tình Nguyện viên, chính quyền địa phương và từ đó dẫn đến khi đi làm mình cũng làm tốt làm việc ở QC và cả BA. Khi gặp khách hàng, dễ nói chuyện hơn, mình trao đổi với các thành viên trong team của mình như là dev, designer cũng sẽ tốt hơn.
Hoàng trong một buổi tổ chức hoạt động tình nguyện – Người quản trò đang cầm micro
Khoa: Hoàng có thể mô tả sơ sơ QC là làm gì không?
Hoàng: QC là đảm bảo cái mà dev làm ra chạy đúng requirement của khách hàng. Đảm bảo cho phần mềm chạy tốt hơn không có quá nhiều lỗi (phần mềm nào chẳng có lỗi :D).
Khoa: Phần mềm phải làm xong rồi mới kiểm tra lại hay là?
Hoàng: Thực ra thì dựa vào requirement, mình xây dựng ra những bộ test case
Khoa: Là viết test case trước khi dev làm
Hoàng: Không, cùng lúc với dev làm.
Khoa: Công việc đó (QC) Hoàng làm khoảng 8 tháng xong rồi nghỉ thì tại sao lại không tiếp tục công việc đó?
Hoàng: Thứ nhất là công ty quá xa vị trí mình ở. Thứ hai là ở trường mình có nhiều bài tập đồ án tốn khá nhiều thời gian cho nên mình không đảm bảo được thời gian để đi làm. Mình cũng đang muốn công việc của mình nó thiên về giao tiếp với khách hàng nhiều hơn nên mình quyết định nghỉ một thời gian để tìm hiểu về vị trí BA
Khoa: Vậy là QC sẽ không có nói chuyện gì với khách hàng đúng không?
Hoàng: Cũng có nhưng mà nó ít so với BA
Khoa: Ủa, vậy sẽ nói chuyện gì với khách hàng
Hoàng: Thường khách hàng sẽ hỏi là quy trình kiểm thử như thế nào? Sử dụng tool gì để test. Khách hàng có thể track bug ở đâu, trao đổi về Report Testing.
Khoa: Có khi nào khách hàng tự báo bug luôn không?
Hoàng: Có. Tất nhiên là sẽ không có phần mềm nào hoàn chỉnh 100%, sẽ luôn có bug. Thì khi khách hàng gặp Bug có thể đăng bug lên, QC có thể cùng trao đổi khách hàng: bug đó thỉnh thoảng bị hay là hay là luôn luôn xảy ra. Hay là do yếu tố bên khách hàng như mạng internet, thiết bị.
Khoa: Vậy là QC sẽ là người tìm ra nguyên nhân lỗi chứ không phải dev hả?
Hoàng: QC sẽ vào cái bug đó và làm lại xem có gặp bug đó hay không, gọi là reproduce Bug. Sau đó, QC sẽ liên hệ với dev để coi thử là bug đó có có thực sự là do dev hay là do vấn đề nào khác.
Khoa: Còn trường hợp cái bug đó không được không làm lại được?
Hoàng: Ừ thì mình cũng có một trải nghiệm như sau. Có một cái lỗi mà 7 người trong team mình đều không reproduce lại được. Thì mình có trao đổi với khách hàng là cứ để cái bug đó ở trong backlog. Một thời gian thì sau khoảng 2, 3 sprint thì cũng không gặp lại nó.
Khoa: Hoàng có nói là Hoàng thích làm BA vì được nói chuyện nhiều với khách hàng thì từ đâu mà mày có suy nghĩ như vậy. Tức là Hoàng tìm hiểu công việc BA ở đâu để quyết định chuyển công việc như thế?
Hoàng: Đầu tiên mình được bạn Khoa giới thiệu, sao không thử mảng BA đi. Vì Khoa biết mình làm Công tác Xã hội thì đi Khoa nghĩ là BA cũng hợp với mình.
Khúc này hơi deep tý nha mấy bạn, tại lỡ hỏi rồi. Thực chất thì công việc của Hoàng mình cũng hiểu phần nào rồi, chủ yếu để cho mọi người hiểu quá trình Hoàng làm việc ý mà. Thôi mọi người đọc tiếp nhé - Khoa.
Thực chất thì lúc đó cũng không biết 100% là hợp hay không nhưng mà mình đã quyết định bỏ thời gian ra tìm hiểu về vị trí này khoảng 3 tháng: Mình bắt đầu tìm hiểu là vị trí này công ty nào tuyển, tuyển có nhiều hay không, range lương như thế nào.
Rồi mình đọc các job description thì mình mới coi là mình thiếu cái kỹ năng gì từ đó thì mình đi học những cái mình thiếu
Khoa: Vậy cái thiếu đó là gì?
Hoàng: Thứ nhất là UI/UX, nhưng mình lợi cái là có tham gia Công tác Xã hội, biết được design, một ít về UI/UX và từng tìm hiểu rồi.
Khoa: Design đó có kỹ không, hay cái mức độ như thế nào?
Hoàng: Như là vẽ wireframe thôi, thấy design nó hợp lý, thân thiện với người dùng, hợp lý về UX, còn không nhất thiết phải quá đẹp hay gì đó. Thường thì muốn đẹp thì vẽ wireframe, đề xuất xong designer sẽ thực hiện bản hoàn chỉnh hơn.
Khoa: Còn kỹ năng nào nữa không?
Hoàng: Thứ hai đó là kỹ năng sử dụng các tool vẽ use case như draw.io. Nó online free và tiện lợi, có thể export ra PNG, lưu xuống máy dạng XML rất tiện.
Cái này mình hay dùng để vẽ các User Case, biểu đồ khi làm đồ án ở Đại học. Ngoài ra mình còn biết thêm những tool khác như Visio của Microsoft, Lucidchart.
Kỹ năng nữa cũng rất quan trọng đó là kỹ năng giao tiếp. Mình giao tiếp tiếng Việt cũng ổn, thì mình sẽ làm việc tốt với các bên ở Internal team (Việt Nam Team). Nhưng khách hàng đa số là người nước ngoài nên mình cần phải improve thêm về Tiếng Anh. Hiện tại mình chat với khách cũng tốt, nhưng về phần giao tiếp (nói chuyện trực tiếp) tiếng Anh còn hơi kém.
Kỹ năng quản lý thì mình tham khảo thêm về cách sử dụng các tools như Jira, TFS, đọc nhiều tài liệu về quản lý dự án, quản lý task để có sẵn lý thuyết, khi đi làm mình áp dụng luôn, đỡ tốn thời gian tìm hiểu khi đi làm.
Và tham gia các group trên facebook, cộng đồng BA để đọc những bài viết, những kinh nghiệm những anh chị đi trước đã trải qua, và chia sẻ lại để improve khả năng phân tích và giải quyết vấn đề.
Khoa: Hoàng thấy kỹ năng nào của QC giúp ích được cho BA
Hoàng: Thứ nhất là trong BA có QC. Cái mà mình thấy hay dùng nhất của QC là UAT (User Acceptance Testing – Kiểm thử chấp nhận). Và có thêm các kỹ năng về document, tức là mình đã làm quen với việc đọc document, requirement và xây dựng các test case tỉ mĩ từ khi làm QC, nên qua áp dụng cho BA cũng tốt hơn.
Khoa: Ủa vậy Hoàng có thể nói kỹ hơn sự khác nhau giữa test casse và UAT
Hoàng: Test case là mình test chi tiết từng trường hợp hơn. Còn UAT là kiểm thử chấp nhận. Tức là mình kiểm tra những cái case người dùng sẽ hay dùng nhất, phần mềm có đáp ứng cho tiêu chí chấp nhận và có sẵn sàng cho sử dụng không. Mình thường thực hiện nó thông qua một check list, có những tính năng mà cần người dùng UAT nhiều, thì nhờ các anh chị trong công ty vô thử, và chạy thử với mỗi người 1 trường hợp khác nhau, và xin feedback từ họ. Trước UAT là QC đã đảm bảo phần mềm chạy tốt rồi và UAT mình test lại để cho một user dùng những tính năng hay dùng nó chấp nhận được là ổn.
Khoa: Tức là UAT mình có thể đưa cho khách hàng coi và họ hiểu được, đúng không?
Hoàng: Ừm, đúng rồi. Họ xem và hiểu thông qua checklist mình xây dựng.
Khoa: Còn test case nó thiên về kỹ thuật hơn?
Hoàng: Đúng rồi, test case đôi khi kiểm tra những trường hợp rất là lắc léo luôn.
Khoa: Thì công việc mới của Hoàng thì Hoàng apply như thế nào
Hoàng: Lúc mình đi làm thì đã có 8 tháng kinh nghiệm QC, nhưng mình chấp nhận apply vị trí intern 2 tháng.
Ban đầu mình làm ở BA dạng pre-sale. Đầu tiên mình tham gia phân tích các tool như CRM, HRM các tool về quản lý nhân sự, khách hàng. Sau đó dựa vào tuỳ yêu cầu của khách hàng để đề xuất giải các tool phù hợp hoặc xây dựng thêm tính năng theo mong muốn của khách hàng.
Sau đó mình đề xuất với sếp của mình xin chuyển sang IT BA và được sếp đồng ý chuyển sang dự án mới với vai trò IT BA sau 2 tháng intern.
Khoa: Thì dự án mới đó là dự án đã có sẵn?
Hoàng: Dự án đó đã có từ trước nhưng chạy chưa tốt, khách hàng muốn nâng cấp. Khách hang của dự án này bên Sing.
Linh: Khi join vào một dự án có sẵn như vậy thì việc học cái domain knowledge có khó không?
Hoàng: Thật ra thì may mắn là dự án này cũng liên quan đến tình nguyện xã hội luôn, mà mình đã có 3 năm sinh hoạt ở Đội Công tác Xã hội nên cũng có khá nhiều kinh nghiệm về thể loại, nên mình rất nhanh hiểu về domain này. Còn những tính năng thì cũng chưa quá phức tạp, nó dạng như blog, và chạy các chiến dịch liên quan đến việc truyền thông điệp.
Linh: Theo Hoàng thì làm việc với khách nước ngoài vậy có khó khăn gì không?
Hoàng: Theo mình nghĩ là tiếng Anh là điểm yếu nhất của mình. Đôi khi khách hiểm lầm ý mình, và cần phải vẽ sơ đồ để giải thích. Thứ hai là làm việc online với khách nên việc chờ đợi làm mình trĩ hoàn nhiều việc khác.
Khoa: Khó khăn với khách hàng là vậy, còn khó khăn với team dev, designer như thế nào?
Hoàng: Designer là bên team Singapore luôn, nên được coi như là trao đổi với khách hàng. Còn team Dev, QC thì hiện tại mình thấy chưa có khó khăn với bản thân trong dự án này, vì mình cũng có thời gian làm Dev và cả QC nữa, nên khi truyền đạt về requirement thì mình share theo hướng của Dev và QC luôn.
Khoa: Quy trình cho 1 tính năng mới thì như thế nào?
Quy trình hiện tại: Khách hàng sẽ đăng user story mô tả tính năng họ muốn làm ở đơn giản nhất. Và mình sẽ phân tích và đưa ra đề xuất, khi đã confirm tất cả thì mình document lại thành requirement và truyền đạt đến Dev + QC.
Khoa: Khi khách hàng đăng user story vậy, Hoàng có thường say no không?
Hoàng: Có chứ. Ví dụ mình làm một cái popup, có rất nhiều cách để tắt popup. Thì mình có thể để xuất cho khách vì sao nên dùng dấu chéo (x) để tắt. Popup to quá thì mình giải thích có thể gây khó chịu cho user, mình nên làm sao để thân thiện với user hơn.
Ví dụ khách có nghĩ ra một tính năng nhưng khi trao đổi với team dev mà tính năng đó quá phức tạp thì mình có thể deal lại với khách để cân nhắc độ ưu tiên và mức độ xây dựng của tính năng này.
Khoa: Tức là mình có thể thảo luận với team dev, desinger về tính năng, nhưng BA vẫn là người quyết định cuối cùng và chốt với khách hàng.
Hoàng: Đúng rồi. Đa số các tính năng mình sẽ được tự chốt với khách hàng.
Khoa: Khi dev làm xong thì BA là người làm UAT?
Hoàng: Đúng rồi, nhưng trước đó là có team QC kiểm tra thật kỹ luôn. Và mình cũng trao đổi phần kiểm thử với QC.
Khoa: Vậy là khi khách hàng pass cái UAT thì có 2 trường hợp: có thể khách hài lòng hoặc không. Vậy có trường hợp nào sau UAT mà khách muốn chỉnh sửa không?
Hoàng: Có chứ. Vì mình còn non kinh nghiệm nên thỉnh thoảng cũng có một số trường hợp. Cũng cái ví dụ popup, mình có trao đổi với anh frond-end là làm sao cho show popup nó mượt đúng ý khách hàng. Nhưng bên khách cũng chưa hình dung được. Nên mình cứ discuss là cứ làm đi, khách họ sẽ có feedback sau.
Khoa: À, tức là nếu có chỉnh sửa cũng những thứ lặt vặt thôi, vì hầu như đã trao đổi với khách lúc đầu rồi.
Hoàng: Um, vì dự án lần này khách khá quan trọng về UI/UX nhưng mà design họ gửi chỉ có mobile & desktop thôi. Có thể ipad nó chưa tốt nên BA có thể linh động để trao đổi phần này với khách hàng. Có thể làm trước luôn rồi đưa khách hàng nhận xét vì mình biết là những cái này sửa tốn rất ít thời gian so với tổng thời gian xây dựng tính năng.
Khoa: À, thà là deal trước với khách hàng những cái core feature chính, còn mấy cái lặt vặt cứ làm rồi show lên cho khách nhận xét
Hoàng: Um, đúng rồi.
Khoa: Ngoài team phát triển sản phẩm, BA có giao tiếp với những team khác như sale, marketing gì không?
Hoàng: Những công ty và team khác mình không biết. Nhưng hiện tại dự án này team mình không có giao tiếp với team sale, marketing nữa. Có thể mấy anh Sếp ở trên lo rồi. hehee
Khoa: Vậy sắp tới Hoàng có dự định học gì để cải thiện kỹ năng BA của mình không.
Hoàng: Thứ nhất là tiếng Anh giao tiếp để tự tin với khách hàng nước ngoài rồi. Ngoài ra mình dự định học một khoá về BA để biết rõ chuẩn quy trình BA là như thế nào.
Khoa: Hoàng có lời khuyên gì cho những bạn muốn làm BA không? Có nên theo con đường của Hoàng là làm QC rồi chuyển qua BA, hay intern thẳng BA luôn?
Hoàng: Mình phân làm 2 đối tượng. Đối tượng thứ nhất là chưa tìm hiểu gì về BA thì nên apply QC để hiểu về quy trình, cách làm việc trong team, một số kỹ năng về document sau đó mình làm BA tốt hơn.
Còn những bạn có khả năng tự học, kỹ năng mềm tốt, giao tiếp tốt thì nên appy luôn vị trí intern BA tốt hơn.
Khoa: Một số bạn sẽ nói là những kỹ năng mềm khi tham gia những câu lạc bộ, Công tác Xã hội hay Đoàn-Hội gì đó thì tốn thời gian không có ích gì thì Hoàng có lời khuyên gì cho những bạn đó không?
Hoàng: Thực ra thì không nhất thiết phải tham gia. Các bạn còn nhiều cách khác như là đi làm thêm như làm trợ giảng ở các trung tâm tiếng Anh. Tham gia những công việc như là dẫn khách du lịch, đi tour. Vừa biết cách nói chuyện với khách hàng vừa tăng khả năng tiếng Anh của bản thân.
Công việc đơn giản hơn là các bạn có thể làm ở những quán cà phê với vị trí bộ phận tiếp tân, phục vụ để hiểu cách làm hài lòng khách hàng, cách nói chuyện với khách hàng.
Bởi vì khi làm BA sẽ có nhiều trường hợp mình rất là khó chịu với khách hàng thì mình phải học cách kiềm chế bản thân.
Nhưng mà tham gia rõ câu lạc bộ trường học là một trải nghiệm rất là tốt. Mình thấy là nó cho mình rất nhiều thứ luôn á. Ví dụ như mình là Đội trưởng Đội Công tác Xã hội nên mình sẽ có những cơ hội đến gặp trực tiếp địa phương, làm việc với chính quyền địa phương để trao đổi về lịch trình của các chương trình tình nguyện.
Mình cũng là người quyết định lịch trình của các hoạt động này và mình biết cách làm các quy trình riêng cho từng địa phương tại vì mỗi địa phương sẽ có cái cách làm việc khác nhau
Khoa: Tức là nó cũng na ná giống như BA về cái quy trình giống như là mình làm việc với khách hàng là là nói chuyện với chính quyền địa phương còn làm việc với team phát triển sản phẩm là quay về trường xin giấy tờ.
Hoàng: Đúng rồi đó.
Khoa: Cảm ơn Hoàng về buổi nói chuyện, với những bạn muốn trao đổi thêm với Hoàng thì có thể liên hệ qua kênh nào nhỉ? đã update mới: [email protected] (email mình nhé)
Đây là Hoàng nhé!
3. Kết
Qua buổi phỏng vấn trên, mình nghĩ bạn cũng có cái nhìn tổng quan về công việc của QC và BA rồi. Một số kỹ năng không thể thiếu của BA: Giao tiếp, phân tích, xử lý vấn đề, quản lý.
Ngoài ra khi chuyển sang một vị trí mới mà chưa có kinh nghiệm gì ở vị trí mới đó thì thử intern cũng là lựa chọn không tồi.
Thứ ba là nhiều khi nghề chọn người cũng đúng bạn à. Lúc trước thấy mình code dạo iOS, Hoàng cũng apply thử vị trí iOS nhưng… rớt rồi chuyển sang làm QC, sau đó mới sang BA. Nếu không có lần rớt đó, chắc giờ Hoàng nó cũng làm iOS dev rồi chăng?
