Lucas Ontivero: Opiniones

Google, muy lejos de la gente?

Mon, 21 May 2007 14:13:26 GMT

Hace poco vi este video en youtube sobre como podrían ser las futuras búsquedas en Google con un "poquito" de IA. Luego de verlo pensé que era una total y absoluta tonteria ya que el video me mostraba como podia uno conseguir una imagen de una porción de pizza que no estuviese sujeta a copyright en poco mas de 2 minutos!!!. Bueno, para mi eso me pareció muchísimo tiempo y además la forma en que se hacian las búsquedas también me pareció absurdo porque quien podría ser tan tonto de poner "I am looking for a piza please" en el google?.

La verdad es que me equivoqué y si no miren algunas búsquedas por las que llegan a mi blog:

como averiguo de cuantos bits es mi pc?
codigo de un contador de una factura en vbnet
codigo de la serie de lucas(c++)
cuales son las partes del patrón composite

Estas son cuatro búsquedas que veo en el log de visitas de hoy, y en dias anteriores (que no las puedo ver) han habido otras por el estilo. Ahora, salvo la que listo en tercera posición que ni google ni yo ni vos ni dios sabe que estará buscando esa persona, las demás son perfectamente entendibles pero google los mandó a mi blog que es lo mismo que mandarlos a la m#$%&")!$%..

Cambié de parecer y mas allá de si es posible o no llegar a esto en el corto plazo creo que es la dirección a seguir. Sin dudas!

Saludos

Satisfacción de los clientes

Thu, 21 Dec 2006 15:33:10 GMT

Una de las frases que más abundan en la literatura de los negocios de la última década es la de "satisfacción del cliente". Hay algunas conclusiones que al respecto he obtenido con mi experiencia y que voy a plasmar aquí.

Balancear las expectativas.

A la diferencia entre lo que se espera y lo que se obtiene la llamo desilusión. Esta es sin dudas la mejor métrica del fracaso. El sistema de comercialización de software, que se compone de los sistemas de remuneración de comerciales (premios/comisiones), objetivos empresariales y productos de la competencia, está aceitado para crear en los clientes altísimas expectativas que a la postre generan una altísima desepción. Aquí también cuenta la cultura de contratación de los clientes quienes sospecharían de una oferta de una Ferrari F50 a U$S 5.000 pero que a la hora de comprar quieren software muy barato y de entrega casi inmediata. Algo así como un "mentime que me gusta".

Entregar lo que el cliente realmente espera

No estamos en condiciones de hacer esto. Por qué?

El software siempre tiene errores por lo que a veces se habla de "pocos errores" o "no encontramos mas errores" como admitiendo un cierto nivel aceptable de errores pero el cliente no quiere errores ni tiene por qué aceptarlos. Imaginemos que vamos al cajero electrónico a sacar $1.000 y nos da $990 y que cuando reclamamos nos dicen "el cajero tiene un nivel aceptable de error de (+/-)10 por mil". Obviamente nadie acepta esto. Bueno, los usuarios de software si lo hacen y muchas veces en el circuito principal del flujo de una operación.
El software no se entrega a tiempo y el criterio mas común (erróneo por cierto) es que hay que entregar el software para la fecha comprometida aún a sabiendas de que contiene montones de errores. Muchas veces estas entregas se ponen en producción junto con otras aplicaciones críticas. Dos errores: (uno) el compromiso asumido no solo es en fecha de entrega sino también en calidad de la entrega. (dos) la fecha de entrega surge de una planificación inicial que no aplica en esta industria por más que en otras si lo haga.
Los proyectos software tienen un condiciones que los clientes no estás dispuestos a aceptar salvo condiciones de oportunidad o necesidad extraordinarias. Una fórmula que se puede aplicar a todo, "calidad = (tiempo * recursos) / alcances", trae un poco de lógica y calidad constante hay que sacrificar algo.

Tenemos dos clientes?

Comenzamos con una distinción, satisfacción del cliente vs. satisfacción del usuario. Sabemos que ambos determinan el éxito o el fracaso del proyecto. El problema está en que cada uno tiene su definición de "cliente".
Veamos, quien es el cliente?

Si desarrollamos un sistema de administración de recursos humanos para una empresa de servicios financieros. A quien hay que satisfacer?
- a la empresa de servicios financieros?
- al departamento de recursos humanos?
- al personal de ese departamento?
Si brindamos el outsourcing de parte de la tarea desarrollo de un producto de seguros a otra empresa que será la que comercializará el producto desarrollado. A quien hay que satisfacer?
- a la empresa a la que le realizamos partes del desarrollo del producto?
- a los clientes de la empresa?

Es decir, a quienes debemos satisfacer, a los clientes primeros o a los clientes finales, a quienes nos pagan el proyecto o a quienes beneficia el proyecto, a quienes pueden elogiar o boicotear el proyecto o a quienes podrán ascender o degradar según resulte el proyecto? Respuesta ñona: "a todos", si pero desgraciadamente los recursos son limitados por cuanto vivimos en el mundo real.

Básicamente tenemos varios clientes o clientes e intermediarios. Es que durante el ciclo de vida de un proyecto las conversaciones con el cliente no son tales sino que se habla con un representante el cual muchas veces es total o parcialmente ajeno a la problematica que se intenta resolver con el proyecto. Tipicamente son gerentes de sistemas quienes toman decisiones tales como definir los alcances de la solución y priorizarlos, opinan sobre las interfaces de usuarios que se les presentan en los prototipos y a veces hasta definen las posibles tecnologias a utilizar. Luego, cuando se lleva el soft para instalalo y capacitar a los usuarios nos pasa que en medio de una sala de capacitaciones repleta por personas que conocen al detalle sus tareas uno les comienza a explicar como operar el sistema y comienzan a notarse las caras y luego los comentarios: "Eso es obligatorio? porque la mayoria de las veces no tenemos que cargarlo", "Tantas pantallas para hacer eso? en el sistema que tenemos ahora con una basta", "puedo seguir imprimiendo con F12? porque a las teclas, los mas viejos, ya las tenemos así" y otras muchas. En ese momento te das cuenta que estuviste hablando con la persona equivocada y hay que convencer a la masa o el proyecto fracasa porque las quejas suben, las resistencias se hacen mas fuertes, los boicotes se arman y listo, si tu intermediario estaba satisfecho porque hiciste todo lo que el quería que hicieras ya no lo está mas.

Quien dijo que si se puede?

Mon, 13 Nov 2006 00:18:22 GMT

Siempre creí, y aún lo creo, que tanto las universidades, empresas y gobiernos deberían orientar y "planificar" todos sus esfuerzos hacia la creación de una masa crítica capaz de crear de bienes y servicios con el mayor valor agregado posible. Solo así se puede generar riqueza verdadera. Cabe aclarar que en la industria del software el valor agregado es, por propiedad transitiva de varios factores, resultado del conocimiento de los ingenieros.
El problema que veo es que no se trata de cualquier conocimiento sino de aquellos que, por las leyes de mercado, son mas escazos y por lo tanto mas caros. Ahora, con un peso 3 a 1 respecto del dolar y un costo en recursos humanos inferior a un octavo del costo de un informático en Estados Unidos (los invito a buscar cuanto ofrecen por un desarrollador C++) uno podría pensar que tenemos algunas ventajas pero en realidad me parece que no. El problema es que solo tomamos de cada industria aquellas tareas que menos aportan y en nuestro caso particular, son tareas de desarrollos diseñados, administrados y negociados en el exterior. Pero ojo, no cualquier desarrollo sino solamente aquellos que requieren menores aptitudes. No me imagino a ninguna empresa venir para realizar tareas de desarrollo de aplicaciones de bajo nivel. (Mi definición de "aplicaciones de bajo nivel": cualquier aplicativo que necesariamente debe codificarse con C/C++ y asm).
Y es que acá es donde veo un problema difícil: estos conocimiento están un tanto monopolizados. Y si no veamos si en Argentina se desarrollan algunas cosas similares a estas, por ejemplo:

herramientas como winzip, acrobat, winamp, quicktime
sistemas CAD/CAM,
sistemas operativos (no necesariamente para PC, podría ser para un torno),
compiladores (igual que antes; podría ser para un PLC),
tecnología de encriptación,
antivirus,
software de control, para aviación, navegación, robótica,
relacionados con IA,
para tratamiento de imágenes,
bases de datos,
emuladores,
juegos

La lista puede extenderse tanto como uno quiera pero la mayoría de estos puntos tienen un denominador común, requieren de: investigadores, equipos interdiciplicarios (matemáticos y físicos, siempre), conocimientos superiores en varios campos, dinero y lo que a mi como informático mas me interesa, desarrolladores que trabajen a bajo nivel.

El tema es que los informáticos nunca se involucran el este campo y creen que corresponde al area de conocimientos de los electrónicos. Pero, alguien a visto alguna vez código escrito por un electrónico? yo sí y déjenme decirles que es lo mas espantoso que existe sobre la faz de la tierra y solo puede ser igualado por código de un ingeniero en telecomunicaciones.

Y así fue como por ejemplo Motorola luego de su desesperada búsqueda de gente con estos conocimientos y luego de contratar hasta a electrónicos (por dios!!! en que cabeza puede entrar esto) tuvo que bajar los brazos y despertar del sueño de desarrollar a bajo nivel para hacer lo que al fin y al cabo hacemos todos, jugar con legos.