Một nhà phát triển nên tranh luận chống lại các tính năng không cần thiết hoặc có hại?

Một thái độ tốt từ các nhà phát triển khi thảo luận về các tính năng mới, và cụ thể là các tính năng không quan trọng / nghi vấn là gì?

Giả sử bạn đang phát triển một số loại ngôn ngữ như Java và ông chủ nói: "Chúng tôi cần con trỏ để các nhà phát triển có thể sử dụng bộ nhớ đối tượng trực tiếp!"

Nhà phát triển có nên từ chối ý tưởng này vì nó bổ sung các lỗ hổng bảo mật và độ phức tạp không thể tưởng tượng được, hay anh ta nên làm gì?

Đây có thể không phải là một ví dụ tốt, nhưng còn những thứ nằm trong vùng xám hơn, như thêm các nút phá vỡ quy trình làm việc hoặc đi ngược lại cấu trúc bên trong của chương trình, v.v.?

Phân phối "có thể làm" tối ưu so với "không thể làm" tối ưu cho một lập trình viên thông thường là gì?

EDIT: Câu hỏi không phải là về một ông chủ tồi: D

Tôi đã quan tâm nhiều hơn đến việc làm thế nào để mọi người tiếp cận các vấn đề mới có thêm một số vấn đề đáng chú ý trong khi có thể rất hữu ích.

Nên có thái độ chung:

1. vâng, chúng tôi sẽ làm điều đó, vặn vẹo sự phức tạp
2. có lẽ
3. không, việc làm lại nói chung và hàm ý không biện minh cho sự thay đổi

Điều gì nên là phản ứng của một nhà phát triển tốt?

Điều tốt nhất là có một cuộc họp và đưa ra những ưu và nhược điểm như một nhóm, và dựa trên đó thảo luận về giải pháp tốt nhất. Nếu bạn có một nhóm, hãy để họ đồng ý về giải pháp. Khi một nhóm đồng ý về một cái gì đó, các nhà quản lý và "ông chủ" có xu hướng đi cùng với giải pháp.

Nếu sếp của bạn vẫn không đồng ý, thì bạn đã làm tất cả những gì bạn có thể làm: bạn đã cùng nhóm và quản lý của mình cùng nhau giải quyết những ưu và nhược điểm và mặc dù sếp của bạn đã chọn giải pháp kém hơn.

Chìa khóa cho vấn đề này là thảo luận về những ưu và nhược điểm của một nhóm. Bằng cách làm như vậy, bạn đang thảo luận về giải pháp tốt nhất với nhóm của mình, đồng thời chỉ ra quyết định của sếp (trước khi đưa ra) mà không có phản ứng chính trị xảy ra sau khi thực tế nói với mọi người lý do tại sao bạn nghĩ rằng sếp quyết định là một trong những sai.

Đây là một tình huống đấu thầu liên quan đến chính trị công việc, nhưng nó có thể được xử lý một cách thân thiện.

Nếu sếp của bạn bảo bạn làm những nhiệm vụ ngu ngốc, thì bạn nên (vui lòng) giải thích tại sao nó lại ngu ngốc.

Nếu anh ấy hoặc cô ấy không có được điểm, thì bạn có nghĩa vụ phải làm những điều ngu ngốc. Đó là nó. Anh ấy là ông chủ. Trong trường hợp như vậy, bạn chỉ có thể làm những gì anh ấy / cô ấy nói, hoặc nói chuyện với sếp của anh ấy / cô ấy hoặc thay đổi công việc.

Bạn có thể nói với sếp rằng trong khi đó là kỹ thuật có thể, nó sẽ có giá X số tiền trong thời gian và tiền chi cho nỗ lực phân tích, thiết kế, để viết lại mã hiện, thử nghiệm, kiểm tra hồi quy, ... Và sau đó yêu cầu nếu đối tượng là giá trị nó . Đôi khi câu trả lời sẽ là "có! Chúng ta phải có cái này!", Đôi khi nó sẽ là "không, tôi đoán là không".

Nếu tính năng được yêu cầu vi phạm một số nguyên tắc cốt lõi của ứng dụng (chẳng hạn như "Thêm nút màu xanh!" Cho giao diện người dùng được chỉ định và được thiết kế để chỉ có các nút màu đỏ theo yêu cầu của khách hàng) thì tôi nghĩ rằng nó ổn để hỏi "Tại sao?" và đề cập rằng nó đi ngược lại với thiết kế được thiết lập trước.

Cuối cùng, hầu hết mọi thứ đều là "có thể làm" (có thể không khó từ quan điểm kỹ thuật để thêm nút màu đỏ vào giao diện người dùng chỉ có màu xanh), đó là câu hỏi "nên làm gì?"

Để trả lời câu hỏi đã chỉnh sửa của bạn, tôi nghĩ câu trả lời phải là # 2, "Có thể", đang chờ điều tra và phân tích thêm.

Bạn không muốn trả lời số 1 "Có, vô điều kiện" bởi vì bạn có thể bị mắc kẹt khi cam kết với thứ gì đó mà bạn không có khả năng cung cấp trong khung thời gian nhất định.

Bạn không muốn trả lời # 3 "Không, công việc quá nhiều" bởi vì sau đó có vẻ như bạn đang bất hợp tác và khó khăn không cần thiết.

Từ quan điểm của một nhà phát triển: KHÔNG BAO GIỜ nói với bất kỳ ai trả các hóa đơn mà họ không thể có những gì họ muốn. Thay vào đó, bạn có thể nói với họ rằng họ không thể có nó với giá đó, hoặc họ không thể có chính xác như cách họ nghĩ ban đầu.

Để ví dụ "con trỏ" của bạn; .NET, một môi trường mã được quản lý, có con trỏ. Chúng rất cần thiết cho rất nhiều khả năng tương tác với mã không được quản lý. Tuy nhiên, việc sử dụng chúng "an toàn" được quy định chặt chẽ và nếu được sử dụng trong mã "không an toàn", mã đó yêu cầu quyền bảo mật cao hơn trong thời gian chạy. Nếu bạn đang phát triển một ngôn ngữ được quản lý cũng yêu cầu truy cập bộ nhớ trực tiếp thông qua con trỏ, bạn có thể đưa ra một sơ đồ tương tự như sắp xếp phía sau hậu trường nơi bạn có thể, sử dụng các con trỏ được quản lý chỉ đọc mà bạn không thể tự động sắp xếp và cho phép " đúng "con trỏ chỉ trong các khu vực đáng tin cậy nhất của cơ sở mã.

Đối với các ví dụ GUI của bạn: nếu bạn biết rằng một tính năng mới sẽ "phá vỡ" dòng mã hiện tại, thì bạn có thể kiểm tra điều đó và phát triển nó mạnh mẽ hơn để quay trở lại bất kỳ công việc nào trước đó được thực hiện bởi quy trình công việc. Khách hàng của bạn, và đôi khi ngay cả người quản lý của bạn, thường không có đầu mối hoặc quan tâm đến cấu trúc của chương trình; nếu một cái gì đó họ muốn là khó khăn do cách bạn cấu trúc chương trình, thì theo định nghĩa cấu trúc là sai vì nó không cho phép bạn làm những gì khách hàng muốn.

Trong mọi trường hợp, tính năng mới này có thể tăng phạm vi công việc cần thiết ngoài những gì khách hàng đã nghĩ. Điều đó sẽ lần lượt yêu cầu gia hạn lịch trình, nhiều tiền hơn và / hoặc giảm các công việc khác theo kế hoạch.

Tuy nhiên, nếu bạn biết một cách để đạt được kết quả cơ bản tương tự theo cách dễ dàng hơn hoặc hợp lý hơn, thì điều đó có thể được đề xuất cho khách hàng. Mặc dù chúng chắc chắn tồn tại, nhưng may mắn là tôi vẫn chưa thấy một khách hàng nào từ chối lắng nghe ý kiến ​​của các nhà phát triển, đặc biệt là trong môi trường Agile nơi có "chủ sở hữu sản phẩm" có nhiệm vụ duy nhất là phát triển các chi tiết cần thiết khác nhau như những cái này

Nếu bạn dành nhiều năm để lập trình cho các ứng dụng lớn và suy nghĩ nghiêm túc về nó trên đường đi, bạn sẽ phát triển ý thức tinh chỉnh khi một tính năng sẽ gây ra vấn đề lớn hơn tính hữu dụng của nó. Một từ khác cho điều này là sự khôn ngoan , và cũng giống như trường hợp của các loại trí tuệ khác, nó có thể là một thách thức để làm cho những người không có nó nhìn thấy giá trị của nó.

Các áp phích khác đã lập luận rằng bạn nên cố gắng định lượng chi phí của vấn đề sẽ được đưa ra bởi một tính năng có vấn đề, và đó là một ý tưởng tốt khi có thể, nhưng thường thì không. Nó thường chỉ có thể ước tính chi phí thực hiện ngay lập tức. Thậm chí điều đó thường khó khăn cho các tính năng lớn hơn. Đối với các chi phí trong tương lai, bạn đang ở một vị trí khó khăn. Bạn không biết chắc chắn những tính năng nào khác sẽ được yêu cầu hoặc sản phẩm sẽ được bảo trì trong bao lâu. Chi phí thường sẽ cao hơn nhiều so với bạn có thể dự phòng với ước tính dựa trên sự thật khó khăn.

Bạn càng chứng tỏ được nhiều năng lực trong quá khứ, bạn sẽ càng mất nhiều thời gian để đơn giản tuyên bố một tính năng là một ý tưởng tồi. Điều đó chỉ có thể đi cùng với thời gian và một kỷ lục chứng minh thành công. Điều đó nói rằng, bạn nên luôn luôn thể hiện sự háo hức để thực hiện yêu cầu, vì đó là những gì khách hàng của bạn muốn. Bạn nên thể hiện sự bảo lưu dựa trên kinh nghiệm của mình và một khi bạn có, nó sẽ trở thành vấn đề không phải là vấn đề trong 90% các trường hợp bởi vì bạn sẽ bắt đầu một cuộc trò chuyện bắt nguồn từ vấn đề, đó là: Tại sao họ yêu cầu bạn thêm Tính năng này ở nơi đầu tiên? Tại thời điểm đó, bạn có thể đưa ra các lựa chọn thay thế, hoặc có thể đồng ý rằng mặc dù tính năng được yêu cầu sẽ đưa ra các vấn đề, nhưng nó vẫn cần thiết.

Tất nhiên cũng có thể là bạn sai. Kỹ thuật phần mềm có vui không?

Vì câu hỏi khá mơ hồ, tôi sẽ khái quát một chút với câu trả lời của mình.

Luôn luôn hỏi họ, nhưng lắng nghe lý luận của họ. Đôi khi, mọi người chỉ quên đi tính thực tế của một tính năng hoặc thời gian lập trình sẽ mất bao lâu. Mặt khác, đôi khi chúng ta bị mắc kẹt trong tâm lý lập trình viên là hiệu quả / không rườm rà / v.v. và chúng ta quên rằng những gì chúng ta coi là không thiết yếu cho một dự án thực sự không dành cho khách hàng.

Nếu họ có lý do chính đáng, thì hãy cho họ biết sẽ mất bao lâu để lập trình nó và tất cả những lùm xùm có thể xảy ra trong quá trình thực hiện và xem liệu họ có còn muốn tiếp tục với nó không. Mặt khác, nêu lý do tại sao bạn không nghĩ rằng đó là một ý tưởng tốt và xem phản ứng của họ là gì. Rửa sạch và lặp lại.

Hầu hết đã được nói, nhưng có một điều tôi sẽ nhấn mạnh trong môi trường làm việc hiện tại của tôi. Tôi làm việc cho một công ty là nhà thầu cho các công ty khác và các ứng dụng ra có liên quan đến quy trình kinh doanh (với số tiền hợp lý họ thúc đẩy doanh số và giao tiếp khách hàng).

Các quy trình kinh doanh cùng với các sản phẩm đi kèm có thể (ít nhất là nếu công ty đủ lớn) rất phức tạp. Ở một mức độ nhất định, nếu bạn đang mô hình hóa một thứ phức tạp, ứng dụng kết quả sẽ có độ phức tạp liên quan. Vì hầu hết các cá nhân của người kinh doanh chỉ nhìn thấy một phần của quy trình, ứng dụng / quy trình hoàn chỉnh xây dựng trên một sự phức tạp lớn hơn so với những gì người dùng có thể nhìn thấy.

Quan điểm của tôi là, khi một yêu cầu kinh doanh mới xuất hiện, nó sẽ hoạt động cho những người kinh doanh, bởi vì nó không làm tăng độ phức tạp cao hơn nhiều, nhưng có thể có tác động lớn hơn đến toàn hệ thống. Theo tôi đây không phải là một lý do để tranh luận chống lại sự thay đổi đó. Đó là điểm đúng đắn để thảo luận về những nỗ lực (và chi phí) với khách hàng. Có thể sẽ không ngăn khách hàng xây dựng tính năng đó, nhưng theo thời gian họ sẽ có cảm giác về các ứng dụng và một số cuộc thảo luận về "uuh, bạn thật đắt tiền!" sẽ ít kén chọn hơn

Tôi không biết liệu bạn có ở trong một tình huống có thể so sánh được không, nhưng tôi đã học được rằng tình huống của các bên liên quan không nhất thiết phải có sự phức tạp tương tự xảy ra giống như tình huống mà các nhà phát triển và kiến ​​trúc sư của hệ thống CNTT phải đối mặt. Trong tình huống đó giao tiếp giúp cả hai bên.

Xin lỗi, nhưng câu hỏi này nghe như một trẻ vị thành niên xin lời khuyên của cha. Nếu đây là trường hợp, nhà phát triển tốt sẽ cần phải tuân theo các điều răn sau:

• Vẫn trung thành với chính mình. Nếu ruột của bạn cảm thấy không thoải mái về một tính năng, hãy nói rõ mối quan tâm của bạn. Rất có thể là đội đang chờ khai mạc.
• Đừng cố gắng thay thế kinh nghiệm bằng các quy tắc của người có kinh nghiệm. Đối với bạn, mọi tình huống đều khác nhau, mọi tính năng đều mới. Đây là một điểm cộng với người cao niên của bạn không có.
• Phát triển phần mềm không phải là khoa học chính xác, nó sẽ không bao giờ. Do đó, tích lũy trí tuệ, không hành vi.
• Chấp nhận thất bại. Nếu nhóm đồng ý khác, đừng lặp lại mối quan tâm của bạn.
• Suy nghĩ tích cực. Nếu ý tưởng thực sự cầu xin 'bắn hạ nó', hãy thử tìm và đặt tên cho các khía cạnh tích cực của nó trước khi bạn liệt kê những thiếu sót của nó.
• Học cách tương tác với mọi người. Chúng tôi phát triển thường đặt kiến ​​thức kỹ thuật trên năng lực xã hội. Các khả năng kỹ thuật đạt đỉnh sớm trong đời, nhưng năng lực xã hội có thể tiếp tục phát triển cho đến khi nghỉ hưu.

Tôi tin vào việc đẩy lùi các yêu cầu xấu. Nhưng tôi cũng tin rằng khi bạn đã cố gắng hết sức để giải thích lý do tại sao họ xấu và họ vẫn muốn họ, thì bạn đồng ý và thực hiện công việc của mình.

Chẳng hạn, tôi đã có những người muốn các yêu cầu loại trừ lẫn nhau một thứ mà ứng dụng đã làm. Nếu tôi làm điều đó, thì điều này sẽ, đảm bảo 100%, phá vỡ. Vì vậy, tôi gửi lại yêu cầu và nói với họ rằng điều này sẽ phá vỡ quy tắc kinh doanh khác mà chúng tôi đã có và họ có muốn thay đổi quy tắc này không? Thông thường, nhóm nhỏ đưa ra một yêu cầu cụ thể không có quyền truy cập vào bức tranh lớn hơn về những gì phần còn lại của ứng dụng có thể làm. Hầu hết thời gian tôi gửi lại một trong những thứ này, khách hàng đã nhận ra rằng quy tắc nội bộ quan trọng hơn và quyết định rằng sự thay đổi mà họ muốn không đáng có. Khi họ đã quyết định thực hiện thay đổi, họ đã làm điều đó sau khi tham khảo ý kiến ​​với những người đã đưa ra yêu cầu ban đầu.

Đôi khi chỉ cần đặt câu hỏi làm rõ sẽ khiến họ thấy vấn đề không đơn giản như họ nghĩ. Đôi khi bạn muốn hỏi tại sao họ muốn một cái gì đó và đi đến nhu cầu thực sự đó là thúc đẩy sự thay đổi. Một khi bạn hiểu điều đó, thường sẽ dễ dàng hơn để thấy một giải pháp thay thế phù hợp với bạn với tư cách là nhà phát triển và đáp ứng nhu cầu của họ. Nếu bạn có thể trình bày giải pháp đó theo cách nó sẽ đáp ứng tốt hơn nhu cầu của họ so với đề xuất quỹ đạo, bạn đã cải thiện rất nhiều cơ hội để chấp nhận thay đổi của bạn.

Đôi khi, khi một thay đổi sẽ tạo ra sự tàn phá ở mức cơ bản trong thiết kế của bạn, chỉ cần cung cấp cho họ ước tính mới về số giờ thay đổi là đủ để tắt nó đi. Nếu bạn kết hợp điều đó với đánh giá rủi ro chỉ ra chức năng quan trọng nào bạn có thể đưa ra các lỗi mới để nói với họ, sẽ mất 6 tuần nỗ lực tận tâm của 3 người, đột nhiên nó không còn quan trọng nữa.

Nhưng đôi khi bạn nói với họ đây không phải là một ý tưởng hay và tại sao và họ vẫn nói, "Quá tệ, chúng tôi cần nó." Bạn giành được một số và bạn mất một số và đôi khi nhu cầu kinh doanh thực sự đã thay đổi và ứng dụng phải đáp ứng điều đó. Một khi quyết định đã được hoàn thành, không còn là lúc để đặt câu hỏi về những gì bạn đang làm và thời gian để tiếp tục thực hiện nó. Nếu bạn đã ghi lại sự phản đối của mình, thì cá nhân bạn vẫn nên ở một nơi tốt khi nó vượt quá ngân sách và gây ra các lỗi mới và thú vị hơn. Và họ thậm chí có thể sẵn sàng lắng nghe bạn hơn vào lần tới khi bạn đã xây dựng một hồ sơ theo dõi về việc đúng về những điều này.

Chìa khóa để chiến thắng nhiều cuộc thảo luận này (không ai thắng tất cả trong số họ) trước tiên là xây dựng một hồ sơ theo dõi để biết bạn đang nói về điều gì. Tiếp theo gửi một tài liệu bằng văn bản nêu rõ những gì bạn quan tâm (nhiều người quản lý có nguy cơ bất lợi, họ có nhiều khả năng không muốn ai đó có tài liệu chứng minh họ sai sau này, vì vậy họ chú ý nhiều hơn đến những gì bạn viết) để đảm bảo họ hiểu tất cả các chi phí (không chỉ hàng giờ mà cả rủi ro bảo mật, giới thiệu các lỗi mới, thời hạn bị thiếu, v.v.) của việc thực hiện thay đổi. Thay đổi không miễn phí và họ cần hiểu điều đó. Chìa khóa tiếp theo là làm điều này như người lớn và không thích trẻ con rên rỉ ("nhưng tôi không muốn sử dụng ... vì tôi không thích nó"). Làm cho một trường hợp kinh doanh không làm điều đó và bạn sẽ nhận được rất nhiều trong việc đẩy lùi một yêu cầu xấu.

Nếu tôi đọc bạn chính xác, câu hỏi thực sự là về sự phức tạp chưa biết. Ban đầu tôi đọc câu hỏi của bạn như sau: "Tôi thấy nguy cơ cực kỳ phức tạp của sự phức tạp quá mức nhưng ông chủ thì không" Nhưng bạn đang nói rằng ông chủ không phải là vấn đề, vì vậy tôi không chắc là rủi ro là gì thêm phức tạp không thể chấp nhận được.

Trong trường hợp đó, tôi muốn đề xuất một số loại chiến lược giảm thiểu rủi ro. Hình ảnh bạn đang xem xét thêm các dịch vụ WCF / web vào API của bạn, điều này có thể tuyệt vời hoặc rất phức tạp mà không có phần thưởng:

• thêm tính năng trên một nhánh. Nếu nó hoạt động, hợp nhất nó. Nếu nó biến thành một tổ chuột, giết nó.
• khởi động một dự án một trang mới và làm bằng chứng về khái niệm. Nếu bạn không thể làm bằng chứng về khái niệm trong một thời gian ngắn, thì hãy bỏ nó đi. Nếu bằng chứng về khái niệm hoạt động, làm cho nó lớn hơn và tích hợp nó với
• truy quét web để mọi người hiểu rõ về tính năng hoặc công nghệ đó. Khi có nhiều sự kìm kẹp đang diễn ra, một công nghệ có thể là một số rủi ro thực sự của sự phức tạp quá mức. Java Beans và COM + có thể là những ví dụ cũ, nhưng tốt về các tính năng thực sự làm tăng sự phức tạp và có thể hoặc không thể cung cấp về mặt lợi ích của phương trình

Tranh cãi không. Thảo luận có thể có. Nhưng nó nên được coi là một bổ sung cho thông số kỹ thuật và ưu tiên với các tính năng khác. Nếu bạn biết rằng yêu cầu sẽ thêm một lượng thời gian và độ phức tạp không hợp lý để thực hiện thì hãy nêu ra điều đó. Không phản đối việc thực hiện yêu cầu, giống như một lời giải thích về những gì bạn nghĩ rằng nó sẽ mất để thực hiện.

Nó không phụ thuộc rất nhiều vào yêu cầu. Việc thực hiện con trỏ đủ lớn để ảnh hưởng đến toàn bộ dự án vì vậy giá trị của nó sẽ được cân nhắc nếu được lựa chọn.

Thực hiện một nút phá vỡ dòng chảy. Có thể không phải là một vấn đề lớn nếu hình thức có thể được đặt ra theo cách mà nút là tùy chọn. Tôi đã làm điều này rất trong thực tế. Tôi đã thêm nút nhưng cũng thu thập đủ thông tin trước khi bàn tay trở thành tùy chọn. Người dùng mong đợi nó sẽ được sử dụng và những người nhận ra rằng nó chỉ là không cần thiết.

Đó là tất cả về sự cân bằng và biết khi nào nên chọn trận chiến của bạn. Một số điều dễ dàng hơn để thực hiện dù sao so với việc xử lý các khía cạnh xã hội của việc không bao gồm nó.

Vấn đề tôi thấy là việc bạn sử dụng từ tranh luận.

Bạn phải đưa ra các vấn đề thiết kế và lý do đằng sau chúng, nhưng hãy cảnh giác vì các lập trình viên có xu hướng phòng thủ về các vị trí họ đã thực hiện và tranh luận điểm chỉ vì lý do tranh luận (Đôi khi). Tôi phải ngăn mình khỏi cãi nhau một chút - và tôi không luôn thành công. Ngoài ra, khi tôi già đi, tôi thấy mình sai thường xuyên hơn trước đây - hoặc tệ hơn là tôi không nhận ra mình thường xuyên sai như thế nào :)

Nếu bạn đã nêu rõ các yêu cầu (ngôn ngữ phải an toàn, chúng tôi cần con trỏ để truy cập các thói quen cũ) thì bạn có thể trình bày cách hai yêu cầu xung đột và hỏi cái nào quan trọng hơn. Khi bạn có các yêu cầu và lý do đằng sau chúng, bạn thậm chí có thể đưa ra một giải pháp hoàn toàn khác hỗ trợ cả hai yêu cầu (JNI - kinda).

Nếu không, có lẽ đây là thời điểm tốt để mã hóa chúng!

1. Nhận ra rằng bạn không biết tất cả mọi thứ và không thể làm mọi thứ.

2. Nếu bạn chắc chắn rằng đó là một ý tưởng tồi thì hãy nói những gì xấu.

3. Nếu họ cố gắng thúc đẩy bạn, hãy nói - Cần thêm thời gian để phân tích, nếu bạn cần thêm thời gian hoặc nói rằng chúng tôi chưa tìm được giải pháp tốt cho vấn đề này.

4. Nếu họ vẫn khăng khăng thực hiện ý tưởng tồi, hãy nhận được sự thừa nhận từ họ rằng bạn đã khuyên chống lại nó bao gồm cả lý do của bạn. Bạn thậm chí có thể gửi email tóm tắt cuộc thảo luận với một bản sao cho người quản lý của bạn. Điều này có thể tiết kiệm ** của bạn sau này.

Trong một kịch bản lý tưởng, bạn có một Nhà phát triển chính đưa ra quyết định cuối cùng về mặt kỹ thuật và Trưởng nhóm kinh doanh đưa ra quyết định cuối cùng về phía doanh nghiệp. Điều này sẽ trả lời hai câu hỏi chính:

1 cái gì? Khách hàng muốn gì?

2) Thế nào? Làm thế nào để chúng ta thực hiện điều này từ góc độ công nghệ.

Những gì khách hàng muốn là người ra quyết định cuối cùng vì họ là người trả các hóa đơn

Là một nhà phát triển, bạn không nên thực sự quan tâm những yêu cầu nào được yêu cầu thực hiện.

Tuy nhiên, bạn nên giải thích nếu một cái gì đó không thực tế và nếu có những cách tốt hơn.

Đôi khi yêu cầu khách hàng thực tế của nó (đến từ chính trị nội bộ của khách hàng). Sau đó, nó vô vọng và phải được thực hiện (nhưng ban quản lý cũng nên xem xét liệu tiếp tục dự án đó hay liệu họ có nên thương lượng lại giá hay không.)

Đây gần như là một nhiệm vụ hàng ngày đối với tôi, và trên thực tế tôi rất vui vì điều đó.

Nếu bạn có thay đổi để đưa ra ý kiến ​​của mình về việc một số yêu cầu nhất định nên hay không nên là một phần của ứng dụng, những người không có kỹ thuật sẽ mong đợi bạn điền vào kiến ​​thức kỹ thuật của mình (ví dụ: "sử dụng con trỏ sẽ làm cho ứng dụng không ổn định" hoặc "sử dụng tham số GET cho mục đích X là rủi ro bảo mật "). Nghiên cứu sinh kỹ thuật cũng sẽ đánh giá cao phản hồi của bạn về một số lợi thế hoặc sự không hài lòng cụ thể mà họ có thể không nghĩ tới.

Tất nhiên, thật khó khăn khi mọi người đều muốn có tính năng X và cuối cùng bạn nói "nó có thể không tốt", nhưng cuối cùng, mọi người đều cố gắng tạo ra một ứng dụng an toàn, mạnh mẽ và ổn định (có thể duy trì, linh hoạt, v.v ... ) và mọi giọng nói nên được tính.

Trả lời câu hỏi của bạn, đây không phải là một phần công việc của nhà phát triển (nghĩa là phát triển), nhưng đó là một "phần phụ" mang lại chất lượng và làm việc theo nhóm.

Nếu bạn ở vào vị trí để hiểu được nhược điểm của việc đó (phức tạp, thiếu khả năng sử dụng, v.v.), thì đó là lợi ích tốt nhất cho mọi người để bạn giải thích nó với khả năng tốt nhất của bạn. Thông thường những người không phải là nhà phát triển không hiểu vấn đề của việc thêm các tính năng mới. Thật dễ dàng cho họ vì họ không phải làm bất cứ điều gì hoặc thậm chí nghĩ về nó.

Tuy nhiên, nếu quyền hạn quyết định rằng tính năng mới sẽ được thêm vào, thì bạn nên thực hiện công việc tốt nhất có thể. Nó là một thử thách.

Và, nếu tính năng mới quá ngu ngốc hoặc môi trường làm việc quá nhảm nhí, thì đã đến lúc tìm một công việc khác.