Khi nào thì chấp nhận hy sinh sự gọn gàng của thiết kế để hoàn thành một dự án?

Khi làm việc trên một sản phẩm cần được hoàn thành sớm và hoạt động tốt, khi nào bạn có thể hy sinh khả năng bảo trì và "gọn gàng" của thiết kế để hoàn thành công việc một cách nhanh chóng? Và ở mức độ nào là ổn, đặc biệt là khi các kỹ thuật được sử dụng để làm cho nó "gọn gàng" là mới đối với tôi?

Hãy nhớ rằng bạn được tuyển dụng để hỗ trợ một doanh nghiệp. Theo một cách nào đó, phần mềm của bạn đang ảnh hưởng đến lợi nhuận của doanh nghiệp. Bạn cần đạt được sự cân bằng giữa một giải pháp hoàn hảo về mặt kỹ thuật và thời gian đưa ra thị trường sản phẩm của bạn và doanh nghiệp sẽ thu được bao nhiêu lợi ích từ nó.

Theo kinh nghiệm của tôi, các nhà phát triển thường cảm thấy lo lắng về sự hoàn hảo về kỹ thuật. Nhưng có những lý do rất hợp lệ để hy sinh các thuộc tính chất lượng như khả năng bảo trì hoặc hiệu suất để đưa sản phẩm ra khỏi cửa nhanh hơn. Nó phụ thuộc vào doanh nghiệp và sản phẩm. Nhưng "luôn luôn phấn đấu cho một thiết kế hoàn hảo" là một cách tiếp cận quá đơn giản.

Vào cuối ngày, điều duy nhất quan trọng là giá trị cho doanh nghiệp. Chỉ ra làm thế nào để tối đa hóa nó trong ngắn hạn và dài hạn và nhắm đến mục tiêu đó.

Thuật ngữ "nợ kỹ thuật" rất tiện dụng để giúp thông báo các quyết định kinh doanh như thế này. Bất kỳ công việc nào bạn không làm bây giờ sẽ gây ra một số lượng công việc sau này. Cũng giống như với tài chính, nhận nợ là rủi ro nhưng có thể đáng để tận dụng nếu bạn sẽ có thể trả nợ sau này.

Phải nói rằng, nợ kỹ thuật không phải là tỷ lệ 1: 1 tại thời điểm hoàn vốn. Lỗi đắt hơn để sửa chữa sau khi phát hành, và tác động đến năng suất trong tương lai khi phát triển từ một hệ thống di sản lộn xộn có thể gây khó chịu. Bạn có thể đang xem xét dành gấp đôi thời gian để sửa lỗi của mình, hoặc có thể gấp 1.000 lần số giờ và tài nguyên.

Công việc của bạn trong quyết định này là tìm hiểu sự phân nhánh của các phần cắt góc cụ thể mà bạn đang xem xét, và sau đó truyền đạt các phân nhánh đó cho những người đưa ra quyết định kinh doanh. Kỹ năng ước tính đặc biệt này có thể cần rất nhiều nghiên cứu và làm việc từ phía bạn để phát triển tốt ngay bây giờ, nhưng nó sẽ là vô giá trong sự nghiệp của bạn.

Khi nó được chấp nhận và hậu quả được hiểu bởi chủ sở hữu / khách hàng / người dùng.

Một thợ sửa ống nước phải đưa ra xử lý rác để sửa chữa. Tôi muốn sử dụng bồn rửa trong thời gian đó, nhưng anh ấy sẽ phải tính hóa đơn cho tôi về thời gian và vật liệu để đặt vào các đường ống tạm thời bằng cách sử dụng băng keo có thể vỡ. Điều này cũng sẽ trì hoãn việc xử lý trở lại cửa hàng sửa chữa. Nếu tôi chấp nhận thanh toán bổ sung với sự hiểu rằng tôi có nguy cơ bị tắc. Sẽ mất thêm một ngày để sửa chữa xử lý và sự chậm trễ thậm chí lâu hơn trước khi anh ta có thể đưa nó trở lại, đó là chấp nhận được.

Bạn có thể đúng giờ và ngân sách ngay bây giờ, nhưng hy sinh / rủi ro một khoản phí thậm chí cao hơn trong dài hạn. Điều này có thể khó hiểu để những người phi kỹ thuật hiểu, nhưng đó là những gì nhân viên bán hàng dành cho.

Rất nhiều người từ bỏ cách nhanh chóng khi học một cái gì đó mới và chỉ làm theo cách họ luôn làm. Nếu đây là một mô hình không chỉ mã của bạn sẽ bị ảnh hưởng mà các kỹ năng của bạn với tư cách là một lập trình viên sẽ vẫn còn hạn chế.

Tuy nhiên, vào cuối ngày, phần mềm duy nhất thành công là phần mềm được phát hành.

Sau khi thời hạn mềm đi qua. Và thậm chí sau đó nó là một mức độ "OK" rất thấp. Sau khi thời hạn khó khăn trôi qua, dĩ nhiên là phải tranh luận. Bởi vì đó là bản chất của thời hạn khó khăn.

Hơn nữa, điều này phát sinh nợ kỹ thuật. Đối với mỗi giờ / ngày bạn dành thời gian để cắt giảm tâm lý, điều đó sẽ khiến bạn tốn gấp đôi thời gian khi bạn phải chạm vào dự án này. Nếu bạn phải thì tốt nhất là vội vàng, giao hàng, và sau đó ngay lập tức bắt đầu sửa tất cả băng vịt của bạn. Trở lại với một dự án hack-eye năm sau là một cơn ác mộng. Nếu bạn sẽ không bao giờ chạm vào nó một lần nữa, vì vậy, không ai quan tâm. Nhưng lần duy nhất tôi rời khỏi một dự án nói dối mãi mãi là khi tôi chuyển việc.

Hãy nhớ rằng, thời gian những điều này là công việc của người quản lý dự án. Nếu bạn đang vội vã đáp ứng thời hạn, đó là lỗi của Thủ tướng. Làm đúng, làm một lần và làm một cách bình tĩnh và chính xác. Cuộc sống quá ngắn ngủi cho bất cứ điều gì khác.

Tất cả các câu trả lời khác được đăng ở đây là tốt. Tôi muốn thêm rằng mặc dù là một nhà phát triển trong dự án, bạn là người quản lý (người bảo vệ) của thiết kế.

Nếu bạn không ủng hộ giải pháp kỹ thuật phù hợp thì tôi sẽ không hứa với bạn. Bạn nên luôn luôn tranh luận để làm mọi việc đúng cách với sếp của bạn và Thủ tướng nên luôn luôn tranh luận có lợi cho thời hạn.

Hy vọng rằng nếu bạn ở trong một tổ chức hợp lý, một thỏa hiệp sẽ đạt được giúp đáp ứng thời hạn và cũng không đi quá xa thiết kế cùng một lúc.

Như đã nói, đừng cho rằng nếu thời hạn của Thủ tướng không đạt được thì thế giới sẽ kết thúc và dự án sẽ thất bại. Nó thường không phải là màu đen và trắng và hầu hết thời gian của PM là mềm và có chỗ để điều chỉnh.

Hầu như mọi thời hạn tôi từng theo lịch trình PM hầu hết là giả tạo. Tuy nhiên, họ sẽ bảo vệ răng và móng tay của mình và giả vờ khác bởi vì nếu Thủ tướng đẩy thời hạn thì PM LOOKS BAD!

Chỉ vì PM trông tệ không có nghĩa là dự án đã thất bại. Nếu bạn hiểu điều này, bạn sẽ ngạc nhiên khi bạn có thể nhận được một PM để uốn cong.

Trích dẫn khách hàng cho thiết kế gọn gàng. Nếu trích dẫn đó là không thể chấp nhận được đối với họ, thì hãy đi vào phân tích chi phí của từng thành phần (thường là chi phí == thời gian phát triển). Hãy để họ lấy đồ ra khỏi "a la carte" nếu họ chọn. Nhiều người sẽ nhảy vào lúc cạo râu vì những thứ "vô dụng" như thử nghiệm và thiết kế. Giải thích các rủi ro của phương pháp này, nhưng nếu họ chấp nhận rủi ro, thì tiến hành theo hướng dẫn. Nếu tôi chỉ có đủ tiền cho một chiếc xe clunker, thì tôi sẽ mua một chiếc xe clunker, ngay cả khi tôi biết nó có thể sẽ bị hỏng trong 8 tháng. Khách hàng của bạn có trách nhiệm cân nhắc những rủi ro này và chấp nhận hậu quả.

Một điều mà bạn không muốn làm là nói cho khách hàng nghĩ rằng họ có một phần mềm được thiết kế đẹp mắt, khi họ chỉ trả tiền cho (và nhận) một mẩu rác chưa được kiểm tra. Nếu có gì đó không ổn (có thể sẽ xảy ra), trong kịch bản đầu tiên, chúng sẽ trông tệ, nhưng trong kịch bản thứ hai, bạn sẽ trông tệ.

Không bao giờ ổn, nhưng đôi khi bạn phải thỏa hiệp để hoàn thành một dự án. Một thực tế đáng buồn là hầu hết các doanh nhân hoàn toàn không biết gì và sẵn sàng hy sinh khả năng duy trì sau này cho một cái gì đó ngay bây giờ. Bí quyết là biết cách đạt được sự cân bằng; có thể dự án sẽ không gọn gàng như nó có thể, nhưng miễn là nó không phải là một con heo đất thì đó là một sự thỏa hiệp xứng đáng.

Điều đó hoàn toàn phụ thuộc vào câu hỏi "Bạn hoặc bất kỳ ai khác có thể hình dung muốn sửa đổi nó sau này?" Nếu có, bạn nên cố gắng có một thiết kế "gọn gàng", nếu không bạn có nguy cơ phải vứt bỏ mọi thứ và bắt đầu lại 6 tháng sau.

Tất nhiên, bạn có thể mất sự gọn gàng quá xa, nhưng nói chung một chút gọn gàng sẽ giúp bạn tiết kiệm công việc sau này.