Cambiando de trabajo

Hoy miércoles 30 de Abril del 2008, luego de 3 años y dos días exactamente, renuncio a mi empleo, a mi primer empleo.

Hace bastante que estoy descontento con varios aspectos de la empresa, entonces comencé una búsqueda y recibí una oferta de un puesto que me interesaba mucho y acepte.

Realmente estoy muy emocionado por esta nueva oportunidad, por conocer nueva gente, por aprender más, que es lo más importante, y sentirme valorado y contento en lo que hago. Realmente trabajar es algo que te tiene que gustar. Yo ya no sentía ganas de ir a trabajar todas las mañanas, y si pasa eso, hay algo que no funciona. Estoy confiado en que voy a poder aprender mucho en mi nuevo trabajo, y recuperar las ganas de trabajar.

Estoy sintiendo una inmensa cantidad de emociones a la vez. Estoy triste por no ver más a mis compañeros, eso es lo que más me cuesta, la gente, las costumbres, las relaciones laborales y las amistades que forme en estos tres años. Igual soy positivo, confío en que en el mundo hay más gente buena que mala, que vamos para adelante y que voy a encontrarme con un grupo muy bueno.

No estaba contento con el aspecto profesional en mi trabajo, además de temas éticos que no viene al caso mencionar. Al haber terminado los proyectos más importantes, no fui asignado a ningún otro proyecto que me interesase. También nunca estuve de acuerdo al 100% con los líderes de desarrollo en muchos temas, debido a que no compartía su idea de la formación de los equipos de desarrollo y no sentía que apreciasen mi tipo de perfil no técnico para encarar los proyectos y comunicarme con los clientes. No tenia a nadie de quien aprender en la empresa, con mi mismo perfil. Igual no puedo negar que aprendí un montón en esos tres años, mucho gracias a la gente de la empresa, y también a los clientes, uno de los cuales se convirtió en mi ‘coach’ y compartí varios proyectos con él, del cual tuve el lujo de recibir innumerables aprendizajes.

Espero con ansias empezar el nuevo trabajo el 2 de Mayo del 2008, encontrar nuevos desafíos, hacer amigos y fundamentalmente aprender mucho, pero mucho!

Email BugMeNot - Instant Disposable Email - Bypass Compulsory Registration

En un proyecto de creación de una librería de software donde era necesario realizar investigación de archivos, era necesario suscribirse a sitios y/o foros para obtener información sobre los archivos. Debido a que la necesidad de entrar a cada sitio o foro era única generalmente, era muy incomodo recibir luego información de estos sitios luego, ya que se llenaban las casillas de basura.

La solución implementada fue utilizar BugMeNot, un mail instantáneo que lo perdés en 24 horas. Para comenzar creas una cuenta en la página de BugMeNot, simplemente llenando un dialogo. Luego ingresas ese mail que te creo en la página donde uno quiere registrarse, y finalmente recibís en la página de BugMeNot el mail.

Muy útil para que tu mail no quede subscripto en lugares innecesarios, que luego pueden llegar a vender sus bases de datos a spammers.

Entreprise Architect

Una herramienta de modelado para UML que me recomendaron años atrás y sigo usando en la actualidad es Enterprise Architect. Realmente es muy buena, tiene muchas opciones y aunque la interfaz no sea muy amigable ni el comando 'undo' no siempre funcione como uno espera (Estoy hablando de la versión 6.0, pero la 7.1 ya esta disponible), este programa completísimo y flexible en lo que uno puede hacer con los diagramas.

Se las recomiendo a cualquier persona que tenga que armar diagramas UML. Bajá una versión completa de evaluación acá.

Diez Errores típicos de los Estadounidenses al escribir en inglés

Este interesante artículo comenta diez errores típicos del idioma inglés. Aunque el inglés no es mi lengua nativa, me sentí muy identificado con varios de ellos, como también sorprendido porque en varios no tengo problemas. Por ejemplo, me cuesta distinguir entre it's o its, pero nunca me confundiría con their y they're, pero una persona del proyecto en el cual trabajé en Estados Unidos lo hizo varias veces. Se los dejo acá:

1. Loose for lose
No: I always loose the product key.
Yes: I always lose the product key.

2. It’s for its (or god forbid, its’)
No: Download the HTA, along with it’s readme file.
Yes: Download the HTA, along with its readme file.
No: The laptop is overheating and its making that funny noise again.
Yes: The laptop is overheating and it’s making that funny noise again.

3.They’re fortheir for there
No: The managers are in they’re weekly planning meeting.
Yes: The managers are in their weekly planning meeting.
No: The techs have to check there cell phones at the door, and their not happy about it.
Yes: The techs have to check their cell phones at the door, and they’re not happy about it.

4.i.e. for e.g.
No: Use an anti-spyware program (i.e., AdAware).
Yes: Use an anti-spyware program (e.g., AdAware).
Note: The term i.e. means “that is”; e.g. means “for example.” And a comma follows both of them.

5.Effect for affect
No: The outage shouldn’t effect any users during work hours.
Yes: The outage shouldn’t affect any users during work hours.
Yes: The outage shouldn’t have any effect on users.
Yes: We will effect several changes during the downtime.
Note: Impact is not a verb. Purists, at least, beg you to use affect instead:
No: The outage shouldn’t impact any users during work hours.
Yes: The outage shouldn’t affect any users during work hours.
Yes: The outage should have no impact on users during work hours.

6. You’re foryour
No: Remember to defrag you’re machine on a regular basis.
Yes: Remember to defrag your machine on a regular basis.
No: Your right about the changes.
Yes: You’re right about the changes.

7. Different than for different from
No: This setup is different than the one at the main office.
Yes: This setup is different from the one at the main office.
Yes: This setup is better than the one at the main office.

8. Lay for lie
No: I got dizzy and had to lay down.
Yes: I got dizzy and had to lie down.
Yes: Just lay those books over there.

9. Then for than
No: The accounting department had more problems then we did.
Yes: The accounting department had more problems than we did.
Note: Here’s a sub-peeve. When a sentence construction begins with If, you don’t need a then. Then is implicit, so it’s
superfluous and wordy:
No: If you can’t get Windows to boot, then you’ll need to call Ted.
Yes: If you can’t get Windows to boot, you’ll need to call Ted.

10.Could of, would of for could have, would have
No: I could of installed that app by mistake.
Yes: I could have installed that app by mistake.
No: I would of sent you a meeting notice, but you were out of town.
Yes: I would have sent you a meeting notice, but you were out of town.

Tipos de Líder

Un jefe surge por nombramiento, un líder surge por medio del reconocimiento de un grupo. El Gerente de Proyecto debe ser un líder: una de sus responsabilidades es definir y comunicar la Visión del Proyecto y ayudar a su equipo a llegar a ella.

Existen tres tipos de líder: el Líder Democrático, el Líder Laissez-Faire ("Dejar Hacer"), y el Líder Autocrático.

¿Cómo se comporta un Líder Democrático? Decide las cosas consultando a su equipo, pero mantiene el control. Esto es visto por su grupo como una valoración por el individuo, pero a veces el Líder Democrático es percibido como una persona insegura. ¿Cuándo es bueno? Cuando hay tiempo para analizar las opciones ante una decisión.

¿Cómo se comporta un Líder Laissez-Faire? Ejerce poco control sobre los miembros del equipo. Esto inspira libertad de acción y creatividad, pero a veces genera poca motivación y deja el grupo a la deriva. ¿Cuándo es bueno? Cuando el grupo es maduro, responsable y esta altamente motivado, o cuando tiene habilidades y talento muy altos.

¿Cómo se comporta un Líder Autocrático? Domina a los miembros de su equipo por medio de la coerción, de la influencia y del poder. Esto genera una resistencia pasiva por parte del grupo. ¿Cuando es bueno? Cuando hay que tomar decisiones urgentes, apremiantes, cuando hay situaciones límite.

Es erróneo pensar que alguna de las tres formas de Liderazgo es incorrecta. Es incorrecta si se la aplica el 100% del tiempo: siempre se debe tener presente que en un proyecto existen diferentes situaciones, y que cada una exige una actitud diferente para resolverla.

Un buen Gerente de Proyecto debe identificar claramente estos tres tipos de liderazgo y saberlos utilizar (!los tres!) en todas las escenas del proyecto.

Personalmente me siento mas identificado con un líder democrático.

Este artículo lo saque de Mejores proyectos, el Blog de IAAP. Altamente recomendable

Trac: Página para informar sobre el acceso al repositorio

Trac es un software de administración de proyectos web con una interface a un repositorio Subversion. (Ya describí trac en un post anterior: leer)

Es bueno informar en el wiki de Trac, el acceso al repositorio a todos los interesados del proyecto. Sobre el tema de accesos, se puede crear el mismo par de usuario/contraseña para el repositorio y para el Trac, pero también pueden ser distintos.

En esa página del wiki debe informar la URL del repositorio, clientes para bajarlo e instrucciones. Por ejemplo:

To access this project's source code, first of all you need to download and install Tortoise SVN from http://tortoisesvn.sourceforge.net/ if you are using Windows, or ZigVersion if you are using Mac, from http://zigversion.com/

Install the program and then create the following folder in your hard disk: "C:\" or anywhere else you'd prefer. Right click over that folder, click on "SVN Checkout", and in the field titled "URL of repository", enter the following URL: http:///

Finally click on Ok. You will be asked for a username and password, use your TRAC user and pass. The source code will be downloaded to the directory. The procedure may take some time.

La filosofía de Google

Una lectura muy interesante es la filosofía de Google como empresa. Les dejo las diez conclusiones a las que ha llegado Google:

1. Lo más importante es pensar en el usuario (Focus on the user and all else will follow)
2. Es mejor especializarse en algo y hacerlo realmente bien (It's best to do one thing really, really well)
3. La velocidad es un valor seguro (Fast is better than slow)
4. La democracia en la web funciona (Democracy on the web works)
5. No tiene por qué estar en su despacho para obtener una respuesta (You don't need to be at your desk to need an answer).
6. Es posible obtener ingresos actuando de forma ética (You can make money without doing evil)
7. Es imposible abarcar toda la información disponible (There's always more information out there)
8. La necesidad de información supera todas las fronteras (The need for information crosses all borders)
9. Es posible ser profesional sin llevar traje (You can be serious without a suit)
10. No nos conformamos con unos resultados estupendos (Great just isn't good enough)

Mas detalle sobre cada una de ellas en los siguientes enlaces, en inglés o en castellano.

Ocho consejos para pasar de jefe a líder

Los jefes se nombran, los líderes surgen. No es lo mismo ser el jefe de un grupo que ser su líder. Estas recomendaciones ayudan a un jefe a ser un buen líder de su equipo:

Respeta diferencias de personalidad y diferencias de habilidades. No todas las personas tienen las mismas habilidades, por lo que no puede exigirse el mismo rendimiento a cada uno de los miembros de un equipo. Un buen líder debe conocer las habilidades de cada integrante del equipo y tiene que ser capaz de determinar cuánto puede esperar de cada uno.

Reconoce la contribución de cada miembro del equipo. Cada uno aporta a su manera, pero debe aportar. Una vez que se haya logrado el objetivo grupal, el líder debe reconocer y señalar la contribución que haya hecho cada uno. De esa forma cada persona no sólo estará contenta por el logro grupal, sino que también se sentirá motivada por su aporte individual.

Calendario para clientes y miembros del equipo de un proyecto

Una excelente práctica que llevo a cabo en mi trabajo es tener un calendario, donde se informan las fechas de vacaciones, días de estudio o exámenes, feriados nacionales y entregas o fechas importantes para un proyecto.

Obviamente que para que este calendario sea relevante tiene que estar disponible para todos los miembros del equipo y todos los interesados del proyecto, en tiempo real.

La solución tecnológica adoptada inicialmente fue un calendario Google. Todos los interesados tenían acceso y podían crear los eventos y estos estarían disponibles para todos, mediante notificaciones por email, RSS, o la interfaz de Google.

Esto funciono sin problemas hasta que surgió la necesidad de mantener a varios clientes, varios proyectos, y recursos que compartían uno o más proyectos.

La solución adoptada fue un calendario en Microsoft Sharepoint 2007. Realmente no soy amigo de Sharepoint, pero encontré útil esta funcionalidad de calendario. Se pueden crear grupos de usuarios y cada entrada en el calendario puede ser configurada para uno o más grupos. Esto permita que un recurso cargue por ejemplo un día de examen solo en un calendario, y elija a los receptores (los clientes de los proyectos asignados a él). También, un cliente no ve fechas de entrega de otros proyectos, que no tienen porque estar disponibles para él.

Los desarrolladores también son usuarios

Les quería recomendar este artículo donde se fundamenta muy bien la recomendación de pensar, cuando construís código, en todos los usuarios: también los próximos programadores que tengan que depurar tus líneas.

“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it”

Gracias Ignacio Rodríguez por compartir esto!

Cuando justificar el texto en informes para clientes

Un día tuve una discusión amigable con un compañero del equipo, ya que teníamos que entregar un informe y yo quería justificar el texto y el no. Finalmente recurrimos a nuestro mentor, Jeffrey, y el nos dijo lo siguiente:

I am pro and con. I think that large blocks of text should always be justified, i.e. pages and pages without breaks like chapters in a novel. However, for short blocks or blocks that are frequently broken by headings, then justification makes it less legible. But the factual answer is look at your client's documents that they generate internally and see what justification they're used to reading.

Sabio consejo.

Les recomiendo leer el siguiente articulo sobre este tema, que pareciera no ser muy importante, pero hay que tener en cuenta en muchos ámbitos: Rules of Desktop Publishing for Text Alignment

Cambiando la forma de trabajar con un cliente

En la empresa donde trabajo, en una época hubo un contrato con una empresa para la cual se le suministraban doce desarrolladores y ellos estaban en contacto cliente con los líderes del cliente, que estaban en Estados Unidos.

Esta modalidad de trabajo fracaso, debido al bajo nivel de inglés de los desarrolladores, a la baja capacidad de comprensión que tenían ante los pedidos del cliente, y a las expectativas fallidas sobre el conocimiento o seniority del equipo de desarrollo.

Ese proyecto no fracaso del todo, ya que los clientes eligieron solo dos desarrolladores, tal vez no los mejores, pero si los que estaban siempre, los bomberos en realidad.

El problema fue la forma con que se encaro este contrato. Darle contacto al cliente a desarrolladores sin experiencia no fue buena idea.

Les dejo parte del mail donde proponía una nueva forma de trabajo luego de la reducción de personal pedida por el cliente, ya que me pidieron a mí que diera una charla de buenas prácticas y de trabajo organizado a los que quedaron afuera, para que entren en otros proyectos:

Luego de dar la charla y escuchar el “feedback” de los chicos, estuve pensando una forma de que lo de este cliente llegase a funcionar, aunque no sé si es tarde. El tema importante es que todos los procesos presentados son muy lindos y todos más o menos los entendieron, pero necesitan a alguien que los guie en su uso, los aliente y los ayude.

En mi humilde opinión, me parece que lo mejor sería tener un PM local, que se abstraiga de todas las tareas de desarrollo (esto lo recalco y me parece muy importante), y sea el punto de contacto de los PMs del cliente, para que ellos minimicen o completamente anulen el contacto con los desarrolladores.

Además de ser el dueño de los requerimientos y tener una idea general de todos los sitios, crearía una base de conocimiento de todos estos proyectos, en trac podría ser, y alentaría y ayudaría a los desarrolladores que lo ayuden a llenarlo, con cualquier cosa que pueda hacerle la vida fácil a alguien en el futuro que tenga que arreglar algo o agregar nueva funcionalidad en el sitio.

Otra de las ventajas que tendría esto, seria aislar a los desarrolladores de las dudas y tareas que mandan los PM del cliente,, ya que escuche que a veces no están muy al tanto de lo que hacen. Esta persona, podría filtrar estas cosas, evitando posible retrabajo en el futuro. También seria alguien que se comiese la presión de los PMs, para que el equipo de desarrollo este más tranquilo. Digamos que transmitiría las tareas con tranquilidad y cordialidad, y seria alguien que defienda al equipo de desarrollo.

Tal vez esto sea muy caro y el cliente no lo acepte, pero hay que hacerles entender que tendrían una “knowledgebase” muy importante de todos sus proyectos, y otras cosas como métodos, passwords, etc. Supongo que es una posible solución.

La historia continua con que el cliente contrato unos rusos, y están muy contento con su desempeño. Se mantuvieron a los dos desarrolladores acá, pero no se logro aumentar el tamaño del equipo.

Problemas que trae una nueva versión de un sistema operativo para un producto masivo

Experiencias de mi vida laboral - Problemas que trae una nueva versión de un sistema operativo para un producto masivo

Cuando estábamos desarrollando el software de "Software Asset Management/License compliance", sufrimos la salida de SQL Server 2005 y luego de Windows Vista. Digo sufrimos porque realmente hubo que cambiar mucho en un proyecto que ya estaba prácticamente cerrado.

Este producto tenía como destinatarios a cualquier empresa, y tenía sus requerimientos de sistemas operativos, y funcionaba con SQL Server 2000 o MSDE 2000 (Microsoft SQL Server Desktop Engine 2000), la versión gratuita y limitada del gestor de bases de datos de Microsoft.

Ni bien salió el SQL Server 2005 (acompañado por el SQL Server 2005 Express, la evolución del MSDE), tuvo que cambiarse el software para soportar esto, no solo porque los clientes lo pedían, sino porque luego salió el Windows Vista, que no puede correr MSDE.

Hay que tener en cuenta las plataformas existentes y futuras en la planificación de un proyecto, ya que los cambios pueden afectar mucho la fecha de entrega y la carga de trabajo a llevar a cabo. Espero que no me pase más esto, porque recrear los instaladores, cambiar toda la documentación e incluso interfaces del producto con la base de datos, manejar luego soporte sobre dos versiones distintas de un programa ya listo no es tomado con alegría por el equipo, y menos por la empresa que no lo planifico desde un principio.

Acá les dejo parte del mail de un cliente quejándose (con buena razón) por la falta de soporte a SQL Server 2005:

As far as SQL Server 2005 support is concerned, I'm surprised you guys haven't leveraged one of your customers who are using the product with SQL 2005 to help provide some instructions on how to make it work. We are a small operation with only 23 computers, but we upgraded to SQL 2005 because of the vast performance gains. 90% of my friends in the IT sector have also
upgraded their workplace to 2005 as well.

I hope you can receive my construction criticism about the install process. I may have expressed my frustration excessively, but I do hope there is something positive in that for you.

Thank you again for your quick response. Please let me know if you release a version which is compatible with SQL Server 2005 or come up with an instruction document on how to make this work with it.

Aplicacion de procesos en otras Areas

Una vez en el trabajo no entregaron los recibos de sueldo por unos meses y llegue a averiguar quién era el responsable por el retraso, y era uno de los socios. Le comunique que era importante entregarlos y se comprometió a hacerlo, pero esto no me pareció suficiente, porque no es la primera vez que sentía ese retraso, entonces le conté mi opinión en el siguiente mail:

Me alegro que entreguen los recibos, pero no me parece suficiente.

Me enseñaron que cuando hay un problema, lo que hay que hacer es un informe con lo siguiente:

1) Causa del incidente

2) Medida tomada para arreglarlo

3) Medidas a tomar para que no pase nunca más algo de esta índole.

Estaría bueno que mandes un mail a toda la empresa indicando los puntos 1 y 3, ya que el 2 lo conocemos todos (fue que firmaste los recibos). Podes poner que estabas muy ocupado y lo dejaste pasar, o lo que haya pasado en realidad. Luego, tendrías que instaurar un proceso para que no se te olvide mas, no creo que mi área sea procesos de administración, pero puedo ayudar.

Tal vez te parezca que es mucho, que un problema de un cliente se merece ese esfuerzo, y esto no es tan importante. Pero en realidad lo es, la cosa es que se viene hablando de esto hace bastante, es una preocupación más que sentíamos todos. Vos una vez que defendí a unos proveedores, me dijiste que cuide mas a la gente interna. Si escribís algo como lo te sugiero y creas un proceso para que eso nunca pase de nuevo, estarías cumpliendo con lo que vos dijiste.

Tal vez algún día, el mercado u otras cuestiones nos lleven a que tengamos que entrar en algún tipo de certificación seria de calidad. Para eso, la organización tiene que empezar a adoptar procesos, y para que esto funcione, ustedes tienen que dar el ejemplo y cambiar la mentalidad de trabajo, sin perder de vista estas cosas, que son detalles, pero ayudan al correcto funcionamiento del sistema.

Saludos,
Martin

Obviamente que esto puede parecer atrevido, pero en la organización tenían en cuenta mis quejas y eran bienvenidas porque su objetivo era mejorar.

Inspecciones de Software

Una práctica interesante que aprendí en la facultad y aun no pude aplicar formalmente en mi vida profesional son las inspecciones de software.

Podemos ver a las inspecciones de software como un repaso detallado y formal del trabajo en proceso. Pequeños grupos de trabajadores (4 o 5) estudian el "producto de trabajo" independientemente y luego se reúnen para examinar el trabajo en detalle. El ""producto de trabajo"" representa código, requerimientos, diseño y otros productos de trabajo son inspeccionados. Los productos de trabajo son considerados en progreso hasta que la inspección y las correcciones necesarias estén completas. Se realiza un seguimiento sobre todas las inspecciones.

Los objetivos principales son identificar errores, aumentar la productividad, reducir costos y mejorar la calidad del software. Realmente le veo bastante futuro a este método, aunque hay que superar las dificultades para utilizarlo, ya que es visto como un gasto innecesario de tiempo, pero está comprobado que rinde sus frutos.

Lee más sobre inspecciones acá.

Discurso de Steve Jobs en la ceremonia de graduación de la universidad de Stanford

El 12 de junio del 2005, Steve Jobs, el CEO de Apple y de Pixar dió un discurso en la ceremonia de graduación en la universidad de Stanford. Les recomiendo que se tomen unos minutos para ver el video o leer el texto, realmente vale la pena por el mensaje que transmite. Es inspirador y muy motivante.

Leer el texto del discurso acá.

Stay Hungry. Stay Foolish.

"Email etiquette" y política de emails en una empresa

En las comunicaciones laborales, uno de los tipos más importantes y más menospreciados es el email. Realmente creo que una buena utilización de esta herramienta es fundamental para cualquier empresa o persona que utiliza el email como medio de comunicación. Les dejo las 32 reglas del sitio emailreplies.com, el cual les recomiendo consultar para obtener más información sobre el tema.

1. Be concise and to the point

2. Answer all questions, and pre-empt further questions

3. Use proper spelling, grammar & punctuation

4. Make it personal

5. Use templates for frequently used responses

6. Answer swiftly

7. Do not attach unnecessary files

8. Use proper structure & layout

9. Do not overuse the high priority option

10. Do not write in CAPITALS

11. Don't leave out the message thread

12. Add disclaimers to your emails

13. Read the email before you send it

14. Do not overuse Reply to All

15. Mailings > use the bcc: field or do a mail merge

16. Take care with abbreviations and emoticons

17. Be careful with formatting

18. Take care with rich text and HTML messages

19. Do not forward chain letters

20. Do not request delivery and read receipts

21. Do not ask to recall a message.

22. Do not copy a message or attachment without permission

23. Do not use email to discuss confidential information

24. Use a meaningful subject

25. Use active instead of passive

26. Avoid using URGENT and IMPORTANT

27. Avoid long sentences

28. Don't send or forward emails containing libelous, defamatory, offensive, racist or obscene remarks

29. Don't forward virus hoaxes and chain letters

30. Keep your language gender neutral

31. Don't reply to spam

32. Use cc: field sparingly

Este sitio también recomienda que la empresa tenga una política de emails para obligar a tener en cuenta estas reglas. Leer sobre la creación de una política de emails acá.

Finalmente, unos tristemente graciosos comics de Dilbert sobre el tema:

Teniendo en cuenta la accesibilidad en programas de distribución masiva

Cuando ayudé a desarrollar el producto de "Software Asset Management/License Compliance", teníamos que diferenciar en una lista de computadoras, con cuales había actividad y con cuales no (y los distintos grados de actividad).

La primera idea que surgió fue crear un código de colores, aplicar estos a la lista de computadoras y crear un dialogo con una leyenda, indicando el significado de cada color. Esta idea era apropiada y todos los miembros del equipo estábamos satisfechos con la solución a proponer.

Cuando la presentamos nos llevamos una sorpresa, ya que el líder de proyecto la rechazó por no ser accesible para personas que no podían diferenciar los colores. Nunca se nos hubiese ocurrido que podía llegar a ser rechazada por ese tema; todo el equipo aprendió del incidente. Una columna indicando el estado solucionó el tema.

Estamos todos muy acostumbrados a ver las opciones de accesibilidad en Windows, seguro que muchos jugaron con ellas, pero no habíamos tenido eso en cuenta para nuestro trabajo en desarrollo de software.

Zen and the Art of Motorcycle Maintenance: An Inquiry into Values

Esta novela filosófica no es realmente un libro de software, pero si un libro sobre la calidad, tema altamente relacionado con el desarrollo de software. Fue escrito por Robert Pirsig y según el libro Guiness fue el libro filosófico más leído en todo el mundo (fue traducido a 27 lenguas). Este libro fue recomendado en la materia "Calidad En Desarrollo De Sistemas" de la facultad.

Fue uno de los libros más interesantes que leí, dejándome con una sensación indescriptible y un entendimiento sobre la calidad mucho más profundo y completo.

En el libro, el autor explora el significado y los conceptos de la calidad (un término que para él no se puede definir). Se contrasta a dos tipos de personas, los románticos (los que ven el lado externo de las cosas) y los clásicos (los que necesitan saber el detalle). Al principio se alinea con los clásicos, pero luego se da cuenta que es necesario un entendimiento de los dos puntos de vista sobre las cosas. Entiende que lo que trae aparejado la tecnología y la deshumanización del mundo parece repulsivo para un romántico. El puede ver la belleza de la tecnología y se siente a gusto con las tareas mecánicas. El mantenimiento de una moto puede ser tedioso y aburrido o excitante y apacible; todo depende en la actitud y la paz interior, o la falta de ella.

Este libro es altamente recomendable para cualquier persona, sea cual sea su profesión.

The Ethics of Belief

El libro "Waltzing With Bears: Managing Risk on Software Projects" que recomendé anteriormente (Leer) contiene un fragmento de un ensayo de William K. Clifford de 1987 para comenzar a tratar el tema de riesgos

Este ensayo nos cuenta la historia del dueño de un barco que cree que no va a poder hacer otro viaje por inconvenientes técnicos. Igualmente deja al barco partir porque se hace creer a si mismo que fue es un barco muy confiable durante toda su vida. Luego se presentan dos escenarios, que hubiese pasado si llegaba el barco a destino, o que hubiera pasado si el barco se hubiese hundido.

En ambos casos, él es culpable, aunque nadie hubiese muerto, él hubiese sido igualmente culpable, solo que si se hubiesen salvado, el no hubiese sido encontrado, porque corrió el riesgo igual sin prepararse. No importa que pasó al final.

¿No sienten lo mismo cuando hacen software? Si no manejamos los riesgos, cuando nos retrasamos sufrimos las consecuencias, cuando no nos retrasamos, tuvimos suerte, pero somos igualmente culpables del manejo del proyecto.

Para expandir el tema y leer más detalles, les recomiendo que lean el ensayo acá.

Distintas perpectivas de un producto de software

La siguiente imagen muestra las distintas perspectivas de un producto de software, dependiendo de quién sea uno. Altamente interesante visión de esta triste realidad.

(Hagan click sobre la imagen para verla completa y poder leer las leyendas)

Waltzing With Bears: Managing Risk on Software Projects

Este libro sobre administración de riesgo en los proyectos de software fue escrito por el mismo dúo que escribió el libro Peopleware (el cual recomendé en un post anterior: Leer): Los señores Tom DeMarco y Tim Lister.

Ellos escriben este ameno libro, contándonos el porque y el como de manejar riesgos en un proyecto, contando innumerables y ricas experiencias en su historia como consultores.

Una de las enseñanzas más importantes que nos deja este libro es la siguiente: Es éticamente incorrecto ignorar los riesgos, además que se compromete el éxito de los proyectos de software, pero no tiene sentido comercial evitarlos, ya que los proyectos sin riesgo no traen ganancias. Tenemos que acepar y administrar los riesgos.

Los proyectos T&M complican el planeamiento de los recursos en una organización

T&M significa Time & Material(s). Es una forma de contratación de un proyecto: el cliente paga por las horas utilizadas de los recursos para llevar a cabo el proyecto. Esto se utiliza cuando no está en claro lo que hay que hacer todavía, por lo que no se puede crear una estimación sobre los requerimientos (Inexistentes hasta ese momento).

La mayoría de los proyectos en los que trabaje fueron T&M, y uno de los problemas de esta modalidad es que al no saberse cuando se van a terminar los proyectos, la persona que maneja a la gente (asignaciones) no puede planear con exactitud la utilización de los recursos para otros proyectos.

Las consecuencias de esto son tiempos muertos y superposición de tareas. Ambos escenarios son perjudiciales para la empresa ya en primera instancia no se factura, y en la segunda se cansa al recurso y se comprometen los proyectos en el que está asignado. Supuestamente los tiempos muertos deben estar considerados en el precio hora que se negocia en los contratos T&M.

Importancia de los requerimientos de software para la distribución de un producto

Un punto muy importante que hay que tener al crear un producto (en este caso fue de auditoría de software) que va a ser distribuido son los requerimientos de software que este pueda requerir. Por ejemplo, no se le puede pedir a una empresa que instale el .NET Framework para auditarle sus archivos, es simplemente impensable. Y desarrollar el producto con .NET (o Java pidiendo el J2SE sería el mismo escenario) es la primer propuesta que se le ocurriría a un desarrollador. Sin embargo hay que tener en cuenta factores como este, requerimientos no funcionales que pueden hacer fracasar un proyecto o un producto si no son tenidos en cuenta. La solución fue trabajar con el querido C++ en este caso.

Sumamente Peligroso! Lo busca la CIA!

La siguiente imagen la creó un compañero luego de tener una semana complicada donde tuvimos que recuperar dos veces una base de datos en producción por errores que cometí.



"Handinshorts" es como me llamaba a veces el líder a veces de Estados Unidos, porque la palabra es similar a mi apellido de alguna manera y aludía a mi trabajo cuando estaba de mal humor. No creo que haga falta explicar su significado.

Negociando por unas 'facturas' para ayudar a traer ideas nuevas

Esta pequeña anécdota es de cuando queríamos que las empresa nos pague unas facturas para una reunión para obtener nuevos procesos de calidad con el equipo. Nunca antes en la empresa se había reunido un equipo interno y les había comprado facturas, pero siempre se hacia cuando venían clientes, cuando venia alguien 'de afuera'. Acá esta la forma en que gane las facturas:


MArtin marita, ahora vamos a hacer una reunion de calidad del proyecto.... que tal unas facturas? es posible?
Marita viene alguien de afuera?
MArtin si, ideas nuevas esperamos
MArtin que no estan en nuestro cerebro
MArtin no?
MArtin entonces podria calificarse como algo de afuera
Marita mmmm
Marita quien estan en la reunion?
MArtin todo el equipo
MArtin cof cof
Marita ok
Marita a que hora?
MArtin 1515.. si queres voy a buscarlas yo...
Marita te aviso 1500
MArtin gracias!!

Los desarrolladores,...¿no se sienten así a veces?

Sin palabras.
Gracias Ignacio Rodríguez por compartir esto!

Foro de discusiones en un proyecto: Historia de cuatro implementaciones y problemas de privacidad

En el proyecto de creación de una librería de software trabajamos con un equipo externo que utilizaba una aplicación web para realizar su trabajo, el que consistía en realizar investigaciones sobre archivos para determinar su estado de licenciamiento.

Teníamos un grupo de calidad interno revisando su trabajo y respondiendo sus consultas por mail o IM, pero toda esa información se perdía y la forma de consulta era desorganizada así que uno de mis compañeros en el equipo sugirió un foro de discusiones para que el que tenga un problema cree un nuevo tema y nosotros lo ayudemos y para que se ayuden entre ellos también. Afortunadamente esta experiencia fue un éxito ya que el equipo se comprometió en este nuevo ámbito y rindió sus frutos para el proyecto.

El problema que tuvimos fue la elección de la implementación del foro. Inicialmente comenzamos con un plugin para Trac. Era muy simple y funcional, pero le faltaban funcionalidades de un foro más profesional, como la notificación por mail que era reclamado por los miembros del equipo ya que les avisaría sobre cambios en temas que participaron. Adiós primera implementación.

Como segunda implementación buscamos un proveedor de foros de discusión web gratuito. Hay varias páginas que dan ese servicio gratuito, sobre un muy buen foro, phpBB. Este foro tenía todas las funcionalidades que necesitábamos y estábamos todos muy contentos con él, contentos hasta que le comentamos al jefe de proyecto de Estados Unidos sobre el foro. El se enojó (y con buena razón) porque estábamos publicando en servidores de otra empresa datos del proyecto, y eso era una falta contra el acuerdo de confidencialidad. Adiós segunda implementación.

Como la empresa trabaja generalmente con tecnologías Microsoft, decidimos probar un foro dentro de un sitio Sharepoint 2007. Yo pasé mis necesidades (que incluían notificación por mail) y finalmente lo implementaron y migramos todos los datos ahí. Solo faltaba la notificación por mail. El sector de infraestructura tenía que resolver un tema de accesos para activarla, pero finalmente no se pudo solucionar. Además extrañábamos el foro phpBB, mucho más amigable que el Sharepoint, el cual no nos servía. Adiós tercera implementación.

Ya estando resignados nos íbamos a conformar con el Sharepoint, pero un compañero me sugería arduamente que trate de instalar un foro phpBB para hostearlo en la empresa. Por suerte me convenció y pude hostearlo en el servidor donde teníamos los sitios Trac que corrían también bajo Apache. Este foro utilizaba a MySQL como sistema de gestión de bases de datos. Ver funcionando al foro fue muy gratificante.

Además de todos estos movimientos que pueden ser divertidos hasta cierto punto, nos pasamos horas migrando temas manualmente entre implementaciones, lo que era una tarea para nada agradable y perdimos muchas horas por falta de guía en esta situación y falta de experiencia. Por suerte se pudo aprender mucho de esto, para no cometer los mismos errores en el futuro.

Google Docs y sus aplicaciones

Ayer comenté en un post sobre una utilización de una hoja de cálculo o spreadsheet de Google (Leer), hoy voy a comentarles sobre Google Docs y aplicaciones de esa tecnología.

Google Docs es un servicio de Google que permite crear hojas de cálculo o spreadsheets (como MS Excel) y documentos de texto (como MS Word). Todo esto se edita y visualiza sobre el browser, se guarda en los servidores de Google y puede ser accedido en cualquier lugar con una conexión a Internet. Lo más importante es que Google Docs es una herramienta colaborativa, esto quiere decir que uno puede invitar a cualquier persona para trabajar sobre el documento online (sea un spreadhseet o un documento de texto), y los cambios se ven en tiempo real. También se puede publicar el documento sin permitir la edición. Otro punto para destacar es que guarda un historial de revisiones con todas las modificaciones realizadas, indicando que usuario realizo la modificación y cuando. Además tiene una ventana de chat para conversar entre todos los que la están editando el documento. Finalmente se puede exportar a un archivo sea .doc, .xls o .pdf entre otros.

Les cuento mis aplicaciones de Google Docs:

En la facultad lo use varias veces para preparar trabajos prácticos. En algunas materias los alumnos creaban un documento y cada uno iba agregando temas para que todos tengan ahí lo que hay que estudiar para el parcial.

En el trabajo lo use para crear una matriz de asignaciones, organizar reuniones, crear documentos colaborativamente con gente de Estados Unidos y tener una lista de tareas realizadas para que sea vista online.

En mi vida personal lo uso para mantener mis CVs o currículum vitaes, ya que puedo accederlos cuando los necesito y exportarlos a .doc o .pdf cuando necesito enviarlo. También esta publicado, entonces hay gente a la cual le paso la URL de mi CV, y si hago modificaciones, el documento se republica con los cambios.

Además lo uso para tener una lista con los componentes de las computadoras que tengo en casa.

También lo usé para organizar quien o quien no venía a mi cumpleaños: Anoté todos los nombres de las personas que invité, y marcaba en verde o en rojo según me iban confirmando su asistencia o ausencia y luego supe bien cuanta gente iba a ve.

Incluso realicé una lista de cosas para llevar en las vacaciones con mis amigos y otra con mi novia. Lo bueno es que voy a poder reutilizar estas listas el año que viene, ya que uno siempre lleva más o menos lo mismo. Cuando volví de mis vacaciones anoté lo que me había olvidado para no olvidármelo en mis próximas vacaciones.

Finalmente tengo una curva de peso (en el spreadsheet se pueden hacer gráficos) ya que me había desviado de mi peso ideal y quería bajar los kilos de mas, entonces me peso todo los viernes y anoto en la curva. Comparando con las semanas anteriores ya puedo ir mentalizándome sobre mi comportamiento alimenticio futuro.

The Fifth Discipline: The Art and Practice of the Learning Organization

Este libro de Peter Senge no es de la temática de la Ingeniería de Software sino es mas del área de organización empresarial. Las ideas que propone son muy interesantes.

Una organización inteligente cuenta con las siguientes disciplinas:

- Dominio personal
- Modelos mentales
- Construcción de una visión compartida
- Aprendizaje en equipo
- Pensamiento sistémico (la quinta disciplina)

El comenta todos los puntos anteriores, contando experiencias o historias de problemas que tuvieron distintas empresas y cuales fueron las causas. Todos los problemas los describe mediante diagramas indicando la situación, que alimenta a cada consecuencia y como aplicar una 'palanca' para resolver estos problemas.

Senge propone al pensamiento sistémico como la quinta disciplina, el arte de ver el árbol y el bosque, no abstraerse siempre perdiendo de vista la complejidad total de un sistema.

A continuación transcribo una parte del libro, donde comenta la importancia de que una organización tenga una visión compartida:

As a part of building shared vision, the process of committing to live by certain basic values also undermines internal politics. Once, as part of a three-day visioning session for the management team of a Boston area technology firm, the question of honesty came up. The group had casually identified "honesty and forthrightness in all communications" as one of their operating ground rules. The management team had developed a vision they were beginning to get really excited about, when one of the senior salespeople commented off handedly, "Of course, we don't mean that we will be honest to our customers."

The entire process ground to a halt. The group reconsidered what they meant by "commitment to honesty and forthrightness in all communications." The president broke the silence by stating, "Yes. For me, this means being completely honest with our customers."

The salesman responded, "If we do we'll lose 30 percent of our booking next month. In this business none of our competitors are honest when they tell a customer when a new computer system will arrive. If we tell the truth, our delivery times will be 50 percent longer than what customers believe they will get from competitors."

"I don't care," was the president's response. "I simply don't want to be part of an organization that sanctions lying, to our customers, our vendors, or anyone else. Moreover, I believe that, over time, we'll establish a reputation for reliability with our customers that will win us more customers than we'll lose."

The exchange continued for more than an hour. At the end, the group was together in support of telling the truth. The salesperson knew that if bookings dropped off in the next month or two, the other members of the team would not come screaming for his head. And he and the rest had begun to develop a vision of building a new reputation for honesty and reliability among their customers. This session took place six years ago. In the intervening period, the firm has prospered and established a preeminent position in its niche market.

Organizando una reunión con Google Docs (Spreadsheet)

Cuando era el Project Manager del proyecto de creación de una librería de software, trabajamos con un equipo externo, que trabajaba desde sus casas sin restricción de horarios debido a que trabajaban sobre una aplicación web que estaba en linea 24/7.

El equipo se fue formando de a poco, primero ingresaron cinco, luego otros cinco. En una época llegaron a ser doce. Luego de que quedaron diez, decidimos hacer una reunión de entrenamiento sobre un nuevo proceso de trabajo que desarrollamos.

Tratar de acordar una reunión de entrenamiento de aproximadamente cuatro horas de duración con diez personas que no están en la empresa y tienen otras obligaciones no es fácil.

Entonces se me ocurrió crear un 'spreadsheet' de Google para resolver el problema. Es una hoja de calculo como el Microsoft Excel que se puede editar y visualizar en un browser. Pero lo más interesante es que podés invitar a otros usuarios de Google a editar la planilla, y guarda todas las revisiones para saber quien hizo cada cambio, y se puede volver a cualquier revisión anterior.

Entonces creé una matriz con los nombres como filas y los días de una semana (dentro de un mes) y envié el mail un lunes, diciéndoles que marquen con una X en los días que podían, (en las filas de su nombre) y que el viernes me iba a fijar en la planilla y que tenía que haber un día que todos pudiesen asistir.

Afortunadamente tuve éxito, el viernes habían marcado todos que podían el día martes pero faltaba una persona, con el que arreglé para que venga ya que todos los demás habían elegido ese día.

Acá les dejo una captura de la planilla resultante.

LinkedIn

LinkedIn es un sitio web de contactos profesionales. Su moto es "Relationships matter, Your professional relationships are key to your professional success".

Cuando te unís, creas un perfil y completas datos sobre tu carrera profesional y tus estudios. Tu perfil ayuda a que te encuentren colegas o clientes. Uno también puede buscar gente y armar una red de contactos.

Yo lo uso para tener un lugar donde guardar los contactos de compañeros de la facultad, clientes, ex-clientes, compañeros de trabajo, y todo el que alguna vez se relacionó conmigo por temas de mi profesión.

También uno puede recomendar gente y ser recomendado. Yo recomendé a mi 'coach', Jeffrey Vasquez, acá esta lo que escribí:

Jeffrey, in my two years I have of working experience, shaped me into what I am today. He has been my biggest influence. His constant teachings, his countless processes, his dedication and over the top expectations allowed me to grow in an infinite way. He taught me the value of quality above everything and how to be politically correct with clients, how to understand them and their needs. Our constant discussions about morals, work ethics really enriched the way I look at work and life as well. Working with him has been priceless, it has been an immense pleasure and an honor.

Luego el me recomendó a mí y esto es lo que escribió:

“Mr. Häntzschel has been a critical resource for every project I've completed and I have relied and depended on his efforts to ensure project success and customer satisfaction. It was been a great privilege to work with someone of such high ethical character and dedication to team success.”

Psst, What is Software, Anyway?

El titulo de arriba corresponde al primer capítulo del libro "Software Perspectives - The System is the Message" escrito por Peter Freeman en 1987.

Lamentablemente solo leí el primer capítulo, ya que no pude conseguir el libro porque es bastante raro, lo pude leer gracias a que fue distribuido por un profesor en la facultad. La materia se llama "Calidad En Desarrollo De Sistemas". Les dejo un pequeño resumen que les recomiendo leer:

Este capitulo empieza diciendo que esta bien preguntar, nadie tiene que estar avergonzado. Software es mas que solo programas, y uno de los conceptos que no es tenido en cuenta es el echo de que es un sistema. Antes de comprender el proceso de creación de software, es útil comprender primero que es software en sí mismo.

Desde el punto de vista de una computadora software es un conjunto de programas que determinan que se debe hacer. Pero cuando indagamos sobre que esperamos que la computadora haga para nosotros ese concepto de software es erróneo, llevando el concepto del software a un aspecto mayor. Lo que básicamente realizamos es rever el alcance de lo que es un software y desmitificando que solo es un conjunto de ejecutables sino un proceso más complejo que posee un ciclo de vida sobre el cual debemos actuar.

Una de las ideas que nos conduce a este concepto es que la productividad medida en líneas de código centra a los desarrolladores y Project Managers a considerar que el único output valido y considerable es la producción de código, generando montañas de código o inclusive sistemas técnicamente sofisticados pero inútiles para los usuarios.

A continuación una lista de los puntos de que es software para Freeman:

• The brain and soul of a computer, not just a coat of paint.
• The embodiment of the function of a system.
• The capture knowledge abaut an application area.
• The collection of all the programms and data that are necesary to make computer a special-purpose machine design for a particular application.
• All of the information (documentation) produced during the development of the software-intensive system.

Trac: Respondiéndome una pregunta

Cuando comencé a trabajar y a administrar Trac (Software de administración de proyectos que recomendé anteriormente: Leer) tuve muchas dudas, muchas de las cuales fueron resueltas por la excelente documentación que acompaña al sistema, y otras por la grandiosa comunidad de usuarios del grupo de Google Trac Users

En esa época había instalado un plugin para tener un foro de discusiones en el sitio, y deseaba que personas ajenas al dominio del proyecto accedan a este, pero sin la posibilidad de acceder a todo el resto de Trac (Los tickets, el repositorio y las paginas wiki). Para eso tuve que involucrarme en el mundo de los raros permisos de Trac. Como la documentación no me sirvió para crear ese tipo de usuarios recurrí al foro con este post:

Hello,
I've just installed the Discussion Trac plugin, and i want to
create a subset of users or user group with only permissions to view
or append to the discussion.
I created some new users, and i can't remove any of these
permissions:

User Action
----------------------
User1 BROWSER_VIEW
User1 CHANGESET_VIEW
User1 FILE_VIEW
User1 LOG_VIEW
User1 MILESTONE_VIEW
User1 REPORT_SQL_VIEW
User1 REPORT_VIEW
User1 ROADMAP_VIEW
User1 SEARCH_VIEW
User1 TICKET_APPEND
User1 TICKET_CHGPROP
User1 TICKET_CREATE
User1 TICKET_MODIFY
User1 TICKET_VIEW
User1 TIMELINE_VIEW
User1 WIKI_CREATE
User1 WIKI_MODIFY
User1 WIKI_VIEW


I tried adding TRAC_ADMIN to User1, and it worked. I removed that
permission, and it worked.
Why can't i remove all other permissions?
Isn't this possible?

Thank you very much!!
Martin

Un usuario respondió que tenía el mismo problema, pero nadie se acercó a proveer la solución. No me rendí y la encontré. Para que ese usuario y cualquier otra persona que se encuentre con ese problema (y busque en el foro antes de preguntar) lo pueda solucionar, me tomé el trabajo de describirles (informalmente y no con mi mejor inglés) la solución que apliqué al tema:

I got it!!
There is a permission table in trac db which only had trac admin
users, and a user named anonymous. However, i had lots of other users
that could access trac, the ones i created with the apache user
creation utility.
The thing was that in the permission table there was a user named
anonymous with all those permissions.
So i got sqlite browser, a ui for editing tracs db.
I deleted all entries for the anonymous user.
And then user1 had no permissions. I added the ones i wanted, and it
worked!!!
I had a problem then, i had deleted all the permissions from the users
who didn't appear in the permission table, normal users.
So i created a new permission group, named default, with all the
permissions listed in this topic.
Then i gave the default group permission to everyone (but user1) and
it worked.
I created a new user (user2) and by default, it has no permissions!

Hope this works for you too, ask me if anything!

El tema completo del foro puede verse acá.