Một dự án bắt đầu đầy hi vọng. Khi bắt đầu dự án, bạn và team đều trên cùng một xuất phát điểm – ít nhất là có vẻ như vậy.
Nhưng khi làm việc, bạn nhận ra rằng nhận thức của team về một điều gì đó đang bất đồng. Đã bao giờ bạn gặp trường hợp như vậy chưa?
Một Team tốt có thể xoay sở để thích nghi với điều này, nhưng đôi khi sự hiểu lầm này gây nên nhiều phiền phức cản trở bước chân của cả team, thậm chí giết chết project trước khi nó kịp bắt đầu.
Để giải quyết vấn đề này , Jonathan Rasmusson – khi còn làm việc tại Thoughtwork – đã cùng đồng nghiệp tạo ra một công cụ nhỏ để định nghĩa dự án:10 câu hỏi bạn nên hỏi trước khi bắt đầu dự án của mình
Những câu hỏi này phục vụ hai mục tiêu: Alignment (tạm dịch là đồng bộ) và Expectation setting (thiết lập kỳ vọng).
Alignment bảo đảm bạn và những người khác có chung nhận thức về lý do: vì sao team được thành lập, chúng ta phải làm những gì, và làm thế nào chúng ta làm điều đó – những điều cơ bản.
Expectation setting để bảo đảm bạn đã trao đổi rõ ràng với team và các bên liên quan điều gì cần thiết để làm project thành công, đây là Rules of engagement (các quy tắc tham gia.)
Phần 1 : Alignment
Allignment bao gồm 5 câu hỏi “tại sao” nhằm mục đích làm rõ kỳ vọng của khách hàng. Làm thế nào bạn biết khách hàng của bạn thực sự cần gì, hãy bắt đầu bằng việc hỏi .
1. Tại sao chúng ta lại ở đây?
Bạn không thể xây dựng một sản phẩm tuyệt vời nếu ngay từ đầu, bạn không biết lý do tại sao phải bạn xây dựng nó.
Đây là câu hỏi này mang đến cho bạn và team bối cảnh của dự án, việc trả lời nó giúp bạn
- Phán đoán chính xác hơn khi thực hiện dự án,
- Biết được nên làm gì bỏ gì ( trade- off)
- Giúp team có khả năng sáng tạo, tạo ra những sản phẩm tốt hơn đáp ứng chính xác những gì khách hàng cần
Ví dụ, bạn được thuê một công ty xây dựng thuê để tạo ra một hệ thống thông báo tình trạng các con đường dẫn đến công trường xây dựng hàng ngày.
Tại sao các công ty chi vốn cổ đông cho dự án này?
Dự án nhằm mục đích an toàn, nó là một yêu cầu/ quy định bắt buộc, hay nó nhằm mục đích gia tăng hiệu quả của việc chuyên chở hàng hóa nguyên liệu đến công trường ?
Tùy theo mục đích của dự án, ta sẽ phán đoán được chức năng gì là thực sự cần thiết với khách hàng.
2. Tạo Elevator Pitch (giới thiệu nhanh)
Một elevator pitch nói lên thông tin sản phẩm của bạn, nó có mục đích gì và vì sao nó lại đặc biệt.
Một Elevator Pitch tốt phải làm rõ các yếu tố sau :
– Ai là khách hàng
– Họ muốn giải quyết vấn đề gì thông qua dự án
– Tên dự án là gì
– Phân loại ( category) của dự án
– Tính năng chủ yếu của dự án là gì
– So với những dự án cùng loại
– Nó khác ở điểm nào.
Tạo một elevator pitch tốt có thể khó hơn bạn nghĩ. Nhưng nó cho bạn có một khái niệm thực sự chặt chẽ, khả thi về dự án.
3. Thiết kế bao bì sản phẩm
Suy nghĩ thật kỹ về sản phẩm của bạn từ quan điểm của khách hàng . Tạo bao bì cho sản phẩm không chỉ giúp bạn hiểu khách hàng hơn, nó còn là một phương pháp team-building tốt, bởi bạn và team được thỏa sức sáng tạo ở thời điểm này.
Bạn không cần phải đưa ra bất cứ điều gì cầu kì hoặc phức tạp. Chỉ cần tự hỏi mình:
1. Ba lý do hàng đầu để khách hàng mua sản phẩm này là gì?
2. Slogan tiêu biểu cho toàn bộ sản phẩm là gì?
4. Tạo danh sách những điều không làm
Nói “có” bao giờ cũng dễ hơn “không”.
Trong một project, việc tạo danh sách những việc không có trong scope cũng quan trọng không kém danh sách những việc sẽ làm.
Thường ta có rất nhiều điều muốn làm, nhưng thời gian và dự toán là hữu hạn. Vì vậy, việc định ra chính xác những gì không làm nên được làm ở giai đoạn càng sớm càng tốt.
Việc tạo ra list này giúp khách hàng hiểu họ có thể kỳ vọng gì vào project đồng thời cũng giúp team hiểu những task nào là trọng yếu trong quá trình xây dựng sản phẩm, giúp họ tập trung vào trọng tâm.
Hãy tạo 1 bảng như trong hình, ghi những điều bạn sẽ làm, những điều bạn không làm. Nếu có những tính năng bạn không quyết được đặt vào đâu ở thời điểm này, hãy để tạm vào list những điều sẽ quyết sau.
5. Gặp những bên liên quan.
Hầu hết mọi người thường nghĩ dự án chỉ liên quan đến bản thân và nhóm phát triển. Nhưng thực tế, các dự án liên quan đến nhiều người khác nữa, nhất là trong công ty lớn.
Bạn hãy lên danh sách những người bạn nên gặp gỡ và thiết lập quan hệ trước khi bắt đầu project.Điều này giúp các bên liên quan biết và có chuẩn bị khi bạn nhờ giúp đỡ.
Phần 2: Expectation setting
6. Chọn giải pháp kỹ thuật:
Thực tế, ngay từ bước chọn thành viên của team, bạn đã chọn giải pháp kỹ thuật – Nếu bạn chọn các thành viên giỏi về một kỹ thuật nào đó, họ có xu hướng chọn kỹ thuật đó để sử dụng theo thói quen. Dù vậy, trước quyết định sử dụng một giải pháp bất kỳ, hãy lấy ý kiến của toàn team trước khi bắt đầu dự án, việc này giúp team :
- Đề cao sự đồng thuận trong team.
- Thấy được các việc cần chuẩn bị về tool và kỹ thuật
- Từ các giải pháp kỹ thuật, có thể nhìn thấy giới hạn và điểm yếu của sản phẩm. Từ đó có các quyết định hợp lý.
Ở bước này, trong cuộc họp cần phải làm rõ 3 điểm sau:
– Bạn định thiết kế sản phẩm thế nào. Hiển thị ý tưởng bằng sơ đồ.
– Xác định các risk có thể xảy ra nếu sử dụng các kỹ thuật trên.
– Thảo luận xem các kỹ thuật trên có phải là phương án tối ưu không? Lấy sự đồng thuận của toàn team.
7. Điều gì khiến bạn mất ngủ
Có hàng ngàn trắc trở có thể đến với dự án của bạn. Có những cái bạn có thể xử lý, có những cái không. Nhiệm vụ của chúng ta là nhận ra các nguy cơ, phân loại chúng, và chuẩn bị đối phó với những thứ có thể đối phó được.
Ví dụ, bạn chẳng làm gì để ngăn khủng hoảng kinh tế được, vì thế hãy quẳng nỗi lo này ra sau đầu.
Nhưng đấu tranh để giành team member tốt thì có giá trị để thử.
Đây là cơ hội để bạn list up ra tất cả những điều bạn cần có để giảm thiểu nguy cơ, giúp cho dự án thành công và “chiến đấu” để có được chúng.
Tất nhiên là bạn sẽ chẳng bao giờ có được mọi thứ bạn muốn đâu. Nhưng dù sao thử đòi một chút cũng chẳng mất gì.
8. Dự tính thời gian hoàn thành.
Việc dự kiến một dự án mất bao nhiêu ngày để hoàn thành trước khi nó bắt đâu là không thể, nhưng ít nhất chúng ta cần thông báo với các bên liên quan một cách đại khái cần 3-6 hay 9 tháng.
Điều quan trọng của câu hỏi này không nằm ở tính chính xác của ước tính, thời gian dự tính này nhắc nhở chúng ta mục tiêu của dự án, nhấn mạnh chúng ta sẽ phải làm được những gì với nguồn lực trong tay trong thời gian cho phép.
Việc lập kế hoạch cho một dự án 3-6 tháng sẽ mất vài ngày đến 2 tuần.
Theo tác giả, bí quyết để một dự án thành công là nó không được dài hơn 6 tháng.
Việc không xác định rõ mục tiêu khiến dự án dường như không bao giờ kết thúc, và sản phẩm làm ra cũng dễ bị lạc đường, không đầy đủ. Nếu khách hàng cứ yêu cầu thêm tính năng mà không để ý đến thời hạn, dự án sẽ ngày càng chệch hướng, nặng nề hơn và cuối cùng đổ vỡ.
9. Xác định rõ ưu tiên cái gì.
Mỗi dự án đều có 4 yếu tố quan trọng: thời gian, tiền, phạm vi phát triển và chất lượng.
4 yếu tố trên đối lập nhau và không thể cùng đặt ưu tiên cao được.
Ở phần này, chúng ta cần làm rõ, trong dự án cái gì là quan trọng nhất và không được thay đổi, cái gì có thể điều chỉnh.
Ngoài ra việc thảo luận cái gì có thể khiến dự án thất bại – sản phẩm khó dùng, tốc độ, tính an toàn và đặt chúng lên trade off slider cũng giúp ích rất lớn khi ta cần đưa ra những quyết định quan trọng.
10.Chúng ta cần gì và bao nhiêu :
Đây là câu hỏi về 2 vấn đề nóng bỏng với mỗi bên: mất bao nhiêu thời gian và chi phí sẽ là bao nhiêu.
Trong trường hợp một dự án đã fix budget, chúng ta chỉ việc xem với budget đó, ta có thể xử lý được số task được đưa ra không.
Đây cũng là cơ hội để bạn phán đoán một team thế nào có thể giảm giá thành đến mức thấp nhất, quyết định số người trong team, các kỹ năng cần có của thành viên và thành lập team dựa theo tiêu chí này.
Trên đây là 10 câu hỏi khi bắt đầu dự án cuả Jonathan Rasmusson
Mục đích của việc thực hiện 10 câu hỏi inception deck tìm ra những khái niệm cốt lõi của dự án, sau đó chia sẻ kết quả đến các bên liên quan và những người khác trong team.
Việc thực hiện tất cả 10 bước sẽ làm bạn mất vài ngay hoặc vài tuần cho một dự án dài 3-6 tháng. Nhưng nó là một công cụ vô giá để thiết lập mục tiêu cho dự án và nhắc nhở mọi người vai trò của họ cũng như của project.
Source: Agile Samurai book – Tác giả Jonathan Rasmusson/ labs.septeni-technology.jp