Đánh giá thiết kế nên giúp cải thiện sản phẩm. Nhưng quá thường xuyên, chúng lại biến thành một cuộc truy tìm. Phản hồi nằm rải rác trong email, ảnh chụp màn hình, các chuỗi chat, PDF và ghi chú cuộc họp. Ai đó phải biến mớ hỗn độn đó thành các hành động cụ thể. Và một người khác lại phải chứng minh rằng các hành động đó đã được hoàn tất.
Đó là lúc hàng giờ làm việc biến mất. Đội thiết kế có thể nghĩ rằng việc đánh giá đã xong khi cuộc họp kết thúc, nhưng công việc thực sự thường chỉ bắt đầu sau đó. Trưởng dự án thu thập nhận xét. Kỹ sư kiểm tra xem từng nhận xét còn áp dụng hay không. Người đánh giá hỏi cập nhật trạng thái. Các hành động được chép sang một công cụ theo dõi khác. Bằng chứng phê duyệt lại được lưu ở một nơi khác.
Tự động hóa đánh giá thiết kế thay đổi nhịp làm việc đó. Nó cung cấp cho các nhóm một cách có cấu trúc để nhận xét, phân công, theo dõi, phê duyệt và rút kinh nghiệm từ mỗi lần đánh giá. Trong Altium Agile Teams, việc đánh giá có thể diễn ra xoay quanh ngữ cảnh thiết kế, thay vì xoay quanh các tệp rời rạc.
Kết quả là một quy trình đánh giá gọn gàng hơn. Người đánh giá có thể tập trung vào rủi ro. Nhà thiết kế có thể tập trung vào thay đổi. Trưởng dự án có thể thấy điều gì còn mở, điều gì đang bị chặn và điều gì đã sẵn sàng để khép lại.
Phản hồi rời rạc làm lãng phí thời gian vì các nhóm phải quản lý việc đánh giá trước khi họ có thể hành động dựa trên nó.
Một buổi đánh giá PCB điển hình có thể có sự tham gia của kỹ sư điện, kỹ sư cơ khí, kỹ sư cơ khí, bộ phận mua sắm, firmware, kiểm thử, chất lượng, sản xuất và một đối tác bên ngoài. Mỗi người nhìn thấy một rủi ro khác nhau. Điều đó rất hữu ích. Vấn đề bắt đầu khi ý kiến của họ xuất hiện ở nhiều nơi khác nhau.
Một người đánh giá ghi chú trên PDF. Người khác gửi ảnh chụp màn hình qua email. Người thứ ba bình luận trong chat. Ai đó ghi lại các hành động trong biên bản họp. Một nhà cung cấp gửi nhận xét muộn trong một tệp riêng. Không có phản hồi nào là sai, nhưng quy trình trở nên chậm chạp vì trưởng dự án phải tự ghép lại toàn cảnh bằng tay.
Điểm Đau Trong Đánh Giá Thiết Kế | Cảm Giác Thực Tế | Chi Phí Ẩn |
Ảnh chụp màn hình trong email | Nhận xét thiếu ngữ cảnh thiết kế. | Người đánh giá lặp lại câu hỏi hoặc bỏ lỡ đúng vấn đề. |
Đánh dấu trên PDF | Phản hồi khó liên kết với dữ liệu thiết kế đang hoạt động. | Các nhóm mất thời gian kiểm tra xem vấn đề còn tồn tại hay không. |
Các quyết định chỉ đưa ra trong cuộc họp | Hành động phụ thuộc vào ghi chú và trí nhớ. | Người phụ trách và hạn chót trở nên không rõ ràng. |
Checklist thủ công | Các nhóm sao chép cùng một danh sách từ dự án này sang dự án khác. | Các bước bị bỏ qua khi công việc trở nên gấp gáp. |
Không có nhật ký kiểm tra | Bằng chứng phê duyệt bị phân tán. | Sau này các nhóm phải cuống cuồng giải thích điều gì đã thay đổi. |
Công cụ theo dõi hành động tách riêng | Các vấn đề nằm tách khỏi thiết kế. | Nhà thiết kế mất thời gian đối chiếu tác vụ trở lại với layout. |
Ý kiến từ người đánh giá đến muộn | Nhận xét đến sau khi nhóm đã chuyển sang bước khác. | Việc làm lại tăng lên vì ngữ cảnh đã thay đổi. |
Vấn đề đau đầu không chỉ là cuộc họp đánh giá. Mà là công việc hành chính sau cuộc họp. Đó là nơi hàng giờ làm việc biến mất.
Đánh giá rời rạc cũng tạo ra vấn đề về mức độ tin cậy. Nếu các hành động bị phân tán, mọi người sẽ không bao giờ thực sự chắc chắn rằng việc đánh giá đã được khép lại hoàn toàn hay chưa. Thiết kế có thể tiếp tục tiến lên, nhưng nhóm vẫn mang theo sự bất định. Sự bất định đó xuất hiện sau này dưới dạng kiểm tra lại, câu hỏi lặp lại và các vòng ký duyệt bổ sung.
Tự động hóa đánh giá thiết kế đưa quy trình đánh giá vào trong một luồng công việc rõ ràng. Ví dụ, trong Altium Agile Teams, đánh giá thiết kế diễn ra tại một vị trí trung tâm nơi các bên liên quan của dự án có thể tạo và quản lý các đợt đánh giá có cấu trúc cho một dự án thiết kế trong Workspace. Các đợt đánh giá có thể được phân cho người đánh giá, bao gồm tệp đính kèm và các mục checklist, đồng thời được kiểm soát thông qua quy trình hoàn tất hoặc phê duyệt.
Đánh giá thiết kế trong Altium Agile Teams
Cấu trúc đó giúp các nhóm đánh giá dữ liệu thiết kế với ít phải chuyển ngữ cảnh hơn. Thay vì coi việc đánh giá là một hoạt động tách biệt, việc đánh giá trở thành một phần của luồng dự án. Nhận xét, quyết định, trạng thái checklist và bằng chứng phê duyệt được giữ gần với thiết kế hơn.
Đối với một nhóm điện tử đang phát triển, điều này rất quan trọng. Một người đánh giá có thể nêu ra một điểm cần lưu ý. Nhóm có thể theo dõi thay đổi được yêu cầu. Người khởi tạo có thể thấy điều gì còn mở, điều gì đã được phê duyệt và điều gì cần được chú ý. Lần đánh giá tiếp theo có thể xây dựng dựa trên những gì đã học được, thay vì bắt đầu lại từ một trang giấy trắng. Một buổi đánh giá thiết kế như vậy giúp xác định các vấn đề thiết kế, cung cấp hồ sơ tuân thủ có thể truy vết và giúp đảm bảo thiết kế đáp ứng các yêu cầu và tiêu chuẩn của công ty.
Các đợt đánh giá có cấu trúc biến nhận xét thành các hạng mục công việc rõ ràng. Một buổi đánh giá hữu ích tạo ra câu trả lời chung cho ba câu hỏi:
Nếu không có cấu trúc đó, phản hồi có thể vẫn mơ hồ. Một nhận xét như “kiểm tra khoảng hở đầu nối” có thể hữu ích, nhưng vẫn để lại nhiều câu hỏi. Đầu nối nào? Khoảng hở nào? Bản sửa đổi nào? Ai sẽ xác nhận bản sửa lỗi?
Tự động hóa giúp ích bằng cách giữ phản hồi gần hơn với đối tượng thiết kế và hồ sơ đánh giá. Các đợt đánh giá thiết kế trong Altium Agile Teams cung cấp quyền truy cập vào dữ liệu dự án liên quan, tệp, nhận xét, biểu diễn trực quan và các công cụ phản hồi mà người đánh giá cần. Luồng công việc có thể bao gồm các biểu mẫu tương tác cho phép người dùng bình luận, đính kèm tệp, xem tài liệu thiết kế và tiến qua các bước của quy trình.
Đó là sự thay đổi hữu ích. Phản hồi trở nên dễ hành động hơn vì nó không chỉ là một tin nhắn mà là một phần của luồng đánh giá được kiểm soát.
Các đợt đánh giá có cấu trúc cũng giúp dễ phân biệt các vấn đề lớn với các cải tiến nhỏ. Một hạng mục chặn phát hành không nên nằm cạnh một sở thích về kiểu trình bày với cùng mức độ quan trọng. Trạng thái đánh giá rõ ràng giúp nhóm quyết định điều gì phải sửa ngay, điều gì có thể hoãn lại và điều gì cần được xem xét thêm một vòng nữa.
Đánh giá không đồng bộ cho phép chuyên gia đóng góp khi họ có thể, trong khi dự án vẫn tiếp tục tiến lên. Điều này quan trọng vì người đánh giá phù hợp không phải lúc nào cũng rảnh cùng thời điểm với phần còn lại của nhóm. Một kỹ sư cơ khí có thể đang họp với nhà cung cấp. Một kỹ sư sản xuất có thể đang ở xưởng. Một trưởng bộ phận mua sắm có thể đang xử lý rủi ro linh kiện. Một người đánh giá chất lượng có thể cần thời gian để kiểm tra xem bằng chứng phát hành đã đầy đủ hay chưa.
Nếu cách duy nhất để đóng góp là tham gia một cuộc họp dài, một số ý kiến sẽ đến muộn hoặc không đến. Nhóm có thể có tốc độ, nhưng lại mất chất lượng đánh giá. Đánh giá không đồng bộ giữ cánh cửa mở cho đầu vào tốt hơn mà không ép mọi quyết định phải diễn ra trong một khung giờ họp duy nhất.
Nó cũng thay đổi sắc thái của công việc đánh giá. Người đánh giá có thể xem xét thiết kế khi họ có đủ tập trung để đưa ra đóng góp hữu ích. Nhà thiết kế có thể phản hồi mà không cần chờ cuộc họp tiếp theo. Trưởng dự án có thể thấy mức độ tham gia và trạng thái hoàn tất mà không phải liên tục hỏi cập nhật.
Điều này không có nghĩa là các cuộc họp biến mất. Một số vấn đề vẫn cần thảo luận trực tiếp. Nhưng cuộc họp sẽ tập trung hơn vì nhóm có thể dùng nó để ra quyết định, chứ không phải để đọc to các nhận xét.
Checklist giúp các nhóm đánh giá theo các tiêu chuẩn đã biết thay vì dựa vào trí nhớ.
Checklist tùy chỉnh hữu ích cho những hạng mục phải được kiểm tra mỗi lần, chẳng hạn như hướng đầu nối, trạng thái vòng đời, linh kiện rủi ro cao, ràng buộc lắp ráp, rủi ro nhiệt, khả năng tiếp cận để kiểm thử, đầu ra phát hành và các rủi ro về khả năng sản xuất đã biết. Mục tiêu không phải là bắt kỹ sư làm theo một kịch bản, mà là ngăn các sai sót có thể tránh được đi sang giai đoạn tiếp theo.
Điều này quan trọng vì chất lượng đánh giá thường phụ thuộc vào tính nhất quán. Người đánh giá giàu kinh nghiệm có thể biết cần tìm gì, nhưng một nhóm đang phát triển không thể chỉ dựa vào kinh nghiệm và trí nhớ. Một checklist mang lại đường cơ sở chung cho cả nhóm. Nó giúp những người đánh giá mới đóng góp. Đồng thời, nó cũng giúp quy trình đánh giá dễ được cải thiện hơn sau mỗi dự án.
Những checklist tốt nhất là ngắn gọn, phù hợp và gắn với rủi ro thực tế. Nếu checklist quá dài, mọi người sẽ chỉ lướt qua. Nếu checklist quá chung chung, mọi người sẽ bỏ qua. Nếu checklist phản ánh rủi ro thực tế của sản phẩm, quy trình và phát hành, nó sẽ trở thành một biện pháp kiểm soát hữu ích.
Trong Altium Agile Teams, bạn có thể bắt đầu với một mẫu checklist rồi tùy chỉnh nó
Khoản tiết kiệm thời gian lớn nhất đến từ việc giảm công việc hành chính của khâu đánh giá, chứ không phải từ việc thúc ép công việc kỹ thuật.
Hãy dùng mô hình đơn giản này như một hướng dẫn lập kế hoạch. Con số chính xác sẽ thay đổi theo từng nhóm, kích thước bo mạch và độ sâu đánh giá, nhưng mô hình chung thường giống nhau.
Hoạt Động Đánh Giá Thủ Công | Nỗ Lực Điển Hình Cho Mỗi Lần Đánh Giá | Tác Động Của Tự Động Hóa |
Thu thập nhận xét từ email, chat và tệp | 1 đến 3 giờ | Nhận xét được giữ gần hơn với ngữ cảnh thiết kế |
Tạo và phân công danh sách hành động | 1 đến 2 giờ | Có thể tạo tác vụ từ nhận xét |
Theo dõi checklist | 1 đến 2 giờ | Trạng thái checklist hiển thị trong luồng đánh giá |
Chứng minh việc khép lại trước khi phát hành | 1 đến 3 giờ | Nhật ký kiểm tra và trạng thái đánh giá dễ truy vết hơn |
Lặp lại cùng một vấn đề trong lần đánh giá tiếp theo | Thay đổi tùy trường hợp | Các mẫu đánh giá chuẩn giúp giảm việc bỏ sót lặp lại |
Chuẩn bị cập nhật trạng thái đánh giá | 30 phút đến 1 giờ | Các hạng mục còn mở và trạng thái đánh giá dễ nhìn thấy hơn |
Kiểm tra lại xem phản hồi còn áp dụng hay không | Thay đổi tùy trường hợp | Nhận xét được giữ gần hơn với ngữ cảnh thiết kế liên quan |
Qua ba lần đánh giá chính thức, ngay cả khi chỉ tiết kiệm được hai giờ cho mỗi lần đánh giá, nhóm cũng đã lấy lại được sáu giờ. Các bo mạch lớn hơn và các nhóm phân tán có thể tiết kiệm nhiều hơn vì có ít việc phải theo đuổi, ít phải sắp xếp lại và ít cuộc họp cập nhật trạng thái hơn.
Việc tiết kiệm thời gian không chỉ nằm ở khía cạnh hành chính mà còn giúp bảo vệ sự tập trung cho kỹ thuật. Mỗi giờ dành để lần theo các bình luận là một giờ không được dùng để cải thiện thiết kế. Mỗi câu hỏi lặp lại đều làm gián đoạn sự tập trung. Mỗi hành động không rõ ràng đều gây ra chậm trễ.
Tự động hóa giúp các nhóm dành nhiều thời gian hơn cho việc đánh giá dựa trên nhận định chuyên môn và ít thời gian hơn cho việc điều phối.
Đánh giá nhanh hơn cải thiện tốc độ lặp vì các nhóm thiết kế có thể hành động theo phản hồi sớm hơn. Nếu bình luận đến muộn hoặc rời rạc, người thiết kế phải dừng lại, dựng lại bối cảnh và quyết định điều gì còn quan trọng. Nếu phản hồi được cấu trúc, phân công và hiển thị rõ ràng, vòng cập nhật layout tiếp theo sẽ bắt đầu sớm hơn. Nhóm cũng có thể thấy liệu việc đánh giá đang bị chặn bởi một vấn đề nghiêm trọng hay nhiều hạng mục nhỏ.
Đây là điểm mà tự động hóa đánh giá thiết kế hỗ trợ tính linh hoạt thực sự. Nó không loại bỏ kỷ luật trong đánh giá mà loại bỏ lực cản xoay quanh kỷ luật đó.
Một vòng đánh giá nhanh hơn cũng cải thiện tinh thần làm việc. Người thiết kế không phải bảo vệ những quyết định đã được thống nhất. Người đánh giá không phải lặp lại những bình luận đã được đưa ra. Trưởng dự án không phải theo đuổi trạng thái qua năm kênh khác nhau. Quy trình trở nên nhẹ nhàng hơn vì công việc được hiển thị rõ ràng.
Khả năng hiển thị đó đặc biệt quan trọng khi dự án đang chịu áp lực. Ở giai đoạn cuối dự án, các nhóm thường phải đồng thời xử lý thay đổi thiết kế, ràng buộc nguồn cung, phản hồi từ sản xuất và thời hạn phát hành. Một quy trình đánh giá có cấu trúc giúp nhóm thấy rõ điều gì quan trọng ở thời điểm hiện tại và điều gì có thể chờ.
Đánh giá thiết kế tồn tại để phát hiện rủi ro, không phải để tạo ra rủi ro. Khi quy trình xoay quanh việc đánh giá bị phân mảnh, bản thân hoạt động đánh giá sẽ trở thành nguồn gây chậm trễ, công việc lặp lại và sự thiếu chắc chắn. Đó chính là vấn đề mà tự động hóa giải quyết; không phải bằng cách thay thế nhận định kỹ thuật, mà bằng cách loại bỏ phần chi phí điều phối bao quanh nó.
Những nhóm di chuyển nhanh nhất qua các chu kỳ lặp không phải là những nhóm bỏ qua kỷ luật đánh giá. Họ là những nhóm đã biến kỷ luật đánh giá thành thứ dễ thực hiện. Bình luận luôn bám sát thiết kế. Hành động đều có người phụ trách. Checklist phản ánh rủi ro thực tế. Việc hoàn tất được hiển thị rõ ràng mà không ai phải hỏi.
Đó là hình ảnh thực tế của một quy trình đánh giá có cấu trúc, và bất kỳ nhóm nào sẵn sàng thay đổi cách phản hồi được luân chuyển đều có thể đạt được.
Sẵn sàng triển khai các đợt đánh giá thiết kế gọn gàng và nhanh hơn?
Altium Agile Teams mang đến cho nhóm của bạn một môi trường được xây dựng chuyên biệt cho các đợt đánh giá thiết kế có cấu trúc, với bình luận tập trung, mẫu checklist, theo dõi hành động và quy trình phê duyệt được tích hợp trực tiếp vào bối cảnh dự án thiết kế của bạn. Khám phá Altium Agile Teams →
Tự động hóa đánh giá thiết kế sử dụng các quy trình làm việc có cấu trúc để quản lý bình luận, hạng mục hành động, checklist và phê duyệt trong một môi trường dự án dùng chung. Thay vì thu thập phản hồi thủ công từ email, PDF và các luồng trò chuyện, các nhóm làm việc từ một bản ghi đánh giá trung tâm được gắn trực tiếp với thiết kế. Kết quả là giảm chi phí điều phối và có được dấu vết kiểm toán rõ ràng từ lúc bình luận được nêu ra đến khi xác nhận hoàn tất.
Phần lớn công việc làm lại không bắt nguồn từ các quyết định kỹ thuật kém, mà từ phản hồi đến muộn, bị hiểu sai hoặc chưa bao giờ được đóng lại một cách chính thức. Các đợt đánh giá có cấu trúc giúp giảm làm lại bằng cách đảm bảo mọi bình luận đều có người phụ trách rõ ràng, mọi hành động đều có trạng thái hiển thị và mọi phê duyệt đều có thể truy vết. Khi vòng lặp thiết kế tiếp theo bắt đầu, nhóm biết chính xác điều gì đã thay đổi và vì sao, thay vì phải tranh luận lại về những quyết định đã được đưa ra.
Một buổi đánh giá thiết kế PCB đầy đủ thường có sự tham gia của kỹ sư điện, kỹ sư cơ khí, nhóm firmware, sản xuất, thu mua, kiểm thử và chất lượng. Mỗi chuyên môn nhìn thấy một nhóm rủi ro khác nhau. Thách thức nằm ở việc thu thập những ý kiến đó dưới dạng có thể sử dụng được. Các đợt đánh giá không đồng bộ, có cấu trúc giúp tất cả các bên liên quan có thể đóng góp mà không cần mọi người phải có mặt cùng một lúc.
Checklist ghi lại tri thức tổ chức dưới dạng có thể lặp lại. Nếu không có chúng, chất lượng đánh giá sẽ phụ thuộc vào kinh nghiệm của người đang có mặt trong phòng. Một checklist được duy trì tốt sẽ đảm bảo rằng các hạng mục rủi ro cao được kiểm tra trong mọi dự án, chứ không chỉ khi một người đánh giá giàu kinh nghiệm tình cờ nêu ra chúng.