Một phân tích có nên là bất khả tri về công nghệ? [đóng cửa]

Tôi đã có một cuộc tranh cãi ngày hôm qua với một trong những đồng nghiệp của tôi. Anh ấy (một nhà phân tích kinh doanh, trước đây là một lập trình viên) nghĩ rằng anh ấy nên nhận thức được công nghệ được sử dụng để thực hiện hệ thống, vì vậy anh ấy có thể đưa ra quyết định thiết kế tốt hơn. Theo ý kiến ​​của tôi (tôi là một lập trình viên), một phân tích không nên được kết hợp theo bất kỳ cách nào với công nghệ và tôi tin rằng một nhà phân tích giỏi có thể tạo ra một thiết kế tuyệt vời mà không phải lo lắng về các chi tiết thực hiện.

Tôi có đúng khi nghĩ như vậy không? Có bất kỳ lý do tại sao một nhà phân tích kinh doanh sẽ cần phải biết công nghệ được sử dụng để thực hiện hệ thống?

EDIT: Tôi tin rằng tôi đã sử dụng thuật ngữ sai khi nói business analyst. Có lẽ tôi có nghĩa là kiến ​​trúc sư, hoặc nhà phân tích hệ thống. Tôi không quen với những điều khoản này. Tôi có nghĩa là một cái gì đó như kiến ​​trúc sư hoặc phân tích hệ thống nếu bạn thích.

Cảm ơn tất cả mọi người vì câu trả lời tuyệt vời của bạn! Tôi chưa có nhiều kinh nghiệm và tôi rất vui vì bạn đã mở mắt về điều này.

Chắc chắn có những trường hợp hợp lý để một nhà phân tích kinh doanh hiểu công nghệ ít nhất cũng đủ để hiểu được ý nghĩa của việc đặt câu hỏi cho người dùng doanh nghiệp về tầm quan trọng của một tính năng cụ thể. Ví dụ: nếu doanh nghiệp đã quen với hành vi của ứng dụng khách béo trong khi ứng dụng mới sẽ dựa trên web, có thể sẽ có nhiều "yêu cầu" không đáng kể ở một khách hàng béo nhưng tương đối khó với một ứng dụng dựa trên web. Nếu nhà phân tích kinh doanh hiểu liệu một yêu cầu từ doanh nghiệp sẽ là tầm thường đối với nhóm phát triển hay liệu nó sẽ liên quan đến 20 giờ phát triển AJAX,

Đối với bất kỳ dự án nào, có khả năng một số lượng lớn các yêu cầu trong thực tế sẽ thỏa mãn doanh nghiệp bằng cách thực hiện các loại đánh đổi khác nhau. Nhà phân tích kinh doanh càng hiểu về những gì họ đang thực hiện, họ càng có khả năng đưa ra một loạt các yêu cầu nhằm tối đa hóa lợi ích cho doanh nghiệp trong khi giảm thiểu chi phí.

Đã làm việc cả hai mặt của vấn đề này, tôi phải đồng ý với Nhà phân tích. Tôi đã thấy một số thiết kế nghèo nàn ngoạn mục do thiếu hiểu biết về khả năng của công nghệ. Trong một số trường hợp, nó là kết quả của việc quảng cáo tiếp thị là sự thật. Nói chung, vấn đề đã tạo ra các thông số kỹ thuật không phù hợp với khả năng kỹ thuật.

Nhà phân tích nên xác định những gì cần phải làm, khi nào và bởi ai. Họ nên biết tại sao nó đang được thực hiện. Ưu tiên phát triển nên phụ thuộc nhiều vào Why hơn các yếu tố khác. Nhóm thiết kế và phát triển cần xử lý như thế nào. Để phát triển các hệ thống hiệu quả về chi phí, các nhà phân tích cần chỉ định những gì cần được thực hiện theo các thuật ngữ không vượt qua ranh giới của công nghệ có sẵn.

Đẩy các ranh giới có thể làm tăng chi phí theo một số cách, nhưng trong một số trường hợp có thể có lợi nhuận đáng kể. Một số yếu tố chi phí là:

• Thử nghiệm có thể được yêu cầu để phát triển một giải pháp làm việc;
• Nhân viên mới hoặc chuyên gia tư vấn có kiến ​​thức chuyên ngành có thể cần phải có được;
• Đào tạo về công nghệ mới có thể cần thiết;
• Phát triển có xu hướng chậm hơn và tỷ lệ lỗi cao hơn; và
• Những nỗ lực thêm có thể trì hoãn các giải pháp đơn giản hơn có giá trị ngay lập tức hơn.

Nếu công nghệ sẽ được sử dụng được biết đến thì nên xem xét bởi các nhà phân tích khi tạo ra thiết kế. Các công nghệ khác nhau làm những việc khác nhau và một thiết kế không tính đến những khác biệt đó sẽ có vấn đề.

Tuy nhiên, các nhà phân tích kinh doanh không nên quan tâm đến việc sử dụng công nghệ nào, công việc của họ là thu thập các quy tắc kinh doanh và làm cho chúng trở nên dễ hiểu đối với đội ngũ kỹ thuật. Các nhà phân tích / kiến ​​trúc sư / nhà thiết kế hệ thống hoặc bất kỳ tên nào khác mà họ có thể được cung cấp nên biết các công nghệ đang được sử dụng và thiết kế xung quanh họ vì họ phải là những người thực hiện thiết kế thực tế chứ không phải các nhà phân tích kinh doanh.

Tôi tin rằng có một điểm giữa hai dòng suy nghĩ có lẽ thực tế hơn. Mặc dù một thiết kế cấp cao có thể là tốt nhất khi không theo công nghệ, nhưng phải xem xét các hạn chế và yêu cầu trong thế giới thực đã biết cần được đưa vào thiết kế. Thiết kế này ở cấp độ nào? Bạn có đủ yêu cầu? Làm thế nào linh hoạt là môi trường? Là quản lý đầu tư vào một hướng kỹ thuật cụ thể?

Không có thông số hoạt động nào đưa bạn đi theo một hướng cụ thể? Bạn có một loạt các tài nguyên có khả năng thực hiện một giải pháp trong bất kỳ ngăn xếp công nghệ nào không? Có vấn đề tương tác yêu cầu truy cập vào các hệ thống khác?

Câu trả lời cho những câu hỏi này là cần thiết trước khi bạn có thể nói dứt khoát liệu công nghệ nên là một phần của phương trình hay liệu thiết kế có nên thúc đẩy lựa chọn công nghệ hay không.

Không có ràng buộc và là một thiết kế cấp cao, tôi có thể đồng ý với suy nghĩ của bạn rằng thiết kế đó thực sự là bất khả tri. Tuy nhiên, trong hơn 20 năm kinh nghiệm của mình, tôi hiếm khi rơi vào tình huống không có bất kỳ ràng buộc nào làm hạn chế lựa chọn của tôi - và điều đó đã đưa thiết kế của tôi đến các gia đình công nghệ hoặc công nghệ cụ thể.

Các giao diện người dùng lý tưởng sẽ là nơi người dùng nghĩ một ý nghĩ, và những gì họ muốn thực hiện chỉ đơn giản được thực hiện. Bất cứ điều gì thiếu sót đó đều bị tê liệt bởi những hạn chế về công nghệ mà chúng ta có, do đó, tất nhiên BA cần phải hiểu bối cảnh nào họ có thể thiết kế hệ thống.

Các công nghệ khác nhau có thể có cấu trúc chi phí và hiệu quả rất khác nhau để giải quyết một vấn đề nhất định. Những chi phí này có thể bao gồm những thứ như chi phí thuê mướn trong khu vực địa phương, chi phí năng lượng và làm mát cho các hệ thống cụ thể, mã hiện có và khả năng tái sử dụng thiết bị hiện tại, v.v., v.v. nếu một người đang làm việc trong một dự án mà chi phí và hiệu quả không ở đâu quan trọng như những cân nhắc khác (như trong an toàn hàng không, kiểm soát nhà máy hạt nhân, cấy ghép y tế, v.v.). Nhưng đối với hầu hết các tình huống kinh doanh, quản lý có thể quan tâm đến cấu trúc chi phí của các giải pháp tiềm năng so với lợi ích của việc triển khai hệ thống.

Các chuyên gia phân tích kinh doanh nên biết những loại ứng dụng mà chúng ta đang phát triển như * ứng dụng Web / Ứng dụng Console / ứng dụng di động / Báo cáo ứng dụng vv * để cô ấy tốt hơn có thể đưa ra một bộ tốt đẹp của các tính năng cho ứng dụng hoặc đẩy lùi vào người sử dụng dựa trên những kỳ vọng không thể như kéo và thả lồng cấp 3 (ví dụ).

Anh ấy / cô ấy không cần phải biết công nghệ nào như Java / C # / Python / SQL, v.v.

Bản thân quá trình phân tích cần phải hoàn toàn không tin vào công nghệ. Khi bạn đang nghiên cứu khách hàng và nhu cầu của nó, bạn cần phải làm như vậy với một tâm trí hoàn toàn cởi mở. Tuy nhiên, mặt khác của đồng tiền là nhà phân tích thường được yêu cầu cung cấp các khuyến nghị và cũng có thể được yêu cầu xử lý kiến ​​trúc hệ thống. Đây là một khía cạnh hoàn toàn khác nhau về vai trò trong đó sự hiểu biết rộng hơn về các công nghệ có sẵn là rất quan trọng, vì nó có thể tạo ra sự khác biệt lớn cho khách hàng không chỉ về khả năng đưa dự án ra khỏi mặt đất, mà còn về mặt về nhu cầu lâu dài của khách hàng và tính bền vững của chính dự án.

Mặc dù sự thật là phần lớn hơn của phần mềm thiết kế về cơ bản là giống nhau bất kể công nghệ được sử dụng là gì, luôn có những lĩnh vực mà thiết kế sẽ bị ảnh hưởng bởi sự lựa chọn công nghệ. Các lựa chọn nền tảng có thể ảnh hưởng đến các lựa chọn ngôn ngữ và API, trong khi khả năng chuyên môn, hỗ trợ và thậm chí chi phí cũng sẽ có tác động đến các lựa chọn được đưa ra. Vì vậy, từ góc độ, một phần của vị trí của bạn là hợp lý khi phân tích thực tế nên được thực hiện mà không chịu ảnh hưởng của bất kỳ công nghệ cụ thể nào, tuy nhiên sử dụng phân tích để xác định thiết kế sẽ luôn đòi hỏi kiến ​​thức công nghệ rộng hơn, để nhà phân tích có thể đưa ra khuyến nghị sẽ cho phép áp dụng các thiết kế nhằm đáp ứng nhu cầu của khách hàng.

Mỗi công nghệ có những giới hạn và ràng buộc, do đó, có ý nghĩa đối với một nhà phân tích để xem xét những giới hạn đó. Mặt khác, một nhà phân tích biết rõ về .net, nhưng đã không thấy Java từ cuối những năm 1990, rất có thể sẽ thiết kế một giải pháp .net - sử dụng thuật ngữ và mẫu thiết kế .net - ngay cả khi Java (hoặc RoR, v.v.) sẽ phù hợp hơn với vấn đề. Sau này, tương đối khó thực hiện một thiết kế như vậy trong một công nghệ khác.

Do đó, tôi nghĩ một nhà phân tích nên không tin tưởng khi công nghệ chưa được chọn, nhưng có kinh nghiệm trong những trường hợp lựa chọn đã được đưa ra.