Làm thế nào để các công ty phần mềm tùy chỉnh của Cameron xử lý nợ kỹ thuật?

"Các công ty phần mềm tùy chỉnh" là gì?

"Các công ty phần mềm tùy chỉnh" Tôi có nghĩa là các công ty kiếm tiền của họ chủ yếu từ việc xây dựng các phần mềm tùy chỉnh, một lần, một phần mềm. Ví dụ là các đại lý hoặc công ty trung gian, hoặc nhà thầu / chuyên gia tư vấn như Redify .

Điều gì trái ngược với "các công ty phần mềm tùy chỉnh"?

Đối lập với mô hình kinh doanh trên là các công ty tập trung vào các sản phẩm dài hạn, cho dù chúng có thể triển khai ứng dụng trên máy tính để bàn / thiết bị di động hay phần mềm SaaS.

Một cách chắc chắn để xây dựng nợ kỹ thuật:

Tôi làm việc cho một công ty cố gắng tập trung vào một bộ sản phẩm SaaS. Tuy nhiên, do một số hạn chế nhất định, đôi khi chúng tôi cuối cùng đã uốn cong theo ý muốn của một số khách hàng nhất định và chúng tôi kết thúc việc xây dựng các phần mềm tùy chỉnh chỉ có thể được sử dụng cho khách hàng đó.

Đây là một cách chắc chắn để phát sinh nợ kỹ thuật. Bây giờ chúng tôi có một chút phần mềm để duy trì không thêm gì vào sản phẩm cốt lõi của chúng tôi.

Nếu công việc tùy chỉnh là một cách chắc chắn để xây dựng nợ kỹ thuật, làm thế nào để các cơ quan xử lý nó?

Điều đó khiến tôi suy nghĩ. Các công ty không có sản phẩm cốt lõi là trung tâm của mô hình kinh doanh của họ, họ luôn làm công việc phần mềm tùy chỉnh. Làm thế nào để họ đối phó với khái niệm nợ kỹ thuật? Làm thế nào nó không đẩy họ vào phá sản kỹ thuật ?

Nếu bạn có thể uốn cong các yêu cầu cụ thể của người dùng thành thứ gì đó sẽ hữu ích cho mọi người, thật tuyệt. Nếu khách hàng sẵn sàng trả chi phí hỗ trợ liên tục cho tính năng này, cũng rất tuyệt. Nhưng nếu bạn là một nhóm nhỏ và bạn thấy mình phải vật lộn để hỗ trợ tất cả các tính năng của mình, thì không có gì ngoài việc đưa ra một số quyết định khó khăn về các tính năng bạn cần ít nhất, và sau đó đầu tư thời gian để loại bỏ chúng khỏi cơ sở mã của bạn.

SaaS đặt bạn vào một vị trí tốt để thu thập số liệu thống kê sử dụng. Bạn nên xem xét việc cải thiện các tính năng của mình nếu bạn chưa có để bạn có thể theo dõi xem ai đang sử dụng cái gì. Kinh nghiệm của chúng tôi là những khách hàng bình thường nhất cũng thường bị rối loạn chức năng nhất; anh chàng đó đã giậm chân và nín thở cho đến khi bạn đưa cho anh ta nút xuất khẩu sang MS-Access có lẽ đã không sử dụng nó trong hơn một năm. Một số tính năng vẫn được duy trì mặc dù chỉ có một khách hàng đang sử dụng chúng, bởi vì khách hàng đó ồn ào và đe dọa sẽ đưa doanh nghiệp của anh ta đi nơi khác mỗi khi điều gì đó không làm anh ta hài lòng. Việc ngừng sử dụng tính năng này có thể khiến bạn mất một khách hàng ngay bây giờ, nhưng thời gian dành cho việc hỗ trợ tính năng đó có thể khiến bạn mất hàng chục khách hàng trong những năm qua. Nó là thước đo chất lượng của đội ngũ quản lý của bạn,

Khi bạn ngừng cung cấp một tính năng, hãy đảm bảo thông báo quyết định cho khách hàng của bạn (hoặc ít nhất là những người bị ảnh hưởng) trước, bất cứ nơi nào từ sáu tháng đến ba năm là hợp lý. Trong thực tế nếu bạn thấy mình đồng ý xây dựng các tính năng dành riêng cho người dùng, bạn có thể cố gắng để nhân viên bán hàng của mình xây dựng ngày hết hạn ngay từ đầu. Gọi nó là "hỗ trợ trọn đời" và nói rõ rằng họ muốn nó càng lâu thì càng tốn nhiều tiền. Cố gắng cung cấp cách giải quyết cho các khách hàng của bạn để họ không bị bối rối khi một tính năng hoạt động, ví dụ như tập lệnh chuyển đổi các tệp XML đã xuất của bạn thành định dạng truy cập MS hoặc một chút lời khuyên về cách chọn RDBMS tốt hơn.

Một cái gì đó có hiệu quả đối với chúng tôi như là một biện pháp phòng ngừa là lấy báo cáo từ nhóm bán hàng của chúng tôi gửi cho nhóm phát triển và quản lý của chúng tôi hàng tháng. Báo cáo này bao gồm phản hồi từ khách hàng - tính năng nào phổ biến nhất, tính năng nào được yêu cầu nhiều nhất, tính năng được đề xuất nào đang tạo ra tiếng vang lớn nhất. Điều này thật thú vị nếu bạn là nhà phát triển nhưng lợi ích thực sự là cho đội ngũ bán hàng, những người hiện đang suy nghĩ thêm một chút về từng tính năng trong bối cảnh của bức tranh lớn hơn, thay vì gửi một luồng yêu cầu tính năng vô tận và ưu tiên dựa trên trên đó khách hàng là lớn nhất. Hiệu quả đã làm cho nhân viên bán hàng của chúng tôi khó tính hơn khi đưa ra các yêu cầu tính năng mới trong một cuộc đàm phán vì họ có ý thức hơn về việc mỗi tính năng có thể phù hợp với đề xuất giá trị tổng thể của sản phẩm của chúng tôi.

Có mã mô-đun với nhiều bài kiểm tra tự động sẽ giúp bạn khi bạn hack các tính năng vào sản phẩm của mình và hack chúng trở lại, nhưng cuối cùng đây không phải là câu hỏi lập trình mà là câu hỏi quản lý. Viết mã để bán hàng là một trò chơi ngu ngốc.

Khi tôi phải đối mặt với các yêu cầu phát triển tùy chỉnh, tôi lọc chúng thông qua bộ lọc tuyệt vời để chia các yêu cầu thành 3 cọc:

1. những điều tuyệt vời sẽ hữu ích cho mọi người và tương đối dễ thực hiện
2. những điều tuyệt vời sẽ hữu ích cho mọi người và khó thực hiện
3. một trong những điều ngu ngốc chỉ cần cho một khách hàng này mà thực sự không cần đến họ

• Loại 1 được thực hiện trong chu kỳ dev hiện tại.
• Loại 2 được thực hiện trong chu kỳ phát triển tiếp theo.
• Loại 3 nhận được báo giá 1 tháng của thời gian dev sau đó hầu hết khách hàng nhận ra rằng yêu cầu của họ không xứng đáng.

Thành thật mà nói, điều này không bao giờ thất bại và tôi không nghĩ rằng cuối cùng chúng tôi đã thực hiện bất kỳ tính năng nào trong danh mục 3. Và tất nhiên không có khách hàng nào đi bộ (doanh số sẽ không cho phép tôi thực hiện điều này nếu không :)

(kinh nghiệm này là tại một công ty ISV)

do một số hạn chế nhất định, đôi khi chúng tôi cuối cùng đã uốn cong theo ý muốn của một số khách hàng nhất định và chúng tôi kết thúc việc xây dựng các phần mềm tùy chỉnh chỉ có thể được sử dụng cho khách hàng đó.

Vấn đề của bạn không phải là bạn đang tạo mã chỉ được sử dụng cho một khách hàng. Vấn đề là bạn đang kết hợp mã chỉ được sử dụng cho một khách hàng vào một sản phẩm mà bạn đang bán cho nhiều khách hàng khác không cần chức năng đó.

Các công ty không có sản phẩm cốt lõi là trung tâm của mô hình kinh doanh của họ, họ luôn làm công việc phần mềm tùy chỉnh. Làm thế nào để họ đối phó với khái niệm Nợ kỹ thuật? Làm thế nào nó không đẩy họ vào Phá sản kỹ thuật?

Họ giao sản phẩm. Và sau đó họ tiếp tục. Khi bạn đang phát triển một sản phẩm theo hợp đồng, mọi thứ bạn làm trong dự án đó đều dành cho một khách hàng đó. Bất kỳ khoản nợ kỹ thuật nào có thể tích lũy trong quá trình phát triển đều trở thành vấn đề của khách hàng sau khi hợp đồng kết thúc và nhà phát triển chuyển sang dự án khác cho một khách hàng khác.

Điều đó không có nghĩa là nó ổn để làm một công việc nhảm nhí, tất nhiên. Mục tiêu số một của bạn là làm cho khách hàng của bạn muốn tiếp tục làm việc với bạn, và thực hiện công việc chất lượng là cách để đạt được điều đó. Điều đó cũng không có nghĩa là nợ kỹ thuật không phải là vấn đề đối với các nhà phát triển hợp đồng. Ngay cả khi bạn liên tục tự viết mã sạch, rất có thể bạn sẽ được thuê vào một lúc nào đó để làm việc trong một dự án đã tích lũy một đống nợ. Điều đó có thể tốt (khách hàng muốn trả tiền cho bạn để dọn dẹp mớ hỗn độn) hay không (khách hàng không biết mã đó tệ đến mức nào và không hiểu tại sao "chỉ" thêm một vài tính năng sẽ mất nhiều thời gian như vậy ).

Tôi không đồng ý với tiền đề rằng công việc tùy chỉnh được đảm bảo để tạo ra nợ kỹ thuật. Tránh nợ kỹ thuật không có nghĩa là tránh một số loại chức năng - điều đó có nghĩa là tránh sự cứng nhắc không cần thiết, các vấn đề phụ thuộc và những điều khiến cho một cơ sở mã khó thay đổi (nghĩa là tốn kém). Chức năng tùy chỉnh không ngụ ý bất kỳ điều nào trong số này - nó chỉ bao hàm một cơ sở hẹp cho chức năng. Vì vậy, chìa khóa của họ là đưa yếu tố logic phổ biến, có thể tái sử dụng càng nhiều càng tốt ra khỏi triển khai càng tốt, để lại các công cụ một lần tùy chỉnh như mô-đun độc lập có thể được triển khai cho khách hàng yêu cầu.

Chẳng hạn, giả sử rằng bạn có một ứng dụng có thể phân phối là một ứng dụng web nội bộ mà khách hàng của bạn sẽ cài đặt trên mạng nội bộ. Một ngày nọ, một khách hàng xuất hiện và đề nghị lái một chiếc xe tải chở đầy tiền cho công ty của bạn nếu bạn tạo phiên bản cho họ có ứng dụng máy tính để bàn "khách hàng giàu" thay vì giao diện trình duyệt. Chà, nếu hệ thống của bạn được kiến ​​trúc tốt và các phần phụ thuộc của bạn được quản lý tốt, thì đây chỉ là vấn đề sử dụng lại tên miền, truy cập dữ liệu và các thành phần dịch vụ trong khi tạo một thành phần trình bày mới. Nợ kỹ thuật không phải là một sự cân nhắc, mặc dù bạn chỉ có một khách hàng muốn quay lại năm 1999 và có một ứng dụng máy tính để bàn cho việc này.

Đây là một câu hỏi hơi phức tạp để trả lời bởi vì giống như nhiều điều nó thực sự phụ thuộc vào hoàn cảnh của dự án, mức độ kiểm soát của công ty hợp đồng, liệu phần mềm tùy chỉnh có được quản lý bởi công ty hợp đồng trong toàn bộ vòng đời hay không, số tiền về "sự can thiệp" của những người khác có quyền truy cập vào cơ sở mã, thái độ của tất cả những người liên quan, sự phức tạp của dự án và phương pháp được sử dụng ... Tôi thực sự có thể tiếp tục.

Tất cả các hệ thống có một mức độ nợ kỹ thuật. Trong một số trường hợp, điều này có thể không đặc biệt đáng chú ý do những nỗ lực mẫn cán từ phía các nhà phát triển làm việc luôn luôn duy trì một cơ sở mã sạch, tuy nhiên không có hệ thống nào là hoàn hảo và một thiết kế lại lớn có thể làm cho một vấn đề dường như vô hại nhưng lâu dài trở nên rõ ràng. Vậy làm thế nào để các công ty hợp đồng xử lý việc này?

Trong nhiều trường hợp họ không. Thông thường phần mềm sẽ được viết bởi một công ty, sau đó được sửa đổi bởi một công ty khác và không có gì lạ khi thấy cơ sở mã bị rối tung vì mỗi công ty theo hợp đồng làm việc theo thời hạn chặt chẽ và sẽ không biện minh cho thời gian để giữ sạch mã ( và đôi khi hầu như không được kiểm tra) nếu điều đó có nghĩa là họ có thể có nguy cơ bỏ lỡ thời hạn.

Trong các trường hợp khác, bạn thấy các công ty không chỉ quản lý tốt dự án đã ký hợp đồng của mình mà còn bằng cách nào đó tìm thấy thời gian để rời khỏi cơ sở mã hiện tại ở trạng thái tốt hơn so với họ đã tìm thấy. Họ làm điều này thường xuyên với kế hoạch cẩn thận, xác định các nguồn nợ kỹ thuật - thường là những nguồn sẽ ảnh hưởng đến công việc mới nhất - và họ đưa ra các chiến lược để cung cấp các trường hợp thử nghiệm và sửa đổi góp phần quản lý nợ kỹ thuật và đưa tất cả những điều này vào lịch trình dự án của họ .

Là một phần mềm tùy chỉnh đảm bảo nợ kỹ thuật thay vì viết một sản phẩm trung tâm? Câu trả lời ngắn gọn là không, tuy nhiên có khả năng nợ kỹ thuật sẽ tích lũy nếu không được xử lý tích cực. Điều này giống như với bất kỳ dự án phần mềm khác. Nếu bạn kiểm soát dự án hoàn toàn trong suốt vòng đời của nó, thì bạn có cơ hội tốt hơn để xử lý nợ kỹ thuật. Nếu không, sau đó bạn sẽ cần phải xử lý nợ kỹ thuật có thể đã tích lũy từ mã mà công ty trước đó để lại.

Mặt khác, nếu câu hỏi của bạn là hỏi liệu viết phần mềm bất kể mô hình kinh doanh của bạn có đảm bảo cho nợ kỹ thuật hay không. Câu trả lời sẽ là Tuyệt đối. Câu hỏi thực sự là làm thế nào bất kỳ công ty xử lý nợ kỹ thuật. Hãy để nó tích lũy và xử lý nó vào thời gian đã định, hoặc quản lý một cơ sở mã sạch theo cách liên tục để trả hết nợ kỹ thuật càng sớm càng tốt? Câu trả lời đó thuộc về các ưu tiên cá nhân của một công ty và liệu các khoản nợ kỹ thuật phát sinh có liên quan đến tài chính hay không.

Phần mềm tùy chỉnh không phải là một đảm bảo của nợ kỹ thuật, nhưng phục vụ hai thạc sĩ là.

Một công ty phần mềm tùy chỉnh sẽ xây dựng một phần mềm phù hợp chính xác với nhiệm vụ trong tay, phân phối và bảo trì nó nếu cần thiết. Phần mềm tùy chỉnh thực sự thường không cần các tính năng mới được thêm vào rất thường xuyên.

Vấn đề được mô tả trong câu hỏi này là khi các công ty sản phẩm xây dựng các tính năng tùy chỉnh thành một sản phẩm chung khác. Nếu sản phẩm hoàn toàn tùy chỉnh, nó sẽ chỉ di chuyển khi các yêu cầu tại một khách hàng thay đổi. Nếu sản phẩm hoàn toàn chung chung, nó sẽ chỉ di chuyển khi các tính năng mới được thêm vào để làm cho nó hấp dẫn hơn. Nhưng khi bạn có một tính năng tùy chỉnh trong một sản phẩm chung khác, bạn có hai đoạn mã, tiếp xúc gần, di chuyển ở các tốc độ khác nhau. Giống như các mảng kiến ​​tạo gây ra động đất, giao diện giữa các đoạn mã này là một "điểm nóng", chín muồi cho các vấn đề.