Thao Trinh – Người thích tự do và lang thang như gió -
  • Trang chủ
  • Chuyện nghề
  • Đọc
  • Me
Thao Trinh – Người thích tự do và lang thang như gió -
Trang chủ
Chuyện nghề
Đọc
Me
  • Trang chủ
  • Chuyện nghề
  • Đọc
  • Me
Agile (APM), Chuyện nghề

Làm sản phẩm có nên áp dụng Scrum không?

thaotrinh.info__lam-san-pham-co-nen-ap-dung-scrum-khong

Câu hỏi:
Làm sản phẩm nó nên áp dụng Scrum không?

Vấn đề gặp phải:

Tình hình là công ty mình đang chuyển đổi sang mô hình scrum cho việc phát triển sản phẩm. Nó khá là khó khăn khi mà các tính năng phải chia nhỏ hết mức để có thể hoàn thành Sprint Goal. Nhưng chính vì chia nhỏ ra như vậy mà End User không được có trải nghiệm tốt nhất khi tính năng không hoàn thiện 100% (vì chia nhỏ cho từng sprint). 2 tuần để làm 1 số tính năng mà còn phải fix production bug cũ + thêm không đánh giá được hết ảnh hưởng nền chuyện không hoàn thành Sprint Goal là chuyện thường xảy ra. Có cách nào khắc phục được không.

2 nữa là bản thân mình thấy nếu không tính năng không hoàn thiện mà đã đưa tới khách hàng thì tỷ lệ khách không lựa chọn sử dụng là cao với trải nghiệm lần đầu mà team không để tý tới điều đó thì mà chỉ nghĩ tới có sản phẩm để sale với KH thôi thì cũng không ổn mà 1 designer không đủ tiếng nói. Vậy có cách nào để có lý do thuyết phục hơn không hay mình suy nghĩ vậy là chưa đúng.

Trả lời:

Dù bạn làm gì, Agile (hay Scrum) sẽ giúp được bạn.

Agile giúp tổ chức hay đội nhóm của bạn linh hoạt và chủ động hơn trong việc tiếp cận và giải quyết vấn đề. Mọi đội nhóm với tinh thần và cách làm việc như trên, bạn sẽ đồng ý với tôi nó sẽ “tốt” hơn phiên bản hiện tại của đội nhóm bạn đang có đúng không?

Vậy tại sao lại không Agile (hay Scrum)?

Trở lại vấn đề của bạn.

  1. Tính năng chia nhỏ và End user không có sản phẩm hoàn thiện để sử dụng sau mỗi sprint.
  2. Sprint Goal thường không đạt được, và thường xuyên xảy ra.
  3. Đưa sản phẩm chưa hoàn thiện tới khách hàng.

Hãy luôn nhớ rằng, releaseable (hay phần tăng trưởng được) không nhất thiết phải release ngay lập tức. Nó có thể đợi tới sprint sau, khi tích hợp đủ mới thực hiện release. Việc release không giới hạn (bắt buộc) khi bạn kết thúc sprint (tất nhiên team bạn có thể làm điều này nếu tính năng đó thực sự hay ho và “đủ” hoàn thiện để release).

Vấn đề thứ 2 là câu hỏi sẽ nhiều nhóm mới tiếp cận Scrum sẽ quan tâm. Sprint Goal không hoàn thành sẽ do nhiều nguyên nhân, dựa trên follow của Scrum, mình xin note một vài ý kiến:

  • Sprint Goal chưa thực tế. Nó quá nhiều US, có lẽ vậy.
  • Nhóm đang chưa thực sự tập trung vào Goal.
  • Có nhiều issue chen ngang trong sprint (PO có một chút điều chỉnh – SM chưa follow được, team chỉ quan tâm tới task mà bỏ quên sprint goal).
  • Plan chưa thực sự hợp lý: dựa trên các sprint trước, việc lập kế hoạch cho sprint sau là quan trọng, nếu team bạn liên tục fail sprint goal, hãy hỏi SM sao lại thế. Nếu bạn là SM hãy tự hỏi bản thân và xem lại các số liệu để nhìn nhận vấn đề.

Vấn đề tiếp theo, hãy follow PO để cùng thảo luận. Dù đề cao việc tổ chức đội nhóm, nhưng Scrum đề xuất 3 vai trò, trong đó PO là “chủ” thực sự của sản phẩm. Chỉ anh ấy mới biết tính năng release phục vụ việc gì. Và tại sao cần release một tính năng chưa thực sự hoàn hảo. Mọi thành viên trong development team nên quan tâm tới sprint goal nhiều hơn việc release khi nào và release cái gì. Tất nhiên bạn có trách nhiệm quan tâm tới đứa con tinh thần của mình, nhưng bằng cách hãy trao đổi nếu thấy điều đó có vấn đề. PO sẽ vui vẻ lắng nghe góp ý của bạn, vì dù sao, bạn cũng là người tạo ra sản phẩm – và biết đâu đấy là một khách hàng khó tính muốn góp ý cho sự phát triển của doanh nghiệp?

June 10, 2020by thaotrinh
Chuyện nghề, Đọc

Vì sao bạn nên phân tích đối thủ để đưa ra giải pháp thiết kế tốt hơn

thaotrinh.info__vi-sao-ban-nen-phan-tich-doi-thu-de-dua-ra-giai-phap-thiet-ke-tot-hon

Vì sao bạn nên phân tích đối thủ để đưa ra giải pháp thiết kế tốt hơn, và làm việc đó như thế nào ?

Bài dịch từ tổ chức Interaction Design Foundation (bài viết gốc https://bit.ly/3okB8lE)

Một người thiết kế UX không hề sống cách biệt với phần còn lại của thế giới. Mỗi ngày, bạn bắt gặp và sử dụng sản phẩm và dịch vụ được thiết kế bởi người khác. Trước khi bắt đầu một dự án thiết kế UX mới, việc hiểu phạm vi của nó bằng cách nhìn xung quanh xem thử những người đi trước đã làm gì, và phân tích một cách nghiêm khắc (critically analyzing) những thiết kế của họ – là điều hoàn toàn hợp lý. Tại bài viết này, chúng tôi sẽ phác thảo một số một số nhân tố chính cấu thành lên “Tư duy so sánh” (comparative mindset) và làm như nào để chúng dẫn bạn tới thành công

Phân tích đối thủ cạnh tranh là một trong các công cụ cơ bản về áp dụng UX. Thực tế, một bản báo cáo phân tích UX của đối thủ cạnh tranh là một trong các tài liệu UX phổ biến. Tất nhiên, khi kêu gọi thiết kế một phương pháp giải quyết cho một vấn đề, bạn sẽ muốn biết những người khác đã giải quyết nó như thế nào, xác định xem điểm mạnh cũng như điểm yếu, và xem liệu thiết kế của bạn có cải thiện được những gì mà người đi trước đã làm không. Tại bài viết, chúng ta sẽ khám phá việc phân tích đối thủ như là một chiến lược và cách tư duy, hơn chỉ là một công cụ mà chỉ được sử dụng trong vài dịp cần thiết. Tiếp cận và sử dụng tư duy phản biện và tư duy so sánh là điều cần thiết cho sự nghiệp của một người thiết kế UX. Hãy cùng khám phá vì sao nó cần thiết, và làm thế nào để vận dụng chúng.

CÓ NHỮNG ĐỐI THỦ CẠNH TRANH NÀO MÀ MỘT DỰ ÁN UX GẶP PHẢI ?

Trước khi bắt đầu công việc phân tích đối thủ, quan trọng là bạn cần biết rằng bất kỳ dự án UX nào luôn phải đối mặt với 2 loại đối thủ cạnh tranh. Thi thoảng, bạn sẽ được giao nhiệm vụ thiết kế sản phẩm hoặc dịch vụ mà nó cạnh tranh trực tiếp với sản phẩm/dịch vụ khác (vd: Uber là đối thủ cạnh tranh trực tiếp của Lyft), thực tế điều này rất bình thường. Nhưng nhiều trường hợp, bạn phải đối mặt với đối thủ gián tiếp. Một số sản phẩm có thể phục vụ mục đích hoàn toàn khác với sản phẩm của bạn, tuy nhiên, một số thành phần tương tác (interaction element), hay thành phần giao diện (interface element) hoặc User flow sẽ có vài điểm chung. Ví dụ, bạn có thể nhìn xem quá trình để tạo một tài khoản mới, cách mà họ chào mừng thanh viên mới, hoặc làm như nào mà họ có thể cô đong thông tin trên phạm vi giới hạn của màn hình. Với một số trường hợp như vậy, chúng ta có thể cân nhắc chúng như sản phẩm cạnh tranh gián tiếp của sản phẩm bạn đã, đang hoặc sẽ phát triển.

KHI NÀO VÀ TẠI SAO CHÚNG TA NÊN SO SÁNH SẢN PHẨM THIẾT KẾ CỦA MÌNH VỚI NGƯỜI KHÁC?

Câu trả lời ngắn cho câu hỏi này, là tại bất kỳ khi nào mà bạn có cơ hội. Bất kỳ lúc nào mà bạn bắt tay vào làm một dự án mới, hoặc làm việc với thứ không liên quan và chả mất quá nhiều thời gian, mỗi lần gặp một một sản phẩm khác là một cơ hội để học tập thông qua so sánh.

“Fortune favors the prepared mind”

– Louis Pasteur

Đối với vế câu hỏi “vì sao”, thì có 2 hướng trả lời. Thứ nhất, quan sát những gì người khác đang làm cũng cho phép bạn xác định những thứ họ không làm (hoặc làm chưa tốt), nhớ thứ này mà nó sẽ tạo cơ hội cho bạn đưa ra một sản phẩm/dịch vụ tốt hơn. Bạn có thể giả định rằng bất kỳ giải pháp thiết kế nào ngoài kia được thiết kế để phục vụ một lý do nào đó. Kiểm tra xem cách những người thiết kế khác gỡ rối một vấn đề cụ thể có thể là một nguồn cảm hứng cho việc học tập và phát triển kỹ năng bản thân. Tuy nhiên, nó không chỉ dừng lại ở mức copy. Học tập có nghĩa là bạn đào sâu những thành phần tương tác và giao diện đó để hiểu vì sao chúng hoạt động tốt, và rồi áp dụng sự hiểu biết của mình trong thiết kế.

ĐẢM NHẬN VIỆC PHÂN TÍCH ĐỐI THỦ CẠNH TRANH NHƯ LÀ MỘT PHẦN CỦA QUY TRÌNH THIẾT KẾ UX.

Theo một cách chính thức hơn, phân tích đối thủ thường được thực hiện vào thời điểm ban đầu của dự án. Trong trường hợp này, bạn sẽ quan sát thị trường, tìm hiểu xem bạn phải đối mặt với bao nhiêu đối thủ trực tiếp, rồi cố gắng xác định những điểm yếu của trải nghiệm người dùng của các sản phẩm đó, để vạch ra những gì bạn có thể làm để giúp vấn đề trải nghiệm tốt hơn. Nếu như không có bất kỳ đối thủ cạnh tranh trực tiếp nào, bạn có thể thử tìm một số khía cạnh khác nhau về mặt trải nghiệm, và xem họ đã làm như thế nào để để đạt được những mục tiêu phụ đó. Thông thường, phía khách hàng đã làm cái này trước cả bạn rồi, họ sẽ xem và so sánh một số đối thủ cạnh tranh gián tiếp rồi đưa một số yêu cầu như “Tôi muốn cái app giống như này, như này và như này”

Thi thoảng, việc phân tích đối thủ có thể diễn ra sau khi sản phẩm đã đưa ra thị trường và chạy một khoảng thời gian. Sau đó một đối thủ cạnh tranh trực tiếp xuất hiện, rồi bạn sẽ muốn xem họ đang làm gì cũng như làm sao để sản phẩm của bạn đấu tranh lại sản phẩm của họ. Một số thành phần tương tác mới có thể được đưa vào (vd: giao diện âm thanh chẳng hạn) và bạn cần cân nhắc liệu có nên update sản phẩm của mình hay không. Người thiết kế UX cũng có thể được giao nhiệm vụ xác định xem sản phẩm cần update những trend mới nhất ( vd: một ngôn ngữ thiết kế mới được đưa ra từ nhà sản xuất thiết bị).

Dù thế nào đi chăng nữa, khá thường xuyên, việc phân tích đối thủ cạnh tranh được cân nhắc như là hoạt động không chính thức mà người thiết kế UX thực hiện vì lợi ích của bản thân họ. Nó có thể là một hướng đi tuyệt vời để theo kịp với các trend mới nhất trong ngành công nghiêp sản phẩm, phát triển và có được cảm hứng cho những thiết kế trong tương lai, hoặc để update một cái đã có. Nó cũng là việc học hỏi bằng cách đào sâu nghiên cứu lý do mà một thiết kế có thể hoạt động tốt (hoặc không tốt)

LÀM SAO ĐỂ TẬN DỤNG TỪ VIỆC CHẠM TRÁN NHỮNG ĐỐI THỦ GIÁN TIẾP?

Là một người thiết kế, bạn có thể học hỏi rất nhiều từ đối thủ. Khi bạn sử dụng những sản phẩm/dịch vụ trong đời sống thường ngày, từ góc nhìn là người sử dụng chúng, hãy để ý tới những giải pháp thiết kế vừa tạo sự thanh lịch cũng như sáng tạo mà chúng sẽ phục vụ như một nguồn truyền cảm hứng tới sản phẩm thiết kế của riêng bạn. Tuy nhiên, chỉ dừng lại ở mức sao chép là CHƯA ĐỦ. Chỉ vì một phần của thiết kế hoạt động hiệu quả trong một trường hợp cụ thể, không có nghĩa rằng nó cũng sẽ hoạt động tốt như vậy tại sản phẩm khác. Cùng với đó, bạn nên luôn luôn để ý tới mối nguy hiểm đối với việc chạy theo trend một cách mù quáng. Có một sự khác biệt RẤT LỚN giữa một thiết kế tốt và một thiết kế CHỈ BIẾT THEO TREND: thiết kế tốt có giá trị lâu dài và nó là sự kết hợp giữa cảm hứng và tính thẩm mỹ, cùng với đó là sự hỗ trợ của kiến thức khoa học và nghiên cứu. Những thiết kế này hòa hợp với một nhu cầu cụ thể từ khán giả, và chúng xác định tình trạng thật của con người một cách hiệu quả (they address very real dimensions of the human condition effectively). Trend thì chỉ đến rồi đi, đơn giản vì nó chỉ hỗ trợ góc nhìn thẩm mỹ của nhà thiết kế.

“Những ứng dụng giả tưởng mà chỉ biết chạy theo trend và trắng trợn lờ đi các quy ước căn bản về tính khả dụng, các cách áp dụng UX tốt và các nguyên tắc căn bản về thiết kế tương tác, có khả năng lớn sẽ thất bại trong thế giới thực”

– Miklos Philips, UX Principal Lead, Prototypr.io

Khi đánh giá các sản phẩm thiết kế khác, quan trọng là bạn đừng chỉ tập trong vào nhân tố “wow” mà cũng phải nắm bắt những câu hỏi “Vì sao?” – Ví dụ như, điều gì khiến một sản phẩm thiết kế cụ thể hoạt động tốt? Liệu nó vẫn hoạt động tốt nếu được đặt tại một bối cảnh sử dụng hoàn toàn khác? Để cho ngắn gọn, thì hãy đào sâu nghiên cứu thứ mà nó khiến một thiết kế tốt hơn – hoặc tệ hơn.

#JustUXStuff

March 4, 2018by thaotrinh

About me

Đề xuất cho bạn

Định nghĩa công việc theo phương pháp S.M.A.R.T

Định nghĩa công việc theo phương pháp S.M.A.R.T

Revision database

Revision database

Tạo đối tượng trong C# từ url API hoặc Json String

Git hướng dẫn cơ bản cho người mới

Git hướng dẫn cơ bản cho người mới

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Bài mới

  • Định nghĩa công việc theo phương pháp S.M.A.R.T
  • Họp xong việc và họp thêm việc
  • Giá trị của Scrum Master trong case study của Leflair
  • Sự khác biệt giữa làm việc chăm chỉ và làm việc chăm chỉ một cách thông minh.
  • Một tách trà

Mọi người quan tâm

No comments to show.

Chuyên mục

  • Agile (APM)
  • Chuyện nghề
  • Đọc
  • Học nghề
  • Làm thợ
  • Uncategorized

Tags

Agile Dev Kanban Marketing Nhóm Scrum Sách Sản phẩm Think Tôi tự học

Người học thức, tức là người thà biết ít mà thật biết những gì mình biết, còn những gì mình không biết, thì cũng biết rõ là mình không biết. “Không có sự dốt nát nhục nhã bằng tin tưởng rằng mình đã biết trong khi mình chưa biết”. Văn hóa là một vấn đề thuộc phẩm chứ không phải thuộc lượng

© 2015 copyright thaotrinhminh@gmail.com // All rights reserved // Privacy Policy