Spaghetti Tower Marshmallow Challenge

Spaghetti Tower Marshmallow challenge là một thử thách khá nổi tiếng và được thử nghiệm bởi nhiều đối tượng khác nhau, từ trẻ em cho đến người lớn, từ các trường học, cho đến hoạt động build-up nội bộ doanh nghiệp. Tôi dám chắc bạn đã từng ít nhiều nghe đến nó, hoặc cũng từng biết đến nó nhưng không rõ tên gọi của nó mà thôi. Vậy thì cái challenge này có điều gì đặc biệt mà tôi lại dành hẳn một bài viết cho nó?

Challenge này là gì?

Cha đẻ của challenge này là Peter Skillman, ông đã thiết kế ra nó trong lúc đang giữ chức General Manager of Smart Things (tạm dịch là Tổng giám đốc những thứ thông minh) tại Microsoft. Luật chơi thì vô cùng đơn giản (trẻ em cũng là đối tượng thí nghiệm):

  • Người chơi được chia thành các nhóm nhỏ (khoảng 3-4 người)
  • Nhiệm vụ chung là xây dựng lên một cấu trúc cao nhất có thể chống đỡ được một viên kẹo dẻo (marshmallow).
  • Timebox: 18 phút
  • Các vật dụng được cung cấp:
    • 20 sợi spaghetti khô (khá giòn và dễ gãy)
    • 1m băng dính
    • 1 đoạn dây
    • 1 gói kẹo dẻo (marshmallow)

Theo mô tả của mình, Peter Skillman đã tiến hành thử nghiệm trong suốt 5 năm, với hơn 700 người, với nhiều nhóm khác nhau: từ trẻ em, học sinh cho đến sinh viên MBA, kỹ sư, quản lý,…

Vậy theo bạn, nhóm nào là nổi trội hơn cả?

Kỹ sư, Quản lý,… ?

Không. Nhóm thắng cuộc ở đây là trẻ mẫu giáo. Đúng vậy, nhóm trẻ 6 tuổi là kẻ thắng cuộc ở thử thách trên, trong khi nhóm về bét lại là sinh viên MBA.

Vậy điều gì đã khiến những đứa trẻ trở đánh bại tất cả? Liệu rằng chúng có tư duy hay kế hoạch gì đặc biệt chăng? Hay vì chúng là trẻ em nên quen thuộc với kẹo dẻo hơn người lớn? Tất cả đều không đúng, một đứa trẻ làm sao có thể thông minh hơn nhóm kỹ sư và quản lý, chúng không thể hiểu biết về kiến trúc hơn đội người lớn được. Vậy bí quyết ở đây là gì?

Đó chính là cách mà trẻ con tiếp cận bài toán. Chúng chỉ đơn thuần là bắt tay vào làm và làm. Chúng thử nghiệm nhiều cách hơn, cứ xây đổ thì chúng lại xây lại, cho đến khi xây ra được một kiến trúc cao nhất trong các lần thử.

Hay nói cách khác, chúng bắt đầu từ những thất bại và học hỏi chúng ngay lập tức. Chúng cứ xây thử rồi kiểm tra, sau đó lại thử tiếp và kiểm tra tiếp, cho đến khi hết 18 phút quy định. Chúng không hành động theo một con đường được vạch sẵn nào cả, và kỳ diệu (có thật không?) là đây lại là cách đem đến chiến thắng.

Sinh viên MBA, trái lại, là những kẻ nghĩ và tính toán rất nhiều rồi mới hành động, thì kết cục lại là kẻ về bét.

Rõ ràng, nghĩ nhiều so với việc xắn tay vào làm, thì việc xắn tay vào làm hẳn nhiên là tốt hơn rồi.

Vậy suy nghĩ nhiều là xấu?

Không phải vậy, về sau khi challenge phổ biến, thì người chiến thắng lại là các kỹ sư.

Tôi thử challenge

Hồi còn làm ở công ty cũ, tôi cũng đã có cơ hội join thử cái challenge này (Thực ra là công ty tổ chức, và tôi thì mặc nhiên phải tham gia). Chúng tôi chia làm 4 đội, mỗi đội 3 người, tôi cũng không nhớ cụ thể cơ cấu ban bệ thành phần tham gia, nhưng duy chỉ có team tôi đặc biệt là vì có 3 người là kỹ sư (2 ông IT, 1 ông kỹ sư hàng không), đến nỗi các sếp còn bảo là unfair team.

Khi bắt đầu challenge, đồng đội của tôi rất tự tin và chia sẻ rằng mình đã từng biết đến challenge này rồi, và chúng tôi cứ làm theo best practices là xong mà thôi. Như tôi đã nõi ở trên, khi challenge phổ biến thì người chiến thắng là các kỹ sư. Họ bắt đầu biết vận dụng các kiến trúc cấu trúc sau khi đã nghiên cứu và tính toán đủ lâu. Kiến trúc tối ưu nhất được đưa ra là xây theo dạng lập phương (Cube), sau đó build từng tầng lên thành dạng Kim tự tháp (Pyramid).

Và đó chính là những gì mà đồng đội truyền đạt lại cho chúng tôi. Chúng tôi cũng làm đầy đủ các bước, lên ý tưởng, phác hoạ, sau đó triển khai. Cấu trúc mà chúng tôi chọn là xây dựng các khối lập phương.

(Source: https://makefuncreating.com/crafts/how-to-build-a-tall-spaghetti-and-marshmallow-tower/)

Và team chúng tôi đã xuất sắc giành giải nhất. Có cái nịt

Chính xác thì team chúng tôi về gần bét (3/4) đội tham dự.

Còn team giành giải nhất, tréo ngoe thay, lại là team của phòng Marketing (nơi mà chẳng có một ai là kỹ sư cả).

Giải pháp của họ là gì? Giống hệt những đứa trẻ kể trên, họ chỉ thử nghiệm, học hỏi và thử nghiệm tiếp, không có gì đặc biệt ở đây hết.

Vậy tại sao chúng tôi lại thua? Chúng tôi đã không tính đến một yếu tố cực kỳ quan trọng, đó chính là THỜI GIAN. Chúng tôi chỉ có chính xác 18 phút cho toàn bộ công việc, từ lên ý tưởng, phân tích thiết kế, và triển khai (kể cả testing và release nữa, LOL). Kiến trúc chúng tôi phác thảo là chính xác, tuy nhiên thời gian để chúng tôi triển khai nó thì không đủ, và dẫn đến kết cục cuối cùng là chúng tôi đã thua cay đắng.

Tôi học được gì

Nếu đem lên bàn cân, thì spaghetti tower marshmallow challenge chẳng khác gì bài toán xây dựng một sản phẩm mà tôi - một người kỹ sư IT đang phải giải quyết hàng ngày.

Chúng tôi cũng có target, ý nghĩa, thời gian, nhân sự, budget,… và cái cấu trúc cao nhất mà challenge yêu cầu cũng tương ứng với việc xây dựng một sản phẩm phần mềm tốt nhất (thế nào là tốt thì tôi sẽ giải thích ở một bài viết khác)

Nhìn từ góc độ quản lý dự án, thì challenge này là một dự án, nguồn lực chúng tôi đã có, và định nghĩa hoàn thành của dự án cũng đã có.

Vậy thì cụ thể tôi học được gì?

Bài học đầu tiên: Khi xây dựng một sản phẩm, mà trong tay chúng ta chưa có một mô hình, hoặc con đường cụ thể nào, thì cách tối ưu nhất là hãy cứ thử - fail - học - thử. Hãy làm như tụi trẻ con ở nghiên cứu của Peter Skillman kể trên. Điều này cũng được các công ty ở Sillicon valley thực hiện triệt để, thậm chí còn có một thuật ngữ nổi tiếng cho việc này “fail fast and fail cheap”. Điều này cũng là dể hiểu thôi vì theo một số thống kê không chính thức, có khoảng 90% các startup sẽ chết (10% chết trong ngay năm đầu tiên), và chỉ có 10% là kẻ thành công (hoặc là chưa chết cho đến thời điểm thống kê). Vì vậy, sẽ quá là lãng phí nếu các startup nghĩ quá nhiều mà không làm gì hết (như các sinh viên MBA ở thí nghiệm trên), trong khi vẫn chưa rõ ràng một con đường thành công nào cả.

Tuy nhiên, nếu đã có con đường dẫn đến thành Rome rồi thì ta cứ men theo nó mà đi thôi, lúc này việc thử nghiệm nhiều lại hoá thành dở hơi và lãng phí. Khoan, bạn vẫn chưa quên lần thực nghiệm của tôi ở trên chứ? Tôi có model rõ ràng rồi, tôi có phác hoạ rồi, vậy mà tôi vẫn về sau là sao? Lý do tôi cũng đã kể trên rồi, bạn phải chú ý đến thời gian nữa. Nhưng thời gian chỉ là một cách minh hoạ ngắn thôi, bản chất ở đây là bạn phải chú ý đến nguồn lực của bạn. Bạn cần phải tính toán xem mình, với những thứ trong tay, có khả năng theo con đường kia đến thành Room thành công hay không? Giả sử như bên đó bắt bạn phải đi xe ngựa, trong khi team lại đi dép cao su Trường Sơn, mà bạn vẫn cắm đầu bắt team phải đi, thì kết quả là gì ai cũng rõ. Và đó cũng chính là bài học thứ 2.

Ngoài ra, trong quá trình phát triển sản phẩm, tôi cá rằng phần lớn sản phẩm của bạn cũng sẽ dựa trên một vài sản phẩm nào đó đã có sẵn trên thị trường, và bạn sẽ thêm một số tính năng khác mà bạn giả định rằng sẽ vượt trội hơn đối thủ, và đem lại lợi thế cạnh tranh, cũng như được người dùng đón nhận. Ở trường hợp này, bạn hãy học hỏi và đi theo con đường của các sản phẩm tương tự để tiết kiệm thời gian và nguồn lực, tuy nhiên, cần phải chủ ý, đến đoạn bạn cần phải tách đoàn và see you again (như Dom & Brian trong Fast and Furious vậy).

Tôi cũng không phản đối việc sản phẩm của bạn có thể là độc nhất, là đột phá sáng tạo, tuy nhiên xác suất đó có nhiều không? Và nếu giả sử bạn rơi vào trường hợp này, thì chiến lược ở đây hẳn bạn cũng đã rõ rồi, là làm theo bọn trẻ con mẫu giáo thử - fail - học - thử. Và quan trọng, việc thử nghiệm này phải do thị trường quyết định, không phải là bạn, CEO,CFO,… hay bất cứ ai đánh giá cả.

Ngoài ra, trong quá trình phát triển sản phẩm, sẽ có những lúc bạn cũng sẽ cần phải phát triển một hoặc một vài tính năng mới rơi vào 1 trong 2 trường hợp trên (là đã có đường đến Rome hay là chưa ai mở), thì chiến lược là gì bạn đã hiểu rồi chứ.

Tuy nhiên, nếu trong tay bạn có đủ nguồn lực, hãy tự tin là cô gái mở đường đi, vì risk đi kèm với return mà, high risk high return. Bạn mở đường thành công, bạn là winner - winner take all.

“Trên đời này làm gì có đáy, người ta bán mãi cũng thành đáy thôi” (Lỗ To)

À tôi nhầm,

“Trên đời này làm gì có đường, người ta đi mãi thì thành đường thôi” (Lỗ Tấn)