Làm thế nào tôi có thể thuyết phục ban quản lý xử lý nợ kỹ thuật?


158

Đây là một câu hỏi mà tôi thường tự hỏi khi làm việc với các nhà phát triển. Cho đến nay tôi đã làm việc tại bốn công ty và tôi nhận thấy sự thiếu chú ý trong việc giữ sạch mã và xử lý nợ kỹ thuật cản trở tiến trình trong tương lai trong một ứng dụng phần mềm. Ví dụ, công ty đầu tiên tôi làm việc đã viết một cơ sở dữ liệu từ đầu thay vì sử dụng một cái gì đó như MySQL và điều đó đã tạo ra địa ngục cho nhóm khi tái cấu trúc hoặc mở rộng ứng dụng. Tôi đã luôn cố gắng trung thực và rõ ràng với người quản lý của mình khi anh ấy thảo luận về các dự đoán, nhưng quản lý dường như không quan tâm đến việc sửa chữa những gì đã có và thật kinh khủng khi thấy tác động của nó đối với tinh thần đồng đội.

Suy nghĩ của bạn về cách tốt nhất để giải quyết vấn đề này là gì? Những gì tôi đã thấy là mọi người đóng gói và rời đi. Công ty sau đó trở thành một cánh cửa quay vòng với các nhà phát triển ra vào và làm cho mã trở nên tồi tệ hơn. Làm thế nào để bạn truyền đạt điều này đến quản lý để khiến họ quan tâm đến việc phân loại nợ kỹ thuật ?


5
"Làm việc với các nhà phát triển" "truyền đạt điều này đến quản lý" Bạn đang hỏi về vấn đề gì? Nhà phát triển hay nhà quản lý? Bạn muốn thay đổi hành vi của ai?
S.Lott

45
Nợ kỹ thuật giống như nợ tài chính - về lâu dài sẽ dễ dàng hơn nhiều khi không tích lũy nó để bắt đầu. Thanh toán tất cả các hóa đơn kỹ thuật của bạn một lần một tuần.
Lawrence Dol

7
Mike> Tôi nghĩ rằng bạn sống trong thế giới hạn chế hơn nhiều vì thời hạn và ngân sách hạn chế thống trị thế giới tôi đang sống. Nếu phần mềm không thích ứng tốt với nhu cầu trong tương lai và cần nhiều công việc để khắc phục, thì quản lý thường quan tâm nhiều hơn đến việc bỏ qua nó và tiếp tục củng cố các tính năng. Bây giờ rất nhiều bạn đồng hành tôi đã làm việc đưa ra bảng chấm công để các nhà phát triển cần ghi lại công việc của họ và nếu thời gian không được đầu tư vào nơi quản lý nhìn thấy doanh nghiệp tiềm năng, thì bạn đang lãng phí thời gian.
Hành tinh hoang vắng

4
Tôi đoán bạn có thể nói đó là một vấn đề với lợi ích ngắn hạn so với lợi ích dài hạn. Nếu một nhóm phần mềm dọn dẹp một hệ thống theo cách mà các tính năng mới mất dưới một giờ để thực hiện thay vì một ngày, đó là một lợi ích ngay lập tức. Nếu quản lý thấy bạn đang cố gắng cải thiện mã và đi ngược lại những gì họ muốn, thì bạn đang là một kẻ nổi loạn trong mắt họ. Tôi thực sự không biết giải pháp tốt nhất là gì, nhưng có vẻ như đây là một vấn đề phổ biến và tôi đã thấy những gì nó làm cho các đội.
Hành tinh hoang vắng

3
Scott> Để trả lời câu hỏi, đó là thái độ quản lý mà tôi muốn thay đổi. Các nhà phát triển biết mã và có kinh nghiệm đầu tiên về việc mã nào sẽ được cải thiện để làm cho mọi thứ dễ dàng hơn. Trong một công việc trước đây khi chúng tôi phát hành phiên bản mới của một ứng dụng, số lượng lỗi tiếp tục tăng với tốc độ khủng khiếp. Tôi đã cố gắng hết sức để có được các chiến lược thử nghiệm tại chỗ, nhưng nó thường cảm thấy như một nguyên nhân bị mất.
Hành tinh hoang vắng

Câu trả lời:


191

Khi tôi gặp ông chủ của mình để thảo luận về vấn đề này, ông nói rằng tôi nên bao gồm việc tái cấu trúc trong tất cả các ước tính của mình. Anh ấy nói đó không phải là vấn đề anh ấy muốn nghĩ đến. Thay vào đó, tôi nên xử lý nó.

Đây không phải là một vấn đề mà quản lý nói chung muốn nghĩ đến. Họ không phải là kỹ sư. Chỉ cần biến điều này thành một phần chưa được nói trong tất cả các ước tính của bạn và bạn sẽ thấy rằng nợ kỹ thuật giảm.

Nó sẽ không bao giờ hoàn hảo mặc dù. Nợ kỹ thuật, giống như nợ thẻ tín dụng, là một khoản đầu tư để có được khách hàng nhanh hơn và giành thị phần so với đối thủ của bạn nhanh hơn. Giống như tín dụng, nếu được quản lý đúng cách, nó có thể khiến bạn khá thành công.


30
kinh nghiệm của tôi nói chung là dọc theo dòng này. Các khoản nợ kỹ thuật được làm sạch khi các tính năng mới được thêm vào. Đôi khi, các ước tính cho các bản sửa lỗi / tính năng 'liên quan' nhất định được đệm để bao gồm dọn dẹp những thứ này.
Ken Henderson

4
+1 Bạn chia sẻ chính xác tình cảm của tôi ... ngoại trừ bạn thể hiện bản thân một cách ngoại giao hơn nhiều;)
Michael Brown

7
Câu trả lời tốt. Tôi vẫn chưa thấy một doanh nghiệp vui mừng ký kết một dự án 'tái cấu trúc' sẽ không mang lại lợi ích gì cho khách hàng, chỉ có mã gọn gàng hơn. Tái cấu trúc như bạn đi.
JBRWilkinson

7
"Khi tôi gặp ông chủ của mình để thảo luận về vấn đề này, ông nói rằng tôi nên bao gồm việc tái cấu trúc trong tất cả các ước tính của mình." - Đây là thái độ của tôi và lập trường của nhiều nhà phát triển trong các đội tôi đã làm việc. Tuy nhiên, khi 9 đến 5 nhà phát triển như chúng tôi gọi họ quan tâm đến đánh giá của họ và tăng lương, họ sẽ không tạo ra nhiều công việc hơn cho chính họ. Rốt cuộc, họ sẽ làm theo bất cứ điều gì quản lý nghĩ, đó là người trả tiền cho họ.
Hành tinh hoang vắng

8
@ jmort253: có một vấn đề (nhẹ) với chính sách tuyệt vời này -> không thể thay đổi rộng rãi (nghĩa là thay đổi cơ sở dữ liệu như OP đã nói). Những người phải được giải quyết rõ ràng.
Matthieu M.

48

Giống như Gandhi đã nói khi được hỏi liệu chiến thuật của anh ta có hiệu quả với một người như Hitler không. Ông nói, "Nó sẽ khó khăn." Nhưng tôi nghĩ có một lập luận công bằng rằng câu trả lời thực sự là "Không". Đáng buồn thay, tôi không nghĩ những gì bạn đang cố gắng có thể được thực hiện. Không phải là tôi đang cố tỏ ra bi quan, mà là tôi đang cố gắng thành thật.

Vấn đề với tôi không phải là các nhà quản lý cần thuyết phục. Những người tốt hơn đã hiểu rằng nợ có thể là một kẻ giết người nếu không được quản lý. Nhưng cho dù họ có hiểu hay không, dù họ là người quản lý tốt hay xấu, tất cả họ đều phải đối mặt với áp lực giao hàng, và việc giao hàng đó được đánh giá bởi ông chủ của họ trước một ngày. Chất lượng chỉ quan trọng nếu nó cực kỳ xấu, trong trường hợp đó là lỗi của nhà phát triển, hoặc cực kỳ tốt, trong trường hợp đó là sự sáng chói trong quản lý đã khiến điều đó xảy ra. Chất lượng chỉ cần là "đủ tốt."

Tôi nghĩ rằng tôi thích những gì Renesis nói trong câu trả lời của anh ấy, bởi vì đó là một trong số ít người hiểu rằng quản lý nghĩ rất khác so với kỹ thuật. Và tôi nghĩ rằng tất cả chúng ta đã thấy sự phát triển của các công ty để trở thành định hướng theo ngày và được quản lý dự án nhiều hơn so với khách hàng và chất lượng tập trung. Bằng cách này, ý tôi là các công ty điển hình, không phải là những công ty thực sự mạnh mẽ có can đảm để nói "Nó sẽ được thực hiện khi nó hoàn thành" (như Apple Computer hoặc id Software - và vâng, tôi hiểu rằng đôi khi mọi người không tự do để có cách tiếp cận đó).

Nhưng đây là điều: các công ty thực hiện phương pháp chất lượng đầu tiên ... bạn chú ý điều gì về họ? Đúng vậy, họ được điều hành bởi các kỹ sư, không phải nhân viên bán hàng, tiếp thị, quản lý dự án hoặc kế toán. Hãy nghĩ về HP, Apple, id, Google, Microsoft và IBM. Tất cả bắt đầu và thành công bởi các kỹ sư, không phải nhân viên bán hàng, mặc dù nhân viên bán hàng chắc chắn đã đóng góp một phần và tôi chắc chắn nhiều người sẽ tranh luận về việc Microsoft có liên quan đến chất lượng :). Và trong số đó, những người đã xuống dốc đã thoát khỏi sự lãnh đạo theo hướng kỹ thuật. Mặc dù vậy, có rất nhiều tranh luận trong tuyên bố đó, vì có rất nhiều công ty kỹ thuật cuối cùng đã thất bại do không thể thích nghi với việc thay đổi thời gian và quản lý sự tăng trưởng của chính họ. Tôi không thấy lãnh đạo dựa trên kỹ thuật là nguyên nhân cho những thất bại đó, với tôi rằng ' là một vấn đề về kỹ năng và sự nhạy bén trong kinh doanh độc lập với ai đó là nhà phát triển hoặc kế toán viên. Tôi nghĩ nói chung, tuy nhiên, có một sự cống hiến trong kỹ thuật đối với sự khắt khe về trách nhiệm và kỷ luật có lợi cho các công ty nơi kỹ thuật là một thành phần.

Nghiêm túc, nhìn xung quanh. Lãnh đạo CNTT đang rất thiếu. Tập trung luôn là chi phí và thời gian, và hiếm khi về chất lượng miễn là nó đủ tốt. Các nhà lãnh đạo CNTT hiếm khi báo cáo với CEO nữa, giờ đây luôn là CFO. CNTT bị mắc kẹt trong việc hỗ trợ sản xuất và ngày càng chú ý đến các nhà quản lý dự án, những người tập trung vào các phần nhỏ hơn, dễ tiêu hóa hơn và có thể đo lường được, không thay đổi đáng kể giá trị cách mạng (không phải điều này là sai; chia rẽ và chinh phục là một điều tốt, nhưng tầm nhìn cần phải có mặt cho bức tranh lớn).

Xin lỗi vì mất quá nhiều thời gian cho bài đăng này, nhưng cuối cùng tôi nghĩ câu hỏi của bạn, về cách làm cho quản lý quan tâm đến nợ kỹ thuật, thường được giải quyết tốt hơn bằng cách tìm đúng nhà lãnh đạo, thay vì thay đổi người hiện có. Giải thích nợ kỹ thuật cho các nhà tư tưởng tiêu chuẩn có nghĩa là thay đổi trọng tâm thành tiền và chi phí, như Renesis đã nói, và tôi nghĩ rằng mất rất nhiều trong dịch thuật; ngay cả khi bạn đã thành công với nó, nó sẽ chỉ quan trọng nếu nhà lãnh đạo cao nhất trong công ty mua nó. Thuyết phục người quản lý cấp trung của bạn làm điều đúng đắn có lẽ sẽ chỉ khiến anh ta bị sa thải.


43

Điều đầu tiên cần làm là thay đổi từ ngữ. Gọi nó là "nợ kỹ thuật" mang lại cho ban lãnh đạo ý tưởng cho phép nó là một khoản đầu tư thuộc loại nào đó - khi thực sự nó giống như một loại virus. (Tôi giống như Dave Ramsey của nợ kỹ thuật.)

Cho phép nó không được trả tiền đi kèm với một chi phí lớn không thể nhìn thấy hoặc dễ dàng định lượng.

Liệt kê các vấn đề như sau để quản lý:

  • Ước tính tính năng mới cao hơn mức cần thiết. Hoặc, không thể hoàn toàn.
  • Mã xấu sinh ra nhiều mã xấu hơn
  • Danh sách lỗi phát triển ngay cả khi các nhà phát triển luôn sửa chúng
  • Các thành viên trong nhóm đang rời đi (điều này có thể cho thấy rằng có một vấn đề như được giải thích trong câu trả lời xuất sắc này )

7
+1, mặc dù tôi nghĩ viên đạn cuối cùng phải là "Các thành viên tốt nhất / tốt nhất đang rời đi"
Ken Henderson

12
Nợ kỹ thuật bit đôi khi một khoản đầu tư. Nếu bạn đang chạy đua với một công ty khác và những người ra mắt trước tiên sẽ có được thị trường cho chính họ, thì sẽ rất hợp lý khi tạo các phím tắt trong mã để khởi chạy nhanh hơn. Không ai quan tâm rằng bạn có mã hoàn hảo nếu bạn không có khách hàng trả tiền.
quant_dev

3
@quant_dev nếu bạn thấy đây là sự phân đôi giữa "nhanh hơn" và "mã hoàn hảo" thì tất nhiên bạn sẽ nghĩ như vậy. Không có lý do tại sao các phím tắt không thể nghe có vẻ kỹ thuật trong trường hợp chúng không được coi là nợ kỹ thuật.
Nicole

2
@Renesis "Không có lý do tại sao các phím tắt không thể là âm thanh kỹ thuật" - điều đó không đúng.
quant_dev

3
Và đôi khi nó hoàn toàn không phải là nợ kỹ thuật, nó chỉ là một mớ hỗn độn: các trang
web.google.com/site/unclebobconsultingllc/ mẹo

30

Quản lý của tôi đã thực sự bắt đầu nỗ lực nghiêm túc để giải quyết nợ kỹ thuật, đó là một trong những lý do tôi thích làm việc ở đó, nhưng đó là một nỗ lực lâu dài và không bao giờ đau lòng để nhắc nhở họ tại sao nỗ lực đó đáng giá.

Một cách để tôi duy trì áp lực là bất cứ khi nào tôi được yêu cầu ước tính và thời gian có thể được tiết kiệm nếu tôi không phải giải quyết các vấn đề nợ kỹ thuật cụ thể, tôi đưa điều đó vào ước tính của mình . Ví dụ: " Lỗi này sẽ khiến tôi mất 2-3 ngày để theo dõi, nhưng nếu chúng tôi đã xử lý 2 lỗi 'ưu tiên thấp' khác này đã tồn tại mãi mãi, thì có lẽ sẽ mất ít hơn một. " câu trả lời sẽ được tiếp tục và sửa chữa những cái khác trong khi bạn đang ở đó.

Tôi cũng đồng ý với các câu trả lời khác về việc chỉ xem xét cải thiện một phần công việc của bạn và thực hiện chúng khi bạn đi nếu nó không quá đột phá. Nhiệm vụ hiện tại của tôi liên quan đến việc bổ sung một số mã được thiết kế rất kém. Thay vì thêm vào mớ hỗn độn bằng cách viết mã mới của mình để khớp, tôi dành một chút thời gian để củng cố chức năng chung, vì vậy việc gửi gói trở thành một cuộc gọi chức năng một dòng thay vì liên tục lặp lại 15 dòng sao chép và sửa đổi đôi chút dán nồi hơi.

Tôi biết thực tế là nó sẽ cứu được sự tỉnh táo của một số người bảo trì hơn nữa trên đường. Tôi biết bởi vì tôi là người duy trì ngày hôm nay. Tuy nhiên, tôi cũng tin rằng nó sẽ tăng tốc nhiệm vụ hiện tại của riêng tôi là đưa tính năng này vào và gỡ lỗi ngay bây giờ.

Một kỹ thuật khác mà tôi đã sử dụng trong quá khứ và nên làm lại là giữ một nhánh tái cấu trúc DVCS xung quanh trong một cây làm việc riêng biệt trong thời gian đó khi bạn biên dịch, chờ một bài kiểm tra dài hoặc chỉ cần thay đổi tốc độ cho một chút khi bạn bị đốt cháy trên một lỗi. Miễn là bạn thỉnh thoảng hợp nhất từ ​​thượng nguồn để bạn không phân kỳ quá xa, bạn có thể mất bao lâu bạn muốn tái cấu trúc các thay đổi với rất ít nỗ lực cận biên. 15 phút ở đây và mỗi ngày có thể thực sự cộng dồn theo thời gian.


20

Bạn có thể thử tương tự thẻ tín dụng. Hỏi họ "bạn có cảm thấy thoải mái khi để sao kê thẻ tín dụng của bạn không được trả tiền trong một khoảng thời gian dài không?"

Các nhà quản lý hiểu chi phí và lợi ích, nhưng (thường) không phải là các thuật ngữ kỹ thuật được sử dụng bởi các nhà phát triển của chúng tôi. Thuật ngữ "nợ kỹ thuật" đã được phát minh để giúp vượt qua rào cản giao tiếp này, nhưng bạn có thể cần phải nói rõ hơn. Hầu hết các nhà quản lý đều biết rất rõ (thường là từ kinh nghiệm của chính mình) rằng các khoản thanh toán bằng thẻ tín dụng quá hạn tăng với lãi suất khủng khiếp nên thật đau lòng khi để chúng không được trả. Điều này có thể giúp họ có được sự nghiêm trọng của vấn đề liên quan đến entropy phần mềm.

Nhưng nếu điều này không thuyết phục được họ, hãy cố gắng thu thập bằng chứng thực tế và thực hiện một số tính toán. Ví dụ, chi phí cho công ty là bao nhiêu - cả bằng tiền mặt cứng và mất thời gian - để thay thế một nhân viên rời đi.


12

Không ai sẽ đưa tiền cho việc thay thế một thứ gì đó hoạt động bằng thứ khác mà (với bất kỳ may mắn nào) cũng hoạt động.

Những gì bạn có thể làm là đề xuất thay thế nó bằng một cái gì đó nhiều hơn, tức là gói dịch vụ nợ công nghệ thành một bản nâng cấp mang lại lợi ích kinh doanh tức thời và hữu hình.

Tất nhiên bạn nên cởi mở về nó, chúng tôi không nói về việc "lén lút" trong một dự án mới ở đây.

Tôi thấy mặt khác, khó xử lý hơn của các nhà phát triển. Về cơ bản, nó hiểu rõ điều này: đối với một số nhà phát triển, đảm bảo mã của bạn là mã tốt nhất có thể bạn có thể là một vấn đề đáng tự hào chuyên nghiệp. Đối với những người khác, đây chỉ là một công việc khác và mục đích là để hoàn thành nó nhanh chóng và về nhà.

Không có sức thuyết phục nào sẽ thay đổi tình huống đó và nếu bạn đưa ra một tiêu chuẩn chất lượng mã bắt buộc, các nhà phát triển chín đến năm của bạn sẽ tìm ra cách để làm việc với hệ thống, trong khi các nhà phát triển chuyên dụng của bạn chắc chắn sẽ bị làm phiền bởi toàn bộ quy trình Không nhắm vào họ, nhưng bạn không thể nói rằng nhà phát triển X phải tuân thủ các quy tắc, trong khi Y có thể làm bất cứ điều gì anh ta muốn).

Những gì hoạt động, nhưng vẫn có thể rất bực bội là để các nhà phát triển tận tâm và hiểu biết hơn của bạn giám sát cơ sở mã, có lẽ là một sự đánh đổi tốt giữa việc tiến lên và thu dọn những gì đang xảy ra ở đó.


5
+1 Nhưng 9-5 nhà phát triển đó, tốt, bạn muốn cánh cửa quay vòng cho họ, lý tưởng nhất là với một số hình thức tăng tốc.
Orble

3
@ Tổ chức: +1. Nếu họ không quan tâm đầy đủ, họ thực sự nên làm việc ở một nơi khác. TUYỆT VỜI của nó có các nhà phát triển đến với bạn với "Tôi chỉ có ý tưởng này ...".
quick_now

3
@ Tổ chức Trong một số lĩnh vực phát triển nhất định, chúng có thể hữu ích. Tôi hoàn toàn không phải là một fan hâm mộ của "hợm hĩnh nhà phát triển", nhưng bạn phải tìm ra sở trường của mọi người để họ có thể sử dụng. Điều tồi tệ nhất bạn có thể làm là giả sử mọi người giống bạn.
biziclop

Cá nhân, tôi nghĩ rằng ngành công nghiệp đang bị cường điệu hóa. Nơi tôi làm việc dựa trên hầu hết các công việc phần mềm có được 300 ứng viên tốt áp dụng những ngày này. Với mức độ cạnh tranh đó, một người sử dụng lao động có thể đủ khả năng thuê những người sử dụng lao động đi xa hơn và tốt hơn mức trung bình.
Orble

"Nâng cấp nâng cấp thành tái cấu trúc để mang lại lợi ích hữu hình (điểm bán)" là những gì tôi nghe được từ Kiến trúc sư trưởng của chúng tôi, vì vậy tôi sẽ phải thứ hai.
Mario T. Lanza

12

Thực tế là, trong rất nhiều công ty, đặc biệt với tình hình kinh tế hiện tại, mỗi giờ phải được lập hóa đơn cho ai đó.

Hoặc họ đi xuống, nhanh lên .

Trừ khi các khách hàng hiện tại sẵn sàng trả tiền cho việc tái cấu trúc, điều này rất khó xảy ra trừ khi nó đi kèm với hiệu suất hoặc tính năng được nâng cấp đáng kể. Sau đó, nó sẽ không xảy ra trên các cơ sở mã cũ. Bạn có thể lẻn vào ngân sách cho các dự án mới hơn, nếu khách hàng có túi sâu, nhưng trừ khi bạn không cần thay đổi API trong tái cấu trúc, nó sẽ không được sử dụng cho các dự án cũ hơn và cũng có thể giới thiệu tình hình mà công ty đang hỗ trợ hai cơ sở mã hóa, điều này gây ra đau đầu và chi phí hơn nữa.

Là một kỹ sư, tôi rất thích cấu trúc lại mã cũ, không còn thực sự phù hợp với mục đích, mỗi khi một thứ gì đó trở nên lỗi thời hoặc không được dùng nữa. Nhưng như các MD của tôi trong tất cả các công ty tôi từng làm việc đã nói với tôi: "Ai sẽ trả tiền?"


12

Tôi luôn cố gắng dọn dẹp khi tôi đi. Tôi không được thực hiện cho đến khi mã sạch. Vấn đề với nợ kỹ thuật là hầu hết mọi người không hiểu nó. Cách tốt nhất để giải quyết nó là không tích lũy bất kỳ của nó. Nếu người quản lý của bạn tin tưởng các nhà phát triển của bạn quyết định cách giải quyết vấn đề, bạn có thể biến vệ sinh mã thành một phần của mọi tác vụ lập trình. Nếu bạn không bao giờ kiểm tra mã xấu, bạn không tích lũy nợ. Nếu bạn cũng tuân theo Quy tắc Hướng đạo nam (luôn để lại mã sạch hơn bạn đã tìm thấy), khoản nợ hiện tại của bạn sẽ biến mất dần.

Tôi không thấy tái cấu trúc là một nhiệm vụ tách biệt với việc thực hiện các tính năng. Nó là một phần không thể thiếu của nó.


5
Tôi không thể đồng ý nhiều hơn: "Nợ kỹ thuật giống như nợ tài chính - về lâu dài đơn giản hơn là không tích lũy được để bắt đầu. Thanh toán tất cả các hóa đơn kỹ thuật của bạn mỗi tuần một lần"
Lawrence Dol

7

Nếu bạn đang làm việc với những người quản lý phi kỹ thuật, sẽ rất hữu ích nếu bạn có thể đưa cuộc thảo luận của mình thành những điều họ hiểu. Nếu bạn có thể xây dựng một trường hợp thực tế cho ROI dương trên công việc đã bỏ ra để trả nợ kỹ thuật, bạn có thể nhận được ở đâu đó. Bài tập đó sẽ phụ thuộc vào hoàn cảnh của bạn, nhưng một ví dụ có thể giống như thế này:

Phân tích thời gian các nhà phát triển buộc phải dành bao nhiêu thời gian để hỗ trợ Hỗ trợ các vấn đề sản xuất, sau đó đưa ra trường hợp sửa mã cũ bị hỏng sẽ A. giảm số lượng vấn đề hỗ trợ, B. giúp Hỗ trợ giải quyết vấn đề dễ dàng hơn mà không leo thang đến Phát triển và C. giảm thời gian Phát triển dành cho các vấn đề sản xuất khi chúng phát sinh. Đặt nó dưới dạng đô la tiết kiệm bằng cách không có nhà phát triển bị ràng buộc làm công việc hỗ trợ. Ngoài ra, hãy chỉ ra rằng mỗi giờ nhà phát triển dành hỗ trợ là một "vấn đề gấp đôi" bởi vì bạn không chỉ trả tiền cho nhà phát triển để hỗ trợ mà còn đốt chi phí cơ hội cho những gì nhà phát triển có thể làm (thêm tính năng mới, v.v. .)

Vâng, một số con số sẽ là voodoo / khói và gương ... không sao, bí mật quản lý bẩn thỉu là họ biết rằng phần lớn các con số họ quẩn quanh là tổng số BS Chỉ cần bạn đưa cho họ thứ gì đó dường như cụ thể để làm việc với, vì vậy họ có thể có được nó trong đầu, bạn có cơ hội chiến đấu.


6

Sau lời giải thích về nợ kỹ thuật này, ban quản lý của bạn nên được thuyết phục để trả hết:

Hãy tưởng tượng rằng bạn có một nhà bếp rất bẩn đầy rác rưởi. Trước khi chuẩn bị một bữa ăn, trước tiên bạn phải dành một giờ để làm sạch. Và nó là như thế mỗi khi bạn muốn ăn. Ngoài ra, khi chuẩn bị một bữa ăn, bạn phải hết sức cẩn thận, để đảm bảo rằng crap không rơi vào bữa ăn của bạn.

Nhà bếp là mã của bạn, bữa ăn là sản phẩm của bạn, và ăn là bán sản phẩm của bạn.

Nếu họ có thể đủ khả năng chờ đợi lâu hơn để thay đổi được thực hiện, mà không có mạng lưới kiểm tra đơn vị an toàn, thì có điều gì đó không ổn trong công ty của bạn.


4

Đó phải là một lập luận rất thuyết phục, về mặt sản phẩm và trường hợp kinh doanh ban đầu, rằng tôi không thể sử dụng số tiền đó bây giờ để làm điều gì đó quan trọng hơn với tôi. Dù muốn hay không, quản lý của bạn hoặc khách hàng của bạn đang trả tiền cho việc này và bạn cần có khả năng bán hàng để thuyết phục họ.

Hãy viết lại điều này để định vị mình là khách hàng. Tốt vai cũ.

Giả sử bạn đang mua tủ lạnh. Và bạn có thể mua một tủ lạnh với giá 1000 đô la hoạt động tốt từ Acme Corp Hoặc một tủ lạnh với giá 2000 đô la từ Acme Deluxe Fridges trông giống nhau ở bên ngoài và có cùng thông số kỹ thuật, nhưng chi phí bảo trì thấp hơn do kiến ​​trúc bên trong sạch hơn.

Là một khách hàng, bạn sẽ tự mua?

Và các kỹ sư của Acme Deluxe nghĩ gì là câu trả lời tốt hơn?


3
Tôi đang có một thời gian khó khăn để xác định lập trường của bạn về điều này. Tôi nghĩ câu trả lời của bạn là "nó phụ thuộc vào những gì khách hàng muốn". Vấn đề là, không phải mọi khách hàng đều hiểu rằng tủ lạnh giá rẻ sẽ bị rò rỉ, gunk khó chịu từ phần tủ đông, gây ra tiếng động lớn và cuối cùng ngừng hoạt động sau 5 năm, trong khi một chiếc khác sẽ hoạt động trơn tru và yên tĩnh trong 20 năm và không được thay thế cho đến khi nó được coi là lỗi thời bởi các chủ sở hữu sẽ bán lại nó để đổi lấy một mô hình mới. Tuy nhiên, tôi thích câu hỏi bạn đặt ra. Đó là suy nghĩ kích động. +1
jmort253

Dòng đầu tiên - "Phải có một lập luận rất thuyết phục [] rằng tôi không thể sử dụng số tiền đó ngay bây giờ để làm điều gì đó quan trọng hơn với mình." Tôi thẳng thắn sử dụng ví dụ về tủ lạnh, tôi không quan tâm đến những gì diễn ra trong tủ lạnh của mình. Tôi chỉ muốn một kết quả. (thực phẩm lạnh với giá cả hợp lý). Nói thẳng ra, tôi không quan tâm nếu các kỹ sư tủ lạnh nghĩ rằng đó là một sản phẩm tốt hơn trong nội bộ. Tôi có thể hỏi ý kiến ​​họ nhưng đó thực sự không phải là quyết định của họ.
jasonk

3

" Nợ kỹ thuật " có thể là một chủ đề khó khăn để trình bày với ban quản lý vì họ có thể không thấy sự cần thiết của nó. Câu hỏi có thể được đặt ra là liệu có một nhà vô địch trong công ty hay không, "Hãy nhìn xem, chúng tôi đang dành X% thời gian để xử lý nợ kỹ thuật ở đây. Hãy cho chúng tôi 3 tháng để cho bạn thấy điều này hoạt động tốt", hoặc một cái gì đó giống. Có một yêu cầu đối với quyền tự chủ ở đó nhưng cũng có khung thời gian vì nếu không thì ban quản lý có thể tự hỏi bao lâu cho đến khi họ thấy một số kết quả là lãnh thổ khá nguy hiểm.

Điểm đầu tiên là liệu họ có coi đây là một vấn đề hay không. Nếu người có thị lực kém không biết gì về kính mắt và họ có thể cung cấp những loại thay đổi nào, làm sao họ hiểu tại sao xét nghiệm mắt có thể có giá trị? Cùng một ý tưởng ở đây, nơi chủ đề khá kỹ thuật và không dễ dàng định lượng không may.


Tôi đồng ý với điều này đầy đủ và tìm thấy nó ngày càng nhiều. Gần đây, tôi đã tập hợp một danh sách các khiếm khuyết đã được mở lại bởi vì một sửa chữa thích hợp đã không được đưa ra hoặc các khiếm khuyết có tính chất tương tự. Hy vọng các nhà phát triển đưa vào thời gian dành. Đôi khi họ làm, đôi khi họ không, nhưng loại dữ liệu này là nền tảng hữu ích để cho quản lý thấy một sản phẩm không lành mạnh đang ảnh hưởng đến doanh nghiệp của họ như thế nào.
Hành tinh hoang vắng

2
Ở nơi làm việc hiện tại của tôi, làm thêm giờ được phân bổ vì những lý do sai. Nếu thời gian được đầu tư để giữ cho ứng dụng khỏe mạnh thay vì các vấn đề về hỏa hoạn, tiền sẽ được tiết kiệm khi làm thêm giờ và các nhà phát triển sẽ được trao quyền nhiều hơn thay vì đốt cháy và gây khó chịu cho ban quản lý.
Hành tinh hoang vắng

Nhưng quản lý (trong hầu hết các trường hợp chính xác!) Thấy nó theo cách này. Tôi có một magimix thập niên 1980 vẫn hoạt động và bạn bảo tôi thay thế nó chỉ vì nó cũ và màu sắc không hợp thời trang!
James Anderson

2

Bạn chỉ nên ngừng phàn nàn về nó.

Đây là lý do tại sao:

  1. Họ không bao giờ có kế hoạch sử dụng phần mềm lâu hơn một năm
  2. Sẽ thật lãng phí thời gian để điều chỉnh nó nếu kế hoạch của họ là đổ nó sau đó
  3. có một số vấn đề thực sự cần khắc phục ngay bây giờ
  4. lập trình viên chỉ cần học cách đối phó với bảo trì, ngay cả khi nó không phải lúc nào cũng vui
  5. phàn nàn rằng bạn biết rõ hơn những gì cần phải làm là kiêu ngạo - người khác đưa ra quyết định và bạn nên hài lòng về điều đó
  6. Dù sao họ cũng tin tưởng bạn viết mã tốt

Vì vậy, cách tốt nhất về phía trước là:

  1. Khi họ giao cho bạn nhiệm vụ mới, hãy cố gắng thực hiện nó tốt nhất có thể trong thời gian nhất định
  2. Viết nó hoàn hảo lần đầu tiên. Nếu bạn cần thay đổi nó sau đó, bạn đã mắc lỗi ngay lần đầu tiên và mọi thay đổi luôn đi sai hướng - và đó là cơ hội học tập cho các lập trình viên khi bạn mắc lỗi.
  3. Đừng hỏi thêm thời gian cho nó, bạn sẽ không nhận được nó, có những thời hạn bạn biết.

3
Tôi hầu như đồng ý ngoại trừ việc người ta biết rằng ngay cả phần mềm nhảm nhí cũng có xu hướng tồn tại lâu hơn nhiều so với những người tạo ra nó. Nhưng bạn đã đúng, tốt hơn hết là đừng phàn nàn. Thay vào đó, nếu bạn thấy một số bao thanh toán lại ở quy mô giới hạn sẽ giúp tính dễ hiểu của mã, nó có thể đáng để tiếp tục và thực hiện các thay đổi mà KHÔNG CÓ GIẤY PHÉP trong quá trình bảo trì / sửa lỗi của bạn (và có rủi ro khi làm như vậy).
Angelo

@Angelo - Sẽ không tốt hơn để nói lên mối quan tâm của bạn hơn là cho phép nhóm chịu đựng trong im lặng? Tôi đã thấy vấn đề này làm gì đối với tinh thần đồng đội và cả với thời gian / tiền bạc bị lãng phí khi làm thêm giờ. Tôi không thấy nó là "rên rỉ" như vậy. Bạn chỉ đơn giản là chỉ ra các rủi ro dự án và nếu ý tưởng của bạn có thể tăng tốc thời gian giao hàng và hợp lý hóa các quy trình, thì tại sao ít nhất không thử nói lên mối quan tâm của bạn? Nếu tai này bị điếc, thì ít nhất bạn cũng biết mình đang đứng ở đâu.
Hành tinh hoang vắng

2
Bạn phải phàn nàn về điều đó một cách ồn ào , nếu không đó là lỗi của bạn nếu mã của người khác bị hỏng ("Bạn có biết đây là một mớ hỗn độn và không nói cho ai biết không?"). Đứng lên và đi "Này ông chủ, thứ chết tiệt này sớm muộn gì cũng sẽ gặp fan" là điều tối quan trọng để giữ cho một nhóm phát triển hoạt động.
Alex

1

Tôi cho rằng bạn chưa bao giờ tham gia vào một dự án để viết lại / thay thế hoặc thậm chí nâng cấp và hệ thống hiện có.

Đây là một số dự án khó nhất để hoàn thành thành công. Một số vấn đề bạn sẽ gặp phải là:

  1. Quy tắc kinh doanh bị mất trong thời gian.
  2. Tài liệu và thực hiện là hoàn toàn không đồng bộ.
  3. Những gì bạn thấy là một lỗi mà người dùng xem là một tính năng.
  4. Ngược lại, nhiều "tính năng" sẽ được người dùng xem là khiếm khuyết.
  5. Bạn sẽ không khiến người dùng mua vào - họ sẽ coi "tìm hiểu thực tế" của bạn là "những người mọt sách hỏi những câu hỏi ngu ngốc", họ sẽ coi nỗ lực thử nghiệm là một sự lãng phí thời gian, họ sẽ nhấn mạnh vào việc thêm các tính năng mới do đó sẽ kéo dài dự án đã bị chậm tiến độ.
  6. Có thể mã nguồn không khớp 100% với tệp thực thi đang chạy.
  7. Trong khi bộ phận của bạn đang loay hoay trong việc tái cấu trúc phát triển, doanh nghiệp thực sự muốn không được thực hiện.
  8. Rất có thể là việc bao thanh toán lại của bạn sẽ liên quan đến "các giao diện được cải thiện sạch hơn", do đó kéo các dự án khác vào vũng lầy của việc giao hàng trễ và các thử nghiệm thất bại.
  9. Sau khi dự án được đóng hộp (hơn 50% những nỗ lực này thất bại hoàn toàn), bạn sẽ mất tất cả tín dụng - bạn sẽ cần chuyển đến một công ty khác ở một thị trấn khác để tìm ai đó chuẩn bị lắng nghe bạn.
  10. Nếu dự án "thành công", mọi người sẽ nhớ đó là cơn ác mộng - bạn sẽ .......

Tôi khuyên bạn nên tránh mọi dự án viết lại / tái cấu trúc như bệnh dịch hạch, chúng có thể là một trong những kinh nghiệm thú vị nhất trong bất kỳ sự nghiệp chuyên nghiệp nào.

Có rất nhiều sự khôn ngoan trong câu "Nếu nó không bị hỏng thì đừng sửa nó".


1
"Tôi cho rằng bạn chưa bao giờ tham gia vào một dự án để viết lại / thay thế hoặc thậm chí nâng cấp và hệ thống hiện có" - Sai, 7 năm của nó.
Hành tinh hoang vắng

1
Tôi hoàn toàn đồng ý rằng viết lại đầy đủ thường là một thảm họa. Nhưng tôi có ba ví dụ trong 8 năm cuối sự nghiệp. Một là một khẩu hiệu dài dẫn đến việc chúng tôi có thể duy trì sản phẩm tốt hơn nhưng không cung cấp giá trị kinh doanh; một cái khác là viết lại ngắn mà thành công hoàn toàn; thứ ba là một quyết định không viết lại, cuối cùng đã giết chết công ty. Chọn chất độc của bạn.
Tom Harrison Jr

1

Đối với cuộc sống của tôi, tôi không thể hiểu tại sao một số người lại sợ thay đổi một cách mù quáng - nó thiếu tự tin vào khả năng của chính bạn.

Tôi đã xem một chương trình tối qua trên Công viên Quốc gia Yosemite và nhận xét rằng từ năm 1940 đến cuối những năm 1990, không một cây Sequoia mới nào mọc lên. Người ta phát hiện ra rằng lý do tại sao có một chính sách nghiêm ngặt chống lại việc đốt cháy rừng và nón thông Sequoia cần hơi nóng từ lửa để mở và giải phóng hạt giống của chúng.

Bạn thấy đấy, một đám cháy cứ sau mười năm thì khỏe mạnh. Nó đã dọn sạch tất cả số gỗ chết và tích lũy để giữ cho cây khỏe mạnh (quy trình) và nhường chỗ cho những cái mới (tính năng).

Tôi đang có một dự án ngay bây giờ có một trường hợp rõ ràng để xây dựng lại: Phần mềm kế thừa được viết hoàn toàn bằng cách sử dụng các biểu mẫu web .NET. Hầu như tất cả logic nghiệp vụ được kết hợp với logic xem thẻ HTML / máy chủ và không thể mở rộng sang các ứng dụng khác mà doanh nghiệp đã phát triển.

Quản lý đứng đằng sau nhiệm vụ bởi vì họ có một sự tin tưởng thích hợp vào các nhà phát triển của họ, mà tôi nhận ra, đó là một sự xa xỉ hiếm có.

Vâng, hãy tự hỏi nếu xây dựng lại là thực sự cần thiết. Làm hết sức mình để sử dụng lại mã hiện có hoạt động ở nơi bạn có thể. Tích hợp mã đó vào việc xây dựng lại nếu cần thiết. Đừng để ai thuyết phục bạn rằng sợ thực hiện những thay đổi táo bạo là cách duy nhất để tồn tại như một nhà phát triển phần mềm.

Chúc may mắn!


1
Làm thế nào để trả lời câu hỏi này, "Làm thế nào để bạn truyền đạt điều này đến quản lý để khiến họ quan tâm đến việc phân loại nợ kỹ thuật?"
gnat

1
@gnat: Làm thế nào để hầu hết các "câu trả lời" trả lời câu hỏi đó trực tiếp? Xem, ví dụ, câu trả lời của James Anderson, tp1 hoặc bất kỳ câu trả lời nào ở đầu với nhiều phiếu nhất. Nhưng để trả lời câu hỏi của bạn, tôi đã cung cấp một sự tương tự thay thế mà OP có thể sử dụng. Dường như với tôi rằng bạn chỉ đơn giản là không đồng ý với ý kiến ​​của tôi về vấn đề này. Điều đó tốt, nhưng không có lý do để downvote.
Matt Cashatt

1
theo cách đọc của tôi, câu trả lời hàng đầu mà bạn giới thiệu dường như trực tiếp giải quyết câu trả lời được hỏi, dựa trên kinh nghiệm có liên quan "Khi tôi gặp sếp để thảo luận về điều này ..." Theo ý kiến ​​của bạn, tôi có xu hướng đồng ý với nó, nhưng tôi bỏ phiếu dựa trên về chất lượng nội dung, không phải về việc tôi ủng hộ ý kiến ​​cụ thể hay không đồng ý. Mô hình bỏ phiếu Hỏi & Đáp của Stack Exchange khá kém khi (mis) được sử dụng cho các cuộc thăm dò ý kiến
gnat

1
Tôi khuyên bạn nên đọc lại, sau đó. Mô tả cuộc trò chuyện với sếp của một người về phương pháp xử lý nợ kỹ thuật bằng cách đệm các ước tính cho công việc trong tương lai không trả lời câu hỏi, "Làm thế nào để bạn truyền đạt điều này cho ban quản lý để khiến họ quan tâm đến việc loại bỏ nợ kỹ thuật?" hoặc. Tuy nhiên, tôi đã không bỏ phiếu trả lời vì nó đã thêm vào cuộc trò chuyện. Vì vậy, tất cả những gì bạn đã thành công trong việc làm là tắt tiếng một ý kiến ​​về vấn đề mà bạn đồng ý mà không có lý do đáng kể. "Lập trình viên" nên là nơi chúng ta có thể trò chuyện. Không phải tất cả mọi thứ là nhị phân.
Matt Cashatt

1

Bạn cần cung cấp cho ban quản lý của mình một lý do tài chính để xử lý nợ kỹ thuật và khung quản lý giảm nợ kỹ thuật đó.

Duy trì một lộ trình công nghệ là một trong những khuôn khổ như vậy. Bắt đầu với một lộ trình sẽ giúp bạn tránh khỏi tình trạng nợ kỹ thuật và cũng có thể giúp bạn giảm nợ hiện tại.

Nhiều dự án dài hạn thành công đã liên kết với các ban chỉ đạo và lộ trình để định hướng phát triển. Điều này đặc biệt hữu ích khi có nhiều nhóm phát triển và các bên liên quan.

Đề nghị của tôi là bạn thảo luận chiến lược này với các nhà quản lý của bạn (và nếu có thể những người đưa ra quyết định về nơi tiền được chi tiêu).

Cách tiếp cận chung để tạo và quản lý lộ trình rất đơn giản, nhưng nó cần có sự hỗ trợ của đội ngũ quản lý của bạn. Đầu tiên, xác định một mục tiêu. Xác định các yếu tố của nợ kỹ thuật và phát triển kiến ​​trúc hệ thống mục tiêu làm giảm các yếu tố của nợ kỹ thuật của bạn. Hãy nhớ rằng, nó không cần phải hoàn hảo, hoàn toàn khả thi và tốt hơn những gì bạn đang có. Hãy tính đến phần mềm, công cụ phát triển, nền tảng phần cứng, các tính năng mới quan trọng có thể được thêm vào hệ thống. Làm một phân tích chi phí. Nếu bạn có kiến ​​trúc mong muốn, những lợi ích hữu hình của việc thực hiện tái cấu trúc là gì? (Lợi ích sẽ bao gồm giảm thời gian thử nghiệm, các sản phẩm phần mềm đáng tin cậy hơn, chu kỳ phát triển dễ dự đoán hơn, v.v.) Nếu bạn có thể hiển thị đủ lợi ích để thực hiện tái cấu trúc, bạn có thể nhận hỗ trợ quản lý.

Khi bạn có lộ trình và hỗ trợ quản lý, hãy phát triển một loạt các bước (còn gọi là kế hoạch) mà bạn cần thực hiện để đến trạng thái mong muốn này. Có thể là một ý tưởng tốt để thành lập một ban chỉ đạo duy trì lộ trình, đào tạo và giáo dục các nhóm phát triển về lộ trình và định kỳ xem xét các thay đổi về tính toàn vẹn của kiến ​​trúc.

Lộ trình thực sự hữu ích và có lẽ câu hỏi thứ 13 trong Bài kiểm tra Joel là "Bạn có lộ trình không?"

Dưới đây là video về giờ đầu tiên của phiên lộ trình Red Hat Linux gần đây .


1

Đã từng tham gia viết lại chính, (không chỉ tái cấu trúc), tôi có thể đồng ý rằng việc các nhân viên tài chính đồng ý với dự án là một trong những rào cản lớn. Vượt qua rào cản đó đòi hỏi tôi phải viết, trình bày và bảo vệ một báo cáo chỉ ra một số vấn đề có nghĩa là việc kinh doanh của các công ty sẽ bị chết trong nước trong thời gian gần đến trung hạn.

Các yếu tố chính để có được thỏa thuận đi trước:

  • Mã hiện tại nằm trong chuỗi công cụ không còn được hỗ trợ, (MicroPower Pascal), chỉ chạy trên nền tảng phát triển gần như không hỗ trợ, (PDP11-23).
  • Tìm kiếm các nhà phát triển có thể làm việc trên các công cụ và mục tiêu đã trở nên gần như không thể.
  • Phần cứng mục tiêu không còn khả dụng nếu cần phụ tùng và nhà sản xuất ngày càng không muốn cung cấp dịch vụ sửa chữa.
  • Các vấn đề trong mã đã dẫn đến sự không hài lòng của khách hàng và chi phí phục vụ trực tiếp dễ nhận biết.
  • Việc thêm các tính năng mới hoặc thậm chí sửa lỗi đã trở nên gần như không thể do các hạn chế của phần cứng đích dẫn đến việc phải cấu trúc lại các khu vực khác để cung cấp không gian khi giải quyết các vấn đề.
  • Với thời gian xây dựng 8 giờ để phát triển và thử nghiệm mọi thay đổi đều tốn kém.

Báo cáo nêu chi tiết các vấn đề, với ước tính chi phí liên tục và đưa ra 3 tùy chọn:

  1. Đóng băng nơi chúng tôi đã có thể thậm chí không sửa lỗi trong tương lai gần.
  2. Tối ưu hóa mã chỉ cho không gian, không liên quan đến khả năng bảo trì, chỉ ra rằng bất kỳ ai cố gắng duy trì mã được tối ưu hóa sẽ phải thông minh hơn bất kỳ ai đã tối ưu hóa.
  3. Thực hiện lại, với khả năng kiểm tra và khả năng bảo trì là các yếu tố cao, trong một tiêu chuẩn công nghiệp, được dạy rộng rãi, ngôn ngữ, (ANSI C), trên phần cứng COTS mới, chi phí thấp, (PC-104), với nhiều nhà cung cấp có sẵn trong nhà thiết kế thẻ giao diện để cho phép nó hoạt động với phần cứng hiện có còn lại. Thêm một bộ tính năng mới hạn chế như một phần của sự phát triển, chẳng hạn như bộ lưu trữ không bay hơi, bộ hẹn giờ theo dõi để cung cấp khởi động lại tự động trong tình trạng lỗi, một số đơn vị đã gặp sự cố nhiều lần trong ngày và yêu cầu gọi lại dịch vụ £ 40 để đặt lại , chẩn đoán tốt hơn trong quá trình.

Có được sự lựa chọn thứ 3 cho hợp đồng 3 tháng của tôi, hợp đồng 3 tháng của tôi đã biến thành 3 năm làm việc rất chăm chỉ, cả việc phát triển phần mềm và phần cứng mới, nhưng với kết quả rất tốt.

Đối với các trường hợp có nợ kỹ thuật ít cực đoan hơn, tôi có xu hướng áp dụng cái mà tôi gọi là tái cấu trúc du kích:

Khi có sự cố với một mô-đun cụ thể:

  1. Viết một bộ các bài kiểm tra chứng minh vấn đề cũng có khả năng thất bại mà không tái cấu trúc
  2. Tái cấu trúc như là một phần của sự phát triển chỉ ra rằng các thử nghiệm vẫn không thành công.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.