Category: doing

  • WPDE #2 – Hệ thống thẻ tàu điện ngầm Metro

    Weekly Product Design Exercise #2
    The NYC metrocard system has remained unchanged for decades. The cost of the metrocard machine infrastructure, the lost time of waiting in line to buy a metrocard, touching a dirty machine to do it, the potential of losing the metrocard, and the ease of gaming the system by swiping your card for others has cost the city millions of dollars and leaves much to be desired from the user experience.

    Design a new system that allows a daily user who uses the metro everyday or an-out-of-town visitor who will use the metro just once to get access to the metro, on time, without having a physical NYC metrocard on hand.
    Asked by WeWork. Learn how to solve these type of exercises with my book “Solving Product Design Exercises“.

    Hệ thống thẻ tàu điện ngầm NYC không hề thay đổi trong mấy chục năm qua. Chi phí cho hạ tầng máy móc thẻ metro, thời gian mất cho việc xếp hàng chờ mua thẻ metro, chạm vào máy bẩn để làm việc đó, khả năng mất thẻ metro và việc dễ dàng gian lận trên hệ thống bằng cách quẹt thẻ của mình cho người khác đã khiến thành phố tiêu tốn hàng triệu đô la và trải nghiệm người dùng còn tồn đọng rất nhiều điều để cải thiện.

    Hãy thiết kế một hệ thống mới cho phép người dùng sử dụng tàu điện ngầm hàng ngày hoặc khách ngoại tỉnh – những người sử dụng tàu điện ngầm chỉ một lần để đi đến tàu điện ngầm đúng giờ mà không cần mang theo thẻ tàu điện ngầm NYC vật lý.

    Câu hỏi của WeWork.


    Comment của Giang:

    20210505

    VN chưa có metro, mình cũng chưa từng ra nước ngoài luôn. Thôi đi tìm hiểu đã :v Đời đâu phải lúc nào cũng được thiết kế cái thứ thân thuộc với mình đâu.

  • WPDE #1 : Gọi đúng tên người học

    Giới thiệu về series Weekly Product Design Challenges của Artiom Dashinsky

    Artiom Dashinsky là tác giả cuốn Solving Product Design Exercises: Questions & Answers, giới thiệu các câu hỏi phỏng vấn và câu trả lời gợi ý cho vị trí Product Designer.

    Series Weekly Product Design Challenge được gửi đến email của người theo dõi hàng tuần. Mình đã theo dõi đến kì thứ 47, trước khi bắt tay vào dịch series này.

    Bước thêm một bước đến với ước mơ, kể ra cũng thú vị, nhỉ.

    Sau đây mời bạn đến với bài tập 1.


    Weekly Product Design Exercise #1

    At the beginning of each new semester or school year, teachers are faced with the challenge of remembering names for a large number of new students.

    Design an experience to help an educator match faces to names, with the goal of shortening the time needed to reach complete un-aided accuracy.
    Asked by Google. Here are solutions from different designers around the world: Joel Califa, Nenad Milosevic, Volkan Gunal

    Bài tập #1

    Vào đầu học kì, giáo viên phải đối mặt với việc nhớ tên rất nhiều học sinh mới.

    Hãy thiết một trải nghiệm để giúp một nhà giáo ghép gương mặt với tên gọi, với mục tiêu rút ngắn thời gian cần thiết để đạt được độ chính xác mà không cần hỗ trợ.

    Câu hỏi của Google.


    Suy ngẫm của Giang

    Mình dựa trên bộ câu hỏi sau của Artiom để bắt đầu suy nghĩ về vấn đề và giải pháp:

    Why is this product or feature important?
    What problem are we trying to solve?
    What impact does it have on the world?
    How does this product benefit customers?
    What business opportunity does it create?”

    Excerpt From: Artiom Dashinsky. “Solving Product Design Exercises: Interview Questions & Answers.” Apple Books.

    1. Tại sao sản phẩm/chức năng này lại quan trọng?

    Suy nghĩ của mình là, vấn đề này quan trọng với ai? Mình đã đi học 12 năm, vấn đề nhớ tên dường như không phải là chuyện được để tâm nhiều. Mình học ở một trường công lập, với mức học phí rất thấp, giáo viên dạy từ 4-5 lớp cho các môn như Toán Lý Hóa Văn Anh, và cả chục lớp cho các môn như Sử Địa Giáo dục công dân. Việc yêu cầu giáo viên nhớ tên cả lớp dường như là hơi quá quắt.

    Tụi mình deal với việc này như thế nào?

    Vì chỗ ngồi là cố định, nên tụi mình có một sơ đồ lớp, với tên của học sinh được điền vào từng vị trí chỗ ngồi. Giáo viên nhìn vào sơ đồ và vị trí thực tế trong lớp, rồi gọi cái tên tương ứng, nhớ gương mặt của học sinh. Để củng cố, mỗi học sinh có thể có một bảng tên viết bằng chữ to, in hoa để ngay trước mặt, và mỗi lần đứng dậy phát biểu, học sinh sẽ giới thiệu tên mình.

    Kết quả: Sau khoảng 1 tháng, giáo viên có thể nhớ tên khoảng tầm 70% số học sinh mà không cần sơ đồ lớp nữa. Những bạn thường phát biểu và những bạn ngồi bàn đầu sẽ được nhớ nhanh hơn. Những bạn ít phát biểu và những bạn ngồi giữa sẽ hay bị quên tên hơn.

    Tuy nhiên, câu chuyện sẽ không dễ dàng như vậy nếu:

    • Lớp không cố định chỗ ngồi (lớp tiếng Anh, các lớp học ngoại khóa, các lớp huấn luyện cho người lớn)
    • Những nơi mà học sinh không chủ động trong việc khiến giáo viên nhớ mình
    • Những nơi mà học sinh được xem như khách hàng, và việc không nhớ tên sẽ bị xem là một điểm trừ trầm trọng (trường tư, trung tâm tiếng Anh, kĩ năng mềm…)

    2. Vấn đề mà mình đang cố gắng giải quyết là gì?

    Giáo viên tốn nhiều thời gian để ghép tên & mặt

    Giáo viên phải nhớ quá nhiều tên & mặt (hàng chục đến hàng trăm)

    Giáo viên nhớ và quên rất nhanh

    3. Tác động của vấn đề này?

    Học sinh bị quên tên: cảm thấy không được tôn trọng, tốn thời gian để giới thiệu lại, có ấn tượng xấu với giáo viên

    Giáo viên: giao tiếp trở nên kém hiệu quả

    4. Sản phẩm này sẽ giúp gì cho khách hàng?

    Nhớ nhanh hơn, lâu hơn, kĩ hơn

    5. Cơ hội kinh doanh cho sản phẩm này?

    • Dùng trong các trung tâm giáo dục, giúp giáo viên nhớ tên học viên nhanh hơn, cải thiện trải nghiệm khách hàng
    • Dùng trong các quán ăn, để nhân viên nhớ các khách hàng trung thành
    • …

    Giải pháp của Joel Califa: Google Cue (Mobile App)


    Giải pháp của Nenad Milosevic: Face Apps (Mobile App)

    Cách tiếp cận:

    1. Phỏng vấn ~20 giáo viên về practice của họ để nhớ tên.
    2. Tham khảo ý kiến của các nhà giáo trên internet, Facebook… các trang web là một nơi rất truyền cảm hứng để tìm kiếm thông tin nếu mình biết tìm ở đâu và tìm thế nào. Sau đây là một số ý tưởng khá truyền cảm hứng:
      • Ứng dụng có thể gợi ý những từ tương tự như tên của học sinh hoặc thậm chí có thể gợi ý những con vật giống với khuôn mặt của chúng (với bộ lọc những con vật có khả năng gây khó chịu).
      • Những cái tên mà bạn thất bại trong bài kiểm tra / bài kiểm tra là những học sinh mà bạn nên tập trung hơn.
      • Nhắc nhở (thông báo) từ ứng dụng để xem lại ghi chú trước khi đến lớp và sau đó một lần nữa, thêm bất kỳ thông tin nào sẽ giúp bạn nhớ tên học sinh của mình.
      • Hướng dẫn giáo viên cách hoàn thành hồ sơ học sinh (tạo hồ sơ mới, nhập tên học sinh, chụp ảnh, viết một câu ngắn về học sinh đó, v.v.).
      • Chỉ định chỗ ngồi và lập sơ đồ chỗ ngồi. Có ảnh tên trên biểu đồ đó thực sự hữu ích.
      • Liên kết ngoại hình hoặc tính cách của học sinh với tên của họ. Lấy chữ cái đầu tiên của tên người đó và nghĩ về một từ bắt đầu bằng chữ cái đó để mô tả họ. Ví dụ, Pietro is polite (lịch sự). Gaston wears glasses. Nếu bạn có thể nhớ đặc điểm mà bạn liên kết với mỗi người, bạn sẽ biết tên của họ bắt đầu bằng chữ cái gì và có nhiều khả năng nhớ nó hơn.
      • Việc in sơ đồ chỗ ngồi, thẻ tên và bảng tên rất hữu ích.
      • Vào đầu năm học, yêu cầu học sinh nói tên của họ mỗi khi họ nói.
      • Chơi trò chơi là cách phá băng tuyệt vời cho một lớp mới. Không chỉ vậy, đây là cách tốt để các học sinh mới cảm thấy thoải mái với lớp học, và còn giúp họ có cơ hội hiểu biết lẫn nhau! Tôi thường chơi trò tên gọi trong buổi học đầu tiên của năm, với mỗi lớp; chẳng hạn như Tính từ Alex ’; Mỗi học sinh đứng lên lần lượt và lặp lại tên của họ cùng với sở thích (hoặc tính từ, động vật, v.v.) bắt đầu bằng cùng một chữ cái đầu tiên trong tên mình, chẳng hạn như tôi là Elise và tôi chính xác (exacting). Học sinh tiếp theo lặp lại điều này và thêm tên của họ vào cuối danh sách. Sau đó, ở phần cuối, tôi lặp lại tên và mô tả của mọi người.
      • Ở trường đại học, chúng tôi luôn được bảo rằng không chỉ học tất cả các tên của sinh viên càng sớm càng tốt mà còn phải tìm hiểu một điều độc đáo về chúng (đội bóng yêu thích, ca sĩ, v.v.) để giúp xây dựng mối quan hệ với chúng.
      • Thông thường, khó nhớ nhất là tên của sinh viên nước ngoài, điều này có thể xa lạ với đôi tai của người phương Tây. Đảm bảo viết phiên âm của tên nếu cần. Ví dụ, trong một lớp học của tôi, tên của một sinh viên Trung Quốc được phiên âm là Xiou – nhưng lại phát âm giống như “Shaw”.
      • Sử dụng sự hài hước trong các liên kết của bạn để tạo ấn tượng lâu dài. Tôi cứ bối rối không biết một học sinh là Egla hay Elga cho đến khi tôi tưởng tượng ra cô ấy với một quả trứng luộc to bằng cái đầu.
      • Tôi yêu cầu học sinh của tôi viết tên mình bằng với chữ thật lớn để tôi có thể đọc từ đầu lớp.
      • Hãy đảm bảo rằng bạn biết tên của những sinh viên đến thăm bạn trong giờ hành chính. Hãy dành một vài phút để hỏi học sinh về bản thân họ, chuyên ngành, họ đến từ đâu,… Tiếp xúc cá nhân là một trong những cách bạn có thể tăng hiệu quả giảng dạy của mình.
      • Xếp thứ tự chữ cái của học sinh theo tên! Đặt tất cả A và B vào một bàn, v.v. Khi Cory, Cody và Carmen ngồi cùng nhau, điều đó thực sự giúp bạn ít nhất có được chữ cái đầu trong tên họ.
      • Tôi lưu ý học sinh nào đang ngồi ở đâu bằng cách lập sơ đồ chỗ ngồi ngay lập tức. Sau đó, trong khi tôi để học sinh tham gia vào các hoạt động, tôi ghi một vài ghi chú về học sinh bên cạnh tên của họ.
      • Tôi có thể đưa ra nhận xét về ngoại hình của học sinh: “đeo kính”, “hoa tai lớn”, “tóc ngắn màu vàng”. Tôi có thể lưu ý rằng họ nhắc tôi nhớ về một người khác mà tôi biết. Hoặc tôi có thể viết ra một điều gì đó về giọng nói hoặc cử động của họ để giúp tôi ghi nhớ chúng.
      • Tôi yêu cầu học sinh mô tả bản thân bằng một tính từ bắt đầu bằng tên của họ.
      • Cho học sinh ngồi cùng chỗ trong vài tuần đầu tiên cho đến khi bạn có thể ghép tên với khuôn mặt.
        Yêu cầu học sinh nêu tên của họ mỗi lần trước khi họ nói. Điều này có thể được tiếp tục cho đến khi mọi người (giáo viên và sinh viên/học sinh) cảm thấy họ biết những người trong phòng.
      • Sử dụng tên của học sinh thường xuyên nhất có thể.
      • Có một bài kiểm tra ngắn vào đầu lớp về tên của học sinh.
      • Một số giáo viên vẽ học sinh của mình để giúp họ nhớ ai là ai. Các bản phác thảo có thể nhanh gọn, 20 giây nguệch ngoạc ghi lại những đặc điểm nổi bật nhất của học sinh.
    3. Tham khảo các đối thủ cạnh tranh để không phát minh lại cái bánh xe. Dùng thử chúng, ghi chú lại.

    Mặt khác, Nenad cũng được truyền cảm hứng rất lớn từ các ứng dụng của Google, và anh muốn giữ phong cách thống nhất, nên font chữ, biểu tượng, màu sắc, thương hiệu và các yếu tố khác phù hợp với nguyên tắc xây dựng thương hiệu của Google và đặc biệt là Material Design.

    MỤC TIÊU

    Để kết nối và tạo thêm các mối quan hệ cá nhân với học sinh. Giúp đồng nghiệp nhớ tên của học sinh mới bằng cách hợp tác và chia sẻ.

    USER

    PAIN POINT

    IDEATION

    USER FLOW

    Tập trung vào 3 chức năng chính:

    1. Class Roster
    2. Quiz
    3. Seating chart

    MOCKUP & WIREFRAMING

    Đánh giá của mình:

    Điểm cộng:

    Nenad xuất phát từ góc nhìn của user, làm persona kĩ, và thu nhặt được rất nhiều insight quý báu từ user để đem vào sản phẩm của mình. Do đó,


    Giải pháp của Volkan Gunal: Pupils (Mobile App)

    1. Insight
      • Design focus
        • User
        • Goal
        • Context
        • Task
        • Tool
      • Product Principles
        • Encouraging Joyful Accessible Expressive
      • Product Mission
    2. Product Framework
      • Application framework
        1. Class Roster
        2. Student Directory
        3. Cheat Sheets

    Tóm tắt giải pháp

    1. Đầu vào: Danh sách học sinh (tên, ảnh)
    2. Đầu ra: Tên & ảnh được kết nối với nhau trong trí nhớ của giáo viên
    3. Process: Sử dụng Mobile app được cài đặt trong điện thoại (của giáo viên?)
      1. Người dùng tạo lớp học
      2. Người dùng nhập tên & ảnh của học viên theo lớp
      3. Phần mềm tạo ra các bài học (show cả tên & ảnh của học sinh) & bài tập kiểm tra (nối, lựa chọn ảnh đúng trong nhiều ảnh khác nhau cho đúng với tên, lựa chọn tên đúng trong nhiều tên khác nhau cho đúng với ảnh…) dựa trên cơ sở dữ liệu được nhập
      4. Người dùng học & làm bài kiểm tra
      5. Hệ thống báo cáo kết quả học, từ kết quả học để tạo ra các bài học tiếp theo (giảm tần suất tên & ảnh đã nhớ, tăng tần suất tên & ảnh chưa nhớ)
    4. Các tính năng bổ sung:
      1. Nhập danh sách từ file
      2. Nhập danh sách tên bằng voice & OCR
      3. Nhập ảnh bằng camera điện thoại
      4. News: tài liệu tham khảo cho giáo viên

    Đánh giá của Giang

    Điểm cộng:

    • Làm persona tốt
    • App nhiều chức năng thú vị

    Điểm trừ:

    • Không phân chia rõ mức độ cần thiết của các chức năng với mục tiêu chính. Theo mình, chức năng nhập dữ liệu, tạo bài học & câu hỏi, report tình hình học là các chức năng quan trọng nhất. Các chức năng khác có thể bổ sung sau.
    • Không dựa trên người dùng thực tế

  • Hỏi đáp: Review một khóa học

    Em ơi, chị thấy khóa này về chủ đề X hay quá nè, mà chị đang phân vân về giảng viên, không biết là có hợp với chị hông. Em có kinh nghiệm gì có thể chia sẻ về việc review khóa học không?

    (Đính kèm đường link tới một khóa học trên Coursera)

    Đáp:

    Hello chị, việc chọn một khóa học để học, có thể xem tương đương với việc đi mua một món đồ hay một sản phẩm dịch vụ để đáp ứng một nhu cầu nào đó. Như vậy,

    Bước 1, ta cần xác định:

    1. Nhu cầu của bản thân: Mình muốn học gì, phạm vi đến đâu, budget thế nào…
    2. Thị trường đang cung cấp gì, đáp ứng nhu cầu của ta đến đâu.

    Với mục số 1, nếu là để đáp ứng nhu cầu công việc, có thể tham khảo:

    • Job description
    • Job post

    Các thông tin này rất sẵn trên các trang tuyển dụng. Lấy tầm 5-10 mẩu tin, gạn lọc từ khóa, ta sẽ có được một cái nhìn khá bao quát về nhu cầu của thị trường đối với ngành nghề đó.

    Với mục số 2, ta có thể tìm kiếm các khóa học đang có trên thị trường dựa trên bộ từ khóa đã có.

    Bước 2, sau khi đã xác định rõ nhu cầu, các option thị trường cung cấp, ta có thể lập một bảng so sánh:

    Bước 3: Ra quyết định

    Tóm lại:

    1. Xác định nhu cầu của bản thân
    2. Xác định cái thị trường cung cấp
    3. Xác định các tiêu chí, lập bảng so sánh
    4. Chọn lựa dựa trên các tiêu chí đó

    NHƯNG…

    Có một chữ “nhưng” rất to! Quy trình thông thường là như trên, nhưng câu chuyện này lại rẽ sang một hướng khác. Nhờ Design Thinking hôm bữa nên mình áp dụng zô luôn!

    Có vẻ chị quan tâm nhiều đến giảng viên, vậy giảng viên như thế nào sẽ khiến chị không thích ạ?

    À, chị quan tâm cách truyền đạt của giảng viên, cùng 1 kiến thức nhưng mỗi người có 1 cách truyền đạt và dẫn dắt khác nhau. Chị không thích khóa học mà không có bài tập thực hành và tương tác trực tiếp, nên chị khá là ngại ngần với các course online.

    (Nghĩ thầm: vậy mà chị kêu em đi review khóa học online!)

    Vậy là chị thích offline interaction, chứ không phải đang cân nhắc giữa các giảng viên online?

    Ừa. Chị follow thầy A kia cũng khá lâu, người đó truyền cảm hứng lắm. Nhưng để học được lớp của thầy thì phải qua Mẽo, học phí cũng khá khẩm. Kiểu mình có 1 cái favourite nhưng mình chưa đủ điều kiện để đáp ứng, nên quay qua alternative option thì mình ko mấy mặn mà…

    Vậy chị muốn học từ người thầy đó, hay là học kiến thức đó?

    Trong trường hợp này thì có lẽ là học từ người thầy đó hơn là kiến thức

    Nếu vậy thì cách tiếp cận có lẽ sẽ khác đi rồi. Theo em thì, để gần người đó (tiện thể học) thì mình có nhiều cách khác chứ không cần chỉ đi học. Ví dụ, gửi mail cho người đó, bày tỏ lòng ngưỡng mộ và xin một chân phụ dự án của người đó, kết nối với một nhóm để tổ chức một buổi online conference… Nếu vẫn muốn đi học, thì làm một bản dự toán chi tiết xem hết bao nhiêu, nếu khóa học thật sự có giá trị thì cũng rất đáng để lên kế hoạch dài hơi cho nó 😀

    Ừa, chị sẽ nghiêm túc review lại các lớp online, và tìm thầy offline tốt hơn nếu có thể. Chị cũng không vội, miễn là tìm được thầy phù hợp.


    Mình học được gì qua câu chuyện trên?

    1. Cái người ta hỏi chưa chắc là cái người ta thật sự cần
    2. Chỉ đưa công cụ cho người thật sự cần công cụ đó, nếu không sẽ là gánh nặng cho họ
    3. Tiêu chí đánh giá của mỗi người là khác nhau


  • Ước lượng Story Point trong Scrum: Liệu còn hữu dụng?

    Blog, Development | Apr 26, 2018
    PHẦN MỘT
    Chúng ta hẳn còn nhớ lần đầu đọc Tuyên ngôn Agile (The Agile Manifesto). Nó đem đến cảm giác cực kì phấn khích. Những giá trị của nó thúc đẩy và gia tăng sức mạnh của đội nhóm. Nó tạo ra giá trị sâu sắc hơn cho khách hàng và đẩy lùi những chuyện vớ vẩn khỏi công việc phát triển phần mềm. Mọi thứ đã đâu vào đấy.
    Tua nhanh đến năm 2018, và “Houston, có biến”.
    Scrum hữu dụng, và mọi thứ vẫn đâu vào đấy, nhưng… việc áp dụng Agile và Scrum một cách nhanh chóng đã tạo ra một cơn ác mộng cho những người lên kế hoạch ở cấp độ tổ chức (enterprise-level planners) – những người chịu trách nhiệm cho việc ước lượng Epic/Portfolio. Lĩnh vực này đã lấy một thông lệ được tạo ra cho những nhóm nhỏ làm việc mật thiết với nhau một cách đồng bộ – sau đó cải tiến để áp dụng cho số đông.
    Một nhóm Scrum trở thành vài nhóm hay hàng chục nhóm, mỗi nhóm có một cách hiểu khác nhau về “thế nào là một Story Point”. Hiện nay, không hề có nhóm nào có cùng trải nghiệm, cơ sở hạ tầng hay các bộ kĩ năng giống với nhóm nào; do đó, không hề có nhóm nào định nghĩa Story Point giống nhóm nào.
    Rồi đột nhiên, các quản lý cấp cao cố gắng chia Epic backlog dựa trên hơn 25 diễn giải khác nhau về một Story Point. Càng nhiều nhóm đang làm trên một sản phẩm, ngọn núi phải leo càng lớn [Xin thứ lỗi cho sự châm biếm này]
    17 anh chàng ở Snowbird (17 người tham gia cuộc họp ở Snowbird, từ đó đi đến Tuyên ngôn Agile năm 2001 – ND) sẽ nói gì?
    Scrum cơ bản sẽ nói rằng đừng cố thử ước lượng một Epic backlog, vì việc đó chỉ phí công và đầy chỗ không chính xác. Các chi tiết chắc chắn sẽ thay đổi, và mọi thứ sẽ lại được sắp xếp lại thứ tự ưu tiên vào phút cuối. Nhưng nói điều đó với Epic/Portfolio Manager đang phải đảm đương việc đưa ra một lịch trình tiến độ để cấp vốn, hẳn bạn sẽ nhận được ánh mắt hình viên đạn!
    Ước lượng Epic bị lệch từ số ngày của các nhóm Scrum đơn lẻ khi việc ước lượng vốn vô cùng đơn giản. Các dependency, bộ kĩ năng sẵn có, các công cụ để hoàn thiện công việc được lặp đi lặp lại. Các thành viên riêng lẻ biết về năng lực và giới hạn của từng người. Khi ai đó nói rằng một story là 5 point, mọi người trong team biết chính xác điều người đó ngụ ý là gì. Khi Scrum mở rộng (grew legs), ý nghĩa của “5 points” dần trở nên mơ hồ. Càng thêm nhiều nhóm, càng khó cho các nhà quản lý để diễn giải Story Point. Ở khoảng 10 hay 20 nhóm Scrum… thì tất cả hoàn toàn là một đống hỗn độn! Nếu không có một đường trung đạo (center line) cho việc ước lượng, cả nhóm sẽ trở nên bất ổn rất nhanh.
    Điều này làm dấy lên câu hỏi: “Liệu Story Point có còn là cách hiệu quả để ước lượng các Epic trong Scrum?”
    Một số người cho là có, bạn vẫn có thể dùng Story Point với framework mở rộng (scaling framework) đúng đắn. Một số khác cho là Scrum đã đi quá xa so với những nguyên lý Agile vì công việc không thể chia nhỏ. Khi quy mô của Scrum tăng lên, làm thế nào để các nhóm có thể thiết lập một tiêu chuẩn thống nhất cho việc ước lượng Epic backlog để những nhà quản lý cấp cao, những bên liên quan và những nhóm khác có thể đồng ý với nhau?
    ƯU ĐIỂM VÀ NHƯỢC ĐIỂM CỦA STORY POINTS
    Chúng tôi đã có vài cuộc thảo luận nội bộ và đi đến những ưu điểm và nhược điểm của việc sử dụng Story Point đối với việc ước lượng trong Scrum ở cấp cao. Hãy đọc qua danh sách dưới đây và cho chúng tôi biết ý kiến của bạn về chủ đề này, về những điều bạn chưa đồng ý và những chỗ chúng tôi còn thiếu sót nhé.
    Ưu điểm: Story Points giúp chia nhỏ những backlog lớn.
    Story Points có thể rất hữu dụng với vai trò là một phần của một scaling framework như SAFe và NEXUS. Những framework này cung cấp những phương pháp ước lượng có khả năng mở rộng (scalable estimation techniques) để chia nhỏ công việc ở các cấp độ Epic, Program và Portfolio:
    · SAFe xem xét bức tranh lớn về cách công việc đi từ quản lý sản phẩm (Product Management) đến quản trị sản phẩm (Governance), các nhóm Program và các nhóm Dev, rồi đến khách hàng.
    · NEXUS thiên về cách tiếp cận từ dưới lên, tập trung vào việc việc hợp nhất nhiều nhóm Scrum làm việc trên cùng một sản phẩm. Thông qua sự minh bạch, NEXUS cố gắng bảo vệ và tăng cường những kết nối giữa các nhóm và giữ cho việc thay đổi đồng bộ nhất có thể.
    Từ góc độ chiến thuật, một phương pháp được các nhà huấn luyện khuyên dùng là để cho nhóm đang làm công việc ước lượng đảm đương các cuộc họp về ước lượng (meeting the estimate). Cùng một nhóm đó luôn làm trên cùng một module nên ý nghĩa của các Story Point được duy trì rõ ràng và thống nhất từ Sprint này sang Sprint khác. Nhược điểm là năng lực cho mỗi module (capacity per module) trong mỗi lần phát hành (release) bị cố định, vì các nhóm không thể [đồng thời] nhảy từ module này sang module khác (across the modules). Bạn bị bó buộc trong lượng công việc có thể được hoàn thành trong một lần release cho mỗi module.
    Một cách tiếp cận khác là chỉ định một hoặc hai đại diện từ mỗi Scrum để tham gia một buổi họp ước lượng chính thức. Những người đại diện này có thể đưa ra quyết định về các story size mà không cần bắt cả nhóm phải ngừng công việc của mình. Phương pháp này giả định rằng mỗi người đại diện đều có kiến thức về cách nhóm của họ định nghĩa một Story Point, để họ có thể chia sẻ, thảo luận và tìm ra những lý do chung để ước lượng các story. Nhược điểm ở đây là mỗi nhóm Scrum phải tin và làm theo bất cứ điều gì mà những người đại diện mà họ đã chọn đặt ra về ước lượng cho mỗi story. Đồng thời, rủi ro có thể xảy ra là những người đại diện bị ảnh hưởng từ những cách tiếp cận về ước lượng của các đại diện từ những nhóm khác.
    Nhược điểm: Đây không phải là Scrum!
    Những chuyên gia về Agile sẽ cho rằng các phương pháp này không đại diện cho Scrum. Nếu cùng một nhóm luôn làm trên cùng một module, liệu điều này có đe dọa khả năng mở rộng không? Khái niệm về các nhóm tự quản lý thì sao? Từ quan điểm năng lực, việc giới hạn một nhóm thành một module không thúc đẩy khả năng mở rộng. Điều này không còn là agile mở rộng (scaled agile) nữa. Từ góc độ của nhóm, nếu chỉ có một sự ước lượng mang tính đại diện xa rời với cả nhóm, tính ổn định của nhóm sẽ gặp rủi ro vì (1) người đại diện không có kiến thức đúng về vấn đề dependency hay integration cụ thể hoặc (2) người đó có thể trở nên chịu ảnh hưởng từ những kinh nghiệm của một nhóm khác không phù hợp với cách thức hoạt động của nhóm mình. Trong cả hai trường hợp, người ta lo sợ rằng mọi thứ đang trở nên đi từ trên xuống (top-down) quá mức, tạo ra những cách biệt về tốc độ (Velocity gap) và một đống hỗn độn ngu ngốc trong PMO.
    PHẦN HAI:
    Trong phần dưới đây, chúng ta sẽ đi qua những ưu điểm và nhược điểm của các story point để thiết lập một cơ sở (baseline) thiết yếu nhằm huy động ngân sách, và liệu chúng có đang bao hàm nhiều hơn so với thứ mà Scrum dự định cho chúng không.
    Ưu điểm: Story Points thiết lập một baseline thiết yếu để huy động ngân sách
    Story Points đem đến cho nhà quản lý một điểm tham chiếu dữ liệu cơ sở để ước lượng và tính toán tốc độ (Velocity) giữa nhiều nhóm với nhau, vốn là điều mà ai cũng biết là chuyện ác thiết yếu nếu cần gọi vốn cho bất kì dự án lớn nào.
    Trong waterfall, các nhà quản lý có thể nói chuyện với các bên liên quan trên phương diện những con số (giờ, ngày, tuần, tháng). Ai cũng có thể hiểu những con số. Chẳng có gì tốn ít hơn một giờ. Khi Internet và Agile xuất hiện, không còn dùng giờ được nữa vì nhiều task có thể được hoàn thành còn nhanh hơn cả thời gian dự định họp để lên kế hoạch cho nó! Mặt khác, một số story có những Timeline và Dependency cần cung cấp tài liệu cho những bên liên quan. Story Point cung cấp cho các nhà quản lý một ý tưởng cơ bản về chỗ mà một story đổ vào spectrum, liên quan đến kinh nghiệm trước đó của một nhóm và cách họ đóng gói nó.
    CTO của chúng tôi, Kaushal Amin so sánh việc ước lượng Epic với việc hỏi xem cần bao nhiêu cái thùng (công sức – Effort) để chuyển đồ:
    Công ty A nói rằng họ sẽ chuyển hết đồ với 150 thùng. Công ty B có thể chuyển hết với 100 thùng. Nhìn qua thì có vẻ công ty B năng suất hơn, nhưng nếu công ty B dùng những cái thùng lớn hơn thì sao? Công sức cần bỏ ra có thể y như nhau, chỉ là các công ty đó ước lượng “kích thước thùng” (bucket size) khác nhau mà thôi.
    Ở cấp độ Program, bạn không thể ép buộc cùng một “kích thước thùng” (bucket size) giữa các nhóm. Tuy nhiên, Story Point có thể giúp các nhóm chia nhỏ công việc đến từng đơn vị chức năng nhỏ nhất để theo thời gian, những người lập kế hoạch cấp cao có thể nghiên cứu và hiểu từng nhóm đang dùng bucket size nào để ước lượng.
    Nhược điểm: Story Point [đang] bao hàm nhiều ý nghĩa hơn so với vai trò mà Scrum sắp đặt cho nó
    Ưu điểm cũng chính là nhược điểm. Story Point chưa bao giờ được tạo ra với dự định là sẽ trở thành một thước đo hiệu suất. Việc ước lượng Story Point chỉ là ước lượng, không phải dự báo. Nhưng, chúng đang được sử dụng để so sánh năng lực giữa các nhóm với nhau.
    Scrum chưa bao giờ dự định bó buộc các nhóm vào một cam kết “làm hay là chết”. Story Point tượng trưng cho một sự ước tính theo kiểu vừa ước đoán vừa lập luận “tốt vừa đủ” về quy mô liên quan trong một dự án. Nếu toàn bộ dự định về tính linh động (intent of Agility) là để cho phép các tổ chức phản ứng với những thay đổi theo kế hoạch, thì chúng ta không có được lợi ích đẩy đủ của Scrum.
    Trong phần sau và cũng là phần cuối về ước lượng story point, chúng ta sẽ xem xét những ưu điểm và nhược điểm của story point để tạo điều kiện cho các nhóm nâng cao chất lượng và những vai trò nhất định không hiểu story point từ góc độ kinh doanh.
    KAUSHAL AMIN
    Chief Technology Officer

    Người dịch: Trà Giang, 20180510

  • Hỏi đáp cùng James Bach (tại KMS Technology Việt Nam, mùa hè 2016)

    Bài gốc được đăng tại: https://www.kms-technology.com/blog/testing/q-a-with-james-bach.html
    Lời người dịch:

    James Bach ghé thăm KMS Technology Việt Nam vào mùa hè năm 2016. Vài tháng sau thì tôi mới gia nhập KMS (tiếc ơi là tiếc), và mãi đến năm 2018 thì tình cờ tôi mới được một tiền bối giới thiệu bài viết này và đề nghị tôi dịch thử. Quả thật là một thử thách cho một cô nàng chẳng biết gì nhiều về thế giới IT vào thời điểm đó, nhưng bài viết này cũng tạo phần nào cảm hứng để tôi tiếp tục dấn thân vào chuyện bếp núc của ngành làm phần mềm. Cảm ơn James Bach và chị Hòa Lê 😀

    —

    Tôi có vinh dự được nói chuyện cùng James Bach vào mùa hè năm 2016 khi ông đến thăm Việt Nam. Ông là cha đẻ của siêu nhận thức (metacognition) về kiểm thử phần mềm và cũng là người thầy đã khai sáng cho nhiều người về lĩnh vực này. Kiến thức của ông bao hàm nhiều lĩnh vực trong kiểm thử phần mềm, từ kiểm thử theo ngữ cảnh (context-driven testing), heuristics (tự nghiệm), sự nghiêp của tester, cho đến cuộc sống bí mật của tester. Nếu bạn có cơ hội được học hỏi từ ông, chắc hẳn bạn sẽ hoàn toàn đồng ý với tôi rằng ông thật tài năng.

    • Ông làm thế nào để đảm bảo chất lượng của một dự án Agile đa vùng (co-located Agile project)?
      James: Bạn sẽ cần giao tiếp có kế hoạch trước rất nhiều, vì giao tiếp không tự nhiên xảy ra khi người ta ở xa nhau. Tôi đề nghị nên điện đàm (conference call) hàng ngày. Những dự án được phân bổ (distributed projects) cần có bộ phận lãnh đạo mạnh mẽ để đưa mọi người lại gần nhau. Tôi cũng đề nghị những người then chốt nên đến thăm nhau định kì, thay vì chỉ dựa dẫm vào giao tiếp qua phương tiện điện tử.
      (“Dự án Agile đa vùng (co-located Agile) có nghĩa là các thành viên nhóm Agile làm việc ở những địa điểm khác nhau hoặc nhiều nhóm Agile đang làm những phần khác nhau của sản phẩm từ những địa điểm khác nhau”).
      Chúng ta đều biết trong môi trường Agile, tốc độ cao và chất lượng cao là ưu tiên hàng đầu. Người ta có khuynh hướng làm không nghỉ, nhưng vì chất được được đo dựa trên những đặc điểm của dự án và nhóm, nên yếu tố con người là nhân tố then chốt để đảm bảo chất lượng dự án. Điều này nghĩa là giao tiếp hiệu quả và tư duy sắc bén có thể ảnh hưởng lên sự thành công của dự án. Ý kiến của James đem đến một số ý tưởng về việc giao tiếp được củng cố trong các dự án.
      Thứ nhất, giao tiếp hiệu quả được quyết định dựa trên ngôn ngữ, sản phẩm, công cụ/công nghệ, và kiến thức về quy trình (process knowledge) của nhóm. Để giao tiếp một cách hiệu quả vượt qua khoảng cách địa lý và múi giờ, các nhóm được phân bổ cần nói cùng một “ngôn ngữ”. Ngôn ngữ ở đây không chỉ nói đến thuật ngữ về mặt ngôn ngữ (speaking terms) như tiếng Anh, Đức hay Pháp, mà còn là thuật ngữ về sản phẩm và những tính năng hay quy trình của công cụ/công nghệ, mà mỗi nhóm sẽ cần ở trình độ hiểu biết tương đương nhau để nói và hiểu lẫn nhau.
      Để đồng bộ, cần làm thêm một số bước. Các nhóm cần hỏi những câu hỏi súc tích và hợp lý, để làm rõ các yêu cầu hay đề nghị và để xem lại các kết quả trước khi phát hành (release). Sự đồng đều về kiến thức giữa các nhóm được phân bổ nên tạo điều kiện cho họ ra quyết định ở các vấn đề nội bộ, thực hiện “nguyên tắc tự quản lý”. Một nhóm không nên bảo nhóm khác cái gì [cần] và/hoặc làm thế nào để hoàn thành một task.
      Thứ hai, áp dụng những công cụ và cách thức giao tiếp thích hợp cũng đóng một vai trò quan trọng đối với việc giao tiếp của nhóm. Có khá nhiều lựa chọn từ giao tiếp trực tiếp (nói chuyện mặt đối mặt hay Video call) cho đến những dạng gián tiếp (Email, Forum, hay Text chat). Có nhiều công cụ phổ biến và hữu dụng để cân nhắc, bao gồm: Skype, Slack, Confluence, GoToMeeting, hay Google Drive, những thứ hỗ trợ giao tiếp và cộng tác một cách dễ dàng giữa các nhóm onshore và offshore. Những cách thức và ứng dụng này có thể giúp thu hẹp khoảng cách múi giờ và địa lý.
      Thêm vào đó, để giao tiếp được hiệu quả hơn, phạm vi công việc cần được sắp xếp một cách hợp lý để hoàn toàn hỗ trợ khách hàng một cách thích hợp và đem lại sự kết nối suôn sẻ. Bạn nên lên lịch cho các chuyến thăm onshore/offshore đều đặn để thiết lập mối quan hệ với các thành viên và phản hồi ngay với các thay đổi trong việc phát hành, các cột mốc quan trọng (milestone), hay công nghệ.
    • Ông định nghĩa code kiểm thử được là như thế nào? Các tiêu chí của ông là gì?
      James: Mọi code đều kiểm thử được. Một số code dễ kiểm thử hơn các code khác. Tính có thể kiểm thử trong code chỉ có nghĩa là nó dễ kiểm thử như thế nào. Code dễ kiểm thử hơn khi nó có thể quan sát (observable) được và có để kiểm soát được. Hãy hỏi về logging ở mức độ chức năng (functional-level logging) và giao diện scriptable (scriptable interface). Đồng thời, code dễ kiểm thử hơn khi chúng đơn giản và có thể phân tích được. Tính có thể phân tích được (decomposability) là khả năng có thể phân tích các thành phần và kiểm thử biệt lập một cách tương đối.
      Cụ thể hơn, có nhiều cách đơn giản để định nghĩa code có thể kiểm thử, chẳng hạn: logic của code (code logic), quy ước đặt tên code (code naming conventions) và cấu trúc/kiến trúc của dự án (project structure/architecture). Code kiểm thử được luôn bao gồm khả năng mở rộng, tính dễ bảo trì, tính có thể sử dụng lại, và tính có thể nâng cấp (ability of extension, easy maintenance, re-usability, and upgradability). Burak Guzel của EnvatoTuts đã liệt kê 15 cách tốt nhất để viết code có thể đọc được.
    • Một tester cần loại kĩ năng nào để có thể tiến vào thế giới DEVOPS?
      James: Tôi không biết nhiều đến thế về thế giới DEVOPS. Nhưng thế giới đó không chào đón tester. Nó chào đón lập trình viên. Do đó kĩ năng được yêu cầu đầu tiên là lập trình. Sau đó bạn cần tìm kiếm những công cụ để hỗ trợ công việc kiểm thử của mình.
      Có một số chiến thuật mà tester cần nắm bắt để tiến vào thế giới DEVOPS:
      · Live site testing: Testers cần phải kiểm thử sản phẩm trong quá trình sản xuất, ngay khi nó được phát hành (release).
      · Thu thập và phân tích phản hồi từ người dùng trong lĩnh vực đó. Phản ứng nhanh với bất kì vấn đề phát sinh nào của người dùng.
      · Ủng hộ tính có thể kiểm thử. Việc xây dựng sản phẩm với tư duy kiểm thử trong đầu là thứ có tính quyết định.
      James đã đưa ra những luận điểm vững chắc. Tester cần nâng cao khả năng hiểu coding, build-production, công cụ, và hệ điều hành như Linux và Windows.
    • Ông làm thế nào để quyết định loại thông tin nào nên đưa vào báo cáo cuối cho khách hàng? Loại thông tin nào thì hữu ích và loại nào thì không?
      James: Không có báo cáo nào là hoàn hảo. Chỉ có báo cáo đem đến giá trị cho khách hàng.
      Dưới đây là một số lời khuyên của tôi:
      · Xây dựng lòng tin (bằng cách trở nên đáng tin).
      · Biết ngữ cảnh của việc kiểm thử của mình (test framing).
      · Không bao giờ dùng một con số không nằm trong ngữ cảnh (ví dụ: no test case counts).
      · Nhấn mạnh những hoạt động test về mặt tổng thể (đặt test vào đúng ngữ cảnh).
      · Nhấn mạnh rủi ro của sản phẩm (đặt bug vào đúng ngữ cảnh).
      Chúng ta có thể xây dựng báo cáo cuối với 3 cấp độ:
    • Cấp độ 1: Thực trạng và sự thật (facts and truth) về bug và những điều quan sát được (observations)
    • Cấp độ 2: Làm thế nào mà bạn nắm được những thực trạng đó? Làm thế nào để kiểm thử những thực trạng đó
    • Cấp độ 3: Làm thế nào mà bạn biết việc kiểm thử có tốt không? Tại sao nó đủ tốt, tại sao không?
    • Ông ước lượng công sức bỏ ra cho việc kiểm thử trong một dự án như thế nào?
      James: Không có một bảng tính thần kì nào có thể cho bạn biết việc kiểm thử sẽ mất bao lâu, nhưng ước lượng tốt bắt đầu từ sự hình dung (visualization). Bạn có thể hình dung ra quy trình kiểm thử trong đầu không? Nhiều tester gặp vấn đề khi làm chuyện đó. Nhưng nếu họ không rõ ràng về cái mà việc kiểm thử sẽ trông ra sao hay cảm thấy như thế nào, họ sẽ không nảy ra được ý nào về việc nó sẽ kéo dài bao lâu.
      Đi kèm với điều này là một danh sách những câu hỏi khác cùng câu trả lời, có thể giúp ước lượng công sức dành cho việc kiểm thử trong một dự án:
      · Thật sự cần bao nhiêu thời gian để kiểm thử?
      · Sẽ tốn bao nhiêu thời gian để hoàn tất việc kiểm thử?
      · Lượng thời gian tối thiểu có thể dùng để kiểm thử là bao nhiêu?
      · Cần kiểm thử bao nhiêu để đảm bảo giải pháp đạt chất lượng cao?
      · Cần bao nhiêu test case?
      · Cần bao nhiêu tester?
      · Yêu cầu những kĩ năng test nào?
      · Việc kiểm thử sẽ tốn bao nhiêu tiền?
      · Ta có cần phải kiểm thử tất cả không?
      Cảm ơn James đã dành thời gian trả lời những câu hỏi của chúng tôi. Kiến thức và kinh nghiệm sâu sắc của ông đã mở rộng kiến thức về kiểm thử của chúng tôi và quả là một cơ hội tuyệt vời khi được học hỏi từ ông.
      Cảm ơn James rất nhiều.
      HOA LE

    Người dịch: Trà Giang, 20180517

  • NPS – net promoter score và chuyện may mắn

    Từ NPS…

    NPS là một chỉ số dùng để đo lường mức độ hài lòng của khách hàng với một sản phẩm hay dịch vụ, được đo bằng công thức:

    NPS = % promoters – % detractors

    Cách tính toán cụ thể như sau:

    Phương pháp đo lường:

    • Nội dung khảo sát khách hàng:“ Trên thang điểm từ 0 đến 10, bạn sẵn sàng giới thiệu dịch vụ/ sản phẩm của [công ty] đến bạn bè / người thân là bao nhiêu điểm ?”  Tổng hợp kết quả: Từ kết quả có được sẽ phân khách hàng thành 3 nhóm:
      • Promoters (9 – 10 điểm): là những khách hàng rất hạnh phúc với sản phẩm và dịch vụ của công ty bạn. Họ sẽ là nguồn khách hàng trung thành và giúp doanh nghiệp bạn mở rộng danh sách khách hàng chính là bạn bè / người thân của họ.
      • Passives (7 – 8 điểm): là những khách hàng hài lòng tương đối do còn tồn tại những điểm chưa thoả mãn. Họ có thể dễ dàng chuyển đổi sang sản phẩm / dịch vụ của đối thủ.
      • Detractors (dưới 6 điểm): luôn là những khách hàng “người ra đi đầu không ngoảnh lại” và không ngần ngại lan truyền những góp ý làm ảnh hưởng đến thương hiệu của bạn.
    • Đo lường kết quả: Chỉ số NPS = % (Promoters) – % (Detractors)
    • Ví dụ: Khảo sát 20 khách hàng, trong đó có 10 Promoters (50%) , 5 passives (25%) và 5 detractors (25%). Suy ra: Chỉ số NPS = 50% – 25% = 25%

    (Nguồn: http://blog.cloudjetsolutions.com/nps-chi-so-do-luong-su-hai-long-cua-khach-hang/)

    …đến chuyện may mắn

    Mình biết đến chỉ số này lần đầu tiên khi làm Training Evaluation Form. Chỉ số NPS của một khóa học là một tiêu chí để xem xét độ hài lòng của học viên với khóa học, và có nên tiếp tục tiến hành khóa đó hay không.

    Tuy nhiên, NPS đối với mình không chỉ dừng lại trong phạm vi công việc, nó còn có thể dùng để đo lường sự may mắn của mình nữa. Tại sao ư? Vì NPS chính là lượng hóa của câu “Tiếng lành đồn xa, tiếng dữ đồn xa”, hay chính là sức mạnh của marketing truyền miệng.

    Bất cứ làm chuyện gì, mình đều cần đến những nguồn lực. Có hai dạng nguồn lực: nội tại (do bản thân tự có) và ngoại tại (do khả năng vận động từ cộng đồng (network) của mình). Nguồn lực nội tại thì nhỏ bé và tăng rất chậm, còn nguồn lực ngoại tại thì rất lớn và có khả năng tăng theo cấp số nhân.

    Đối với một con người, NPS của người đó = % số người sẵn sàng nói tốt về người đó với bạn bè, người thân – % số người nói những điều bất lợi về người đóNếu mình là một người đàng hoàng, làm việc tốt, những người xung quanh mình (bạn bè, người thân, đồng nghiệp) khi được người khác hỏi về mình sẽ có thể nói rằng: “Bạn A làm việc được lắm, anh/chị làm việc với bạn ấy được đó”. Một đồn mười, mười đồn trăm, đi đâu mình cũng gặp được người sẵn sàng làm việc cùng, sẵn sàng giúp đỡ. Vận may từ đó mà sinh.

    Ngược lại, nếu mình là một người không đàng hoàng lắm, hẳn nhiên khi ai đó hỏi “Anh/chị tính tuyển nó về, mày thấy ok hông?”, những người xung quanh mình có lẽ sẽ trả lời: “Thằng đó tánh kỳ lắm, anh chị cẩn thận”. Một đồn mười, mười đồn trăm, không ai chịu làm việc chung với mình, không ai chịu giúp mình nữa. Vận rủi từ đó mà tạo.

    Thế nên mình luôn tự nhủ: hãy cố gắng để NPS của mình là một số dương.

    Nhân tiện tám tiếp về NPS, giả sử như mình để ý một anh chàng và mình muốn dùng NPS để đánh giá coi ảnh có ok hông, thì cách tiến hành sẽ là: đi hỏi bà con anh em bạn bè đồng nghiệp của ảnh: “Ảnh làm người yêu có ok hông, anh/chị/em chấm bao nhiêu điểm trên 10?”, sau đó tính toán % promoter và % detractor để tính NPS của ảnh. Nếu NPS của ảnh trên 0 thì ok, còn dưới 0 thì bái bai 😉

    Tuy nhiên, cái khó trong bài toán tính NPS với mình chính là việc chọn mẫu, và đối tượng được chọn để lấy mẫu có đáng tin cậy không. Thế nên, lại link tiếp tới một lưu ý nhỏ nữa: “Chọn bạn mà chơi” 😉 “Hãy cho tôi biết bạn của bạn là ai, tôi sẽ nói cho bạn biết bạn là người như thế nào”, hay như mình đọc được ở đâu đó: “Mình chính là trung bình cộng của ba người mà mình thân thiết nhất”.

    Trà Giang, 30/11/2017

  • System Usability Scale - Thang đo tính khả dụng của hệ thống

    SUS được John Brooke phát minh vào năm 1986, để đo tính khả dụng của bất kì hệ thống nào một cách nhanh chóng.

    Ưu điểm của SUS: Rẻ và nhanh, nhưng vẫn có giá trị nhất định. Thay vì đoán, bạn sẽ biết hệ thống của mình đang ở đâu so với thị trường.

    SUS là một thang đo Likert gồm 10 câu hỏi. Người trả lời sẽ đánh giá mức độ đồng ý từ 1 tới 5, trong đó 5 là hoàn toàn đồng ý, 1 là hoàn toàn không đồng ý.

    1. Tôi nghĩ là mình sẽ dùng hệ thống này thường xuyên

    2. Tôi thấy hệ thống này phức tạp một cách không cần thiết

    3. Tôi nghĩ hệ thống này dễ dùng

    4. Tôi nghĩ tôi cần hỗ trợ từ một chuyên viên kĩ thuật để dùng được hệ thống này

    5. Tôi thấy nhiều chức năng của hệ thống được hợp nhất tốt

    6. Tôi thấy nhiều chỗ không được thống nhất ở hệ thống này

    7. Tôi nghĩ là hầu hết mọi người sẽ học được cách dùng hệ thống này một cách nhanh chóng

    8. Tôi thấy dùng hệ thống này quá cồng kềnh

    9. Tôi cảm thấy tự tin khi dùng hệ thống này

    10. Tôi cần học rất nhiều thứ trước khi có thể làm quen với hệ thống này

    Cách tính Điểm khả dụng (Usability Score) với SUS

    Người dùng đánh giá mức độ đồng ý từ 1 tới 5, trong đó 5 là hoàn toàn đồng ý, 1 là hoàn toàn không đồng ý.

    · Với mỗi câu lẻ, trừ đi 1

    · Với mỗi câu chẵn, lấy 5 trừ đi điểm câu đó

    · Cộng dồn giá trị có được, và sau đó nhân điểm tổng với 2.5

    · Kết quả là một điểm trên thang 100 (không phải là phần trăm đâu)

    Đem điểm này đi so sánh:

    SUS sẽ không có tác dụng nói cho bạn biết chính xác vấn đề nằm ở đâu, nhưng sẽ cho bạn một tín hiệu để biết tính khả dụng của hệ thống như thế nào.

    Điểm trung bình trên thị trường là 68. Nếu dưới 68, tính khả dụng của hệ thống đang gặp những vấn đề rất nghiêm trọng cần được làm rõ.

    80.3 = A. Mọi người yêu thích hệ thống và sẽ giới thiệu nó cho bạn bè.

    68 = C. Bạn đang làm tốt đó, nhưng cần cải thiện thêm.

    51 trở xuống = F. Ưu tiên tính khả dụng lên hàng đầu và chỉnh nó ngay lập tức.

    Cách dùng SUS:

    Đầu tiên, Để người dùng trải nghiệm hệ thống

    Sau đó, cho làm bài đánh giá SUS

    Một số cách khác để đánh giá tính khả dụng của hệ thống:

    · Qualtrics: 5 câu để đánh giá độ hài lòng của khách hàng

    · SUMI — Software Usability Measurement Inventory — một bộ câu hỏi 50 câu

    · SUPR-Q — Standardized User Experience Percentile Rank Questionnaire — 1 bộ 13 câu, đánh giá trang web trên các yếu tố: tính khả dụng, độ đáng tin cậy, giao diện và độ trung thành

    Nguồn tham khảo cho người mới bắt đầu:

    · SUS: A Quick and Dirty Usability Scale [PDF] (1986).

    · SUS: A Retrospective [PDF] (2013).

    Nguồn:

    https://elearningindustry.com/directory/software-categories/learning-management-systems/best/user-experience: Các LMS được đánh giá dựa trên SUS, Perceived Usefulness & NPS

    Lược dịch: Trà Giang

    https://nguyenphantragiang.medium.com/system-usability-scale-thang-%C4%91o-t%C3%ADnh-kh%E1%BA%A3-d%E1%BB%A5ng-c%E1%BB%A7a-h%E1%BB%87-th%E1%BB%91ng-967bfa898d85

  • Nhân vật – Personas

    (bài viết mang tính chất tổng hợp để học, không có giá trị đúng sai, vui lòng không mang đi đâu).

    Persona là gì?

    Personas là một công cụ UX hữu ích để tóm tắt dữ liệu nghiên cứu về mong muốn, nhu cầu, hành vi của người dùng. Các nhà thiết kế tạo ra các hồ sơ nhân vật để nhân cách hóa những phát hiện và hiểu biết của họ cho các bên liên quan của dự án. Điều này là để giúp hướng dẫn việc ra quyết định của họ đối với việc đáp ứng nhu cầu của người dùng.

    Các loại Persona:

    Theo Anthony, về khả năng xài lại của Persona

    Nguồn: https://uxmovement.com/thinking/the-big-problem-with-personas/)

    Wordy persona

    Persona truyền thống gồm các phần sau:

    • A written bio
    • Demographics
    • Stock photo
    • Personality attributes
    • Motivations, Goals, Frustrations, etc

    Hạn chế: khó tra cứu và không tái sử dụng được. Tốn nhiều thời gian để làm, nhưng các bên liên quan không thèm ngó. Do đó, ta có loại persona thứ 2 là Reinventing Persona

    Reinventing Personas

    Để persona dùng được, cần loại bỏ các yếu tố gây nhiễu và chỉ tập trung vào những điều thiết yếu. Persona cần có 5 điểm thiết yếu sau:

    1. Concise snippets of information (context)
    2. Clarity on who the persona represents (context)
    3. Insight into user goals and priorities (user goals)
    4. Details about their tasks that frustrate them (paint points – task-oriented needs)
    5. Details about their tasks that delight them (pleasure points – task-oriented needs)

    persona-patterns-anatomy.png

    Theo Lene Nielsen , phân loại theo các cách tiếp cận persona

    (Nguồn: Personas)

    1. Goal directed persona

    9b41e7956f74eb1629d4c189f193097b.jpg

    2. Role-based persona

     

    3. Engaging persona

    8f9de451987dcf58884332b56b51a62f.jpg

    4. Fictional persona

    Dựa trên giả định của team design, có thể xem như bản nháp đầu tiên, cần được verify lại.

    Một dạng persona khác lượm trên mạng:

    main-qimg-5b82777b13aae3344423c26b1148a084-c.jpeg

    Các bước để tạo ra persona:

    1. Quora: https://www.quora.com/Whats-the-best-way-to-define-personas

    2. https://www.interaction-design.org/literature/article/personas-why-and-how-you-should-use-them

    3dae7b545b1b8323dd21b07333ab6643.jpg

    Tài liệu tham khảo, copy các thể loại:

    https://www.quora.com/Whats-the-best-way-to-define-personas (và một lô related links)

    The Big Problem with Personas

    What makes a good persona?

    https://www.forbes.com/sites/forbesagencycouncil/2018/03/14/how-to-craft-the-ideal-user-persona-for-your-brand/#5f6bda2b6ead

    Tổng hợp: Trà Giang

  • Lời mào đầu khi hỏi về tính khả dụng (Usability Testing) để nhận được phản hồi chân thành

    Câu giới thiệu thảo mai thường thấy trong các buổi kiểm tra tính khả dụng mà tôi (tác giả) gặp quài quài khi đi ngâm cứu về tính khả dụng:

    “Please give your open and honest feedback. I didn’t design this so don’t feel like you need to sugarcoat anything. You won’t hurt my feelings.”

    (Mong bạn phản hồi cởi mở và chân thành. Tôi không thiết kế những thứ này, nên bạn không cần phải thảo mai về điều gì cả. Bạn không làm tôi thấy tổn thương đâu.)

    Tuy nhiên, câu hỏi đặt ra ở đây: liệu việc tách bạch là tôi không liên quan tới thiết kế đó, dù là nói thật hay không, có phải là cách tốt nhất để khuyến khích những người tham gia đưa ra những phản hồi cởi mở và chân thành?

    Tôi đã tiến hành vài ngâm cứu và tìm ra vài thứ sau:

    Đóng khung vấn đề

    Mấy dòng giới thiệu đầu buổi test không nhằm nhò gì mấy để khuyến khích người dùng đưa ra phản hồi cởi mở hết. Với đa số bà con, đưa phản hồi chả thoải mái gì cho dù ở trường hợp lý tưởng đến thế nào, chưa kể là đưa cho thằng cha ất ơ mới gặp nào đó nữa chớ. Nhưng sự thật không bị che giấu là thứ sống còn cho thành công của dự án của khách hàng!

    Khách hàng không trả tiền để xác nhận mấy thứ họ làm tốt rồi. Họ muốn thấy mấy lỗi chủ quan (human error), nghe ý kiến thực tế về thứ đang không hoạt động trước khi quăng người vô dự án làm. Nhưng, trong môi trường phòng lab, đối diện với cái gương hai chiều, bản năng con người trỗi dậy và người ta có xu hướng làm hài lòng.

    Trong thí nghiệm của tôi, mấy câu giới thiệu mẫu mực ngăn cản sự cởi mở và chân thành mà đáng lẽ mấy câu này nên khơi gợi ra. Khi tôi nhắc người tham gia nhớ là một người đã dành thời gian, công sức vào thiết kế này để khiến họ buồn lòng, tôi đang mồi để đo lường phản hồi của họ.

    Họ vẫn e dè nói thẳng, thường rào đón câu trả lời của mình để giảm nhẹ tầm ảnh hưởng (ví dụ: Có lẽ chỉ có mình tôi thôi, nhưng…). Điều này dẫn đến những phản hồi không hiệu quả làm mờ và giảm thiểu ảnh hưởng của vấn đề thiết kế lên user.

    Thí nghiệm

    Tôi tiến hành thử nghiệm này trên 10 buổi kiểm tra tính khả dụng trên một prototype trên InVision mà tôi đã thiết kế. Khách hàng duyệt cho sự thay đổi trên kịch bản. Các phiên kéo dài một giờ tại phòng nghiên cứu tính khả dụng của LiquidHub. Không có khách hàng ở phòng quan sát.

    Những thay đổi và thành công của chúng

    Tôi thử vài thay đổi trên câu giới thiệu, Nếu thành công, câu mới sẽ khơi gợi người tham gia đưa ra phản hồi trung thực mà không suy tính ý kiến của họ với nỗi sợ đề phòng.

    Câu này không đem đến tác dụng tốt:

    “We’re going to look at a prototype that I designed. I put time and energy into coming up with ideas, but I need your feedback to make it the best version it can be.”

    “Chúng ta sẽ xem một prototype mà tôi đã thiết kế. Tôi đã dành thời gian và công thức để đưa ra những ý tưởng này, nhưng tôi cần phản hồi của bạn để biến nó thành phiên bản tốt nhất có thể.”

    Câu này không hiệu quả vì nó đặt áp lực không hợp lý lên người tham gia để giúp tôi hoàn thành công việc. Với lại, việc định hình tôi là một người thiết kế thuần túy, thiết lập một phong thái đối kháng (ví dụ: ý kiến của bạn và ý tưởng của tôi).

    Đây là phiên bản có tác dụng tốt nhất:

    usability-testing_quote

    “My job is to help the client make this as amazing as possible. We’ve had some ideas already. And when we brainstormed, we put all our ideas in the design without judgement. You will help me figure out which ideas are great, which are duds, and come up with new ideas we didn’t think of.”

    “Công việc của tôi là giúp khách hàng biến thứ này thành thứ tốt nhất có thể. Chúng tôi đã có một vài ý tưởng. Và khi chúng tôi động não, chúng tôi đã đưa ra tất cả những ý kiến này vào thiết kế mà không có suy xét gì cả. Bạn sẽ giúp chúng tôi chỉ ra những ý tưởng nào là tốt, tồi, và đưa ra những ý tưởng mới mà chúng tôi chưa từng nghĩ đến.”

    Tại sao câu mới này lại có tác dụng?

    Tôi đã học được rằng dòng mới này thay đổi cách người tham gia tiếp cận toàn bộ tương tác trong bài kiểm tra tính khả dụng. Với câu mới, những người tham gia bắt đầu hành động như một đối tác thiết kế, áp dụng tư duy giải quyết vấn đề thay vì chỉ phản ứng với thiết kế như một sự kích thích.

    Những người tham gia đã thoải mái hơn khi dẫn dắt cuộc thảo luận về các lĩnh vực mà họ quan tâm, dẫn đến những cuộc trò chuyện ngoài hướng dẫn nhiều hơn (nghĩa là, cuộc trò chuyện khác với cuộc thảo luận đã được lên kế hoạch). Những khu vực này đã chín muồi với những hiểu biết sâu sắc.

    Câu mới cũng hiệu quả vì mọi người tin tưởng hơn vào ý kiến ​​của họ. Họ liên tưởng việc cho ý kiến với việc họ đang có ích, không bị phán xét.

    Nó không làm cho họ hoàn toàn quên rằng có thể có những người quan sát đằng sau tấm gương, nhưng nó đã cho họ một mục đích rõ ràng và sự hiểu biết về cách đáp ứng sự mong đợi của chúng ta. Nói tóm lại, nó khai thác bản năng con người để làm hài lòng mọi người theo cách có lợi cho dự án.

    Kết luận

    Kết quả thử nghiệm của tôi khiến tôi tò mò muốn thử nghiệm các “quy tắc” kiểm tra tính khả dụng được chấp nhận rộng rãi khác. Ví dụ, trong phòng thí nghiệm, chúng tôi được hướng dẫn để tiến hành trên các nhân vật (persona) trung lập, có thể đo lường được để chúng tôi không ảnh hưởng lên người tham gia bằng những khẳng định bằng lời hoặc không lời.

    Điều gì sẽ xảy ra nếu chúng ta phá vỡ quy tắc đó? Liệu việc này có “định hướng nhân chứng”, như chúng ta đã được cảnh báo, hay chúng sẽ giúp ta xây dựng mối quan hệ? Ta có thể làm gì để phá vỡ vỏ bọc của người tham gia nhanh hơn để có được những phản hồi trung thực và cởi mở?

    Tôi khuyến khích các nhà nghiên cứu và nhà thiết kế tham gia cùng tôi trong cuộc thám hiểm này. Miễn là thử nghiệm được thực hiện với sự tôn trọng người dùng và phục vụ các mục tiêu của khách hàng, chúng ta nên tuân theo quy trình của riêng mình để lặp lại, xác thực và kiểm tra.

    Nói cho cùng, chúng ta là các chuyên gia cải tiến quy trình. Nếu chúng ta không hướng các phương thức của mình về phía chính bản thân mình thì chúng ta đang bỏ lỡ cơ hội để phát triển.

    The Line to Say in Usability Testing to Get Honest Feedback

    Dịch: Trà Giang

     

     

  • UX – Nút Cancel – Tại sao không nên có màu

    Lỗi thường gặp: nút Cancel có màu

    Bài này giải thích công dụng của nút Cancel, và tại sao không nên dùng màu cho nút này.

    cancel_button-non_action.png

    Nút Cancel thường xuất hiện ở những màn hình cần sự xác nhận

    Nút Cancel hay còn có những tên khác như “Not Now”, “No Thanks”, “Maybe Later”, or “Skip” tùy ngữ cảnh. Tuy nhiên, chúng có chung một tác dụng: bỏ qua (dismiss) màn hình hiện tại mà người dùng đang sử dụng, đưa người dùng về màn hình trước đó. Nút Cancel đóng vai trò như một cái phao cứu sinh để không tạo ra những thay đổi không mong muốn trên hệ thống.

    Do đó, nút Cancel nên tạo cảm giác an toàn cho người dùng, bằng cách thể hiện sự dự phòng an toàn (a fallback to safety), chứ không phải là một lời kêu gọi hành động (a call to action).

    Phân biệt nút Cancel và những loại nút khác:

    • Normal button: khi nhấn vào sẽ tạo ra thay đổi trên hệ thống. Dấu hiệu thể hiện điều này là màu trên button.
    • Cancel button: khi nhấn vào không tạo ra thay đổi trên hệ thống. Do đó, nếu dùng dùng màu, người dùng sẽ bối rối: “nhấn vô cái nút này có thay đổi data gì không ta”. Thay vào đó, ấn tượng đúng cần được tạo ra ở đây là “yên tâm, nhấn vô đây, không có thay đổi gì đâu”.cancel_button-non_action

    Đối với nút button, nên:

    • Dùng màu trung tính, để phân biệt với các nút CTA khác. Càng nhiều nút thì màu trung tính này phải đủ nổi bật để người dùng nhận diện nhanh hơn. Đối với người lỡ bấm nhầm và cần thoát ra nhanh thì màu xám này giúp họ nhận ra ngay để nhấn vào. Đối với những người sẵn sàng hành động thì màu xám này giúp họ bỏ qua nó, tập trung vào các nút CTA.
    • Dùng màu xám đủ tối, để dễ đọc và không bị nhầm với trạng thái disable. Để đảm bảo dễ đọc thì nên kiểm tra độ tương phản bằng một công cụ WCAG 2.0 contrast ratio chẳng hạn như Contrast Checker. Công cụ này giúp chỉ ra màu xám đang dùng có đạt chuẩn màu dễ đọc không.cancel_button-gray

     

    cancel_button-gray

    Tóm lại: hãy trung lập (neutralize) nút Cancel

    Đa số trường hợp người dùng kích hoạt màn hình xác nhận, họ đã sẵn sàng hành động. Tuy nhiên khi họ bấm nhầm và không muốn làm hành động đó, nút Cancel cần đưa cho họ sự an toàn.

    Một nút Cancel có màu đem đến tín hiệu sai. Nó khiến người dùng xem nó là một lời kêu gọi hành động thay vì một sự rút lui an toàn. Hãy trung lập nút Cancel để người dùng có cảm giác họ kiểm soát tốt hơn và tự do hơn khi sử dụng ứng dụng.

    Nguồn: https://uxmovement.com/buttons/why-cancel-buttons-should-never-have-a-color/

    Lược dịch, phóng tác, sắp xếp, chém gió: Giang Nguyễn