¿Cuáles son los impactos profesionales de elegir entre soporte de software (soporte de producción), desarrollo y pruebas? ¿Cuál tiene un futuro mejor?

He pasado por estos tres trabajos.

Me gradué en 2002, de una de las 10 mejores escuelas en China con maestría CS. Me uní a Microsoft en Shanghai como ingeniero de soporte . No había elección. Microsoft en ese momento era como Google y Facebook de hoy. Pero Microsoft no tuvo un desarrollo completo de productos en China hasta finales de 2003. El soporte técnico de los productos es el único trabajo técnico que tienen. Durante mis dos años como ingeniero de soporte, había sido brevemente desarrollador durante medio año en un proyecto formal de producto comercial. Así que tuve una sensación de primera mano sobre el trabajo de un desarrollador: codificar características, corregir errores, descubrir por qué algunas API son lentas en algún momento, discutir con los PM sobre si es un error o por diseño, dar estimaciones y responder “¿por qué toma 5 días? ¿No debería ese trabajo solo necesitar unas pocas horas? “, Cambiar el código para cambiar los requisitos, cambiar la interfaz de usuario y un montón de cosas debajo solo porque un gran jefe dijo algo en una revisión y se le pidió que actualizara mis especificaciones de diseño porque no t refleja cómo es el último código, …

Dejé el trabajo de ingeniero de soporte en aproximadamente 2 años. En 2004, me uní al grupo de desarrollo de productos de Microsoft en Beijing, también conocido como MS ATC o Microsoft Advanced Technology Center, como probador . El título formal fue SDET o ingeniero de desarrollo de software en prueba. En la terminología actual, el trabajo consistía más en herramientas e ingeniería de calidad.

Dos preguntas para ser respondidas aquí:

  1. Por qué dejé el trabajo de ingeniero de soporte.
  2. ¿Por qué me convertí en un probador, en lugar de dev.

Dejé el trabajo de ingeniero de soporte porque descubrí que el ingeniero de soporte tiene oportunidades de carrera muy limitadas . En algún momento a principios de 2004, estaba tratando de encontrar un trabajo en Hong Kong por razones personales. La mayoría de las ofertas de trabajo de TI en Hong Kong fue trabajo de desarrollador. Envié más de 50 solicitudes. No hubo respuesta. Pensé que debía hacerlo porque mi única experiencia profesional era ingeniero de soporte. Aunque en ese momento los ingenieros de soporte en Shanghai sintieron que técnicamente éramos muy fuertes, no parecía verse de la misma manera desde afuera. Es natural y razonable que en cualquier empresa, el grupo de desarrollo de productos sea siempre más importante que el grupo de atención al cliente. Si no tienes producto, no tienes nada que vender. La atención al cliente solo entra en escena cuando el cliente ha sido adquirido.

Me hice tester solo porque no me fue bien en la entrevista. En ese momento, es común que la gente diga “a este candidato no le fue bien en la codificación, pero parece bueno en la resolución de problemas y la comunicación, ¿lo consideramos un SDET?” Aunque tal razonamiento casi ha desaparecido hoy en día. Probablemente no me fue bien en la entrevista de codificación, probablemente porque no había mucha codificación que hacer en el trabajo diario como ingeniero de soporte. Principalmente solo escribimos código de muestra para los clientes o armamos un prototipo rápido. Mi habilidad de codificación se oxidó muy rápidamente en los dos años en el rol de ingeniero de soporte.

Además, debería mencionar que me uní a MS ATC Beijing en 2004 como “contratista a tiempo completo”, que no era “empleado a tiempo completo”, ni un contratista normal que trabaja para otra compañía como Wipro o Mindtree y trabaja con Microsoft. De todos modos, el punto es que sufrí una pérdida bastante significativa al cambiar de ingeniero de soporte al grupo de desarrollo de productos. Por cierto, lo hice bien y me convertí en empleado a tiempo completo en menos de un año.

En 2005, me mudé a Shanghai, uniéndome a otro grupo de desarrollo de productos en Microsoft. Me uní a ese grupo todavía como un SDET. Tuve elección y elegí permanecer como SDET.

Aquí están las razones:

  1. Es un área menos concurrida . En otras palabras, menos competencia . Muchos buenos desarrolladores no quieren ser una SDET. Por otro lado, las herramientas y la ingeniería de calidad necesitan fuertes habilidades de programación. Al final del día, las pruebas de software consisten en resolver problemas, a veces problemas muy difíciles, y escribir código para resolverlos. No es tan extremo, sino algo así como “un pez grande en un estanque grande” frente a “un pez grande en un estanque pequeño”. Fuertes habilidades técnicas en el mundo SDET obtendrán una mejor ventaja.
  2. SDET no tiene algunos de los dolores en el trabajo de un desarrollador. Tuve una experiencia de primera mano de estos dolores durante el breve trabajo de desarrollo de medio año cuando estaba en el grupo de apoyo. Como SDET (y luego líder de pruebas y gerente de pruebas), la mayoría de las veces soy mi propio PM. Tengo grandes autónomos . Debo decirme qué función (de las herramientas) debo hacer, por supuesto, tomo las aportaciones de quienes usarán las herramientas. Cuando construyo herramientas, tengo la libertad de elegir tecnologías y eso me da la oportunidad de jugar con cosas nuevas y aun así cumplir con mi compromiso. La mayoría de los desarrolladores no tienen esa flexibilidad , de manera simplificada: si su producto está escrito en Java, debe seguir escribiéndolo en Java en los años siguientes. Nada detiene a un SDE con mente curiosa para probar otras tecnologías en el tiempo libre, pero usarlas en proyectos en el trabajo suele ser una mejor manera de esforzarse.

Pasaron diez años y creo que esa elección fue buena. Obtuve lo que quería al hacer esa elección:

  • Tenía mucha autonomía y obtuve flexibilidad para aprender cosas nuevas para el trabajo. Por ejemplo, recientemente, jugué con neo4j para ayudar a articular cierta lógica de negocios en la herramienta que estoy construyendo; Jugué con varios sistemas de registro (ver https://medium.com/@ericzheng/ch…).
  • En parte porque es un área menos concurrida, en parte por suerte, en parte porque trabajé duro y trabajé de manera inteligente, me ascendieron muy rápido en la disciplina SDET. También me convertí en gerente de segunda línea de un equipo de ~ 30 personas. Si estuviera en la disciplina SDE, mi oportunidad de obtener el mismo avance profesional será igual en el mejor de los casos, o algo menor debido a una competencia más intensa. No me da vergüenza hablar de eso y no deberíamos hacerlo: dado que todo lo demás es igual (aunque obviamente no en realidad), si la misma cantidad de dinero puede comprar una casa más grande en Texas que en California, ¿por qué elegir California?

Para resumir [1]:

  1. El ingeniero de soporte no es un iniciador. Un ingeniero de software en cualquier empresa no tan sexy es mejor que un ingeniero de soporte en Google / Facebook / Uber / Airbnb.
  2. Tester ofrece algunas oportunidades únicas y puede ser intrigante de alguna manera. Elegir sabiamente.
  3. Dev es una opción segura.

[1] Realmente no me gusta hacer un resumen. Tiende a simplificar demasiado los asuntos integrales y a ocultar matices, contextos y sutilezas. Muchas personas tienden a ver solo el resumen y hacer comentarios o troll en la parte del resumen. Aunque creo que tener un resumen es una buena estructura de escritura.
[2] Microsoft fusionó SDE y SDET hace un año. He sido gerente de ingeniería desde entonces. Me sentí bien con el nuevo papel. Es un título nuevo para mí, pero descubrí que el trabajo me resulta familiar: descubrí que cuando era líder de pruebas y gerente de pruebas, pasé una gran parte de mi tiempo en estos años en lo que hace un gerente de ingeniería hoy.

A menudo les digo a mis juniors cien veces más. El éxito no depende de “Lo que haces” sino de “CÓMO lo haces”.

El soporte, el desarrollo y las pruebas son diferentes entre sí, no superiores / inferiores entre sí.

¿Crees que las pruebas son fáciles? Intente ejecutar 1000 casos de prueba en un día sin saber cómo usar una herramienta de automatización de prueba.

¿Crees que el soporte de producción es inferior? Intente analizar un error de producción mientras el liderazgo de la empresa está tratando de obtener un resultado y solucionarlo, mientras que cada minuto que gasta le cuesta a la empresa cientos de dólares.

Cada área tiene sus desafíos. El punto es asegurarse de ser desafiado. No cambias según lo que haces. Cambias cuando termina el desafío. Para cualquier cosa que sea nueva o más desafiante.

El soporte de productos es siempre un tipo de trabajo en el que el desarrollador se siente insatisfecho. He visto a muchos de mis amigos desarrolladores declarar que es un trabajo aburrido de solo revisar los registros. Por lo tanto, parece que se debe evitar el soporte del producto.

El desarrollo es siempre un campo mejor que cualquiera de los tres. Pero todo depende de qué empresa (gran empresa o una nueva empresa) y en qué producto estará trabajando. Por ejemplo, puede estar en una gran empresa trabajando en un producto principal O puede estar en una empresa nueva y trabajando en su producto principal, en ambos casos el crecimiento profesional es bueno. Sin embargo, se observa que las empresas de nueva creación le proporcionan un mayor crecimiento para su rendimiento.

Las pruebas son un campo de la industria de TI que se ha multiplicado en los últimos años. Las empresas se han dado cuenta de que hay muchos proyectos que se pueden ganar fácilmente para las pruebas y contratan a más y más evaluadores. Un probador trabaja en una aplicación que ya está desarrollada (como un usuario final). El valor de esta experiencia solo estará en otra compañía que tenga un producto similar.
El mayor alcance del crecimiento profesional se encuentra en las pruebas de rendimiento y automatización.

Todo lo anterior se basa en mi experiencia en la industria de TI.
Puede diferir en función del desempeño de la empresa / proyecto / individuo.

Todo lo mejor 🙂

Cualquier día el desarrollo tiene un futuro prometedor.
Cuando esté en Soporte, haga un esfuerzo adicional y obtenga una vista de 360 ​​grados del Producto. Luego, puede expresar su competencia y desear que desee pasar al desarrollo de productos a su gerente. Más allá de esto, depende de su Gerente y Organización para ayudarlo.
Esta es únicamente mi opinión personal.
Espero que esto ayude .