miércoles, 31 de diciembre de 2008

12 fuentes de competitividad en el siglo XXI

competitividad Saltando por allí caí en este post de Consultoría artesana en red en donde Julen (que tiene una buena experiencia sobre sus espaldas) resume en 12 las fuentes de competitividad de las organizaciones.

Hay muchas de estas listas, la mayoría llenas de frases vacías. Así que se las recomiendo especialmente para que no se les pierda en este mar de información en el que navegamos todos los días (estoy hecho un poeta hoy).

Los puntos son:

  • Sentirse más que una empresa.
  • Coger olas.
  • Dejar hacer.
  • Diseñar paracaídas.
  • Eliminar perfiles de puestos de trabajo (¡Ojo con esta, que no quiere decir despedir gente!).
  • Gestionar en Internet.
  • Conseguir diversidad interna.
  • Clientes y usuarios son parte de la organización.
  • Abandonar rápido.
  • Olvidar productos y servicios, una empresa trabaja con estilos de vida.
  • Trabajar en abierto (casi) todo.
  • No crecer, sino desarrollarse.

Todos estos puntos están desarrollados y comentados en la entrada original.

Lo que le pedimos a la facultad.

Corría el año '94, tenía 18 años, estaba terminando la secundaria en el Carlos Pellegrini y tenía que decidir qué hacer respecto a mis estudios universitarios: hacerlos, no hacerlos, qué carrera. Fui uno de los pocos que se anotaron para algunas reuniones de orientación vocacional. Éramos sólo dos con la tutora.

Si menciono todos esos datos es para intentar acercarle un reconocimiento a esa tutora cuyo nombre no recuerdo. Que todos los que han dedicado su tiempo a eso se sientan agradecidos de mi parte.

Sólo ahora, a la distancia, puedo entender qué tan importante fueron esas reuniones para mí. No sólo elegí mi carrera, decisión con la cual estoy más que conforme. Lo más importante, creo, fue el ajuste de mis expectativas con respecto a la carrera, antes de entrar a la facultad.

Digo esto porque durante las cursadas, luego en mi vida profesional y como ayudante, me es frecuente escuchar las mismas quejas respecto de la universidad. Digo "de la universidad" o "de la carrera" como institución o forma de aprendizaje, no de una universidad o carrera en particular. Creo que muchas de esas quejas parten de esperar de una carrera universitaria (podrían incluirse otros tipos de estudio) cosas que no puede dar.

Es repetida la frase "Fulanito es mejor (programador, analista, líder de proyecto, lo que sea) que Menganito y nunca fue a la facultad". Es que un diploma no pretende ni puede garantizar aprendizaje o conocimiento y mucho menos conocimiento actualizado.

De hecho una carrera no puede garantizar nada. Puede ofrecer, y está en cada uno tomar o no, y también cómo. Y "tomar" implica un esfuerzo activo. Otra de las frases, quejas o reclamos típicos: "eso no se dió en clase". Si el profesor es bueno tal vez no lo haya dado, pero seguramente lo ha mencionado, o más específicamente, incluido en los temas a evaluar. Esfuerzo activo implica tomar el tema, investigarlo, volver con preguntas, discutirlo, etc.

Y luego "no uso nada de lo que vi en la facultad" que tiene su raíz en una o dos situaciones: o esa persona no vio nada en la facultad, o luego no logró relacionar su trabajo con lo visto. Lo primero es, seamos sinceros, un poco imposible (¿nada? ¿en absoluto?). Es más fácil cargar contra la institución, sobre todo cuando la alternativa es responsabilidad propia.

Establecer una relación entre lo que la facultad ofrece y el trabajo profesional requiere y llenar los baches entre ambos es parte de ese esfuerzo propio necesario para ser un buen profesional.

Lo que sucede, arriesgo, es que cuesta superar el cambio de paradigma entre los primeros estudios (desde jardín de infantes hasta el final de la secundaria) y los universitarios. Algunos no lo hacen nunca.

En un principio estamos fuertemente guiados. Nos dicen qué hacer, se nos enseña mucho por repetición, o a través de ciclos guiados de prueba y error. Nuestra única responsabilidad es prestar el cuerpo (estar allí físicamente) y hacer lo que nos piden (léase: estudiar tal cosa, o hacer tal tarea). De a poco esas guías se van alejando de nosotros hasta que...

En la universidad desaparecen. Por lo menos en la mayoría de las materias que he cursado el profesor expone, da una guía de estudio o ejercicios, y se pone a disposición de los alumnos para dudas, correcciones, o lo que sea. Luego, al final, evalúa.

Me gusta decir en clase que la cursada es un carro del que los alumnos tienen que tirar para llevarlo a la meta. La iniciativa está de su lado. Puede haber algún empuje, un incentivo, un puntapié inicial. Pero cualquier intento de "empujar" por parte del profesorado termina, según lo que he vivido, en la repetición de una ceremonia que el alumno interpreta para aprobar y luego olvida.

¿Y qué es lo que ofrece una carrera? Algunas mejor otras peor, pero en esencia es sólo una base, conceptos iniciales. Digamos lo mínimo y un poco más para que luego, cuando sea realmente necesario, podamos investigar por nuestra cuenta.

Eso, contactos (que no es poco), diversidad de relaciones (cuando la hay, que es mejor), un idioma en común para comunicarnos mejor con otros profesionales (eso no se consigue fácil en ningún otro lado) y en nuestro caso -carreras de sistemas- una ventana a la vida profesional a través de la experiencia que podemos extraer de los profesores (digo extraer, vean dónde pongo la acción) que en su mayoría, además de dar clase, trabajarán en algo relacionado, o mediante pasantías o mecanismos similares.

Eso, y un papel que dice que por lo menos pudimos atravesar, de una manera o de otra, toda una serie de exámenes. En un principio, cuando estamos frente a alguien que no nos conoce salvo por esos papeles, y si nuestra experiencia no es precisamente deslumbrante, créanme, se vuelven importantes.

Pero nada es absoluto. No hay nada en una carrera que no se pueda conseguir por otras vías (experiencia, autoaprendizaje, todas las formas de iniciativa propia). Y hay que tener en cuenta que para muchas personas el método de una carrera universitaria no es el más adecuado a su propia personalidad, su forma de pensar y de aprender.

Esto último -para volver al principio y cerrar- es lo importante, y lo que obtuve de aquellas sesiones de orientación vocacional: conocer y estar más o menos seguro de que ésa era la forma de aprender que yo prefería.

Se las recomiendo a cualquiera que esté empezando, no importa qué tan seguro se sienta, de todas maneras no hay nada que perder.

martes, 30 de diciembre de 2008

WTF: Plataforma pro-salvación de VB (!?)

Vengo de leer Plataforma pro-salvación de Visual Basic .NET (SVB.Net). No quiero pelearme con nadie, pero... ¿realmente es para tanto?

Para aquellos a los que les de fiaca seguir el link, vamos a lo esencial, y cito:

[...] Para el que todavía no esté al tanto de la historia, durante la segunda semana de diciembre ha tenido lugar en Dallas el encuentro de desarrolladores DevConn4, en el que Matt Gretz, destacado miembro del equipo de VB.NET, hacía público el Roadmap que Microsoft tiene previsto para este producto, que no trae buenas noticias para la gran comunidad de desarrolladores en Visual Basic, y que provocó un revuelo impresionante tanto en la sala del evento como en la blogosfera y medios especializados.

Resumidamente, el Roadmap prevé la progresiva desaparición de Visual Basic, mediante un plan de migración que facilitará los desarrolladores pasar a C# en un plazo de tres años. [...]

En principio pongamos los pies en la tierra. Todo esto no implica que para 2012 VB muera abruptamente y todo aquel que desarrolle en ese lenguaje sea etiquetado de obsoleto y puesto de patitas en la calle. Valga como ejemplo la cantidad de programadores en tecnologías "viejas" (¡de hace más de veinte años!) que todavía son requeridos, y muy bien pagos por cierto. Así que si la discusión es por lo laboral, no le veo mucho sentido.

Es un problema el tema de las certificaciones, supongo. Pero para cualquiera que tenga un mínimo de conocimientos de programación, una certificación en VB es casi equivalente a una en C#... aunque reconozco que no sé hasta qué punto se "ablandan" los criterios en cuanto a certificaciones en las empresas que las requieren. Aquí los defensores pueden tener un punto, aunque de hecho ni es mencionado como problema.

Si la discusión es más "filosófica" (funcional, digamos), sigo sin entenderla. Tenemos dos lenguajes que, hoy en día, son prácticamente equivalentes. Me arriesgaría a decir, incluso, que si molestan sus pequeñas diferencias es porque uno a esta altura pretende escribir exactamente la misma serie de líneas de código con distintas palabras o símbolos en cada uno de ellos.

Si hablamos de gustos bueno, es otra cosa. Al que le gusta más VB le gusta más y no hay argumento en contra ni a favor de ello. Sobre gustos no hay nada escrito, como quien dice. Yo programaba en VB y luego pasé (forzosamente, no fue una elección) a C# y me gustó más, pero podría no haber sido así.

Pero a lo que voy es... es tan sólo un lenguaje. Si uno sabe programar, sabe programar y punto. Obviamente que la adaptación a un lenguaje específico cuesta, pero ¿tanto realmente?

Que se entienda, lo que me sorprende es esta "lucha por la supervivencia" no de VB en particular sino de un lenguaje de programación, que podría ser cualquiera. Me sorprende que alguien esté tan apegado a un lenguaje como para montar tremendo esfuerzo. Yo no lo haría ni por VB, ni por C# ni por ningún otro.

¿A uds. que les parece?

10 tipos de salario.

Del inefable 10 puntos... rescato este post, para reír o llorar:

  1. Salario cebolla: Lo ves, lo agarras… y te pones a llorar.
  2. Salario canalla: No te ayuda en nada, solo te hace sufrir pero no puedes vivir sin él.
  3. Salario humor negro: Te ríes para no llorar.
  4. Salario preservativo: Te corta la inspiración y te quita las ganas.
  5. Salario impotente: Cuando más lo necesitas te abandona.
  6. Salario dietético: Con este comes cada vez menos.
  7. Salario del ateo: Ya dudas de su existencia.
  8. Salario menstruación: Viene una vez al mes y dura tres días.
  9. Salario tormenta: No sabes cuándo va a venir, ni cuánto va a durar.
  10. Salario teléfono móvil: Cada vez vienen más chiquitos.

Los remito al post original para la yapa (hay uno más), y de paso se dan una vuelta por este blog que me gusta bastante.

¿De qué tipo es el salario de uds.?

lunes, 29 de diciembre de 2008

El valor de tu sitio web.

Me parece que entiendo la popularidad de WebValuer, una página que calcula el valor monetario de un blog o sitio: creo que sobrevalúa sistemáticamente. Según ellos...

Los linkeo por el piropo nomás.

Casi me olvido: visto en PuntoGeek.

Bad Usability Calendar.

Bad Usability Calendar: 12 consejos sobre lo que no debemos hacer al diseñar un front-end presentados con mucho humor.

Visto en webmaster libre.

A great place to work.

En mi oficina tenemos algunas frases recurrentes sobre Google: "¡Maldita sea, lo hicieron!", "Estos tipos hicieron un pacto con el diablo", "Bueno, sí, Google lo hace, pero ellos son Google", etc.

Tenemos otras dos que decimos bastante: "No abras esa puerta" y "No juegues a Dios". Esas valen para todos los mortales excepto para la gente de Google (si es que son mortales). Ellos son expertos en abrir puertas y jugar a ser Dios.

Ahora en serio. A veces les sale mal, por supuesto. De hecho, es probable que la mayoría de las veces les salga mal, pero sólo nos enteramos de sus éxitos y de algún que otro fracaso muy estrepitoso. Pero así es la innovación, el abrir puertas, ser Dios (en el sentido de crear algo que no existe). Cien fracasos para un éxito... ¡Pero qué éxito!

¿Cómo, cómo lo hacen? No tengo idea, si la tuviese probablemente estaría trabajando allí.

Y de pronto me dí cuenta de que ésa es la respuesta: si tuviese idea de cómo hacer esas cosas, trabajaría allí. O por lo menos lo intentaría. ¿Por qué? Porque Google ha logrado convertirse en la Meca para muchos (no todos, pero creo que casi) dentro de los negocios en los que participa.

¿Así que ése es el secreto? Tenemos tres factores de producción: capital, tierra y trabajo. El capital ya no es un problema para ellos (¿existe algo que no puedan comprar?), la tierra no es un factor influyente, queda el trabajo: la gente, las personas. Los mejores en su campo trabajando en un ambiente que favorece la innovación. No creo haber descubierto América con esto.

Para conseguir a los mejores han tomado un camino por el que ahora están transitando muchas empresas: marketing. Hace un par de días paseaba por el centro y vi en la puerta de un edificio de oficinas el logo de una empresa (no me fijé ni cuál era) y la frase "Great place to work".

Cada vez más empresas se han dado cuenta de que el camino es convencer a todo el mundo de que "éste es un gran lugar para trabajar". Todos deben creerlo saberlo. Así que hacen esas cosas que solemos ver en las campañas de marketing: la sala de juegos, los carritos, el cuasi-parque-de-diversiones, el 20% de tiempo para proyectos personales (que terminan siendo corporativos), las juntas de empleados, la cafetería...

Son grandes beneficios para el trabajador, sí. Pero creo que están más orientados a los de afuera que a los de adentro. Otro detalle: el proceso de selección. Enrevesado, delirante, casi caprichoso. Es que si todos pudiésemos entrar al paraíso éste ya no sería tan codiciado. Más de uno (me cuento) entraría aunque sea sólo para "probar", y para poder decir (y decirse): "Google me contrató".

Ahora, ¿será un "great place to work" realmente? Por las historias que se leen por allí, es como cualquier otro: a algunos les encanta, otros no terminan de encajar. Pero el hecho es que casi todos quieren probar, y de los que pasen el primer filtro técnico quedarán los que superen el período de "adaptación".

¿Qué es realmente un "great place to work" que además favorezca la innovación? Digo, ¿cuál es la esencia? Porque conozco de empresas con grandes beneficios (bonus, horarios flexibles, muchos proyectos, buen ambiente entre los compañeros...) pero que no lo son.

Se las dejo picando. No es que tenga opinión y quiera crear suspenso, sino que no lo sé realmente.

Por cierto... buscar "Great place to work" en Google.

Programación Genética: pintando estilo Darwin.

Jugando con programación genética, Roger Alsing creó un algoritmo que produce generaciones de imágenes a partir de polígonos semitransparentes y las selecciona de acuerdo a su similitud con una imagen determinada.

El resultado es sorprendente... creo que es más fácil mostrarlo que decirlo:

Imagen original Generación 151
Generación 1021 Generación 2015
Generación 4199 Generación 5663
Generación 10067 Generación 30600
Generación 116706 Generación 182927

Lo bueno es que ha liberado los binarios y el código fuente (ver enlaces al final). Les recomiendo bajar la aplicación (no requiere más instalación que copiarla en una carpeta), elegir una de sus fotos favoritas y probarlo ustedes mismos. Muy, muy interesante.

Enlaces del blog de Roger Alsing :

Y para una intro al mundo de la programación genética: Guía de Campo de la Programación Genética, por Carlos en La Singularidad Desnuda.

Vía Google Blogoscoped.

domingo, 28 de diciembre de 2008

Ahora en Twitter.

Finalmente caí en la tentación, creé mi cuenta en Twitter (@apanitsch) y pasé de la 1 a la 2 de Las 5 etapas de la aceptación de Twitter, que por cierto son:

  1. Negación: “Twitter me parece algo estúpido. A quién le importa lo que otra gente esté haciendo ahora mismo?”
  2. Presencia: “Ok, no entiendo por qué la gente lo adora, pero al menos me abriré una cuenta.”
  3. Vertedero: “Estoy en Twitter y lo uso para poner enlaces a mi blog y mostrar a la gente mis notas de prensa”.
  4. Conversación: “No posteo siempre material útil, pero uso Twitter para mantener auténticas conversaciones 1×1″
  5. Microblogging: “Estoy usando Twitter para publicar información útil que la gente lee y también converso con ellos 1×1 auténticamente”

Primeras impresiones: en principio gratamente sorprendido por la facilidad con que dí de alta la cuenta y logré actualizarla vía SMS (si bien es algo que no voy a usar hasta ver mi factura de teléfono). Esperaba que fuera bastante más difícil que eso. El widget para Blogger quedó bien sin necesidad de personalizarlo (por suerte, odio lidiar con elecciones de colores, letras y esas cosas), pueden verlo en la barra del blog.

Sin saber nada del mundo Twitter, pensé que sería más razonable para mí utilizar el e-mail. Mi segunda grata sorpresa fue lo rápido que encontré TwitterMail, dí de alta la cuenta y salió andando.

En menos de un minuto pasé a... "¿esto es todo?". Sin nada que postear se me ocurrió que podría volcar allí mis bookmarks en delicious, y ya que estamos avisar cuándo posteo en este blog... Tercera grata sopresa, un servicio para ambas cosas: twitterfeed.

Y... eso es todo por ahora, supongo. Parece que con todo esto me voy adentrando en la etapa 3 (vertedero).

Actualización: acabo de agregar TwitterGadget, con lo que pude integrarlo a mi cuenta en Gmail... muy bonito todo, sí, sí, sí.

Conclusiones: entiendo la gracia, es bastante increíble que algo tan simple la tenga, pero la tiene. Mucho le debe a la cantidad de usuarios y servicios bien establecidos en torno a ella.

Ahora sí, eso es todo. Muy lindo pero por ahora estoy mas sólo que Hitler en el día del amigo. ¿Recomendaciones de algo interesante para seguir?

Libros: Federico Frischknecht - Dirección Recursiva.

Una de mis últimas materias en la facultad fue Organización, a cargo de Pedro Basualdo (en la Facultad de Ciencias Económicas de la UBA, carrera de Sistemas, lástima que no encuentro algún sitio con información actualizada, si alguien lo conoce se agradece el dato), materia a veces criticada por algunos contenidos demasiado teóricos que costaba enlazar con el día a día.

Críticas que tenían su razón de ser, hay que reconocerlo. Recuerdo la sensación de "muy interesante, pero ¿y con esto qué?" con la que me quedé al terminar la cursada. No recordaba prácticamente ningún tema en particular, y sentía que no me había llevado nada en concreto.

Realmente mucho, mucho después (casi tres o cuatro años) algunas situaciones del día a día activaron un camino neuronal poco transitado que me condujo hacia ellos, y fue como una revelación.

Estoy hablando del terrible Federico Frischknecht con su Dirección Recursiva (ISBN 950-02-3624-9), uno de los libros más difíciles de entender con los que me topé, pero realmente increíble (hay un pequeño resumen referente al conflicto en las organizaciones a cargo del Lic. Guillermo Bilancio aquí).

El autor construye un sistema para representar la toma de decisiones en las organizaciones (una verdadera catedral), y lo utiliza luego para analizar sus elementos: el conflicto, el cambio, la crisis, la estrategia, etc.

Es (como toda construcción teórica) una herramienta, y ésto fue lo difícil de entender para mí en su momento. El libro no tiene recetas ni guías ni respuestas, sino un marco teórico para analizar a las organizaciones que tendremos que aprender a utilizar para que nos sea útil.

sábado, 27 de diciembre de 2008

Parallel Computing (paralelización) y el fin de un paradigma.

Apenas llevo leídos un par de posts y mojado los talones en este mar que es el término "parallel computing".

No es nada nuevo bajo el sol, salvo que... bueh, mejor cito que apenas estoy empezando con esto:

Hoy vengo a hablar de otra crisis que nos toca más directamente a los programadores: el fin de la Ley de Moore tal y como la conocíamos hasta ahora. No es que los microprocesadores vayan a dejar de doblar su potencia cada año y medio más o menos, sino que este incremento de velocidad va a dejar de ser transparente para los desarrolladores de software. Los desarrolladores tenemos nuestra propia crisis técnica. El crecimiento de velocidad va a venir de las mejoras en paralelización de los microprocesadores, no de las mejoras de velocidad de proceso en sí.

de ¡La broma ha terminado!, en La masa, el ladrillo, la bota, el bocadillo... (el resaltado es mío)

¡Ay si es cierto, la que se nos viene...!

viernes, 26 de diciembre de 2008

Jueguitos de viernes: Gravity Master.

Sigo llegando un poco tarde con los juegos, trataré de ponerme a tiro. Pero en compensación tengo uno de los más adictivos que postée (gracias a Cerebrado): Gravity Master.

El objetivo es tan simple como hacer pasar esa bolita negra por los puntos indicados. Para ello tendremos que crear formas sólidas y saber aprovechar bien las leyes de gravedad...

Yo ya lo terminé, pero viene con un editor de niveles... cuestión de buscar por ahí, ¿o alguien propone alguno?

Objetivos.

Un equipo tiene, por definición, objetivos. Pueden ser más o menos explícitos, y su cumplimiento en tiempo y forma más o menos vital para su existencia, pero los tiene.

Las personas también tienen sus objetivos, que no son los mismos. Si bien a veces (raramente, según mi percepción) coinciden, pensar que los objetivos de los integrantes del equipo son los objetivos del equipo mismo es, por lo menos, un poco naïf.

Para entender (o predecir) las posiciones y reacciones de una persona en un equipo chico o mediano (digamos, menos de 10 integrantes) podríamos pensar en cómo esa persona compatibiliza sus propios objetivos con los del equipo, ya sea modificando, posponiendo, priorizando o descartando unos u otros, en tanto le sea posible.

Las variables crecen. Deberíamos tener en cuenta la información de la que dispone esa persona y, por supuesto, el error. Es claro que a todos, en algún momento, nos sale el tiro por la culata.

Todo esto fue disparado por una frase sacada del contexto de una conversación ajena que me quedó dando vueltas. Iba más o menos así: "Si uno tiene un producto [de software] más o menos decente y un flujo de bugs más o menos constante, vendiendo barato y cobrando un abono por el mantenimiento, puede mantener una cartera de clientes y un rédito razonable por...".

Lo que me quedó (vaya uno a saber si el emisor de la frase -que no recuerdo quién era- estaba pensando en esto) fue "un flujo de bugs más o menos constante". Claro, en este esquema los errores son funcionales al proveedor del software, ya que con un producto estable el cliente puede verse tentado a abandonar el abono de mantenimiento y estancarse en determinada versión. Pero los errores no pueden ser terribles (el producto debe ser "decente") ya que más allá de cierto límite el cliente podría pensar que existen opciones mejores.

No sé qué tan común pueda ser la situación. El negocio del cliente debería ser muy estable, de modo que no requiera nuevas funcionalidades cíclicamente.

¿Cómo afectaría esto al equipo del proveedor del software?

A la empresa proveedora tal vez le interesaría tener un producto cerrado. Al fin y al cabo, tener un equipo de desarrollo para hacer mantenimiento es costoso, y es posible generar ingresos mensuales de otras maneras. O, mejor aún, concentrarse en expandir su base de clientes.

Pero a los integrantes del equipo tal vez no les interese tanto (y es por esto que comencé mencionando el tema de los objetivos). Al fin y al cabo si no se vislumbran ánimos de lanzar nuevos proyectos, su trabajo desaparece.

¿Estoy diciendo que los integrantes del equipo introducen bugs a propósito? No, esto sería un extremo realmente inusual. Nunca escuché nada parecido.

Pero sí he visto una tendencia a mantener el "status quo". Es decir, una tendencia a no trabajar en esas cuestiones de fondo que realmente solucionarían los problemas y dedicarse simplemente a introducir parches para cada situación puntual reportada.

Pongamos de ejemplo una situación de la que se habla mucho, y que tal vez cuadre: la claridad del código, la reutilización, la legibilidad, la simpleza... "esas cuestiones" que todo el mundo dice que son importantes pero...

Si mi objetivo individual es permanecer ("permancer y tanscurrir", diría) no tengo demasiado interés en hacer el código claro y sencillo para otras personas... No es que lo esté complicando a propósito, sino que producir código de calidad creciente no es un resultado inevitable de programar sino que implica un esfuerzo consciente y adicional para el cual no tengo incentivos.

Ahora, si mis objetivos individuales son otros: aprender, innovar, progresar en lo profesional, crear un producto de calidad superlativa o simplemente que sea mejor cada día, etc... La cosa cambia.

Releyendo, es notoria mi simpatía por los "innovadores" frente a los "permanecientes" (estas frases sólo pueden surgir en época de fiestas). Cierto. Pero que no se interprete que desmerezco a los segundos frente a los primeros.

¿Por qué una persona no querría innovar, aprender, progresar? No es necesariamente que no quiera, sino que dentro del equipo prioriza otros factores. O peor, que no encuentra la forma de hacerlo, o que el ambiente no es propicio, por lo que prefiere hacerlo en otro lado. Conozco excelentes profesionales que exprimen su creatividad en su actividad privada y en el trabajo simplemente "cumplen" para obtener un suplemento extra, del que esperan poder deshacerse en el futuro... ¿qué puede haber de reprochable en eso?

Nada, en mi opinión. Pero es común que "cumplir", "dedicarse a corregir lo reportado" esté mal visto. Vemos que en los anuncios de recursos humanos se requieren siempre personas "innovadoras, proactivas y... (un montón de palabras bonitas)" cuando no es lo que realmente se necesita... o lo que se quiere.

Así, tenemos situaciones conflictivas entre organizaciones o jefes y profesionales frustrados al ver que se descartan todas sus iniciativas o renuentes al cambio y la innovación, para el que no encuentran incentivos.

miércoles, 24 de diciembre de 2008

De vuelta.

Recién llegado de las vacaciones, para colmo enganchadas con estas semanas de fiestas... Desconexión absoluta, fuera de ritmo, de horarios. No tengo la más mínima idea de eso que llamamos "actualidad" (no me enteré ni del zapatazo a Bush), miles de post para leer en el reader... cuesta mover los dedos sobre el teclado, las ideas no llegan, las palabras no salen.

Pero con ganas y energías renovadas, eso sí. Rota la procrastinación del primer post, ¡a ponerse al día!

Felices fiestas para todos, nos estamos leyendo.

lunes, 1 de diciembre de 2008

¡Vacaciones!

Hoy empiezan oficialmente mis vacaciones. ¡Nos vemos en 3 semanas!

jueves, 27 de noviembre de 2008

Tipos de programadores.

Es genial la última de Sinergia sin Control. Si algún despistado no se ha suscrito a su feed, que lo haga ya mismo.

miércoles, 26 de noviembre de 2008

De desarrollador a líder de proyecto: desafíos de la gestión para el técnico recién ascendido.

¿Se puede liderar un proyecto de desarrollo de software sin conocimientos técnicos? ¿Son imprescindibles para la gestión, o sólo una ayuda? ¿Los mejores líderes son aquellos que ocuparon puestos técnicos en el pasado? ¿O los mejores son aquellos que han estudiado y ganado experiencia específicamente en la gestión, tal vez en varios rubros? ¿La gestión tiene nada, poco o mucho que ver con lo técnico?

Comencemos por dividir (arbitrariamente, claro está) a los líderes de proyecto en dos grandes grupos: los que llegan al puesto habiendo comenzando su carrera desde el lado técnico y aquellos que llegan comenzando desde del lado de la gestión de proyectos.

Los primeros (digamos "los gestores-técnicos") serían aquellos que comienzan como programadores y progresan naturalmente hacia líderes o referentes de su equipo.

Con el tiempo las funcionalidades bajo su responsabilidad son cada vez más amplias, el equipo cada vez más grande y eventualmente abandonan del todo la programación para dedicarse exclusivamente a la gestión de uno o varios proyectos.

Bajo su responsabilidad pueden caer ya no sólo programadores sino también analistas funcionales, testers, diseñadores, administradores de sistema, de base de datos, personal de mantenimiento, soporte al cliente, etc.

Los segundos (digamos "los gestores de carrera") serían los estudiantes de carreras como Administración o Gestión de Empresas, que comienzan ayudando en la gestión de proyectos (de cualquier tipo) y van progresando hasta alcanzar el liderazgo de uno.

Así que a la pregunta "¿se puede liderar un proyecto de desarrollo de software sin conocimientos técnicos?" yo respondo "sí, absolutamente".

Por supuesto que el gestor de carrera deberá tomar experiencia en el rubro, que como cualquier otro tiene sus particularidades, su jerga, sus recovecos. Dispone para ello de un marco teórico: sabe de métodos de estimación de tiempos, de seguimiento, de ajuste, de administración de recursos, de manejo de personas, de motivación, etc.

Tendrá que aprender cuáles son las diferentes etapas del desarrollo, las muchas posibilidades que existen para recorrerlas, sus ventajas y desventajas, cuáles son los requerimientos, los productos, los tiempos y el personal necesario para cada una de ellas.

Para el gestor técnico el salto es inverso y simétrico: conoce el rubro pero deberá aprender a tratar con personas, a motivar, a liderar, a coordinar más allá de lo técnico, a evaluar y negociar cuestiones económicas, políticas, emocionales.

Desde un lado o de otro se puede llegar a cualquier nivel de excelencia o chapucería.

Pero hay un tema. El conocimiento técnico ayuda, por supuesto, sólo si no se hace abuso de él. Obviamente, el único que puede presentar estas tendencias hacia el abuso del conocimiento técnico es aquel líder con un pasado como desarrollador, ya que tiene que ver justamente con ese origen.

¿A qué me refiero cuando digo tendencias hacia el abuso del conocimiento técnico? Es más fácil dar ejemplos que tratar de definirlo, así que invento algunos:

  • Imponer estimaciones de acuerdo a su conocimiento técnico. Pero ya no es él quien ejecuta las tareas (eso era antes), y puede que no acepte que los tiempos de su equipo ya no son necesariamente los que él hubiese presentado.

    Por otro lado, un gestor de carrera confía necesariamente en las estimaciones de su equipo, simplemente porque como él no puede evaluarlas técnicamente no puede discutirlas. Podrá negociarlas, requerir más esfuerzo o más recursos, pero jamás objetarlas en términos de "esto está bien o mal".

    Claro que el gestor de carrera puede imponer estimaciones. Como dije antes, a la chapucería se llega desde cualquier lado.

  • Reservarse la resolución de cuestiones técnicas y no transmitir requerimientos funcionales. Es un poco lo que comentaba en Requerimientos: cuando no son asteroides sino sólo polvo cósmico.

    Si el líder no controla su "corazoncito técnico", puede tender a resolver requerimientos y distribuir sólo directivas técnicas ("armar una base de datos así y asá") en vez de directivas funcionales ("hay que hacer un módulo de ventas").

    Pueden seguir la entrada referenciada para ver los problemas que (en mi opinión) ello ocasiona. Por otro lado, el gestor de carrera transmite sólo requerimientos funcionales ya que no conoce de soluciones técnicas.

  • Evaluar técnicamente al equipo de acuerdo a parámetros propios. Estos parámetros pueden estar obsoletos o no ser objetivos.

    Es el caso del líder de proyecto "del ciclo de vida" que evalúa "cantidad de líneas de código escritas".

    El gestor de carrera no cuenta con criterios propios para evaluar técnicamente al equipo por lo que deberá buscar parámetros objetivos: una opinión externa, una auditoría de código o similar.

    Buen momento para recalcar nuevamente lo de la chapucería: el gestor de carrera también puede confiar ciegamente en las capacidades técnicas de su equipo, o no preocuparse por ellas y evaluar sólo los resultados... hasta que todo colapsa como una cáscara vacía.

  • Desestimar nuevas herramientas, nuevos lenguajes, nuevas tecnologías. Tal vez por rechazo a perder del todo el control: si se adoptan nuevas tecnologías su conocimiento previo ya no se aplicaría al proyecto, por lo que perderá cierto grado de poder de decisión.

    Un gestor de carrera no tiene pretensiones de control técnico del proyecto. Sólo le interesará el rumbo funcional o de negocio, que es lo que cae bajo su responsabilidad.

  • Desestimar herramientas metodológicas o mejores prácticas de la gestión de proyectos, por considerarlas demasiado formales o informales, demasiado simples o complicadas, o simplemente inútiles.

    Una suerte de desprecio por la teoría del campo de la gestión de proyectos (que no es el propio), sobrevalorando las cuestiones técnicas frente a las administrativas.

    Al revés también se da: muchos gestores de carrera desprecian las tareas de codificación. Pero lejos de dañar al proyecto esto lo beneficia: cada uno a su trabajo.

Verán que todos los puntos tienen una raíz en común. En el fondo está mi propia visión del líder de proyecto: un profesional entre profesionales, un profesional de la gestión.

Una cuestión cultural, una estructura (tal vez en decadencia pero de todas maneras) muy extendida, ubica al líder de proyecto "por encima" de otros profesionales: programadores, técnicos en hardware, administradores de base de datos, etc.

Eso hace que a veces se olvide que el trabajo del líder es obtener y administrar a las personas y a los recursos, coordinar el trabajo en equipo y llevar las riendas de las negociaciones y gestiones necesarias entre el equipo y el exterior... (entre otros, claro).

El tema es, ningún profesional debería decidir en el campo del otro. Pensemos en estas situaciones: programadores decidiendo funcionalidades, líderes de proyecto imponiendo fechas en las que "tiene que estar todo", clientes requiriendo (caprichosamente) determinada tecnología, programadores haciendo testing, analistas funcionales diseñando reportes en SQL.

Son todas situaciones en las que un actor de esta comedia a la que llamamos "desarrollo" invade el terreno del otro. Es allí donde se originan los problemas.

Recordemos que el tema de este post fue: las tendencias, los sesgos que debe afrontar un técnico que deviene en líder de proyecto. No creo que ningún pasado X impida ser buen líder o que el mejor líder es aquel que estudió la teoría en una facultad. Otra vez: ambos caminos pueden conducir tanto a la chapucería como a la excelencia.

domingo, 23 de noviembre de 2008

Patos criollos: 20 desastres relacionados con el software.

En cuatro post de VariableNotFound... ¡y con más referencias al final!

Ideales para esgrimir como excusa cuando metemos la pata: "Mire, si le puede pasar a la NASA..."

Ah, por las dudas que algún despistado no entienda. Pato criollo = "cada paso una cag...".

viernes, 21 de noviembre de 2008

Juegos de viernes: Jelly Towers.

"¡Hoy es viernes! ¿Dónde estuvo mi juego? Eran las tres de la tarde y yo trabajando."

Qué costumbrista que es la gente... perdón, la verdad que lo tenía agendado y me olvidé de postearlo.

Tarde pero seguro, acá les dejo Jelly Towers, que tiene un objetivo bastante original: tenemos que alimentar a... no sé, unos gusanos, con gelatina.

Se complica que da calambre.

miércoles, 19 de noviembre de 2008

Frases: reciprocidad.

"No te trataré como una prioridad cuando me tratas como a una opción"

Visto en El pito doble por Cerebrado.

martes, 18 de noviembre de 2008

Guía para perplejos: primera vista al código en un nuevo trabajo y... ¡ups!

La anécdota es común, casi una leyenda urbana... cosas que a nadie le pasó pero a todo el mundo le contaron, y reza casi siempre en variaciones del siguiente tema:

"Durante las entrevistas de trabajo todo me pareció perfecto... se habló de implementar las últimas tecnologías y mejores prácticas, de innovación, de una rueda interminable de nuevos y desafiantes productos a implementar.

La gente con la que hablé me pareció de mucha experiencia en el rubro, sin miedo a admitir errores y con ganas de corregirlos a futuro, así que no dudé en cambiar de trabajo.

Ya en el primer día de trabajo, al bajar a detalle, a ver el código... ¡Horror..."

Luego viene una gran lista de WTF's vinculados al desarrollo de software (pueden buscar ejemplos divertidos en The Daily WTF): que tal cosa estaba horriblemente mal, que tal otra era directamente un delirio, que esto no se usa así y que lo otro no se usa asá, o que el jefe esto y el jefe lo otro... La historia en general finaliza con el protagonista huyendo despavorido sin mirar atrás.

Sin exagerar, creo que todos los que entran a un nuevo ambiente de trabajo o a un nuevo proyecto se encuentran con alguna que otra cuestión extraña, no del todo clara, o directamente... digamos... que está mal. Esto es normal, todo equipo tiene sus vicios o errores.

La situación puede ubicarse en una escala que va desde lo divertido a graves errores (siempre desde el punto de vista del ingresante) no ya puntuales, sino de concepto, tanto en el código como en el proceso, pasando por cuestiones que pueden llamarse "de criterio" donde se acepta una visión diferente a la propia sin estar de acuerdo, pero reconociendo sus razones.

La pregunta que propongo es ¿cómo actuar en un caso extremo? Lo que sigue a continuación es lo que yo hice (no "hice correctamente" sino simplemente "hice") e intentaría hacer, aclarando desde el vamos que nunca me vi en una situación así, extrema, donde "está todo mal" y "esta gente no sabe lo que hace y no entiende de razones".

Creo que lo primero y principal es ubicarse y bajarse del caballo, sobre todo si nos integramos a un desarrollo que ya está funcionando.

Es decir, desacelerar, bajar un cambio, no hacer declaraciones rimbombantes, explosivas ni mucho menos agudas o que puedan resultar hirientes para el autor o responsable de lo que se objeta. Creo que podría ser más absoluto: en principio, lo mejor es no decir ni dar a entender absolutamente nada.

¿Por qué? Vamos, reconozcamos que sería poco profesional de nuestra parte entrar a un equipo y declarar, luego de dos o tres días de trabajo "esto está todo mal". ¿Qué análisis pudimos realizar en ese tiempo? ¿Qué tanto pudimos saber en un par de días de las personas que lo hicieron, de cuándo fue y en qué circunstancias?

Así que el segundo paso es, simplemente, recabar información, conocer a las personas que nos rodean y entender cómo llegaron a eso. Todo, absolutamente todo en un desarrollo tiene su razón de ser. Obviamente los orígenes pueden no ser técnicos, pueden ser... digamos "históricos": tienen que ver con una historia que no conocemos y en la cual todavía no escribimos ni una coma.

Esta actitud pone a prueba el respeto al trabajo ajeno: podemos criticar, pero es una falta de respeto hacerlo sin conocer no sólo el problema (que puede que sólo nosotros estemos viendo) sino aunque sea un poco de su historia.

Después de un tiempo (que dependerá también de las urgencias del caso) sin que nos hayan preguntado explícitamente, se puede tantear a ver si una recomendación encuentra algún oído atento. Más que decir "esto está mal", es mejor enfocar las cosas por el lado de "se me ocurrió que podríamos cambiar esto y..."

Pueden pasar dos cosas: que seamos escuchados o que no. En el primer caso es un buen comienzo, independientemente de si "nos hacen caso" o no. Es decir, si alguien escucha y defiende "ese delirio", está bien. Es lo lógico. De a poco, cada vez con más confianza, se puede debatir o incluso pelear. Pero hay que tener en claro que para pelear hay que ganar cierta confianza.

Digresión (está bien escrito, ver RAE): en general no me peleo "mal" con mis compañeros de equipo, pero a veces pasa. Y pasa porque hay cierta confianza que permite pelearse de vez en cuando sin que eso sea catastrófico. Hasta diría que un equipo en el que no hay peleas es algo sospechoso. Si uno tiene una idea, la defiende. Y hay veces en que a uno o a otro se le suelta un tornillo o lo toma a personal (o era personal)... la vida sigue.

Está el tema del tiro por elevación: ¿qué pasa si sentimos que el problema está en una persona en particular? Puede ser un compañero, un líder de proyecto, un analista, un gestor, lo que sea. ¿Hablamos con su superior? Puede ser, nunca sin haber intentado por todos los medios debatir con él primero, y teniendo en cuenta que puede "salir mal", por lo que se vuelve más importante que nunca tener un planteo coherente, no agresivo, y una propuesta de solución.

Ahora, ¿qué pasa si realmente no vemos posibilidades de cambiar las cosas, o sentimos que no queremos hacer semejante esfuerzo? Bueno, nada. Alejarse. Buscar otro trabajo, cumpliendo lo mejor posible con la tarea que se nos asigna mientras tanto. Sin escándalos, y sobre todo, sin "tirar basura" a los que quedan para irse con un portazo, eso sólo habla mal de uno mismo.

Aclaro otra vez: que no conozco la verdad revelada, y que lo que creo o recomiendo surge más de mis errores que de mis aciertos. En el papel (o la pantalla) es todo muy fácil, pero la vida real es otra cosa. Supongo que lo único que se puede hacer en este tipo de situaciones muy complicadas es hacer el mayor esfuerzo posible.

lunes, 17 de noviembre de 2008

De la falta de visión del desarrollo profesional en las pymes.

Siempre trabajé en pequeñas y medianas empresas o emprendimientos de uno o dos socios. Aunque conozco de oídas la experiencia de la "gran consultora o empresa" por compañeros de facultad, trabajo y amigos, no es la mía. Tengo que aclararlo porque mis impresiones deben estar necesariamente sesgadas por esto.

Aclarado el punto, entramos en tema.

Es difícil que exista un Plan de Carrera institucionalizdo en una pyme. Es común que para programadores, analistas o integrantes de la rama de gestión el desarrollo profesional debe transitar otros caminos, más personales.

Esto implica estudios universitarios o cursos y certificaciones a los que la empresa puede aportar, por ejemplo brindando días para estudio o financieramente, pero la tracción tendrá que estar en cada uno. Quiero decir que no habrán ofertas institucionales, más bien hay que pedir, suplicar o exigir de acuerdo al caso. Y algunas veces la empresa entorpece más que ayuda al avance profesional.

Por otro lado, el desarrollo de software es un rubro que por su dinámica depende mucho del aprendizaje. Cuando no se aprende, cuando no se mejora o no se está al corriente de las tendencias y tecnologías, el estancamiento lleva al fracaso.

Esto es así en cualquier industria, por supuesto. Pero los cambios tecnológicos impactan más rápidamente en el desarrollo de software, por lo que el aprendizaje debe ser continuo. Actualmente es imposible decir que un producto, por más completo (funcionalmente) que esté, está "cerrado". La tecnología avanza a paso acelerado, los clientes y usuarios demandan funcionalidades impensadas hace apenas un par de años, y la competencia es feroz.

Así que las pymes tienen el difícil compromiso de crecer junto a los profesionales que la integran. Es esto o la rotación constante, o el estancamiento. En mi experiencia, la norma ha sido la rotación o el estancamiento.

Por rotación se entiende que alcanzado un punto, se percibe que:

  • No hay espacio para crecer: la estructura institucional es pequeña y los puestos escasos.

  • No hay recursos: el día a día no da tregua y no hay presupuesto para más personal que alivie la carga de trabajo dando espacio a la investigación y experimentación.

    Los profesionales son constantemente tentados con ofertas de otros proyectos y la empresa no puede retenerlos.

  • No hay una visión que dé importancia al aprendizaje y la innovación: en realidad, éste punto está en el origen de los otros dos, porque cuando existe una clara visión de aprender e innovar se buscan los medios, y usualmente aparecen.

    Pero de todas maneras, con o sin visión institucional, los profesionales del área crecen. Y cuando no hay una visión se encontrarán con que han crecido más que la empresa, o que para crecer tienen que buscar otros destinos.

Aunque parezca contradictorio, creo que en una pyme la rotación ayuda. Evita el estancamiento. Obliga a la empresa a depender un poco menos de las personas y apoyarse un poco más en los procesos... o morir. Es bueno apoyarse en las personas, pero me parece que la norma en una pyme es el completo desbalance en este sentido. Es la clásica imagen del trabajo descordinado, desordenado e ineficiente (aunque muchas veces creativo) de estas empresas.

La partida de un socio, gerente o trabajador estrella en una pyme es un momento de crisis. Habrá que ver si los procesos (los que existan) soportan la pérdida de conocimiento que ello implica y si se logran captar profesionales que logren cubrir el espacio y mejorar.

Es decir, si la empresa sobrevive a la rotación, se verá fortalecida. Habrá superado una etapa en la que muchas fracasan.

En todo caso, obliga a la empresa a hacer lo que por falta de visión no hace de manera ordenada: cambiar, mejorar, mantenerse al día con la tecnología.

Decía al principio, rotación (con aprendizaje o muerte) o estancamiento. El estancamiento se da cuando la falta de visión hace que los profesionales que crecen se alejen, quedando siempre los más conservadores y reacios a los cambios. Si la sangre nueva no logra cambiar las cosas la rotación continuará en un proceso de selección natural en el que queden sólo los más conservadores, fortaleciendo la tendencia. El mercado decidirá cuánto puede durar esta situación.

Imagino que por aquí está la clave del conflicto constante en las pymes. El desarrollo, el aprendizaje, no es parejo, no es ordenado, se da aleatoriamente. Programadores estancos en una tecnología determinada, un un líder de proyecto "del ciclo de vida", un gerente conservador, pueden asfixiar lenta y discretamente a una pyme. Cuanto más arriba más difícil el cambio, pero no importa dónde, el conflicto será permanente.

viernes, 14 de noviembre de 2008

Frases: malicia e incompetencia.

Nunca atribuyas a la malicia lo que puede explicarse por la incompetencia.

Napoleón Bonaparte.

Juegos de viernes: Gold Miner

Gold Miner es un juego simple y terriblemente adictivo, perfecto para restarle un día de trabajo a la semana.

Parece sencillo pero se complica rápidamente...

El viejazo.

Alguna vez comenté que de un tiempo a esta parte estoy medio sensible a los viejazos (ver aquí y aquí). Para que quede claro, definí "viejazo" más o menos así:

Uno de esos momentos en que algún manejo de fechas medio desprolijo devuelve un resultado que en principio sentimos como un "way out of range" pero que después se valida.

Bueno, me acaba de pasar. Pero esto es más que un simple viejazo. Esto es como una bofetada:

(Foto de Kirk Weddle, visto en Alt1040)

Me parece imposible que alguien no sepa qué es, pero por las dudas:

¡Es el mismo flaco! A ver, yo compré ese disco cuando estaba en el secundario, un poco antes de que explotara la cosa. Nunca fui gran fanático (es el único disco de ellos que escuché con atención), pero fui a verlos (no me gustó demasiado)... quiero decir... ya era "grande" cuando ese pibe, que ahora es bastante "grande" era un bebé...

No somos nada.

jueves, 13 de noviembre de 2008

Pedrito (el líder de proyecto) y el lobo: la importancia del feedback.

Todos conocen la historia de Pedro y el lobo. Por las dudas se las refresco:

<spoiler>

Pedro era un pastor que se divertía gritando que venía el lobo sólo para molestar a la gente del pueblo, que corría inútilmente a ayudarlo. Hasta que finalmente vino el lobo. Pedro gritó pero como lo había hecho tantas veces en broma nadie le creyó... Las versiones varían: en el cuento infantil se dice que el lobo se comió unas ovejas, yo digo que también atacó a Pedro y lo dejó inválido y deforme para toda la vida.

</spoiler>

A veces sucede algo por el estilo en el desarrollo de software: se establece una fecha difícil (mas no imposible) de cumplir, la presión se hace sentir, el equipo hace un esfuerzo extra, se trabaja a las apuradas, a deshoras, se llega a tiempo o no, y luego... nada.

¿Nada? Sí, nada. Ni para bien ni para mal. Nada si se ha cumplido o alguna suerte de reprimenda o discurso sobre la responsabilidad, la confianza y los compromisos asumidos, si es que no. La vida sigue, el desarrollo continúa, se agregan funcionalidades, se corrigen errores... la presión desaparece...

Supongamos que ésa es la situación percibida, ¿cuál es el origen? Si no tenemos más información hay que inventarla. Inventemos. Me imagino tres escenarios, que se pueden ir completando a placer:

  1. La fecha límite fue artificialmente establecida para "meter presión" al equipo. La creencia subyacente puede ser que la gente se "relaja" cuando no tiene un límite de tiempo, se pierde en detalles o simplemente vaguea.

  2. La fecha era real, pero poco importante. No hay un cliente comprometido ni socios desesperados. El líder apunta que (a ojo de buen cubero) no está tan lejos de "quedar bien" hacia arriba terminando justo a tiempo (o un poco antes) si presiona hacia abajo. O tal vez era un hito interno en su línea de tiempo, y exagerar la importancia de esas fechas es su manera de tener las riendas cortas.

    Así que presiona. Si llega mejor, y se olvida de bajar las felicitaciones (o no las hubo, porque esto puede suceder a cualquier nivel). Si no se llega aparece el discurso un tanto licuado y abstracto mencionado más arriba, porque al fin y al cabo no hay una gran mala noticia.

  3. El límite existe, y sí era importante.

    Una posibilidad es que el líder haya utilizado su cintura para "zafar" de la situación y todo pasó de largo.

    Otra posibilidad es que, intentando "resguardar" al equipo de presiones excesivas, actuó como paraguas y no bajó el escarmiento.

En resumen: la fecha no existía, o sí pero no era importante, o sí pero el equipo no se enteró de las consecuencias.

Independientemente del origen o las causas subyacentes, si la comedia anterior se representa un par de veces los integrantes del equipo reaccionan como los habitantes del pueblo: simplemente se vuelven inmunes a las fechas límite y renuentes a hacer cualquier esfuerzo extra para cumplirlas.

Esta reacción es esperable, incluso la más lógica y, desde el punto de vista del equipo, la más sana. La experiencia les ha enseñado que esforzarse por alcanzar esas fechas no tiene ningún beneficio, ni su incumplimiento consecuencia alguna.

Es terríblemente difícil salir de esta situación sin un hito desagradable (como sería para Pedro aparecer sin un brazo o una pierna) o costoso (Pedro podría perder algunas ovejas), un golpe de efecto. Se necesitaría, por ejemplo, la pérdida de un cliente o la aparición de un bonus por cumplimiento de la fecha de entrega. Desagradable o costoso. Malo o menos malo (desde el punto de vista de la empresa), malo o bueno (desde el punto de vista del equipo).

Pensemos en cómo el feedback, en cualquier caso, modifica las cosas (cada punto es el correspondiente a la situación mencionada arriba):

  1. Por más que la fecha establecida sea "artifical", proporcionar feedback demuestra preocupación por el estado del proyecto, conciencia de su estado, monitoreo constante. Es decir, demuestra la importancia que se le asigna, el interés que tiene para el líder. Sea este interés ficticio o no, motiva. O por lo menos no desmotiva, como sí lo hace una fecha que luego pasa prácticamente desapercibida.
  2. Si la fecha es poco importante, se aplica el mismo razonamiento del punto anterior. Podemos además agregar que la fecha alguna importancia tiene. Si es importante para el líder puede ser importante para el equipo. Por ejemplo, quedar bien hacia arriba es un beneficio que se multiplica al ser extendido a cada uno. ¿Por qué no hacerlo?
  3. Si la fecha era realmente importante, es tal vez el peor caso. Los motivos para el compromiso están, pero no son transmitidos. No es raro notar la falta de éste.

En todo caso, la ausencia de feedback sólo puede dar indicios negativos: poco interés en el proyecto o presión acumulada en "algún lado" o manipulación grosera y finalmente inútil (BTW: ¿"manipulación" es "motivación grosera" por definición?), un líder ausente o... no perfecto (para decirlo políticamente).

Un líder de proyecto tiene muchas tareas y atribuciones. Pero para un equipo de profesionales todas pueden resumirse en una: establecer un medio en donde la información fluya, ya sea comunicando o facilitando u obligando a los demás a comunicarse, en todas la direcciones.

Hay mucho que comunicar en un proyecto de software: los requerimientos, las restricciones, los recursos, los avances, las novedades, los cambios, todo. En un equipo de profesionales, un líder no impone sino comunica... bueh, esto dependerá también de qué tan profesional sea el líder ¿no?

El hecho es que siendo un sistema de comunicación (ver artículos relacionados), cualquier problema de comunicación en un integrante del equipo, y más en el lider, es muy problemático.

Sobre esto último, algunos relacionados:

La autopista del desarrollo.

Una clase sobre buenos modales.

Comunica... ¿QUÉ?

Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir.

Problemas eléctricos...

Andamos con problemas eléctricos en la oficina, así que quería recordarles a mis compañeros de trabajo (y a todo el mundo) que...

Frases: procrastinador profesional.

Me gustan las fechas límite. Me encanta el zumbido que producen al pasar de largo.

- Douglas Adams

Visto en Microsiervos.

miércoles, 12 de noviembre de 2008

Frases: información.

Si tienes información, úsala. Si no la tienes, búscala. Si no la encuentras ¡inventa!

- No sé de quién es (¡ayuda!)

Factores de motivación.

Llego un poco tarde, así que supongo que algunos ya habrán leído Motivación - La lista, de tictac.

En este post ordena los resultados de una propuesta de armar una lista de "elementos que os motivan, motivaron u os motivarían como empleados".

Creo que se ha armado un buen resumen, con el que coincido muchísimo:

  • Confiar en las personas que tengo alrededor.
  • Transparencia y comunicación.
  • Empleabilidad (yo diría "usabilidad").
  • Flexibilidad, variedad y movilidad.
  • Gozo intelectual.

Son sólo los títulos, los detalles aquí.

Un artículo mío más o menos relacionado, aquí.

martes, 11 de noviembre de 2008

Frases: siempre hacia delante.

Jamás retrocedas. Sólo da media vuelta y sigue avanzando.

Programar es sólo escribir.

Hace un tiempo, en Codificando... divagando... es lo mismo comentaba qué era lo que pasaba por mi cabeza cuando programaba... mejor dicho, cuando escribía código, que no es lo mismo. Tenía curiosidad por saber si mi forma de escribir código era "rara" o "normal":

[...] Y es que no, no estoy pensando si se entiende por ello el buscar una solución a un problema, o el buscar algo en la memoria. Más bien estoy en un estado parecido al de este mismo momento (ésa es la idea que me llamó la atención). Estoy escribiendo, como quien escribe un documento, una carta, o lo que sea. Y como todo autor, le escribo a un lector imaginario (¡en serio!) [...]

Hoy me encuentro en Coding Horror con Coding: It's Just Writing, en el que se comenta un poco el mismo paralelismo entre la escritura de código y la escritura, a secas.

Me agendo para leer un artículo de Donald Knuth al que se hace referencia, Literate Programming (sugerente, el título):

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.

lunes, 10 de noviembre de 2008

Frases: Admitir los errores.

Un hombre nunca debe avergonzarse por reconocer que se equivocó, que es tanto como decir que hoy es más sabio de lo que fue ayer.

Swift, Jonathan

Codificación: datos de la aplicación como recursos XML embebidos (parte IV).

Parte I: Resumen.

Parte II: La definción del archivo XML.

Parte III: Encapsulamiento.

Parte IV: Que funcione.

IV. Que funcione.

Ya tenemos nuestras clases de definición de menú alimentadas por un recurso incrustado en el ensamblado, ahora vamos desde el front-end.

Dejemos Form1 para pruebas. Agregamos un nuevo formulario: frmPrincipal, y en él un TreeView, trvMenu. El código del formulario será:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;

namespace EjemploRecursosXMLEmbebido
{
    public partial class frmPrincipal : Form
    {
        public frmPrincipal()
        {
            InitializeComponent();            
            CargarMenu(Menues.Raiz, this.trvMenu.Nodes);
        }

        private void CargarMenu(MenuItem definicionMenu, TreeNodeCollection contenedor)
        {
            TreeNode menuNodo = CrearNodo(definicionMenu);
            foreach (MenuItem definicionSubmenu in definicionMenu.Submenues())
                CargarMenu(definicionSubmenu, menuNodo.Nodes);

            contenedor.Add(menuNodo);
        }

        private TreeNode CrearNodo(MenuItem menu)
        {
            TreeNode nodo = new TreeNode();
            nodo.Text = menu.Titulo;
            nodo.Name = menu.Id;

            return nodo;
        }


    }
}

Son solamente dos procedimientos: CargarMenu, que recorre recursivamente la estructura de definiciones de menú y CrearNodo, que es una función que crea el nodo correspondiente a cada definición de ítem de menú.

Dejé para este momento el tema "que haga algo" para ejemplificar las bondades del encapsulamiento del XML en esta manera.

¿Qué sucede cuando seleccionamos alguna opción en el menú? Por lo pronto, nada. Lo lógico sería que de alguna manera se visualice el front-end de la funcionalidad correspondiente. Necesitaremos algunas definiciones extra para avanzar.

Sólo a modo de ejemplo (no me gusta mucho cómo queda), implementaremos el front-end de cada funcionalidad como un UserControl. Así que colocamos un SplitContainer (splitContainer1) en el formulario. Éste lo divide visualmente en dos controles Panel (splitContainer1.Panel1 y splitContainer1.Panel2). En splitContainer1.Panel1 colocamos trvMenu. En splitContainer1.Panel2 cargaremos un UserControl creado dinámicamente cuando el usuario haga click en un ítem del menú.

Comencemos con sólo dos funcionalidades del menú: Compras/Presupuestos y Compras/Ordenes.

Primero, agregamos dos nuevos UserControl al proyecto: uscComprasPresupuestos y uscComprasOrdenes. Pongamos cualquier cosa dentro de ellos. Yo he puesto simplemente un Label con el nombre de la funcionalidad.

Segundo, agregamos código al evento NodeMouseDoubleClick en frmPrincipal para que cargue el control correspondiente de acuerdo al menú que ha recibido el evento:

private void trvMenu_NodeMouseDoubleClick(object sender, TreeNodeMouseClickEventArgs e)
{
    UserControl frontendUC = null;
    switch (e.Node.Name)
    {
        case "compras_presupuestos":
            frontendUC = new uscComprasPresupuestos();
            break;

        case "compras_ordenes":
            frontendUC = new uscComprasOrdenes();
            break;
    }

    //si no tiene front end asociado no hace nada
    if (frontendUC == null)
        return;

    //si ya hay un front-end cargado, lo eliminamos.
    if (this.splitContainer1.Panel2.Controls.Count > 0)
        this.splitContainer1.Panel2.Controls.RemoveAt(0);

    frontendUC.Dock = DockStyle.Fill;
    this.splitContainer1.Panel2.Controls.Add(frontendUC);

}

Este código tiene un switch en el que se selecciona el control correspondiente de acuerdo al nombre del nodo (recordemos que habíamos asignado a cada nodo un nombre igual al id del menú en su definición en el archivo XML). Si no hay un UserControl asociado al menú no hace nada. Si lo hay, elimina el correspondiente a la opción anteriormente seleccionada y crea el nuevo, colocándolo en splitContainer1.Panel2.

Probemos... ok, funciona (por lo menos en mi máquina funciona).

A algunos la solución les parecerá buenísima... ¡manos a la obra! ¡Ya tenemos la estructura de la aplicación, ahora a programar funcionalidad! Hay como 200 funcionalidades que implementar, son 200 controles por crear, así que ¡rápido!

A otros la solución les hará un poco de ruido... "qué incómodo ese switch... por más que tengo los datos del menú en XML, sigo teniendo que agregar la línea que crea el UserControl... no es como crear el nodo a mano en diseño, pero... bueno, empecemos y veremos qué pasa".

Otros con más experiencia verán que ese switch va a convertirse en un problema, y ni hablar de cuando los menúes empiecen a "moverse" por los cambios estéticos y de funcionalidad... ¿quién mantendrá eso ordenado y legible dentro de un par de meses, con 200 o más entradas case, y probablemente con muchas "de basura"?

En realidad, en este momento no es demasiado importante la actitud a tomar. Pero en un par de meses será fundamental. Créanme, ese switch va a ser un problema. Si alguen lo detecta ahora, bien. Si lo corrige, mejor. Pero dentro de un tiempo, si no se corrige va a crecer transformándose en algo muy feo.

En la próxima entrada de la serie veremos una de las soluciones posibles para aislar al front-end de los problemas del crecimiento y los cambios en el menú.

Parte I: Resumen.

Parte II: La definción del archivo XML.

Parte III: Encapsulamiento.

Parte IV: Que funcione.

domingo, 9 de noviembre de 2008

Test: ¿Qué lenguaje de programación es?

En Name that code se nos presentan algunas líneas de código y tendremos que responder de qué lenguaje de programación se trata.

No me fue mal... 75%. aunque saqué varias por descarte.

Name That Code
Created by OnePlusYou - Free Dating Site

Las personas: el activo de las empresas... no.

Un poco a cuento de las cuestiones laborales sobre las que venía reflexionando, dos perlitas:

1) Yoriento referencia una frase vista en el blog de Escolar, atribuída a "Eusebi Cima, vicepresidente de Fomento del Trabajo (la patronal catalana) y presidente de la patronal Fepime, sobre las ayudas de 1.500 euros para los empresarios que contraten a parados con cargas familares":

"Desgraciadamente, lo que necesitamos son ayudas para despedir a la gente. Hay un ajuste de mercado, una crisis muy grave, se está generando desocupación y no puestos de trabajo. Ahora no es el momento de crear este tipo de ayudas."

2) Un extracto (muy iluminado, a mi entender) del blog de Javier Llinares (no tiene relación directa con el punto 1):

Yo no estoy de acuerdo en que las personas sean el mejor activo que tienen las empresas, ni siquiera estoy de acuerdo en que las personas sean un activo de las empresas, ya que si fuesen algo que poner en el balance, en lugar de en la cuenta de resultados, creo que lo que serían es un renting.

Las personas son un activo para ellas mismas, nunca para las empresas, ya que para que algo sea considerado un activo, tiene que existir cierto nivel de posesión, y naturalmente las personas solo se pertenecen a ellas mismas.

El resaltado es mío. Les recomiendo el artículo completo.

sábado, 8 de noviembre de 2008

Qué significa NINJA en "Crisis NINJA".

Voy a deschavar (con alguna vergüenza) mi desconexión absoluta de la actualidad en estos días (que no de la realidad, que es bien diferente) y de paso hacer un favor a quienes no se atrevían a preguntar.

Acabo de leer en el blog de Javier Llinares Salas, por primera vez, el significado de NINJA, término que ha estado dando muchas vueltas estos meses:

NINJA = No income, no job, no assets, es decir que un ninja es una persona que no tiene ingresos, no tiene trabajo y no tiene propiedades.

Un rayo de luz al interior de mi zócalo...

viernes, 7 de noviembre de 2008

Gestión del tiempo.

No quisiera que esta joyita se perdiera entre los links de "lo que leo":

La teoría de gestión no sirve para los proyectos importantes.

"Las cosas realmente importantes de la vida, ni se pueden elegir, ni se pueden medir".

Jueguitos de viernes: Assembler.

Assembler es un juego de ingenio bastante original, en el que tenemos que arreglárnoslas para colocar unas cajas en los espacios indicados... no es tan fácil como parece...

Un poco corto para mi gusto, deja con ganas.

Máxima seguridad.

Espero que el afán de aumentar la seguridad en mi oficina no llegue a esto...

Visto en The Daily WTF.

jueves, 6 de noviembre de 2008

Codificación: datos de la aplicación como recursos XML embebidos (parte III).

Parte I: Resumen.

Parte II: La definción del archivo XML.

Parte III: Encapsulamiento.

Parte IV: Que funcione.

III. Encapsulamiento.

Con lo que tenemos hasta aquí ya podríamos armar nuestro menú de ejemplo copiando y pegando el código de prueba que tenemos y modificándolo para recorrer los datos de acuerdo a las necedidades del caso.

Pero hay un tema extremadamente importante que aclarar antes de seguir: cuidado con XML. Podemos definirlo y utilizarlo muy fácilmente, y así de fácil se nos puede ir de las manos. Ya he comentado algunos ejemplos en este blog:

  • XML * Inconciencia.
  • XML (donde comenzaba con la muy acertada frase: "XML is like Violence, if it doesn't solve the problem, use some more").
  • Pobre XML.

XML es una muy buena herramienta para guardar los datos, pero nunca, nunca jamás (créanme) accedan directamente a ellos desde toda la aplicación.

En este sentido son asimilables a una base de datos: no accedemos a ellos creando una conexión y los objetos necesarios para ejecutar un comando SQL en cada módulo, clase o procedimiento en el que los necesitamos. Siempre creamos una capa de datos que puede ser más o menos compleja y con más o menos funcionalidades de acuerdo al caso, pero nunca, nunca accedemos a ellos directamente.

Las razones principales son:

  • Claridad del código.
  • Si cada vez que deseamos obtener información de un menú hacemos

    
    //......
    
                string resourceName = "EjemploRecursosXMLEmbebido.Menu.xml";
                
                XmlDocument menuesXML = new XmlDocument();
                using (Stream s = this.GetType().Assembly.GetManifestResourceStream(resourceName))
                {
                    menuesXML.Load(s);
                }
    
    //.... (etcétera)...
            
    

    Estaremos ensuciando el procedimiento con todo este montón de cuestiones acerca de los recursos, los streams y demás que dificultan la lectura.

  • Mantenimiento.
  • Imaginemos que utilizamos el código anterior en muchas clases de nuestro proyecto. El simple hecho de cambiar el nombre del recurso implicaría buscar la cadena "EjemploRecursosXMLEmbebido.Menu.xml" por todos lados y reemplazarla.

    Es fácil cometer errores al utilizar XPath. Tal vez no todos los programadores del equipo están familiarizados con él. En cada acceso podría cometerse un error diferente.

  • Mejoras, nuevas funcionalidades, reutilización.
  • Veremos que hay mucho para mejorar en la utilización de recursos XML. Las posibilidades son muchas y usualmente iremos aprendiendo sobre la marcha, a medida que surjan las necesidades. Por ello es que necesitamos tener encapsulado el acceso, para poder modificarlo sin que el resto del sistema se vea afectado.

Espero haberlos convencido. Si es así, estarán dispuestos a crear un par de clases que encapsulen el recurso y lo hagan invisible al resto de la aplicación.

Examinemos la estructura de cada nodo que representa un ítem del menú:

<menu id="compras">
  <titulo>Compras</titulo>
  <submenues>
    <!-- lista de elementos menu con la misma estructura-->
  </submenues>
</menu>

Podemos crear una clase (MenuItem) que encapsule ese nodo y exponga los datos que contiene como propiedades:

using System;
using System.Collections.Generic;
using System.Xml;

namespace EjemploRecursosXMLEmbebido
{
    public class MenuItem
    {
        XmlNode _nodo;

        public MenuItem(XmlNode nodo)
        {
            _nodo = nodo;
        }

        public string Id
        {
            get { return _nodo.SelectSingleNode("@id").InnerText; }
        }

        public string Titulo
        {
            get { return _nodo.SelectSingleNode("titulo").InnerText; }
        }

        public IEnumerable<MenuItem> Submenues()
        {
            XmlNodeList submenues = _nodo.SelectNodes("submenues/menu");

            foreach (XmlNode menuNodo in submenues)
                yield return new MenuItem(menuNodo);

        }

    }
}

Y otra clase que nos dé acceso al recurso (Menues):

using System;
using System.Xml;
using System.IO;
using System.Collections.Generic;

namespace EjemploRecursosXMLEmbebido
{
    public static class Menues
    {
        private static XmlDocument _menuDocument;
        private const string _resourceName = "EjemploRecursosXMLEmbebido.Menu.xml";
        
        static Menues()
        {
            _menuDocument = new XmlDocument();
            using (Stream s = typeof(Menues).Assembly.GetManifestResourceStream(_resourceName))
                _menuDocument.Load(s);
        }

        public static MenuItem Raiz
        {
            get { return new MenuItem(_menuDocument.SelectSingleNode("menu")); }
        }

    }
}

Ya estamos listos para otra prueba. Colocamos un nuevo botón sobre el formulario, cuyo código será:

        private void button2_Click(object sender, EventArgs e)
        {
            foreach (MenuItem menuItem in Menues.Raiz.Submenues())
            {
                MessageBox.Show(menuItem.Titulo);
            }
        }

Vemos que ahora, para nuestro front-end de pruebas, el XML simplemente no existe, ni siquiera "sabe" que es un recurso XML. Simplemente solicita a la clase Menues el menú raíz y recorre sus submenúes mostrando el título.

Pero seguimos sin tener un menú como la gente. Paciencia...

Parte I: Resumen.

Parte II: La definción del archivo XML.

Parte III: Encapsulamiento.

Parte IV: Que funcione.