Rất nhiều dự án phần mềm đi chệch hướng không phải vì đội làm kém, mà vì họ làm đúng những gì được yêu cầu, chỉ tiếc rằng những gì được yêu cầu lại không phải những gì thật sự cần. Gốc rễ của sự lệch pha này thường là một bản brief mơ hồ, nơi người đặt làm mô tả mong muốn của mình một cách không đủ rõ, và đội làm lấp đầy những khoảng trống bằng phỏng đoán của họ. Kết quả là một sản phẩm đúng theo chữ nhưng sai theo ý. Một bản brief tốt là một trong những khoản đầu tư có lợi nhất bạn có thể bỏ vào một dự án, vì nó định hướng mọi thứ phía sau. Bài viết này hướng dẫn cách viết một bản brief mà đối tác khó lòng hiểu sai.
Vì sao một brief tốt quyết định nửa thành công
Brief là cầu nối giữa điều trong đầu bạn và điều đội làm sẽ tạo ra, và chất lượng của cầu nối đó quyết định khoảng cách giữa mong muốn và kết quả. Một brief rõ ràng thu hẹp khoảng cách đó, để đội làm hiểu đúng và xây đúng. Một brief mơ hồ mở rộng nó, để mỗi khoảng trống trở thành một cơ hội cho sự hiểu lầm.
Đầu tư vào một brief tốt tiết kiệm rất nhiều rắc rối và chi phí về sau. Sửa một hiểu lầm khi nó còn nằm trên brief gần như không tốn gì; sửa nó khi sản phẩm đã được xây dựng tốn kém và đau đớn. Vì thế, dù viết brief đòi hỏi công sức suy nghĩ ban đầu, nó là công sức được đền đáp gấp nhiều lần qua việc tránh được những vòng làm lại và những sản phẩm lạc hướng. Một brief tốt không phải thủ tục hành chính mà là công cụ định hướng quan trọng nhất ở giai đoạn đầu của dự án.
Bắt đầu từ vấn đề, không từ giải pháp
Sai lầm phổ biến nhất khi viết brief là mô tả giải pháp bạn hình dung thay vì vấn đề bạn cần giải quyết. Khi bạn nói tôi muốn một nút bấm làm việc này ở đây, bạn đang áp đặt một giải pháp cụ thể, có thể không phải cách tốt nhất, và bạn tước đi của đội làm cơ hội đề xuất một cách hay hơn dựa trên chuyên môn của họ. Tệ hơn, nếu giải pháp bạn hình dung không thật sự giải quyết vấn đề gốc, đội làm sẽ xây đúng thứ vô dụng.
Cách tốt hơn là bắt đầu từ vấn đề: điều gì đang khó khăn, ai đang gặp khó, hậu quả là gì, và thành công trông như thế nào. Khi đội làm hiểu vấn đề thật, họ có thể đề xuất giải pháp tốt nhất dựa trên chuyên môn của mình, và họ cũng làm tốt hơn vì hiểu mục đích đằng sau mỗi yêu cầu. Hãy mô tả cái đích bạn muốn tới, rồi để những người làm nghề tư vấn con đường, thay vì vẽ sẵn một con đường có thể không dẫn tới đâu. Vấn đề là thứ ổn định và đáng tin để xây dựng quanh nó, còn giải pháp cụ thể nên là kết quả của sự hợp tác.
Mô tả người dùng và bối cảnh thật
Một brief tốt vẽ rõ ai sẽ dùng sản phẩm và trong hoàn cảnh nào, vì điều này ảnh hưởng sâu tới mọi quyết định thiết kế. Một công cụ cho nhân viên kho dùng trên đường khác hẳn một công cụ cho kế toán dùng ở bàn làm việc. Người dùng của bạn rành công nghệ hay không, họ dùng trong điều kiện nào, họ đang cố đạt được gì, tất cả là thông tin quý giúp đội làm tạo ra thứ thật sự phù hợp.
Việc mô tả người dùng và bối cảnh cụ thể cũng giúp tránh những giả định sai. Đội làm, nếu không được cho biết, sẽ tự hình dung người dùng theo cách của họ, có thể rất khác thực tế. Bằng cách cung cấp một bức tranh rõ ràng về những người thật sẽ dùng sản phẩm và hoàn cảnh thật của họ, bạn giúp đội làm đặt mình vào vị trí người dùng và đưa ra những quyết định phù hợp. Đây là một phần của brief thường bị bỏ qua nhưng có giá trị lớn, vì phần mềm cuối cùng được dùng bởi con người trong những hoàn cảnh cụ thể, không phải trong sự trừu tượng.
Phân biệt rõ phải có và nên có
Một brief tốt phân biệt rõ giữa những gì thật sự bắt buộc phải có và những gì chỉ là mong muốn tốt nếu có. Sự phân biệt này cực kỳ quan trọng vì nó định hướng việc ưu tiên khi nguồn lực có hạn, điều luôn xảy ra. Nếu mọi thứ đều được mô tả như nhau, đội làm không biết đâu là điều không thể thiếu và đâu là điều có thể hoãn, và họ có thể dồn công sức sai chỗ.
Hãy thành thật với chính mình về điều gì thật sự cần để sản phẩm hữu ích, và điều gì chỉ làm nó đẹp hơn. Một mẹo là tự hỏi với mỗi tính năng, điều gì xảy ra nếu nó không có trong phiên bản đầu. Nếu sản phẩm vẫn giải quyết được vấn đề cốt lõi, đó là thứ có thể chờ. Sự phân biệt rõ ràng này giúp dự án tập trung nguồn lực vào những thứ quan trọng nhất trước, và cho phép những điều chỉnh hợp lý khi ngân sách hay thời gian bị siết. Một brief không phân biệt ưu tiên là một brief đẩy mọi quyết định khó cho đội làm tự đoán.
Đừng tự thiết kế thay cho người làm
Có một ranh giới tinh tế cần giữ: brief nên rõ ràng về vấn đề và mục tiêu, nhưng không nên cố thiết kế chi tiết kỹ thuật thay cho đội làm. Khi một người không chuyên cố chỉ định cách mọi thứ phải được xây dựng về mặt kỹ thuật, họ thường tạo ra những ràng buộc không cần thiết và bỏ lỡ những cách làm tốt hơn mà người làm nghề biết. Brief nên nói cái gì và tại sao, để người làm lo cái như thế nào.
Điều này không có nghĩa bạn không được có ý kiến về sản phẩm; ngược lại, ý kiến của bạn về trải nghiệm mong muốn và những ưu tiên là quý giá. Nhưng hãy diễn đạt chúng dưới dạng mục tiêu và mong muốn, không phải dưới dạng những chỉ định kỹ thuật cứng nhắc. Sự tin tưởng vào chuyên môn của đội làm, kết hợp với sự rõ ràng về điều bạn cần đạt được, tạo ra một sự hợp tác hiệu quả. Bạn mang tới hiểu biết sâu về việc kinh doanh của mình, họ mang tới hiểu biết sâu về cách xây dựng, và brief tốt là nơi hai loại hiểu biết này gặp nhau đúng cách.
Tiêu chí thành công đo được
Một brief mạnh bao gồm những tiêu chí cụ thể để biết khi nào dự án thành công. Thay vì những mục tiêu mơ hồ như cải thiện hiệu quả, hãy cố diễn đạt thành công một cách cụ thể và nếu có thể là đo được. Điều này vừa giúp đội làm hiểu rõ đích đến, vừa cho cả hai bên một thước đo chung để đánh giá kết quả thay vì tranh cãi cảm tính về việc sản phẩm có đạt hay không.
Tiêu chí thành công rõ ràng cũng định hướng những quyết định khó trong dự án. Khi phải chọn giữa các phương án, câu hỏi cái nào phục vụ tiêu chí thành công tốt hơn cho một câu trả lời khách quan. Nó biến những cuộc thảo luận từ chỗ dựa trên sở thích cá nhân sang chỗ dựa trên mục tiêu chung. Hãy dành thời gian suy nghĩ về việc bạn sẽ biết dự án thành công bằng cách nào, và đưa điều đó vào brief, vì một đích đến rõ ràng giúp cả đoàn cùng chèo về một hướng thay vì mỗi người hiểu thành công một kiểu.
Những gì một brief nên tránh
Cuối cùng, có vài điều một brief tốt nên tránh. Tránh sự mơ hồ khiến người đọc phải đoán; nếu một câu có thể hiểu theo nhiều cách, hãy làm nó rõ hơn. Tránh nhồi quá nhiều chi tiết kỹ thuật mà bạn không chắc, vì điều đó vừa gò bó vừa có thể sai. Tránh trộn lẫn những điều bắt buộc với những điều mong muốn mà không phân biệt. Và tránh viết brief một lần rồi coi như xong; brief tốt thường được tinh chỉnh qua trao đổi với đội làm, những người có thể đặt câu hỏi làm rõ những chỗ bạn chưa nghĩ tới.
Một brief tốt không nhất thiết phải dài hay hoa mỹ; nó cần rõ ràng, trung thực về ưu tiên, và tập trung vào vấn đề cùng mục tiêu. Hãy xem nó như khởi đầu của một cuộc đối thoại với đội làm, không phải một bản hợp đồng đóng kín. Khi được viết tốt và tinh chỉnh qua trao đổi, brief trở thành nền tảng vững chắc cho cả dự án, giảm mạnh nguy cơ hiểu lầm và đặt mọi người vào cùng một trang ngay từ đầu. Đó là một trong những việc đơn giản nhưng có tác động lớn nhất mà người đặt làm có thể làm để dự án thành công.
Đội ngũ Microads luôn cùng khách tinh chỉnh brief ở giai đoạn đầu, đặt câu hỏi để làm rõ vấn đề và mục tiêu thật trước khi bắt tay xây dựng. Nếu bạn đang chuẩn bị một dự án phần mềm và muốn được hỗ trợ làm rõ yêu cầu để tránh hiểu sai, hãy gọi 0919 788 815 hoặc trao đổi với chúng tôi qua khanhn@microads.vn.
