Como aprovechar LinkedIn profesionalmente y al máximo

Hace poco me encontré con este interesante artículo, que indica cómo aprovechar LinkedIn, una red social que recomendé en un post anterior.

Para los que recién comienzan a utilizar este tipo de red social, les recomiendo que le peguen una mirada al artículo, para aprender cómo aprovecharla mejor y conocer la aplicación al máximo:

Leer Artículo.

Historias del correo: Encomienda sorpresa y tazas rotas

En mi primer trabajo, cada vez que me enfermaba y no podía ir a la oficina pasaba algo extraño. No eran problemas de trabajo ni con los clientes, solamente sucesos fuera de lo normal.

Por ejemplo en el primer proyecto en el cual trabaje, me hice muy amigo de la persona que se encargaba de soporte al usuario de la empresa en Estados Unidos. Me conto que tenían en un deposito unas tazas con el nombre del proyecto, ya que era un producto de uso masivo y le dije que gestione para que manden algunas para acá.

Unos días antes de mi cumpleaños me enfermé. Justo ese día me llamaron diciendo que llego un paquete para mí con el nombre de la clienta. Yo pensé que eran las tazas y les dije que lo reciban (El tema era que Fedex pedía 300 pesos que es lo que habían cobrado la aduana).

Quince minutos luego me llama un compañero diciendo que los contenidos del paquete eran algo personal, que era para mí y que era una sorpresa. También me comento que escucho decir a uno de los jefes que tenía que pagar yo los 300 pesos, lo cual no me causo mucha gracia.

Luego de que me recupere volví y había en mi escritorio una caja de un monitor LCD. Realmente me emocione pero eso fue una broma de mis compañeros, que habían puesto la el paquete adentro de la caja del monitor, con una hoja impresa con la conocida imagen de Nelson (personaje de los Simpsons) diciendo “Ha ha”.

Adentro de la caja había un montón de pequeños regalos de la clienta de Estados Unidos por mi cumpleaños. Me había mandado un montón de chocolates (los cuales compartí), un CD del guitarrista Joe Satriani, un CD de una cantante amiga de ella, una remera de una cervecería que me quedaba chica (ahora que recuerdo la tiene una ex novia, maldición), una polvo para cocinar una Cheesecake instantánea, unos fideos con salsa para calentar por microondas, un café muy raro, una sopa instantánea de papa, un gel de chocolate energizante y alguna que otra cosa más que no recuerdo.

Fue muy emocionante y grato recibir esto, realmente me sorprendió, fue el primer regalo personal de un cliente que recibí (y el único hasta hoy). Luego de unos días me dijeron que los 300 pesos los pagaba la empresa ya que era lo que correspondía por ser un regalo empresarial aunque de carácter personal.

Luego de unos meses, volví a enfermarme y me volvieron a llamar. Había otra encomienda, esta vez si eran las tazas, pero de 12 sobrevivieron 3 nada más (y con bastantes rayones). Ahora que estoy en otra oficina las extraño.

Perdiendo dos horas de trabajo por un error de la aplicación

En mi primer día en mi nuevo trabajo, tuve un grave problema con el Microsoft Project 2007. Era bastante tarde y el líder de proyecto al que reemplazaba me estaba explicando cómo hacer el informe de estado del proyecto, en el cual se entrega el calendario actualizado.

Luego de dos horas de trabajo habíamos terminado y cuando nos dispusimos a cerrar el Microsoft Project seleccionamos cerrar y presionamos que queríamos guardar los cambios realizados en el documento. Lamentablemente, apareció un mensaje informándonos de un error para el cual no había opción de volver atrás, solo daba la opción de presionar OK.

Luego de hacer clic (no había otra salida) nos dispusimos a abrir de nuevo el archivo y vimos que no se había salvado ningún cambio.

Nos tuvimos que quedar a rehacerlo (en otra máquina por las dudas) y nos fuimos casi dos horas tarde. Era un viernes, y yo salí maldiciendo mi nuevo trabajo. Por suerte eso no ocurrió mas.

Realmente es lamentable que la versión 2007 del Project no tenga ningún sistema de recuperación de datos, como tiene el Word 2007 por ejemplo (y creo que el 2003 lo tenía también). Es inconsistente que Microsoft lance aplicaciones del mismo paquete que no tengan las mismas funcionalidades que en estas épocas son consideradas básicas.

La tarea más frustrante que tuve que hacer hasta ahora – Parte 2

Ayer les conté sobre una tarea que tuve que realizar sobre SMS (Microsoft System Management Server 2003), que comparada con lo que contare ahora fue un “pedazo de torta” o un “paseo en el parque” (Traducción de las frases “A piece of cake” y “A walk in the park” que en ingles significan que algo fue sencillo).

En otro proyecto, para otro cliente, que lamentablemente usaba el mismo sistema, tuvimos que preparar un parche para una aplicación que tenía que ser .exe, y distribuirlo en una red SMS (que generalmente acepta archivos de instalación .msi). Esto hubiese sido más simple si hubiésemos tenido que trabajar en el dominio con el servidor y el cliente que venía preparado por Microsoft , pero teníamos que probar con una maquina virtual que nos había mandado el cliente para distribuir el software desde el servidor.

Inicialmente se agrego la maquina al dominio y costó mucho para que el SMS la reconociese. Por suerte estaba presente la persona que conocía parcialmente SMS, la cual me ayudo mucho.

Finalmente logre que se vean las dos maquinas y comencé a hacer las pruebas de instalación del parche por SMS.

Algo funcionaba mal, había veces que se comunicaban las maquinas, y veces que no. Veces que tardaba unos minutos en aparecer la instalación del programa, y veces que tardaba horas, con la misma configuración.

Estuve muchos días con esto, me sentía muy frustrado ya que quería terminar la tarea, volvía a mi casa triste, no podía olvidarme, ya que necesitaba algún progreso o alguna indicación de mejora para sentirme bien. Además, fueron mis últimas semanas de trabajo. No logre terminarlo. Realmente me dejo un gran sabor amargo, que solo lo puede disminuir el hecho de que no fui entrenado ni realmente me apasiona el trabajo de infraestructura. Luego seguí comunicándome con compañeros para ver en que había quedado la tarea, y parece que luego de un tiempo se pudo completar.

Espero no toparme con SMS en lo inmediato, pero sé que adquirí gran conocimiento del sistema si es que me toca, para terminar el post en un tono alegre.

La tarea más frustrante que tuve que hacer hasta ahora – Parte 1

Les voy a contar sobre la tarea más frustrante que tuve que hacer en el trabajo (en mi primer trabajo) hasta ahora. Esta involucro un producto de Microsoft (no podía faltar, en las malas más que en las buenas), el Microsoft System Management Server 2003 (coloquialmente conocido como SMS). Este software sirve para instalar automáticamente software en una empresa desde un servidor y para tener una base de datos de todos los archivos y programas de todas las computadoras (entre otras cosas).

Mi primer encuentro con este software fue cuando estaba trabajando en un proyecto de construcción de una librería de software en un proyecto de Software “Asset Management/License compliance”. Nuestra librería se rellenaba con datos recolectados por SMS, y como había salido el Microsoft Office 2007, el cliente quería ingresar ese software (en todas sus ediciones) en la librería.

Siempre recibíamos copias de seguridad de la base de datos de SMS de empresas para ingresarlas a la librería, pero esta vez nos pidieron que nos encarguemos nosotros. Por suerte Microsoft distribuye a sus partners un ambiente de prueba de SMS, con una maquina virtual que es el servidor de SMS, y un cliente en el mismo dominio. Se instaló en la maquina virtual cliente el Office 2007 y luego comencé a trabajar con la consola de administración del SMS para que se recolecten los datos de la maquina cliente y poder darle ese base de datos al desarrollador para que se importe en la librería.

Decir que configurar el SMS fue difícil es ser muy bueno con la palabra difícil. Realmente fue muy complicado y frustrante, ya que es un sistema bastante complicado, y no me deberían haber asignado la tarea a mí, tendría que haberla visto alguien de tecnología, y justo en ese momento el único que tenía idea estaba en un cliente por un largo tiempo.

Luego de varios días de leer tutoriales y probar, logre llenar la base de datos con los archivos del Office 2007. Realmente fue muy gratificante haber terminado esa tarea. Creo que cuanto más difícil es la tarea, más gratificante es terminarla con éxito. Realmente no tenía tiempo para ponerme con una aplicación compleja sobre la cual no recibí ningún tipo de entrenamiento formal e informal.

Siempre uno se va a encontrar con tareas frustrantes en el trabajo. Hay que tratar de que no lo agobien a uno y tener mucha pero mucha paciencia y atacar la tarea día a día.

El principio de Pareto (la regla del 80:20)

El principio de Pareto enuncia que el 20% de cualquier cosa producirá el 80% de los efectos, mientras que el 80% restante sólo cuenta para el 20% de los efectos. Este principio lo enuncio Vilfredo Pareto por primera vez cuando dijo que el 20% de la población de Italia era dueña del 80% del país.

Este interesante principio aplica también a muchas cosas, como el software. Aca les dejo unas aplicaciones de la regla:

• 80% of process defects arise from 20% of the process issues.
• 20% of your sales force produces 80% of your company revenues.
• 80% of delays in schedule arise from 20% of the possible causes of the delays.
• 80% of customer complaints arise from 20% of your products or services.
• Project Managers know that 20 percent of the work (the first 10 percent and the last 10 percent) consumes 80 percent of the time and resources.
• 20% of your marketing efforts generate 80% of your marketing results.
• 20% of your products or projects or customers will generate 80% of your profitability.

Existe el diagrama Pareto para ilustrar esta regla. En el siguiente ejemplo se ven las frecuencias relativas sobre las causas de llegar tarde al trabajo. Esta sirve para saber cuáles son las causas más importantes, y atacar estas, ya que causan la mayoría de los problemas.Fuentes:
http://www.isixsigma.com/library/content/c010527d.asp
http://es.wikipedia.org/wiki/Principio_de_Pareto
http://en.wikipedia.org/wiki/Pareto_chart

Metodologías Agiles: Reuniones diarias

Las reuniones diarias son unos de los pilares de las metodologías de desarrollo ágiles. Los propósitos de ellas son:

• Share commitment
• Communicate daily status, progress, and plans to the team and any observers
• Identify obstacles so that the team can take steps to remove them
• Set direction and focus
• Build a team

¿Quien tiene que ir a una reunión diaria?

Principalmente todo el equipo, y también algún otro interesado, pero hay que aplicar la regla de "Pig and Chickens:

A chicken and a pig are together when the chicken says, "Let's start a restaurant!".
The pig thinks it over and says, "What would we call this restaurant?".
The chicken says, "Ham n' Eggs!".
The pig says, "No thanks, I'd be committed, but you'd only be involved!".

Esto sería hacer lo siguiente:

Institute a rule where only the “committed” participate and the “involved” are only allowed to observe.

¿De qué hablamos en la reunión diaria?

• Sobre las tareas y/o obstáculos de hoy o ayer
• Hay que enfocarse en las tareas a realizar
• Hay que Destrabar bloqueos o cualquier impedimentos.

¿Donde llevamos a cabo las reuniones diarias?

Lo mejor sería hacerlo siempre en el mismo lugar, al mismo tiempo. Se puede usar la reunión para comenzar el día de trabajo.

¿Cómo mantenemos el nivel de energía de la reunión diaria?

• Estando cerca
• Haciéndola todos parados, para no divagar.
• Que no se extienda más de 15 minutos
• Algo muy importante es que esta es una reunión de equipo, no es para reportar al líder, tiene que discutir todo el equipo entre ellos.

Para más información, lean este interesante artículo de Jason Yip, del cual me base para escribir este post: It's Not Just Standing Up: Patterns of Daily Stand-up Meetings

Nadie lee las licencias (EULAs)

Una empresa (PC Pitstop) incluyo una clausula muy extraña en la licencia de uno de esos programas:

A special consideration which may include financial compensation will be awarded to a limited number of authorize licensee to read this section of the license agreement and contact PC Pitstop at consideration@pcpitstop.com . This offer may be withdrawn at any time.

Luego de cuatro meses y mas de 3000 descargas del programa, alguien mando el mail y se le pago U$S 1000. Esto prueba que la gente lee las licencias. El objetivo de esa empresa es que la gente lea las licencias, ya que muchos de los programas que traen spyware te dicen eso en la licencia y te dan la opción de cancelar y no instalar el software.

Diez consejos para fracasar en su proyecto

Para que se entretengan y aprendan, les dejo los diez consejos para fracasar en su proyecto, del Blog Mejores Proyectos (el cual recomiendo). Que tire la primer piedra el que nunca cometió ninguno de estos errores:

1. Usted sabe que la planificación no es más que un buen deseo que no se cumplirá. ¿Para que perder tiempo planificando entonces?, comience a trabajar de inmediato, y no pierda su tiempo en papeles.

2. Nunca pida definiciones al sponsor o al cliente, lo verán como a un molesto. Si algo no queda como el sponsor o el cliente lo necesitaba siempre hay tiempo para un cambio de alcance, y por otro lado no se lo avisaron.

3. No se moleste en perfeccionar la definición del alcance del proyecto en el inicio del mismo, y mucho menos acordarla por escrito con el cliente. Esto es una pérdida de tiempo y le quita “flexibilidad” a la gestión, además es mucho mas aburrido que ir definiéndolo sobre la marcha.

4. Acepte proyectos con cronogramas incumplibles, y no los re-planifique. De todos modos los proyectos siempre se atrasan, entonces para qué incomodar a sus superiores ya desde el inicio. (Este consejo es tan bueno que también es válido para costos).

5. No establezca responsables en el equipo, luego pretenderán que les reconozcan sus logros. Eso sí, tenga siempre a mano a uno o dos culpables por entregable (este punto es muy importante para asegurarse futuros fracasos).

6. Documente lo menos posible, la documentación lo compromete y hasta puede que quede en evidencia el estado de su proyecto.

7. Cambie a los miembros del equipo una o dos veces por proyecto. Así podrá culpar a los que no están por los problemas que aparecen o a los nuevos por no entender el proyecto. Si se llegase a quedar sin más opciones, es el momento de que usted cambie de proyecto.

8. Si te estás comunicando no estás haciendo cosas, por lo tanto, comunicarse es perder el tiempo. Por otro lado usted no tiene nada que escuchar ni del cliente ni del equipo, si fuesen tan listos ya serían PMs.

9. Otro punto clave: jamás pida capacitación para el equipo, un individuo capacitado es un recurso que genera más valor y apreciado por el mercado, por lo tanto le exigirá un mejor sueldo, o peor aún, se irá a otro proyecto.

10. No pierda tiempo revisando los términos y condiciones de los contratos, y tampoco se moleste en generar una buena relación con abastecimiento. Los proveedores solo quieren sacarle el dinero de su proyecto y abastecimiento solo dificulta las compras.

Armas nucleares con iTunes

En la EULA (end-user license agreement) de iTunes 7 de Apple se puede leer lo siguiente:

You also agree that you will not use these products for any purposes prohibited by United States law, including, without limitation, the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons.

Realmente no se como se le puede ocurrir a los abogados de Apple que iTunes se pueda usar para crear armas nucleares o biologías, pero bueno, supongo que tienen que ser muy cuidadosos.

Les recomiendo The Small Print Project, en esa pagina hay muchos mas ejemplos graciosos de licencias para software y otras cosas, de ahí obtuve este articulo, ya que seamos sinceros, nadie las lee.

Índice de utilización de los lenguajes de programación

Para todos los interesados en la popularidad o utilización de su lenguaje de programación favorito, les recomiendo el índice de TIOBE, el cual se construye contando los resultados de los lenguajes en los buscadores mas populares inicialmente. Es muy interesante la forma en que construyen el índice, léanla acá.

El índice se actualiza mensualmente. Además del raking, hay un gráfico histórico con la evolución de los lenguajes desde hace cinco años atrás:


También si lo requieren, la empresa vende por U$S 1500 datos completos desde el 2001.

Technology adoption lifecycle

Les presento a la curva de difusión de la innovación, en el ciclo de vida de adopción de la tecnología. Este es un modelo sociológico desarrollado en 1957 con la intención de estudiar la adopción de tecnología en agricultores en Estados Unidos, pero sigue siendo utilizada actualmente. El estudio dividió a la gente en los siguientes grupos:

• Innovators - had larger farms, were more educated, more prosperous and more risk-oriented
• Early adopters - younger, more educated, tended to be community leaders
• Early majority - more conservative but open to new ideas, active in community and influence to neighbours
• Late majority - older, less educated, fairly conservative and less socially active
• Laggards - very conservative, smalls farms and capital, oldest and least educated

Por ejemplo, cuando se adoptan nuevos procesos de desarrollo de software, es muy posible que los que sean afectados se distribuyan en los cinco grupos mencionados. Uno piensa que todos los que trabajamos en software estamos buscando siempre lo nuevo, que la mayoría somos jóvenes, pero esto no es así. Siempre hay gente que puede pensar que pierde poder al adoptarse una nueva forma de trabajar o un nuevo software.

Digamos que depende también de lo que se adopte. Ahora en mi nuevo trabajo estoy con muchas ganas de comenzar con procesos ágiles, entonces me puedo describir como del grupo de los innovadores. Puede que en algunos años me sienta muy cómodo con esa practica, deje de actualizarme, y al aparecer algo nuevo por no estar informado lo voy a rechazar.

Fuente: Wikipedia.

Mucho cuidado con las políticas de confidencialidad de los clientes

En mi nuevo trabajo estamos desarrollando software para una gran empresa financiera. Ellos tienen un sistema donde se suben los entregables. Inicialmente yo utilizaba el usuario y la contraseña de un compañero, pero uno de los clientes me dijo que me daba una si necesitaba, ya que tenia que subir archivos ahí.

Cometí un error, tal vez no muy importante, no paso nada, pero podría haber pasado. Le comente que estaba usando el usuario y la contraseña de un compañero pero estaría muy agradecido que me pase uno el. Luego de unas horas obtuve mis credenciales e ingrese al sitio. Al ingresar el sistema me muestra una gran cantidad de advertencias, una de ellas dice:

User must keep User's Access Code confidential and must ensure that it is not disclosed to any other person.

¿Descubrieron mi error? Nunca tendría que haberle comentado al cliente que usaba las credenciales de un compañero ya que podría haberle creado problemas a el y a la empresa. En esa situación tendría que haber dicho que mi compañero subía los archivos por mi. Nunca se puede ser demasiado cuidadoso.

Agilidad en los requerimientos

Cuando uno piensa en la palabra requerimientos, pero no en el sentido que le da el software, sino en el sentido del lenguaje, uno se da cuenta que algo requerido es algo pedido, y suena como algo obligatiorio.

Luego uno ve los requerimientos de un sistema que van siendo achicados o cambiados durante un proyecto. Lo que alguna vez fue requerido, ya no lo es mas. La palabra toma una gran flexibilidad en la ingeniería del software.

Veamos que es un requerimiento para distintas entidades o personas (obtenido de Wikipedia):

• Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
• Una condición o capacidad que debe ser conformada por el sistema (RUP).
• Algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson).

En las metodologías ágiles se tienen una lista de requerimientos, pero se van priorizando y cambiando en el planeamiento de cada ciclo de desarrollo, ya que generalmente el cliente no tiene una visión clara de lo que quiere inicialmente .

GPL vs Lesser GPL (LGPL)

Además de la GPL que expliqué ayer, existe la LGPL. La diferencia principal es que cualquier software bajo la licencia LGPL permite que pueda ser utilizado por un programa no libre (propietario), mientras que la GPL no. Les dejo las razones por las cuales no conviene utilizar esta licencia (De un artículo de gnu.org):

Proprietary software developers have the advantage of money; free software developers need to make advantages for each other. Using the ordinary GPL for a library gives free software developers an advantage over proprietary developers: a library that they can use, while proprietary developers cannot use it.

Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Lesser GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library.

However, when a library provides a significant unique capability, like GNU Readline, that's a horse of a different color. The Readline library implements input editing and history for interactive programs, and that's a facility not generally available elsewhere. Releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline.

Proprietary software developers, seeking to deny the free competition an important advantage, will try to convince authors not to contribute libraries to the GPL-covered collection. For example, they may appeal to the ego, promising “more users for this library” if we let them use the code in proprietary software products. Popularity is tempting, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs above all.

But we should not listen to these temptations, because we can achieve much more if we stand together. We free software developers should support one another. By releasing libraries that are limited to free software only, we can help each other's free software packages outdo the proprietary alternatives. The whole free software movement will have more popularity, because free software as a whole will stack up better against the competition.

GNU General Public License v3

La Licencia Pública General de GNU o más conocida por su nombre en inglés GNU General Public License o simplemente su acrónimo del inglés GNU GPL, es una licencia creada por la Free Software Foundation a mediados de los 80, y está orientada principalmente a proteger la libre distribución, modificación y uso de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios. La licencia GPL, al ser un documento que cede ciertos derechos al usuario, asume la forma de un contrato, por lo que usualmente se le denomina contrato de licencia o acuerdo de licencia. Como contrato, la GPL debe cumplir los requisitos legales de formación contractual en cada jurisdicción.

Lee acá la licencia en forma completa.

¿Es Open Source lo mismo que Software Libre?

La respuesta a la pregunta del titulo de este post es No. Mucha gente cree que ambos terminos significan lo mismo, pero esto no es verdad. Les dejo unas palabras de un artículo del gran Richard Stallman donde explica las diferencias:

Nearly all open source software is free software; the two terms describe almost the same category of software. But they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement. For the free software movement, free software is an ethical imperative, because only free software respects the users' freedom. By contrast, the philosophy of open source considers issues in terms of how to make software “better”—in a practical sense only. It says that non-free software is a suboptimal solution. For the free software movement, however, non-free software is a social problem, and moving to free software is the solution.

Free software. Open source. If it's the same software, does it matter which name you use? Yes, because different words convey different ideas. While a free program by any other name would give you the same freedom today, establishing freedom in a lasting way depends above all on teaching people to value freedom. If you want to help do this, it is essential to speak about “free software.”

We in the free software movement don't think of the open source camp as an enemy; the enemy is proprietary (non-free) software. But we want people to know we stand for freedom, so we do not accept being misidentified as open source supporters.

Copyright vs. Copyleft

Un termino interesante que apareció gracias a la movida del software libre es Copyleft: que básicamente es una forma para que los que hacen software libre aseguren que cualquier otro que use ese código lo haga de la misma forma, dejándolo libre. Les dejo lo mas importante del artículo del sitio de GNU donde explica que es el Copyleft:

Copyleft is a general method for making a program or other work free, and requiring all modified and extended versions of the program to be free as well.

The simplest way to make a program free software is to put it in the public domain, uncopyrighted. This allows people to share the program and their improvements, if they are so minded. But it also allows uncooperative people to convert the program into propietary software. They can make changes, many or few, and distribute the result as a proprietary product. People who receive the program in that modified form do not have the freedom that the original author gave them; the middleman has stripped it away.

Copyleft says that anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it. Copyleft guarantees that every user has freedom.

Proprietary software developers use copyright to take away the users' freedom; we use copyright to guarantee their freedom. That's why we reverse the name, changing “copyright” into “copyleft.”

Copyleft is a way of using of the copyright on the program. It doesn't mean abandoning the copyright; in fact, doing so would make copyleft impossible. The word “left” in “copyleft” is not a reference to the verb “to leave” — only to the direction which is the inverse of “right”.

Propuesta para cambiar el proceso de administración de tareas - Parte 2

Como contaba anteriormente en la parte 1 de esta historia, mi presentación inicial no basto. Lo que hice a continuación fue escribir una propuesta formal con lo siguiente:

1. Descripción del proceso utilizado actualmente, o sea que estaba haciendo en el presente para administrar las tareas del proyecto, reportarlas al cliente, asignarlas al equipo de desarrollo y al de calidad.
2. Presentación de una propuesta para mejorar ese proceso, sin entrar en temas de tecnología todavía, solo procesos de alto nivel.
3. Aplicación de tecnología para soportar al proceso, desarrollando un plan inicial para soportar el proceso con herramienta existente, el costo de este (en horas de recursos), posibles mejoras del proceso a futuro con las posibilidades de la herramienta y luego todo lo mismo con la herramienta propuesta (Trac).
4. Cuadro comparativo separado en distintas secciones entre las dos herramientas, con las ventajas y desventajas de cada una. Para conocer bien la herramienta existente hable con referentes en la empresa sobre ella. Trac ya la conocía bastante bien.
   
5. Conclusiones, donde obviamente me puse a favor de la nueva herramienta, sino ni hubiese escrito la propuesta en primer paso.

Ahora estoy en la espera del resultado. Creo que es posible lograr la incepción de la herramienta para mejorar el proceso de administración de tareas en la organización. Pronto les como sigue la historia!

Vendiendo Software libre

Espero que en post de ayer haya quedado claro que el software libre se puede vender. Les dejo las palabras más importantes del artículo de GNU sobre el tema (Aunque les recomiendo leer todo el articulo):

Many people believe that the spirit of the GNU project is that you should not charge money for distributing copies of software, or that you should charge as little as possible — just enough to cover the cost.

Actually we encourage people who redistribute free software to charge as much as they wish or can. If this seems surprising to you, please read on.

The word “free” has two legitimate general meanings; it can refer either to freedom or to price. When we speak of “free software”, we're talking about freedom, not price. (Think of “free speech”, not “free beer”.) Specifically, it means that a user is free to run the program, change the program, and redistribute the program with or without changes.

Free programs are sometimes distributed gratis, and sometimes for a substantial price. Often the same program is available in both ways from different places. The program is free regardless of the price, because users have freedom in using it.

Un profesor de la facultad cree que algún día todo el software es libre. No se puede pagar por algo que podes copiar fácilmente. Por ejemplo, no podes fotocopiar un auto ni fabricarlo en tu casa, pero podes copiar software fácilmente. La pregunta que se hace mucha gente es: ¿Cómo voy a ganar plata trabajando en el desarrollo de software? La respuesta es fácil, todo el mundo necesita nuevo software, que le hagan modificaciones al software existente, etc. Más que nunca la venta de software pasaría por desarrollar servicios, no mas venta de productos, como el Microsoft Windows, o el Autocad. Vamos a ver si esta predicción se vuelve realidad.

¿Qué es el software libre?

Generalmente se piensa que el software libre son los programas que descargas gratuitamente, pero realmente el significado abarca muchos mas aspectos, es una cuestión de libertad, no de precio.

Les dejo los conceptos principales del software libre de la pagina de GNU (Les recomiendo que lean el articulo completo):

Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

Propuesta para cambiar el proceso de administración de tareas - Parte 1

En mi nuevo trabajo, notaba una deficiencia en la administración de tareas, por lo cual hice una propuesta de mi querido Trac (un software de administración de proyectos web que recomendé anteriormente).

En este post les contare como encare la propuesta, para que cuando tengan alguna idea y quieran proponerla, tomen en cuenta lo que hice.

La primer fase fue comentarle lo que veía y decir a mi superior que tenia una herramienta para recomendar. Quedamos en que me un día iba a venir a verla, entonces fui al sitio oficial, donde hay una "live demo" para hacer una demostración, y anote en un cuaderno todas las ventajas de la herramienta, para cuando venga a verla, le daba una charla mas o menos ordenada mostrándole la herramienta.

El día llego y comencé a mostrarle la herramienta. El tema es que había una herramienta en uso que no estaba diseñada para administrar tareas, pero podía adaptarse. Al finalizar mi presentación realmente no había ganado nada. La encare mal, ya que mostré todas las posibilidades de la herramienta, pero no indique claramente que problemas podía solucionar, como se comparaba con la otra herramienta ni que ventajas tenia.

Me pidió que le preparase lo anteriormente dicho para poder llegar a presentar la herramienta y eso me dispuse a hacer. Otro día se los cuento!

Enriquece tu vocabulario de inglés día a día fácilmente

La pagina Answers.com, (la cual comente en un post anterior) tiene un servicio que se llama “Word of the day” que te envía por RSS o por mail la palabra del día, con el significado, ejemplos de utilización, la pronunciación, sinónimos y todo lo que provee Answers.com

Es una buena forma para mejorar el inglés día a día y lleva solo 1 minuto!

Foros para hacer preguntas sobre desarrollo de software

Cuando tenia que desarrollar para la facultad (ya que nunca desarrolle en mi vida laboral) y tenia preguntas, solía preguntar en los siguientes foros:

• Codeguru
• CodeProject
• DevX

En cada uno de esos sitios, además de haber mucho código, tutoriales y ejemplos, existen foros de discusión donde una gran comunidad responde ayudando a personas, y también hace preguntas. Realmente me sirvió mucho y les recomiendo que si se quedan trabados con algo pregunten en esos lugares, ya que además de que hay gente que realmente sabe mucho, responden casi inmediatamente. Hay foros para muchos lenguajes, igualmente los que mencione ahí solo son de C++, C# y derivados, pero seguro que hay muchos sobre Java u otros lenguajes. Es buena practica preguntar en esos lugares para que te ayuden a solucionar problemas y de paso ver si hay alguna pregunta que uno puede responder para ayudar a alguien y fortalecer la comunidad.

Administrando tareas y defectos: Software Triage

Triage es un termino medico que tiene el siguiente significado:

Triage is a process of prioritizing patients based on the severity of their condition so as to treat as many as possible when resources are insufficient for all to be treated immediately.

En la ingeniería del software el termino tiene el siguiente significado:

Triage is now also applied in system development. Requirements and design options are triagedto avoid wasting effort on ideas that will obviously never succeed. At some point in the software development lifecycle, regardless of which model you use, we have to make some tough decisions. What defects do we fix? Which should we let go? How do we decide? Triage is one way!

Descubrí este termino hace poco en la lista de hitos de la pagina oficial de Trac. Resulta que tienen un hito en el cual asignan todas las tareas o defectos (de ahora en mas tickets) que no están planeadas, o no se sabe todavía para que hito deben ser hechas, o si vale la pena completarlas o deben ser canceladas. Ellos documentaron el proceso para aplicar 'triage' sobre los tickets.

¿QA = QC?

En muchos sectores de la industria del software se habla de QA y QC como si fuesen lo mismo. Igual reconozco que esto esta cambiando de a poco, y espero con este post ayudar a destacar las diferencias.

QA es la sigla de 'Quality Assurance' y QC es la sigla de 'Quality Control'. QC se puede relacionar con testing, que es realizar un control de calidad sobre algún artefacto, pero generalmente se refiere a testing como QA, que son todas las medidas que se toman para asegurar la calidad de un artefacto, que en parte es asegurarnos que se haga QC sobre algo, pero no es hacer el control de calidad exactamente.

Recomiendo que lean este interesante articulo para interiorizarse mas sobre el tema.

Quality control activities are focused on the deliverable itself. Quality assurance activities are focused on the process used to create the deliverable. They are both powerful techniques and both must be performed to ensure that the deliverables meet your customers quality requirements.

No apresurarse a realizar una entrega al final del día sin necesidad

Seguro que muchas veces les paso que tenían que mandar algo al cliente, tal vez no una entrega final ni definitiva, pero algo que ellos necesitaban, tal vez un script para alguna base de datos, algunas instrucciones o algún otro artefacto que podría tener errores.

Lo que recomiendo es que si estamos al final del día y no existe urgencia para enviar esto, mejor no enviarlo. Dejarlo en el horno durante la noche, que nuestra cabeza puede llegar a encontrar algún problema con lo que se tiene que enviar mientras dormimos.

A mi me paso de enviar varias veces algo, y que descubrir al otro día que surgieron errores, también otras veces estuvo todo bien. Cuando surgen errores, quedamos mal ante el cliente, y no esta bueno ir sumando puntaje negativo por cuestiones evitables como estas.

Varias veces que se decidió esperar al otro día, se encontraron errores, ya que tal vez al final del día no estaba todo el equipo, y siempre es bueno que otra persona le pegue un vistazo al trabajo realizado, uno no puede controlar la calidad de lo uno que hace. También al final del día uno tiende a asegurar que algo esta bien, pero por cansancio u otros factores como querer irse de la oficina, no revisa a conciencia el trabajo realizado.

Ténganlo en cuenta, cuando puedan, dejen reposar el trabajo una noche, trae buenos resultados.

Firefox 3 Download Day!

Mozilla Firefox es el navegador o browser que vengo usando desde su aparición hace pocos años. Realmente estoy muy contento y para festejar la salida de Firefox 3, la gente de Spread Firefox quiere que te registres para que te avisen cuando sale Firefox 3, lo bajes ese día y se rompa el record mundial de downloads por 24hs.

Da la palabra que bajaras Firefox 3 ese día acá. Todavía no se anuncio la fecha, pero si ingresas el mail te van a avisar así bajas el programa ese día, ayudas a Mozilla a romper el record y aportas lo tuyo a favor del software libre.

Imitando costumbres de los clientes

Una buen consejo, aunque tal vez no sea muy importante ni logre maravillas, es copiar algunas pequeñas costumbres de los clientes. En este caso es en los emails. Examinando que indentación usan, como saludan, como se refieren a las personas y otros factores de la redacción se puede imitar al cliente y tal vez así crear menos distancia en las comunicaciones.

Como escribir sin distracciones

Hace poco me encontré con un articulo de un escritor que da consejos para escribir sin distracciones, y dice que una de los retos mas grandes de los escritores hoy en día es la internet y el llamado del sillón si uno esta en su casa.

Good writing requires focus.

Estas son diez pautas que sugiere el escritor:

1. Do your research first.
2. Turn off the Internet.
3. Use Writeroom (program for writing text, and nothing else. They block out the rest of your computer with a black background).
4. Shut down everything else.
5. Turn off the TV.
6. Clear your desk.
7. Shut off all phones and notifications.
8. Let people know you’re in DND mode.
9. Just write.
10. Take breaks.

Les recomiendo que lean el articulo completo acá.