Khi các tổ chức phẳng trở nên phổ biến hơn, các phương pháp và quy trình đi kèm với chúng cũng vậy. Blog này không thảo luận về cấu trúc tổ chức phẳng nói chung mà là cách một tổ chức phẳng hoạt động trong lĩnh vực quản lý dự án. Các nguyên tắc quản lý dự án học được từ một tổ chức phẳng có thể được áp dụng trong các công ty phẳng nhất đến các tổ chức có cấu trúc phân cấp cao nhất.
Bạn có thể đang đặt câu hỏi, “tại sao tôi lại quan tâm đến quản lý dự án phẳng?” Đối với người quản lý dự án, câu trả lời rất đơn giản: ít phân công, ít phải hỏi về tình trạng, và ít giám sát. Điều này dịch thành nhiều thời gian hơn cho bạn để tập trung vào những điều bạn yêu thích… trừ khi bạn thực sự thích làm người quản lý nhiệm vụ (và nếu đó là trường hợp của bạn thì bạn nên dừng đọc ở đây). Đối với người được quản lý, điều này cũng khá rõ ràng: tại sao bạn cần có một người cai trị liên tục săn đón bạn về tình trạng và “tư vấn” bạn cách làm công việc của mình đúng cách? Một lần nữa, nếu bạn thực sự thích điều đó thì có lẽ đây không phải là phong cách phù hợp với bạn. Ý tưởng ở đây là các quản lý cần ít quản lý hơn và mọi người khác có quyền tự chủ và tự do hoàn thành công việc của họ theo cách họ muốn mà không bị làm phiền.
Trước khi bắt đầu với quy trình, có ba yếu tố quan trọng cần thiết để thực sự làm cho điều này thành công: Tin tưởng, Minh bạch và Giao tiếp.
Ở ĐÂY
Hình 1. Tin tưởng, Minh bạch, Giao tiếp
Tin tưởng: Việc tin tưởng lẫn nhau là chìa khóa cho một cấu trúc dự án phẳng thành công
Minh bạch: Mọi người cần phải hoàn toàn mở cửa về những gì họ đang làm. Điều này có thể được thực hiện bằng cách truyền đạt công việc của họ thông qua một số phương tiện sau:
Giao tiếp: Mọi người cần có khả năng giao tiếp với nhau và nên được khuyến khích làm như vậy.
Khi có sự tin tưởng, sẽ có sự minh bạch. Khi có sự minh bạch, mọi người bắt đầu cảm thấy an toàn. Khi mọi người cảm thấy an toàn và được khuyến khích mở cửa về công việc của mình, giao tiếp chỉ diễn ra một cách tự nhiên.
Giờ đây, sau khi chúng ta đã đề cập đến các yêu cầu tiên quyết, chúng ta có thể thảo luận về việc triển khai quản lý dự án phẳng.
Trưởng nhóm dự án: "Nhưng tôi nghĩ rằng không ai là sếp trong một cấu trúc phẳng chứ?" Mặc dù không ai thực sự cần tham gia vào "quản lý và kiểm soát" nhưng việc có một người hỗ trợ là quan trọng. Hãy nghĩ về trưởng nhóm dự án như một nhạc trưởng đảm bảo rằng mọi người đều đang chơi đúng và cùng một nhịp.
Mục tiêu và Mục đích Rõ ràng: Mục tiêu dự án phải được truyền đạt một cách rõ ràng ngay từ đầu dự án. Các câu hỏi như, “Mục tiêu của chúng ta là gì? Chúng ta đang cố gắng đạt được điều gì? Ai lại muốn cái widget này chứ?” cần được định rõ và một không gian Wiki là nơi hoàn hảo để làm điều đó.
Yêu cầu và trách nhiệm: Dù là người dẫn dắt dự án hay bộ phận tiếp thị, yêu cầu cần được ghi chép lại, nếu không sẽ dễ dẫn đến hỗn loạn trong một phong cách quản lý dự án phẳng. Không có một hướng dẫn rõ ràng, "sếp" có thể dễ dàng xuất hiện và thu thập các mảnh vỡ trong một môi trường bình thường. Trong một môi trường phẳng, mọi người có thể dễ dàng lạc lối nếu không có yêu cầu được định rõ. Trong một hệ thống theo dõi vấn đề, như Jira, những yêu cầu này có thể được ghi lại dưới dạng Nhiệm vụ hoặc Câu chuyện. Thực hành tiêu chuẩn sẽ là người dẫn dắt dự án giao nhiệm vụ cho các cá nhân. Trong một môi trường làm việc phẳng hơn, một danh sách các nhiệm vụ chưa được giao sẽ được trình bày cho nhóm, nơi họ có thể tự giao những nhiệm vụ này cho bản thân (hoặc cho người khác). Hệ thống này (tức là nơi tất cả các nhiệm vụ được trình bày) có thể đơn giản như một bảng tính Excel được chia sẻ hoặc phong cách như một bảng Kanban. Một khi điều này được thiết lập, mọi người có thể xem và theo dõi trạng thái của toàn bộ dự án mà không cần phải là sếp.
Kho thiết kế tập trung: Một kho thiết kế tập trung là chìa khóa để tạo và duy trì phong cách quản lý dự án này. Không có việc tổng hợp hoặc cập nhật liên tục tình trạng thiết kế của từng thành viên trong nhóm cho một “sếp”. Nếu mọi người không thể xem công việc của nhau thì không có sự kiểm tra và cân bằng. Mỗi thành viên trong nhóm là một bộ kiểm tra cho người khác. Trong thế giới Phần mềm, điều này được thực hiện một cách chính thức bằng cách tạo một Yêu cầu Rút và có đồng nghiệp kiểm tra công việc của bạn thông qua việc xem xét mã (thay vì sếp đóng vai trò là cánh cổng). Trong việc tạo sơ đồ hoặc bố trí, điều này cũng có thể được thực hiện thông qua một quy trình tương tự. Blog này thảo luận về việc cam kết thiết kế của bạn vào một kho lưu trữ Git (tức là “SVN” hoặc “CVS” mới). Trong trường hợp này, người ta sẽ tuân theo thực hành Kỹ sư Phần mềm tương tự của việc cam kết vào một nhánh phát triển và sau đó phát hành một Yêu cầu Rút. Để biết thêm thông tin về chủ đề này, bạn có thể tham khảo hướng dẫn Git của Atlassian về việc tạo yêu cầu rút.
Trong ví dụ này, bạn có thể thấy chúng tôi đã thiết lập một dự án nhỏ bao gồm các yêu cầu khác nhau tạo nên một widget hệ thống nhúng. Dự án, trong trường hợp này, là một Epic chứa các yêu cầu để xây dựng một bảng mạch “Blinky LED”.
Hình 2. Một Epic chứa các yêu cầu thiết kế để xây dựng một “Bảng mạch LED Blinky Cầu kỳ”
Trong không gian dự án này, chúng tôi có các “thành phần” cơ khí, điện và phần mềm, trong đó mỗi thành phần đều được gán cho một trưởng nhóm thành phần.
Hình 3. Một cái nhìn về tất cả các thành phần và trưởng nhóm thành phần cho dự án
Hình 4. Một ví dụ về một nhiệm vụ chứa nhiều thành phần
Phần điện đang sử dụng Altium và đẩy mã của mình lên máy chủ Git (Bitbucket trong trường hợp này).
Hình 5. Các commit Git của thiết kế sơ đồ
Kỹ sư phần mềm và cơ khí cũng làm như vậy. Trong dự án cụ thể này chỉ có ba thành viên trong nhóm nhưng có thể chứa vô số thành viên, miễn là có một trưởng nhóm thành phần (tức là ai đó chịu trách nhiệm cho phần đó của dự án).
Không gian wiki này cho phép một cuộc trò chuyện diễn ra giữa tất cả người dùng tham gia vào các giai đoạn ý tưởng sản phẩm, triển khai, hoặc xác minh.
Hình 6. Một trang wiki chứa thông tin về sản phẩm (bao gồm các nhiệm vụ)
Dù là một bảng tính, danh sách nhiệm vụ, trang wiki, hay một chuỗi email, việc quan trọng là người điều phối dự án và các thành viên khác trong nhóm cần có khả năng xem tất cả những gì đang diễn ra trong dự án. Điều này cho phép mọi người được giữ trách nhiệm với nhau chứ không phải chỉ bởi một người quản lý duy nhất. Trong công ty chúng tôi, chúng tôi thấy bảng Kanban là cách tốt nhất để hình dung tất cả các hoạt động của dự án.
Hình 7. Một bảng Kanban chứa các nhiệm vụ của dự án ví dụ
Cuối cùng, nếu một thành viên trong nhóm phát hiện ra một lỗ hổng, họ nên cảm thấy được trao quyền để tạo nhiệm vụ và giao nó cho các đồng đội khác mà không chần chừ. Có thể họ phát hiện ra một lỗi hoặc họ chỉ cần thêm một phần cứng để hỗ trợ việc triển khai phần mềm của mình - dù là gì, họ cần cảm thấy thoải mái khi chủ động yêu cầu này theo cách ngang hàng chứ không phải từ trên xuống.
Việc quản lý micromanagement đã trở nên lỗi thời. Quản lý dự án theo phong cách bằng phẳng thay vì từ trên xuống không chỉ trở nên phổ biến mà còn giảm áp lực cho mọi người. Người quản lý dự án ít phải theo đuổi việc cập nhật tình hình và các nhà thiết kế cũng mất ít thời gian hơn để tạo ra những báo cáo tình hình đó. Bài viết này đã trình bày các nguyên tắc đằng sau phong cách tiếp cận quản lý dự án theo kiểu bằng phẳng và cách triển khai như thế nào. Không cần phải làm phẳng toàn bộ cấu trúc công ty để áp dụng phong cách tiếp cận quản lý dự án theo kiểu bằng phẳng - họ chỉ cần áp dụng các nguyên tắc đã đề cập ở trên và lao vào thực hiện.
Bạn có muốn tìm hiểu thêm về cách Altium có thể giúp bạn với thiết kế PCB tiếp theo của mình không? Hãy nói chuyện với một chuyên gia tại Altium hoặc tiếp tục đọc về cách thư viện thành phần toàn diện của Altium Designer kết nối trực tiếp với các công cụ thiết kế và mô phỏng của bạn, để dễ dàng thiết kế các hệ thống nhúng với chức năng bạn cần.
ĐượcƯu Đãi Đặc Biệt Khi Bạn Thêm Một Ghế Altium Designer® Mới