Các kỹ sư phần mềm cũng nên đóng vai trò là hỗ trợ công nghệ? [đóng cửa]

Một kỹ sư phần mềm cũng nên đóng vai trò là hỗ trợ kỹ thuật? Đó là, nếu một công ty cho phép các kỹ sư của họ đội cả kỹ sư phần mềm và mũ hỗ trợ kỹ thuật. Có vẻ như nó sẽ loại bỏ khả năng viết phần mềm nếu phần lớn thời gian của một kỹ sư được hỗ trợ kỹ thuật.

Đây là một vấn đề kinh điển trong các công ty có thành phần phát triển phần mềm trong công việc của họ, cho dù họ có phải là công ty phần mềm hay không. Tôi đấu tranh với điều này tất cả các thời gian.

Có nhà phát triển tham gia hỗ trợ sản xuất

Ưu

• Chiến đấu với hội chứng "Phát triển trong chân không" . Thật có giá trị khi được tiếp xúc với cách người dùng sử dụng ứng dụng. Cho đến khi cuối cùng tôi thấy đây là một nhà phát triển trẻ, tôi đã không nhận ra mình là một nhà phát triển UI ngu ngốc. Tất cả những gì tôi quan tâm là mã hóa và không thiết kế, phân tích hoặc quan điểm của người dùng.
• Các nhà phát triển không giỏi như họ nghĩ họ có thể khiêm tốn (mặc dù không có gì đảm bảo bạn sẽ nhận được lợi ích này; một số nhà phát triển thực sự lãng quên, ích kỷ và bướng bỉnh).
• Các nhà phát triển sẽ đạt được kiến ​​thức tên miền . Điều này rất quan trọng nếu các nhà phát triển của bạn cuối cùng sẽ trở nên tốt hơn trong việc xác định và điền vào các khoảng trống trong giai đoạn phân tích kinh doanh (giả sử có bất kỳ) bỏ ​​lỡ.
• Hỗ trợ tốt là một điểm tiếp thị. Nếu bạn làm tốt, khách hàng sẽ đánh giá cao nó. Và một nhà phát triển toàn diện với các kỹ năng giao tiếp và kiến ​​thức tên miền có khả năng làm tốt điều này. Tuy nhiên, tôi vẫn thích các ứng dụng có chất lượng đủ cao mà chúng không cần hỗ trợ. Chất lượng vượt trội là hình thức hỗ trợ khách hàng của riêng mình (và cũng là một điểm tiếp thị).

Nhược điểm

• Yếu tố gián đoạn . Đây là lỗi số một của công việc trộn dự án và công việc hỗ trợ, không có gì. Các dự án can thiệp vào hỗ trợ, và hỗ trợ can thiệp vào các dự án. Các dự án phụ thuộc vào ước tính và tiến độ quan trọng, hỗ trợ là không thể đoán trước và có thể liên quan đến sự cấp bách ngẫu hứng. Các dự án dựa trên lịch trình, hỗ trợ dựa trên gián đoạn. Không phải là một sự kết hợp hạnh phúc, và rất bực bội cho các nhà phát triển để đối phó.
• Không phải ai cũng giỏi hỗ trợ . Một người ít kinh nghiệm với ứng dụng hoặc doanh nghiệp hoặc ai đó có cá tính hoặc kỹ năng giao tiếp sao cho họ được bảo vệ tốt hơn khỏi quyền truy cập của người dùng có thể không hoạt động tốt trong hỗ trợ.
• Sử dụng tài nguyên không hiệu quả . Frank Shearar lưu ý trong các ý kiến ​​rằng một nhà phát triển thực hiện hỗ trợ tầm thường có thể đắt hơn công nghệ hỗ trợ cấp một.

Theo kinh nghiệm của tôi, hầu hết các nhà phát triển không thích hỗ trợ. Đã phục vụ ở cả hai bên dự án và hỗ trợ, tôi có thể thông cảm. Khi phải làm cả hai cùng một lúc, yếu tố giảm thiểu thường là làm thêm giờ, thường không được trả lương, để giải quyết các trường hợp khẩn cấp hỗ trợ và vẫn đưa ra thời hạn dự án. Các nhà quản lý dự án thích làm thêm giờ không được trả lương vì điều đó có nghĩa là hẹn hò mà không tốn nhiều tiền hơn, nhưng đối với các nhà phát triển, đó chỉ là một bát lớn.

Tuy nhiên, tôi cũng tin rằng nếu các nhà phát triển đã làm tốt hơn việc tạo ra các hệ thống trực quan và đáng tin cậy, bạn sẽ có ít sự hỗ trợ hơn. Vì vậy, điều này tạo ra một đối số tròn kỳ lạ để trộn lẫn hai. Những gì tôi nghĩ bạn nên làm nếu bạn phải làm cả hai là tìm cách để tránh làm cho nó đồng thời.

Tôi nghĩ rằng các nhà phát triển đã đội hai chiếc mũ. Hỗ trợ giống như một bộ lọc được sử dụng để bảo vệ sự phát triển khỏi các vấn đề tầm thường như không cắm máy tính. Tuy nhiên, cần có sự kết hợp chặt chẽ giữa phát triển và hỗ trợ. Một số khách hàng có vấn đề chính đáng có thể là kết quả của một lỗi. Trách nhiệm của sự phát triển là giúp giải quyết những vấn đề này càng sớm càng tốt. Vì vậy, theo một nghĩa nào đó, các nhà phát triển đã là một phần của nhóm hỗ trợ ... hãy gọi đó là hỗ trợ cấp 2.

Nhấn mạnh, không.
Chúng ta đều biết làm thế nào khó khăn để có thể phải dừng những gì bạn đang làm để yêu cầu trả lời một câu hỏi. Tôi trả lời điện thoại cho một bàn trợ giúp và tôi viết một số ứng dụng tiện ích.

Tôi không thể tập trung giải quyết vấn đề vì cứ sau 5 phút tôi lại phải nhấc điện thoại. Cả hai công việc đều không được thực hiện tốt như tôi có thể vì tôi liên tục nghĩ về những gì tôi có thể làm để giải quyết vấn đề và tôi không bao giờ làm việc với chương trình đủ lâu để thực hiện đầy đủ bất kỳ giải pháp nào tôi có thể có.

Một lần nữa, tôi không thể nhấn mạnh đủ tầm quan trọng của việc có thể tập trung vào khía cạnh này hay khía cạnh khác.

Tôi sẽ không bao giờ đặt một nhà phát triển là hỗ trợ dòng đầu tiên. Số lần gián đoạn và số tiền bạn sẽ phải lặp lại sẽ khiến hầu hết các nhà phát triển hét lên RTFM và cúp máy cho người tiếp theo gọi. Đây không phải là thứ mà khách hàng của bạn cần, đây cũng không phải là thứ bạn muốn các nhà phát triển của mình phải chịu đựng.

Có một quy tắc nhất định trong bất kỳ vị trí dịch vụ khách hàng. Đối với một người gọi giận dữ, người đầu tiên trả lời điện thoại là sai. Cho dù họ có chủ tịch của công ty, người phát triển ứng dụng hay người quản lý hỗ trợ, điều đó không thành vấn đề. Khi khách hàng có được người thứ hai, người có thể hoặc không thể biết họ đang làm gì, khách hàng sẽ có thể bình tĩnh và giải thích vấn đề rõ ràng hơn.

Đây không phải là một môi trường bạn muốn giữ lại các nhà phát triển tốt. Có giá trị nào khi nhà phát triển tương tác với khách hàng về một vấn đề đặc biệt khó khăn vượt xa "tại sao người giữ cốc của tôi không làm việc nữa"? Chắc chắn rồi. Nhưng đó là sau khi yêu cầu hỗ trợ đã được xem xét thông qua các dòng hỗ trợ cấp một và cấp hai.

Nó phụ thuộc vào công ty.

Công việc của tôi là chính xác như thế này . Tôi là một nhà phát triển phần mềm, nhưng vì chúng tôi là một công ty khá nhỏ, mỗi nhà phát triển đảm nhận vai trò hỗ trợ "không chính thức" thường dựa trên phần mềm của riêng họ. Một số nhà phát triển phải thực hiện nhiều hỗ trợ hơn các nhà phát triển khác, tùy thuộc vào một số yếu tố như số lượng sản phẩm họ đã phát triển / vận chuyển, sản phẩm của họ có lỗi như thế nào và hiệu quả của chúng khi hỗ trợ . Nếu bạn có thể cung cấp cho khách hàng chính xác những gì họ cần để giải quyết vấn đề, họ sẽ tiếp tục quay lại với bạn để giải quyết vấn đề nhanh nhất có thể. Con dao hai lưỡi? Đúng. Bạn bị giảm năng suất, nhưng khách hàng hài lòng, và nhiều khả năng vẫn là khách hàng. Điều này rất quan trọng đối với các công ty nhỏ hơn.

Chúng tôi có một nhóm hỗ trợ hệ thống, nhưng vì bản chất của những gì chúng tôi làm, họ chủ yếu phải giải quyết các vấn đề liên quan đến phần cứng. Cá nhân, trong một công ty nhỏ hơn, vấn đề này không gây khó chịu như người ta tưởng. Chắc chắn, bạn nhận được cuộc gọi trong khi bạn đang cố gắng thực hiện một số tính năng quan trọng, nhưng đồng thời, dịch vụ khách hàngđược cải thiện nhiều; họ có thể có tiếng nói có thẩm quyền biết (trong nhiều trường hợp) cách giải quyết vấn đề của họ thay vì một người có thông tin cũ và tập lệnh hỗ trợ. Nếu bạn không thể giải quyết vấn đề ở đó và sau đó, có thể trấn an cá nhân họ rằng bạn sẽ thực hiện sửa lỗi cho lỗi của họ hoặc xem xét yêu cầu tính năng của họ để phát hành trong tương lai. Bạn có thể nhận được phản hồi thực sự trực tiếp từ người dùng phần mềm của mình, vì vậy phiên bản tiếp theo của bạn có thể còn tuyệt vời hơn bạn nghĩ.

Tôi thích nghĩ rằng khách hàng hài lòng tạo ra một hình ảnh tích cực hơn về công ty của bạn, điều này thường dẫn đến nhiều khách hàng hơn . Và đó là lý do tại sao, là một kỹ sư phần mềm, tôi thích hỗ trợ công nghệ.

Không có gì bực bội hơn là bộ phận hỗ trợ công nghệ máy tính không sẵn sàng kết nối bạn với một người thực sự hiểu chuyện gì đang xảy ra. Tôi hy vọng rằng bất kỳ công ty ứng dụng lớn nào cũng sẽ có một số lập trình viên làm việc hỗ trợ công nghệ.

Các nhà phát triển nên là dòng hỗ trợ cuối cùng.

Chỉ khi bộ phận trợ giúp và bộ phận QA của chúng tôi không thể giúp khách hàng, chúng tôi mới được giải quyết. Và thậm chí sau đó nó phải đi qua hệ thống theo dõi lỗi ưu tiên của chúng tôi.

Nếu đó là một vấn đề thực sự lớn, chúng tôi sẽ nghe nó.

Tôi sẽ chỉ làm điều này nếu đó là một nhà phát triển mới hoặc một người không quen thuộc với tên miền và cơ sở khách hàng. Làm cho nó trở thành một điều vĩnh viễn không phải là một ý tưởng tốt.

Công việc cuối cùng của tôi là chính xác này. Chúng tôi hỗ trợ các hệ thống hiện có và cũng đã viết những hệ thống mới khi cần thiết. Đó là một thảm họa hoàn toàn. Tôi sẽ liên tục bị gián đoạn. Tinh thần của tôi rất thấp vì các dự án bắt đầu sẽ mất mãi mãi để hoàn thành. Ngoài ra, chúng tôi đã phải mang theo một máy nhắn tin để được hỗ trợ ngoài giờ mà không phải trả thêm tiền (đây là trong lĩnh vực chăm sóc sức khỏe). Tôi nghĩ rằng giải pháp (mà tôi đã đề xuất với người quản lý của mình vào thời điểm đó), sẽ là có một tuyến đầu hỗ trợ kỹ thuật và nếu đó là một lỗi phần mềm thì hãy chuyển tiếp cho các nhà phát triển. Không cần phải nói tôi chỉ kéo dài một năm rưỡi cho đến khi cuối cùng tôi rời đi để có một công việc phát triển tốt hơn!

Một số thời gian, chắc chắn là có. Đối mặt với khách hàng thường đưa ra một viễn cảnh mà hầu hết mọi người, đặc biệt là lập trình viên, thiếu. Cách người dùng thực sự sử dụng sản phẩm, hoặc thực sự nghĩ rằng thường khác xa với cách người xây dựng (kỹ sư) nghĩ rằng họ làm.

Nó nên dành cho các gợi ý định kỳ ngắn, để không làm gián đoạn nhiệm vụ phát triển thực tế.

Có những tài năng và kỹ năng bạn cần để phát triển phần mềm, và những tài năng và kỹ năng bạn cần để có hiệu quả trong hỗ trợ hàng đầu. Tôi không biết rằng những tài năng này có bất kỳ mối tương quan.

Điều này có nghĩa là bạn phải thuê các nhà phát triển dựa một phần vào khả năng hỗ trợ qua điện thoại của họ hoặc bạn để khách hàng của mình trực tiếp nói chuyện với những người không giỏi xử lý khách hàng và không muốn làm việc đó ngay từ đầu. Điều này có thể hoặc không thể tốt hơn việc họ nói chuyện với một anh chàng có giọng Ấn Độ dày, người đọc từ một kịch bản lịch sự.

Ngoài ra, khi bạn làm cho công việc trở nên khó chịu (và tôi không biết bất kỳ nhà phát triển nào thực sự thích hỗ trợ trực tuyến), một số nhà phát triển của bạn sẽ rời đi. Nhìn chung đây là những người có thể có được công việc khác dễ dàng hơn: tức là những người giỏi. Khi quá trình này diễn ra, bạn kết thúc với một cửa hàng chứa đầy những người kém tài năng, khiến cho người có thẩm quyền không thể bỏ qua lời đề nghị công việc đầu tiên từ người khác.

Khi phát triển nghiêm túc, hãy quên nó đi nếu thường xuyên bị gián đoạn. Vợ tôi đã phàn nàn rất nhiều về việc dự kiến ​​sẽ phát triển và hỗ trợ người dùng đồng thời.

Tôi nghĩ rằng rất nhiều trong số đó phụ thuộc vào công ty. Công ty BigCo điển hình của bạn thường có thể đủ khả năng để có người hỗ trợ để cách ly các nhà phát triển. Mặt khác, một startup có tổng cộng ba người có thể không có tài nguyên để cung cấp cho những người hỗ trợ riêng biệt.

Tôi nghĩ rằng chiến lược chung tốt nhất (không liên quan đến quy mô công ty hoặc nguồn lực) là sử dụng các nhóm hỗ trợ để khắc phục sự cố treo trái cây thấp và các vấn đề phổ biến nhất ("Bạn đã thử tắt và bật chưa?"). Các kỹ sư nên làm việc với khách hàng về các vấn đề phức tạp hơn đòi hỏi kiến ​​thức về cách hệ thống hoạt động cùng với sự hỗ trợ theo định hướng của nhà phát triển hơn (API, công cụ dành cho nhà phát triển, v.v.). Bạn có thể yêu cầu người hỗ trợ đóng vai trò là một "liason", nhưng tôi thấy điều đó thường rắc rối hơn giá trị của nó.

Mặc dù tôi không nghĩ rằng việc sử dụng dev làm hỗ trợ mọi lúc, tôi nghĩ rằng có một điều gì đó để nói về việc có một nhà phát triển hỗ trợ ban đầu cho một ứng dụng. Điều này đặc biệt bao gồm hỗ trợ sau giờ làm việc. Tôi cũng nghĩ rằng có thể hữu ích để chúng được lên lịch để hỗ trợ sau giờ làm việc cho các ứng dụng của họ một cách thường xuyên.

Không có gì giống như nhiều cuộc gọi 3AM để khiến bạn nhận ra ảnh hưởng gì đến các quyết định thiết kế và / hoặc phím tắt nhất định đối với khả năng mọi người hỗ trợ và duy trì mã của bạn.

Lý tưởng là không vì những lý do nêu trên, nhưng có trong khi dự án còn non trẻ, bởi vì các nhà phát triển có thể cung cấp các giải pháp nhanh chóng, thường được doanh nghiệp mong đợi, hỗ trợ cho việc cải tiến phần mềm. Tôi đánh giá cao các nhà phát triển cung cấp hỗ trợ một cách thông minh: ví dụ, những người cho vay các kỹ năng phân tích của họ cho nhóm hỗ trợ toàn thời gian chính thức hơn và những người trả lời doanh nghiệp theo cách thể hiện tinh thần phục vụ và hợp tác. Chìa khóa thành công này mặc dù bao gồm quản lý công nhận và chính thức hóa hỗ trợ cấp một và cấp hai để nhanh chóng giảm tải cho các nhà phát triển khỏi vai trò chỉ là vai trò ngắn hạn của họ. Các nhà phát triển thể hiện sở trường cho cả phát triển và hỗ trợ nên được xây dựng như hỗ trợ cấp ba hoặc hỗ trợ cho những người hỗ trợ. Vì vậy, nên là phụ thuộc thời gian, tài năng và mong muốn phụ thuộc, và được quản lý hiệu quả.

Sở thích của tôi là trả lời các câu hỏi hỗ trợ khó khăn và lấy những gì tôi đã học được từ kinh nghiệm để giảm nhu cầu hỗ trợ nói chung, có lợi cho người dùng cuối và hỗ trợ chính.

Tôi đã rơi vào cái bẫy này khi tôi gia nhập một công ty có lương cao. Trong cuộc phỏng vấn tôi đã được thông báo rằng sẽ có 70% phát triển và 30% hỗ trợ và tôi đã chấp nhận lời đề nghị. Có thể đó là công ty hoặc môi trường mà tôi hiện đang làm việc. Nhưng thực tế nó hỗ trợ 90% và phát triển 10%. Đã vài năm rồi tôi mất đi sự phát triển. Tôi rất tiếc rằng tôi đã chấp nhận đề nghị này.

Nhưng tôi cảm thấy như mình đã mất đi sự kìm kẹp của tiền mã hóa hơn rất nhiều công nghệ và khuôn khổ mới. Bây giờ tôi không biết bắt đầu lại từ đâu. Tôi tiếp tục chuẩn bị nhưng những ví dụ hellowworld này không đủ để có một số kinh nghiệm thực tế tốt và thực sự rất khó để cập nhật kiến ​​thức và kinh nghiệm của tôi. Tôi thậm chí không thể rời bỏ công việc của mình để bắt đầu lại vì những cam kết gia đình.

Thật không may, tôi đang rơi vào bế tắc.

Vui lòng không chấp nhận vai trò nếu bạn không thích hoặc không quan tâm.

Nhược điểm - giả sử bạn phải giao dịch trực tiếp với khách hàng.

1) Làm hỏng khách hàng của bạn

Nếu đó là hỗ trợ dòng đầu tiên / 2/3 (tôi thực sự có nghĩa là hỗ trợ dòng mờ) trong đó các nhà phát triển giao dịch trực tiếp với khách hàng, thì đó là một lừa đảo lớn. Các nhà phát triển có bộ kỹ năng cần thiết để gỡ lỗi hoặc phát triển các giải pháp để giải quyết vấn đề. Nếu khách hàng có quyền truy cập hoàn toàn vào nhà phát triển (dòng mờ) - sẽ không có khách hàng nào ngăn cản "lạm dụng" đặc quyền này - dẫn đến những khách hàng hư hỏng, đòi hỏi và đặc quyền không trả nhiều hơn bất kỳ khách hàng nào khác.

2) Điều hòa các nhà phát triển của bạn để nói dối và tạo nên những câu chuyện.

Bất cứ ai đã giao dịch với khách hàng đều biết rằng đó là điều kiện tiên quyết để có thể nói dối họ. Có một lỗi với sửa lỗi 1 dòng có thể được thực hiện trong 5 phút. Một người hỗ trợ khách hàng sẽ được đào tạo để quản lý kỳ vọng của khách hàng - rằng sẽ mất đến 3 ngày để giải quyết.

Là một nhà phát triển, nếu bạn phải giao dịch trực tiếp với khách hàng, bạn phải nghĩ ra những cách sáng tạo để xoa dịu hoặc lừa dối khách hàng khi công việc chính của bạn là giải quyết các vấn đề kỹ thuật và đảm bảo hệ thống hoạt động trơn tru.

3) Sơ yếu lý lịch của bạn.

Trừ khi bạn thực hiện chuyển đổi từ Kỹ sư phần mềm sang Chuyên viên phân tích kinh doanh / Tư vấn CNTT / Quản lý dự án, CV của bạn sẽ bị ảnh hưởng từ khía cạnh kỹ thuật.

Công việc hỗ trợ được trả tiền mà xoay vòng trong nhóm là một câu chuyện khác nhau.

Ưu

1) Ngừng rên rỉ từ rên rỉ

Các nhà phát triển làm những gì họ ghét sẽ khiến họ đánh giá cao việc mã hóa hơn rất nhiều. Có một lập trình viên liên tục huýt sáo? Đặt chúng trên đường dây nóng trong một tháng.

Có nguyên nhân họ làm. Tôi lol khi tôi đọc câu hỏi này? Tôi giống như đây là một câu hỏi (không phải là tôi đang hỏi bạn có quyền hỏi câu hỏi OP) không, nhưng nó khá khoa trương bởi vì hầu hết mọi Dev tôi từng gặp đều có một loại công việc hỗ trợ kỹ thuật tiềm ẩn trong hoặc chức năng công việc của cô. Bạn chỉ đơn giản là không thể tránh nó. Trong hầu hết các trường hợp, người có khả năng kỹ thuật cao nhất của bạn không chỉ trong lĩnh vực chức năng của bạn, mà còn về mặt CNTT nói chung. Rất khó để tránh hoàn toàn.