Cómo liderar un proyecto de desarrollo sin experiencia técnica

He sido un desarrollador práctico durante toda mi carrera y me encanta trabajar con código. Siempre me ha molestado el líder del equipo que tiene poca o ninguna experiencia con respecto a una tecnología en particular y, sin embargo, insiste en una determinada implementación.

Ahora me encuentro al otro lado del espejo. Soy el desarrollador principal de un cliente gordo que se implementará en C #, sin embargo, mi experiencia es en la creación de aplicaciones web Java. Si bien sé que puedo aprovechar los patrones de diseño y los paradigmas de OO en cualquier idioma, estoy perdido en lo que respecta a los estándares de codificación, las herramientas del ciclo de vida del proyecto y los procedimientos de lanzamiento / distribución. No tengo dudas de que puedo aprender lo básico dentro de un mes o dos, pero hay ciertas experiencias que solo se pueden reunir con el tiempo.

¿Qué debo hacer y cómo evito convertirme en el líder del proyecto que odiaba cuando estaba desarrollando?

Honestamente, no importa cuánta experiencia tenga con una tecnología, mi consejo es el mismo: no imponga decisiones tecnológicas sobre aquellos que tendrán que vivir con ellos mientras está ocupado administrando.

Se honesto contigo mismo. Apuesto a que la razón por la que odiaste a esos gerentes anteriores no fue porque no tenían la base de conocimiento para tomar decisiones, sino porque hicieron cumplir las decisiones y nunca lidiaron con las consecuencias.

Eso se aplica si nunca ha tocado .NET antes o si es el desarrollador más experto del equipo. Su trabajo ahora es administrar, no tomar decisiones técnicas.

La gestión podría, según el nivel de habilidad de sus desarrolladores, significar asesorarlos cuando lo soliciten. "¿Has mirado en Spring.NET?" (tenga en cuenta la falta de instrucción allí) es algo perfectamente bueno para decir. Además, "Google alrededor, mira lo que está haciendo el resto del mundo, no somos los primeros en enfrentar este problema".

En algunos aspectos, como desarrollador Java experimentado, puede estar en una mejor posición que la mayoría para esto. La mayoría de los frameworks y tecnologías de Java tienen un equivalente análogo en .NET. Por lo tanto, no tiene que decir "Aquí está lo mejor para usar", puede decir "He usado esto en Java, ¿conoce un equivalente de .NET?"

También fomente mucha conversación dentro del equipo. Organice reuniones de discusión técnica semanales. Todo lo que necesitas es información, al final; necesita saber qué decisiones tomaron y por qué. No necesita tomar esas decisiones para el equipo.

He tenido algunos muy buenos gerentes / líderes de equipo que sabían muy poco sobre la tecnología, y algunos de mis peores gerentes han sido aquellos que pensaron que sabían todo.

Para ser un líder, si tiene personas razonablemente competentes, lo principal es poder juzgar su competencia y juicio, y dar a cada uno la libertad que pueda manejar, mientras mantiene a los "patos salvajes" en la tarea y los "apenas competidores "ocupados con actividades" seguras "pero productivas. Asegúrese de que todos marchen al mismo baterista.

Su mayor desafío probablemente sea mantener a raya a la alta gerencia. Querrán informes, cronogramas y marcas de verificación, y debe descubrir qué es lo que quieren y cómo simularlos razonablemente bien. (Bueno, no exactamente "falso", pero produce documentación que los satisfaga sin consumir su tiempo o el tiempo de su equipo).

No fue elegido por sus habilidades de codificación de C #, y a menos que vaya a escribir código desde el principio, no importa si conoce C # o no. Debe comenzar a pensar en un nivel superior:

• ¿Qué habilidades aporta cada persona de tu equipo?
• ¿Qué componentes son críticos para el éxito del proyecto?
• ¿Qué tiene que producir además del código real? (¿Pruebas? ¿Documentación?)
• ¿Cómo reunirás los requisitos, si aún no lo has hecho?
• ¿Cómo abordarán usted y su equipo el proceso de diseño?
• Usted sabe que tener un estándar de codificación es importante, pero puede confiar en su equipo para determinar exactamente qué estándar quieren seguir.
• ¿Cómo puede detectar problemas temprano?

Algunas de estas cosas pueden pasar al territorio de gestión de proyectos, pero como desarrollador principal, trabajará estrechamente con el gerente del proyecto en estos y otros temas.

Por supuesto, aprenda a ser efectivo trabajando en C # lo más rápido posible. Solo recuerde que su función es ver más allá de la sintaxis y los detalles del marco y mirar la imagen más grande.

Toma un enfoque práctico. Comience por obtener un manual de C # simple y escriba un código. Pruebe algunas cosas básicas que sabría hacer con los ojos vendados en otro idioma.

Lea sobre el estilo de programación y la convención. Debería encontrar esto en parte en su manual de todos modos, pero también puede usar productos como StyleCop y Resharper para imponer reglas de estilo que no conoce. Esto lo capacitará efectivamente muy rápidamente para hacer las cosas de una manera comúnmente aceptada para evitar problemas al compilar su software.

Solo sé tú mismo y aplica los conocimientos de diseño que ya tienes. Los conceptos básicos son esencialmente los mismos, independientemente del idioma. Donde habrá diferencias será en cómo los idiomas difieren en términos de estructura será bastante mínimo, y gran parte se hará evidente muy rápidamente a medida que se combinan una aplicación de prueba o dos.

Si hay cosas obvias que no sabes, sé comunicativo. Su equipo respetará la honestidad más que simplemente irrumpir sin una pista. Tome decisiones bien informadas y razonadas, y siempre tómese un par de minutos para considerar su respuesta. Tendrá que ser firme sin intentar dominar, y no puede dejar que su falta de conocimiento en un área parezca ser un reflejo de su capacidad para liderar el equipo. El liderazgo implica la tutoría, pero la tutoría no significa que no se pueda mostrar la disposición de aprender algo nuevo.

Si piensa así y realmente se preocupa por eso, ya evitó el riesgo de convertirse en este tipo de líder de proyecto. Es un tipo de personalidad totalmente diferente que se atrevería a tomar decisiones sin el conocimiento adecuado. Solo mantén una mente abierta a lo que te dicen tus compañeros de trabajo y crea y fomenta una cultura de diálogo e intercambio de información en tu equipo.

Parece que hay algunos problemas en juego aquí.

La tecnología utilizada en el proyecto que está liderando y el proceso que rige el desarrollo de ese proyecto.

¿Eres el líder del equipo o un desarrollador líder? Un desarrollador líder también hace bastante trabajo de diseño y desarrollo. Entonces, la única forma de evitar esto es simplemente ponerse manos a la obra y aprender la nueva tecnología .

Si realmente dirige el equipo, deberá confiar en el equipo y dejar que dirijan la mayor parte de la dirección técnica del proyecto. Por supuesto, conceptualmente, podrá mantener esa dirección en la dirección correcta.

Los procesos que rigen el desarrollo del proyecto deberían estar en su lugar . Es solo cuestión de leerlos, comprenderlos y ejecutarlos.

Si no es así, negocie con su jefe para obtener un mentor que lo ayude a implementar algún proceso de desarrollo. Esto es muy importante Fallará bastante rápido si el proceso no está en su lugar y es ad hoc.

¡Buena suerte!

La oportunidad viene de vez en cuando ... No la agarres ... Yo diría, trata de aprender los conceptos básicos de C #. Obtenga un tutorial en línea, intente trabajar en ello. inicialmente sería difícil aprender el nuevo concepto, más tarde, cuando realice su primera tarea, tendrá cierta confianza en él.

Piensa en positivo, intenta asumir una tarea difícil, depura tu propio código y estoy seguro de que dominarás en él.

No pierdas tu oportunidad.

Creo que si tienes un buen grupo de desarrolladores de .Net, hay mucho conocimiento en el equipo que quizás necesites aprovechar para comenzar. Hay mucha similitud entre Java y .Net de que lo que ya sabes puede aplicarse más o menos directamente. La importancia es saber lo que es importante para acertar en este proyecto y los riesgos involucrados. Comunícate con tu equipo tantas veces como sea necesario. La práctica de la ingeniería de software evoluciona a lo largo de un proyecto, por lo que puede ser difícil tener una "mejor práctica" al principio del proyecto.

Tuve un poco al revés de tu experiencia, donde me dan un equipo muy verde de graduados que no son del campo relacionado con el software. Si bien tengo todas las razones para estipular lo que hay que hacer (estaba empleado), en cambio busqué práctica para que nos moviéramos y mucho entrenamiento y discusión para desarrollar nuestra práctica de ingeniería de software. ¡Aprendí un montón del equipo en el camino y casi estamos allí para entregar nuestro primer proyecto interno después de más de un año en el trabajo!

Estoy perdido cuando se trata de estándares de codificación, herramientas de ciclo de vida del proyecto y procedimientos de lanzamiento / distribución.

Encuentre un producto de código abierto que use la misma tecnología que usará.

Si es posible, encuentre uno que sea de alguna manera similar al dominio del problema. Esto no es tan importante como encontrar un proyecto con la misma tecnología y actualizaciones activas.

Descargue su código de trabajo. Léelo

Averigua qué herramientas usan. Usalos, usalos a ellos.

Descubre cómo construir y lanzar el proyecto de código abierto. Constrúyelo y suéltalo.

Un proyecto de código abierto (con varios contribuyentes) ilustrará las mejores prácticas.

No tengo dudas de que puedo aprender lo básico dentro de un mes o dos, pero hay ciertas experiencias que solo se pueden reunir con el tiempo.

Cierto.

Aprende de la comunidad de código abierto.