Un día un pibe programador dijo "Ché, qué es esta variable rorColo" y vino Mister Old Grandpa a decirle "Es true cuando hay un error en el proceso de colocación."
A la papirola.
Y nunca faltan esas tablas llamadas USRPIJATBL001 o lo que es peor, que todos los datos se repitan en todas las tablas, haya o no FK.
Grandes monstruos se han construído sobre el estiércol del día a día. "Necesito un string ya. A ver... oh si, string93". Claro que estoy hablando casos extremos, que he visto poco (por suerte!). Sin embargo, muchísimos sectores de sistemas en muchas empresas están caldeadas y pelean día a día con estos problemas. Con leer The Daily WTF ya nos damos una idea.
Por otro lado es común que las variables, clases, etc, se nombren como vienen, y no se respete ningún estándar. Y sólo estoy hablando de nomenclaturas. Podemos escribir estándares sobre cualquier situación "estándar" que se nos ocurra.
Este post es para divagar un poco sobre qué ocurre y de quién es la culpa cuando esos estándares existen, pero no se respetan. ¿Están mal escritos? ¿Los empleados son rebeldes?
Vamos a analizar los actores. ¿Pero por dónde empezar? ¿Desde el management o desde la fuerza de programadores rasos? Y bueno, empecemos de arriba a tirar palos.
El management y los arquitectos que desarrollan el estándard...
Un estándard de programación tiene que pasar a formar parte de la cultura de tu empresa, porque afecta directamente a la calidad del producto software que vas a crear. Estés o no en una empresa cuyo negocio central sea sistemas, deberías siempre apuntar a hacer software de calidad, y el software se construye de muchas cosas, pero una de ellas es el código. Y en el código podemos poner solamente código o podemos implementar un modelo realmente bien pensado de forma arquitectónica para aprovechar las ventajas de las buenas prácticas.
Entonces, si debe ser parte de la cultura de la empresa, y parte del proceso de creación de productos con calidad, ¿No es una tarea importante del management (en conjunto con los arquitectos) que se implemente? Yo opino que sí. Cuando entré en uno de mis trabajos me hicieron leer guias y guias de estándares, y siempre los respeté todos. Empecé a trabajar en un sector que los utilizaba y realmente creía ver código conciso y pensar que lo podría haber hecho cualquiera. Sin embargo, luego me moví a otro sector que era todo lo contrario. ¡Un desastre!
Poco a poco fuí impulsando cambios (desde abajo, como programador) para intentar mejorar la aplicación de los estándares, además de otras cosas. Pero nunca nadie de arriba se interesó por si estábamos haciendo las cosas bien o no. Cada uno de nuestros proyectos tenía un arquitecto asignado. Sólo lo conocí en un curso, y nada más. Ni siquiera se interesó cuando se arrancó un proyecto impulsado por el sector mismo, para construir un framework de SharePoint.
Sin interés de arriba el único que puede impulsar un cambio es uno, pero lo más probable es que los cambios significativos sólo fuesen a impactar en nuestro sector y nada más. Es un estándar tirado a la basura porque no se implementa ni se promueve.
Los project managers...
Un PM se la pasa pensando en fechas de entrega, implementaciones, y tareas pendientes. Casi nunca un PM te vá a decir "che y si rehacemos el módulo X?". Tienen un trabajo bastante cargado, y son apurados por el mismo management. Sin embargo, de vez en cuando deberían impulsar cambios a mejoras en la calidad y promover la implementación de estándares. Si tus programadores trabajan mejor, se entienden mejor, y hacen las cosas más rápido, ¿no van a mejorar los resultados?. Obviamente.
Pero es difícil parar la pelota, encontrar el tiempo, y pensar la jugada. Pero lo lamento, también los culpo.
Los analistas técnicos y programadores seniors...
Si se nos presenta un estándar de programación es nuestra responsabilidad aplicarlo, independientemente de cómo trabaje el resto y del código con el que estemos trabajando. Así que si no aplicamos un estándar... obviamente, es NUESTRA culpa también. Nadie está exento.
Además, como miembros más experimentados y/o más antiguos, hay que impulsar la implementación a los programadores más novatos. Se les debe inculcar la cultura de la calidad, y una de las cosas que eso requiere es el uso de estándares.
Es culpa de todos. Promuevan y apliquen los estándares. Y si no tienen uno, es buen momento para arrancar.
Yo estoy a punto de escribir uno para la empresa en donde estoy, donde voy a usar mi experiencia propia más estándares que ya conozco. Una vez terminado, sea aceptado o no, lo publicaré aquí.
Thursday, April 28, 2011
Friday, April 15, 2011
La calidad contra el tiempo
Cuando uno ha llegado a un buen nivel de entendimiento de patrones de diseño, arquitecturas de aplicaciones, conocimiento de los frameworks de las empresas por las cuales pasamos (con sus ventajas y desventajas), conociendo qué podemos esperar de los demás (según su seniority, experiencia, funciones, etc), llegamos a un momento donde nos preguntamos: Si hicieramos las cosas apuntando siempre a una mucho mejor calidad, ¿Habría una ganancia para nosotros y la empresa?
Pensemos en la siguiente frase que leí el otro día: "No te quejes de que las cosas no estén bien hechas. Si lo estuvieran, no tendrías trabajo". Es excelente e ilustra muy bien la realidad de las empresas de software. Hasta ahora no he pasado por ninguna que tenga un gran desarrollo de frameworks, con diseños excelentemente pensados, extensibles, que puedan evolucionar, etc.
Linux puede hacerlo, Google puede hacerlo, Microsoft (algunos productos nomás) puede hacerlo. Por algo están la cima, por algo pueden competir de la manera que lo hacen. ¿Pero puede una empresa pequeña competir de tal manera? Facebook no nació de adentro de una piscina de dinero. Creo que todos estamos familiarizados con la película "The Social Network". Tengo mis propias críticas de la misma, pero las dejaré para otro post. Ahora pensemos en el concepto demostrado por el protagosnista.
Todo inició "hackeando" sitios web de otras universidades para armar una competencia de "qué chica te gusta más" y rápidamente construyó un sistema de ranking online. No hubiera sido posible de no tener una buena base de conocimientos de programación. Pero qué estoy diciendo! No hubiera sido posible sin entender bien la programación, el manejo de servidores, los tipos de seguridad, etc. Con todo ese conocimiento, Zuckerberg fué capaz de crear un "negocio" prácticamente en una noche. Si bien no recibía ganancias por él, no faltaba mucho por hacerse para que eso fuera posible. Claro que después se dedicó a lo que es facebook.
Lo que nos permite hacer todo esto tan rápidamente no es sólo conocimiento (aunque es algo ESCENCIAL), sino también nuestra proyección a futuro y la calidad de nuestro código.
Imaginen un escenario más cercano a nosotros. No es lo mismo iniciar una aplicación con base de datos (abms y esas yerbas) teniendo un framework para conexión a datos, que no teniendo nada. Supongamos que la programación del negocio y las interfaces de usuario, sin manejo de datos, nos toma 2 meses. Entonces, los datos en una aplicación de este tipo nos tomarían como otros 2 meses o mes y medio si no tuviéramos framework. Con framework podríamos tardar 3 semanas y con un auto generador de código medio "pelele" o de código débil podríamos tardar una semana o un poco más, por la complejidad que ese código mal generado nos podría generar, y si tuviéramos un framework y además un generador de código con alta calidad en su producto podríamos estar tranquilos que con un par de horas podríamos generar todos los datos y estaríamos muy seguro de lo generado. Tardaríamos más en crear el modelo de datos que hacer la capa de datos en sí.
Ven la importancia? Reducimos en 2 meses el desarrollo de nuestra aplicación. Claro que son números sacados de la galera, pero estoy seguro de que no estoy tan alejado en el porcentaje de disminución de tiempo que cada escenario refleja.
Imaginen la importancia de esto en los siguientes aspectos:
* Licitamos por un proyecto. Somos los que prometemos las mejores estimaciones de tiempo. Eso no sólo es bueno por el tiempo en sí, sino porque nuestros costos probablemente serán los menores, por lo que podremos obtener (Además) un mayor margen de ganancias.
* Nuestros programadores encargados de la arquitectura, frameworks y generadores de código podrán alcanzar un gran nivel de conocimiento (con la adecuada guía)
* Nuestra empresa podrá expandirse y tener un sector de arquitectura dedicado a resolver problemas al sector de software.
Y aquí en este último punto hay algo muy importante. Sistemas está para solucionar los problemas de los demás, pero quién soluciona los problemas de Sistemas?
Generalmente en las empresas no hay tiempo para desarrollar los frameworks, arquitecturas, generadores de código, y refactorear las aplicaciones actuales para mejorar su calidad y disminuir el costo de manutención. Invertir en un sector de arquitectura es una inversión REAL. Ponemos X plata hoy para mañana tener X+Y plata, donde X fué la inversión y donde Y es la ganancia. GANANCIA. DINERO. VIEJA, ES GUITA LO QUE SE PIERDE DÍA A DÍA.
Yo manejo una teoría donde una aplicación puede llegar a recrearse por completo en menos de una hora, adaptándola a nuevos estándares, arquitecturas y necesidades, todo estando bajo una misma base extensible, consensuada y proyectada para un fin como ese. Pero claro, irónicamente me falta tiempo para desarrollarla. Ese proyecto lo tengo pendiente desde hace tiempo, aunque hace poco empecé a hacer anotaciones para que en algún momento pudiera iniciar mi proyecto de investigación. Mientras tanto, continúo conocimiendo la mayor variedad de problemáticas posibles para sistematizarlas en un futuro y poder encauzar todas las acciones de un negocio en una arquitectura extensible que intuya automáticamente las decisiones de negocio a tomar, pudiendo establecer las particularidades de cada negocio, pero sin olvidar que todo se resume a las matemáticas. Claro que si tu problema entra en el campo de las sociales, ya no te podré ayudar (al menos por ahora). Habrá que seguir negociando con proveedores, teniendo una fuerza de ventas, etc. Pero nunca digas nunca, yo creo que en algún momento las sociales se reducen a una matemática extremadamente compleja que hoy por hoy no nos es posible teorizarla, y por eso lo tenemos como una disciplina aparte. Además si dicha matemática existiera, sería simplemente menos costoso y más rápido usar nuestras habilidades sociales que realizar todos los cálculos pertinentes (hoy por hoy).
Persona detrás de la pantalla leyendo: "Bueno este flaco fuma de la buena."
No podemos pasar nuestra vida programando. Llega un momento donde todo profesional que aprecie a su carrera y le ponga importancia debe tomar una decisión: ¿De qué sigo? Hoy en día hay algunos caminos posibles (deben haber más):
* Gerenciamiento
* Liderazgo y Conducción
* Arquitectura
* Otros no relacionados tan directamente a software. Redes, hardware, etc.
Es imposible preveer las dificultades del futuro, y nunca vamos a tener un generador de código que nos solucione nuestros problemas para toda la vida. Pero con una teoría bien armada que apunte hacia eso (o que tienda a infinito, por decirlo de una forma análoga un poco estúpida) podemos apuntar alto en nuestras decisiones de arquitecturas. Claro, lo más probable es que no logremos llegar tan alto, pero no hay que perder el orgullo por ello.
El costo del tiempo que hoy perdimos pensando y mejorando nuestras arquitecturas y generadores lo ganaremos mañana durante el resto de nuestras vidas.
Quizás el día de mañana todo desemboca en una raza de Terminators que pueden hacer de todo mejor que los humanos, incluyendo cosas tan humanas y dificiles de sistematizar como negociar con otras empresas, armar campañas de marketing, tomar decisiones políticas a nivel internacional, etc. No creo que llegue a ver eso en esta vida, pero estoy seguro que el día de mañana la subjetividad y la personalidad podrán programarse y parametrizarse.
¡¡Pero basta de volar!! El punto final es que poner nuestro esfuerzo al servicio de la calidad, apuntándo alto o aunque sea a resolver algunos problemas menores locales siempre nos va a favorecer.
Dedicar 25% de nuestro día a ello puede marcar la diferencia. 2 de 8 horas por día puede hacer que el día de mañana nuestro trabajo sea más fácil 8 de 8 horas por día.
Saludos desde una mesa puesta en una nube en el cielo, jugando al ajedrez con el arquitecto de matrix. (??)
Pensemos en la siguiente frase que leí el otro día: "No te quejes de que las cosas no estén bien hechas. Si lo estuvieran, no tendrías trabajo". Es excelente e ilustra muy bien la realidad de las empresas de software. Hasta ahora no he pasado por ninguna que tenga un gran desarrollo de frameworks, con diseños excelentemente pensados, extensibles, que puedan evolucionar, etc.
Linux puede hacerlo, Google puede hacerlo, Microsoft (algunos productos nomás) puede hacerlo. Por algo están la cima, por algo pueden competir de la manera que lo hacen. ¿Pero puede una empresa pequeña competir de tal manera? Facebook no nació de adentro de una piscina de dinero. Creo que todos estamos familiarizados con la película "The Social Network". Tengo mis propias críticas de la misma, pero las dejaré para otro post. Ahora pensemos en el concepto demostrado por el protagosnista.
Todo inició "hackeando" sitios web de otras universidades para armar una competencia de "qué chica te gusta más" y rápidamente construyó un sistema de ranking online. No hubiera sido posible de no tener una buena base de conocimientos de programación. Pero qué estoy diciendo! No hubiera sido posible sin entender bien la programación, el manejo de servidores, los tipos de seguridad, etc. Con todo ese conocimiento, Zuckerberg fué capaz de crear un "negocio" prácticamente en una noche. Si bien no recibía ganancias por él, no faltaba mucho por hacerse para que eso fuera posible. Claro que después se dedicó a lo que es facebook.
Lo que nos permite hacer todo esto tan rápidamente no es sólo conocimiento (aunque es algo ESCENCIAL), sino también nuestra proyección a futuro y la calidad de nuestro código.
Imaginen un escenario más cercano a nosotros. No es lo mismo iniciar una aplicación con base de datos (abms y esas yerbas) teniendo un framework para conexión a datos, que no teniendo nada. Supongamos que la programación del negocio y las interfaces de usuario, sin manejo de datos, nos toma 2 meses. Entonces, los datos en una aplicación de este tipo nos tomarían como otros 2 meses o mes y medio si no tuviéramos framework. Con framework podríamos tardar 3 semanas y con un auto generador de código medio "pelele" o de código débil podríamos tardar una semana o un poco más, por la complejidad que ese código mal generado nos podría generar, y si tuviéramos un framework y además un generador de código con alta calidad en su producto podríamos estar tranquilos que con un par de horas podríamos generar todos los datos y estaríamos muy seguro de lo generado. Tardaríamos más en crear el modelo de datos que hacer la capa de datos en sí.
Ven la importancia? Reducimos en 2 meses el desarrollo de nuestra aplicación. Claro que son números sacados de la galera, pero estoy seguro de que no estoy tan alejado en el porcentaje de disminución de tiempo que cada escenario refleja.
Imaginen la importancia de esto en los siguientes aspectos:
* Licitamos por un proyecto. Somos los que prometemos las mejores estimaciones de tiempo. Eso no sólo es bueno por el tiempo en sí, sino porque nuestros costos probablemente serán los menores, por lo que podremos obtener (Además) un mayor margen de ganancias.
* Nuestros programadores encargados de la arquitectura, frameworks y generadores de código podrán alcanzar un gran nivel de conocimiento (con la adecuada guía)
* Nuestra empresa podrá expandirse y tener un sector de arquitectura dedicado a resolver problemas al sector de software.
Y aquí en este último punto hay algo muy importante. Sistemas está para solucionar los problemas de los demás, pero quién soluciona los problemas de Sistemas?
Generalmente en las empresas no hay tiempo para desarrollar los frameworks, arquitecturas, generadores de código, y refactorear las aplicaciones actuales para mejorar su calidad y disminuir el costo de manutención. Invertir en un sector de arquitectura es una inversión REAL. Ponemos X plata hoy para mañana tener X+Y plata, donde X fué la inversión y donde Y es la ganancia. GANANCIA. DINERO. VIEJA, ES GUITA LO QUE SE PIERDE DÍA A DÍA.
Yo manejo una teoría donde una aplicación puede llegar a recrearse por completo en menos de una hora, adaptándola a nuevos estándares, arquitecturas y necesidades, todo estando bajo una misma base extensible, consensuada y proyectada para un fin como ese. Pero claro, irónicamente me falta tiempo para desarrollarla. Ese proyecto lo tengo pendiente desde hace tiempo, aunque hace poco empecé a hacer anotaciones para que en algún momento pudiera iniciar mi proyecto de investigación. Mientras tanto, continúo conocimiendo la mayor variedad de problemáticas posibles para sistematizarlas en un futuro y poder encauzar todas las acciones de un negocio en una arquitectura extensible que intuya automáticamente las decisiones de negocio a tomar, pudiendo establecer las particularidades de cada negocio, pero sin olvidar que todo se resume a las matemáticas. Claro que si tu problema entra en el campo de las sociales, ya no te podré ayudar (al menos por ahora). Habrá que seguir negociando con proveedores, teniendo una fuerza de ventas, etc. Pero nunca digas nunca, yo creo que en algún momento las sociales se reducen a una matemática extremadamente compleja que hoy por hoy no nos es posible teorizarla, y por eso lo tenemos como una disciplina aparte. Además si dicha matemática existiera, sería simplemente menos costoso y más rápido usar nuestras habilidades sociales que realizar todos los cálculos pertinentes (hoy por hoy).
Persona detrás de la pantalla leyendo: "Bueno este flaco fuma de la buena."
No podemos pasar nuestra vida programando. Llega un momento donde todo profesional que aprecie a su carrera y le ponga importancia debe tomar una decisión: ¿De qué sigo? Hoy en día hay algunos caminos posibles (deben haber más):
* Gerenciamiento
* Liderazgo y Conducción
* Arquitectura
* Otros no relacionados tan directamente a software. Redes, hardware, etc.
Es imposible preveer las dificultades del futuro, y nunca vamos a tener un generador de código que nos solucione nuestros problemas para toda la vida. Pero con una teoría bien armada que apunte hacia eso (o que tienda a infinito, por decirlo de una forma análoga un poco estúpida) podemos apuntar alto en nuestras decisiones de arquitecturas. Claro, lo más probable es que no logremos llegar tan alto, pero no hay que perder el orgullo por ello.
El costo del tiempo que hoy perdimos pensando y mejorando nuestras arquitecturas y generadores lo ganaremos mañana durante el resto de nuestras vidas.
Quizás el día de mañana todo desemboca en una raza de Terminators que pueden hacer de todo mejor que los humanos, incluyendo cosas tan humanas y dificiles de sistematizar como negociar con otras empresas, armar campañas de marketing, tomar decisiones políticas a nivel internacional, etc. No creo que llegue a ver eso en esta vida, pero estoy seguro que el día de mañana la subjetividad y la personalidad podrán programarse y parametrizarse.
¡¡Pero basta de volar!! El punto final es que poner nuestro esfuerzo al servicio de la calidad, apuntándo alto o aunque sea a resolver algunos problemas menores locales siempre nos va a favorecer.
Dedicar 25% de nuestro día a ello puede marcar la diferencia. 2 de 8 horas por día puede hacer que el día de mañana nuestro trabajo sea más fácil 8 de 8 horas por día.
Saludos desde una mesa puesta en una nube en el cielo, jugando al ajedrez con el arquitecto de matrix. (??)
Monday, April 11, 2011
Creando nuevas costumbres organizativas
Muchas veces se nos ocurren ideas en medio de un desarrollo, pero carecemos del tiempo necesario para pensarlas en detalle y mucho menos vamos a poder desarrollarlas en el momento. Esto hace que muchas veces nuestras ideas se olviden y no nos acordemos de ellas hasta mucho tiempo después.
Otras veces, encontramos "chunks" de código que sabemos que podrían compartimentarse para reutilización en vez de repetir las mismas líneas de código una y otra vez. Ni siquiera estamos siendo pretenciosos de aplicar patrones de diseño y realizar una solución realmente profesional para la reutilización de ese código. No, simplemente queremos compartimentar ese comportamiento en otro lado para reutilizar, porque de por sí no tenemos tiempo para una solución profesional. Lo que es peor, muchas veces no tenemos ni siquiera de aplicar esa solución de compartimentación (Sea un método aparte, clase, etc).
Otras veces se nos ocurren modelos y clases que realmente nos podrían ayudar en el día a día, pero no estamos totalmente seguros de que sean la forma correcta, o sea que todavía son ideas que necesitan ser más pensadas.
A veces tenemos ideas para hacer aplicaciones pequeñas que nos ayuden en el día a día. Algo que nos permita grabar todos nuestros scripts de tsql que usamos para modificar la base de datos y que luego nos ayude para implementar en los demás ambientes y clientes, por ejemplo. Otro que nos genere código automático para todas nuestras tablas. Otro que tome las entidades de nuestros modelos y nos genere automáticamente nuestros ABM, ya sean ASPX o WinForms.
En fin, podemos llegar a tener infinidad de ideas (que surgen de necesidades) que podrían realmente incrementar nuestra productividad a gran escala. Incluso quizás sean tan valiosas que la empresa podría generar mucho más dinero, al poder cumplir con los proyectos en mucho menor tiempo.
La creatividad es una cosa genial, pero hay que tener cuidado con la creatividad desmesurada. He visto casos donde han puesto a programadores Juniors a codificar generadores de código.... Obviamente todavía ni sabían cómo debía ser un código.
Pero sin irnos de tema, el foco del post se centra en cómo podríamos organizar nuestras ideas para que no se pierdan. Lamentablemente cómo obtener tiempo vamos a dejarlo para otro post.
Algo que se nos puede ocurrir en un principio es tener un archivo de texto donde anotamos todas nuestras ideas. Es lo más básico que podemos empezar a hacer. Sin categorizar y sin organizar. Anotamos nuestros pensamientos e ideas y las dejamos ahí, para un día poder volver a ellas y desarrollar las ideas que realmente veamos que nos van a servir.
Luego podríamos querer organizar mejor esas ideas. Por categoría, proyecto asociado, personas involucradas, tiempo que se debe invertir, etc. Una planilla de excel puede resultar mucho más cómodo para esto, y no requerimos ningún desarrollo de nada para tener este organizador de ideas. Perfecto! De repente ahora tenemos todo mucho más organizado.
Pero el día de mañana, cuando vemos que nuestra organización de ideas nos permitió avanzar con muchos proyectos y mejorar la calidad de nuestros productos, se nos podría ocurrir "Hey, y si hago que todos los empleados aporten sus ideas?". Y ahí creamos el nuevo proyecto "Organizador de Ideas", que podrá ser una aplicación web/winform aparte, o podemos incluirlo en alguna aplicación donde ya los empleados estén acostumbrados a usar (por ejemplo, una aplicación que distribuye las tareas).
Al principio lo extendemos a un sector (seguramente sistemas) pero como vemos que dá resultado lo empezamos a distribuir a toda la empresa. Tarde o temprano terminamos teniendo toda una gestión de ideas internas muy importante que (correctamente administrado) no sólo podría llevar a la empresa a un nuevo nivel, sino que también aumentarán la moral de todos y el apego a la empresa. "Mira Jimmy, aplicaron mi idea en el reporte de balance general!". Hoy en día lograr que las personas se queden en una empresa es muy difícil, y yo lo vivo también como empleado. El factor que más me afecta es no sentir que estoy haciendo algo que me importe. En otras palabras, no estar haciendo lo que nos gustaría hacer, o estar generando los cambios que nos gustarían.
Es el problema que tuve cuando trabajé en una empresa grande. Burocracia a montones, cero creatividad en los empleados compañeros, salvo excepciones, y cualquier cosa "loca" que pudiese crear sólo iba a ayudar a un puñado de personas, y realmente no podías hacer cambios importantes ni tomar decisiones. Esto es muy desmotivador.
Una correcta gestión de ideas podría cambiar completamente el futuro de la compañía. La genialidad viene de las personas, no de ningún proceso burocrático ni de ninguna galletita de la fortuna. Generalmente uno suele tener un gurú arriba del management que dicta la dirección de la empresa. Pero... ¿y si la empresa siguiera sus propias necesidades en todos sus niveles jerárquicos?
Obviamente debemos diferenciar una idea de un reclamo: "Arreglen el aire acondicionado" no es una idea, "Despidan a fulanito" tampoco lo es. Por ello las ideas deben ser gestionadas, filtradas, y debe llamarse la atención a aquellos que participen de forma negativa. Obviamente, puede ser que arreglar el aire acondicionado sea una buena "idea" porque mejoraría la productividad y moral de los empleados. Todo debe ser analizado.
Recordemos que yo siempre hablo desde la ignorancia. Lo mío son puras ideas lanzadas al blog. Pero me resulta interesante divagar por unos momentos.
Este fué un post simplemente para fomentar el pensamiento sobre este tema. No he visto empresas que gestionen las ideas y el pensamiento en sí (que es de donde surge el verdadero conocimiento), pero seguramente hay varias por ahí (seguramente grosas en sus rubros).
Otras veces, encontramos "chunks" de código que sabemos que podrían compartimentarse para reutilización en vez de repetir las mismas líneas de código una y otra vez. Ni siquiera estamos siendo pretenciosos de aplicar patrones de diseño y realizar una solución realmente profesional para la reutilización de ese código. No, simplemente queremos compartimentar ese comportamiento en otro lado para reutilizar, porque de por sí no tenemos tiempo para una solución profesional. Lo que es peor, muchas veces no tenemos ni siquiera de aplicar esa solución de compartimentación (Sea un método aparte, clase, etc).
Otras veces se nos ocurren modelos y clases que realmente nos podrían ayudar en el día a día, pero no estamos totalmente seguros de que sean la forma correcta, o sea que todavía son ideas que necesitan ser más pensadas.
A veces tenemos ideas para hacer aplicaciones pequeñas que nos ayuden en el día a día. Algo que nos permita grabar todos nuestros scripts de tsql que usamos para modificar la base de datos y que luego nos ayude para implementar en los demás ambientes y clientes, por ejemplo. Otro que nos genere código automático para todas nuestras tablas. Otro que tome las entidades de nuestros modelos y nos genere automáticamente nuestros ABM, ya sean ASPX o WinForms.
En fin, podemos llegar a tener infinidad de ideas (que surgen de necesidades) que podrían realmente incrementar nuestra productividad a gran escala. Incluso quizás sean tan valiosas que la empresa podría generar mucho más dinero, al poder cumplir con los proyectos en mucho menor tiempo.
La creatividad es una cosa genial, pero hay que tener cuidado con la creatividad desmesurada. He visto casos donde han puesto a programadores Juniors a codificar generadores de código.... Obviamente todavía ni sabían cómo debía ser un código.
Pero sin irnos de tema, el foco del post se centra en cómo podríamos organizar nuestras ideas para que no se pierdan. Lamentablemente cómo obtener tiempo vamos a dejarlo para otro post.
Algo que se nos puede ocurrir en un principio es tener un archivo de texto donde anotamos todas nuestras ideas. Es lo más básico que podemos empezar a hacer. Sin categorizar y sin organizar. Anotamos nuestros pensamientos e ideas y las dejamos ahí, para un día poder volver a ellas y desarrollar las ideas que realmente veamos que nos van a servir.
Luego podríamos querer organizar mejor esas ideas. Por categoría, proyecto asociado, personas involucradas, tiempo que se debe invertir, etc. Una planilla de excel puede resultar mucho más cómodo para esto, y no requerimos ningún desarrollo de nada para tener este organizador de ideas. Perfecto! De repente ahora tenemos todo mucho más organizado.
Pero el día de mañana, cuando vemos que nuestra organización de ideas nos permitió avanzar con muchos proyectos y mejorar la calidad de nuestros productos, se nos podría ocurrir "Hey, y si hago que todos los empleados aporten sus ideas?". Y ahí creamos el nuevo proyecto "Organizador de Ideas", que podrá ser una aplicación web/winform aparte, o podemos incluirlo en alguna aplicación donde ya los empleados estén acostumbrados a usar (por ejemplo, una aplicación que distribuye las tareas).
Al principio lo extendemos a un sector (seguramente sistemas) pero como vemos que dá resultado lo empezamos a distribuir a toda la empresa. Tarde o temprano terminamos teniendo toda una gestión de ideas internas muy importante que (correctamente administrado) no sólo podría llevar a la empresa a un nuevo nivel, sino que también aumentarán la moral de todos y el apego a la empresa. "Mira Jimmy, aplicaron mi idea en el reporte de balance general!". Hoy en día lograr que las personas se queden en una empresa es muy difícil, y yo lo vivo también como empleado. El factor que más me afecta es no sentir que estoy haciendo algo que me importe. En otras palabras, no estar haciendo lo que nos gustaría hacer, o estar generando los cambios que nos gustarían.
Es el problema que tuve cuando trabajé en una empresa grande. Burocracia a montones, cero creatividad en los empleados compañeros, salvo excepciones, y cualquier cosa "loca" que pudiese crear sólo iba a ayudar a un puñado de personas, y realmente no podías hacer cambios importantes ni tomar decisiones. Esto es muy desmotivador.
Una correcta gestión de ideas podría cambiar completamente el futuro de la compañía. La genialidad viene de las personas, no de ningún proceso burocrático ni de ninguna galletita de la fortuna. Generalmente uno suele tener un gurú arriba del management que dicta la dirección de la empresa. Pero... ¿y si la empresa siguiera sus propias necesidades en todos sus niveles jerárquicos?
Obviamente debemos diferenciar una idea de un reclamo: "Arreglen el aire acondicionado" no es una idea, "Despidan a fulanito" tampoco lo es. Por ello las ideas deben ser gestionadas, filtradas, y debe llamarse la atención a aquellos que participen de forma negativa. Obviamente, puede ser que arreglar el aire acondicionado sea una buena "idea" porque mejoraría la productividad y moral de los empleados. Todo debe ser analizado.
Recordemos que yo siempre hablo desde la ignorancia. Lo mío son puras ideas lanzadas al blog. Pero me resulta interesante divagar por unos momentos.
Este fué un post simplemente para fomentar el pensamiento sobre este tema. No he visto empresas que gestionen las ideas y el pensamiento en sí (que es de donde surge el verdadero conocimiento), pero seguramente hay varias por ahí (seguramente grosas en sus rubros).
Subscribe to:
Posts (Atom)