Để người dùng có thể tự mình yêu cầu hoặc hướng dẫn họ theo?

Tôi chắc rằng mọi người đã trải nghiệm một cái gì đó như thế này. Bạn đi vào một cuộc họp với một khách hàng có một dự án. Họ không có / một vài yêu cầu trong đầu và sự hiểu biết mơ hồ về những gì họ muốn / cần. Tại thời điểm này, dường như có hai lựa chọn:

1) Nói với người dùng, "Ok, vì vậy tôi không thể xây dựng một cái gì đó cho bạn nếu bạn thậm chí không thể mô tả nó. Tại sao chúng ta không quay lại với nhau trong một vài tuần khi bạn biết bạn muốn gì".

2) Gặp gỡ người dùng một vài lần và giúp họ tìm ra những gì họ muốn bằng cách hướng dẫn họ thực hiện bằng phương pháp Socole tốt. "Bạn có cần theo dõi X không?", "Còn Y thì sao?", "Bạn có cần chức năng Z không?"

Với tùy chọn đầu tiên, bạn không bị mắc kẹt khi thực hiện công việc của người khác hoặc có được sức mạnh tâm linh, tuy nhiên, người dùng có thể không bao giờ cung cấp cho bạn thông số kỹ thuật mạch lạc, hoặc họ có thể mất thời gian khi thời hạn tiếp tục đến gần. Với lựa chọn thứ hai, bạn lãng phí rất nhiều thời gian để trở thành một nhà phân tích kinh doanh và phải nhồi nhét một loạt kiến ​​thức kinh doanh vào đầu mà bạn có thể sẽ không bao giờ sử dụng nữa, nhưng bạn sẽ có nhiều khả năng đưa ra một thông số kỹ thuật làm cho bất kỳ ý nghĩa.

Đối với tôi, đây là một trong những khía cạnh thách thức nhất của sự phát triển và tôi có cảm giác tôi không cô đơn trong tình cảm này. Theo kinh nghiệm của bạn, lựa chọn nào trong số này có xu hướng hoạt động tốt hơn?

Tôi phải thừa nhận rằng đôi khi tôi chọn tùy chọn 3)

3) Lắng nghe khách hàng những ý tưởng mơ hồ, nói về ý tưởng dành hàng tuần để giúp họ tìm ra chính xác những gì họ muốn ... vì vậy hãy tìm ra những gì họ cần, xây dựng và tái cấu trúc theo yêu cầu.

Điều này hoạt động, đặc biệt là cho các công việc nhỏ, bởi vì nó giúp tránh những tình huống mà khách hàng có ý tưởng tuyệt vời này trong đầu, điều này không thực tế trong thế giới thực.

Nó xảy ra với tôi mọi lúc; "Chắc chắn chúng ta có thể làm ..." là một cụm từ rất đáng sợ. Đặc biệt là những thứ được đề cập hầu như luôn là tiếng chuông, tiếng huýt sáo và lớp tính năng "đẹp để có". Họ hoàn toàn không hiểu điều đó trong tuyên bố "rõ ràng là một trình theo dõi lỗi, và sau đó ..." phần lớn các công việc tiềm năng nằm trong bốn từ đầu tiên.

Vì vậy, đôi khi thật tuyệt khi lấy tầm nhìn của khách hàng , áp dụng một lượng lớn các lập trình viên thông thường và xây dựng một cái gì đó phù hợp với nhu cầu của họ.

Về mặt câu hỏi ban đầu; Tôi thấy nó phụ thuộc rất nhiều vào bối cảnh. Nếu bị mắc kẹt với khách hàng (nghĩa là thông qua hợp đồng làm việc mà tôi bị ràng buộc hoặc không có công việc thay thế nào) thì # 2 là cách tiếp cận hợp lý nhất. Nếu không, có khả năng cao là trong một tuần bạn sẽ được giới thiệu một thông số tuyệt vời và chi tiết ... điều này hoàn toàn vô dụng đối với bạn với tư cách là một lập trình viên.

Nhiều vấn đề tương tự như đã đề cập ở trên (# 3) và một vấn đề khiến bạn phải làm # 2 bằng mọi cách.

Nếu bạn muốn chỉ là một lập trình viên, thì bạn hãy đợi cho đến khi người khác tìm ra những gì khách hàng cần và sau đó mã hóa nó

nếu bạn muốn trở thành một nhà phát triển , và đây là khách hàng của bạn , thì bạn nắm lấy tay khách hàng và nhẹ nhàng đưa họ đi qua khu rừng rậm rạp đáng sợ cho đến khi bạn cùng nhau tìm thấy đồng cỏ đầy hạnh phúc ở ngã tư của Wants and Nhu cầu.

ĐỊA CHỈ: quá trình này được gọi là "phân tích và thiết kế hệ thống" hay còn gọi là Tư vấn, và nó không bao giờ nên được thực hiện miễn phí

Lập trình sơ bộ về việc giải quyết các vấn đề của người dùng. Vì vậy, với tôi, nhận được nỗ lực và nỗi đau "thêm" để có được một giải pháp hiệu quả, thỏa đáng cho người dùng của chúng tôi hầu như luôn chiến thắng để tránh rắc rối "thêm" và cuối cùng không cung cấp bất cứ điều gì hữu ích.

(Tất nhiên, có những người dùng thực sự ngoài kia thực sự không biết họ muốn gì và không nỗ lực nào có thể đưa họ vào trạng thái mà họ có thể đưa ra bất kỳ quyết định có ý nghĩa nào. Nhưng tôi tin rằng trong hầu hết các trường hợp họ có một vấn đề thực sự, họ sẵn sàng bỏ ra công sức và tiền mặt để giải quyết vấn đề, và họ sẽ rất vui nếu chúng tôi có thể giúp họ gần hơn với giải pháp làm việc.)

Vì vậy, điểm mấu chốt là, trọng tâm của chúng tôi là giải quyết vấn đề của người dùng. Điều này đôi khi có thể yêu cầu hỏi một số câu hỏi được nhắm mục tiêu và cho họ thêm thời gian để tìm ra câu trả lời. Đôi khi nó yêu cầu lập biểu đồ miền với nhau, hợp tác chặt chẽ. Đôi khi nó đòi hỏi phải dành một chút thời gian để tạo ra các bản phác thảo / nguyên mẫu / mockup đơn giản, sau đó cho họ xem kết quả và hỏi "điều này có giống như những gì bạn đã nghĩ không?" (sau đó ném nguyên mẫu đi khi họ nói "thực ra, tôi đã suy nghĩ về một thứ hoàn toàn khác ..." và bắt đầu lại ... :-)

Kỹ năng thực sự là trong việc lựa chọn phương pháp phù hợp cho đúng thời điểm.

Cuối cùng nhưng không kém phần quan trọng, theo kinh nghiệm của tôi, các giải pháp tốt hầu như luôn đòi hỏi ít nhất một số kiến ​​thức về miền từ phần của nhà phát triển. Không có điều này, bạn không có ngôn ngữ chung thực sự với người dùng, do đó không có gì đảm bảo rằng những gì bạn cung cấp sẽ thực sự hữu ích cho họ. Người dùng thường không có nhiều đầu mối về công nghệ, vì vậy không biết điều gì là không thể và điều gì là chi phí cho các phương pháp / tính năng khác nhau. Vì chúng ta không thể mong đợi họ học công nghệ một cách hợp lý để có đủ chi tiết, chúng ta nên thực hiện bước bổ sung đó từ cuối cây cầu.

Đây có thể được coi là nỗ lực "thêm" mà không phải trả lại - tuy nhiên, tôi thích xem đó là đầu tư, vì hai lý do:

• nó giúp tôi cung cấp các giải pháp tốt, về lâu dài làm tăng giá trị thị trường của tôi với tư cách là nhà phát triển và
• các miền khác nhau không hoàn toàn khác biệt, vì vậy ít nhất một phần kiến ​​thức miền đó có thể được sử dụng lại trong các hợp đồng biểu diễn trong tương lai.

Là một nhà phát triển phần mềm, một phần nhiệm vụ của bạn là có được sự hiểu biết đầy đủ về miền mà phần mềm sẽ được sử dụng. Do đó, là một phần của giai đoạn non trẻ của một dự án là vô cùng quý giá (về thời gian và trải nghiệm của khách hàng) . Vâng, điều này có nghĩa là thực hiện một phân tích kỹ lưỡng và yêu cầu. Đây là thời điểm hoàn hảo để kết hợp người dùng mục tiêu, phỏng vấn họ hoặc đi bộ xung quanh vị trí nơi phần mềm của bạn sẽ được sử dụng.

Nhưng, để có được kỹ năng này gần như là một hình thức nghệ thuật, đặc biệt là khi miền không được kết nối với một chuyên ngành kỹ thuật. Các câu hỏi rõ ràng của bạn có thể gây khó chịu cho khách hàng, sự hiện diện tại chỗ của bạn có thể không muốn, sự thiếu hiểu biết về cấu trúc xã hội của đối tượng mục tiêu của bạn có thể phá vỡ các kết nối vẫn còn mong manh.

Không hiểu được sự phức tạp của giai đoạn này thường dẫn đến sự thất vọng, cả với các nhà phát triển phần mềm, như với khách hàng. Chúng tôi muốn vượt qua giai đoạn này nhanh hơn bao giờ hết hoặc hoàn toàn loại bỏ nó. Kết quả thường là thảm họa: sau khi bắt đầu vội vã, trong quá trình phát triển, các cổ phần thành công ngày càng cao hơn và việc quay trở lại bảng vẽ trở nên khó khăn hơn bao giờ hết. Khi hệ thống cuối cùng đã hoàn thành và hàng triệu người đã bỏ ra, cả khách hàng và công ty kỹ thuật đều không sẵn sàng thừa nhận sự thất bại của mình, dẫn đến việc giới thiệu một hệ thống bị lỗi.

Một cách khác là để cho một nhà phân tích kinh doanh làm công việc cho bạn. Điều này có thể hợp lý đối với một số sản phẩm và nhà phân tích thường có thể là trung gian, nhưng nó sẽ chỉ tạo ra nhiều kênh liên lạc hơn (và do đó có khả năng xảy ra lỗi cao hơn).

Trong mọi trường hợp: viết lại một đoạn mã không bao giờ vượt quá việc viết lại một đoạn yêu cầu.

ps có thể bạn nghĩ rằng tôi ủng hộ phương pháp thác nước. Tôi không phải là người tin tưởng vào 'thiết kế lớn lên phía trước', nhưng tôi tin rằng nỗ lực phân tích tên miền phải tương xứng với nỗ lực triển khai. Người ta có thể thực hiện nhiều chu kỳ (nguyên mẫu, phát hành ứng cử viên, v.v.).

Chắc chắn tùy chọn 2 trừ khi người dùng của bạn là nhà phát triển (thậm chí sau đó có thể cần tùy chọn 2).

Rất nhiều vòng đời phát triển phần mềm tập trung vào thu thập yêu cầu. Hầu hết người dùng không chỉ biết những gì họ muốn, họ cũng không biết những gì có thể, vì vậy làm việc với người dùng để hiểu những gì người dùng cần là một nhiệm vụ phát triển phần mềm quan trọng.

Tôi nghĩ bạn cần phải đi với cả hai lựa chọn. Hãy để họ đi và quyết định những gì họ muốn. Sau đó, khi có một ý tưởng cụ thể để sử dụng làm điểm khởi đầu, hãy hướng dẫn họ giúp tinh chỉnh các yêu cầu đối với một cái gì đó hữu ích.

Bạn không muốn nhảy vào Lựa chọn số 2 khi họ hầu như không thể nói rõ những gì họ muốn vì nó sẽ khiến toàn bộ quá trình chậm lại và bực bội hơn (trừ khi họ đã có một ý tưởng rất rõ ràng về những gì họ muốn khi đến với bạn, nhưng theo kinh nghiệm của tôi điều này là rất hiếm). Làm cho họ có được ý tưởng của họ với nhau. Yêu cầu họ viết một cái gì đó ra giấy, mô tả những gì họ muốn về các hệ thống hiện có nếu có thể (ví dụ: "chúng tôi muốn có một trang web như blahblah.com nhưng với những khác biệt này ... chúng tôi muốn có một công cụ thực hiện Nhiệm vụ A như Sản phẩm X , nhưng UI cũng phải thực hiện Nhiệm vụ B ... "). Sau đó, đây là thời điểm tốt để bắt đầu tinh chỉnh những gì họ muốn thành những yêu cầu rất cụ thể mà bạn có thể sử dụng để xây dựng hệ thống.

Nói chung, khách hàng sẽ đến với bạn biết chính xác những gì họ nghĩ rằng họ cần. Thật không may, đây là những gì họ sẽ nói với bạn, thay vì mô tả (các) vấn đề dẫn đến giải pháp mà họ nghĩ bạn sẽ cung cấp.

Để thiết kế một cái gì đó sẽ đáp ứng nhu cầu của họ, bạn phải xác định những nhu cầu đó, và để làm điều đó, ai đó sẽ phải giữ khách hàng và rút ra những nhu cầu đó. Nếu không ai khác có thể làm điều đó, thì bạn phải. (Nếu ai đó nghĩ rằng họ có thể, bạn có thể phải ngồi lại với họ và rút ra những nhu cầu thực sự sau này ...)

Với tùy chọn 2, qua một số cuộc họp, bạn có thể hy vọng huấn luyện khách hàng chia sẻ vấn đề với bạn hơn là giải pháp. (Ngay cả khi khách hàng có khả năng kỹ thuật - ví dụ: họ không có sẵn để thực hiện công việc này và cần bạn thực hiện thay thế - họ vẫn có thể tập trung vào một triển khai không lý tưởng cho khách hàng cuối.) cho dù bạn sử dụng quy trình phát triển nào đi chăng nữa, bạn vẫn cần quay lại vài lần cho đến khi họ có thể trả lời các câu hỏi theo cách xác định thông số kỹ thuật cho bạn.

Hãy nhớ rằng, bạn muốn bắt lỗi càng sớm trong chu kỳ phát triển càng tốt. Nếu bạn có thể bắt chúng trong khi yêu cầu thay vì trong quá trình mã hóa hoặc thử nghiệm, bạn sẽ tiết kiệm cho mình rất nhiều thời gian.

Lựa chọn 1 là một cách tuyệt vời để tránh làm một số công việc. Tôi đã sử dụng nó khi tôi tin rằng công việc là không cần thiết hoặc tôi có nhiều việc quan trọng hơn để làm.

Đầu tiên, người dùng không biết những gì máy tính có thể làm. Hầu hết chúng ta đã dành nhiều năm để học cách hiểu máy tính và tính toán, và những gì rõ ràng đối với chúng ta có thể không dễ hiểu đối với những người đã dành những năm đó để học những thứ khác.

Thứ hai, người dùng không nhất thiết phải biết họ cần gì và thường không biết họ muốn gì, theo bất kỳ ý nghĩa hành động nào.

Để cho một sự tương tự, khi tôi mua ngôi nhà hiện tại của mình, một nhà thiết kế nội thất đã chọn màu tường cho các phòng ở tầng chính (đầu tiên ở Mỹ, mặt đất ở Anh). Tôi sẽ không bao giờ chọn những màu sắc đó cho mình. Tôi muốn một ngôi nhà trông đẹp, và có nó. Nếu nhà thiết kế đã lắng nghe tôi và đưa cho tôi bất cứ điều gì tôi có thể nói rõ, thì nó cũng sẽ không xuất hiện.

Cách duy nhất để cung cấp cho người dùng thứ gì đó làm những gì họ cần theo cách họ thích là tự làm việc với họ.