Nota: Pido disculpas por la extensión de esta pregunta, pero creo que es necesario explicar la situación con todos los detalles para brindar la máxima comprensión. Hay un resumen de TL; DR al final para quienes solo quieren saber los conceptos básicos de la pregunta.
Durante casi tres años (tres a partir del 27 de julio de 2014), he trabajado como desarrollador web en una pequeña agencia de desarrollo especializada en sitios web basados en PHP con sede en EE. UU. Durante ese tiempo, he visto a nuestra fuerza laboral crecer significativamente de solo dos desarrolladores (incluido yo mismo) y un propietario a cinco desarrolladores, un gerente de proyecto, un gerente de marketing y un gerente de cuenta para un total de diez personas ahora.
Debido a nuestro rápido crecimiento, veo la necesidad de que estandaricemos nuestras prácticas de desarrollo para que nuestro código sea consistente y esté bien mantenido sin importar quién lo escriba o para qué proyecto esté escrito. Con ese fin, quiero presentar una propuesta para comenzar a usar los estándares FIG (principalmente PSR-2) junto con partes de (PHP QA Toolchain) [ http://phpqatools.org/] . Otra área que quiero ver mejorada es nuestro uso de Git para administrar nuestro código fuente, lo que incluye cambiar a un mejor host con más funciones de colaboración de código y colocar todo el trabajo bajo control de versión.
Sin embargo, el problema de acudir al propietario para discutir estos cambios es que mi opinión parece no tener peso, ya que casi siempre se ignoran mis sugerencias e inquietudes. Desafortunadamente, hay un desarrollador más senior en la empresa que ha estado allí más tiempo que nadie, excluyendo al propietario (alrededor de siete años), por lo que siempre tiene el oído del propietario para todo y, por lo tanto, tiene la última palabra.
En marzo de 2013, comencé a presionar para que nuestra empresa adoptara Git como estándar para mantener nuestro código fuente: habíamos estado usando SVN aquí y allá porque eso era todo lo que sabía el propietario. Después de unos seis meses de presionar, finalmente logré que nuestro gerente de proyecto considerara la idea. Pasó otro mes antes de que siquiera considerara llevárselo al dueño. El desarrollador senior se enteró y se opuso con vehemencia a usar Git porque no lo sabía. En cambio, quería seguir usando SVN o comenzar a usar Mercurial.
Para resolver este problema, el pm nos pidió que creáramos un resumen de las razones y los beneficios de nuestro sistema elegido, así como las desventajas y las comparaciones. Ambos presentamos nuestras propuestas con bastante rapidez (dentro de 1 a 2 semanas), pero tuvimos que esperar otros dos meses antes de que tomara una decisión. Le dijo al propietario que necesitábamos cambiar a Git porque es el estándar de la industria y luego le presentó mi esquema. Debido a que la idea provino de un miembro de la gerencia (el pm), el propietario finalmente accedió.
Me alegró mucho escuchar esto, así que reuní todas las notas, investigaciones e ideas que había estado desarrollando durante los nueve meses anteriores en un plan de implementación. Sin embargo, mis esperanzas se desvanecieron cuando fui a presentar ese plan al propietario y al propietario. Sin que yo lo supiera, el propietario ya le había pedido al desarrollador más senior que elaborara su propio plan de implementación, sobre el cual tuve muy pocos comentarios. Como resultado, apenas usamos un host de repositorio que tiene muy pocas funciones y cuesta mucho más dinero que el host que elegí en mi plan. Por "apenas" me refiero a que menos del 10% de nuestros proyectos y el código que escribimos para ellos está controlado por versión. Definitivamente no es así como quería que esto sucediera: en mi opinión, debemos estar al 100% y cualquier cosa menos es una responsabilidad debido a los miles de dólares que ofrecemos para nuestros proyectos.
Desafortunadamente, el director del proyecto, que era mi mejor defensor, ya no está y el nuevo parece ser ineficaz hasta ahora para cambiar las cosas. Es probable que tenga que ir directamente al propietario si quiero que cambie algo, pero me temo que no me escuchará. Traté de discutir mis ideas con mi compañero desarrollador, pero me descartó por completo al decir que "no le importa y no quiere hablar de eso".
¿Cuál es la mejor manera de llevar mis ideas a la mesa y al menos iniciar una discusión? ¿Debería intentar hablar con el nuevo director del proyecto o tratar de hablar directamente con el propietario? Si voy directamente al dueño, ¿cómo puedo lograr que escuche y respete mis pensamientos?
Quiero comenzar a implementar algunas políticas nuevas en la agencia de desarrollo para la que trabajo, pero mis ideas no se respetan y, a menudo, se ignoran o se entregan a alguien con mayor antigüedad para una implementación a medias. ¿Cómo puedo presentar mis pensamientos de una manera lo suficientemente convincente que al menos sea entretenida y discutida?
Estaba pensando más en esta situación mientras lavaba los platos y se me ocurrió lo que creo que es la raíz del problema: el propietario tiene mucho miedo de perder al desarrollador principal, por lo que escucha todo lo que tiene que hacer. decir para mantenerlo feliz. El desarrollador sénior, sin embargo, está tan acostumbrado a hacer las cosas a su manera que cualquier cambio probablemente se vea como "para qué molestarse, funciona para mí" o tal vez incluso se perciba como una amenaza. Temo que esta actitud obstaculice nuestro crecimiento y dificulte la colaboración como equipo.
He redactado un documento que contiene mis sugerencias y la razón de ser de ellas. Voy a enviarlo por correo electrónico a nuestro nuevo gerente de proyecto, al desarrollador principal y al propietario más tarde hoy. Me imagino que probablemente sea mejor alcanzar los tres objetivos en lugar de centrarse en un solo individuo. Espero que alguien escuche lo que tengo que decir y abra la discusión.
Me temo que se está golpeando la cabeza contra la pared: el desarrollador sénior, en realidad el CTO, no escucha nada que decir y el propietario cede el 100 % al desarrollador.
Tomaste un descanso cuando el primer ministro estaba cerca y podía abogar por ti, pero desafortunadamente, habría sido un caso de la luz al final del túnel proveniente de un tren que se aproximaba. Porque el desarrollador senior, si se le hubiera dado la responsabilidad de implementar el plan, habría preparado la implementación para que fallara, y la única pregunta en debate habría sido si lo hizo deliberadamente o no.
La regla de "no atribuir a la malicia lo que fácilmente podría atribuirse a la estupidez" no tiene relevancia porque el resultado habría sido el mismo: una buena idea de cambio condenada por una mala planificación y ejecución.
Además, espero que el desarrollador sénior esté ocupado discutiendo su idea con el propietario, combinando una mala planificación y ejecución con un concepto deficiente. No espero que tu carrera se vea favorecida por tal movimiento.
No espero que haga mella en la forma en que se gestiona la ingeniería de software en la empresa, a menos que logre convencer al desarrollador senior de que su idea es su idea y a menos que lo vea como un socio en el que puede confiar para hacer el cambio sucede, y usted recibe poco o ningún crédito por ello. Y esa es fácilmente la parte más importante: que obtienes poco o ningún crédito por lo que sea que hagas.
Espero que te paguen bien por presentarte a trabajar todas las mañanas y que, por lo demás, te traten bien.
Ha hecho casi todo bien en su trabajo para implementar cambios en este asunto. Se te ocurrió una idea; usted construyó un caso de negocios para ello; obtuvo la aceptación de un miembro del equipo de gestión; Esperaste pacientemente a que se aprobara la idea.
Y ahora está descubriendo lo difícil que es hacer un buen trabajo para implementar el cambio. Rara vez la racionalidad es la fuerza impulsora. En cambio, los egos y las relaciones son las fuerzas impulsoras. Esta es la realidad en proyectos de $ 500 y proyectos de $ 500 mil millones ambos. (Mire el proyecto de armas estadounidense llamado F-35, por ejemplo). Los sistemas humanos, como las empresas, se resisten al cambio; se unen para evitar el cambio. Y ahora has tenido experiencia de primera mano de cómo funcionan estos anticuerpos de la empresa: se aferran a las buenas ideas y las debilitan. A menudo, cuanto más presionas por el cambio, más poderosos e irracionales se vuelven los anticuerpos de la empresa.
Su intento profesional de implementar el cambio es una experiencia de desarrollo de carrera increíblemente valiosa, incluso si el cambio no sucedió de manera efectiva.
En este punto, debe decidir si vale la pena seguir intentando implementar este cambio en esta empresa. Posibles opciones:
En cualquier caso, tenga paciencia. Esté preparado para que el desarrollador de larga duración diga: "Oye, tengo una idea, ¿por qué no usamos un buen servidor Github y ponemos todo lo que hacemos en él?" Cuando diga eso, no digas la verdad ("¡esa fue mi idea!"). Di, "¡buena idea!"
Definir las nuevas políticas obviamente no es su responsabilidad.
Estuvo bien que tuvieras la iniciativa de proponerlos, pero no te tomes como un insulto personal que no se sigan. En ese aspecto, una afirmación como "Si voy directamente al dueño, ¿cómo puedo hacer que escuche y respete mis pensamientos?" podría entenderse como que solo te sientes respetado si siguen tus ideas. Eso sería una muy mala actitud.
Entonces, antes que nada, respira hondo y relájate. Si después de todo, todavía cree que sus ideas tienen mérito, vaya a ese desarrollador senior (que es la persona que puede cambiar la opinión de su jefe) y hable con él. Dado que tiene una formación técnica, puede discutir sus diferentes opiniones en un plano estrictamente técnico e intentar convencerlo de los méritos de su idea (y, por el contrario, es posible que él pueda convencerlo de los méritos de sus ideas).
Si no estás de acuerdo y él no cambia de opinión entonces, bueno, hiciste todo lo que estaba en tu mano.
Si lo convence y se dirige a su jefe diciendo "hola jefe, MagentoDev tiene algunas buenas ideas que deberíamos implementar", entonces es algo bueno.
Si lo convence y se dirige a su jefe y le dice: "Hola, jefe, tengo algunas ideas geniales que deberíamos implementar", entonces también es algo bueno (porque sus ideas se implementarán y eso es todo lo que quiere, ¿Correcto?)
I tried to discuss my ideas with my fellow developer, but he completely brushed me off by saying that he "does not care and does not want to talk about it."
teego1967
aroth
aroth
cristobal barbero
MagentoDev
MagentoDev