Là những dấu hiệu của một nhà phát triển xấu? [đóng cửa]

Tôi đã từng đổ lỗi cho việc thay đổi thông số kỹ thuật từ khách hàng để thối mã, không nhận ra rằng các mô hình kinh doanh thay đổi và đó là công việc của tôi để phát triển theo cách thích nghi. Bây giờ tôi thấy đó là dấu hiệu của một nhà phát triển tồi (tôi đã thay đổi!).

Nhưng bây giờ tôi thấy những "tiếng rên rỉ" khác trong bản thân mình. Một vài lần gần đây tôi thấy mình nói rằng 'nó giống như cố gắng lắp một cái chốt vuông vào một cái lỗ tròn', và tôi cũng thấy mình đổ lỗi cho sự thiếu quyết đoán của khách hàng đối với một dự án không tiến triển.

Có dấu hiệu nào tôi nên để ý xem tôi nên thay đổi thái độ ở đâu không? Là khách hàng luôn luôn đúng, hoặc đôi khi tôi có lý khi nhận được sự thất vọng?

Tôi sẽ không nói bạn là nhà phát triển tồi. Nhận thức được các vấn đề đã đưa bạn vượt ra ngoài định nghĩa này.

Yêu cầu thay đổi. Đó là một cho trước. Một nhà phát triển tốt cần phải tính đến điều này. Nhiều kỹ thuật lập trình hiện đại giúp đối phó với điều đó.

Sống đúng với thông số ban đầu là không thực tế. Cũng không thực tế là thay đổi các yêu cầu tất cả các thời gian.

Khách hàng chắc chắn không phải lúc nào cũng đúng. Tuy nhiên, đó là "quyền" thường xuyên hơn chúng ta muốn anh ấy / cô ấy trở thành (như trong, cố gắng thích nghi với anh ấy nếu anh ấy không hoàn toàn tắt). Nhưng khi bạn thấy anh ấy lái dự án sai hướng, hãy cố gắng biện hộ cho những điều bạn cho là đúng.

Không có quy tắc cứng nào về những điều này, và ngay cả những nhà phát triển giỏi và có kinh nghiệm cũng không đạt được 'Zen' hoàn hảo. Cách tiếp cận sai duy nhất là không cố gắng cải thiện những điều này.

Có những trường hợp nó là khách hàng. Nhưng đó cũng là vấn đề của bạn

Có những trường hợp nó là nhà phát triển, và có những trường hợp, đó là khách hàng. Nhưng, thông thường, cả hai đều là vấn đề của bạn , vì vậy thái độ đổ lỗi cho bản thân có xu hướng thành công hơn, bởi vì nó sai ở khía cạnh giải quyết vấn đề thay vì chỉ tay bất lực. Do đó, bạn sẽ thường tìm thấy nó ở các nhà phát triển có kinh nghiệm hơn.

Một thái độ thậm chí còn tốt hơn là IMHO nhìn vào nó mà không đổ lỗi: "đó là lỗi của khách hàng tôi có mã tệ hại, bởi vì anh ta luôn thay đổi yêu cầu" sau đó trở thành "khách hàng này đang tìm ra những gì anh ta muốn, vì vậy phản hồi, tạo mẫu nhanh và linh hoạt hơn quan trọng hơn sự hoàn thiện, mạnh mẽ và tốc độ ".

Một loại tâm trí: đừng phán xét nó, hãy xem nó như thế.

Đầu tiên, một khách hàng không biết họ muốn gì cho đến khi họ nhìn thấy nó. Đó là một phần của sự hấp dẫn của các bước lặp nhỏ của mô hình Agile với sự tham gia của khách hàng nặng nề. Thứ hai, đừng mong đợi một sản phẩm sẽ "hoàn thành" khi bạn hoàn thành mã.

Microsoft sử dụng một sản phẩm có tên 'Watson' (thông điệp gửi phản hồi bạn nhận được khi cửa sổ bật lên) để theo dõi các vấn đề trực tiếp trở lại máy khách. Truy xuất nguồn gốc là một cách tốt để theo dõi các vấn đề trở lại với người dùng trải nghiệm chúng. Bạn có thể nhận được truy xuất nguồn gốc bằng cách hỏi. Hoặc, nếu bạn có tài nguyên, hãy tích hợp chức năng vào (các) sản phẩm. Điều quan trọng là theo dõi các vấn đề / cải tiến để chúng có thể được giải quyết.

Cuối cùng, chắc chắn khách hàng có thể hay thay đổi. Trong những trường hợp như vậy, tôi cố gắng tập trung vào bí mật tảng băng trôi .

Thay đổi yêu cầu là một thực tế khó khăn của cuộc sống; nhưng mã thối không phải do đó.

Thối mã xảy ra khi có một số phần trong mã của bạn mà bạn không tập thể dục thường xuyên; Vì vậy, khi bạn thực hiện một số thay đổi "không ảnh hưởng đến bất cứ điều gì khác", bạn có thể đưa ra các lỗi. Nói cách khác, mã không thấy ánh sáng ban ngày bị phân hủy chậm và bạn không thể nói khi nào nó ngừng hoạt động.

Vâng, đó là lỗi của bạn chứ không phải người dùng của bạn.

Giải pháp thực sự? kiểm tra tất cả mã của bạn thường xuyên. Tất nhiên, cách tốt nhất là có các bài kiểm tra tự động với độ bao phủ tốt.

Sự thiếu quyết đoán của khách hàng có thể là một vấn đề lớn và nếu bạn không phải là người chịu trách nhiệm quản lý mối quan hệ khách hàng thì có thể rất khó giải quyết. Bạn có thể nói chuyện với người giao dịch với khách hàng và bình tĩnh giải thích rằng tiến trình không thể xảy ra cho đến khi khách hàng đưa ra quyết định. Nếu bạn đang phụ trách các mối quan hệ khách hàng, bạn phải nói với khách hàng rằng họ cần phải đưa ra quyết định trước khi dự án có thể tiếp tục. Nó có thể không phải là thái độ của bạn cần một cuộc đại tu, chỉ cần một phút thiền để bình tĩnh. ;)

Xì gà đưa ra một điểm tốt là thay đổi yêu cầu là một thực tế khó khăn của cuộc sống. Tôi cũng cảm thấy thất vọng vì những tình huống này vì quá thường xuyên, tôi thấy mình đang làm việc trên một sản phẩm mà nhà phát triển phải đưa ra quyết định. Ý kiến ​​của tôi từng là "Tại sao quản lý không thể tìm ra điều này với khách hàng?" Hoặc "Tại sao chúng tôi bắt đầu dự án này nếu khách hàng không biết họ muốn gì?", "Thật đau đầu khi họ thay đổi muộn trong sự phát triển ".

Thực tế đơn giản: điều này sẽ luôn xảy ra, không chỉ trong lập trình / phát triển phần mềm mà trong mọi bước đi của cuộc sống. Thế giới đơn giản sẽ là một nơi rất nhàm chán và rất khác biệt nếu mọi người không bao giờ thay đổi suy nghĩ, không bao giờ thích nghi, không bao giờ giải quyết thay đổi. Mọi người có xu hướng nhìn vào những gì họ được đưa ra và cải thiện nó. Bạn không làm điều tương tự với mã của bạn? Nếu tôi có một khối mã mà tôi không hài lòng (nó không hiệu quả, lộn xộn), tôi sẽ cải thiện nó. (Hệ điều hành có phàn nàn với tôi không? ... đôi khi, nếu tôi đang sử dụng một hệ điều hành không tên nào đó, nhưng nói chung là không)

Là lập trình viên, chúng ta cần nắm bắt cơ hội để cải thiện mọi thứ, và không bị trầm cảm hay khó chịu bởi chúng. Tận dụng cơ hội để nói chuyện với mọi người, cải thiện phong cách của bạn, cải thiện đạo đức làm việc của bạn, tiếp cận mọi thứ với một tâm trí cởi mở, thúc đẩy bản thân trở nên tốt hơn bạn ngày hôm qua. Tiến lên trong sự nghiệp của bạn và không giải quyết quá dễ dàng.

Tôi hiểu rằng không phải ai cũng đồng ý với câu trả lời này nhưng tôi nghĩ điều quan trọng là các câu trả lời cho câu hỏi này bao quát một viễn cảnh rộng hơn.

Khi bạn tương tác với khách hàng, bạn không lập trình; bạn đang học và dạy

Giữ cho khách hàng thông báo và giáo dục họ về quá trình. Thay đổi sẽ xảy ra. Hãy cho họ biết bạn sẽ cố gắng thực hiện chúng, nhưng sẽ tốn kém hơn. Hãy để họ quyết định.

Đừng đi sâu vào chi tiết kỹ thuật ngay cả khi câu hỏi họ hỏi có bản chất kỹ thuật. Bạn bị cám dỗ bởi vì bạn sẽ cảm thấy một chút phòng thủ và sẽ muốn tham gia một thử thách / nhận được sự đam mê của bạn. Đừng làm điều đó; họ không quan tâm đến các chi tiết và sẽ ngừng nghe sau 45 giây.

Nếu bạn không nói với họ trước thời hạn, đừng mong họ biết về các tiêu chuẩn ngành và thực tiễn tốt nhất hoặc bất kỳ lý do nào khác để làm những gì bạn làm. Tôi ghét nó khi tôi không thấy một khoản phí nào cho đến khi kết thúc chỉ để nhân viên bán hàng nói với tôi rằng đó là tiêu chuẩn trong ngành. Tôi không nên mong đợi để biết điều đó. Câu trả lời của tôi là "Làm cho tôi cảm thấy như một thằng ngốc cũng là một tiêu chuẩn?"

Khi bạn ở cùng khách hàng, hãy chú ý đến họ hơn bất kỳ ai hoặc bất cứ điều gì khác trong phòng. Chó thuần hóa là thiên tài về điều này; đặc biệt là nếu bạn có thức ăn

Đó là quản lý yêu cầu xấu hoặc phân tích xấu. Nhà phân tích kinh doanh của bạn (nếu bạn có) hoặc bất cứ ai có yêu cầu cần phải ngồi với khách hàng và cố gắng đạt được tất cả các yêu cầu, ngay cả những yêu cầu mà khách hàng có thể không nghĩ tới. Khách hàng thường không biết mọi thứ họ muốn, một nhà phân tích kinh doanh tuyệt vời sẽ giúp họ tìm ra tất cả.

Đây là lý do tại sao bạn phải luôn luôn thiết lập Tài liệu Yêu cầu Kinh doanh và đăng xuất trước khi bất kỳ ứng dụng nào vượt quá giai đoạn tạo mẫu / nghiên cứu.

Bây giờ, ý tưởng rằng tài liệu này thực sự là cuối cùng bị lỗi, nhưng điều này sẽ giúp bạn có được một ý tưởng tốt hơn về những gì khách hàng thực sự muốn. Và miễn là bạn viết mã với khả năng duy trì trong tâm trí, bạn có thể giữ các vấn đề của mình ở mức tối thiểu.

Và nếu bạn cần một cái cớ để quay trở lại, bạn có thể đổ lỗi cho bất kỳ sự chậm trễ nào trên BRD, rằng khách hàng đã đăng xuất, không bao gồm tính năng như vậy và như vậy, v.v.

(Tất nhiên, đây chỉ là một cái cớ trong trường hợp bạn cần nó. Bạn nên luôn luôn lên kế hoạch cho họ thay đổi một cái gì đó )

Trong trích dẫn của Emerson, "Một sự nhất quán ngu ngốc là hobgoblin của những bộ óc nhỏ bé ..." từ thường bị bỏ qua nhất là ngu ngốc . Tính nhất quán là không thể thương lượng trong một số cài đặt nhất định, nhưng tất cả thường thay thế cho tư duy phê phán và phân tích.

Một mặt, nhiều mô hình phát triển được thiết kế đặc biệt để trợ giúp trong môi trường bạn mô tả; Vì vậy, nếu bạn thấy mình phải vi phạm mô hình của mình, thì ngay từ đầu bạn đã không triển khai nó ngay hoặc bạn đã có mô hình sai.

Nhưng mặt khác, nếu bạn có một lý do hợp lý và có thể hỗ trợ cho việc vi phạm các quy tắc của mình và bạn có thể chỉ ra rằng phương pháp lừa đảo của bạn tạo ra mã dễ bảo trì hơn, thì bạn không nên sợ đi theo con đường hợp lý.