May 20 2010

Dos historias

Published by under Trabajo

He pasado los últimos minutos redactando una entrada para mi blog, en la cual buscaba expresar mi decepción ante un evento que tenido que presenciar.

Sin embargo, he llegado a la conclusión que es útil el detallar lo sucedido y solo me gustaría compartir con ustedes dos anécdotas  en las cuales se ejemplifica parte de lo que me ha decepcionado.

A fin de no herir susceptibilidades, omitiré nombres y cambiare algunas situaciones.

Cierta compañía líder en su segmento decidió realizar una  licitación para  obtener las mejores condiciones posibles en un desarrollo de software crítico para ellos, participo la empresa A, B y C.

Para este relato, la empresa A, es una compañía de clase mundial Nivel CMMI 3 y 5 en algunas localidades, y se encuentra dentro de las 10 empresas más importantes dentro de IT a nivel Mundial, La empresa B, es una pequeña empresa de desarrollo y consultoría en IT de Centro América, con presencia en dos países, sin certificación CMMI, la empresa C, es una compañía muy similar a la empresa A, solo que sus operaciones se centran en Asia.

Tanto la empresa A y la empresa B tienen una ventaja competitiva, conocen la operación del cliente y su plataforma tecnología, han tenido ya proyecto de desarrollo exitosos, la empresa C es totalmente nueva para el cliente.

El cliente presento el alcance del proyecto, y proporciono la información básica del sistema a desarrollar, fijo una fecha para la entrega de la propuesta económica y técnica.

En dicha fecha, las empresas A y B entregaron sus propuestas, la empresa C, presento una cotización de un sistema propietario que cumplía con la mayor parte de los requerimientos del cliente, se excusaron de no presentar una propuesta para el desarrollo pues argumentaron que no tenían todos los elementos para presentar una estimación donde el riesgo no fuera muy alto.

Como final, la empresa ganadora, pese a todos los pronósticos, fue la empresa B, quien tomo como base su inversión en I+D  para presentar una  estrategia de desarrollo que minimizaba los riesgos.

Segunda anécdota.

Cierta compañía que dispone de una área especializada en cierta tecnología, en donde sus integrantes en su gran mayoría, han estado en los últimos cuatro años realizando actividades ligadas a la misma plataforma tecnológica; se ven de pronto sin proyecto alguno, en la búsqueda de actividades facturables, les es asignado un proyecto en donde las actividades a realizar no tienen nada que ver ni con tecnología, ni mucho menos con las actividades que se han estado realizado en los últimos años.

El primer problema que se presenta es la estimación, el reto, como determinar el esfuerzo requerido para hacer algo que simplemente nunca se ha realizado, donde el equipo tiene nula experiencia, y peor aún, no cuenta con las competencias mínimas para realizar el trabajo; adicionalmente, el alcance del proyecto y el entregable no están acotados y definidos claramente.

No existe información histórica que pueda tomarse como referencia; se procede a tratar de hacer un laboratorio el cual arroga resultados que no pueden ser considerados como validos, por que no cumplen con la calidad necesaria y los tiempos de ejecución son por demás altos.

Al final de esta historia, se entrega una estimación con tiempos que no tienen sustento alguno, simplemente se realizo una estimación al vuelo, una estimación basada en dígitos oscilantes, con un riesgo por demás alto de fracaso, pero se cumple la meta, tratar de tener un proyecto que facturar.

Ambas anécdotas demuestras las decisiones tomadas por empresas diferentes en situaciones similares, en este caso, como presentar una estimación  para un proyecto en el cual no tienes las condiciones y los elementos necesarios para garantizar su viabilidad.

La condiciones del cómo se llego a la decisión de presentar o no la estimación, así como las presiones, negociaciones y violaciones a políticas internas y corporativas en ambas historias quedan fuera de este texto.

No responses yet

Nov 11 2009

El nuevo chico del barrio (Google GO)

Published by under Linux

Para aquellos que pensaron que estas fiestas navideñas estaría algo
aburridas, debo decirles que no será así.

En los días pasados (30 de Octubre) se ha liberado un nuevo proyecto de
Google, el cual promete influenciar el desarrollo de software de los
próximos años.

GO[1], es el nuevo lenguaje de programación lanzando por el gigante de
internet, y el cual cuenta con todo el apoyo del mismo, siguiendo sus
políticas, liberado bajo una licencia Open Source.

Quien esta detrás de este proyecto, para empezar el propio google,
respaldado por Rob Pike[2],  ex-investigador de AT&T, arquitecto de Plan
9[3] e Inferno[4] y actualmente Ingeniero principal en google.

GO es un lenguaje compilado, no interpretado, enfocado a las necesidades
principales de los sistemas distribuidos ( Cliente – Servidor,
multiproceso), dudo mucho que lo encontremos ligados a un RAD

Como es de esperarse, GO requiere un tiempo de madurez, de tal forma,
hoy dia solo hay versiones  para 32 y 64 bit en plataformas Unix (OS X
y Linux, sorry Windows 🙂 .)

Los invito a ver el video de presentación [5], y a seguir el desarrollo
de este nuevo lenguaje, no duden que pronto, gran parte de las API que
google libere e incluso, tal vez, el propio Chrome OS[6]. contenga
parte de su código en este nueva apuesta.

[1] http://www.golang.org
[2] http://research.google.com/people/r/index.htm
[3] http://es.wikipedia.org/wiki/Plan_9_from_Bell_Labs
[4] http://es.wikipedia.org/wiki/Inferno
[5] http://www.youtube.com/user/googletechtalks#p/u/0/rKnDgT73v8s
[6] http://es.wikipedia.org/wiki/Google_Chrome_OS

2 responses so far

Ago 09 2009

Contratar personal

Published by under Joiz

Tips para la contratación de personal en áreas  ligadas a la informática.
— Determine el perfil  que necesita, no es lo mismo un programador Jr a un Sr, y mucho menos uno con experiencia en Cobol y otro en C#
— No realice una entrevista personal hasta que se haya pasado por los siguientes filtros
Analice con cuidado los curriculum vitae de los solicitantes
Realice entrevista telefónica en donde solicite detalles de los proyectos en los que el postulante haya colaborado
Valide las referencias laborales, preste especial atención en el tipo de compañía y actividades realizadas, contacte preferentemente al departamento de RH.
— Realice un pequeño examen, ya sea de lectura de código, solución de problemas básicos o de lógica, cuestione en referencia a la implementación de algoritmos básicos asi como metodologías de desarrollo empleadas, no solo es tirar código.
— Antes de contratar, envié al prospecto a  realizar psicométricos e incluya un estudio de personalidad, nuca se sabe que loco puede estar tocando a la puerta .
— Preste atención en el desempeño del candidato en proyecto en los que deba de trabajar en equipo e interactuar con sus compañeros, en muchas ocasiones,  existen personas que solo tienen resultados exitosos cuando trabajan solas.
— En la contratación de personal con poca experiencia, busque características que pueda desarrollar dentro de su organización, La capacidad  para aprender y emplear lo aprendido es fundamental en estos casos.
— Un titulo universitario no es garantía de capacidad o de conocimiento, simplemente, indica que se concluyo con un plan de estudios, no subestime la capacidad de las personas que no se han graduado, muchos lo los mejores Hacker no terminaron la Universidad .
— Si el puesto implica la codificación, prefiera personal  relacionado a carreras tecnológicas y no administrativas, algunas carreras solo enseñan a utilizar paquetería

Tips para la contratación de personal en áreas  ligadas a la informática.

  • Determine el perfil  que necesita, no es lo mismo un programador Jr a un Sr, y mucho menos uno con experiencia en Cobol y otro en C#
  • No realice una entrevista personal hasta que se haya pasado por los siguientes filtros
  • Analice con cuidado los curriculum vitae de los solicitantes
  • Realice entrevista telefónica en donde solicite detalles de los proyectos en los que el postulante haya colaborado
  • Valide las referencias laborales, preste especial atención en el tipo de compañía y actividades realizadas, contacte preferentemente al departamento de RH.
  • Realice un pequeño examen, ya sea de lectura de código, solución de problemas básicos o de lógica, cuestione en referencia a la implementación de algoritmos básicos asi como metodologías de desarrollo empleadas, no solo es tirar código.
  • Antes de contratar, envié al prospecto a  realizar psicométricos e incluya un estudio de personalidad, nuca se sabe que loco puede estar tocando a la puerta :).
  • Preste atención en el desempeño del candidato en proyecto en los que deba de trabajar en equipo e interactuar con sus compañeros, en muchas ocasiones,  existen personas que solo tienen resultados exitosos cuando trabajan solas.
  • En la contratación de personal con poca experiencia, busque características que pueda desarrollar dentro de su organización, La capacidad  para aprender y emplear lo aprendido es fundamental en estos casos.
  • Un titulo universitario no es garantía de capacidad o de conocimiento, simplemente, indica que se concluyo con un plan de estudios, no subestime la capacidad de las personas que no se han graduado, muchos lo los mejores Hacker no terminaron la Universidad :).
  • Si el puesto implica la codificación, prefiera personal  relacionado a carreras tecnológicas y no administrativas, algunas carreras solo enseñan a utilizar paquetería

No responses yet

Jun 05 2007

Excepciones en el seguimiento de Procedimientos y Metodologías.

Published by under Trabajo

Los procedimiento definidos por una área, departamento o empresa, están encaminados a garantizar la calidad de los bienes y servicios que esta proporciona a las entidades que le solicitan dichos servicios.

Cuando, por razones políticas, se toma de decisión de saltarse ciertas fases del procedimiento, se corre un riesgo, riesgo que en todo momento debe de ser asumido por quien esta solicitando el cambio del procedimiento.

Sin embargo, cuando dicho departamento se niega rotundamente a documentar y por supuesto, a asumir el riesgo, entramos en una área en la cual ya no importa en lo mas mínimo los recursos materiales que se han invertido en definir, auditar y sobretodo llevar a cabo los procedimiento dictados incluso por quienes solicitan hacer la EXCEPCION.

Se entra en un ámbito en el cual, finalmente, se hace lo que se quiere hacer, y no lo que se debe hacer en base a las reglas definidas por los procedimientos y metodologías acordados previamente entre ambas entidades.

Ahora bien, el problema realmente se presenta cuando estas excepciones se convierten en reglas, en cuyo caso, se puede optar por una revisión y modificación al procedimiento actual.

Si aun así, después de un tiempo, se vuelve a presentar la misma problemática, no queda otra opción que garantizar los procesos de los cuales somos responsables y documentar internamente la EXEPCIONES solicitadas, con el fin, de que en algún momento dado, se pueda dar una solución de alto nivel.

Esta problemática, es el pan nuestro de cada día

No responses yet