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

17

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?

ltfishie
fuente
12
para evitar ser odiado así, solo habla con los miembros de tu equipo. Hable regularmente, hable con frecuencia, hable 1: 1 "... Su recompensa por una cultura de 1: 1 saludable es una clara falta de drama".
mosquito
1
¿Cuál es su título y su responsabilidad exactamente para este proyecto? ¿Eres un PM, Desarrollador Senior, ...?
NoChance
Aprende de los mejores ... youtube.com/watch?v=GjJCdCXFslY
jfrankcarr
1
Pero en serio, escribí esta serie de artículos hace un tiempo que pueden serle
jfrankcarr

Respuestas:

19

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.

pdr
fuente
2
Correcto. Lo principal es estar dispuesto a dejar que sus "estrellas" técnicas tomen decisiones diferentes a las que usted hubiera tomado. Si puede hacer eso, entonces todos (excepto, por supuesto, la alta gerencia) serán felices y productivos.
Daniel R Hicks
"Por lo tanto, no tiene que decir" Esto es lo mejor que puede usar ", puede decir" He usado esto en Java, ¿conoce un equivalente de .NET? En la mayoría de los casos, si existe una herramienta equivalente, tendrá como prefijo una 'N', por lo que generalmente puede encontrarlas usted mismo.
Dan Neely
Tenga en cuenta que se etiqueta a sí mismo como "Desarrollador principal" y no como "Administrador de proyectos". En mi experiencia, estas son dos cosas muy diferentes.
Wonko el sano
@WonkotheSane: Es cierto que el OP se refiere a Project Lead, Team Lead y Lead Developer como si fueran todos lo mismo, y eso es confuso. Pero tomé mi ejemplo del contexto en el que se usan.
pdr
@pdr - estuvo de acuerdo, casi. La parte sobre "Puedo aprovechar los patrones de diseño y los paradigmas de OO" me hace preguntarme un poco.
Wonko el cuerdo
6

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).

Daniel R Hicks
fuente
4

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.

Caleb
fuente
2

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.

S.Robins
fuente
3
Yo diría que esto es exactamente lo contrario de qué hacer como gerente. Puede ser tentador entrar y tirar un código, pero ese ya no es su trabajo ... su trabajo es permitir que su equipo haga lo que los contrató y confiar en su experiencia y juicio. Intentar acelerar en una plataforma diferente es contraproducente.
Michael Brown
@MikeBrown Esto solo es cierto si el puesto es de gestión. Todos los puestos de liderazgo del equipo que he ocupado han requerido una cantidad significativa de tiempo de codificación, además de la gestión del proyecto, la planificación y otras responsabilidades que esperaría de este puesto. Si el OP hubiera dicho que sería un gerente , entonces mi respuesta hubiera sido muy diferente.
S.Robins
Tienes razón. Asumí gerente por el hecho de que era para una tecnología en la que no tenía experiencia. Haga una edición y deshaceré mi voto negativo :)
Michael Brown
@MikeBrown No estoy seguro de lo que sientes que necesito editar. Respondí la pregunta del OP basándose en su propia declaración de que él se convertiría en el líder del proyecto ... sin embargo, extenderé un poco la respuesta. :)
S.Robins
Oh, no era que sintiera que necesitabas editar ... solo que SO no me dejaría cambiar mi voto sin una edición :(
Michael Brown
1

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.

Thorsten Müller
fuente
1

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!

tehnyit
fuente
0

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.

Harisha
fuente
0

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!

Chris Chou
fuente
-1

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.

S.Lott
fuente
2
A veces, las personas que trabajan en proyectos de código abierto no utilizan las mejores herramientas disponibles ni siguen los estándares (buenas prácticas). Conozco pocos proyectos de código abierto (no quiero nombrarlos) que sean realmente malos en términos de uso de las herramientas adecuadas o incluso de seguir las convenciones de la industria.
Christian P
@ChristianP: Si bien hay algunos proyectos de código abierto menos que estelares, es fácil encontrar proyectos grandes que sean bastante buenos. Y encontrar cualquier proyecto de código abierto como ejemplo es mejor que ningún ejemplo.
S.Lott
Estoy de acuerdo en que cualquier ejemplo es mejor que ninguno. Pero cuando se buscan mejores prácticas, herramientas, etc., se puede aprender más de un buen proyecto de código abierto, incluso si el proyecto no resuelve el mismo problema.
Christian P