¿Cómo tengo éxito como desarrollador principal? [cerrado]

Me he convertido en el desarrollador principal de un proyecto en particular, pero tengo dificultades para centrarme en el panorama general y asegurarme de que todas las partes del proyecto estén cubiertas.

¿Qué debo tener en cuenta al gestionar este proyecto? ¿Cómo puedo asegurarme de que todo se maneje como debería?

He visto este viaje a otros desarrolladores mientras hacen la transición a senior o lead. Aquí hay algunas sugerencias que he hecho a otros.

• Comprende cuál es el objetivo del proyecto.

A menudo no se trata de todas las características que se han introducido en el proyecto. Se trata de un conjunto básico de funcionalidades que atiende una necesidad empresarial. Siempre tenga esto en cuenta porque ese es su objetivo principal.

• Desglose lo que debe hacerse en tareas. Comprender las dependencias entre ellos.

Desglosar un proyecto debería ser bastante sencillo. Divídalo tan pronto como pueda en el proyecto. Si tiene que pasar por alto las partes, comprenda que representan un riesgo hasta que comprenda lo que debe hacerse.

• Comprenda cuáles son las preguntas abiertas o las ambigüedades del proyecto.

Inicialmente no podrá resolver todas las ambigüedades (aunque debería intentarlo). Asegúrese de que su gerente y las partes interesadas del proyecto entiendan qué son y qué riesgos representan para el proyecto.

• Los negocios odian la sorpresa.

Asegúrese de que todos sepan (idealmente a diario, pero cada semana) cuál es el estado del proyecto. Y por estado me refiero a lo que se ha hecho, lo que queda por hacer, las preguntas abiertas, los problemas, etc. Cualquier cosa que pueda afectar la finalización del proyecto debe ser informada.

• Todos los días, repase el panorama general.

Deberías repasar el panorama general todos los días durante una hora. Hazte las preguntas. ¿Qué se ha completado? ¿Qué queda por hacer? ¿Cuáles son las preguntas abiertas? Cual es el objetivo? Debería poder darle a alguien un estado detallado del proyecto cuando lo soliciten.

El primer consejo que le daré es que acepte que administrar el equipo es más crítico que hacer sus propias tareas de programación. Eso significa que cuando tienes 3 juniors que necesitan ayuda, es tu trabajo ayudar a no quejarte sobre cómo te está alejando del desarrollo. Como líder, a menudo se convierte en el obstáculo para el progreso si primero está demasiado concentrado en sus propias tareas de desarrollo.

Además, necesita aprender a delegar. Es difícil darle tareas a alguien cuando puedes hacerlo fácilmente en una hora y sabes que se tambalearán por un día. Sin embargo, nunca progresarán a menos que obtengan las tareas y usted estará trabajando horas extras mientras su equipo está jugando.

Además, nunca solo arregles el código de otra persona. Dígales qué está mal (y por qué) y haga que lo arreglen. O entrará en un ciclo en el que tendrá que arreglar todo porque no están mejorando. Si no pueden arreglarlo, considere si deberían permanecer en el equipo. No dejes que los miembros débiles del equipo se queden porque estás arreglando todo lo que hacen.

Como líder, puedes ser el malo y darles las noticias desagradables (tanto arriba como abajo de la cadena). Eso va también con el trabajo. Eso significa que tiene que hacer la evaluación de bajo rendimiento; debe decirles que la fecha límite se adelantó o que los requisitos han cambiado; necesitas empujar al tipo perezoso que no está progresando; y tiene que decirle a sus superiores cuándo no se cumplirá el plazo y por qué y qué está haciendo al respecto. Ser líder no se trata de ser querido, sino de ser efectivo. Su trabajo es sacar el software por la puerta, no hacer amigos. La comunicación es clave y evitar las malas noticias termina empeorando la situación. Es mucho más probable que un cliente maneje que le digan que pasarán tres semanas más al mes antes del lanzamiento que cuando la fecha de lanzamiento pase y luego le diga que necesita tres semanas más.

Aquí está mi lista de verificación informal. Es muy informal ... No hago todo todos los días, pero si no he tocado todas estas cosas semanalmente, me preocupo un poco, y si no las he golpeado mensualmente, debería entrar en pánico. Y el kilometraje varía completamente según la cultura de la empresa / equipo, el estilo personal y el tipo de proyecto.

• Hable individualmente con el equipo : ¿todos los miembros de su equipo tienen un trabajo útil que hacer? ¿Sabes cuál es el objetivo general del producto y la versión actual? ¿Saben cómo se gana dinero y cuál es el mayor impulso de su negocio? ¿Saben cómo encaja su trabajo actual con todo eso?

• Hable con el equipo colectivamente : reúna a todos con las principales noticias, reúna a los grupos para asegurarse de que la comunicación esté ocurriendo con usted y sin usted. Como equipo pequeño, probablemente se trate de sesiones de estrategia grupal. A medida que el equipo crezca, se convertirá en el caso de que tengas que guiarlos a través de los puntos principales, e inevitablemente se convertirá en un escenario de hablar en ellos. Eso no está mal: hay momentos en que es muy importante que todos te oigan decir la información pública a todos . Entonces todos saben que usted está dando la información universalmente. Pero la reunión "usted para todos" es muy diferente de la reunión de estrategia de grupo en la que es más una guía.

• Pruebe el trabajo del equipo : intente obtener una pequeña encuesta del trabajo de todos. Lea su código, ejecute sus funciones, pruebe sus casos de prueba. No apunte al 100% del trabajo de todos, intente probar un poco de todos. Déles retroalimentación, pero también archive áreas de fortalezas y debilidades en todo el equipo.

• Consulte con su gerencia con anticipación y con frecuencia : esto no es una burla marrón, se mantiene al tanto. Si no sabe qué necesita su gerencia y qué piensa su gerencia, ¿cómo puede su equipo cumplir con las expectativas? Necesitas tener una buena respuesta con tu jefe y debes estar en su equipo, como tu gente está en tu equipo. Ser capaz de comunicarse efectivamente con el jefe en asuntos triviales aumenta la confianza de que podrá obtener ayuda y una comprensión clara cuando llegue la crisis. También es una buena comprobación de la realidad de dónde están las anteojeras de su gran imagen.

• Revise los recursos del equipo periódicamente : las personas gritarán cuando un recurso previamente disponible no esté disponible, pero revisen los puntos desconocidos de dolor. ¿Dónde están tus puntos de estrangulamiento? ¿Hay nuevas herramientas que sería útil tener? La mayoría de los equipos tienen un tipo al que considero el cazador de herramientas que siempre está al día con los últimos y mejores dispositivos. Equilibre las conversaciones entre Tool Hunter y GuyWhoHatesEverythingNew para encontrar el siguiente punto de evolución. Las herramientas incluyen todo: SW, HW, espacio físico, recursos de aprendizaje.

• Conozca y manténgase en contacto con los equipos de soporte. Cada compañía es diferente, pero conozca a las personas a cargo de su control de calidad, redacción de documentos, asuntos legales, instalaciones, finanzas y cualquier otro grupo de apoyo exclusivo de su negocio. Son los mejores desencadenantes del panorama general en los que puedo pensar, porque ven el mundo completamente diferente a ti.

• Conozca a su competencia : pase al menos un tiempo cada semana para descubrir cómo alguien resolvería los problemas que su producto resuelve si no lo estuvieran utilizando. Puede que no sea una sola compañía, pero ¿qué ofrece esa otra solución que usted no ofrece?

• Revisar costo y horario- ¿Qué tan probable es que su equipo se refiera a su fecha límite actual? ¿Qué tal el próximo plazo? ¿Cuál es la tasa de quema de sus costos? ¿Qué grandes compras futuras aún no has pagado? ¿Qué queda de tu presupuesto? Los detalles varían con la forma en que realiza el seguimiento financiero, pero incluso en una empresa muy informal, debe tener una idea de cuántos días / semanas / meses de presupuesto le quedan y cuál es su fecha límite para el producto actual. En algún lugar, de alguna manera es mejor que alguien esté planeando "¿cuántas personas necesitamos para hacer este trabajo? y "¿podemos permitirnos pagarles el próximo mes / trimestre / año?". Necesita conocer esos números y tener información sobre los próximos pasos. Necesita un plan claro para la próxima semana que podría explicar en este momento si alguien entró y preguntó. Necesitas un plan bastante bueno para el próximo mes, eso solo cambiará en 2-3 lugares cuando la realidad golpee. Necesita un plan incompleto para el trimestre y un general fuera de su alcance para el año. Más allá de eso, incluso en un gran proyecto, los números son solo números. Escúchalos, pero date cuenta de que nadie firmó con sangre.

Esa es mi fuera de la parte superior de mi lista de la cabeza. Por lo general, le agrego algo que me golpea en la cabeza con una "sorpresa" (imagíneme un poco sensible a un área que no vi y luego me las arreglo para incluirlo en la lista de verificación). "Sorpresa" con una sonrisa forzada y dientes apretados. )

Además, prepárate para el cambio de contexto temible. Si recién está comenzando en la administración, es probable que tenga un equipo pequeño y alguien en la gerencia pensó que estaría bien que pasara un tiempo administrando un equipo y un tiempo haciendo cosas de contribuyentes individuales. Esto se puede hacer, pero el cambio de contexto entre los dos es difícil. Planea para ello. Bloquee el tiempo para cambiar (como antes y después del almuerzo) y conozca su conjunto de habilidades menos practicadas y tenga en cuenta que tendrá que arrastrarse allí las primeras veces, así que reserve tiempo para hacer algo "relacionado con el panorama general" y calcule que necesitará al menos dos horas para llegar realmente a cualquier parte.

El cambio de contexto funciona en ambas direcciones: gestión en el trabajo práctico y viceversa. Pero cuando pasas de tu punto de fuerza y ​​práctica a tu lugar de incomodidad y menos práctica, entonces sientes más el dolor y el impulso para retirarte es fuerte. Sepa que está ahí y luche contra él y comprenda que dar vueltas en el panorama general lo hace mejor para asimilarlo todo. Tómese el tiempo para golpear.

Lea este libro: Pastoreo de gatos: un manual para programadores que lideran programadores

Hace un tiempo regalé este libro a mi jefe y le gustó. Cuando lo estaba leyendo, parecía que él sabía de lo que estaba hablando. Y esto es así. El autor cuenta sobre su propia experiencia. No es una colección de "verdades simples" del gerente: estas son las palabras del ex programador. Y debe entenderse que fue SU experiencia, pero la suya podría ser diferente. Entonces, en algunas cosas debes mirar críticamente. "El gerente ya no puede ser un programador, es importante".

Cuando asumí el liderazgo técnico de una pequeña empresa recientemente en un producto que no desarrollé, lo que encontré muy útil para administrar las cosas fue documentar en inglés el funcionamiento del producto, características que documenté en pepino y para aspectos internos. Escribí explicaciones del modelo de objetos y fluí a través de varios controladores. Lo que descubrí al hacer eso fue que A) el producto era un poco desordenado :) Y B) Aprendí mucho más rápidamente cómo funcionaba la aplicación, para poder tener una conversación inteligente sobre los problemas que existían y las necesidades de refactorización, o lo que se necesitaría para implementar una característica dada.

Las imágenes también ayudan: no me meto con productos como Visio, solo uso crayones y papel en blanco (realmente, lo hago, trabajo desde casa y a menudo junto a mi hijo de 2 años), pero lo que funcione para usted es lo que debe usar.