Các nhà phát triển phải hiểu lĩnh vực kinh doanh hay thông số kỹ thuật phải đủ?

Tôi làm việc cho một công ty mà tên miền thực sự khó hiểu vì đây là công nghệ cao trong ngành điện tử, nhưng điều này có thể áp dụng cho bất kỳ sự phát triển phần mềm nào trong một miền phức tạp.

Ứng dụng mà tôi làm việc hiển thị rất nhiều thông tin, biểu đồ và số liệu khó hiểu nếu không có kinh nghiệm trong miền. Nhà phát triển sử dụng một đặc tả để mô tả những gì phần mềm phải làm, chẳng hạn như chỉ định rằng một biểu đồ cụ thể phải hiển thị loại số liệu này và số liệu này là công thức số học sau đây.

Theo cách này, nhà phát triển không thực sự hiểu doanh nghiệp và lý do / tại sao anh ta thực hiện nhiệm vụ này. Điều này có thể ổn nếu thông số kỹ thuật thực sự chi tiết nhưng khi nó không hoặc khi tác giả quên trường hợp sử dụng, điều này khá khó để nhà phát triển tìm ra giải pháp.

Mặt khác, đào tạo mọi nhà phát triển cho tất cả các khía cạnh kinh doanh có thể rất dài và khó khăn.

Chúng ta có nên coi trọng đặc tả chi tiết hơn (nhưng như chúng ta biết, đặc tả hoàn hảo không tồn tại) hoặc chúng ta nên đào tạo tất cả các nhà phát triển để hiểu về lĩnh vực kinh doanh?

EDIT: hãy ghi nhớ câu trả lời của bạn rằng công ty có thể sử dụng các nhà phát triển bên ngoài và rằng một sự hình thành cho tất cả các miền có thể là khoảng 2 tuần

Các đặc điểm kỹ thuật là hầu như không bao giờ đủ. Các nhà phát triển không có kiến ​​thức về miền không thể chỉ ra khi đặc tả bị lỗi (hầu hết các trường hợp xảy ra thường xuyên) và đưa ra các lựa chọn thiết kế kém.

Theo kinh nghiệm của tôi, hiện đã làm việc trong 3 ngành rất khác nhau, bạn có thể bắt đầu không biết nhiều về tên miền, nhưng cuối cùng bạn sẽ cần học nó và ai đó sẽ phải hiểu nó ở mức độ chi tiết.

Vấn đề cốt yếu nằm ở trở ngại của nhà phát triển khách hàng: họ muốn thứ gì đó nhưng sẽ chỉ biết khi họ nhìn thấy và bạn muốn giải quyết vấn đề của họ nhưng không thể luôn hiểu rõ vấn đề đó là gì. Càng nhiều kiến ​​thức tên miền về ngành công nghiệp (của khách hàng) mà bạn (nhà phát triển) có thể mang lại, bạn càng dễ dàng dịch "muốn" mơ hồ thành "vấn đề" cụ thể và giải quyết chúng.

Như một ví dụ điển hình, công việc trước đây của tôi là trong ngành hóa chất liên quan đến phần mềm quản lý nhà máy. Tôi đã bắt đầu với kiến ​​thức không có hiệu quả về tên miền, nhưng đã có thể triển khai mã tôi cần để giải quyết các vấn đề phụ do nhà phát triển cấp cao và khách hàng trình bày cho tôi. Theo thời gian, tôi đã nỗ lực tìm hiểu ngành, để tôi có thể giao tiếp dễ dàng hơn ở cấp độ của khách hàng. Khi tôi hiểu ngành của họ, tôi bắt đầu hiểu vấn đề thực sự là gì. Khi họ nói những điều như "chúng tôi cần theo dõi tất cả các giá trị dữ liệu trên mô-đun này" tôi có thể dịch nó thành ý nghĩa thực sự của chúng, đó là "chúng tôi cần lưu giữ hồ sơ lịch sử của từng giá trị mà cảm biến này tạo ra, được lưu trữ trong X ngày duy trì, nhưng luôn được đánh giá dựa trên lần đọc gần đây nhất từ ​​cảm biến đó. "

Vì vậy, có ai đó cần kiến ​​thức về miền và tốt nhất là nhà phát triển vì các vấn đề về miền không phải là vấn đề về mã và việc dịch giữa hai người không phải là chuyện nhỏ. Cuối cùng, bất kỳ nhà phát triển nào đáng để duy trì nhóm của bạn nên chọn tên miền, để họ có thể đưa ra các lựa chọn sáng suốt hơn về các sắc thái của mã của họ.

MỘT SỐ người trong dự án cần phải có kiến ​​thức miền khá đầy đủ. Người đó có thể hoặc không thể là nhà phát triển.

Trong các dự án Agile, chủ dự án khách hàng là người đó và họ đang làm việc cộng tác và chặt chẽ với nhóm. Trong các dự án không phải là Agile, ai đó trong nhóm cần thu thập kiến ​​thức đó, nhưng họ thường không có, đó là một lý do tại sao các dự án không phải là Agile rất dễ bị thất bại.

Có rất nhiều câu trả lời xuất sắc. Tôi thêm cái riêng của mình vì sau khi đọc chúng và tìm kiếm tôi thấy rằng không ai đề cập đến một vấn đề chính: lỗi .

Nếu nhóm không được cung cấp đủ người có đủ thẩm quyền và chuyên môn về miền, thì sớm muộn gì các lỗi cũng sẽ xuất hiện. Có kiến ​​thức về miền, không thể có giá trị / kết quả / mối quan hệ không nhạy cảm. Người ta có thể hy vọng rằng một đặc điểm kỹ thuật chỉ ra chúng một cách rõ ràng nhưng trong thực tế, điều tốt nhất bạn có thể đạt được là tránh những điều rõ ràng nhất (cảnh báo tôi nếu lãi suất trở nên tiêu cực, hoặc những điều như thế - điều này có thể hoặc không phải là lỗi nhưng là đủ lạ để đáng chú ý).

Điều này liên quan chặt chẽ đến việc hiểu lý do cho các lựa chọn và trong trường hợp tốt nhất, nó cũng dẫn đến phần mềm tốt hơn (bởi vì nếu người ta thực sự biết lý do đằng sau một yêu cầu, có thể nghĩ về nó, thay vì phải chấp nhận nó như một sự cho trước ).

Hãy nhớ rằng Einstein đã nói "Nhưng suy nghĩ và ý tưởng, không phải công thức, là khởi đầu của mọi lý thuyết vật lý." , Đó là người ta nghĩ không phải về mặt công thức trừu tượng mà là về ý tưởng ...

Nếu bạn đặt một người chỉ biết tiếng Anh và một người chỉ biết tiếng Nhật trong phòng, họ sẽ không thể dịch từ tiếng Nhật sang tiếng Anh, mặc dù là chuyên gia về ngôn ngữ tương ứng của họ. Vì lý do tương tự, ngay cả các lập trình viên chuyên gia không có kiến ​​thức về miền cũng không thể tìm ra những gì họ cần xây dựng, ngay cả khi họ có quyền truy cập 24x7 đến chuyên gia tên miền giỏi nhất, người không phải là chuyên gia phát triển phần mềm.

Một thông số kỹ thuật là một nỗ lực dịch "tiếng Nhật" của các yêu cầu miền sang "tiếng Anh" của các yêu cầu lập trình. Khi bạn có được chất lượng dịch tương đương với dịch của Google, đó là ngày may mắn của bạn; hầu hết thời gian, chất lượng chỉ là không có, vì vậy bạn không có cách nào để có được ít nhất một số kiến thức về miền. Với một số kiên trì, nó làm cho bạn trở thành một "dịch giả" đàng hoàng vào cuối dự án, vì vậy giá trị của bạn đối với công ty của bạn tăng lên đáng kể. Hầu hết thời gian, bạn cũng có rất nhiều niềm vui trong quá trình, vì vậy đó là một tình huống đôi bên cùng có lợi.

Không có một số khía cạnh của kiến ​​thức kinh doanh, bạn sẽ kết thúc với các nhà phát triển, những người không đặt câu hỏi và mã hóa những gì các thông số kỹ thuật nói. Tôi tin rằng cần có "Người suy nghĩ" để tạo ra phần mềm tốt chứ không chỉ những người có thể đập bàn phím. Hiểu không chỉ "Bạn" đang làm gì mà còn "Tại sao" và cách nó phù hợp với bức tranh lớn hơn giúp mang lại sự hài lòng cao hơn cho nhóm phát triển.

Tôi nghĩ bạn nên cố gắng để có được kiến ​​thức tên miền. Thông số kỹ thuật là danh sách kiểm tra cho biết sản phẩm cuối cùng nên làm gì và được yêu cầu để xác thực sản phẩm của bạn. Là nhà phát triển, bạn nên luôn cố gắng hiểu vấn đề thực sự bạn đang cố gắng giải quyết là gì. Có được kiến ​​thức tên miền sẽ giúp bạn hiểu điều đó.

Nó sẽ giúp bạn thiết kế và viết mã dễ dàng vì bạn sẽ hiểu những gì đang thay đổi các bộ phận (nói bộ quy tắc) và đặt chúng riêng biệt. Bạn không cần phải là một bậc thầy về nó nhưng sẽ có thể nói chuyện với người dùng cuối bằng ngôn ngữ của họ .

Bạn có thể lái một chiếc xe có kiến ​​thức cơ bản về nó; nhưng trong trường hợp bạn muốn tận hưởng chuyến đi, bạn cần tìm hiểu thêm về cách sử dụng chính xác. Cũng như các ngành nghề khác, không bắt buộc phải hiểu tên miền, nhưng thật thú vị khi bạn thực hiện nó .

Tôi nghĩ rằng một nhà phát triển biết doanh nghiệp có giá trị trọng lượng của họ bằng vàng.

Trong một kịch bản "truyền thống" trong đó doanh nghiệp có một số yêu cầu và một số nhà phân tích kinh doanh chuyển những yêu cầu đó thành yêu cầu kỹ thuật thì nhà phát triển giải quyết những vấn đề mà bạn chắc chắn có hai điều có thể xảy ra:

1. Bạn có nhiều điểm thất bại. Nhà phân tích kinh doanh có thể không nhận được tất cả các yêu cầu kinh doanh được dịch hoàn hảo và / hoặc nhà phát triển có thể không dịch những điều đó thành một đặc tả kỹ thuật hoàn hảo. Một biến thể của kịch bản "bí mật quanh phòng". Chỉ là sự cấp thiết của giao tiếp.

2. Một hoặc tất cả chủ sở hữu doanh nghiệp, nhà phân tích kinh doanh hoặc nhà phát triển đủ mới để tổ chức bỏ lỡ các mục chính mà họ sẽ không nghĩ về bình thường. Nhà phát triển dày dạn, hiểu biết về kinh doanh có thể hỗ trợ giáo dục mọi người về những vai trò khác để làm cho sản phẩm hoàn thiện hơn.

Hầu như luôn luôn có sự đánh đổi giữa giá trị của từng tính năng trong thông số kỹ thuật, mức độ cụ thể phải được triển khai đến mức có giá trị và chi phí đáp ứng bất kỳ sự kết hợp nào của các tính năng thông số kỹ thuật. Thông thường, sự đánh đổi tốt chỉ có thể được thực hiện khi kiến ​​thức để thực hiện tất cả những điều trên tồn tại ở một người hoặc một nhóm làm việc chặt chẽ, bao gồm kiến ​​trúc sư phần mềm thực tế và / hoặc người viết mã.

Nếu không có kiến ​​thức cực kỳ cục bộ và thậm chí có thể là cảm xúc ruột, kết quả có thể dễ dàng trở thành một sản phẩm rất tốn kém gần như vô dụng, đáp ứng rất chặt chẽ các thông số kỹ thuật bằng văn bản.

Chi phí tạo ra một thông số không có các vấn đề trên thường có thể lớn hơn việc đào tạo kiến ​​trúc sư và / hoặc lập trình viên để có đủ kiến ​​thức về miền để làm việc với một thông số chi tiết ít khó hiểu hơn (giả sử tính hợp pháp và hợp đồng kinh doanh cho phép điều này).

Có nhà phát triển cần phải biết kinh doanh ở một mức độ. Họ không cần phải biết chi tiết từng phút, nhưng họ cần có hiểu biết cơ bản về báo cáo X được sử dụng để làm gì và nó được sử dụng như thế nào trong quy trình kinh doanh. Càng nhiều nhà phát triển của bạn hiểu về doanh nghiệp, giải pháp họ có thể cung cấp càng tốt.

Dựa trên kinh nghiệm của tôi *, một cá nhân có kiến ​​thức tốt về miền vấn đề và kiến ​​thức tốt về phát triển phần mềm có nhiều khả năng tìm ra giải pháp tối ưu cho vấn đề hơn hai cá nhân, một người có kiến ​​thức tuyệt vời về miền vấn đề và một người có kiến ​​thức tuyệt vời phát triển phần mềm, làm việc cùng nhau.

Tôi nghĩ rằng thực tế đơn giản là giao tiếp xảy ra trong não của một cá nhân nhanh hơn và tốt hơn nhiều lần so với giao tiếp giữa các cá nhân.

* Kinh nghiệm chính tôi rút ra để trả lời câu hỏi này là hơn 10 năm dành cho việc phát triển gói phần mềm kế toán (từ khi bắt đầu đến mode chế độ bảo trì '). Mặc dù kiến ​​thức về phát triển phần mềm của tôi khá tốt, nhưng so với các đồng nghiệp của tôi, tôi thường cảm thấy bị khiếm khuyết do thiếu hiểu biết về miền vấn đề.

Tôi muốn trả lời khi có ai đó đến từ phía doanh nghiệp, người làm việc với các nhà phát triển ít quan tâm đến việc tìm hiểu những điều cơ bản của giao dịch, đôi khi thậm chí có vẻ tự hào vì không phải biết về những điều cơ bản đó: Vấn đề là Các nhà phát triển sẽ không thể nhìn thấy các lỗi trong kết quả ngay từ cái nhìn đầu tiên (kết quả không hợp lý, các dấu hiệu sai, v.v.), đòi hỏi các trường hợp thử nghiệm chi tiết (mà chúng tôi đã không phát triển cho đến gần đây) hoặc giám sát liên tục các kết quả. Trong chừng mực, nhiều như tôi sẵn sàng tìm hiểu những điều cơ bản về phát triển phần mềm để giảm bớt giao tiếp, tôi muốn thúc giục các nhà phát triển làm điều tương tự.

Bạn không cần phải làm vậy, nhưng tại sao bạn lại không muốn?

Tôi sẽ quan tâm đến bất kỳ lập trình viên nào miễn cưỡng và đặc biệt là không thể học tên miền ở một mức độ nào đó. Điều quan trọng là phải ra khỏi "tháp mã ngà" một lần trong một thời gian.

Viết mã mà không có bất kỳ ý tưởng nào về cách nó được sử dụng và cho mục đích gì nghe có vẻ như là một công việc khủng khiếp. Ai muốn phá vỡ những viên gạch khi bạn có thể xây dựng thánh đường?

Càng nhiều nhà phát triển trở nên tham gia và càng có thâm niên trong doanh nghiệp, điều quan trọng hơn là phải có ít nhất kiến ​​thức về miền trung cấp hoặc các lĩnh vực mang nhiều sắc thái của ngành công nghiệp đó có thể bị nhóm nhà phát triển hiểu rõ.

Tuy nhiên, một đặc điểm kỹ thuật nên được áp dụng cho các nhiệm vụ cấp thấp hơn. Nói tóm lại, tốt nhất là đào tạo lực lượng lao động của bạn xuống mức thấp hơn. Họ có thể là lập trình viên đa âm tốt nhất trên thế giới, nhưng nếu họ không thể hiểu vấn đề khá sâu sắc thì họ luôn cam chịu thất bại hoặc lập trình tuần hành chết chóc.

Luôn phải có một số đặc điểm kỹ thuật - bạn không thể mong đợi tất cả các nhà phát triển trở thành chuyên gia tên miền. Đồng thời, nếu các nhà phát triển mù quáng theo dõi một thông số mà không thực sự hiểu nó là gì, kết quả có thể không thực sự là những gì khách hàng muốn. Nó thường xảy ra khi một nhà phát triển thậm chí có mức độ hiểu biết khá (nhưng không phải là chuyên gia), họ có thể bắt lỗi và thiếu sót trong thông số kỹ thuật. Họ cũng có thể đóng góp và đưa ra phản hồi cho quá trình có thể làm cho sản phẩm cuối cùng tốt hơn nhiều.

Có thể đáng để thuê một số chuyên gia tên miền có nhiệm vụ liên kết giữa khách hàng và nhà phát triển để giúp nhà phát triển hiểu rõ hơn và cũng để giúp viết thông số kỹ thuật.

Tôi nghĩ rằng điều này khó để đưa ra một câu trả lời một trong hai cách.

Thật khó để thấy làm thế nào, một nhà phát triển tự do có thể hiểu doanh nghiệp (hoặc khoa học) đằng sau mỗi ứng dụng mà họ phát triển. Trong tình huống này, tôi nghĩ điều quan trọng hơn là nhà phát triển phải biết đặt câu hỏi đúng về thông số kỹ thuật hoặc mô hình kinh doanh hơn là thực sự hiểu chính doanh nghiệp.

Mặt khác, một nhà phát triển doanh nghiệp, giả sử rằng họ đã ở trong cùng một doanh nghiệp, thực sự phải học cách kinh doanh sau vài tháng (hoặc có lẽ là vài năm). Trong nhóm lớn, bạn cũng có thể có một kiến ​​trúc sư hiểu rõ về doanh nghiệp hơn các nhà phát triển.

Trong các doanh nghiệp vừa và nhỏ với các nhà phát triển đơn độc, điều quan trọng là nhà phát triển phải thường xuyên thảo luận với chủ sở hữu / người quản lý để tránh đi ra ngoài và thực hiện điều sai.

Vì vậy, có rất nhiều cách có thể nghĩ về điều này, nhưng chìa khóa là giống nhau trong mọi trường hợp: giao tiếp .

Phát triển phần mềm là nghề duy nhất tôi biết, đòi hỏi bạn không chỉ thành thạo nghề nghiệp của mình mà phải có hiểu biết cơ bản về nghề nghiệp mà bạn đang làm việc. Điều quan trọng là phải có đủ hiểu biết về miền để giao tiếp với khách hàng và nhà phát triển khác trong ngôn ngữ của khách hàng. Là một nhà phát triển, bạn không thể luôn luôn dựa vào người khác để đào tạo bạn. Đôi khi bạn phải tự mình nghiên cứu cá nhân, thường là ngoài giờ làm việc thông thường.

Tôi thực sự hiểu ý của bạn ở đây vì chúng tôi, với tư cách là một công ty trong ngành du lịch, cũng gặp phải vấn đề tương tự. Khi tôi là một nhà phát triển cơ sở, tôi cũng đang học du lịch tại một trường cao đẳng. Vì vậy, bạn có thể đoán rằng tôi không đến từ nền tảng khoa học máy tính nhưng kiến ​​thức du lịch của tôi rất cao.

Chúng tôi đã xây dựng các sản phẩm liên quan đến các công ty phần mềm khác trước đó, nhưng kiến ​​thức cụ thể về tên miền còn thiếu rất nhiều. Như bạn đã mô tả, thực sự rất khó để làm cho đúng nếu bạn đang xây dựng một sản phẩm trong ngành du lịch vì có nhiều mối quan tâm xuyên suốt, v.v.

Vì vậy, phong trào này đã cho rất nhiều kết quả xấu trong dài hạn. Sau đó, chúng tôi đã tiến một bước lớn và tôi bắt đầu chỉ tập trung vào phát triển hơn là phần kinh doanh của dự án. Khi tôi có kiến ​​thức công nghiệp và kiến ​​thức lập trình, dự án phát triển hiệu quả hơn bao giờ hết. Chưa kể, sau đó chúng tôi có thể đưa ra quyết định nhanh hơn vì tôi có kinh nghiệm ở cả hai mặt của đồng tiền.

Như một câu trả lời cụ thể cho câu hỏi của bạn, nó chắc chắn là có theo quan điểm cá nhân của tôi. Nếu dự án mà nhóm của bạn đang thực hiện là một dự án dài hạn, thì hãy đi theo con đường khó khăn và đào tạo nhân viên của bạn về các nguyên tắc và chi tiết cụ thể của miền.

Nếu một nhà phát triển ở lại trong một công ty / ngành trong một thời gian dài, họ sẽ từ từ nhưng chắc chắn sẽ học được "công việc".

Một số công ty thừa nhận và cung cấp đào tạo về "doanh nghiệp". Các công ty tài chính là một ví dụ tốt về điều này.

Bạn càng tìm hiểu về doanh nghiệp, bạn sẽ càng dễ dàng nói chuyện với người dùng của mình. Họ sẽ cảm thấy tin tưởng bạn hơn. Bạn sẽ dễ dàng hiểu được những điều kỳ quặc về việc một hệ thống có thể sai ở đâu nếu nó không hoàn toàn như mong đợi đối với người dùng.

Để trả lời câu hỏi của bạn, thông số kỹ thuật KHÔNG BAO GIỜ đủ theo kinh nghiệm của tôi. Vấn đề phổ biến là chúng thường không chứa đủ thông tin và nhanh chóng bị lỗi thời.

Kinh nghiệm trong lĩnh vực kinh doanh có thể là bắt buộc đối với một số công ty. Họ tìm kiếm các nhà phát triển có kinh nghiệm trong lĩnh vực này khi tuyển dụng. Một số công ty thậm chí còn đặt điều này cao hơn các kỹ năng công nghệ thực tế. (Không có kinh nghiệm tài chính, không có cuộc phỏng vấn là rất phổ biến, chắc chắn là ở Anh).

Từ kinh nghiệm cá nhân, thông số kỹ thuật là đủ miễn là bạn có ai đó trong nhóm làm việc với bạn có kiến ​​thức về miền.

Tôi làm việc trong một ngành rất chuyên môn: chúng tôi làm phần mềm cho phương tiện truyền thông phát sóng. Tôi hầu như không biết gì về phát thanh truyền hình, nhưng tôi biết mã và tôi biết dữ liệu và tôi đã có những người giỏi trong nhóm quản lý dự án hiểu về phát thanh truyền hình. Công thức đó đủ tốt trong vài năm qua để tôi đưa ra chức năng tốt mà khách hàng thích.