Me uní a la compañía en la que estoy trabajando actualmente. Debido al número limitado de personas capacitadas en el desarrollo de software SIG, y como estaba entre uno de ellos, me contrataron directamente como Gerente de Proyecto.
Estaba bastante familiarizado con Java y SIG, y he realizado investigaciones auto motivadas sobre servicios basados en la ubicación, pero no con la gestión de proyectos y el desarrollo de software estructurado. Fue un año después de mi graduación como especial de Geología y durante el año anterior estuve trabajando como académico en una universidad.
Gracias al interés que tenía en el trabajo, apareció una oportunidad y, finalmente, también fui responsable del departamento de Business Intelligence de la empresa. La compañía creía en mí. Yo mismo estudié el almacenamiento de datos y los conceptos de BI y también logré combinar GIS con BI.
Además, actualmente estoy trabajando con dos desarrolladores en nuestra herramienta de BI en C # WPF, donde también a veces desempeño el papel de desarrollador (lo que me gusta).
Traté extremadamente duro de adoptar buenas metodologías de desarrollo de software con gestión ágil de proyectos, pero no fue muy exitoso. Además, aunque creo en un código bien diseñado en lo que respecta a un producto, debido a la falta de conocimiento técnico que tiene mi CEO (que está directamente por encima de mí), normalmente no obtengo la cantidad de tiempo necesario para hacerlo. El tiempo que toma se ve enormemente mejorado por la falta de experiencia que tenemos en el lenguaje de codificación específico en su conjunto también (por ejemplo, WPF en oposición a Java). Tampoco hay un sistema de control de versiones en su lugar.
Estoy extremadamente harto de cómo van las cosas, ya que no está estructurado y encuentro la mayor parte de mi tiempo pensando que trabajando en cómo estructurar las cosas. Espero que ustedes, con buena experiencia profesional, puedan ayudarme a superar esta situación.
Respuestas:
Tuvimos un problema similar (sin los detalles técnicos, por supuesto) en la empresa donde trabajo hace aproximadamente dos años.
Solo necesita hacerlo paso a paso. No intente adoptar el desarrollo de software ágil de inmediato. Hay muchas cosas que aprender y aplicar. No permita que la falta de experiencia lo deprima tampoco.
Construya lentamente (pero tan rápido como pueda: P), de manera constante y segura.
Recomendaría los siguientes pasos (para hacer esto, puede cambiar de administración al desarrollo por un tiempo, pero eso debería estar bien)
Además, si es posible, contrate a un consultor para que pueda verificar el proceso y dar mejores consejos.
No te vuelvas perezoso o desanimado. Simplemente aprenda de sus errores y pruebe diferentes enfoques. ¡Este es solo el comienzo!
Editar:
Estos son algunos de los enlaces y libros que he estado leyendo / usando últimamente ...
Aprendizaje git: Pro Git
Estos son algunos de los blogs que recomendaría (la mayoría de ellos están orientados a .NET):
Para libros, puede ver la lista Buiding A Solid Programming Core en amazon. También recomendaría estos:
fuente
Como gerente, es su trabajo obtener el tiempo requerido para completar un proyecto correctamente. Cuando se acerque al CEO, asegúrese de tener todas las cifras que lo respalden y las razones por las cuales las estimaciones son tan largas como lo son. Es su responsabilidad como gerente hacer que el CEO comprenda por qué lleva n horas / días / semanas completar una tarea determinada. Esto a veces puede ser difícil, pero no he conocido a un CEO que quiera que su compañía fracase todavía y apuesto a que si lo expresa en ese tipo de términos (si todo lo demás falla), puede cambiar su tono.
Si el CEO no está dispuesto a otorgarle el tiempo necesario para completar las tareas, en mi humilde opinión, esté listo para pasar a otro trabajo o prepararse para marchas de muerte continua. Como último recurso, explique al CEO el agotamiento que sin duda vendrá de expectativas poco realistas.
Una vez dicho esto, usted también necesita asegurarse de que sus desarrolladores se le proporciona estimaciones precisas (tremendamente difícil, casi imposible sin adecuados diseños técnicos realizados, que también debe estar en alguna parte).
Ágil no es bueno en todos los dominios de desarrollo. Funciona para algunos tipos de proyectos, falla miserablemente en otros. Es posible que deba probar algunas metodologías diferentes antes de encontrar una que funcione bien .
Obtenga la configuración del control de versiones . Realmente, lleva 5-10 minutos configurar Git, unos minutos más para obtener las operaciones básicas y uno o dos días de lectura para obtener los conceptos más avanzados.
fuente
Hmm, no estoy seguro si te conocí en un evento Agile / XP en Toronto - esto suena familiar
Parece que necesitas un descanso. Tómate un fin de semana largo, emborrachate si quieres y olvídate del trabajo por unos días.
Tranquilízate contigo mismo. La autoaprendizaje es buena, y solo porque una metodología no funcione con las personalidades involucradas, no significa que lo esté haciendo mal, y no es un fracaso personal.
Hay un sitio (beta) pm.stackexchange.com, dirigido a Project Management, es muy posible que obtenga algunos consejos útiles / soporte allí, pero por supuesto, mantenga la pregunta aquí también.
Pasando a las cosas tecnológicas:
Ponga uno como su máxima prioridad. Prefiero sistemas centralizados como SVN (Subversion) sobre git / mercurial, porque una computadora portátil robada no tendrá tanta historia localmente. Especialmente importante si algo súper secreto (como contraseñas y ssh-keys) se registró por error. Pero, es cuestión de gustos. Nada desperdicia más tiempo que los errores del 'control de versión manual', por ejemplo, devolver el código a lo que cree que era.
Buena suerte
fuente
Parece que tiene varios problemas: 1. Comunicarse con la alta gerencia no técnica para que apoyen su programa de mejora; y 2. Impulsar el programa de mejora para el éxito.
La parte más difícil del número 1 es simplemente recordar que la alta gerencia a menudo no estará interesada en los detalles de lo que está trabajando. (¡Si lo fueran, lo harían ellos mismos en lugar de entregárselo!) Parece que el gran obstáculo es 'por qué' y es posible que desee ver CMM 1.1 para obtener una descripción de los beneficios comerciales de una mejora de procesos programa. Ya sea que use CMM o alguna otra cosa para mejorar realmente su proceso, no será importante para esta discusión, solo los datos del estudio Carnegie-Mellon, que muestra que organizaciones más maduras entregan proyectos más rápido con menos variación en el tiempo de entrega.
Hay muchos caminos hacia el éxito en la mejora de procesos, todos tienden a ser muy largos. La experiencia con CMM muestra que puede llevar de 8 a 10 años pasar del nivel 1 al 5. La experiencia con 6 sigma muestra que cada iteración proporciona alguna mejora, pero necesita múltiples iteraciones para eliminar la mayoría de los problemas potenciales y, para cuando llegue el momento Con 6 sigmas de calidad, el trabajo se realiza de manera completamente diferente sin tener que correr el riesgo de intentar reemplazar todo a la vez.
Si hay un enfoque de mejora de la calidad comúnmente utilizado en su industria, tómese el tiempo para intentar ver cómo se aplica al software y úselo para que el resto de la compañía escuche sobre algo con lo que ya están familiarizados y que apoyan. Podemos hablar durante horas sobre herramientas y prácticas de software específicas, pero los CEOs que no son de software lo ignorarán rápidamente. Hable acerca de las prácticas estándar de la industria y él se animará porque está hablando su idioma. Hable sobre el software en los términos comunes de la industria y él comenzará a hacer preguntas relevantes para comprender mejor sus desafíos y sus planes para mejorar los resultados de las empresas.
No ganará todas las solicitudes de soporte de esta manera, ¡probablemente obtendrá muchas menos miradas en blanco y más victorias!
Buena suerte señor!
fuente
Todas sus sugerencias son realmente sensatas y son el camino a seguir en muchas empresas. Pero no son universales, especialmente con equipos que no tienen tanta experiencia. La razón por la que no lo son es que requieren cierta cantidad de trabajo para configurar y mantener, incluso el control de versiones, lo que muchos supondrían que es una apuesta de mesa para cualquier proyecto de software. Debido a que requieren algo de trabajo, también deben proporcionar algún beneficio. ¡Y podría ser el caso de que en su situación particular no lo hagan! ¡O al menos las personas encargadas de tomar las decisiones no ven el beneficio!
Como otros han señalado, necesita:
fuente