¿Debo decirle a mi equipo/gerente que la aplicación móvil actual es mala?

Creo que decir algo es una buena idea, pero cómo lo dices va a ser tan importante como lo que dices.

Como escribiste en tu pregunta, no quieres criticar a tu equipo (lo cual es excelente) y estoy seguro de que no entrarás y solo dirás "la aplicación apesta, mira mi versión que es increíble y la eliminé". en un par de semanas", pero realmente quiere evitar adoptar cualquier enfoque que pueda interpretarse como diciendo eso.

Debe tener en cuenta que hay un par de grandes factores y desafíos potenciales que podrían haber contribuido a que la aplicación existente tardara tanto tiempo en desarrollarse y funcionar y verse como lo hace, muchos de los cuales no habrá enfrentado. en tu reescritura:

1. Experiencia: parece que tiene experiencia previa con el desarrollo de aplicaciones móviles y parece que ese no fue el caso de los desarrolladores que escribieron la existente. He escrito una buena cantidad de código no excelente a lo largo de los años y sé que si volviera y lo volviera a hacer ahora, lo dejaría fuera del parque.

2. Partes interesadas: no tenía ninguna, trabajaba en un vacío y solo se respondía a sí mismo, mientras que los desarrolladores originales probablemente trabajaron según los requisitos y las preferencias de las personas que impulsaban el proyecto. ¿Esa horrible interfaz de usuario que odias? Probablemente sea horrible, pero las partes interesadas y el propietario del producto podrían haber insistido fácilmente en su horror (debería ver algunas de las abominaciones absolutas que he tenido que producir a lo largo de los años porque al director de operaciones o al director le gustó de esa manera). Lo mismo ocurre con los requisitos funcionales: conocía un conjunto completo de funciones desde el principio, ya que tenía una aplicación completa existente para trabajar. Lo más probable es que el proceso de desarrollo original haya consistido tanto en descubrir qué querían que hiciera como en hacer que lo hiciera.

Básicamente, debe darles un poco de holgura y darles el beneficio de la duda de que estaban haciendo lo mejor que podían en circunstancias más difíciles que las que enfrentó y tener eso en cuenta durante la conversación.

Entonces, ¿cómo lo abordas?

En una palabra, humildemente , organizaría una reunión 1-1 con su gerente y le explicaría que después de ver la aplicación existente durante el trabajo reciente, sintió que sería un ejercicio útil recrearla en su propio tiempo ( asegúrese de enfatizar esta parte (no quiere que se vea que descuida su trabajo asignado) como una forma de mejorar sus propias habilidades de desarrollo de aplicaciones móviles y que le gustaría que su gerente eche un vistazo para ver qué piensa. y obtener algunos comentarios. Si su versión es una mejora tan grande como dice (y no tengo motivos para dudar de usted), entonces esto hablará por sí mismo cuando lo usen y vean el código. Si comentan sobre las diferencias de la interfaz de usuario, diga que así es comolo habría hecho si tuviera rienda suelta y que comprenda que no necesariamente va a estar alineado con la forma en que la empresa podría querer que se vea y se sienta su aplicación. Si comentan sobre la diferencia del código, diga que estaba trabajando de la manera en que le enseñaron, pero que está abierto a cualquier sugerencia sobre cómo podría ser mejor.

Tenga en cuenta que no estoy sugiriendo que su versión sea peor que la existente: presenta un caso bastante bueno de que la suya es mejor y no tengo motivos para dudar de usted. Esta humildad es esencialmente una forma de evitar parecer arrogante, lo cual no es una buena apariencia, especialmente cuando aún no tienes un historial en la empresa que lo respalde.

No los llames, que es lo que estarías haciendo. Haz preguntas en su lugar.

"¿Por qué la interfaz de usuario es así? ¿No sería más estándar hacer ____?"

"Apuesto a que podríamos obtener un código mucho más estable si hiciéramos _____"

Sin embargo, el hecho triste es que tienes 23 años. 4 o 5 años pueden parecerte mucho, pero en realidad no lo es cuando consideras que algunos de nosotros lo hemos estado haciendo durante más de 30. Como solo tienes 23 años, tus ideas tienen más probabilidades de ser despedidos. Es por eso que estoy sugiriendo el enfoque de sugerencia humilde. Formule las preguntas de una manera que los obligue a explicarlo sin desafiar realmente o ser confrontativo.

¿Debo mencionar que la aplicación carece de diseño de interfaz de usuario y calidad de código? Si es así, ¿a quién?

Creo que debería abordar esto con su gerente. Fuiste contratado como Desarrollador Móvil, por lo que parte de tus responsabilidades es cuidar, mejorar y advertir sobre cualquier proyecto móvil que tengas.

Puede pensar que esto se reflejará mal en el equipo, pero los inconvenientes de no mencionar esto antes serán peores a largo plazo. Solo asegúrese de tener alternativas y soluciones listas cuando diga qué cosas podrían mejorarse (lo que parece que ya tiene).

es por eso que decidí recrear la aplicación en mi tiempo privado desde cero; esto me tomó 2/3 semanas y estaba listo.

Esto puede ser útil para usted aquí, para que pueda tomar el crédito que merece por su trabajo mientras ayuda a construir una aplicación mejor en conjunto. A pesar de que lo que dice es completamente cierto, es probable que durante 2,5 años haya algunos aspectos complejos que se haya perdido, así que esté abierto a correcciones y cambios también .

Debo decir que este fue un movimiento loco y audaz de su parte, pero si realmente lo hizo bien, seguramente puede resolverlo a su favor. Le sugiero que se reúna con su gerente en persona , donde puede presentar sus inquietudes sobre la versión actual de la aplicación y la solución y las prácticas que propone.

Para ello le sugiero que exprese cuidadosamente sus sugerencias . En lugar de decir "Creo que usar X es malo, y deberíamos usar Y" , intente expresarlo como: "Veo que hacemos X en esta parte del código, ¿podría explicar los beneficios de hacerlo?" ... de esta manera no estás señalando con el dedo, estás manteniendo una actitud de aprendizaje , además de permitirte hacer tus sugerencias de manera efectiva a pesar de tu condición de "Junior".

Luego puede mencionar que ha estado trabajando en un proyecto durante su tiempo libre como prueba de concepto y proceder a mostrar su aplicación. Si lo que describe es cierto, su gerente seguramente quedará impresionado y probablemente tomará en consideración los cambios que propone.

Lo bueno es que los "inconvenientes" se minimizan aquí, ya que se tomó el tiempo de investigar y codificar esas alternativas. Solo asegúrese de asegurarse de que lo hagan en su propio tiempo (por lo tanto, no "perder" el tiempo de la empresa). Espero que puedas arreglar esto a tu favor.

Es un enigma.

Siendo justos, es posible que no haya captado por completo todos los aspectos importantes del código o los más pequeños, dado el tiempo que llevó producirlo. O simplemente podrías ser mejor que el resto de tu equipo. Tomándote la palabra, has creado una posible solución al volver a hacerlo, pero también has puesto de relieve dos problemas internos graves, desarrolladores obsoletos, sin imaginación o uniformados y un gerente que no lo sabía durante dos años y medio. ..

Su enfoque aquí es fundamental para su longevidad con esta empresa.

Te recomendaría esperar lo mejor pero planear para lo peor. Revise el código en el trabajo durante las próximas dos semanas para ver las cosas que puede haber pasado por alto. mientras tanto, en tu tiempo libre, cubre tu culo. Documente todo lo que se está trabajando desde las computadoras de su hogar, capturas de pantalla, cualquier cosa, por si acaso para el peor de los casos legales. Revise su nueva y mejorada aplicación y pruebe todos los aspectos que pueda, verifique todo dos veces tres veces.

Dentro de dos semanas haz el movimiento final. Haga una cita para hablar con su gerente. Muéstreles su aplicación junto a la oferta actual. Vaya él. Deslúmbralo. Sorpréndelo con tu nuevo y genial diseño de interfaz de usuario y la estabilidad del código.

Ofrezca darle el código completo, gratis y claro. Le darás toda la gloria por todos los cambios. A cambio, aceptará amablemente la promoción a desarrollador senior con su correspondiente aumento salarial. Después de lo cual demostrará con su arduo trabajo continuo, su fe en usted. No solo eso, sino que si es necesario, con gusto firmará cualquier acuerdo a tal efecto.

jaque mate

Ve a lo grande o vete a casa. Si se lo das, existe una alta probabilidad de que lo roben y te despidan para simplemente encubrir los enormes "problemas" que potencialmente has revelado. O podrían pensar que eres demasiado arrogante y despedirte. Si lo hacen, aléjate del contenido de que a tu edad puedes codificarlos. Tu próxima oportunidad siempre estará ahí si sigues mejorando tu juego.

Es una apuesta de cualquier manera. La mejor de las suertes.

T

Te recomiendo que empieces con el final en mente: ¿cuál es el resultado que quieres ver? Al leer tu pregunta, supongo que se parece a algo como:

• Una mejor interfaz de usuario que se adhiere más estrechamente a las pautas de interfaz de usuario para las plataformas móviles involucradas
• Una base de código mejor estructurada con patrones arquitectónicos menos cruft y más reconocibles
• Reconocimiento de su impacto en llegar a estos

Independientemente de si esa es la lista completa, el verdadero desafío aquí es la gestión del cambio , es decir, cómo pasar del estado en el que usted, el equipo y la aplicación se encuentran ahora al estado en el que desea estar. tengo que:

• Identifique a las "partes interesadas clave": ¿quién se beneficiará más del futuro que está buscando? ¿Quién va a sufrir más el cambio? ¿A quién le va a importar más, independientemente de si están en esos otros dos grupos? Estas son las personas que necesita de su lado cuando sea el momento de proponer cambios y cuando sea el momento de comenzar a implementarlos.
• Comprenda mejor a sus partes interesadas y su negocio: probablemente sepa mucho sobre su espacio y el desarrollo móvil. Obtenga más información sobre su equipo, cómo llegaron a ser quienes son y dónde están, y su base de código. ¿Es el Objective C orientado a Java porque ese es el paradigma que tenían, o porque la primera persona que lo construyó fue rápido y nadie tuvo tiempo de reescribirlo? ¿Cómo es la cobertura de la prueba? ¿Puede mejorarla? Tener esta comprensión será invaluable cuando llegue el momento de hacer un plan para los cambios que desea, y el proceso de obtenerlo construirá las relaciones que necesitará para lograrlo.
• Cree un entendimiento común y un apetito compartido por el cambio: comience a hablar con esas personas, y con otras, sobre el estado futuro que espera. No tiene que ser inmediatamente relativo a su aplicación; de hecho, a menudo es mejor comenzar en áreas que están claramente desconectadas para evitar generar preocupaciones y reacciones defensivas. Por ejemplo, podría dedicar un tiempo de manera regular a deconstruir y discutir alguna otra aplicación que crea que está realmente bien hecha, particularmente en torno a los aspectos que cree que serían aplicables a su propia aplicación. No es importante terminar esas conversaciones con "... así que también deberíamos hacer eso". Están explorando juntos y juntos llegarán a valorar las cosas que son más importantes.
• Comience poco a poco, genere impulso:No proponga un plan de dos años para entregar todo el código base, ni un proyecto de "detener el mundo mientras reescribimos". En su lugar, busque una serie de cambios que pueda abordar para hacer evolucionar la aplicación hacia un futuro mejor mientras continúa con el desarrollo de funciones. Elija cosas pequeñas que tengan grandes efectos positivos y acéptelos primero, si puede; ambos lo ayudarán a probar su dirección y le darán impulso al lograr éxitos. Tal vez los puntos de partida más importantes sean algunas pequeñas refactorizaciones que facilitan la entrega de algunas funciones importantes; tal vez sea la rearquitectura de una parte de la aplicación para que tenga una mejor base para que no se rompa con tanta frecuencia (porque es más fácil probarla bien, ¿no? ;) Sea lo que sea, hágalos pequeños e incrementales para que pueda

Vas a entrar en esta situación una y otra vez en el transcurso de tu carrera. Desarrollar habilidades sólidas de gestión del cambio, las habilidades para generar cambios de manera que empoderen al equipo y a la empresa, y que desarrollen la moral y las relaciones en lugar de derribarlas, es enormemente valioso y lo llevará más lejos que casi cualquier habilidad técnica que pueda desarrollar.

¡Buena suerte!

Deuda técnica

https://www.techopedia.com/definition/27913/technical-debt

Una vez que una empresa cae en la categoría de deuda técnica, puede encontrarse en una situación difícil. Es un problema muy común y puede empeorar por la política, los procesos y las metas a corto plazo.

La deuda técnica es inevitable. La clave está en gestionarlo.

• escribir pruebas unitarias
• use herramientas de cobertura de código para monitorear los cambios de código
• usar herramientas de linting de código fuente
• rastrear la frecuencia de errores (indicador de deuda técnica)

A menos que todos comiencen a trabajar juntos para resolver los problemas técnicos de la deuda. Nada de lo que haga como programador tiene la esperanza de solucionar las causas. Podrías reescribirlo, rediseñarlo, refactorizarlo o simplemente aplastarlo con un martillo.

La deuda técnica se arrastrará rápidamente hasta el código fuente.

Iría a su gerente y tendría este tipo de conversación con él.

Hola, he estado aquí sólo un corto período de tiempo. En esa cantidad de tiempo, descubrí que agregar nuevas funciones, corregir errores y seguir sus enfoques personalizados para el diseño de la interfaz de usuario está tomando mucho más tiempo del que creo que debería. Si bien carezco de la experiencia para señalar exactamente por qué este es el caso. Me está haciendo sentir incómodo. ¿Sabías que aquí tenemos problemas de deuda técnica?

Él sabrá que está ahí o investigará el problema. La clave es iniciar una conversación amistosa al respecto y evitar cualquier acusación de causa y efecto. Básicamente sientes que está ahí, pero no sabes dónde exactamente.

Sigue sacando el tema. Eso es todo lo que puedes hacer.

La función de un desarrollador sénior debe ser garantizar que se sigan las pruebas unitarias, la cobertura del código, el desforrado del código fuente y otras prácticas analíticas. Todo lo que puede hacer es defender que los necesita.

Anime a las personas a hablar más abiertamente sobre la deuda técnica. Pregunte qué piensa cada persona que es. Trate de iniciar conversaciones al respecto.

Pero, siempre sea amigable, escuche a los demás y no desafíe lo que dicen y, con suerte, con el tiempo se unirá como un equipo para luchar contra esa deuda.