Cách xác định phạm vi dự án Web App với AI: Chuỗi 6 câu lệnh chúng tôi dùng (Từ ý tưởng đến SOW)
Trong năm dự án gần nhất của khách hàng, phần công việc vốn trước đây tốn 12 đến 16 giờ cho các cuộc gọi khám phá (discovery calls) đã giảm xuống còn khoảng 3 giờ làm việc với AI cộng thêm 1 giờ rà soát bởi con người. Chúng tôi thực hiện toàn bộ quy trình này trong một Claude Project duy nhất để ngữ cảnh được giữ nguyên xuyên suốt. Vấn đề nằm ở chỗ? AI luôn mắc ba lỗi sai trong mỗi lần chạy. Vì vậy, chúng tôi đã thêm một bước kiểm duyệt (gate) trước khi bất kỳ nội dung nào được gửi đến khách hàng.
Đây chính xác là chuỗi 6 câu lệnh mà chúng tôi sử dụng, sản phẩm đầu ra (artifact) mà mỗi câu lệnh tạo ra, một ví dụ minh họa đầy đủ, và các chế độ lỗi (failure modes) mà bạn cần tự mình phát hiện.
AI có thể xác định phạm vi một dự án web app không? Có. AI có thể soạn thảo toàn bộ phạm vi (tuyên bố vấn đề, user stories, tính năng, ưu tiên MoSCoW và bản tuyên bố công việc - SOW) chỉ trong vài giờ thay vì vài ngày. Điều nó không thể làm là xác thực bản dự thảo đó. Nó bịa đặt ra các yêu cầu và đánh giá thấp nỗ lực thực hiện, nên bước kiểm duyệt của con người là bắt buộc trước khi ký kết.
Những điểm chính
- AI soạn thảo toàn bộ phạm vi web app trong vài giờ, không phải vài ngày, nhưng không thể tự xác thực kết quả đầu ra của mình.
- Chuỗi gồm sáu câu lệnh: vấn đề, user stories, tính năng, MoSCoW, ước lượng, SOW.
- AI bịa đặt các tích hợp và đánh giá thấp các trường hợp biên (edge cases), vì vậy hãy luôn chạy bước kiểm duyệt của con người.
- Sử dụng Claude Projects hoặc ChatGPT Projects cho chuỗi này; các tác nhân AI (agents) chỉ nên dùng sau khi phạm vi đã được ký kết.
AI có thể viết bản dự thảo phạm vi đầu tiên của bạn trong một buổi chiều. Nó chỉ không thể cho bạn biết khi nào nó sai.
Xác định phạm vi hỗ trợ bởi AI là gì (và KHÔNG phải là gì)?
Xác định phạm vi hỗ trợ bởi AI nghĩa là sử dụng một loạt câu lệnh LLM để biến một ý tưởng sơ khai thành các tài liệu phạm vi có cấu trúc: yêu cầu, user stories, danh sách tính năng, thứ tự ưu tiên và bản tuyên bố công việc (SOW). AI đảm nhận việc soạn thảo và sắp xếp cấu trúc. Con người vẫn thực hiện việc ra quyết định, trao đổi với các bên liên quan và xác thực.
Vậy AI có đang suy nghĩ thay bạn không? Không hẳn. Nó rất nhanh trong khâu thu thập yêu cầu bằng AI, phần mà bạn thường ngồi nhìn trang giấy trắng và cố gắng dịch "Tôi muốn một ứng dụng đặt lịch" thành thứ mà lập trình viên có thể báo giá. Nhưng nó kém trong việc biết khách hàng thực sự cần gì so với những gì nghe có vẻ hợp lý.
Một vài điều mà xác định phạm vi hỗ trợ bởi AI không phải là: nó không tự động hoàn toàn, không thay thế việc nói chuyện với các bên liên quan thực tế, và không đảm bảo độ chính xác. Mô hình sẽ sẵn sàng viết một bản đặc tả tự tin, định dạng đẹp cho một tính năng mà chẳng ai yêu cầu.
Bài viết này giả định bạn đã hiểu quy trình xác định phạm vi. Nếu bạn muốn nắm vững kiến thức nền tảng, hướng dẫn xác định phạm vi từng bước của chúng tôi sẽ đi qua quy trình cơ bản không dùng AI, 7 bước và cấu trúc tài liệu phạm vi đầy đủ. Tại đây, chúng ta tập trung vào lớp AI: câu lệnh nào, theo thứ tự nào và nơi nó gặp trục trặc.
Tổng quan về chuỗi câu lệnh xác định phạm vi bằng AI
Chuỗi này gồm sáu câu lệnh chạy tuần tự, mỗi câu lệnh đưa đầu ra của mình vào câu lệnh tiếp theo. Theo thứ tự: (1) vấn đề và mục tiêu, (2) user stories, (3) danh sách tính năng, (4) ưu tiên hóa MoSCoW, (5) ước lượng nỗ lực, chi phí và thời gian, và (6) bản dự thảo SOW. Hãy chạy chúng trong cùng một dự án để ngữ cảnh được lưu giữ.
Phần thú vị là: vì mỗi câu lệnh xây dựng dựa trên cái trước đó, bạn không cần giải thích lại ứng dụng của mình sáu lần. Mô hình đã biết vấn đề khi nó viết user stories, và đã biết các câu chuyện khi nó ưu tiên hóa tính năng.
- Vấn đề & mục tiêu: biến ý tưởng sơ khai thành tuyên bố vấn đề cộng với các mục tiêu SMART.
- User stories: chuyển đổi mục tiêu thành user stories với các tiêu chí chấp nhận.
- Danh sách tính năng: suy ra một danh mục tính năng cụ thể từ các câu chuyện.
- Ưu tiên hóa MoSCoW: phân loại tính năng thành Must (Phải có), Should (Nên có), Could (Có thể có), Won't (Không làm).
- Ước lượng: đưa ra nỗ lực, khoảng chi phí và lộ trình thời gian.
- Dự thảo SOW: lắp ráp mọi thứ thành một bản tuyên bố công việc.
Đây cũng là một bộ câu lệnh AI cho quản lý dự án sạch sẽ nói chung, nhưng chúng tôi đã tinh chỉnh mọi câu lệnh cụ thể cho web app (công nghệ, tích hợp, các trường hợp biên). Sự tinh chỉnh này là yếu tố phân biệt một bản phạm vi khả thi với một bản chung chung.
Mấu chốt không nằm ở một câu lệnh thần kỳ. Đó là sáu câu lệnh chuyển giao đầu ra cho nhau.
Cách chạy chuỗi từng bước?
Bạn chạy chuỗi từ trên xuống dưới trong một Claude Project hoặc ChatGPT Project, dán từng câu lệnh theo thứ tự và để câu trả lời trước đó nằm trong ngữ cảnh. Dưới đây là sáu bước đơn giản với các câu lệnh chính xác mà chúng tôi sử dụng. Mỗi bước đều được thiết kế riêng cho web app, vì các câu lệnh phân tích kinh doanh chung chung sẽ tạo ra các bản phạm vi chung chung.
Lưu ý trước khi bắt đầu: thay thế các chỗ trống trong ngoặc vuông bằng chi tiết của bạn, và không bao giờ chấp nhận kết quả đầu tiên là cuối cùng. Cách làm chuyên nghiệp là đọc từng kết quả, sửa chữa nó, rồi chạy câu lệnh tiếp theo.
Câu lệnh 1: Tuyên bố vấn đề & mục tiêu
You are a senior product manager scoping a web application.
Here is the rough idea: [describe the app in 2-4 sentences].
The target users are [who]. The business wants [outcome].
Write:
1. A one-paragraph problem statement.
2. 3-5 SMART goals with success metrics.
3. 3 assumptions you are making that I should confirm.
Flag anything that is unclear instead of guessing.Điều này tạo ra phần tổng quan và mục tiêu của bạn. Mẹo nhỏ: dòng "3 giả định" đang gánh vác trách nhiệm lớn. Nó phơi bày những khoảng trống mà AI thường bỏ qua.
Câu lệnh 2: User stories
Acting as the same product manager, turn the goals above into
user stories for a web app. Use the format:
"As a [role], I want [action], so that [benefit]."
Cover every user role. For each story, add 2-3 acceptance
criteria. Group stories by feature area.Bây giờ bạn đã có các yêu cầu chức năng. Đây là bước tạo user story bằng AI gọn gàng. Điểm cần lưu ý: nó có xu hướng quên các vai trò quản trị viên và các trường hợp biên, vì vậy hãy yêu cầu nó lại với "giờ hãy thêm các câu chuyện cho admin, thanh toán thất bại và các trạng thái trống."
Câu lệnh 3: Danh sách tính năng
Based on the user stories above, produce a flat feature
inventory for this web app. Group features into: core, account
and auth, admin, integrations, and notifications. Note any
feature that requires a third-party service or API.Đây là danh sách ứng viên tính năng nằm trong phạm vi. Hãy theo dõi kỹ bước này, vì đây là nơi AI bắt đầu bịa đặt các tích hợp (sẽ nói thêm ở phần sau).
Câu lệnh 4: Ưu tiên hóa MoSCoW
Prioritize the feature list using MoSCoW (Must, Should, Could,
Won't) for a first release (MVP). For each feature give a
one-line reason. Assume a 3-month MVP budget and be ruthless:
most features should NOT be "Must."Bước này gắn nhãn các hạng mục trong và ngoài phạm vi. Chỉ thị "hãy tàn nhẫn" rất quan trọng; nếu không có nó, mô hình sẽ đánh dấu hầu hết mọi thứ là Must (Phải có).
Câu lệnh 5: Ước lượng nỗ lực, chi phí & thời gian
Estimate effort, cost, and timeline for the Must-have features
only. Assume a stack of [e.g. Next.js, Supabase, Stripe] and a
team of [N] developers. Break the estimate down by feature in
days. State every assumption. Give a cost RANGE, not a single
number, and flag the 3 riskiest estimates.Đây là đầu vào cho công cụ tạo scope of work bằng AI về ngân sách và thời gian. Luôn yêu cầu một khoảng giá trị và các giả định, vì một con số tự tin duy nhất là kết quả nguy hiểm nhất mà AI đưa ra cho bạn.
Câu lệnh 6: Dự thảo SOW
Assemble everything above into a draft statement of work for a
client. Include: overview, goals and success metrics, in-scope
features, explicit out-of-scope items, timeline, budget range,
deliverables, assumptions, and a sign-off section. Mark any
section where you are uncertain with [REVIEW].Các thẻ [REVIEW] trở thành danh sách kiểm tra bước kiểm duyệt của con người. Bước này lắp ráp toàn bộ quá trình từ ý tưởng đến SOW mà cả chuỗi đã hứa hẹn.
Ánh xạ Câu lệnh → Phần Phạm vi
Mỗi câu lệnh không chỉ trả lời một câu hỏi, nó điền vào một phần cụ thể của tài liệu bạn gửi cho khách hàng. Sự ánh xạ này thay thế mẫu 11 phần thông thường: thay vì ghi nhớ một khung sườn, bạn chạy chuỗi và tài liệu sẽ tự lắp ráp. Dưới đây là câu lệnh nào tạo ra sản phẩm bàn giao nào.
| Câu lệnh | Tạo ra | Phần tài liệu phạm vi nó điền vào |
|---|---|---|
| 1. Vấn đề & mục tiêu | Tuyên bố vấn đề + mục tiêu SMART | Tổng quan, Mục tiêu & Chỉ số thành công |
| 2. User stories | User stories + tiêu chí chấp nhận | Yêu cầu chức năng |
| 3. Danh sách tính năng | Danh mục tính năng | Các tính năng trong phạm vi |
| 4. MoSCoW | Phân loại Must/Should/Could/Won't | Trong phạm vi (đã gắn nhãn) + Ngoài phạm vi |
| 5. Ước lượng | Nỗ lực, khoảng chi phí, thời gian | Lộ trình, Khoảng ngân sách |
| 6. Dự thảo SOW | Bản tuyên bố công việc đã lắp ráp | Toàn bộ SOW + sản phẩm bàn giao + ký kết |
Khi bạn hoàn thành Câu lệnh 6, bạn sẽ có một bản dự thảo hoàn chỉnh của một tài liệu mà khách hàng thực sự có thể đọc và ký, chứ không phải một đống ghi chú rời rạc.
Mỗi câu lệnh không chỉ trả lời một câu hỏi. Nó điền vào một phần cụ thể của tài liệu bạn sẽ gửi cho khách hàng.
Ví dụ minh họa đầy đủ: Xác định phạm vi SaaS đặt lịch hẹn
Dưới đây là chuỗi được chạy từ đầu đến cuối cho một trường hợp cụ thể: một SaaS đặt lịch hẹn cho một chuỗi phòng khám nha khoa nhỏ. Đây là ví dụ minh họa, không phải tài liệu bàn giao cho khách hàng thực tế, và vâng, chúng tôi đã phát hiện hai lỗi trong đầu ra của AI, những lỗi mà chúng tôi sửa trong phần kiểm duyệt của con người bên dưới.
Đầu ra Câu lệnh 1 (vấn đề & mục tiêu). Vấn đề: một chuỗi nha khoa ba cơ sở bị mất lượt đặt lịch do việc gọi điện qua lại và khách không đến. Mục tiêu: giảm 30% tỷ lệ khách không đến nhờ nhắc nhở, cho phép bệnh nhân tự đặt lịch trực tuyến và cung cấp cho nhân viên lễ tân một lịch chung. Các giả định được đánh dấu: múi giờ duy nhất, chỉ tiếng Anh, không xử lý thanh toán bảo hiểm.
Đầu ra Câu lệnh 2 (mẫu user stories).
- Với tư cách là bệnh nhân, tôi muốn đặt lịch hẹn trực tuyến, để tôi không phải gọi điện.
- Với tư cách là bệnh nhân, tôi muốn nhận nhắc nhở qua SMS, để tôi không quên lịch hẹn.
- Với tư cách là nhân viên lễ tân, tôi muốn xem tất cả ba cơ sở trong một lịch, để tôi có thể quản lý các trùng lặp.
Đầu ra Câu lệnh 3 (danh sách tính năng, tóm tắt). Đặt lịch trực tuyến, đồng bộ lịch, nhắc nhở SMS và email, tài khoản bệnh nhân, quản trị đa cơ sở, báo cáo cơ bản và bước thanh toán (cái cuối cùng này là bịa đặt; không ai yêu cầu nó).
Đầu ra Câu lệnh 4 (bảng MoSCoW).
| Ưu tiên | Tính năng |
|---|---|
| Must (Phải có) | Đặt lịch trực tuyến, lịch đa cơ sở, nhắc nhở SMS, tài khoản bệnh nhân |
| Should (Nên có) | Nhắc nhở email, báo cáo cơ bản |
| Could (Có thể có) | Bệnh nhân tự đổi lịch |
| Won't (v1) | Thanh toán, thanh toán bảo hiểm, ứng dụng di động native |
Đầu ra Câu lệnh 5 (ước lượng, tóm tắt). Giả sử sử dụng Next.js, Supabase và Twilio với hai lập trình viên: các tính năng Must-have chiếm khoảng 45 đến 60 ngày công lập trình, khoảng chi phí quanh mức $35K đến $55K, và lộ trình 8 đến 10 tuần. Ước lượng rủi ro nhất được đánh dấu: logic lịch đa cơ sở.
Đầu ra Câu lệnh 6 (trích đoạn SOW). "Trong phạm vi: đặt lịch trực tuyến, lịch chung đa cơ sở, nhắc nhở SMS (Twilio), tài khoản bệnh nhân. Ngoài phạm vi: thanh toán, bảo hiểm, ứng dụng di động native. Thời gian: 8-10 tuần. Khoảng ngân sách: $35K-$55K. [REVIEW] Xác nhận Twilio hay nhà cung cấp SMS thay thế với khách hàng."
Đọc lướt qua, bạn có thể thấy một bản phạm vi thực tế, có thể ký kết đã hình thành chỉ trong một lần ngồi làm việc. Nếu bạn dự định bổ sung các tính năng thông minh sau này, hướng dẫn của chúng tôi về thêm tính năng AI vào ứng dụng của bạn sẽ tiếp nối từ điểm này.
Cách ước lượng chi phí và thời gian với AI?
Bạn yêu cầu mô hình chia nhỏ ước lượng theo từng tính năng tính bằng ngày, giả định một stack công nghệ cụ thể, nêu rõ mọi giả định và trả về một khoảng giá trị thay vì một con số duy nhất. Sau đó, bạn kiểm tra tính hợp lý của khoảng giá trị đó so với các mức thị trường đã biết, vì AI hầu như luôn neo vào các con số quá lạc quan về nỗ lực.
Hãy coi ước lượng của AI là điểm khởi đầu, không bao giờ là báo giá. Hướng dẫn hữu ích nhất là "đánh dấu ba ước lượng rủi ro nhất", điều này cho bạn biết chính xác nơi cần áp dụng phán đoán của riêng mình. Dưới đây là các mức mà chúng tôi đối chiếu với mọi ước lượng AI.
| Độ phức tạp web app | Khoảng chi phí điển hình | Thời gian điển hình |
|---|---|---|
| MVP đơn giản | $10K-$50K | 1-3 tháng |
| Trung bình (xác thực, thanh toán, dashboard) | $50K-$100K | 3-6 tháng |
| Phức tạp (đa vai trò, tích hợp, mở rộng) | $75K-$150K+ | 6-12 tháng |
Các khoảng này phù hợp với các benchmark được công bố từ các agency và sàn thương mại; nghiên cứu chi phí phát triển ứng dụng của Clutch là một điểm tham chiếu công khai hợp lý. Nếu ước lượng AI của bạn thấp hơn đáng kể so với mức liên quan, nó có lẽ đã bỏ sót các trường hợp biên. Đây cũng là lúc đặt câu hỏi lớn hơn: tự xây dựng hay mua lại. Một bản phạm vi phình to vượt quá mức phức tạp đôi khi ủng hộ việc mua thay vì xây dựng.
Nên dùng công cụ AI nào cho từng nhiệm vụ?
Cho toàn bộ chuỗi, hãy sử dụng Claude Projects hoặc ChatGPT Projects, vì cả hai đều lưu giữ ngữ cảnh xuyên suốt các câu lệnh nên đầu ra được chuyển tiếp mà không cần dán lại. Chỉ sử dụng một agent độc lập sau khi phạm vi đã được ký kết và bạn đang tạo ra các sản phẩm có thể tái sử dụng. Đối với việc xác định phạm vi lẻ tẻ, Projects luôn tốt hơn agent.
Chúng tôi chạy chuỗi trong Claude Projects cho các bước cần ngữ cảnh dài (user stories, lắp ráp SOW) và chuyển sang ChatGPT khi muốn có ý kiến thứ hai về ước lượng. Theo tài liệu Projects của Anthropic, một Project giữ lại ngữ cảnh và hướng dẫn chung xuyên suốt một cuộc hội thoại,这正是สิ่งที่ quy trình làm việc claude projects cho yêu cầu gồm sáu câu lệnh cần. Projects của OpenAI hoạt động tương tự cho chatgpt prompts software development.
Một kỹ thuật đáng học hỏi: phân chia vai trò của AI cho từng bước. Bảo nó "đóng vai trưởng sản phẩm" cho user stories và "đóng vai kỹ sư senior" cho ước lượng. Việc chuyển đổi vai trò thay đổi cách nó suy luận, và nhân vật kỹ sư thường thận trọng hơn đáng kể về nỗ lực thực hiện.
Khi phạm vi đã được bàn giao và quá trình xây dựng bắt đầu, câu hỏi về công cụ chuyển sang các agent lập trình AI, đây là một quyết định hoàn toàn khác.
AI sai ở đâu khi xác định phạm vi? Bước kiểm duyệt của con người
AI mắc lỗi xác định phạm vi theo những cách có thể dự đoán: nó ảo giác ra các tích hợp mà không ai yêu cầu, đánh giá thấp các trường hợp biên và trạng thái lỗi, và hoặc là bịa đặt ra các yêu cầu tuân thủ hoặc âm thầm bỏ sót các yêu cầu thực tế. Nó cũng neo các ước lượng chi phí quá lạc quan. Không điều nào trong số này là hiếm; nó xảy ra trong hầu hết mọi lần chạy, đó là lý do tại sao bước kiểm duyệt của con người là không thể thương lượng.
Các yêu cầu kém chất lượng gây tốn kém dù do con người hay mô hình viết ra. Nghiên cứu Pulse of the Profession của PMI phát hiện ra rằng việc thu thập yêu cầu không chính xác là nguyên nhân chính dẫn đến thất bại dự án trong khoảng 37% các dự án thất bại, vì vậy mục đích của bước kiểm duyệt là bắt những thiếu sót này trước khi chúng đi vào báo giá, không phải sau đó.
Giải pháp là một danh sách kiểm tra ngắn mà con người thực hiện trước khi bất kỳ bản phạm vi nào đến tay khách hàng:
- Xóa các tính năng bịa đặt: loại bỏ bất cứ thứ gì (thanh toán, xuất dữ liệu, tích hợp) mà khách hàng chưa bao giờ yêu cầu.
- Thêm các trường hợp biên bị thiếu: thanh toán thất bại, trạng thái trống, quyền hạn, xử lý lỗi.
- Xác minh mọi tích hợp: xác nhận mỗi dịch vụ bên thứ ba được nêu tên là có thật, cần thiết và đã được tính vào ngân sách.
- Kiểm tra các tuyên bố tuân thủ: xác nhận hoặc sửa chữa bất kỳ yêu cầu xác thực, quyền riêng tư hoặc quy định nào mà AI khẳng định.
- Cộng thêm vào ước lượng: điều chỉnh các con số lạc quan dựa trên tốc độ thực tế của bạn, đặc biệt là những cái đã được đánh dấu là rủi ro.
AI sẽ tự tin xác định phạm vi cho một luồng thanh toán mà nó bịa ra. Nhiệm vụ của bạn là xóa các phần mà không ai yêu cầu.
Những gì chúng tôi học được khi chạy quy trình này trên các dự án khách hàng thực tế
Xuyên suốt nhiều dự án khách hàng gần đây, khâu khám phá vốn trước đây tốn khoảng 12 đến 16 giờ cho các cuộc gọi và viết tài liệu nay đã có thể đưa ra bản dự thảo SOW đầu tiên trong khoảng 2 đến 3 giờ làm việc với AI cộng thêm 1 giờ rà soát bởi con người. Đây là các khoảng thời gian trung thực từ các lần chạy của chính chúng tôi, không phải một con số thống kê tiêu đề chính xác, và giờ làm việc của con người là phần chúng tôi sẽ không bao giờ cắt giảm.
Chúng tôi chạy chuỗi trong Claude Projects, với ChatGPT làm bước kiểm tra tính hợp lý cho các ước lượng. Thời gian tiết kiệm được là có thật, nhưng giá trị nằm ở việc bắt gặp cùng ba lỗi thất bại mỗi lần:
- Nó bịa đặt các tích hợp. Một bước thanh toán trong ví dụ nha khoa mà không ai yêu cầu. Hầu như mọi bản phạm vi đều có ít nhất một tính năng ma.
- Nó đánh giá thấp các trường hợp biên. Các trạng thái lỗi, trạng thái trống và luồng admin luôn bị thiếu hoặc đếm thiếu, đây là nơi ngân sách thực tế bị vỡ.
- Nó xử lý sai tuân thủ và xác thực. Đôi khi nó ảo giác ra một yêu cầu, đôi khi nó bỏ sót một yêu cầu thực tế. Chúng tôi không bao giờ tin tưởng nó ở điểm này.
Vì vậy, chúng tôi đã thêm bước kiểm duyệt của con người ở trên như một bước cố định. Chuỗi viết bản dự thảo nhanh; bước kiểm duyệt là thứ làm cho nó an toàn để gửi đi. Bỏ qua bước kiểm duyệt và bạn chỉ đang gửi đi một phỏng đoán tự tin, được định dạng đẹp.
Cách Techsy tiếp cận xác định phạm vi hỗ trợ bởi AI
Chuỗi này cộng với bước kiểm duyệt của con người chính xác là quy trình làm việc chúng tôi chạy cho các khách hàng xây dựng web app. Chúng tôi soạn thảo nhanh với AI, sau đó một người đã từng triển khai các bản build thực tế sẽ xác thực từng dòng trước khi nó trở thành báo giá. Nếu bạn muốn giao phó việc xác định phạm vi cho một đội ngũ làm điều này hàng ngày, đó là những gì chúng tôi làm. Bạn nhận được một bản SOW có thể bảo vệ được mà không phải trả tiền cho hai tuần gọi điện khám phá dự án trước đó.
Về tác giả
Mert Batur Gurbuz là Đồng sáng lập của Techsy.io, nơi đội ngũ triển khai các agent AI, hệ thống tự động hóa và các pipeline voice/SDR cho khách hàng B2B. Anh ấy đang học tại Đại học Birmingham và viết về ngăn xếp công cụ LLM mà đội ngũ Techsy thực sự sử dụng trong môi trường production.
Đồng sáng lập, Techsy.io — Đại học Birmingham. Kết nối trên LinkedIn.
Câu hỏi thường gặp
AI có thể viết phạm vi dự án hoặc SOW không?
Có, AI có thể soạn thảo một phạm vi dự án hoặc bản tuyên bố công việc hoàn chỉnh, bao gồm vấn đề, user stories, tính năng, ưu tiên, thời gian và khoảng ngân sách. Chạy một chuỗi sáu câu lệnh bên trong một Claude hoặc ChatGPT Project. Bản dự thảo đáng tin cậy như một điểm khởi đầu, nhưng con người phải xác thực nó trước khi ký kết.
Công cụ AI nào tốt nhất để xác định phạm vi dự án phần mềm?
Claude Projects và ChatGPT Projects là những công cụ tốt nhất để xác định phạm vi, vì cả hai đều lưu giữ ngữ cảnh xuyên suốt chuỗi câu lệnh nên mỗi đầu ra sẽ cung cấp dữ liệu cho đầu ra tiếp theo. Chúng tôi sử dụng Claude Projects cho các bước cần ngữ cảnh dài như user stories và lắp ráp SOW, và ChatGPT làm ý kiến thứ hai cho các ước lượng. Các agent phù hợp hơn cho công việc xây dựng sau khi đã có phạm vi.
Làm thế nào để sử dụng ChatGPT hoặc Claude để thu thập yêu cầu?
Chạy chuỗi câu lệnh theo thứ tự: yêu cầu tuyên bố vấn đề và mục tiêu, sau đó là user stories với tiêu chí chấp nhận, sau đó là danh sách tính năng, sau đó là ưu tiên MoSCoW. Giữ mọi thứ trong một Project để ngữ cảnh được chuyển tiếp. Đầu ra của mỗi câu lệnh trở thành đầu vào cho câu lệnh tiếp theo, đó là điều làm cho việc thu thập yêu cầu bằng AI trở nên nhanh chóng.
AI có thể ước lượng chi phí và thời gian dự án phần mềm không?
Có, nhưng chỉ như một điểm khởi đầu. Yêu cầu mô hình chia nhỏ ước lượng theo từng tính năng tính bằng ngày, giả định một stack cụ thể, nêu rõ các giả định của nó và trả về một khoảng giá trị. Sau đó, kiểm tra tính hợp lý so với các mức thị trường: $10K-$50K cho một MVP đơn giản, lên đến $150K+ cho các ứng dụng phức tạp. AI có xu hướng neo vào các con số quá lạc quan.
Phạm vi do AI tạo ra có thực sự đáng tin cậy không?
Đáng tin cậy cho bản dự thảo đầu tiên, không phải để ký kết. AI tạo ra một bản phạm vi có cấu trúc tốt một cách nhanh chóng, nhưng nó bịa đặt các tích hợp, đánh giá thấp các trường hợp biên và xử lý sai các yêu cầu tuân thủ trong hầu hết mọi lần chạy. Coi đầu ra là một bản dự thảo nhanh, sau đó chạy bước kiểm duyệt của con người để xóa các tính năng bịa đặt và thêm các trường hợp biên bị thiếu trước khi bất kỳ ai ký vào.
Làm thế nào để biến một ý tưởng sơ khai thành đặc tả với AI?
Bắt đầu với Câu lệnh 1: dán ý tưởng của bạn trong hai đến bốn câu và yêu cầu AI viết tuyên bố vấn đề, mục tiêu SMART và các giả định mà nó đang đưa ra. Sau đó chạy năm câu lệnh tiếp theo theo trình tự. Đến Câu lệnh 6, bạn sẽ có một bản dự thảo SOW. Toàn bộ chuỗi mất vài giờ thay vì vài ngày.
Xác định phạm vi hỗ trợ bởi AI có thay thế giai đoạn khám phá không?
Không, nó nén gọn giai đoạn khám phá chứ không thay thế nó. Bạn vẫn cần các cuộc trò chuyện thực tế với các bên liên quan để biết khách hàng thực sự muốn gì. AI xử lý việc soạn thảo và cấu trúc, biến các ghi chú của bạn thành yêu cầu và SOW trong vài giờ. Con người vẫn xác thực, ưu tiên hóa và đưa ra các quyết định cuối cùng về phạm vi.
Mất bao lâu để xác định phạm vi một web app với AI?
Theo kinh nghiệm của chúng tôi, một bản dự thảo SOW đầu tiên mất khoảng 2 đến 3 giờ làm việc với AI cộng thêm khoảng 1 giờ rà soát bởi con người, so với 12 đến 16 giờ khám phá và viết tài liệu thủ công. Thời gian AI rất nhanh; giờ rà soát là không thể thương lượng, vì đó là nơi bạn bắt gặp các tính năng AI bịa ra và các trường hợp biên nó bỏ sót.