Yêu cầu dỗ dành người kinh doanh?

Những phương pháp nào có vẻ hoạt động tốt nhất để dỗ các yêu cầu của những người kinh doanh phi công nghệ? Tôi đang làm việc với một nhóm đang cố gắng để có được một thông số chung cho một dự án. Mỗi lần chúng tôi gặp nhau và mong đợi cho cuộc họp tiếp theo, chúng tôi yêu cầu những người kinh doanh mang lại yêu cầu của họ. Họ thường trả lời đại loại như thế này: Bạn ơi, bạn có nghĩ rằng các bạn có thể tạo ra một nguyên mẫu để chúng ta có thể thấy những gì chúng ta thích vào tuần tới không, bạn biết, không phải với bất kỳ dữ liệu hay bất cứ điều gì vì nó là nguyên mẫu, chỉ là chức năng. là một dự án cộng thêm 6 tháng nên rõ ràng là không khả thi (chúng tôi sẽ phải phát triển toàn bộ!), và chúng tôi thậm chí không biết nên làm gì với nguyên mẫu mà không có một số thông số kỹ thuật. Thành thật mà nói, tôi nghĩ giống như hầu hết mọi người, họ có một số ý tưởng về những gì họ muốn, họ chỉ không nghĩ về nó theo cách tập trung cần thiết để thu thập các yêu cầu thực sự. Thay thế cho việc đơn giản là nói với họ, Hãy cung cấp cho chúng tôi những gì bạn muốn hoặc chúng tôi không thể / sẽ không làm bất kỳ công việc nào (chúng tôi muốn họ hài lòng với kết quả này), có cách nào để giúp họ quyết định những gì họ muốn không? Ví dụ: chúng ta có thể nói với họ:

Một số màn hình (trong Powerpoint, trên khăn ăn, bất cứ thứ gì) hiển thị giao diện người dùng bạn muốn với tất cả dữ liệu bạn muốn xem và mô tả chức năng ở lề. Từ đó, chúng tôi sẽ đánh bóng nó và xây dựng phần phụ trợ dựa trên tập hợp các yêu cầu hành vi này.

HOẶC LÀ

Bạn đừng lo lắng về việc nó sẽ trông như thế nào ngay bây giờ (số 1 gác máy). Chỉ cần cung cấp cho chúng tôi danh sách tất cả dữ liệu bạn muốn về mỗi thứ mà chương trình theo dõi. Vì vậy, đối với khách hàng trực tuyến, bạn có thể liệt kê: tên, địa chỉ, số điện thoại, đơn đặt hàng, v.v. Nó không phải là một cấu trúc cơ sở dữ liệu hoàn hảo, nhưng chúng ta có thể tìm ra thứ gì đó từ đây và biết được bạn đang tìm kiếm gì

Có một trong những cách tiếp cận thay thế này để khiến các doanh nhân tập trung vào những gì họ muốn có ý nghĩa? Có những lựa chọn thay thế mà bạn đã thấy trong hành động?

Tôi đã dành 3 tháng cuối cùng trong một giai đoạn đầy đủ - và mệt mỏi - thu thập các yêu cầu của một dự án lớn và đã học được, trên hết, rằng không có giải pháp nào phù hợp cho tất cả mọi người . Không có quá trình, không có bí mật, sẽ làm việc trong mọi trường hợp. Phân tích yêu cầu là một kỹ năng thực sự và chỉ khi bạn nghĩ rằng cuối cùng bạn đã tìm ra tất cả, bạn sẽ tiếp xúc với một nhóm người hoàn toàn khác và phải ném mọi thứ bạn biết ra ngoài cửa sổ.

Một số bài học mà tôi đã học được:

• Các bên liên quan khác nhau nghĩ ở mức độ trừu tượng khác nhau.

  Thật dễ dàng để nói "nói ở cấp độ kinh doanh, không phải kỹ thuật", nhưng nó không nhất thiết phải dễ thực hiện . Hệ thống bạn đang thiết kế là một con voi và các bên liên quan của bạn là những người mù kiểm tra nó . Một số người quá đắm mình vào quá trình và thói quen mà họ thậm chí không nhận ra rằng có là một doanh nghiệp. Những người khác có thể làm việc ở mức độ trừu tượng mà bạn muốn nhưng có xu hướng đưa ra những tuyên bố cường điệu hoặc thậm chí sai, hoặc tham gia vào suy nghĩ mong muốn.

  Thật không may, bạn chỉ cần biết tất cả các cá nhân với tư cách cá nhân và hiểu cách họ nghĩ, học cách diễn giải những điều họ nói và thậm chí quyết định bỏ qua những gì.

• Phân chia và chinh phục

  Nếu bạn không muốn một cái gì đó được thực hiện, gửi nó cho một ủy ban.

  Đừng gặp gỡ với các ủy ban. Giữ những cuộc họp nhỏ nhất có thể. YMMV, nhưng theo kinh nghiệm của tôi, kích thước lý tưởng là 3-4 người (bao gồm cả chính bạn) cho các phiên mở và 2-3 người cho các phiên đóng (tức là khi bạn cần một câu hỏi cụ thể được trả lời).

  Tôi cố gắng gặp gỡ những người có chức năng tương tự trong kinh doanh. Thực sự có rất ít để đạt được và mất rất nhiều từ việc ném những người tiếp thị trong phòng với quầy đậu. Tìm kiếm những người là chuyên gia về một chủ đề và khiến họ nói về chủ đề đó.

• Một cuộc họp mà không có sự chuẩn bị là một cuộc họp không có mục đích.

  Một vài câu trả lời / nhận xét khác đã đề cập đến kỹ thuật người rơm, đây là một câu trả lời tuyệt vời cho những người rắc rối mà bạn dường như không thể nhận được bất kỳ câu trả lời nào. Nhưng đừng dựa vào rơm-men quá nhiều, hoặc người khác sẽ bắt đầu cảm thấy như bạn đang railroading họ. Bạn phải nhẹ nhàng đẩy mọi người đi đúng hướng và để họ tự đưa ra những chi tiết cụ thể, để họ cảm thấy như họ sở hữu chúng (và theo một nghĩa nào đó, họ sở hữu chúng).

  Những gì bạn cần phải có là một mô hình tinh thần nào đó về cách bạn nghĩ doanh nghiệp hoạt động và hệ thống nên hoạt động như thế nào . Bạn cần phải trở thành một chuyên gia tên miền , ngay cả khi bạn không phải là chuyên gia về công ty cụ thể được đề cập. Thực hiện nhiều nghiên cứu nhất có thể về doanh nghiệp của bạn, đối thủ cạnh tranh của họ, các hệ thống hiện có trên thị trường và bất kỳ thứ gì khác thậm chí có thể liên quan từ xa.

  Vào thời điểm đó, tôi thấy hiệu quả nhất khi làm việc với các cấu trúc cấp cao, chẳng hạn như Ca sử dụng, có xu hướng dễ chịu với mọi người, nhưng vẫn rất quan trọng để đặt câu hỏi cụ thể. Nếu bạn bắt đầu với "Làm thế nào để bạn lập hóa đơn cho khách hàng của bạn?" , bạn đang ở trong một cuộc họp rất dài. Đặt câu hỏi ngụ ý một quy trình thay vì thực hiện quy trình tại nơi di chuyển: Mục hàng là gì? Họ tính toán như thế nào? Họ có thường xuyên thay đổi không? Có bao nhiêu loại bán hàng hoặc hợp đồng khác nhau? Họ được in ở đâu? Bạn có được ý tưởng.

  Nếu bạn bỏ lỡ một bước, ai đó thường sẽ nói với bạn. Nếu không ai phàn nàn, thì hãy tự vỗ lưng, vì bạn vừa ngầm xác nhận quy trình.

• Trì hoãn các cuộc thảo luận ngoài chủ đề .

  Là một nhà phân tích yêu cầu, bạn cũng đóng vai trò là người hỗ trợ, và trừ khi bạn thực sự thích dành tất cả thời gian của mình trong các cuộc họp, bạn cần tìm cách để theo dõi mọi thứ. Trớ trêu thay, vấn đề này trở nên nguy hiểm nhất khi bạn cuối cùng đã làm được mọi người nói chuyện. Nếu bạn không cẩn thận, nó có thể làm trật bánh tàu mà bạn đã dành quá nhiều thời gian để theo dõi.

  Tuy nhiên - và tôi đã học được điều này một cách khó khăn từ lâu - bạn không thể nói với mọi người rằng một vấn đề không liên quan . Nó rõ ràng có liên quan đến họ , nếu không họ sẽ không nói về nó. Công việc của bạn là khiến mọi người nói "có" càng nhiều càng tốt và đưa ra một rào cản như thế chỉ khiến bạn rơi vào lãnh thổ "không".

  Đây là một sự cân bằng tinh tế mà nhiều người có thể duy trì với "các hành động" - về cơ bản một hàng đợi chung của các cuộc thảo luận mà bạn đã hứa sẽ quay trở lại để đôi khi , thường được gắn thẻ với tên của những bên liên quan người nghĩ rằng nó là thực sự quan trọng. Đây không chỉ là vì mục đích ngoại giao - nó cũng là một công cụ có giá trị để giúp bạn nhớ những gì đã diễn ra trong các cuộc họp và nói chuyện với ai nếu bạn cần làm rõ sau này.

  Các nhà phân tích khác nhau xử lý điều này theo những cách khác nhau; một số như bảng trắng công khai hoặc nhật ký bảng lật, những người khác âm thầm gõ nó vào máy tính xách tay của họ và nhẹ nhàng phân biệt các chủ đề khác. Bất cứ điều gì bạn cảm thấy thoải mái với.

• Bạn cần một chương trình nghị sự

  Điều này có lẽ đúng với hầu hết mọi loại cuộc họp nhưng nó hoàn toàn đúng đối với các cuộc họp yêu cầu. Khi các cuộc thảo luận kéo dài, tâm trí của mọi người bắt đầu đi lang thang và họ bắt đầu tự hỏi khi nào bạn sẽ đi đến những điều họ thực sự quan tâm. Có một chương trình nghị sự cung cấp một số cấu trúc và cũng giúp bạn xác định, như đã đề cập ở trên, khi bạn cần trì hoãn một cuộc thảo luận đang lạc đề.

  Đừng đi bộ trong đó mà không có ý tưởng rõ ràng về chính xác những gì bạn muốn bao gồm và khi nào . Không có điều đó, bạn không có cách nào để đánh giá tiến bộ của chính mình và người dùng sẽ ghét bạn vì luôn chạy dài (giả sử họ không ghét bạn vì những lý do khác).

• Chế nhạo nó

  Nếu bạn sử dụng PowerPoint hoặc Visio làm công cụ mô phỏng, bạn sẽ gặp phải vấn đề về nó trông quá bóng bẩy . Nó gần như là một thung lũng kỳ lạ của giao diện người dùng; mọi người sẽ cảm thấy thoải mái với các bản vẽ khăn ăn (hoặc các bản vẽ do máy tính tạo ra trông giống như các bản vẽ khăn ăn, sử dụng một công cụ như Balsamiq hoặc Sketchflow ), vì họ biết đó không phải là thật - cùng lý do mọi người có thể xem các nhân vật hoạt hình. Nhưng càng bắt đầu trông giống như một giao diện người dùng thực sự, mọi người sẽ càng muốn chọn và xem xét nó, và họ sẽ dành nhiều thời gian hơn để tranh luận về những chi tiết cuối cùng không đáng kể.

  Vì vậy, chắc chắn hãy thử nghiệm để kiểm tra sự hiểu biết của bạn về các yêu cầu ( sau các giai đoạn phân tích ban đầu) - chúng là một cách tuyệt vời để nhận phản hồi rất nhanh và chi tiết - nhưng hãy giữ chúng lo-fi và đừng vội chế giễu cho đến khi bạn ' khá chắc chắn rằng bạn đang nhìn tận mắt với người dùng của mình.

  Hãy nhớ rằng một giả lập không phải là một sản phẩm có thể cung cấp , nó là một công cụ để hỗ trợ sự hiểu biết. Giống như bạn sẽ không bị giam cầm trong bản giả của mình khi thực hiện thiết kế giao diện người dùng, bạn không thể cho rằng thiết kế đó ổn chỉ đơn giản vì họ đã đưa ra giả thuyết của bạn. Tôi đã thấy các giả được sử dụng như một cái nạng, hoặc tệ hơn, một cái cớ để bỏ qua các yêu cầu hoàn toàn; hãy chắc chắn rằng bạn không làm điều đó Quay trở lại và biến giả đó thành một tập hợp các yêu cầu thực sự.

• Kiên nhẫn.

  Điều này rất khó để nhiều lập trình viên tin tưởng, nhưng đối với hầu hết các dự án không tầm thường, bạn không thể ngồi xuống một lần và đưa ra một thông số chức năng hoàn chỉnh. Tôi không chỉ nói về sự kiên nhẫn trong một cuộc họp; phân tích yêu cầu được lặp lại theo cùng một cách mã. Nhóm A nói điều gì đó và sau đó Nhóm B nói điều gì đó hoàn toàn trái ngược với những gì bạn nghe được từ Nhóm A. Sau đó, Nhóm A giải thích sự không nhất quán và hóa ra đó là điều mà Nhóm C quên đề cập. Lặp lại 500 lần và bạn có một cái gì đó gần giống với sự thật .

  Trừ khi bạn đang phát triển một số ứng dụng CRUD nhỏ (trong trường hợp nào tại sao phải bận tâm với các yêu cầu?) Thì đừng mong đợi nhận được mọi thứ bạn cần trong một cuộc họp, hoặc hai hoặc năm. Bạn sẽ lắng nghe rất nhiều, nói nhiều và lặp lại chính mình rất nhiều. Đó không phải là một điều khủng khiếp, nhớ bạn; đó là cơ hội để xây dựng mối quan hệ với những người chắc chắn sẽ đăng xuất trên sản phẩm của bạn.

• Đừng ngại thay đổi kỹ thuật của bạn hoặc ứng biến.

  Các khía cạnh khác nhau của một dự án thực sự có thể yêu cầu các kỹ thuật phân tích khác nhau. Trong một số trường hợp, UML cổ điển (Sơ đồ ca sử dụng / Hoạt động) hoạt động rất tốt. Trong các trường hợp khác, bạn có thể bắt đầu với các KSI kinh doanh, hoặc động não với sơ đồ tư duy, hoặc lao thẳng vào mockup bất chấp cảnh báo trước đó của tôi.

  Điểm mấu chốt là bạn cần phải tự hiểu tên miền và làm bài tập về nhà trước khi bạn lãng phí thời gian của bất kỳ ai khác. Nếu bạn biết rằng một bộ phận hoặc thành phần cụ thể chỉ có một trường hợp sử dụng, nhưng đó là một bộ phận cực kỳ phức tạp, thì hãy bỏ qua phân tích ca sử dụng và bắt đầu nói về quy trình công việc hoặc luồng dữ liệu. Nếu bạn không sử dụng cùng một công cụ cho mọi phần triển khai ứng dụng, vậy tại sao bạn lại sử dụng cùng một công cụ cho mọi phần của yêu cầu?

• Giữ tai của bạn xuống đất.

  Trong tất cả các gợi ý và lời khuyên tôi đã đọc để phân tích yêu cầu, đây có lẽ là một trong những điều thường xuyên bị bỏ qua nhất. Tôi thành thật nghĩ rằng tôi đã học được nhiều cách nghe lén và đôi khi làm hỏng các cuộc trò chuyện với nước mát hơn so với những cuộc họp theo lịch trình.

  Nếu bạn đã quen với việc làm việc một mình, hãy cố gắng tìm một điểm xung quanh nơi hành động để bạn có thể nghe thấy tiếng nói chuyện. Nếu bạn không thể, sau đó chỉ cần thực hiện các vòng thường xuyên, đến nhà bếp hoặc phòng tắm hoặc bất cứ nơi nào. Bạn sẽ tìm ra tất cả những điều thú vị về cách doanh nghiệp thực sự hoạt động từ việc lắng nghe những gì mọi người khoe khoang hoặc phàn nàn trong thời gian nghỉ giải lao và cà phê.

• Cuối cùng, đọc giữa các dòng .

  Một trong những sai lầm lớn nhất của tôi trong quá khứ là quá tập trung vào kết quả cuối cùng mà tôi đã không dành thời gian để thực sự nghe những gì mọi người đang nói . Đôi khi - rất nhiều thời gian - nghe có vẻ như mọi người đang nói về không có gì hoặc nói về một thủ tục nghe có vẻ vô nghĩa với bạn, nhưng nếu bạn thực sự tập trung vào những gì họ đang nói, bạn sẽ nhận ra rằng thực sự có một yêu cầu chôn trong đó - hoặc một số.

  Có vẻ bề ngoài và ngớ ngẩn như âm thanh của nó, Five Whys là một kỹ thuật thực sự hữu ích ở đây. Bất cứ khi nào bạn có phản ứng "đó là ngu ngốc" đầu gối (không phải là bạn sẽ nói to), hãy tự dừng lại và biến nó thành một câu hỏi: Tại sao? Tại sao thông tin này được gõ lại bốn lần, sau đó được in, sao chụp, quét, in lại, ghim vào bảng hạt, chụp bằng máy ảnh kỹ thuật số và cuối cùng được gửi qua email cho người quản lý bán hàng? Có là một lý do , và họ có thể không biết nó là gì, nhưng đó là công việc của bạn để tìm hiểu. Chúc may mắn với điều đó. ;)

Nếu bạn không thể lấy một cái gì đó từ họ, hãy viết một cái gì đó và phê duyệt nó. Những người phi kỹ thuật nói 'không, tôi không thích điều đó' dễ dàng hơn nhiều so với 'đây là cách bạn nên làm điều đó'.

Thường thì những gì họ muốn và những gì họ nói với bạn là hai điều rất khác nhau. Hãy dành chút thời gian để viết một bản nháp đầu tiên về thông số kỹ thuật với thông tin mà bạn hiện đang biết. Yêu cầu các bên liên quan đọc nó và phê duyệt nó. Khi họ đọc nó, nhiều khả năng họ sẽ thấy những điều họ không thích hoặc đồng ý. Nhận phản hồi của họ và sau đó sửa đổi.

Nếu có điều gì đó mà bạn có thể đi bằng cách này hay cách khác, hãy trực tuyến cả hai tùy chọn và nhờ người ra quyết định đưa ra lựa chọn. Đừng để họ một mình cho đến khi họ làm.

Đối với các nguyên mẫu, tạo ra các mô hình màn hình và giải thích cách mọi thứ sẽ hoạt động thay thế. Một lần nữa, nhìn thấy một cái gì đó giúp họ hình dung những gì đang xảy ra. Mang theo mock-up màn hình mới với bạn đến các cuộc họp và nhận câu trả lời.

Trước đây, tôi thực sự đã mở FireBug và thêm vào thay đổi mà khách hàng đã yêu cầu ngay trước mặt họ để họ có thể thấy nó trông như thế nào. Họ đã đưa ra phản hồi của họ, tôi chụp ảnh màn hình sau đó thực hiện các thay đổi. Họ thực sự thích có thể thấy sự thay đổi sẽ như thế nào và tôi thích nó vì nó rất nhanh và tôi đã nhận được câu trả lời của mình trong cuộc họp đó ... không phải là lần tiếp theo.

Để họ nói nhiều hơn về doanh nghiệp của họ và ít hơn về các ứng dụng. Tìm hiểu vấn đề thực sự là gì: báo cáo cuối tháng mất quá nhiều thời gian, lỗi nhập dữ liệu, chúng đã vượt quá ứng dụng hiện tại của chúng, sự phát triển của công ty đang vượt khỏi tầm kiểm soát.

Tôi đoán những cuộc họp này là với những người thực hiện mua hàng chứ không phải những người thực sự sẽ làm công việc liên quan đến ứng dụng. Hỏi xem bạn có thể gặp một vài người trong số họ không. Họ có thể chỉ cho bạn cách mọi thứ thực sự được thực hiện. Hãy chắc chắn rằng bạn đang giao dịch với những khách hàng đã dự trù ngân sách thời gian cũng như chi phí của họ.

Xem họ có bất kỳ báo cáo nào họ đang sử dụng hoặc muốn sử dụng không. Rõ ràng bạn không thể tạo báo cáo nếu bạn không thu thập dữ liệu đúng cách. Họ phải làm một cái gì đó trừ khi đây là một ngành kinh doanh mà họ chưa bắt đầu.

Nhiều người có những quan niệm chung rằng bạn là lập trình viên, vì vậy bạn biết cách xây dựng tất cả các chương trình. Các trang web thương mại điện tử đều giống nhau, phải không?

Khởi đầu nhỏ. Thật không may, cho đến khi bạn nhận được một cái gì đó trước mặt họ, quá trình chỉ không đăng ký. Nếu bạn không có gì để đi, thì chỉ cần giả nó.

Rất nhiều điều này phải làm với các kỹ năng giao tiếp chung và cách bạn giao tiếp với khách hàng ngay từ đầu. Ngoài ra, tôi không thể nói nhiều về điều đó, ngoài ra - hãy đảm bảo rằng bạn giải thích quy trình như một quá trình tương tác, nơi bạn cũng mong đợi phản hồi và nỗ lực từ phía khách hàng.

Cụ thể cho kịch bản bạn đã mô tả, đây là một số lời khuyên khác: Bắt đầu bằng cách mô tả những gì bạn sẽ thấy hữu ích và cung cấp phương tiện để mô tả thông tin theo các thuật ngữ không yêu cầu chuyên môn kỹ thuật hoặc bí quyết:

• Câu chuyện của người dùng / trường hợp sử dụng Yêu cầu mô tả chi tiết về những gì người dùng đang mong đợi, thông tin họ cần để làm điều đó và những gì bạn nên và có thể mong đợi người dùng tự nhập. Khi bạn có thông tin này, hãy cùng họ tìm hiểu thông tin và đảm bảo rằng mọi thứ đều được bao phủ bởi các câu chuyện - không nên có bất cứ điều gì sẽ đi vào ứng dụng, nơi bạn không có câu chuyện về những gì người dùng sẽ làm ở đó.

• Thuyết minh thuyết phục Điều gì quan trọng hơn để giành được khách hàng? Những phần nào của chương trình hoặc chức năng cần phải nổi bật, và phải được đánh bóng hoàn toàn? Bạn có thể cung cấp cho tôi bản demo mockup, sử dụng bài đăng ghi chú hoặc hộp các tông hoặc các bản dựng khác mà bạn muốn làm việc không?

• Thông tin về thị trường / cạnh tranh Đối với mỗi câu chuyện của người dùng, chúng ta đang làm gì tương tự với đối thủ cạnh tranh? Khác nhau? Câu chuyện nào mà các đối thủ của chúng ta kể, và chúng ta đang cố gắng sao chép / mô phỏng / cải thiện / đổi mới / có mục đích khác nhau?

• Câu hỏi mở Điều gì, trong các yêu cầu và thiết kế, là thông tin mà bạn chắc chắn và thử nghiệm là gì? Chúng ta sẽ thử những lựa chọn thay thế ở đâu để xem cái nào hoạt động? Nếu bạn đang xem xét nhiều lựa chọn thay thế và bạn chỉ nói với chúng tôi một lựa chọn, những cái khác bạn đang xem xét là gì?

Sau đó, rút ​​ra một số ranh giới:

• Xin đừng đặt giới hạn kỹ thuật cho tôi . Một người kinh doanh không nên nói với bạn "sử dụng windows vì nó tốt hơn linux". Tuy nhiên, họ có thể cung cấp hướng dẫn dọc theo dòng chữ "tất cả thị trường mục tiêu của chúng tôi sử dụng cửa sổ, ứng dụng của chúng tôi sẽ phải chạy trên cửa sổ để thành công"

• Đừng lo lắng về thiết kế Đặc biệt nếu bạn giao dịch với những người bán hàng hoặc tiếp thị, họ sẽ có xu hướng sa lầy vào các vấn đề thiết kế. Một lần nữa, thu hẹp phạm vi thông tin vào những gì họ chuyên về - "màu xanh ở đây đẹp hơn" có lẽ không phù hợp. "Đối thủ của chúng tôi đang sử dụng một chủ đề màu xanh lam, và đã có từ những năm 80, đối với các phần của chương trình mà chúng tôi không đổi mới, chúng tôi nên sử dụng sơ đồ màu xanh để truyền đạt rằng chúng tôi không mới", có lẽ là phù hợp. "Tên phải ở trên cùng của màn hình" có lẽ không phù hợp, nhưng "thông tin quan trọng nhất trên trang này là tên người dùng và số dư tài khoản ngân hàng", có lẽ là như vậy. Hãy chắc chắn rằng một nhà thiết kế có liên quan đến việc dịch các yêu cầu này sang UI.

• Viết các quyết định xuống Tốt nhất là xây dựng chúng thành các hợp đồng hoặc các cam kết khác mà bạn thực hiện. Tuy nhiên, hãy nhớ rằng một quyết định mà khách hàng không hiểu, không xứng đáng với bài báo được viết. Một khách hàng đăng xuất trên "ứng dụng sẽ chạy trên cổng 1521" không có giá trị như khách hàng đăng nhập "ứng dụng sẽ chạy trên một cổng tùy chỉnh, có thể định cấu hình, có thể yêu cầu cấu hình đặc biệt cho tường lửa và bảo mật khi được triển khai "

Từ quan điểm của bạn, để khuyến khích quá trình tiếp tục:

• Cung cấp phản hồi ở cùng mức độ trừu tượng Điều này nằm trên bảng, ví dụ, đối với các đơn vị - nếu khách hàng đang nói về khối lượng người dùng hàng tháng, đừng phản hồi trong băng thông rộng. Hoặc, đối với các trường hợp sử dụng - mô tả chức năng theo các trường hợp sử dụng đang hoạt động, thay vì các mô-đun hoặc sửa lỗi hoặc tính năng.

• Cung cấp liên lạc có ý nghĩa Cụm từ các câu hỏi bạn có và thông tin bổ sung bạn đã phát hiện hoặc đang tìm kiếm, về mặt thông tin được cung cấp cho bạn. "Chúng tôi đang đi với linux" có lẽ là phản hồi bằng văn bản kém, trong khi "các thử nghiệm của chúng tôi cho thấy ứng dụng chạy mượt hơn khi được lưu trữ trên máy linux và truy cập bằng IE trên windows" có thể phù hợp hơn.

• Lặp lại nhanh chóng Để giữ khách hàng tham gia, cung cấp các cập nhật và lặp lại nhanh chóng, có ý nghĩa. Thông số kỹ thuật và thông tin không có sẵn hoặc dễ dàng có được khi quá trình bắt đầu có thể mất rất nhiều nỗ lực từ khách hàng của bạn, người có thể, trả tiền cho bạn, trong khi bạn không trả tiền cho họ cho bất kỳ công việc nào của họ. Làm cho khách hàng được tham gia và đầu tư vào quy trình có thể giúp đỡ khi công việc kết thúc là điều họ phải dành thời gian và công sức.

Khách hàng của bạn, những người kinh doanh, có thể có một số vấn đề, mong muốn một số giải pháp kỹ thuật, nhưng có ít ý tưởng về cách giải pháp có thể hoạt động, và do đó có rất ít ý tưởng về cách xác định bất kỳ giải pháp tiềm năng nào. Nếu vậy, vai trò còn thiếu là của các nhà phân tích giải pháp kinh doanh, người có thể nghiên cứu khách hàng, vấn đề của họ, quy trình làm việc của họ, v.v. và làm thế nào bất kỳ giải pháp nào có thể phù hợp với quy trình, văn hóa của công ty, v.v. giải pháp cụ thể có thể khả thi để thực hiện kịp thời, theo ngân sách, v.v ... Đây có thể là một vai trò mang tính liên ngành cao, đòi hỏi một số kiến ​​thức về cả thực tiễn kinh doanh (luật, kế toán, hậu cần, v.v.), tâm lý người dùng, cũng như công nghệ phần mềm.

Có vẻ như bạn muốn buộc khách hàng trở thành nhà phân tích giải pháp kinh doanh của riêng họ. Đây có thể không phải là một vai trò mà họ có đủ chuyên môn để đảm bảo một thông số hợp lý. Và có vẻ như bạn cũng không muốn nhận vai trò này. Nếu cả bạn và khách hàng của bạn không có chuyên môn để hoàn thành vai trò này, bạn có thể không có tất cả những người cần thiết cho một dự án thành công.

Đôi khi, một loạt các nguyên mẫu nhanh chóng mà khách hàng có thể chơi cùng có thể là cách duy nhất để khám phá và hội tụ thử nghiệm một số giải pháp có thể sử dụng cho nhu cầu của khách hàng (lên tiếng và không được truyền đạt). Điều này có thể hoặc có thể không phù hợp với bất kỳ loại hợp đồng không mở nào.

THÊM: Nếu bạn cố gắng buộc tài liệu yêu cầu ra khỏi những khách hàng không có chuyên môn cần thiết, đây có thể là một lá cờ đỏ khổng lồ cho thấy thảm họa sắp xảy ra.

Đừng hỏi các yêu cầu về UI hoặc Data, hãy yêu cầu các chức năng của Function.

Hỏi họ về những gì họ muốn ứng dụng làm. Cho họ biết cách họ muốn sử dụng ứng dụng. Để lại chi tiết như UI, Data, v.v.

Tôi đã phát hiện ra rằng người dùng thường không biết họ muốn gì về UI hoặc Dữ liệu, nhưng họ biết họ muốn gì về chức năng. Ví dụ: họ sẽ nói với tôi "Tôi muốn đăng nhập và xem tất cả Thông tin khách hàng." Đừng quan tâm đến màn hình sẽ trông như thế nào, hoặc dữ liệu nào họ muốn, chỉ cần lấy chức năng từ chúng.

Khi bạn đã có điều đó, hãy thực hiện một mockup nhanh chóng (tôi thích Balsamiq ). Chỉ cần giả định UI / Dữ liệu sẽ là gì và không dành nhiều thời gian cho nó. Sau đó lấy mockup đó lại cho Khách hàng. Từ đó, họ có thể cho bạn biết "chúng tôi không cần các trường này" hoặc "Chúng tôi thực sự muốn có một danh sách số điện thoại, không chỉ một" hay "đây phải là danh sách thả xuống, không phải hộp danh sách".

Khi bạn có điểm bắt đầu, việc xác định Dữ liệu và Giao diện người dùng sẽ dễ dàng hơn nhiều và tôi thấy việc xác định Chức năng là điểm khởi đầu tốt nhất.

Tôi đề nghị bạn cố gắng tập trung họ vào quá trình kinh doanh trước hết. Yêu cầu họ xác định, trong tài liệu hoặc thảo luận về cách họ hiện đang làm bất kỳ nhiệm vụ nào sẽ được xử lý bởi phần mềm của bạn. Sau đó tập trung vào những phần của quy trình họ muốn thấy đã thay đổi (lý do họ muốn phần mềm của bạn). Sử dụng đó làm điểm bắt đầu để thảo luận về những phần khác của quy trình có thể được cải thiện hoặc thậm chí loại bỏ hoàn toàn, bằng cách sử dụng phần mềm của bạn.

Nếu khách hàng của bạn không quen cung cấp các yêu cầu phần mềm, nhóm của bạn nên phác thảo các yêu cầu cho họ. Dự kiến ​​sẽ trải qua nhiều lần chỉnh sửa, nhưng ít nhất bạn nên cung cấp cho họ một tài liệu ban đầu để giúp truyền đạt những gì bạn đang tìm kiếm.

Khi bạn đã hiểu rõ về các yêu cầu chức năng của quy trình kết quả cuối cùng dự kiến ​​sẽ kết hợp với phần mềm của bạn, bạn có thể bắt đầu phác thảo các mô hình giao diện. Nếu bạn muốn cho họ đâm đầu vào nó trước tiên, bạn có thể, nhưng thường thì tốt hơn hết là bạn nên cung cấp những ý tưởng ban đầu và để chúng điều chỉnh chúng xung quanh. Bạn không cần mã chức năng cho việc này. Ảnh chụp màn hình của các UI đang được phát triển, các biểu diễn HTML của bố cục bằng văn bản điền vào tĩnh hoặc thậm chí các bản vẽ (nếu bạn có một nghệ sĩ đàng hoàng trong đội ngũ nhân viên) có thể được sử dụng cho các cuộc thảo luận UI ban đầu.

Khi bạn đã trải qua một vài lần chỉnh sửa và mọi người đồng ý với những gì được trình bày, hãy nhận sự chấp thuận bằng văn bản của khách hàng! Cho dù họ chống cự bao nhiêu, bước này rất quan trọng. Bạn có thể cần phải trấn an họ rằng việc đăng xuất theo yêu cầu không có nghĩa là họ không thể có thêm bất kỳ thông tin nào vào dự án (tùy thuộc vào bản chất mối quan hệ của bạn với khách hàng), trong trường hợp đó bạn nên phác thảo cách sửa đổi các yêu cầu sẽ được xử lý (ví dụ: để xem xét và phê duyệt, được đẩy ra phiên bản tiếp theo, được định giá riêng như một bản nâng cao, v.v.).

Tôi sẽ nói với họ bạn sẽ phát triển tính năng chương trình theo tính năng. Cho đến một cuộc họp tiếp theo, giả sử trong 1-2 tuần bạn sẽ làm việc X số tính năng. Điều này có thể là 1, 2, 3 hoặc nhiều hơn.

Nói rằng bạn sẽ bắt đầu bằng cách phát triển fonctionality quan trọng nhất đầu tiên. Bạn cần bắt đầu với các tính năng cốt lõi. Giả sử bạn đang tạo một máy rút tiền (để tranh luận). Nói với họ, ok (đầu tiên (hoặc tiếp theo) trong danh sách các tính năng quan trọng nhất là yêu cầu ngày sinh của người dùng làm xác nhận khi thực hiện rút tiền lớn (thay thế cho một fonctionnality trong dự án của bạn mà bạn biết không phải là một trong những tính năng cốt lõi chính sẽ được thực hiện tiếp theo).

Khẳng định ngây thơ này nên gợi ra phản ứng từ khách hàng. Khi nó hỏi họ sẽ làm gì tiếp theo? Tính năng quan trọng nhất chưa được thực hiện trong dự án là gì và tốt hơn tính năng bạn đã đề cập.

Sử dụng lại ví dụ trước, khách hàng có thể cho bạn biết đó là xác thực thẻ của người dùng hoặc gửi tiền, v.v. Sau đó yêu cầu họ xác định nó cho bạn. Đừng ngại hỏi nhiều câu hỏi, thậm chí là những câu hỏi ngây thơ nếu cần.

Sau khi bạn đã thảo luận điều này với khách hàng, bạn sẽ có một số yêu cầu cho một phần của tính giả tưởng này. Bạn có thể định nghĩa nhiều hơn một phần của fonctionality nhưng tôi sẽ giữ số lượng rất thấp.

Trong 1-2 tuần gặp lại khách hàng để trình bày cho họ những gì bạn đã làm và nhận đầu vào của họ về nó. Trình bày nó cho khách hàng và nhận đầu vào của họ nếu có bất cứ điều gì cần phải thay đổi hoặc thêm vào.

Sau đó lặp lại bài tập trước cho các tính năng tiếp theo. Tiếp tục với quy trình này theo cách lặp đi lặp lại cho phần còn lại của dự án, đảm bảo bạn giữ liên lạc với khách hàng và có cuộc họp định kỳ để hiển thị công việc của bạn và lên kế hoạch cho những gì sẽ được thực hiện tiếp theo (luôn luôn ở trong các phần nhỏ).

Theo kinh nghiệm của tôi, bạn đang nói về kỹ thuật và họ không quan tâm đến điều đó; họ cũng không muốn cam kết làm bất cứ điều gì (đặc biệt bằng văn bản) và họ không thực sự muốn làm bất kỳ công việc nào, mặc dù điều đó không đặc biệt đối với các loại hình kinh doanh - không ai muốn thực hiện một loạt công việc trong một miền mà họ không biết và không quan tâm để biết. Đó là công việc của bạn (trong tâm trí của họ).

Những gì tôi làm là thế này: nói chuyện với họ về những gì họ muốn, bằng ngôn ngữ miền của họ. Họ sẽ không thể hoặc sẵn sàng chính xác theo cách bạn hy vọng (trường hợp sử dụng, thiết kế theo hợp đồng, v.v.) nhưng bạn có thể chính xác trong việc chuyển loại danh sách desiderata mơ hồ và táo bạo của họ sang thiết kế thực tế, và , do đó, một tài liệu thiết kế. Nếu họ sẽ dành cho bạn thời gian để làm việc này một cách chính thức, thì càng nhiều càng tốt. Nếu không, hãy tạo một ngẫu hứng, không chính thức mà bạn có thể lặp lại.

Đây không phải là một câu trả lời siêu hạnh phúc, nhưng tôi đã thấy cuộc sống trở nên dễ dàng hơn khi tôi ngừng cố gắng để khiến khách hàng (hoặc bất cứ ai, thực sự) bước vào vũ trụ của tôi và nói ngôn ngữ của tôi. Mặc dù tôi tiếp tục hỏi những câu hỏi tương tự lặp đi lặp lại khi tôi liên quan đến tên miền và các yêu cầu (thường chỉ được khách hàng hiểu một cách mơ hồ), điều ngược lại là các cuộc thảo luận không gây khó chịu. Trên thực tế, các mối quan hệ với khách hàng có xu hướng mạnh mẽ hơn, tôi cho rằng vì mọi người thích nói về những gì họ biết, và bạn sẽ hiểu POV của họ tròn hơn bạn có thể nếu tiếp cận một cách tiếp cận nghiêm ngặt hơn.

Không có người quản lý biết điều gì đó về lập trình, tôi chưa bao giờ có một chút thành công nào trong việc này. Thay vào đó, cách tiếp cận duy nhất tôi thấy có hiệu quả là quan sát những gì đang thực sự xảy ra.

Tôi đoán các lập trình viên có khả năng tốt hơn để hình dung ra một chương trình sẽ như thế nào trước khi nó được xây dựng. Tạo mẫu bằng giấy có thể là một kỹ thuật hiệu quả để khắc phục điều này. Nguyên mẫu giấy tương đối "rẻ" để xây dựng. Bằng cách dẫn dắt khách hàng của bạn thông qua một nguyên mẫu giấy đơn giản, bạn thể hiện nhu cầu suy nghĩ "theo cách tập trung cần thiết để thu thập các yêu cầu thực sự." Và nó đưa ra một cách cụ thể để tập trung: thực sự đang cố gắng sử dụng ứng dụng trong đầu bạn!

Ngoài ra, bạn có thể lặp lại rất nhanh từ dự đoán tốt nhất của bạn về những gì khách hàng muốn cho ứng dụng mà khách hàng thực sự muốn, nhưng gặp khó khăn trong việc truyền đạt. Việc xem xét một nguyên mẫu sẽ dễ dàng hơn và quyết định tại sao nó không phù hợp với ứng dụng lý tưởng trong đầu bạn hơn là liệt kê tất cả các yêu cầu của ứng dụng đó.

Tôi đã làm việc trên một trang web nơi các đối tác khác định hướng kinh doanh nhiều hơn. Tôi tiếp tục yêu cầu các yêu cầu cụ thể theo nhiều cách khác nhau. Câu trả lời của họ về cơ bản là "Bạn là người máy tính, chúng tôi hy vọng bạn tìm ra thứ này. Chúng tôi thích làm công việc kinh doanh hơn." Họ không quan tâm đến các chi tiết cụ thể ... cho đến khi phiên bản đầu tiên được phát hành! Họ đã nhiệt tình hơn nhiều về các yêu cầu sau khi phát hành, đưa ra tất cả các loại phản hồi sẽ giúp tôi tiết kiệm rất nhiều thời gian trước khi tôi yêu cầu ban đầu.

Vì vậy, tôi quyết định lặp đi lặp lại là chìa khóa: xây dựng phiên bản khả thi tối thiểu và cải thiện nó dựa trên phản hồi. Nếu các yêu cầu quá mơ hồ và chung chung, hãy đưa ra quyết định dựa trên "Cách thực hiện đơn giản nhất, nhanh nhất là gì?" (chặn thiết kế / kiến ​​trúc hệ thống cơ bản). Đừng cân nhắc quá nhiều về các giả định dựa trên những gì bạn cho là "đúng". Nó sẽ chỉ lãng phí thời gian vì rất có thể quá trình suy nghĩ của bạn khác với khách hàng của bạn.

Ví dụ: khách hàng yêu cầu tính năng tải lên hình ảnh; sẽ không giải thích bất kỳ yêu cầu cụ thể hơn. Xây dựng nó một cách ngây thơ nhất có thể. Mặc dù bạn nghĩ đó là những gì khách hàng sẽ muốn, nhưng không thêm các tính năng cắt xén, thay đổi kích thước và thu nhỏ tự động. Hãy để khách hàng thấy phiên bản khả thi tối thiểu (mà bạn có thể phát triển nhanh hơn nhiều so với phiên bản không ngây thơ) và các yêu cầu sẽ bắt đầu chảy vào như "Đây là điều không đúng với phiên bản hiện tại." Ghi nhật ký từng yêu cầu mới này dưới dạng "lỗi". Bạn có thể ưu tiên những cái nào dễ nhất / có lợi nhất.

Thực tế đã xảy ra với tôi: Yêu cầu đăng ký mẫu với mã mời đặc biệt. Ý tưởng là tạo ra một quy trình đăng ký lan truyền trong đó mỗi người dùng mới nhận được một vài lời mời. Tôi đã dành rất nhiều thời gian để đảm bảo các mã là duy nhất và chỉ có thể được sử dụng một lần. Tôi cũng đã nỗ lực rất nhiều để làm cho quá trình trở nên không ma sát nhất có thể bằng cách làm cho các trường tên và họ cuối cùng là tùy chọn. Cuối cùng, các đối tác đã yêu cầu những thay đổi này: tên bắt buộc và tên cuối cùng, "mã" đăng ký hợp lệ nếu có bất cứ điều gì được đưa vào trường ... thở dài ~