Làm thế nào để đo lường giá trị tiềm năng của tái cấu trúc

Trên một dự án cũ, lớn với nợ kỹ thuật, làm thế nào bạn có thể ước tính hoặc đo lường một cách đáng tin cậy lợi ích của mã tái cấu trúc?

Ví dụ: giả sử bạn có một số thành phần trong giải pháp ngăn xếp phần mềm được viết bằng ngôn ngữ cũ hơn và một số thành phần sau được viết bằng ngôn ngữ mới hơn. Các tính năng mới và sửa lỗi liên tục được thêm vào giải pháp này bởi một nhóm phát triển.

Các nhà phát triển đề xuất rằng việc thay thế các thành phần ngôn ngữ cũ hiện có bằng phiên bản mới sẽ là 'một điều tốt' Tuy nhiên, không có tính năng bổ sung nào được thêm vào bởi công việc này và nó sẽ có giá x dev-days.

Một nhân viên bán hàng đề nghị thêm "một tính năng mới tuyệt vời". công ty đo lường giá trị của đề xuất của mình bằng cách sử dụng một công thức. I E. Nó sẽ kiếm được công ty F triệu bảng, qua t năm với chi phí x ngày làm việc

Làm thế nào công ty có thể chi phí đề xuất tái cấu trúc một cách có ý nghĩa? và trong những trường hợp nào nó có khả năng là lựa chọn có lợi nhất cho công ty?

Nó sẽ kiếm được công ty F triệu bảng, qua t năm với chi phí x ngày làm việc

Đó là bỏ qua chi phí bảo trì, chi phí hỗ trợ, chi phí bán hàng / tiếp thị và đưa ra rất nhiều giả định về cách tính năng này sẽ được thực hiện trên thị trường.

Nhưng sao cũng được; câu hỏi của bạn đủ rõ ràng về những gì bạn đang tìm kiếm:

Làm thế nào tôi có thể làm cho một trường hợp kinh doanh để tái cấu trúc?

Điều chính để nhận ra là thời gian bằng tiền. Bạn có thể truy cập thẳng vào "5 nhà phát triển 2 tuần = 80 giờ * 5 nhà phát triển * $ 50 / giờ -> $ 20.000" và điều đó có ý nghĩa với những người kinh doanh. Những người kinh doanh thông minh sẽ lưu ý rằng 5 nhà phát triển đó đang được trả tiền theo cách mà bạn phản đối rằng đó không phải là chi tiêu / tiết kiệm 20.000 đô la - đó là sử dụng 20.000 đô la theo cách có lợi nhất. Dù sao, với danh sách.

• Hiệu quả - Có lẽ, bạn có thể hoàn thành nhiều thứ hơn với C # so với VB6. Công cụ tốt hơn, thư viện tốt hơn, bất cứ điều gì. Các công nghệ mới có xu hướng tốt hơn mọi thứ so với các công nghệ cũ. Nếu bạn có thể làm công việc trong thời gian ngắn hơn, điều đó có nghĩa là bạn đang tiết kiệm tiền của công ty.
• Chi phí chung - Mã hóa không phải là chi phí duy nhất của phần mềm. Hãy xem xét những gì xảy ra khi Windows 2020 ra mắt. Bạn sẽ dành bao nhiêu thời gian và công sức để ứng dụng VB6 hoạt động trên nó? Bao nhiêu thời gian và nỗ lực hơn một ứng dụng C #? Đó là tiết kiệm tiền công ty của bạn.
• Chất lượng - Có lẽ, bạn có thể hoàn thành công việc với chất lượng cao hơn trong C # so với VB6 (hoặc với kiến ​​trúc sạch hơn hoặc bất kỳ mục tiêu tái cấu trúc nào khác của bạn). Chất lượng cao hơn có nghĩa là ít lỗi hơn. Ít lỗi hơn có nghĩa là chi phí ít hơn để khắc phục các lỗi đó, ít chi phí hỗ trợ khách hàng hơn cho các vấn đề đó, giảm mất khách hàng do vấn đề chất lượng, tăng doanh số do uy tín về chất lượng ... tất cả đô la cho công ty của bạn.
• Tiết kiệm nhân sự - Hãy đối mặt với sự thật: không ai muốn làm việc với ứng dụng VB6 tồi tệ đó. Điều đó có nghĩa là nhiều người sẽ rời khỏi công ty dẫn đến thời gian và tiền bạc để thay thế họ. Điều đó có nghĩa là phải mất nhiều thời gian và tiền bạc hơn để thuê nhân viên mới. Tệ nhất là, điều đó có nghĩa là bạn sẽ có những nhà phát triển hoàn toàn tự tử khi làm việc với ứng dụng VB6 đó. Những nhà phát triển này lần lượt đẩy nhanh vòng xoáy tử thần của các vấn đề chất lượng. Cắt giảm doanh thu và thời gian tuyển dụng tiết kiệm tiền công ty của bạn. Giữ cho các nhà phát triển tự mãn, crappy đi tiết kiệm công ty của bạn.
• Tinh thần - Tương tự, các lập trình viên đã ở đó ghét làm việc trong VB6. Họ sẽ làm điều đó, và họ thậm chí có thể làm tốt. Nhưng nó hút. Có thể không phải cho tất cả mọi người, nhưng chắc chắn cho một số. Điều đó có nghĩa là dành nhiều thời gian hơn để duyệt web để lấy lại động lực. Nó có nghĩa là bữa trưa dài hơn. Nó có nghĩa là ít hoàn thành công việc hơn trong khi các lập trình viên của bạn mất nhiều thời gian hơn để phục hồi từ công việc sucky.
• Khả năng - Điều này ít áp dụng với các nhà tái cấu trúc điều khiển công nghệ, nhưng áp dụng cho loại cấu trúc của các nhà tái cấu trúc. Một số vấn đề về mã chủ động ngăn bạn cung cấp tính năng X thú vị để kiếm hàng tấn tiền. Có lẽ bạn không thể mở rộng quy mô. Có lẽ bạn không thể lấy dữ liệu để làm những tin học tuyệt vời. Có lẽ mã là một tổ chuột đến nỗi thực sự khó thực hiện công việc. Bất cứ điều gì. Đôi khi bạn đang ở điểm đó, đôi khi bạn đang lái thẳng về điểm đó. Thật khó để dịch sang tiếng nói kinh doanh, nhưng nếu bạn có thể thì "vấn đề này đang ngăn chúng ta tận dụng các cơ hội X, Y và Z" có thể rất mạnh mẽ.

Nói chung, "công cụ này sẽ giúp chúng tôi thực hiện công việc tốt hơn; nếu chúng tôi làm việc tốt hơn, chúng tôi có thể kiếm / tiết kiệm cho bạn nhiều tiền hơn".

Câu hỏi bạn nên tự hỏi mình là làm thế nào để nhân viên bán hàng biết rằng tính năng này sẽ có giá x ngày nhà phát triển. Cho rằng ngay cả những người quản lý dự án giỏi với nhiều năm kinh nghiệm chuyên môn cũng không thể nói rằng, dữ liệu đó đến từ một nhân viên bán hàng dường như cực kỳ ... đầu cơ .

Theo kinh nghiệm của tôi, nhân viên bán hàng thường không đưa ra ước tính, nhưng hãy đoán xem bao nhiêu là quá nhiều cho quản lý hoặc khách hàng: nếu quản lý sẵn sàng trả 50 tuần làm việc, nhưng sẽ từ chối hoàn toàn 75 tuần. rằng tính năng này sẽ mất 70 tuần làm việc trong khi sẵn sàng đàm phán lại (một điều không thể nghi ngờ đối với ước tính thực tế) xuống còn 55 tuần.

• Một mặt, bạn có ước tính được thực hiện bởi các chuyên gia CNTT nói điều gì đó như:

  Theo kiểm toán cụ thể này, chúng tôi đang lãng phí 8.000 đô la mỗi ngày khi sử dụng công nghệ lỗi thời so với các dự án tương tự có quy mô tương tự sử dụng các công nghệ mới hơn. Dường như sẽ mất từ ​​50 đến 80 tuần để di chuyển toàn bộ cơ sở mã; trong thời gian này, sẽ không có tính năng mới nào được phát hành. Cũng có 10% rủi ro khi di chuyển một thành phần cụ thể có thể dẫn đến 20-30 tuần làm việc thêm.

• Mặt khác, bạn có những phỏng đoán được thực hiện bởi những người bán hàng, dựa trên đòn bẩy của họ khi đàm phán với người mà họ cần thuyết phục.

Đó là tất cả về tầm ảnh hưởng của bạn trong công ty của bạn. Giao tiếp là chìa khóa ở đây và đây là nơi các nhân viên bán hàng thường giành chiến thắng trước các chuyên gia CNTT khi giải thích các lợi ích của một tính năng cho quản lý (hoặc khách hàng).

Lưu ý rằng nếu trong quá khứ, ước tính của bạn khá chính xác, bạn có được danh tiếng và tầm ảnh hưởng. Nếu ước tính của bạn luôn sai, quản lý có thể sẽ bỏ qua các đề xuất của bạn.

Đối với các ước tính, rất khó để tạo ra một giá trị ở đây, vì có một số lượng lớn các tham số cần tính đến. Trong số những người khác:

• Bạn có thực sự biết nhóm của bạn trong C # khéo léo như thế nào so với VB6 không? Nó dựa trên các phép đo thực tế hay chỉ là phỏng đoán?

• Đội ngũ này đã phát triển các dự án lớn trong C #? Họ có biết các công cụ họ nên sử dụng (IDE, trình gỡ lỗi, trình biên dịch, v.v.) không? Bạn có cần giấy phép bổ sung (trong thế giới của Microsoft, có nghĩa là hàng ngàn đô la cho mỗi máy) không?

• Dự án hiện tại có hoàn toàn rõ ràng và bạn có thể đảm bảo rằng sẽ không có bất ngờ khi di chuyển? Là đơn giản để viết lại tất cả mọi thứ , mọi tính năng, hoặc sẽ có những bất ngờ?

• Bạn có cơ sở hạ tầng hỗ trợ C # không? Thế còn hội nhập liên tục? Còn máy chủ xây dựng của bạn thì sao? Hướng dẫn phong cách? Kiểm tra tĩnh?

• Trong sản xuất, các máy chủ (nếu đây là ứng dụng web) hay PC khách hàng (nếu đây là ứng dụng dành cho máy tính để bàn) có thể chạy phiên bản .NET Framework mà bạn muốn sử dụng không?

Nhưng điều quan trọng nhất là phải biết tại sao bạn muốn viết lại mọi thứ. Có gì vấn đề bạn đang cố gắng để giải quyết thông qua một ghi đè? Mất năng suất? Bạn đo lường nó như thế nào? Làm thế nào để bạn thể hiện sự mất năng suất này cho quản lý?

Khi bạn đã cho thấy rằng bạn đang lãng phí, giả sử, 8.000 đô la mỗi ngày vì VB6 (có nghĩa là bạn sẽ tiết kiệm được 8 000 đô la mỗi ngày khi bạn chuyển sang C #), làm thế nào để bạn giải thích lợi ích của việc nắm giữ mọi phát triển tính năng mới và tập trung vào viết lại hoàn chỉnh? Lợi ích gì so với viết lại lũy tiến khi bạn di chuyển các thành phần của mình thành từng phần nhỏ một, trong khi vận chuyển các tính năng mới?

Trước tiên, bạn cần ước tính chi phí phát triển cho việc bao thanh toán lại như bạn yêu cầu tính năng thúc đẩy bán hàng.

Điều này có thể khó để có được chính xác nếu đó là một công việc lớn, nhưng, giả sử bạn có đủ người có kinh nghiệm trong 2 công nghệ, điều đó là có thể làm được.

Thứ hai, bạn cần một ước tính chi phí của việc không bao thanh toán lại. Nếu bạn đang thực hiện các ước tính cho tôi, tôi sẽ mong đợi một số mức độ. Ví dụ: sự khác biệt giữa chi phí phát triển trung bình cho mã VB và mã C # trong một phần tư. Hoặc một số như vậy. Rõ ràng sẽ phụ thuộc vào cách chính xác bạn theo dõi này.

Với 2 con số này, bạn có thể ước tính thời gian hoàn vốn mà việc bao thanh toán lại sẽ cung cấp cho bạn tức là vào thời điểm nào thì việc bao thanh toán lại sẽ chuyển từ chi phí ròng sang lãi ròng.

Tôi chỉ có thể đoán làm thế nào thuyết phục bất kỳ kết quả nhất định sẽ được. Tuy nhiên, nếu chưa đầy một năm thì có lẽ nó sẽ khá mạnh, hơn 2 năm thì bạn có thể sẽ phải vật lộn.

Ngoài ra, có thể đáng để thêm các kích thước khác để giúp xây dựng trường hợp của bạn. Một cái mà tôi đã sử dụng trong quá khứ là xem liệu có cuộc phỏng vấn thoát nào được trích dẫn công nghệ như một trình điều khiển không. Nếu vậy, bạn có thể lập luận rằng việc bao thanh toán lại sẽ giữ chân nhân viên (tuyển dụng và đào tạo là v đắt tiền).

Rõ ràng, bạn có thể tranh luận những điều này mà không cần bằng chứng hỗ trợ nhưng tôi thấy rằng nó có thể tạo ra một sự khác biệt rất lớn đối với tác động của vụ án.

Giá trị của tái cấu trúc xuất hiện theo nhiều cách khác nhau.

Nó giúp bạn thực hiện các thay đổi khác sau đó, do đó, ngày X mà tính năng đó đã thực hiện sẽ mất 2/3 ngày để hoàn thành. Để sử dụng thuật ngữ nhanh, nó làm tăng vận tốc.

Thay đổi rõ ràng được liệt kê sẽ giúp ích theo thời gian vì bạn sẽ không còn cần phải duy trì các nhà phát triển có kinh nghiệm VB6, chỉ những người có kinh nghiệm về C #.

Nó cũng giúp theo những cách ít hữu hình khác như giữ chân nhân viên và tuyển dụng. Một công việc làm C # và VB6 sẽ hấp dẫn hơn hoặc ít hơn một công việc chỉ làm C #? Bạn sẽ ít nhiều có khả năng nhận một công việc hoặc ở lại một công việc làm việc trên một cơ sở mã tốt đẹp hoặc một công việc tệ hại?

Tôi nghĩ rằng điểm mà các câu trả lời khác bỏ lỡ là bạn cần đo lường chi phí tái cấu trúc so với doanh thu bị mất từ ​​việc không tái cấu trúc.

Tái cấu trúc để thay đổi mã là một sự lãng phí thời gian. Nó cần phải mang lại giá trị cho bảng. Trong bối cảnh này, tôi không có nghĩa là dành một giờ để tái cấu trúc một lớp vấn đề, nhưng việc tái cấu trúc chính như thay đổi sang ngôn ngữ CLR khác như bạn đã sử dụng trong ví dụ của mình.

• Nếu chúng ta tiếp tục làm những gì chúng ta đang làm, chúng ta có đang bỏ lỡ điều gì không? Có một thiết kế cũ kỹ tồi tàn đang giữ chúng ta khỏi nhận ra giá trị? Ví dụ: nếu chúng tôi muốn thêm một tính năng thì khó đến mức có thể mất 100 giờ để thực hiện, so với 50 giờ để cấu trúc lại và 25 giờ để thực hiện theo thiết kế mới?

• Liệu các mã hiện có mang nợ kỹ thuật đang làm chúng ta tốn tiền? Đây có phải là mã cũ nhảm nhí là nguồn gốc của lỗi? Chúng ta cuối cùng làm việc miễn phí để khắc phục vấn đề vì nó? Không ai thích cho đi hàng giờ hóa đơn sinh lợi miễn phí.

• Là chi phí tái cấu trúc bằng hoặc ít hơn chi phí tái cấu trúc?

• Có thể khấu hao chi phí bằng cách có một nhóm nhỏ các ngôi sao nhạc rock tái cấu trúc mã gây ra nhiều vấn đề nhất? Chúng ta có thể truyền bá bộ tái cấu trúc ra khắp các bản phát hành không? Có những sự thiếu hiệu quả nhỏ ở khắp mọi nơi: chúng ta có thể "lấp đầy những khoảng trống" để nói chuyện với công việc làm thêm này không?

Lợi ích của việc có một hệ thống tái cấu trúc

Bạn tạo ra một trường hợp kinh doanh để tái cấu trúc bằng cách so sánh lợi ích cơ bản của doanh nghiệp giữa việc làm và không làm việc đó. Điều này có nghĩa là giảm chi phí thực tế hiện tại hoặc tăng dòng tiền thực tế trong tương lai.

Các mục ngân sách chính bị ảnh hưởng bởi tái cấu trúc là như sau:

• Chi phí bảo trì - nếu hệ thống hiện tại là một đống spaghetti dễ vỡ và trong thực tế có thể quan sát thấy rằng việc sửa các lỗi nhỏ (cả trong quá trình phát triển và vận hành) cần một lượng lớn thời gian, có thể dự kiến ​​rằng chi phí sẽ như vậy bảo trì sẽ nhỏ hơn đối với hệ thống "được thiết kế lại đúng cách". Hãy xem chi phí bảo trì thuần túy hàng năm của bạn là bao nhiêu và làm thế nào chúng có thể thay đổi thực tế sau khi viết lại.

• Chi phí thêm các tính năng mới - một lần nữa, nếu thiết kế và cấu trúc hệ thống hiện tại khiến việc viết các tính năng mới trở nên tốn thời gian một cách vô lý, thì việc viết lại có thể giúp tiết kiệm. Hãy xem ngân sách dự kiến ​​của bạn cho các tính năng mới, nhưng hãy thực tế - nếu bạn cho rằng bạn sẽ thấy cải thiện 50% thì bạn sẽ thực sự phát triển các tính năng trong x man-tháng mà trước đó phải mất 2 * x man-tháng để nhận ra; những lời hứa như vậy có thể khó giữ.

• Chất lượng phần mềm ảnh hưởng đến doanh số bán hàng - nếu hệ thống hiện tại thường xuyên gây ra các sự cố có thể nhìn thấy của khách hàng, ví dụ như sự cố hoặc thời gian ngừng hoạt động mặc dù nỗ lực bảo trì đầy đủ, thì việc viết lại có thể là một giải pháp. NẾU đây là một vấn đề lớn, thì những người bán hàng tương tự có thể định lượng giá trị của một 'tính năng' được gọi là 'sản phẩm ổn định hơn'.

Nếu ba điểm trên không đạt được chi phí viết lại dự kiến ​​(và hơn thế nữa, chi phí cơ hội chi x x ngày cho các tính năng không bằng giá trị của các tính năng đó, lớn hơn chi phí thuần túy của x dev -ngày) sau đó tôi sợ rằng đó là - khoản tiết kiệm dự kiến ​​không biện minh cho việc viết lại.

Ngoài ra, nếu lộ trình của bạn không thể hiện nhu cầu 'nhiều như bạn có thể cung cấp' các tính năng mới, thì khoản tiết kiệm phải ở dạng ', nó thường dùng 10 người để làm tất cả những thứ cần thiết, nhưng sau khi viết lại, chúng tôi đã viết lại 'sẽ có thể làm điều tương tự chỉ với 6 người' . Nếu bạn có thể "bán" nhiều dự án phát triển hơn bạn có nhà phát triển, thì việc cải thiện hiệu quả cho phép bạn phát triển nhiều thứ hơn, nhưng nếu doanh nghiệp có nguồn lực hiện tại đã có thể phát triển tất cả những thứ mang lại giá trị gia tăng, thì lợi ích tài chính duy nhất có thể đến từ việc trả ít người hơn hoặc có những người rẻ hơn.

Giá trị của tái cấu trúc có thể được đo như vậy: tính năng mới hiện tại x sẽ có giá 5 devs 2 tuần. Nếu chúng tôi tái cấu trúc thành phần cũ, chi phí cho các tính năng mới sẽ giảm khoảng 20%. Vì vậy, tính năng mới x sẽ chỉ có giá 4 dev trong hơn 2 tuần.

Tái cấu trúc là một khoản đầu tư trong việc giảm chi phí phát triển trong tương lai. Nếu bạn không thể đưa ra lập luận đó cho việc tái cấu trúc của mình, có lẽ đó không phải là trường hợp kinh doanh cho nó.