Làm thế nào để thoát ra khỏi đường ray hỗ trợ và bắt đầu trả nợ kỹ thuật!


13

Tôi có một người bạn". Vâng, khởi đầu tốt tôi biết nhưng thật lòng đây không phải là tôi!

Về cơ bản, anh ấy đã làm việc trong một dự án thành công được khoảng 4 năm, khó khăn là nợ kỹ thuật đã bắt kịp và anh ấy thấy gần như không thể ngừng hỗ trợ sản phẩm (điều chỉnh cái này và cái kia) và thực sự tiếp tục phát triển thực sự.

Tôi đã đưa ra nhiều đề xuất khác nhau, ghi lại tất cả thời gian của bạn, tạo vé, không trả lời email, v.v. Vấn đề với điều này là dường như chỉ đóng vai trò như một lời nhắc nhở rằng anh ta không làm được gì "hữu ích".

Các khoản nợ kỹ thuật phần lớn đã xảy ra bởi vì trong trường hợp đầu tiên, đó là một lợi ích lớn cho sản phẩm, để nhận các yêu cầu và cuộc gọi điện thoại từ người dùng và chỉ cần nhanh chóng thực hiện chúng.

Những gì tôi muốn biết là có ai có bất kỳ đề xuất nào về cách anh ta có thể thoát khỏi lối mòn này không, một phần lớn trong số đó sẽ thay đổi nhận thức của người dùng để họ không nghĩ rằng họ có thể gọi và mong đợi điều gì đó được thực hiện sau đó ở đó.

Tất cả đều nói rất rõ kế hoạch tốt hơn, mặc dù tôi hiểu rằng rất khó để lập kế hoạch phát triển thực tế với yêu cầu hỗ trợ và áp lực tương đối từ người dùng (xem ở trên).


2
Nếu tôi hiểu chính xác câu hỏi của bạn, bạn của bạn quá bận rộn để xử lý các yêu cầu hỗ trợ / thay đổi người dùng để dọn dẹp mã. Có bất kỳ tính năng mới nào mà người dùng đang yêu cầu đang được duy trì như là kết quả không?
Larry Coleman

@larry coleman, oh yeah đây là một vòng tròn nhớt, các yêu cầu mới bị trì hoãn, điều này cũng gây thất vọng như sự hỗ trợ liên tục.
MrEdmundo

Câu trả lời:


13

Tổ chức của bạn của bạn rất cần một người nào đó thực hiện quản lý thay đổi. Người hoặc nhóm này sẽ thực hiện các yêu cầu thay đổi và sửa lỗi và ưu tiên chúng theo tác động kinh doanh và số lượng nỗ lực cần thiết. Bằng cách đó, các nhiệm vụ quan trọng hơn đối với toàn bộ tổ chức sẽ được thực hiện trước tiên, trái ngược với các nhiệm vụ quan trọng hơn đối với bất cứ ai đang làm phiền bạn của bạn vào lúc này.

EDIT: Như một ví dụ về cách thức hoạt động của nó, hầu hết các tổ chức có quy mô nghiêm trọng. Mức độ nghiêm trọng cao nhất là một ứng dụng hoặc chức năng quan trọng trong kinh doanh không hoạt động. Nếu có điều gì đó mà doanh nghiệp có thể làm để giải quyết vấn đề, điều đó sẽ làm giảm mức độ nghiêm trọng xuống cấp độ tiếp theo. Nếu ứng dụng không quan trọng trong kinh doanh, điều đó làm cho mức độ nghiêm trọng thậm chí thấp hơn. Yêu cầu cải tiến mới thường được ưu tiên riêng biệt.


Hiểu được, làm thế nào để giúp với bất kỳ nhiệm vụ hàng ngày mà hiệu trưởng phải được thực hiện và dường như nắm bắt bất kỳ ưu tiên nào được đưa ra.
MrEdmundo

2
Tôi đoán từ câu hỏi của bạn rằng không có một người hay nhóm nào chịu trách nhiệm thiết lập các ưu tiên có đủ thẩm quyền để khiến họ gắn bó. Đó là một vấn đề lớn. Tôi thậm chí sẽ đi xa hơn để đề nghị bạn của bạn tìm kiếm việc làm mới nếu không thể giải quyết được.
Larry Coleman

hmmmm, tôi thấy quan điểm của bạn, mặc dù một lần nữa tôi không chắc điều này giúp thay đổi nhận thức của các doanh nghiệp như thế nào khi hầu hết các nhiệm vụ mà anh ta làm việc được coi là ưu tiên. Làm thế nào để bạn thay đổi ý tưởng rằng yêu cầu của một người luôn luôn là ưu tiên hàng đầu nhưng không còn nữa nếu không có sự chấp nhận của người đó. Có lẽ câu trả lời anh cần thêm nhân viên.
MrEdmundo

2
Cách duy nhất làm việc này là nếu một người xếp hạng từ doanh nghiệp đang đặt ưu tiên. Nếu người đứng đầu đơn vị kinh doanh đặt ra các ưu tiên, ví dụ, phần còn lại của doanh nghiệp sẽ đi cùng với nó nếu họ coi trọng công việc của họ. Họ có thể không thích nó, nhưng đó sẽ không phải là vấn đề của bạn bè bạn.
Larry Coleman

10

Làm cho người khác nhận cuộc gọi và thay đổi đường dây từ

Chúng tôi sẽ đến đó ngay lập tức.

đến

Đề nghị rất tốt. Tôi sẽ tạo một yêu cầu tính năng để bắt đầu làm việc với nó càng sớm càng tốt. Nếu bạn muốn theo dõi tiến trình theo yêu cầu của mình, bạn có thể theo dõi tại đây: [liên kết đến vé theo dõi trường hợp]. Trong tương lai, bạn cũng có thể gửi yêu cầu cho tương lai theo cách tương tự như tôi ở đây: [link to case tracker]

Đó có lẽ là cách đơn giản và hiệu quả nhất để làm điều đó theo ý kiến ​​của tôi. Bit cuối cùng cố gắng giảm căng thẳng cho người này trả lời các cuộc gọi theo thời gian.

Vấn đề bạn gặp phải với hệ thống 'ưu tiên' hiện tại là khi mọi thứ đều là ưu tiên, không có gì là ưu tiên . Vì thế, bạn của bạn rất cần nghe theo lời khuyên của @Larry Coleman - những người tách biệt khỏi sự phát triển quản lý các yêu cầu thay đổi. Lý tưởng nhất là bạn của bạn thậm chí không biết về một yêu cầu tính năng, cho đến khi nhóm riêng biệt đó đồng ý rằng nó nên được ưu tiên cho công việc. Đó thậm chí có thể là người mới này đang trả lời các cuộc gọi hiện đang ưu tiên họ - miễn là họ hiểu doanh nghiệp và hiểu sự phát triển.


3
+1 cho "khi mọi thứ là ưu tiên, không có gì là ưu tiên"
Larry Coleman

2

Tôi đã trải qua một tình huống tương tự bản thân mình. Sản phẩm được xây dựng trên dây giày và lần đầu tiên trên thị trường ra mắt. Ban đầu nó đã thành công (đối với một doanh nghiệp solo-preneur), nhưng tôi cho rằng mọi thứ đã hoạt động từ 2003-2007. Tôi đã tìm kiếm nhân viên đó nhưng học được một cách khó khăn là thuê nhân viên giỏi là tốn kém và không có nghĩa là dễ dàng. Tôi nhận nó bạn của bạn đang ở trong một tình huống tương tự.

Trong trường hợp của tôi, mọi thứ trở nên rõ ràng rằng mọi thứ sẽ xuống dốc vào một lúc nào đó. Công việc kinh doanh vẫn phát triển, nhưng sự cạnh tranh đang trở lại, thị trường trông như thể sẽ thu hẹp lại, có những dấu hiệu ban đầu (giữa năm 2006) rằng sự suy thoái kinh tế đang diễn ra, v.v. Về cơ bản, một số yếu tố đã dẫn đến Tôi quyết định rằng sản phẩm cuối cùng sẽ chết; càng muộn, càng tốt (cho khách hàng, và bản thân tôi).

Nhìn lại, có lẽ tôi đã đưa ra nhiều quyết định tốt như tôi đã làm những điều xấu, nhưng đây là một bước đi ngắn gọn:

  1. Nhân viên nó đúng cách và sớm. Nhận tài trợ nếu bạn cần nó. (Không tìm kiếm bất kỳ sai lầm lớn nhất của tôi.) Nếu bạn bán hàng, bạn sẽ tìm thấy tiền.

  2. Sử dụng kiểm soát phiên bản / kiểm tra đơn vị / tất cả các hoopla liên quan đến thực tiễn tốt nhất. Tất cả đều trông ngớ ngẩn / lố bịch / không thú vị khi được dạy ở trường đại học nhưng họ thường thực hành tốt nhất vì những lý do chính đáng.

  3. Thuê ít nhất một anh chàng bán hàng / tiếp thị, đặc biệt nếu bạn thiên về công nghệ. (Bởi vì nếu vậy, bạn sẽ có xu hướng tự nhiên dành nhiều thời gian cho các vấn đề công nghệ hơn là tiếp thị, ngay cả khi bạn đã có một mạng lưới liên kết).

  4. Đám đông-nguồn hỗ trợ của bạn. Thiết lập một diễn đàn, để người dùng có thể tự giúp mình. Thiết lập một hệ thống bán vé và mời người dùng chuyên gia của bạn (thường là người dùng diễn đàn thường xuyên) đi sâu vào một phần đặc biệt dưới dạng trợ lý ảo. Hãy để họ quan tâm đến vô số khách hàng cần điều này / nhiệm vụ nhỏ đó được thực hiện trong một vài đô la, để bạn có thể tập trung vào bức tranh lớn hơn.

  5. Tối đa hóa nỗ lực của bạn trong việc giảm số lượng hỗ trợ bạn đang cung cấp. Bạn càng có ít sự hỗ trợ, bạn càng có nhiều thời gian để làm những điều thú vị hơn. Vào thời điểm sản phẩm là bằng chứng giả, khách hàng sẽ biết ơn và nhân viên bán hàng cũng như nhân viên hỗ trợ của bạn cũng vậy.

  6. Yêu cầu các nhà phát triển thực tế thực hiện một số hỗ trợ (một hoặc hai giờ mỗi ngày để họ không mất liên lạc với thực tế) và giúp họ tự do đề xuất bất kỳ kỹ sư tái tạo / thay đổi sản phẩm (UI, chức năng) nếu họ xác định bất cứ điều gì sẽ khiến họ dành ít thời gian hơn cho hỗ trợ. Ý tưởng là, nếu họ bị người dùng cằn nhằn hết lần này đến lần khác vì những lý do tương tự, họ sẽ muốn sửa chữa mọi thứ càng sớm càng tốt để họ có thể thoát khỏi các cuộc gọi hỗ trợ. Và những người thông minh hơn thực sự làm như vậy, và đó chính xác là những gì bạn muốn.

  7. Nếu bạn cảm thấy sản phẩm sắp chết, hãy quyết định giết nó ở đây và ở đó và làm việc ở bước tiếp theo. Hãy để nó chết, thực sự. Một con bò tiền mặt là một con bò tiền mặt; khi nó đã phục vụ mục đích của nó, hãy gửi nó cho người bán thịt. Làm như vậy một cách nhẹ nhàng (đối với khách hàng), nhưng bằng mọi cách, đừng để sự tồn tại kéo dài của nó ngốn quá nhiều thời gian của bạn nếu chi phí bảo trì là đối thủ cạnh tranh của bạn, với lợi ích là người đến sau và bạn đã tích lũy một số nợ kỹ thuật , sẽ thực hiện các tính năng mới nhanh hơn bạn có thể.


1

Một dòng tại một thời điểm. Dành thêm một chút thời gian cho mỗi lần sửa chữa, dọn dẹp các bản hack và thêm các bài kiểm tra tự động khi bạn đi. Thông thường, làm một cái gì đó đúng sẽ kết thúc nhanh hơn nhiều so với việc thêm một hotfix khác. Nếu quản lý thúc đẩy bạn của bạn làm việc nhanh hơn, vì quản lý thường thích làm, anh ta nên phát triển một lớp da dày hơn và chuyển sang chế độ "khi xong việc".


0

Điều quan trọng là loại phương pháp phát triển nào anh ta có xung quanh anh ta để bảo vệ anh ta ở một mức độ nào đó? Ví dụ, trong Scrum có ý tưởng rằng công việc sẽ được thực hiện không thay đổi trong giai đoạn nước rút thường. Do đó, có một số quy tắc về những gì sẽ được thực hiện và những gì có thể không được thực hiện ngay lập tức. Câu hỏi còn lại là quản lý hỗ trợ anh ta muốn không tham gia hỗ trợ ở mức độ nào? Điều này cũng có thể quan trọng vì một quản lý lãnh đạm có thể là một hồi chuông báo tử cho dự án của bạn của bạn.


0

Điều tốt nhất để làm là dừng xe buýt và nhìn lại. Bạn của bạn nên

  • Vẽ một báo cáo về từng vấn đề trong hệ thống và lý do đằng sau tại sao chúng là xấu. Các vấn đề thiết kế nên được làm nổi bật, và số lượng tái cấu trúc phân.
  • Các mốc thời gian thô nên được đưa ra để khắc phục các vấn đề
  • Báo cáo nên được trao cho người quản lý của mình và sau đó cho những người nắm giữ cổ phần trong hệ thống
  • Tất cả các phát triển tính năng nên được tạm dừng trong thời gian sửa chữa.

Nhiều dự án làm điều này. Nếu quản lý không thể tin đó là một trường hợp bị mất, nhưng nếu họ đồng ý, hệ thống có thể được đưa trở lại hình dạng trong thời gian dài.


Về lý thuyết nghe có vẻ tốt, nhưng nếu ứng dụng là nhiệm vụ quan trọng, thì tính năng đóng băng có thể không phải là một lựa chọn.
tdammers

Sau đó có thể là thời điểm tốt để phân nhánh và thêm một nhà phát triển khác để bảo trì.
Tjaart
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.