Negociando con un cliente difícil

En una época negocie con un cliente que no tenía mucha idea de lo que es desarrollar software, aunque hace años que estaba en el negocio, y una vez había sido altamente exitoso, pero luego tuvo que vender su empresa debido a varios problemas.

Finalmente creó un nuevo emprendimiento, para la cual necesitaba que le estimemos un producto que quería desarrollar en mi anterior trabajo.

Primero le hicimos una propuesta y el nos la devolvió con un recorte de 30% de las horas y agrego bastante funcionalidad, algo que no cierra por ningún lado que uno lo mire.

Luego quiso acelerar los tiempos:

Client: I'm assuming that if you can do things faster that the price would go down, right?

Myself: No, faster means getting more people involved, the cost would be similar.

Pensar que acelerar el tiempo de entrega reduce los costos no es algo muy sabio que digamos en ingeniería de software, ya que esto requiere mayores esfuerzos, más gente. Obviamente hay límites o cotas inferiores para acelerar el tiempo, ya que no se puede poner a nueve mujeres a tener un bebe en un mes, se necesitan nueve meses.

Facturandole al cliente 600 horas de mas por error

En mi anterior trabajo tuvimos un grave problema con el cliente de un proyecto al enviarle la factura con ~600 horas de mas. Generalmente se facturaban ~1200 horas por mes, pero una vez le enviamos al cliente una factura con ~1800 horas, lo que hizo sonar muchas sirenas. El problema fue que yo le enviaba al account manager o mi representante del sector comercial una planilla Excel con todas las horas el primero de cada mes y el mandaba los datos al área administrativa para que se confeccione la factura.

En la planilla había dos secciones, una del equipo interno y otra del equipo externo del proyecto. Cada equipo sumaba mensualmente ~600 horas. El account manager sumo dos veces las horas de alguno de los equipos, dando la cuenta ~1800 en vez del usual ~1200.

El cliente llamo para preguntar y corregimos rápidamente el error. Este incidente no causo muchos problemas, pero internamente fue muy grave ya que no se quería tener ningún problema con ese cliente debido a varias particularidades. Desde ahí ayude al account manager con el reporte de horas y eso no volvió a pasar.

Fanático del HTML

Sin palabras

Como lidiar con un compañero de trabajo temperamental

En una época tuve problemas con el líder técnico de un proyecto donde trabaje, digamos que su humor era cambiante y había veces que no sabia manejar el tema. Por suerte esto se resolvió. El tema se debía a una situación particular que fue solucionada.

Tuve una charla con mi 'coach' Jeffrey sobre el tema donde me dio su valiosa opinión:

1/3/2007		6:17:05 PM		MArtin		Jeffrey V.		human resources related question... how do you deal with a moody coworker?
1/3/2007		6:17:42 PM		Jeffrey V.		MArtin		Define moody.
1/3/2007		6:17:51 PM		Jeffrey V.		MArtin		Bipolar or schizophrenic?
1/3/2007		6:19:20 PM		MArtin		Jeffrey V.		that's too much... sometimes JM is in a bad mood, with his headphones listening to angry punk music and not wanting to speak to anybody, and when someone speaks to him, he seems kind of angry, like saying "back off fucker"
1/3/2007		6:19:57 PM		Jeffrey V.		MArtin		Uh, sometimes people are just in bad moods. Let it be their problem as long as it doesn't impact work.
1/3/2007		6:20:59 PM		Jeffrey V.		MArtin		When it does impact work, you say, hey, your bad mood is your problem, but now it's becoming the client's problem and that's not acceptable. Do you work and save the attitude for your own time.
1/3/2007		6:22:34 PM		Jeffrey V.		MArtin		If the person is regularly bipolar, then you need to demonstrate the problem such that they acknowledge and recognize the problem exists. At that point, you just come to an agreement -- you get the person to agree that you will point out to them when they're exhibiting the behavior they already acknowledge such that everyone gets back to work.
1/3/2007		6:22:55 PM		Jeffrey V.		MArtin		NB: this does *not* work with women and PMS.
1/3/2007		6:24:39 PM		MArtin		Jeffrey V.		PMS?
1/3/2007		6:29:00 PM		Jeffrey V.		MArtin		Premenstrual stress.
1/3/2007		6:29:19 PM		Jeffrey V.		MArtin		What do you call it in Spanish?
1/3/2007		6:29:20 PM		MArtin		Jeffrey V.		LOL
1/3/2007		6:29:45 PM		Jeffrey V.		MArtin		Yeah, much to the chagrin of men everywhere.
1/3/2007		6:30:34 PM		MArtin		Jeffrey V.		thanks for those words dude, really good
1/3/2007		6:33:22 PM		Jeffrey V.		MArtin		What do you call premenstrual stress in Spanish?
1/3/2007		6:36:58 PM		MArtin		Jeffrey V.		sindrome premestrual
1/3/2007		6:38:17 PM		Jeffrey V.		MArtin		Your welcome. I've used it successfully for years. You have to reach a point where you're able to call people on their behavior. If they don't acknowledge the issue exists, then they just get more pissed off. But once you get them to recognize the issue, then calling them on it just becomes humorous and lightens everyone's mood.

Ponerse en los zapatos del cliente al redactar informes

Generalmente cuando uno esta trabajando en un proyecto hace bastante, ya tiene todo en la cabeza y cuando tiene que dar explicaciones por algo, o hacer un informe, o reportarle algo a un cliente, deja de lado detalles importantes que uno cree que el cliente los tiene en la cabeza en ese momento, pero no siempre es así. En realidad, casi nunca es así. El cliente puede estar manejando decenas de proyectos y no estar al tanto de un tema puntual del proyecto donde uno trabaja.

La solución a esto es tratar de ponerse en le lugar del otro y relatar los informes, los mails o cualquier otro tipo de comunicación con el mayor detalle posible, con mucho cuidado de caer en obviedades, ya que es posible que tanto detalle le haga pensar al cliente que uno cree que es tonto o algo por el estilo. Si uno redacta adecuadamente, no surgirán este tipo de problemas, siempre siendo muy amable y yendo al punto, sin olvidar detalles.

Los clientes agradecen estas cosas:

Thanks for your detailed and to-the-point communication. This is the type of leadership we need on your side for our team. Keep up the good work.

Informe a enviar al cliente luego de encontrar un problema

Cuando hay un problema que afecta al cliente, por un error que se cometió, por algo que no se tuvo en cuenta pero el cliente no esperaba que se nos pasase por alto o se pensó implícitamente que había que hacer cierta cosa pero no se hizo, hay que enviar un reporte al cliente cuanto antes.

Este reporte debe abarcar mínimamente los siguientes puntos:

• Causa del error, que es lo que se hizo o se venia haciendo que causo el problema.
• Que pasos o medidas se tomaron para resolver el error
• Cuando va a estar este tema resuelto (si es que aun no se pudo resolver).
• Que medidas se tomaron o se van a tomar en el futuro para que no vuelva a pasar esto.

En resumen, hay que contar que paso y dejar al cliente tranquilo que este tipo de errores no van a ocurrir de nuevo, con esto casi seguro uno se puede salvar de una mala situación, enfrentando los errores y trabajando para solucionarlos y para que nunca vuelvan a ocurrir.

Broma conjunta con el cliente al gerente de ventas

En mi anterior trabajo, el primero de abril (April's fool Day) de 2007, se me ocurrió hacerle una broma al gerente de ventas con complicidad de nuestro contacto con el cliente en Estados Unidos.

Justo era un momento bastante inestable por problemas que habíamos tenido con el cliente, y venia posponiendo un viaje que había anunciado.

Le dije al contacto del cliente que llame al gerente de ventas diciéndole que estaba en Ezeiza con el cliente, y acepto a hacerlo.

Encendió un televisor y sintonizo un canal de televisión latino para que se escuche castellano de fondo y llamo. Le comento que estaba en Ezeiza con el vice presidente de ingeniería del cliente, que lo pase a buscar.

Esto puede sonar descabellado, pero nuestro contacto era una persona bastante impredecible, así que podía llegar a hacer eso en cualquier momento.

El gerente le creyó y se puso muy nervioso, yo estaba ahí cerca, aguantándome para no decirle y cuando se puso el saco y se disponía ir al aeropuerto le tuve que decir.

Fue un momento muy grato el equipo y para mí, no tanto para el gerente de ventas. Los clientes que ayudan a hacer bromas son muy valiosos.

El query de la #%&^*@!!!

Recuerdo que hace bastante cuando estábamos desarrollando una librería de software en mi primer trabajo, teníamos problemas para entender al cliente y para que el cliente nos entienda a nosotros.

Un día encontraron un supuesto error que realmente no era un error, pero nos costaba mucho explicarles porque no y realmente se notaba que no tenían el suficiente tiempo o ganas de leer cuidadosamente nuestra solución.

El tema es que para descubrir esto había que realizar una consulta sobre la base de datos, y cuando descubrimos una consulta que pudo resolver el tema, el líder de desarrollo del equipo me mando el mail con la consulta o query en SQL.

Como estábamos apuradísimos con los tiempos, y realmente cansados de este tema, el desarrollador demostró su enojo escribiendo en el 'subject' del mail una mala palabra, y yo realmente ni le preste atención.

Inmediatamente le mandamos el query a nuestro contacto en Estados Unidos que era el contacto del cliente. Esta persona también estaba bajo presión y reenvió el mail sin cambiar nada.

Yo me di cuenta unos minutos después y le avise a mi contacto para que se disculpe. Recibí retos de su parte, pero fue un error en conjunto, ya que ambos ignoramos el titulo del mail.

Por suerte este incidente no causo problemas, pero podría haberlo hecho. Todo depende del cliente, pero hay que ser muy cuidadoso en las comunicaciones, mas cuando vienen de los desarrolladores (Broma!).

Xobni: Email organization, search, and navigation for your Outlook inbox

Xobni es una aplicación que se integra a Outlook y la vengo usando hace unas semanas en mi trabajo. Realmente es muy buena, cambia la forma de usar el Outlook. Siempre esta la necesidad de ver mails anteriores, y realmente Outlook no tiene ninguna funcionalidad muy practica para esto.

Xobni (Que es Inbox escrito al revés) es una 'sidebar' que permite rápidamente ver, buscar y abrir mails y archivos adjuntos viejos. Organiza los mails por persona, y también por conversación, ya que permite agrupar los mails como gmail. Al instalarlo se toma su tiempo para indexar todos los mails de tu casilla, pero luego funciona rapidísimo, dándote resultados instantáneamente.

Otra de las cosas muy interesantes que trae son estadísticas de mails, o sea quien manda a mas horas, detalle de trafico entrante saliente, por semana, mes, año, etc.

Mirá un video introductorio a la aplicación:

Gracias Juampi por la recomendación!

The Wisdom of Crowds

"The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How Collective Wisdom Shapes Business, Economies, Societies and Nations" es un libro de James Surowiecki editado en 2004 que trata de demostrar que en muchos casos mucha gente tiene mas razón que una persona en particular, por mas calificaciones que tenga. Realmente no es un libro que tenga que ver sobre la ingeniería de software, pero se relaciona en cuanto a los equipos de trabajo. Si un equipo de trabajo es muy homogéneo, realmente no hay muchas posibilidades de que aparezcan distintas opiniones, que la gente pelee por sus ideas, pero la heterogeneidad ayuda mucho en esto. Es un libo muy interesante para aprender como reacciona positivamente o negativamente la gente en distintas situaciones.

Les dejo un resumen de las ideas principales del libro de wikipedia:

Tipos de sabiduría de las masas: El autor clasifica las ventajas de las decisiones no organizadas en tres categorías principales:

• Cognición: Juicio de mercado, que puede ser mucho más rápido, más confiable, y menos sujeto a fuerzas políticas que las deliberaciones de los expertos, o comités específicos.
• Coordinación del comportamiento, como optimizar la utilización de restaurantes populares, o prevenir los choques en el flujo del tránsito. El libro está lleno de ejemplos de economía experimental, pero esta sección depende más de experimentos que suceden naturalmente, como peatones optimizando el flujo sobre el pavimento, o el excedente de gente en restaurantes populares. Examina cómo la percepción común en una cultura permite juicios notablemente precisos sobre reacciones específicas de otros miembros de la cultura.
• Cooperación: Cómo los grupos de gente pueden formar redes de confianza sin que un sistema central controle su comportamiento o directamente fuerce su acatamiento. Esta sección es especialmente favorable al libre mercado.

Cuatro elementos requeridos para formar una masa sabia: No todas las masas (grupos) son sabias. Considere, por ejemplo, a las multitudes o a inversionistas enloquecidos en un crecimiento-burbuja del mercado accionario. ¿Qué criterio clave separa las masas sabias de aquellas irracionales?

• Diversidad de opinión: Cada persona debería tener información privada aún si es sólo una interpretación excéntrica de los hechos conocidos.
• Independencia: Las opiniones de la gente no deberían ser determinadas por las opiniones de los que los rodean.
• Descentralización: La gente debería poder especializarse y recurrir al conocimiento local.
• Combinación: Existen algunos mecanismos para convertir los juicios privados en decisiones colectivas.

Fallas de la inteligencia de la masa: Surowiecki estudia situaciones (como Crecimientos-burbuja) en las que la masa produce un juicio muy malo, y argumenta que en ese tipo de situaciones la cooperación de la inteligencia falló porque (de una u otra manera) los miembros de la masa eran demasiado conscientes de las opiniones de los demás y empezaron a emularse unos a otros más que a pensar por sí mismos. Proporciona resultados experimentales de masas influenciadas por un orador persuasivo, lo que le lleva a la conclusión de que la principal razón por la que los grupos actúan de manera uniforme es que el sistema de decisión presenta una falla sistémica. Surowiecki asegura que lo que ocurre cuando el entorno de toma de decisiones no está preparado para aceptar al grupo es que se pierden los beneficios de los juicios personales y la información privada, y el grupo sólo puede lograr el nivel de acierto de su miembro más capaz, en lugar de superar dicho nivel, como se demuestra en el libro que es posible en otros casos. Casos detallados de fracasos históricos incluyen:

• Demasiada centralización: el desastre del cohete Columbia, del que el autor del libro culpa a una burocracia demasiado jerarquizada en la NASA, totalmente cerrada a la sabiduría de los ingenieros de bajo rango.
• Demasiada división: La comunidad que forman los cuerpos de inteligencia americanos fue incapaz de evitar los ataques del 11 de Septiembre de 2001 en parte porque la información que poseía una subdivisión no era accesible a otra. El argumento de Surowiecki es que los grupos (en este caso el de analistas de los cuerpos de inteligencia) trabajan mejor cuando escogen por sí mismos el tema de su trabajo y la información que necesitan. Para reforzar este punto de vista cita el aislamiento del virus SARS como ejemplo de un caso en el que el libre flujo de información permitió a los laboratorios del mundo coordinar sus búsquedas.
• Demasiada imitación: Donde las decisiones sean visibles y hechas en secuencia, puede producirse una "catarata de información" en la que sólo los primeros en tomar decisiones pueden ganar algo al contemplar las decisiones disponibles: una vez que esto ha ocurrido, para el resto de agentes decisores puede ser más útil limitarse a copiar a aquellos a su alrededor.

Unit Testers Get More Chicks

En mi nuevo trabajo el cliente pide todos los desarrollos con pruebas unitarios. ¿Que son las pruebas unitarias? De wikipedia:

En programación, una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión. La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.

Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:

• Automatizable: no debería requerirse una intervención manual.
• Completas: deben cubrir la mayor cantidad de código.
• Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.
• Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.
• Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

Aunque estos requisitos no tienen que ser cumplidos a rajatabla, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.

Luego encontré un articulo muy entretenido que es de un desarrollador que cree que convertirse en un desarrollador orientado a pruebas unitarias (test-driven) es lo mejor que puede hacer para mejorar su rutina, y estas son sus razones:

1. Though counterintuitive, I swear that it makes you code faster. No one tends to believe me on this, but most test-driven developers come to this realization eventually. The reason is simple: you spend much less time debugging the 935 errors from your two-hour code sprees.
2. The tests are my memory. My head is too full of all the languages, frameworks, APIs, and family birthdays I am expected to know to remember everything I’ve ever done on top of that. This week at work I’ve touched three separate projects all with over 1,000 lines of code. I’m sure I had good ideas when I wrote those lines, but now I doubt I can tell you what they are. My tests can though. They remember so I don’t have to. If I go into the code and change something I don’t remember was needed or why, my tests will remind me immediately.
3. In team development, my test-powered memory even travels to the machines of the other developers! How cool is that? When someone goes into the code and says, “Why on Earth did James do this? We don’t need this. I’m going to change that…” my tests will look after my interests for me.
4. I’m a lot more confident in my software. I use to say things like, “I just finished this, so it hasn’t been used much yet and probably still has plenty of issues.” Now by the time I finish something my tests have been using the heck out of it. I won’t kid you and tell you that my software now springs fully formed from the head of my tests, but it definitely comes out farther along the track.
5. Environment changes seldom surprise me anymore. When I move my software to a different box and it can’t cope for whatever reason, I not only know the first time I run the tests, I have an excellent idea of exactly where the problem is.

Trac: Plantilla del mail para informar a un nuevo usuario sus credenciales

Cuando se desea agregar a un usuario nuevo al Trac (un software de administración de proyectos web con una interface a un repositorio Subversion que recomendé anteriormente) conviene tener un mail preparado para esos casos, para no tener que escribir siempre lo mismo.

Un nuevo usuario se agrega cuando se suma una persona al equipo o alguien nuevo quiere acceder a la información del proyecto, del lado del cliente o de la empresa donde uno trabaja.

El mail podría ser el siguiente:

NNNN,

Here's the link to the project server and your login information

http://yourtrac.com

User & pass:

NNNN
NNNNPass

Trac is a project server for managing project work via tickets, it has a roadmap to plan milestones, a wiki interface for communication and most importantly, communication to a subversion repository. In the main wiki, instructions to download the repository are posted.

It also has a timeline which shows everything going on (commits, tickets ) so people can be aware of everything at once, and it has a RSS feed to publish that information.

Regards,

Entrega del proyecto luego de la cancelación

Luego de la cancelación del proyecto de la cual escribí ayer (leer), llego la entrega completa del proyecto al cliente. Ellos tenían acceso a todo ya que tenían un usuario de la pagina web de administración del proyecto (Trac) y el repositorio donde guardábamos todo lo que se producía para el proyecto, pero necesitaban una entrega formal explicando bien todos los componentes mas importantes del software y la documentación sobre los procesos utilizados.

Estas fueron veinte horas de trabajo luego del pedido del cese de actividades por parte del cliente, que uno piensa que se hicieron con mala gana y con bajísima prioridad, dándole mucha mas importancia a los nuevos proyectos que habíamos sido asignados, pero yo realmente me tome el tiempo necesario y fui muy cuidadoso y correcto (como instruí al resto de los compañeros que ayudo en este traspaso) ya que quise dejar la mejor imagen de nosotros y de la empresa, pensando que si ellos en el futuro tenían alguna necesidad con respecto al área, pensasen en nosotros ya que les dejamos una excelente imagen.

Cancelación abrupta de un proyecto

El proyecto mas largo y grande en el cual trabaje comenzó el 19/4/2006 y finalizo el 1/2/2008. La finalización del proyecto fue abrupta, ya que no lo esperábamos. Resulta que estábamos creando una librería con el propósito de ser el soporte de un software de manejo de licencias, pero al final este software, que estaba siendo desarrollado por el cliente fue cancelado, junto con nuestra librería. El proyecto llego a contar con 8 personas trabajando internamente y 12 realizando tareas sobre la base de datos, desde sus hogares a cualquier hora del día.

Recuerdo que justo se cancelo mientras estaba yo de vacaciones. El cliente de USA envió una carta por correo firmada, citando las razones ya mencionadas, felicitando nuestro trabajo, pero pidiendo cesar todas las actividades a fin de mes. El proyecto fue larguísimo y en modalidad T&M (time and materials), lo que implica que se cobraba por hora trabajada, y no se tenia ningún tipo de contrato ni tiempo asegurado el trabajo, el cliente podía hacer cesar los trabajos cuando quería.

Y así paso, recuerdo que ese día que volví de vacaciones mis compañeros me hicieron sentar y me contaron la noticia, que fue un gran golpe por todo el tiempo que me había llevado el proyecto, y el cariño que le tenia al equipo. Gracias a dios logre desconectarme totalmente en las vacaciones y no revise el mail, ya que sino me hubiese enterado y no hubiese sido agradable.

Luego fuimos todos reasignados y seguí trabajando con alguno de mis compañeros. Lo que mas lastima me dio fue que justo estábamos por lanzar una versión nueva del sitio para trabajar sobre la base de datos, con un procedimiento para mejorar el trabajo del equipo externo, y habíamos estado medio año trabajando sobre ellos, y nunca llegamos a verlo en acción para comprobar los resultados, quedo todo en la nada. Realmente frustrante para los que se empeñaron para lograr completar esa nueva versión, que estaba al 90% (Realmente al 90%, no estábamos sufriendo el síndrome del 90%).

Termino este artículo con el aspecto positivo, que fue cambiar de proyecto, ya que aunque no estábamos aburridos ni estancados, habíamos estado mucho tiempo con lo mismo, y un poco de aire fresco viene muy bien.

UML: La importancia de no desviarse de los estandares

Hace poco recomendé al Enterprise Architect como herramienta para modelar UML (Leer Artículo). Ese programa permite modelar con muchas estándares además de UML, lo que es bueno porque te da muchas posibilidades pero también es un arma de doble filo porque uno se ve tentado a utilizar para modelar items que no son estándares. Esto me paso varias veces, por lo cual recomiendo siempre tener un libro o usar la web como referencia para pegarse al estándar.

Muchas veces queda mejor utilizar algún recuadro, pero esto es producto nuestro. Una persona puede no estar pensando en lo mismo y nuestro desvío puede producir un efecto negativo, que no entiendan el diagrama o que lo entiendan mal.

Hay que respetar los lenguajes de modelado, de la misma manera que se respeta el idioma por ejemplo, ya que es una forma de comunicación visual sobre el software a construir

Destruyendo un servidor Linux localizado en un datacenter en Canada

No hace mucho en mi anterior trabajo, me asignaron para que le instale Trac, un software de administración de proyectos web con una interface a un repositorio Subversion que recomendé anteriormente. Realmente lo manejo bien, se instalarlo, configurarlo, customizarlo con plugins, manejar el http.conf del apache para publicar otros sitios, entonces me eligieron por eso.

El tema es que tenía que instalarlo en un Linux. Siempre había instalado todo en Windows Server 2003. Tengo experiencia sobre Linux por la facultad, realmente me cae bien el sistema operativo del pingüinito, aunque admito que uso Windows por comodidad.

Igual ese no fue el problema. El problema fue que tenía que instalarlo en un servidor remoto, y solo tenía acceso SSH, que es una simple línea de comando (bajar cosas de internet con una línea de comando no es nada divertido, repito, nada divertido!). Al enterarme eso avise que no era el más apto para la tarea, pero confiaron en mí y yo seguí con la tarea, tratando de dar lo mejor.

Igualmente me llene de frustraciones, me costaba mucho hacer algo, no soy amigo de las consolas ara trabajar en línea de comando y me sentía mal. Estaba siguiendo un tutorial de internet, que más o menos servía. Para instalar Subversion tenía que cambiarle los permisos a una carpeta, no me acuerdo bien porque. Está claro que era administrador, tenía la password del usuario root del Linux. Entonces use el comando “CHMOD 000 /” o algo similar. Ese comando le quita todos los permisos de lectura y escritura a todos los usuarios. Al terminar de correrse ese comando simplemente no pude hacer mas nada, nada de nada, ni correr un “ls” para listar los archivos. Creo que es lo peor que se le puede hacer un Linux, ya que todos los comandos son archivos.

La empresa del cliente estaba en California. El servidor con el Linux al cual yo me conectaba por SSH estaba en un datacenter en Canada. El cliente tuvo que llamar (y pagarle) a alguien para que instale el sistema operativo de nuevo. Gracias a dios el servidor estaba vacío, no tenía datos, sino la cosa hubiese resultado mucho más oscura. Al cliente se le había dicho el riesgo de ponerme a hacer esa tarea, así que las consecuencias no fueron graves. Al final contrataron a alguien competente para hacer la tarea, y me dejaron a mí para que configure el Trac, ya estando este funcionando y utilizando un usuario no root para que no pudiese volver a hacer lo que hice. Para cerrar el tema con una nota graciosa, la password que me asignaron fue: “P3nd3j0”.

Principios de diseño de Google

Vuelvo a citar a Google en este articulo, para nombrar los diez principios de diseño que tomaron. Ellos se esmeran en lograr un balance armoniosos de todos los principios para satisfacer a los usuarios. Acá están:

1. Focus on people – their lives, their work, their dreams.

The Google User Experience team works to discover people's actual needs, including needs they can't always articulate. Armed with that information, Google can create products that solve real-world problems and spark the creativity of all kinds of people. Improving people's lives, not just easing step-by-step tasks, is our goal.

Above all, a well-designed Google product is useful in daily life. It doesn't try to impress users with its whizbang technology or visual style – though it might have both. It doesn't strong-arm people to use features they don't want – but it does provide a natural growth path for those who are interested. It doesn't intrude on people's lives – but it does open doors for users who want to explore the world's information, work more quickly and creatively, and share ideas with their friends or the world.

2. Every millisecond counts.

Nothing is more valuable than people's time. Google pages load quickly, thanks to slim code and carefully selected image files. The most essential features and text are placed in the easiest-to-find locations. Unnecessary clicks, typing, steps, and other actions are eliminated. Google products ask for information only once and include smart defaults. Tasks are streamlined.

Speed is a boon to users. It is also a competitive advantage that Google doesn't sacrifice without good reason.

3. Simplicity is powerful.

Simplicity fuels many elements of good design, including ease of use, speed, visual appeal, and accessibility. But simplicity starts with the design of a product's fundamental functions. Google doesn't set out to create feature-rich products; our best designs include only the features that people need to accomplish their goals. Ideally, even products that require large feature sets and complex visual designs appear to be simple as well as powerful.

Google teams think twice before sacrificing simplicity in pursuit of a less important feature. Our hope is to evolve products in new directions instead of just adding more features.

4. Engage beginners and attract experts.

Designing for many people doesn't mean designing for the lowest common denominator. The best Google designs appear quite simple on the surface but include powerful features that are easily accessible to those users who want them. Our intent is to invite beginners with a great initial experience while also attracting power users whose excitement and expertise will draw others to the product.

A well-designed Google product lets new users jump in, offers help when necessary, and ensures that users can make simple and intuitive use of the product's most valuable features. Progressive disclosure of advanced features encourages people to expand their usage of the product. Whenever appropriate, Google offers smart features that entice people with complex online lives – for instance, people who share data across several devices and computers, work online and off, and crave storage space.

5. Dare to innovate.

Design consistency builds a trusted foundation for Google products, makes users comfortable, and speeds their work. But it is the element of imagination that transforms designs from ho-hum to delightful.

Google encourages innovative, risk-taking designs whenever they serve the needs of users. Our teams encourage new ideas to come out and play. Instead of just matching the features of existing products, Google wants to change the game.

6. Design for the world.

The World Wide Web has opened all the resources of the Internet to people everywhere. For example, many users are exploring Google products while strolling with a mobile device, not sitting at a desk with a personal computer. Our goal is to design products that are contextually relevant and available through the medium and methods that make sense to users. Google supports slower connections and older browsers when possible, and Google allows people to choose how they view information (screen size, font size) and how they enter information (smart query parsing). The User Experience team researches the fundamental differences in user experiences throughout the world and works to design the right products for each audience, device, and culture. Simple translation, or "graceful degradation" of a feature set, isn't sufficient to meet people's needs.

Google is also committed to improving the accessibility of its products. Our desire for simple and inclusive products, and Google's mission to make the world's information universally accessible, demand products that support assistive technologies and provide a useful and enjoyable experience for everyone, including those with physical and cognitive limitations.

7. Plan for today's and tomorrow's business.

Those Google products that make money strive to do so in a way that is helpful to users. To reach that lofty goal, designers work with product teams to ensure that business considerations integrate seamlessly with the goals of users. Teams work to make sure ads are relevant, useful, and clearly identifiable as ads. Google also takes care to protect the interests of advertisers and others who depend on Google for their livelihood.

Google never tries to increase revenue from a product if it would mean reducing the number of Google users in the future. If a profitable design doesn't please users, it's time to go back to the drawing board. Not every product has to make money, and none should be bad for business.

8. Delight the eye without distracting the mind.

If people looked at a Google product and said "Wow, that's beautiful!" the User Experience team would cheer. A positive first impression makes users comfortable, assures them that the product is reliable and professional, and encourages people to make the product their own.

A minimalist aesthetic makes sense for most Google products because a clean, clutter-free design loads quickly and doesn't distract users from their goals. Visually appealing images, color, and fonts are balanced against the needs for speed, scannable text, and easy navigation. Still, "simple elegance" is not the best fit for every product. Audience and cultural context matter. A Google product's visual design should please its users and improve usability for them.

9. Be worthy of people's trust.

Good design can go a long way to earn the trust of the people who use Google products. Establishing Google's reliability starts with the basics – for example, making sure the interface is efficient and professional, actions are easily reversed, ads are clearly identified, terminology is consistent, and users are never unhappily surprised. In addition, Google products open themselves to the world by including links to competitors and encouraging user contributions such as community maps or iGoogle gadgets.

A greater challenge is to make sure that Google demonstrates respect for users' right to own and control their own data. Google is transparent about how it uses information and never shares data outside Google without a user's explicit consent. Our products warn users about such dangers as insecure connections, different privacy policies on other websites, actions that may make users vulnerable to spam, or the possibility that data shared outside Google may be stored elsewhere. Google is reassuring but truthful about data sharing so that users can make informed choices. The larger Google becomes, the more essential it is to live up to our "Don't be evil" motto.

10. Add a human touch.

Google includes a wide range of personalities, and our designs have personality, too. Text and design elements are friendly, quirky, and smart – and not boring, close-minded, or arrogant. Google text talks directly to people and offers the same practical, informal assistance that anyone would offer to a neighbor who asked a question. And Google doesn't let fun or personality interfere with other elements of a design, especially when people's livelihood, or their ability to find vital information, is at stake.

Google doesn't know everything, and no design is perfect. Our products ask for feedback, and Google acts on that feedback. When practicing these design principles, the Google User Experience team seeks the best possible balance in the time available for each product. Then the cycle of iteration, innovation, and improvement continues.

Ver fuente del articulo acá.

Trac: Página wiki para especificar los tipos de tickets

Continuando el post de ayer donde se enunciaba una pagina Wiki para el trac para especificar los componentes, pienso que también es útil especificar los tipos de tickets, para que cualquier persona que cargue tickets pueda tener bien en claro esto.

Los tipos generales pueden ser:

Defecto: Este tipo debe ser usado cuando se encuentran defectos en algún componente del proyecto (discutido en el post de ayer). Un defecto se define comúnmente como una no conformidad del software a sus requerimientos.

Mejora: Este tipo debe ser usado cuando sugerencias o mejoras se hacen sobre algún componente del defecto.

Tarea: Este tipo debe ser usado cuando una tarea es pedida para el proyecto y no se clasifica como alguna de las anteriores.

Obviamente que cada proyecto es un mundo aparte y tiene sus particularidades y porque no, su propios tipos de tickets y Trac permite configurarlos.

Trac: Página wiki para especificar los componentes del proyecto para el sistema de tickets

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, la descripción de todos los componentes del proyecto a los que puedan ser seleccionados en un ticket. Muchas veces estos son varios y una sola palabra no los termina de definir adecuadamente, para eso esta descripción.

Generalmente un componente de un proyecto en un sistema de tickets es una parte del proyecto sobre la que se trabaja. Se puede crear un ticket seleccionando este componente, cuando se desee realizar un cambio.

Trac permite al administrador administrar (valga la redundancia) los componentes del proyecto.

Esta pagina serviría de guia para cualquier interesado del proyecto, y seria muy útil para nuevos miembros del equipo que no estén familiarizados con el proyecto.

Diez razones por las que todos deberíamos usar LinkedIn

Recién me encontré con este interesante articulo, que da diez razones para usar LinkedIn, una red social que recomendé en un post anterior. Soy un usuario de LinkedIn y como verán pueden ver mi perfil en esa pagina si hacen click en el link situado debajo de mi perfil en este blog.

Les dejo las razones, para mas detalles les recomiendo que lean el articulo completo acá:

1. LinkedIn te puede generar más negocios, más oportunidades de trabajo y más dinero.
2. Te ayuda a mantener contacto directo con los líderes y referentes de tu industria y sector.
3. Te permite estar en contacto con profesionales y que ellos te encuentren a tí.
4. Puedes ser recomendado por otros conocidos, partners o profesionales de tu sector.
5. Puedes obtener respuestas a tus preguntas de otros profesionales. Incluso puedes participar de consultas de otros.
6. Lo puedes utilizar como tu curriculum vitae online y que te descubran por él.
7. En definitiva es cómo tener tu propio sitio web, corporativa o profesionalmente hablando.
8. Te ayuda a estar al día, conocer los movimientos de los personajes del sector puede ser muy útil.
9. Puedes incluir una foto tuya, para que te reconozcan por ella si no recuerdan tu nombre y referencias.
10. Es bien privado. No se puede hacer spam facilmente, ni se puede vulnerar las principios de anonimato que el usuario haya elegido tener.

Los desarrolladores no leen libros!

Hace poco me encontré con un interesante articulo que quiero compartir. Este enuncia que los desarrolladores no leen libros y esto es cierto para la mayoría de los desarrolladores que conozco. Inclusive, el autor del articulo escribió un libro y paradojicamente no piensa que valga la pena que alguien lo compre,

If programmers don't learn from books today, how do they learn to program? They do it theold-fashioned way: by rolling up their sleeves and writing code -- while harnessing the collectivewisdom of the internet in a second window. The internet has rendered programming booksobsolete. It's faster, more efficient, and just plain smarter to get your programming information online.

Leer el articulo completo acá.

Código de Etica de la Ingeniería

de Algo que rescate de la aburrida materia de ejercicio legal y profesional de la ingeniería fue el códigoética. Ya había comentado el código de ética de la ingeniería del software, el cual es de la IEEE. Les dejo las partes mas importantes a mi parecer del código de ética loca, que engloba a todas las ingenierías, la agrimensura y la arquitectura. Es interesante ver la legislación actual sobre el tema en Argentina.

La ETICA PROFESIONAL es el conjunto de los mejores criterios y conceptos que debe guiar a la conducta de un sujeto por razón de los más elevados fines que puedan atribuirse a la profesión que ejerce.

Las REGLAS DE ETICA que se mencionan en el presente Código no implican la negación de otras no expresadas y que puedan resultar del ejercicio profesional consciente y digno.

Contribuir con su conducta profesional y por todos los medios a su alcance, a que en el consenso público se FORME Y SE MANTENGA un exacto concepto del significado de la profesión en la sociedad, de la dignidad que la acompaña y del alto respeto que merece.

No ejecutar actos reñidos con la buena técnica, aún cuando pudiere ser en cumplimiento de órdenes de autoridades, mandantes o comitentes.

No utilizar sin autorización de sus legítimos autores y para su aplicación en trabajos profesionales propios, ideas, planos y demás documentación pertenecientes a aquellos.

No difamar ni denigrar a colegas, ni contribuir en forma directa o indirecta a su difamación o denigración con motivo de su actuación profesional.

No ofrecer, por medio alguno, la prestación de servicios cuyo objeto, por cualquier razón de orden técnico, jurídico, reglamentario, económico o social, etc., sea de muy dudoso o imposible cumplimiento, o si por sus propias circunstancias personales el profesional no pudiere satisfacer.

Dedicar toda aptitud y atender con la mayor diligencia y probidad los asuntos de su cliente.

Leer el código completo acá.

Buenas costumbres al momento de escribir o contestar un email

La guia que aparece a continuación la escribí cuando estaba a cargo de un proyecto donde trabajaba con un equipo externo a la empresa (cada uno con mails servidor, lo que facilitaba la posibilidad que no les llegue el mail). Este equipo llego a ser de doce personas, entonces se complicaba el envío de instrucciones sobre las tareas a realizar, ya que había veces que aludían que no llegaban estas instrucciones. También si respondían no lo hacían a todos, y esto complicaba las comunicaciones en el equipo. Parece una guia para niños de como utilizar el mail, pero hay mucha gente que no conoce estos lineamientos. Lamentablemente el éxito que obtuve con este procedimiento no fue tan bueno como esperaba.

Esta guia intenta dejar en claro como proceder con los mails que reciban del equipo interno.

Cuando envían un mail, incluyan la dirección de la gente a la que va dirigido el mail en el campo "hacia" . Generalmente la dirección de la gente que va en el campo hacia tiene que tomar acción sobre el mail. Si hay gente que quieren que estén enterados de lo que escriben en el mail, pero no son los que tienen que tomar acción sobre lo recibido, escriban sus direcciones en el campo "copia". Cuando reciben un mail, si estan en el campo "copia", es porque quieren que se enteren de los temas del mail, pero no es requerido tomar accion.

Cuando reciban un mail (ya sea que este dirigido a ustedes solamente o a varias personas mas), respondan siempre con una afirmacion y algun comentario de ser necesario.

Al responder el mail, si la respuesta necesita ser leida por todos a los que les fue enviado, presionen el boton "responder a todos", para que todos lean su respuesta. Caso contrario, si la respuesta solo concierne al remitente, usen el boton "responder".