Số 418Quản lý Phạm vi

Glitch của Tiny Speck (2011–2012): đóng trò chơi, giữ lại công cụ chat nội bộ và chuyển hướng thành Slack

Tiny Speck của Stewart Butterfield ra mắt trò chơi trực tuyến Glitch tháng 9/2011, rồi đưa trở lại giai đoạn beta chỉ hai tháng sau. Ngày 9/12/2012 trò chơi đóng cửa vì sức hút hạn chế. Công cụ nhắn tin nội bộ đội dùng khi làm game trở thành nền tảng của Slack, và công ty đổi tên thành Slack Technologies. Bài học về chuyển hướng (pivot) phạm vi sản phẩm dựa trên bằng chứng.

Nguyễn Thu Hà, PMP

19/09/2026

2 phút đọc 0

Bình luận0

Bối cảnh thực tế

Tiny Speck, do Stewart Butterfield (đồng sáng lập Flickr) dẫn dắt, phát triển Glitch — trò chơi trực tuyến nhiều người chơi miễn phí chạy trên trình duyệt bằng Adobe Flash.

Glitch chính thức ra mắt ngày 27/9/2011.
Ngày 30/11/2011, trò chơi quay lại trạng thái beta ("unlaunch"), với lý do cần cải thiện khả năng tiếp cận cho người mới và chiều sâu cho người chơi lâu năm.
Ngày 9/12/2012, Glitch đóng cửa; nhà phát triển nêu lý do sức hút với người chơi hạn chế.
Công cụ nhắn tin nội bộ được đội xây để phối hợp khi làm Glitch trở thành nền tảng của Slack. Tiny Speck sau đó đổi tên thành Slack Technologies.

Phân tích nguyên nhân theo chuẩn PMP

Dữ liệu người dùng là tín hiệu để xét lại phạm vi
Việc "huỷ ra mắt" sau hai tháng cho thấy đội đã đọc tín hiệu giữ chân người chơi kém. Khi giả thuyết giá trị không đúng, tiếp tục mở rộng phạm vi cũ chỉ đốt thêm nguồn lực.
Giá trị nằm ở sản phẩm phụ không có trong phạm vi chính thức
Công cụ chat nội bộ vốn là phương tiện, không phải sản phẩm bàn giao. Nhận ra giá trị của nó đòi hỏi tổ chức nhìn vào tài sản và năng lực đã tích luỹ, không chỉ vào WBS ban đầu.
Đóng dự án có trật tự
Đóng một sản phẩm đang có người dùng cần kế hoạch: thông báo, hoàn tiền, xử lý dữ liệu. Đây là một phần của quy trình đóng dự án (Close Project or Phase).

Lẽ ra PM nên làm gì (và điều đáng học)

Đặt chỉ số giả thuyết giá trị từ đầu

Glitch của Tiny Speck (2011–2012): đóng trò chơi, giữ lại công cụ chat nội bộ và chuyển hướng thành Slack

Bối cảnh thực tế

Phân tích nguyên nhân theo chuẩn PMP

Dữ liệu người dùng là tín hiệu để xét lại phạm vi

Giá trị nằm ở sản phẩm phụ không có trong phạm vi chính thức

Đóng dự án có trật tự

Lẽ ra PM nên làm gì (và điều đáng học)

Đặt chỉ số giả thuyết giá trị từ đầu

Bước 2: Khung quyết định chuyển hướng

Bước 3: Kiểm kê tài sản dự án khi đóng

PM Takeaway (Bài học rút ra)

Nguồn tham khảo

Trắc nghiệm tình huống PMP

Nếu là Butterfield cuối 2012, bạn làm gì với số tiền còn lại?

Tình huống này hữu ích với bạn?

Bình luận (0)