Kỹ sư và kiến thức quản lý

Tin chứ !
Nó sẽ giúp người kỹ sư phát triển các "soft skills" hơn . Thuyền đang tính viết về các soft skills (khong biet dịch ra tieng Viet là gì) trong cái thread "những skills của mot nguoi kỹ sư giỏi" đó .
Nói nôm na là những skills giao tế đối tác giữa người và người .

Anh Thuyền đừng có tranh thủ lảng kiếm cớ hổng chịu viết bài trong này há. Nhím xoá vì thực sự chỉ là một cái help về dùng tool MS Proj và MS Proj S (Micrsoft Project và Micrsoft Project Server để quản lý dự án) nên cái đó không cần thiết, tự nhiên hôm đó nổi hứng viết luôn 1 hơi thôi mà.
Nếu các anh chị hổng chịu thì để Nhím em post lên lại (hiih, may mà có copy để lại để sau này làm support cho các team leader trong project teams) và nếu có hứng thú thì trao đổi tiếp há
Nhân dịp có người bạn làm PM, NC lại tiếp tục góp ý một phần nhỏ các kỹ thuật trong việc lập plan PM ở VN. Ở Mỹ thì ko biết há, nhờ anh Thuyền nói thêm vậy.
Lập plan là việc rất quan trọng ở giai đọan đầu dự án. Không ai biết trước chi tiết đầy đủ cụ thể hết các công việc phát sinh cho dự án nhưng lúc nào thì cũng phải có plan. Một plan với các task không cần quá detail. Nên có 2 plan cho các dự án lớn và sử dụng theo phương pháp ?odivide and conquer? với loại dự án có nhiều Module có thể độc lập nhau và complex. Master plan chỉ cần có các SuperTasks, với Duration và work time. Detail plan cho từng SuperTask nên có các mục Goals (requirement), SubTask name, Start, Finish, Work, Actural work, Remain Work, resource. Các mục khác như priority, ? là tùy PM có cần thêm vào hay hide đi. Khi lập plan cũng nên để ý đến việc staff không tham gia fulltime vào dự án hay tham gia nhiều hơn mà tính toán duration và work time cho thích hợp. Để plan của mình được tốt, cũng nên cần có phương pháp estimate tốt. Wideband Delphi là một phương pháp phổ biến và tốt được đưa ra trong việc estimate này. Microsoft Project là một tool dùng rất hữu ích cho việc này vì nó có tích hợp nhiều khả năng cho quản lý như timesheet để quản lý công việc của mỗi staff hàng ngày; save baseline cho việc đưa plan ban đầu vào backup. Sau khi save baseline ta cứ việc theo dõi thực hiện update thời gian thực lên plan. Sau đó ta chỉ cần show BaselineWork hay Variance Work là nhìn thấy được là ước lượng của mình đúng hay sai, dự án đi sớm hay trễ so với plan và sớm/ trễ bao nhiêu percent. Còn nhiều cái nữa nhưng để khi nào có hứng thì nói tiếp vậy

Lại không biết post ở đâu, Nhím xin post tiếp ở đây, là một vấn đề, kinh nghiệm cho người người làm dự án, nhất làm làm quản lý dự án ở Việt Nam (ở Mỹ thì hổng dám nói há, để Mod Thuyền nói). Với vai trò là QA như Nhím cũng rất quan tâm vì quality với là quan trọng mà. Đang đọc các bài thảo luận về vấn đề này trên www.vietrose.org và thấy hay hay nên máu lên thảo luận mặc dù Nhím cũng đang có nguy cơ bị ?ocháy? deadline hihi
Nhím đang muốn nói tới vấn đề Trễ hạn trong dự án
Đây là một vấn đề mà thường hay gặp phải trong các dự án ở VN. Nhím chỉ đưa ra cái chung chung trong phần mềm, có thể các loại khác cũng có những cái khác, các anh chị em góp ý nhé!
Tác hại của nó thế nào thì khỏi phải nói, bất kỳ từng gặp phải cũng sẽ thấy
Các nguyên nhân chính:
+ Chủ quan:
- Quản lý rủi ro không tốt, sơ sài, thiếu thực tế (như khi copy lại của người khác, ko cho nó quan trọng nên đưa ra không có thực tế, chỉ lý thuyết)
- Ước lượng (estimate) năng lực tổ chức, nhân sự không tốt nên nhân lực không đáp ứng yêu cầu. Ước lượng các task, phân chia Milestone Module, tasks thời gian ko tốt
- Làm việc theo nhóm không tốt, các thành viên chưa thấy được tầm quan trọng của dự án với tổ chức, báo cáo không trung thực
- Dự án bị chia sẻ nhân sự, bị điều động làm các công việc đột xuất mất một khỏang thời gian (cái này do lãnh đạo nhưng cũng thường xuyên xảy ra) hay nghỉ việc đột xuất mà sợ trách nhiệm nên ko báo trước với lãnh đạo, tổ chức.
- Che giấu khuyết điểm, tinh thần thực tế của dự án với lãnh đạo hay báo cáo tình hình dự án không chính xác (cái này chắc không tay PM nào dám điên điên làm thế nhưng lúc trước cty Nhím đi làm đầu tiên gặp trường hợp này, gặp khó khăn ko đem ra thảo luận, hic, thế là tiêu luôn)
- QA không làm công việc sát sao, độc lập và chưa cứng rắn
- Sản phẩm khi làm chỉ có thực tế giả định (dữ liệu giả định, ?) không thể hiện được thực tế , ? nói chung chỗ QC/ KCS làm việc ko tốt, test ko tốt
- PM yếu kém, theo dõi, update dự án ko tốt, thiếu các soft skill khác như quản lý người, làm việc với khách hàng,?
- Không thu thập hết các yêu cầu của khách hàng hoặc hiểu không đúng yêu cầu
- Các thành viên chưa đánh giá đúng việc áp dụng theo quy trình, cố làm đối phó, hậu quả là ko giúp ích được mà chỉ mất thêm công, thời gian f Tư tưởng bảo thủ cứ làm theo cách cũ của mình. Hơn nữa không biết áp dụng nghiên cứu các tool sinh tự động, hay tham khảo nguồn tri thức kết quả nghiên cứu của các team khác nhằm áp dụng tốt hơn (việc này là 1 nhóm khi N làm QA gặp phải, thấy cái gì cũng ngồi làm bằng tay mà thấy thương nhưng vẫn phải bức nó có hướng đi tốt hơn, kết quả là nó lại làm thêm giờ, ? vất vả để ko bị trễ dự án trong khi dự án cũng ko có gì phức tạp lắm và vẫn làm bằng tay thiếu hẳn tính sáng tạo, cuối cùng đành support cho nó là nhóm kia làm thế, làm thế, dùng các tool đó, ?.)
+ Khách quan:
- Khách hàng thay đổi yêu cầu liên tục
- Khách hàng ban đầu chưa hiểu hết được rõ yêu cầu của mình, chấp nhận một cách chung chung, sau khi có release Version mới phát sinh yêu cầu hay thay đổi về nghiệp vụ (bussiness)
- Các thủ tục với khách hàng bị gặp nhiều trở trại trong vấn đề luật lệ, thủ tục có liên quan đến chính phủ thường là các dự án với nhà nước (ví dụ như các dự án với 112 của cty N đang làm, các bác ấy chẳng chịu ký vào yêu cầu gì cả, cứ bảo làm rồi anh em đi lấy requirement đâu đó rồi xúm vào làm, làm xong rồi các bác ấy mới bảo ký, lúc ấy lại thay đổi hoàn toàn yêu cầu. Các bác ấy lại đòi một đống papers theo cái quy trình quái quỷ gì đấy của các bác, rồi trong hợp đồng (constract) thì chỉ có vài cái phụ lục mà tính ra so với cái sản phẩm thực tế mình giao chẳng là cái đinh gì cả. Ví dụ 2 là với các dự án tư nhân, nước ngoài thì các hợp đồng ký kết phải đi qua một đống thủ tục, luật lệ về đầu tư chưa kể là ?oăn chia? cho các bác, ?)
- Máy móc, sản phẩm gặp sự cố ko có backup và ko thể làm việc được, mất nhiều thời gian phục hồi, mất thông tin, không an toàn (điều này thực ra cũng là một rủi ro mà lẽ ra phải lường và phòng ngừa trước)
Biểu hiện:
- Đã trễ một số milestone ban đầu
- Bắt đầu phải làm thêm giờ (mà ko còn là member tự giác nữa, bị buộc phải làm thêm giờ)
- Yêu cầu thay đổi từ phía khách hàng và bugs từ nhóm test (QC) nhiều không kiểm sóat được
- Một số thành viên (key memmbers) chán nản bỏ nhóm đi
- Có quá nhiều NC overdate, và ko giải quyết cũng như các problem ko kiểm sóat được
Cách khắc phục:
- Thương lượng, thuyết phục với khách hàng dời deadline. Sau đó cân nhắc đưa ra một deadline chính xác cho khách hàng nhưng làm sao vẫn cố giữ đảm bảo uy tín
- Thay đổi, thống nhất lại tinh thần, tiêu chí, cách làm việc trong nhóm dự án, sửa sai tuy nhiên vẫn khuyến khích giữ tinh thần nhóm bằng các tưởng thưởng tương đương
- Giải quyết các thành viên có vấn đề trong dự án (tinh thần làm việc nhóm, kỹ năng, trung thực)
- Đánh giá lại toàn bộ dự án. Kiểm tra lại có vấn đề gì sai sót trong dự án ko? Cso thể ktra trong từng task
- Ghi lại các thay đổi. Kiểm sóat theo dõi dự án một cách chặt chẽ hơn
Phòng ngừa:
- Ngay từ đầu dự án, làm công tác tư tưởng và quán triệt cho anh em thấy ý nghĩa, tầm quan trọng, tinh thần, tiêu chí của dự án. Tạo điều kiện để họ thoải mái tự do sáng tạo miễn sao hoàn thành tốt công việc, và không đi ra ngoài quy trình chung
- Ghi lại các thay đổi yêu cầu, và quản lý chúng ? để có thể tracking. Mỗi yêu cầu thay đổi đều phải được confirm kỹ càng tránh việc khách hàng ?oăn có nói không?
- Thay đổi các thành viên có vấn đề trong dự án ngay khi phát hiện ra trong các báo cáo hay cuộc họp định kỳ hay những lần review
- Quản lý rủi ro tốt, có kế hoạch giải quyết vấn đề để kịp thời control
- Chú ý document và PM theo sát dự án để tránh trường hợp bất ngờ có thành viên ko tham gia được
- Nắm kỹ nội lực nhóm, ước lượng công việc tốt, nên dùng nhóm expert cùng brainstorming để đưa ra 1 kết quả hội tụ.
- Các yêu cầu cố gắng đầy đủ nhất ở mức có thể, thiết kế linh họat để dễ thay đổi
- Peer review thường xuyên để verification rằng mình làm đúng, bảo đảm (2 người cũng tốt hơn 1 người, gần gần giống cái kiểu ?opair programming? ấy)
- Nên làm việc theo quy trình, quy trình đó có thể do tổ chức mình đặt ra riêng cho phù hợp và có thể propose để improve nó liên tục giúp cho mình làm tốt hơn và hiệu quả hơn.
- Và sau khi làm tất cả các việc trên thì còn theo dõi phát hiện kịp thời các biểu hiện trên
- Theo dõi, review, báo cáo định kỳ dự án. Qua đó support, training thường xuyên những vấn đề chưa thấu hiểu, các kỹ thuật còn thiếu
- Dữ liệu, sản phẩm lưu tập trung và được bảo đảm an toàn, có thể phục hồi được khi có sự cố
(Trên đó 2/3 là là copyright từ vietrose rồi, N chỉ góp thêm chút ý thui [])
Được small_porcupine sửa chữa / chuyển vào 18:50 ngày 19/10/2005

Đây lại là một vấn đề khác trong quản lý. "You can?Tt manage what you can?Tt measure" . Đó là câu đầu tiên trong phần nói về Function Point Counting. Nó chỉ là một ý tưởng để bàn về vấn đề đo lường (measure) năng lực của dự án (productivity) và các hệ số thích hợp cho từng loại dự án khi đánh giá chung các loại dự án với nhau. Nhím đang làm trong lĩnh vực software nên cố gắng nói rộng ra chung chung, mọi người cùng thảo luận nhé!
Theo các anh chị em thì có cách nào để đánh giá năng lực của project và đo được nó không? Mình sẽ bàn ở từng lĩnh vực nếu nó riêng ra.
Được small_porcupine sửa chữa / chuyển vào 07:31 ngày 17/11/2005

Đề tài này hay nhưng chưa làm quản lý nên chưa nói hết lợi ích của nó được........
Nhưng mà theo thực tế đi làm thì nếu người lãnh đạo mà kiến thức quản lý kém thì nhân viên mệt lắm ............. rất khó mà làm việc .............Mong rằng các anh chị nào mà đã hoặc sắp làm quản lý thì cố gắng nâng cao khả năng này một chút.........
Được cujnon sửa chữa / chuyển vào 08:58 ngày 17/11/2005

Đây có phải là Risk Management ? Em có thể nói thêm về phần này được không, hoặc có cái link nào hay hay cho chị vào đọc thêm? Thanks!

Là Risk Management đó chị. Chị có thể search nó trong vietrose.org . Nhưng hôm qua em tìm cũng thấy ít thông tin lắm. Các bước làm thế nào thì rõ rồi, template cũng có rồi nhưng làm cụ thể thì em vẫn chưa biết cuốn nào riêng về risk.
Để em PM cho chị user/pass vào mấy chỗ đó.
Anh Thuyền có sách hay có kinh nghiệm nào về RM thì share cho bọn em luôn với

Tham gia cho vui!
Tuân thủ quy trình "Công nghệ Phần Mềm" không được chế, tham khảo các thư viện và kinh nghiệm sản xuất phần mềm trong nước và trên thế giới. (Như tôi đã làm "Trắc địa Vệ tinh" hay "WebGIS", có tham khảo VisAD, IDV, Dolsoft ...)
THÂN!

Các bạn nào quan tâm đến Risk Management thì có thể đọc quyển này nhé:
"Fundamentals of Risk Analysis and Risk Management "
Author: Vlasta Molak Vlaska Molak
CRC Press.
Down trong link sau:
http://www.megaupload.com/?d=GESZSLC4
WJT.

Được WJT sửa chữa / chuyển vào 05:02 ngày 28/11/2005