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
chết như chơi
Đội sales ở nhà cứ chém bừa với client rồi chốt kí
Đội dev vào estimate chỉ để Sales kí hđ, chứ không clear gì đc cái scope. Đến khi clear scope thì contract kí xong rồi 
ko confirm officially, thì mình cũng văn bản, và remind, nếu nó ko chốt trên assumption đó thì mình chốt dựa trên assumption. Define escalation model khi kick-off để cố gắng giảm riskk nhất có thể thôi chứ mấy dạng pj kiểu này outsource ăn miếtEm đ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
Em cũng đang khó cái vụ này. Đa phần bị assign quá công số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ử
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
Bằng mọi giá phải confirm nhé.
PM em đang định hướng là Product Mgmt thì em nên đi từ BA. Còn nếu là Project Mgmt thì em start từ Prj Coordinator
Từ chối được thì đã tốt. Có khi bị sếp "ép nhận" vì "khách hàng tiềm năng" ấy chớChèn cái này vào thì cũng ổn, nhưng cuối cùng client không nghiệm thu thì mình cũng chết. Không lẽ kiện tụng thì mất thời gian. Nên em cứ suy nghĩ mãi, tốt nhất là không nên dây vào các con fixed cost nhưng không có clear requirements hoặc client không hợp tác
.
Nói lên ước mơ thôi bácTừ chối được thì đã tốt. Có khi bị sếp "ép nhận" vì "khách hàng tiềm năng" ấy chớ
Chứ thực tế thì phủ phàng
Em hiện tại đang làm dev mobile đã có vài năm kinh nghiệm làm qua một vài dự án chạy theo Agile và Waterfall , dự định sau này em muốn theo hướng PM SM. Các bác cho em xíu road map để có thể theo đuổi con đường này với
Khi Epic được break đủ nhỏ tới các User Story đủ clear về requirement.Anh em PM và SM cho em hỏi chút, làm sao để trả lời được câu hỏi: Bao giờ thì team có thể Deliver được Epic nhỉ
SM - nắm chắc kĩ thuật & kĩ năng làm việc theo Agile/Scrum là được.
Nó sẽ có hai trường hợp:
Để theo hướng PM thì mình có một số lời khuyên cho bạn dưới góc nhìn cá nhân của mình:
Sai hoàn toàn về mục đích cuối cùng.
Về ý chứng chỉ em đã rep bác bên thớt kia rồi nhé.
Em chỉ đưa 1 tình huống cụ thể nhé:
