Recientemente, me encargaron más tareas de planificación de alto nivel debido a que el desarrollador principal de mi equipo se fue. Odio la planificación a largo plazo. Mi cerebro simplemente no parece estar conectado a él de forma natural, y no me interesa lo suficiente como para pasar el tiempo de aprenderlo (es bastante difícil mantenerse al día con el lado de programación de la imagen).
¿Puede uno seguir siendo un buen programador sin ser también un planificador de alto nivel?
Como programador senior, ¿se espera que uno sea bueno para planificar todo el producto y elegir una fecha de finalización?
Respuestas:
Los planes detallados de proyectos a largo plazo son conocidos por ser generalmente inexactos. La funcionalidad del sistema cambiará inevitablemente antes del lanzamiento, y las personas generalmente pasan mucho tiempo resolviendo los detalles que entran en la especificación solo para que las partes interesadas le den una mirada superficial en el mejor de los casos.
Debería leer más sobre la planificación ágil , es posible que se ajuste más a su mentalidad. Muchas metodologías ágiles intentan encontrar formas de alejarse de la planificación detallada a largo plazo.
Las metodologías ágiles intentan minimizar las especificaciones técnicas detalladas y la documentación a favor del código autodocumentado y las historias de usuario atómicas aisladas y , en última instancia, el software que funciona. En un equipo ágil eficiente, habrá una cantidad mínima de tiempo dedicado a la planificación.
Lea el Manifiesto Ágil y mire en Scrum . Use el método de desarrollo de sistemas iterativos y dinámicos para guiar el proyecto.
El principal inconveniente de los enfoques ágiles es que tienes que admitir abiertamente que no conoces el alcance exacto de tu proyecto , y lograr que la gerencia acepte esta idea puede ser extremadamente difícil, y generalmente lleva un tiempo. Vea esta pregunta y respuesta y esta publicación para obtener algunos consejos al respecto.
Sin embargo, es cierto que a medida que se convierta en un programador sénior, probablemente hará menos codificación, pero creo que en un equipo ágil en lugar de significar que escribe más especificaciones técnicas, significaría que pasará más tiempo administrando y dando clases particulares los miembros de su equipo y tomar decisiones arquitectónicas sobre el código.
fuente
Sí, es posible. Sin embargo, si desea ser un buen ingeniero de software o arquitecto de software, ahí es donde entra en juego su planificación de alto nivel. Para mí, la principal diferencia entre un programador y un ingeniero ha sido la capacidad de ver el panorama general.
fuente
Por un tiempo, si. ¿Es posible hacer esto por mucho tiempo? No.
Con muchos empleadores hoy en día, es un procedimiento operativo estándar dar aumentos competitivos en la industria
del costo de vida. Si no mejora, no intente abordar problemas más grandes y más difíciles, esos aumentos competitivos de la industria lo sacarán del mercado en cinco o diez años. Siga así y su empleador eventualmente comenzará a buscar una razón para deshacerse de usted, y su empleabilidad en otros lugares también disminuirá drásticamente.fuente
Claro, puedes ser un buen programador, desde el punto de vista de un programador. Desde el punto de vista de la gerencia es otra cuestión. En mi experiencia, participar en el proceso de planificación es la mejor manera de 1) obtener tareas de programación más interesantes y 2) hacerlas de la manera que desee.
En otras palabras, una vez que se reduce a la planificación a corto plazo, muchas opciones están fuera de la mesa. Si su solución preferida demoraría seis semanas pero solo presupuestan dos, está atrapado con lo que decidieron. Si tiene inquietudes sobre algo que ya discutieron en la planificación a largo plazo, no querrán repetirlo.
Si estás contento con ese estado de cosas, más poder para ti. La mayoría de las personas se sienten menos satisfechas con eso a medida que obtienen más experiencia.
El pequeño secreto sucio es que nadie es muy bueno en la planificación y estimación a largo plazo. Los mejores planificadores son los que son conscientes de sus limitaciones, así que créanlo o no, están a la vanguardia. Obtenga capacitación sobre contabilidad para la incertidumbre en la estimación. Mire técnicas como la programación basada en evidencia o scrum, que se basan en datos históricos para mostrar cuán precisas son sus estimaciones. Serás más feliz a largo plazo si tienes más voz en tu trabajo.
fuente
Respuesta corta: Sí, es posible.
Sin embargo, cuanto más experiencia tenga con el tipo de proyectos en los que participa, mejores ideas de planificación tendrá. Idealmente, como programador tenemos algún enfoque sobre cómo resolver el problema o buscamos uno. Por lo tanto, si conocemos el enfoque, entonces podemos comenzar a pensar en la planificación :)
Otra ruta posible es que un programador que se convierta en un buen planificador también se dirija hacia la Gestión de Proyectos. Por lo tanto, si tiene interés en la gestión de proyectos, puede hacer un esfuerzo adicional en esa dirección.
fuente
Sí y no son sus respuestas.
Por un lado, estás siendo empujado hacia la gestión de proyectos. En mi opinión, todos los buenos programadores tienen cierto grado de capacidad de gestión de proyectos, pero son diferentes conjuntos de habilidades. La capacidad de planificar a largo plazo mejora su capacidad de comunicarse con la gestión real del proyecto. Entonces "no" no puedes ser un buen programador sin la capacidad de planificar a largo plazo.
Dicho esto, la gestión de proyectos es un conjunto de habilidades diferente que atrae a aspectos relacionados pero diferentes a la programación. Entonces aquí es donde entra en juego el "sí". No es necesario ser gerente de proyectos para ser un gran programador.
Para su situación específica, trate de ser más objetivo sobre lo que la empresa necesita y lo que le gusta hacer. Hay demasiado ego reflejado en su pregunta y eso está sesgando su capacidad de ver esta situación. Si puede encontrar maneras de contribuir más a su empleador mientras sigue haciendo las cosas que disfruta, entonces debe considerarlas y hablar sobre el tema con su jefe.
fuente
Planificación y el jefe de Bungie
Dilbert tiene muchas tiras sobre el jefe bungie. Nuestros desafíos y expectativas sobre la planificación pueden ser tanto la causa como el efecto de la maldición del liderazgo. Mi experiencia en una compañía Fortune 100 fue que en un año, todos los que comenzaron el año como líderes del proyecto salieron. Quizás esto se debió al problema de planificación. No estoy seguro de si su líder anterior se fue por esta razón, pero cuando su rol requiere que haga un plan con un compromiso, si no se cumple, a menudo, el resultado es una salida relacionada con la fecha límite.
Contexto Organizacional de Planificación
Si no se siente cómodo con la planificación, quizás se sienta incómodo con la responsabilidad de los compromisos asumidos con el marketing u otras partes interesadas antes de que se documenten o comprendan los problemas a resolver. Este es un buen instinto.
La planificación es una herramienta importante. No lo descuides. No lo malentiendan.
La planificación está integralmente vinculada a los compromisos, la rendición de cuentas y el poder de negociación. La planificación ágil tiene muchos méritos. Debe conocer sus técnicas, así como las técnicas de metodologías planificadas. Su organización puede tener su propio enfoque y obtener consejos y trabajar con alguien que ha sobrevivido al liderazgo de muchos proyectos puede ser sorprendentemente útil.
Un ejemplo de planificación simple: no debe ser sobre software ...
Si una empresa de techado vino a mi casa para ofertar por un reemplazo, si ofertan demasiado bajo, pueden perder dinero en el trabajo, pero si ofertan demasiado, no obtendrán el trabajo en absoluto. De cualquier manera, están fuera del negocio. En su nuevo rol, si muerde demasiado, ejecutará el proyecto hasta que la responsabilidad comience, entonces tendrá problemas. Si estima un proyecto con suficiente relleno para asegurar el éxito en la fecha límite, muchos simplemente eligen a alguien más para liderar. La patada es que no eres como el techador. Puede ver qué tan grande es el techo y tiene datos históricos sobre cuánto tiempo dura ese techo.
Convertirse en un mejor planificador
Es posible que desee considerar algún tipo de capacitación. En las metodologías ágiles, y las metodologías planificadas más recientes, la estimación es una actividad de todo el equipo. En consecuencia, también debería considerar capacitar a su equipo.
Por experiencia, puedo decirle que puede ser frustrante obtener estimaciones de los miembros del equipo que lo pospondrán, darle estimaciones que hacen en dos minutos en función del nombre de la tarea sin referencia a un requisito o descripción de la característica o el código existente, o quienes insisten en que varias de las tareas que usted enumera se pueden realizar en una fracción del día a pesar de que los proyectos pasados han pasado semanas en problemas similares.
Existen varios cursos y certificaciones de capacitación para gerentes de proyectos, pero yo buscaría uno que estuviera acreditado de forma independiente. Puede valer la pena pensarlo dos veces antes de elegir certificar con enfoques basados en metodologías planificadas si espera trabajar con equipos ágiles (o al revés).
SLIM es un método inventado por Putnam después de trabajar en GE y otras compañías en proyectos de DoD en la década de 1970. SLIM es influyente, y su compañía QSM ofrece una certificación que parece fluir de una herramienta que fabrican. Dependiendo de si su empresa ha adoptado su herramienta, puede no tener valor o tener un valor alto.
Steve McConnell (autor de Code Complete) también escribió un libro sobre estimación de software, y su compañía Construx enseña dos clases para créditos PDU que están acreditadas a través del Project Management Institute. Tengo su libro, y si quisiera aprender sobre el tema a través de la capacitación en el aula, probablemente elegiría Construx. También hacen capacitación Scrum y administran varias evaluaciones scrum acreditadas a través de Scrum.org.
Otra fuente que podría proporcionar una gran capacitación académica sobre la estimación de proyectos de software sería el grupo de Barry Boehm en USC , basado en su extenso trabajo en el modelado de costos constructivos de COCOMO y COSYSMO que se ha utilizado en la NASA y otros contratistas grandes para estimar proyectos muy grandes. No estoy seguro de ser un verdadero creyente en COCOMO, pero me gusta el trabajo empírico que han realizado para correlacionar los efectos de los factores de escala y costos en la duración del cronograma.
También encontré un capítulo de un libro de texto publicado por O'Reilly que discute brevemente los principales métodos de estimación de software, incluidos Watts Humphreys PROBE y el juego de planificación de Kent Beck. PROBE incluye una noción de que los ingenieros realizan un seguimiento de las métricas de su propia productividad y luego las aplican a su parte asignada en nuevos proyectos. Planning Game es muy colaborativo entre desarrolladores y otras partes interesadas.
fuente