5 temores de desarrolladores que hemos superado

Halloween es el momento de hablar sobre los miedos. Trabajo como gerente de producto en una empresa de TI, por lo que se tratará de las pesadillas de los desarrolladores. Pero no ordinario, sino aquellos que aparecen en tiempos de cambio.



Cuando una empresa se desarrolla, cambia su enfoque de desarrollo, crea nuevos productos y amplía las capacidades de los actuales, acepta a los empleados por docenas, y aquellos que trabajaron a la antigua usanza pueden tener dificultades para reconstruir. Nos alegramos de los cambios, pero a veces, por qué esconderse, les tenemos miedo. He estado trabajando como gerente de producto durante un año y durante este tiempo me he enfrentado a cinco grandes temores de mi equipo. Hoy hablaré sobre estos miedos y cómo logramos superarlos.

1. Miedo a dejarlo todo

La prueba es una forma segura de lanzar un producto sin errores. Pero a veces no hay equipo para verificar el código.

Creamos DCImanager , un panel para administrar servidores y centros de datos, y a menudo es imposible crear condiciones en las que el código funcionará en un entorno virtual. Por ejemplo, agregamos soporte para el nuevo interruptor, enrutador o modelo de PDU al panel de control, pero no existe tal equipo en el banco de pruebas.

En algunos casos, las pruebas pueden ser descuidadas, pero no las nuestras. El error es costoso. No inicializa solo una variable, y en la mitad de los casos el sistema operativo dejará de instalarse. Está equivocado en un par de líneas de código, y el centro de datos se "acostará". Como saben, nadie quiere ser responsable del centro de datos "caído", por lo que este temor es lo primero en mi equipo (aunque no está relacionado con las transformaciones en la empresa).

Cómo superar el miedo a dejarlo todo

1. Todos los desarrolladores del equipo realizan una revisión del código de cada característica.
2. Mantenemos listas de cosas sin las cuales no se puede liberar la tarea.
3. Después del lanzamiento de desarrollo, analizamos que no lo tomamos en cuenta. Describimos en detalle lo que se ha hecho y qué comportamiento se ha observado, para que en cualquier momento pueda volver a la tarea y restaurar todo en la memoria.
4. Actualización constante de la base de conocimiento. Dedicamos tiempo a la documentación para desarrolladores, compartimos conocimiento entre nosotros sobre eso. entrenamiento y stand-ups.
5. Y por último pero no menos importante. Probamos desarrollos personalizados para clientes con ellos en el equipo provisto.

Una vez que agregamos el control de agregación de puertos para los conmutadores existentes. Si se cometiera un error, la operación del equipo de red en el centro de datos se detendría por completo. El cliente llegó a su centro de datos a las tres de la mañana y controló la situación, por lo que en ese caso volvería rápidamente a la versión anterior y reanudaría la operación del equipo. Podríamos perder el acceso remoto y el centro de datos quedaría paralizado.

2. Miedo a quedarse sin un probador

Nuestros desarrolladores escriben pruebas unitarias, y personas individuales se dedican a pruebas manuales. Pero una vez que hubo una fuerza mayor, y el equipo se quedó sin un probador manual. No pudimos lanzar funciones, por lo que los desarrolladores tuvieron que comprobarse entre sí.

Fue un golpe al orgullo. Dio la casualidad de que todos los programadores de mi equipo abandonaron los probadores (manual y automático). Vuelva a las pruebas manuales para ellos, dé un paso atrás. Los chicos tenían miedo de que si podían hacer frente por su cuenta, los probadores no serían devueltos a ellos. Pero el miedo resultó ser infundado, después de un par de carreras, el probador tomó su lugar en el equipo, y de la experiencia aprendimos muchas cosas útiles.

¿Cuál es el beneficio de las pruebas cruzadas?

1. Recordaron "juventud" y volvieron a mirar el desarrollo desde el lado del probador. En algunos casos, se agregaron acciones adicionales para facilitar la vida del probador. Por ejemplo, generar estadísticas para la verificación.
2. Confirmaron el hecho conocido de que el desarrollador no puede probar su código, ya que hace la vista gorda ante algunas cosas. Por lo tanto, los chicos probaron el código del otro.
3. Una vez más, estábamos convencidos de que los evaluadores son una parte importante del equipo. Son responsables de la calidad de las características que saldrán en el lanzamiento.

3. Miedo a entrar en otro equipo.

DCImanager fue lanzado en 2013. Durante seis años, la tecnología ha cambiado, es hora de hacer una nueva versión, decidimos hacerlo desde cero. Dibujamos prototipos, determinamos MVP y priorizamos. El desarrollo de la versión anterior se congeló, pero no pudieron iniciar la nueva: ya se estaban preparando dos nuevos productos para el lanzamiento, todas las fuerzas se dedicaron a ellos, tuvimos que esperar un poco. Durante la pausa, mis desarrolladores se convertirían en el equipo de proyecto de BILLmanager , nuestro otro producto para la automatización del alojamiento.

Y entonces apareció otro miedo. Los desarrolladores de ingeniería en todos los sentidos de la palabra producto tenían miedo de asumir la facturación. Les parecía que esta no era su área, que no era interesante entender un montón de cuentas. Me preocupaba que desmotivara a mis desarrolladores. A diferencia de nosotros, el equipo de facturación se regocijó con la descarga.

Durante algunos sprints, fuimos a trabajar en BILLmanager, y esta experiencia también fue útil.

Brevemente sobre cómo se llevó a cabo la implementación

1. Para minimizar el estrés de cambiar a otro producto, el equipo siguió siendo un equipo y no dependió de los muchachos de BILLmanager.
2. Las tareas se eligieron de acuerdo con el principio "debes hacerlo ayer, pero no tienes suficientes manos". Los productólogos discutieron las tareas y luego, al planificar el próximo sprint, las traduje al equipo.
3. Los desarrolladores de BILLmanager fueron nuestros mentores. El recepcionista respondió todas las preguntas, y el líder del equipo dijo qué y cómo debería funcionar
4. Tuvimos dos standups. Al principio fuimos a la facturación, luego discutimos los resultados dentro de nuestro equipo.

¿Qué beneficios aportaron los desarrolladores de la introducción a otro equipo?

1. Otro producto es el código de otra persona que necesita comprender; más otra lógica de trabajo para entender. Gracias a la tutoría del líder del equipo y la paciencia del gerente final, nos acostumbramos con éxito a la facturación, impulsamos nuevas habilidades y vimos las mejoras con bastante rapidez.
2. Por supuesto, espiamos cómo funcionan algunas cosas dentro de otro equipo. Puede parecer que todo es igual para todos, pero no importa cómo. Las diferencias radican en los detalles. Como regla general, tomaron lo mejor y lo más conveniente para ellos (por ejemplo, espiaron y, después de haber cambiado ligeramente, comenzaron a usar un tablero de scrum, adoptaron algunos puntos en el estilo de código, etc.).

4. Miedo de convertirse en un mentor / quedarse sin un líder de equipo

La compañía necesita tantos programadores fuertes como sea posible, por lo que cuando un desarrollador bombea habilidades difíciles y pasa al nivel medio, la formación de principiantes se convierte en su responsabilidad. Pero la tutoría general generalmente recae en el líder del equipo. Así fue en nuestro equipo, hasta que la experiencia de un desarrollador líder se necesitaba con urgencia en otro producto. Los programadores que se quedaron sin teamlade tuvieron que tomar el entrenamiento de principiantes y entre ellos.

Ser un mentor da miedo. Debe distraerse de sus tareas, sintonizar con otra persona, explicar lo que usted mismo a veces entiende a nivel de intuición y explicar de tal manera que se entienda. Si el Padawan no entendió, este es su problema. Si cometió un error y no lo notaste, respondes.

No daré consejos sobre cómo convertirse en un buen mentor, este es un tema para un artículo separado. Pero lo logramos, y de esta experiencia bastante estresante aprendimos lo siguiente:

1. Al explicar, se necesita dar más contexto. Todo es hermoso en la cabeza, y cuando lo cuentas, resulta ser desgarrado e incomprensible.
2. No solo se debe mirar un código en una revisión, sino comprender lo que una persona intentó resolver con este código. Entonces es más fácil entender su lógica y encontrar errores.
3. Compartir el conocimiento es útil: aprender a formular pensamientos; pon todo en los estantes de tu cabeza; mientras explica, encuentra la mejor solución al problema.

5. Miedo a no aprender nuevas tecnologías.

Cuando termina la pausa, es hora de comenzar una nueva versión del producto DCImanager. Parece que este es el momento tan esperado. Ahora, con un equipo lleno de personas ambiciosas, comenzaremos todo desde cero, sin mirar los errores antiguos y las dependencias extrañas desarrolladas históricamente en el código. Pero había un lugar para el miedo.

Durante varios años, la tecnología ha avanzado mucho. Escribimos la versión anterior en C ++ 11 y usando make, para la nueva elegimos C ++ 17, CMake, Conan y Docker. El equipo necesita aprender todo esto y aprender cómo solicitarlo. La próxima salida de la zona de confort, el desafío y el pensamiento "qué pasa si no puedo y será peor que los demás", "qué pasa si hay más problemas esperándome, no lo resolveré y me echaré". Todavía estamos dominando las nuevas tecnologías, y la lucha contra este miedo todavía está en proceso.

Cómo aprender nuevas tecnologías más rápido

1. No seas tímido para preguntar a colegas mayores y con experiencia, no tengas miedo de parecer estúpido.
2. Documente para acelerar el proceso de inmersión de los recién llegados y no decir lo mismo 10 mil veces. Mantener una base de conocimiento.
3. De acuerdo, Google siempre está ahí para ayudar. Si no funciona, vea el punto 1.

No miedos, sino desafíos

Aprovecho los experimentos como una oportunidad para aprender cosas nuevas, para mejorar, y trato de que mi equipo también analice sus temores. Creo que el humor de los muchachos depende mucho de mí. Cuando cree en un producto y en los desarrolladores, escúchelos en stand-ups y analice problemas en retrospectiva, ayúdelos en problemas y explique la necesidad de un cambio, entonces es más fácil para ellos superar los temores.

Pero seamos honestos, en stock todavía tenemos un par de fobias invictas. Miedo a los plazos, por ejemplo, o miedo a no llevarse bien con los principiantes. Hasta ahora, parece que no se puede hacer nada al respecto, solo aguanta. Pero tal vez con el tiempo nuestra opinión cambie.

¿Por qué tienes miedo?

PD: si desea ser el primero en ver la versión demo de DCImanager, envíe sus contactos a bizdev@ispsystem.com con el asunto "Quiero ver el nuevo DCImanager". Cuando esté listo, le escribiremos. O si necesita un producto para la gestión del servidor, pero el DCImanager actual por alguna razón no encaja y no hay una solución adecuada en el mercado, escriba sus deseos para dicho software, tal vez incluiremos algo en el plan de desarrollo.