thảo luận Hội anh em Project Manager - Scrum Master

Hideto Takahashi · 28/8/23

Cùng thảo luận thử xem, đâu là methodology đẹp nhất cho dự án Fixed Cost. Điều kiện
1. Fix về timeline
2. Chưa rõ ràng về scope
3. Fix về cost

:big_smile:

Anh em thảo luận thử :big_smile:

hideonhp · 28/8/23

chấm hóng, biết đâu nhảy việc :v

Thai-Tu-Shang · 28/8/23

Newbie hong biet gi đã nói:
Dạ em chào mọi người, em là sinh viên mới ra trường, em đang định hướng phát triển nghệ nhiệp theo hướng BA--> PM, hiện tại em nên apply vào vị trí BA tại các công ty nhỏ hay Project Coordination Intern cho công ty nước ngoài ạ

Theo view của mình thôi nhé, thì bạn nên xuất phát từ 1 role nhỏ trong dự án đi lên ( ví dụ Dev, QC, BA) và đi dần lên.
Hơi lạ chút là nếu đi từ ngạch BA thì thường BA hay thích rẽ hướng lên PO nhiều hơn là PM.
Còn đâu khi ở role nhỏ nhất thì bạn sẽ có thêm nhiều view, còn làm PM intern luôn thì hơi khó

Love U So Much · 28/8/23

Hideto Takahashi đã nói:
Cùng thảo luận thử xem, đâu là methodology đẹp nhất cho dự án Fixed Cost. Điều kiện
1. Fix về timeline
2. Chưa rõ ràng về scope
3. Fix về cost

Anh em thảo luận thử

Lỗ ít tới lỗ nhiều, team nghỉ sạch

Thai-Tu-Shang · 28/8/23

Hideto Takahashi đã nói:
Cùng thảo luận thử xem, đâu là methodology đẹp nhất cho dự án Fixed Cost. Điều kiện
1. Fix về timeline
2. Chưa rõ ràng về scope
3. Fix về cost

Anh em thảo luận thử

Fix time vs Fix cost và scope mở thì chạy Agile thôi. Theo mình là thế.
Scope mở thì phải xem KH họ đang hình dung muốn làm gì, sau đó build 1 cái MVP cơ bản để đánh giá và chạy MVP trước đã.
Vì chưa rõ về scope thì cứ làm và test, sau đó hiệu chỉnh dần.
Bên mình là cty Prod thì thường sẽ chơi theo kiểu này: cho team 1 ý tưởng, golive time thì team đánh giá và tự chốt ( hoặc có những lúc bắt buộc phải fixtime) sau đó thì cứ tập trung làm theo MVP và priority từ cao nhất xuống thấp nhất theo mô hình Moscow. Sau đó MVP ra thì đánh giá và làm mịn nó tiếp ở các phase sau

Hideto Takahashi · 28/8/23

Thai-Tu-Shang đã nói:
Fix time vs Fix cost và scope mở thì chạy Agile thôi. Theo mình là thế.
Scope mở thì phải xem KH họ đang hình dung muốn làm gì, sau đó build 1 cái MVP cơ bản để đánh giá và chạy MVP trước đã.
Vì chưa rõ về scope thì cứ làm và test, sau đó hiệu chỉnh dần.
Bên mình là cty Prod thì thường sẽ chơi theo kiểu này: cho team 1 ý tưởng, golive time thì team đánh giá và tự chốt ( hoặc có những lúc bắt buộc phải fixtime) sau đó thì cứ tập trung làm theo MVP và priority từ cao nhất xuống thấp nhất theo mô hình Moscow. Sau đó MVP ra thì đánh giá và làm mịn nó tiếp ở các phase sau

Chạy Agile thì đẹp theo lý thuyết và giành cho cty product. Nhưng với outsourcing ( vấn đề này gặp rất nhiều ), thì cái này khá rủi ro do ko plan đường dài đc. Anh/em có solution gì khác ko :byebye:

Thai-Tu-Shang · 28/8/23

Hideto Takahashi đã nói:
Chạy Agile thì đẹp theo lý thuyết và giành cho cty product. Nhưng với outsourcing ( vấn đề này gặp rất nhiều ), thì cái này khá rủi ro do ko plan đường dài đc. Anh/em có solution gì khác ko

Outsourcing thì nếu thuê headcount PT lâu dài => giống prod thì cũng chạy đc.
Còn nếu không thì nên chỉ dùng các practice của Agile thôi ( Áp dụng Kanban board...) Còn đâu thì vẫn nên chạy theo kiểu đo time tính tiền bác ơi.
Làm càng clear cái scope càng tốt.
Chứ giờ khách đưa cho bác có 10tr trong 1 tháng ( fix time fix cost) mà bảo làm hệ thống giống như shoppee ( gần giống thôi cũng đc -> scope mở ) thì toang chắc.
Agile nó chỉ hợp với kiểu dự án nhỏ và cần đẩy nhanh ra thị trường, test độ hiệu quả xem ok không để quyết định đầu tư hay ko đầu tư.

namcungkiem · 28/8/23

Hideto Takahashi đã nói:
Cùng thảo luận thử xem, đâu là methodology đẹp nhất cho dự án Fixed Cost. Điều kiện
1. Fix về timeline
2. Chưa rõ ràng về scope
3. Fix về cost

Anh em thảo luận thử

Trong quản lý dự án thì chắc ae quen với QCD rồi. Timeline với Cost fix thì chỉ còn nước deal về Quality thôi. Cố gắng kéo cái Acceptance Criteria về đúng ngưỡng mà team nhắm có thể làm được. Cái khó ở đây là chưa rõ ràng về Scope. Thì practive của mình là vừa làm vừa clearify thôi.
Mình vẫn hay thòng 1 câu với khách là T+XX (T là tính từ time chốt Req đó).
Cơ bản khách nhiều luc sẽ ko happy vì luôn muốn ngon-bổ-rẻ hay nhanh-rẻ-tốt.
Cơ mà cho khách aware (kiểu mình luôn remind liên tục) là khách ko chốt sớm thì cái timeline kia chắc chắn ko giữ được và Cost cũng sẽ đội lên theo (cả bên mình lẫn bên khách).

Hideto Takahashi · 28/8/23

namcungkiem đã nói:
Trong quản lý dự án thì chắc ae quen với QCD rồi. Timeline với Cost fix thì chỉ còn nước deal về Quality thôi. Cố gắng kéo cái Acceptance Criteria về đúng ngưỡng mà team nhắm có thể làm được. Cái khó ở đây là chưa rõ ràng về Scope. Thì practive của mình là vừa làm vừa clearify thôi.
Mình vẫn hay thòng 1 câu với khách là T+XX (T là tính từ time chốt Req đó).
Cơ bản khách nhiều luc sẽ ko happy vì luôn muốn ngon-bổ-rẻ hay nhanh-rẻ-tốt.
Cơ mà cho khách aware (kiểu mình luôn remind liên tục) là khách ko chốt sớm thì cái timeline kia chắc chắn ko giữ được và Cost cũng sẽ đội lên theo (cả bên mình lẫn bên khách).

Khi chưa rõ được scope thì AC cũng hơi không hiệu quả, vì scope có thể change, nhưng rất khó charge client vì scope mở. Em đang gặp tình trạng này và cực khó để plan. Plan theo sprint cũng chết, mà plan theo cả dự án cũng chết do dependency :beat_shot:

Hideto Takahashi · 28/8/23

Thai-Tu-Shang đã nói:
Outsourcing thì nếu thuê headcount PT lâu dài => giống prod thì cũng chạy đc.
Còn nếu không thì nên chỉ dùng các practice của Agile thôi ( Áp dụng Kanban board...) Còn đâu thì vẫn nên chạy theo kiểu đo time tính tiền bác ơi.
Làm càng clear cái scope càng tốt.
Chứ giờ khách đưa cho bác có 10tr trong 1 tháng ( fix time fix cost) mà bảo làm hệ thống giống như shoppee ( gần giống thôi cũng đc -> scope mở ) thì toang chắc.
Agile nó chỉ hợp với kiểu dự án nhỏ và cần đẩy nhanh ra thị trường, test độ hiệu quả xem ok không để quyết định đầu tư hay ko đầu tư.

Nếu lâu dài thì switch Agile là việc hợp lý, làm kiểu offshore.
Còn short term, vd 3 tháng, mà gặp những dự án như này rất mệt mỏi kiểu đo time tính tiền vì time đã fix

namcungkiem · 28/8/23

Hideto Takahashi đã nói:
Nếu lâu dài thì switch Agile là việc hợp lý, làm kiểu offshore.
Còn short term, vd 3 tháng, mà gặp những dự án như này rất mệt mỏi kiểu đo time tính tiền vì time đã fix

Hideto Takahashi đã nói:
Khi chưa rõ được scope thì AC cũng hơi không hiệu quả, vì scope có thể change, nhưng rất khó charge client vì scope mở. Em đang gặp tình trạng này và cực khó để plan. Plan theo sprint cũng chết, mà plan theo cả dự án cũng chết do dependency

Đây là li do nhiều cty thấy dư án quá ngắn là reject luôn chứ k làm. Vì risk cao quá. Ko kịp sửa sai. Scope ko clear thi chắc chắn là ko Estimate dc chinh xac rồi.
Sẽ co 2 cases:
1. Khách quen dư án mới thì cai này vừa lam vừa clearifu cuốn chiếu , staffing người từ từ vào
2. Khách mới - lúc này phu thuộc rất lớn vào tài ăn nói của đội Sale và PM để lái khách. Kiểu khách hướng muốn minh làm thi nc dễ, ko thì ko win-win dc thi chấp nhận bỏ project thôi chứ ăn penalty cũng khổ lắm

Hideto Takahashi · 28/8/23

namcungkiem đã nói:
Đây là li do nhiều cty thấy dư án quá ngắn là reject luôn chứ k làm. Vì risk cao quá. Ko kịp sửa sai. Scope ko clear thi chắc chắn là ko Estimate dc chinh xac rồi.
Sẽ co 2 cases:
1. Khách quen dư án mới thì cai này vừa lam vừa clearifu cuốn chiếu , staffing người từ từ vào
2. Khách mới - lúc này phu thuộc rất lớn vào tài ăn nói của đội Sale và PM để lái khách. Kiểu khách hướng muốn minh làm thi nc dễ, ko thì ko win-win dc thi chấp nhận bỏ project thôi chứ ăn penalty cũng khổ lắm

Đang dính 1 con cố đấm ăn xôi để làm :ah:

Giờ thì thay đổi liên tục nhưng không charge được :cry:

Cuộc Sống Tươi Đẹp · 28/8/23

Có bác nào thi PSM chưa ạ. Cho em hỏi độ khó giữa các level 1 2 3 có khác biệt nhau nhiều không ạ

Hideto Takahashi · 28/8/23

Cuộc Sống Tươi Đẹp đã nói:
Có bác nào thi PSM chưa ạ. Cho em hỏi độ khó giữa các level 1 2 3 có khác biệt nhau nhiều không ạ

PSM 1 rất dễ, thiên về lý thuyết, PSM 2 hơi phức tạp chút, có thêm câu hỏi về tình huống. Còn PSM 3 thì bỏ đi, vì giá đắt nhưng không đáng đâu.

Cuộc Sống Tươi Đẹp · 28/8/23

Hideto Takahashi đã nói:
PSM 1 rất dễ, thiên về lý thuyết, PSM 2 hơi phức tạp chút, có thêm câu hỏi về tình huống. Còn PSM 3 thì bỏ đi, vì giá đắt nhưng không đáng đâu.

À mới xem lại thì PSM 3 là câu hỏi dạng essay, khoai thật

Với cho e hỏi là thi PSM 2 thì có yêu cầu phải thi PSM 1 trước không ạ???

Hideto Takahashi · 28/8/23

Cuộc Sống Tươi Đẹp đã nói:
À mới xem lại thì PSM 3 là câu hỏi dạng essay, khoai thật

Với cho e hỏi là thi PSM 2 thì có yêu cầu phải thi PSM 1 trước không ạ???

Không nhé, cứ tự tin thì phang luôn PSM 2 cho nó tiết kiệm :big_smile:

Thai-Tu-Shang · 28/8/23

namcungkiem đã nói:
Đây là li do nhiều cty thấy dư án quá ngắn là reject luôn chứ k làm. Vì risk cao quá. Ko kịp sửa sai. Scope ko clear thi chắc chắn là ko Estimate dc chinh xac rồi.
Sẽ co 2 cases:
1. Khách quen dư án mới thì cai này vừa lam vừa clearifu cuốn chiếu , staffing người từ từ vào
2. Khách mới - lúc này phu thuộc rất lớn vào tài ăn nói của đội Sale và PM để lái khách. Kiểu khách hướng muốn minh làm thi nc dễ, ko thì ko win-win dc thi chấp nhận bỏ project thôi chứ ăn penalty cũng khổ lắm

Bài học xương máu của em trong việc bid 1 con dự án scope mở vs fix time fix cost đây.
Kiểu tới lúc chốt dự án ( 3 tháng - 100m) mà vẫn không clear rõ được khách hàng muốn làm gì. Và start dự án theo kiểu Agile ( vừa làm vừa BA theo khách)
Tới khi dự án kết thúc ( 6 tháng, chi phí bỏ ra khoảng x4 lần ban đầu ) vì càng làm khách nó càng vẽ ra và charge tiền thêm rất khó (khách nó bảo bọn mày estimate ban đầu như thế r, nó vẫn thuộc scope)
Đợt đó bên mình est Req cũng non. Chỉ là CRUD thôi nhưng bên trong mỗi cái đó nó có cả tỉ cái logic nhỏ lẻ mà ban đầu mình không nhìn thấy được.
Nên tốt nhất với những dự án fix time, fix cost scope mở đừng Agile vội, chết đấy.
Nên làm kiểu base 1 2 sprint đầu để clear cái nó muốn và chốt 1 khoảng scope nhất định. Sau đó thì mới tùy xem to hay bé mà phang kiểu truyền thống hoặc Agile sau.

namcungkiem · 28/8/23

Thai-Tu-Shang đã nói:
Bài học xương máu của em trong việc bid 1 con dự án scope mở vs fix time fix cost đây.
Kiểu tới lúc chốt dự án ( 3 tháng - 100m) mà vẫn không clear rõ được khách hàng muốn làm gì. Và start dự án theo kiểu Agile ( vừa làm vừa BA theo khách)
Tới khi dự án kết thúc ( 6 tháng, chi phí bỏ ra khoảng x4 lần ban đầu ) vì càng làm khách nó càng vẽ ra và charge tiền thêm rất khó (khách nó bảo bọn mày estimate ban đầu như thế r, nó vẫn thuộc scope)
Đợt đó bên mình est Req cũng non. Chỉ là CRUD thôi nhưng bên trong mỗi cái đó nó có cả tỉ cái logic nhỏ lẻ mà ban đầu mình không nhìn thấy được.
Nên tốt nhất với những dự án fix time, fix cost scope mở đừng Agile vội, chết đấy.
Nên làm kiểu base 1 2 sprint đầu để clear cái nó muốn và chốt 1 khoảng scope nhất định. Sau đó thì mới tùy xem to hay bé mà phang kiểu truyền thống hoặc Agile sau.

Thật ra dư án kiểu này nhiều lắm.
Thằng xài ko biết, thằng làm ko xài nên cứ loạn cả lên.
Chính nó còn ko biết nó muốn gì và đôi khi nó cứ kiểu cố y ko hiểu để ép mình về "thuộc scope".

Hideto Takahashi · 28/8/23

Thai-Tu-Shang đã nói:
Bài học xương máu của em trong việc bid 1 con dự án scope mở vs fix time fix cost đây.
Kiểu tới lúc chốt dự án ( 3 tháng - 100m) mà vẫn không clear rõ được khách hàng muốn làm gì. Và start dự án theo kiểu Agile ( vừa làm vừa BA theo khách)
Tới khi dự án kết thúc ( 6 tháng, chi phí bỏ ra khoảng x4 lần ban đầu ) vì càng làm khách nó càng vẽ ra và charge tiền thêm rất khó (khách nó bảo bọn mày estimate ban đầu như thế r, nó vẫn thuộc scope)
Đợt đó bên mình est Req cũng non. Chỉ là CRUD thôi nhưng bên trong mỗi cái đó nó có cả tỉ cái logic nhỏ lẻ mà ban đầu mình không nhìn thấy được.
Nên tốt nhất với những dự án fix time, fix cost scope mở đừng Agile vội, chết đấy.
Nên làm kiểu base 1 2 sprint đầu để clear cái nó muốn và chốt 1 khoảng scope nhất định. Sau đó thì mới tùy xem to hay bé mà phang kiểu truyền thống hoặc Agile sau.

Em đang chết con y hệt. Đang muốn học hỏi kinh nghiệm nếu gặp những con thế này ( ngoại trừ việc reject project ) thì có một methodology nào để follow, hạn chế risk. Dự án em còn khốn nạn hơn là client nó dell confirm cái gì, cứ nói miệng và không official. Sau này có việc cũng không lôi lại evidence để charge :too_sad:

Thai-Tu-Shang · 28/8/23

Hideto Takahashi đã nói:
Em đang chết con y hệt. Đang muốn học hỏi kinh nghiệm nếu gặp những con thế này ( ngoại trừ việc reject project ) thì có một methodology nào để follow, hạn chế risk. Dự án em còn khốn nạn hơn là client nó dell confirm cái gì, cứ nói miệng và không official. Sau này có việc cũng không lôi lại evidence để charge

Thế thì bạn chết là cái chắc luôn. Vì bản chất không confirm gì thì sau lấy gì mà cãi.
Ít ra BA cũng phải chốt được xem là khách nó muốn vẽ ra cái gì.
Chứ giờ khách bảo: tao muốn làm cái xe.
Bên dự án nghĩ: nó muốn làm xe đạp
Nhưng thằng khách nghĩ: tao muốn làm xe máy thì đã chết r, mà muốn làm ô tô càng chết hơn nữa.

thảo luận Hội anh em Project Manager - Scrum Master

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Senior Member

Senior Member

Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Senior Member

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này