Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.109 người đã truy cậpPhiên bản 1.15.0
  1. /Tình huống
  2. /Quản lý Chất lượng
  3. /Facebook (2012): đặt cược HTML5 cho ứng dụng di …
Số 422Quản lý Chất lượng

Facebook (2012): đặt cược HTML5 cho ứng dụng di động, chất lượng trải nghiệm kém và quyết định xây lại ứng dụng gốc

Facebook từng xây ứng dụng di động chủ yếu bằng HTML5 để dùng chung mã trên mọi nền tảng, nhưng ứng dụng chậm và bị chê. Năm 2012, công ty xây lại ứng dụng iOS bằng mã gốc. Tại TechCrunch Disrupt ngày 11/9/2012, Mark Zuckerberg gọi việc đặt cược quá nhiều vào HTML5 là sai lầm lớn nhất của công ty; sau bản ứng dụng mới, người dùng xem số tin trên bảng tin nhiều gấp đôi. Bài học về để yêu cầu chất lượng quyết định lựa chọn công nghệ.

HP
Nguyễn Thu Hà, PMP
27/09/2026
2 phút đọc 0 lượt xem
Bình luận0

Bối cảnh thực tế

Khi người dùng chuyển nhanh sang điện thoại, Facebook chọn xây ứng dụng di động phần lớn dựa trên công nghệ web HTML5 bọc trong ứng dụng, với kỳ vọng viết một lần, chạy mọi nơi và cập nhật nhanh mà không cần chờ duyệt trên cửa hàng ứng dụng.

  • Ứng dụng di động bị phàn nàn rộng rãi về tốc độ và độ mượt.
  • Tháng 8/2012, Facebook phát hành ứng dụng iOS được xây lại bằng mã gốc.
  • Tại TechCrunch Disrupt ngày 11/9/2012, Mark Zuckerberg nói sai lầm lớn nhất của công ty là đặt cược quá nhiều vào HTML5 thay vì ứng dụng gốc — lần đầu ông thừa nhận công khai điều này.
  • Theo ông, kể từ bản ứng dụng iOS mới, người dùng xem số tin trên bảng tin nhiều gấp đôi.

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

  • Lựa chọn công nghệ tối ưu cho đội phát triển, không cho người dùng

    Dùng chung mã và phát hành nhanh là lợi ích cho đội. Yêu cầu chất lượng của người dùng (tốc độ, độ mượt) lẽ ra phải là tiêu chí chính khi chọn công nghệ.

  • Yêu cầu phi chức năng không được định lượng

    Nếu không có mục tiêu đo được (thời gian tải bảng tin, tốc độ cuộn), khó chứng minh công nghệ đã chọn không đạt cho tới khi người dùng phàn nàn.

  • Chi phí chất lượng thể hiện bằng mức sử dụng

    Việc lượt xem tin tăng gấp đôi sau khi đổi sang ứng dụng gốc cho thấy chất lượng kém đã làm mất giá trị kinh doanh lớn — chi phí thất bại không nằm trong ngân sách dự án nhưng có thật.

  • Điểm đáng học: dám đảo ngược quyết định

    Lãnh đạo thừa nhận sai lầm và đầu tư xây lại, thay vì tiếp tục cải thiện từng chút trên nền tảng không đáp ứng yêu cầu.

Lẽ ra PM nên làm gì

  1. 1

    Bước 1: Đặt ngân sách hiệu năng trước khi chọn công nghệ

    Ví dụ: bảng tin hiển thị trong ngưỡng thời gian nhất định trên thiết bị tầm trung; cuộn đạt số khung hình mục tiêu.

  2. 2

    Bước 2: So sánh phương án bằng nguyên mẫu và đo đạc

    Làm hai nguyên mẫu (web và gốc) cho màn hình quan trọng nhất, đo trên thiết bị thật, quyết định theo dữ liệu:

    • Chọn được

      Phương án đạt ngân sách hiệu năng với chi phí phát triển chấp nhận được.

    • Lai

      Web đạt cho màn hình phụ, không đạt cho màn hình chính: dùng mã gốc cho phần cốt lõi.

    • Loại

      Không đạt ở màn hình cốt lõi dù đã tối ưu: không dùng.

  3. 3

    Bước 3: Theo dõi chỉ số chất lượng gắn với giá trị

    Gắn hiệu năng với hành vi người dùng (thời gian dùng, lượt xem) để thấy sớm tác động kinh doanh.

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

Công nghệ là phương tiện, chất lượng người dùng cảm nhận mới là đích. Hãy định lượng yêu cầu phi chức năng trước khi chọn nền tảng, và dám đổi hướng khi dữ liệu cho thấy lựa chọn cũ không đạt.

Nguồn tham khảo

  • TechCrunch — Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5
#Quản lý chất lượng#Phát triển phần mềm#Ứng dụng di động#Lựa chọn công nghệ#Trải nghiệm người dùng

Nguồn: TechCrunch — Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5 (11/9/2012) ↗ (mở trong thẻ mới)

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

Câu 1/1
Đội đề xuất xây ứng dụng di động bằng công nghệ đa nền tảng để tiết kiệm chi phí. Sản phẩm phụ thuộc vào trải nghiệm cuộn bảng tin mượt. PM nên đảm bảo điều gì trước khi chốt công nghệ?

Bạn chọn phương án nào?

Ứng dụng di động web của bạn bị chê chậm. Bạn chọn hướng nào?

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

Bình luận0

Bình luận (0)

Đăng nhập để tham gia thảo luận.

Tình huống tương tự

Số 483Quản lý Chất lượng

Vineyard Wind (2024): cánh tuabin gió ngoài khơi gãy vì lỗi sản xuất, mảnh vỡ dạt vào bãi biển và 150 cánh phải kiểm tra lại

Ngày 13/7/2024, một cánh dài 107 m của tuabin GE Vernova tại Vineyard Wind 1 (Massachusetts) bị gãy, mảnh sợi thuỷ tinh dạt vào bãi biển Nantucket. BSEE đình chỉ phát điện toàn trang trại. GE Vernova kết luận nguyên nhân là liên kết keo không đủ trong sản xuất — lỗi mà khâu đảm bảo chất lượng lẽ ra phải phát hiện — và kiểm tra lại khoảng 150 cánh cùng nhà máy. Bài học về kiểm soát chất lượng tại nguồn.

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận29/10/2026
Số 381Quản lý Chất lượng

NASDAQ và IPO Facebook (2012): giới hạn thiết kế của hệ thống khớp lệnh và quyết định mở giao dịch khi chưa hiểu nguyên nhân gốc

Trong phiên IPO của Facebook ngày 18/5/2012, hệ thống khớp lệnh mở cửa (cross) của NASDAQ gặp giới hạn thiết kế. Lãnh đạo tin rằng vài dòng mã đã sửa xong và cho giao dịch tiếp tục khi chưa hiểu nguyên nhân gốc; hơn 30.000 lệnh bị kẹt hơn hai giờ. SEC phạt NASDAQ 10 triệu USD — mức cao nhất với một sở giao dịch khi đó. Bài học về quản lý chất lượng và ra quyết định khi có sự cố.

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận22/10/2026
Số 369Quản lý Chất lượng

Cloudflare 18/11/2025: một thay đổi quyền truy vấn cơ sở dữ liệu làm tệp cấu hình phình gấp đôi và sự cố lớn nhất kể từ 2019

Một thay đổi về quyền truy cập cơ sở dữ liệu khiến truy vấn sinh tệp đặc trưng (feature file) cho Bot Management trả về dòng trùng lặp. Tệp vượt giới hạn 200 đặc trưng, làm proxy lõi bị panic và trả lỗi 5xx trên phần lớn mạng Cloudflare gần sáu giờ. Bài học về kiểm soát chất lượng cho cấu hình do chính hệ thống nội bộ sinh ra.

1 lượt thích 0 lượt đánh giá hữu ích 0 bình luận22/10/2026

Nội dung

Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
Quảng cáoBộ đề thi thử PMP (mẫu)