A todos les encanta embarcarse en los llamados proyectos de “campo verde”. Ahora tengo alrededor de un año en uno. Anteriormente en este trabajo había hecho algunos otros, aunque tenían vidas limitadas y desde entonces han sido retirados.
(Normalmente, una vida útil de uno o dos años para una pieza de software es una señal de que algo salió mal. En este caso, ese fue solo parcialmente el caso. Algunos de estos programas tenían, por definición, una vida limitada, una cantidad limitada de trabajo hacer después de lo cual ya no eran necesarios. Otros mostraron los signos de mi propia inexperiencia con algunas de las herramientas y bibliotecas particulares que utilicé y no fueron un buen ejemplo de diseño de software. Fueron reemplazadas por mejores sistemas).
Otro proyecto mucho más grande y abierto comenzó hace unos años y el nuevo desarrollo continúa a buen ritmo incluso hoy. Es un “marco” para construir tareas de automatización fuera de línea y, por lo tanto, tiene porciones que cambian raramente y porciones que continúan evolucionando y creciendo. Este programa ahora bastante grande es un poco extraño en nuestra arquitectura de servicios de fondo. Se ejecuta principalmente de forma autónoma en lugar de bajo demanda por otros sistemas de clientes. Una implicación de su papel en nuestro ecosistema de back-end es que solo tuve que tratar con otros ingenieros para definirlo y diseñarlo. Un buen concierto, cuando puedes conseguirlo.
- ¿Qué es ser como un ingeniero de software?
- ¿Cómo se convierte un ingeniero de software en una persona más completa al intentar avanzar en su carrera?
- ¿Cómo puede un desarrollador de productos hacer la transición a un rol de gerente de producto?
- ¿Cómo se puede racionalizar la industria del software de la India a una como en Estados Unidos para un horario de trabajo de 8 a.m. a 5 p.m.
- ¿Cuál es el papel de un ingeniero de producto?
El proyecto más reciente, el que ahora tiene aproximadamente un año, es diferente. Si bien no tiene interacciones orientadas al cliente, es de interés para las ramas del negocio que no son de ingeniería. Por lo tanto, se ha enfrentado a algunos de los desafíos clásicos de “requisitos cambiantes” que son tan comunes y similares a los descritos en la respuesta de Alan Mellor.
Esto todavía califica como un proyecto pequeño con solo dos ingenieros que realizan la mayor parte del trabajo de diseño e implementación. (Por cierto, considero que dos o tres personas tienen un tamaño de equipo óptimo si el proyecto se puede hacer con esas pocas personas).
De todos modos, recibimos muchas solicitudes para cambiar las capacidades del sistema a medida que avanzaba el diseño y la implementación. Debido a que ambos somos desarrolladores muy experimentados, hemos creado una arquitectura que podría acomodar fácilmente estas solicitudes. Uno de ellos, sin duda aparentemente simple para los departamentos que lo solicitaron, resultó tener consecuencias algo más significativas. Considero que es un testimonio para mis colegas en otras ramas del negocio, así como nuestra capacidad para explicar por qué ese cambio tendría que diferirse una cuarta parte para que pudiéramos posponer la satisfacción de esa solicitud en particular.
Entonces, sí, a menudo la diversión de la “hoja en blanco” puede ser estropeada por intrusos jugando con su diseño finamente diseñado. Pero ese no es siempre el caso. En cualquier caso, es parte del trabajo. El software rara vez se ejecuta en ningún tipo de aislamiento, ya sea la arquitectura técnica o el entorno, el institucional o los requisitos comerciales.
Sin embargo, no es razonable esperar estar libre de este tipo de requisitos en evolución en su carrera. Básicamente, todos los que escriben software están proporcionando un servicio a otra persona. Esas personas son partes interesadas y tienen un papel innegable en el proceso de desarrollo. El hecho de que a menudo son personas no técnicas crea un desafío. Esta es la razón por la cual, entre otras cosas, la capacidad de comunicarse efectivamente incluso con personal que no es de ingeniería es importante para las personas en roles de liderazgo en el desarrollo de software.
Sospecho que una de las razones por las cuales las personas persiguen sus propios proyectos favoritos es que no tienen que responder ante nadie para hacerlo …