Así no se hacen las cosas por Ernesto Kiszkurno

Sin querer hacer de este post una defensa de los servicios off-site por sobre los servicios off-shore, sí quería marcar 3 razones que podrían pesar a la hora de tener que decidir cómo conformar equipos de trabajo geográficamente distribuidos (ETGD). Las tres están relacionadas con un factor clave de éxito en proyectos donde el factor humano es el predominante: la comunicación entre los miembros del equipo. Razón número 1: La posibilidad de hacer reuniones presenciales Por un lado sabemos que interactuar cara a cara es mejor que hacerlo telefónicamente, por chat o por correo electrónico. Hay múltiples razones y estudios que lo prueban. Por otro, existe una importante tendencia (que asumo inevitable en este post) hacia la formación de ETGD y a la tercerización, motivada principalmente en el ahorro de costos. Ahora bien, una cosa es ahorrar costos descentralizando o tercerizando funciones y otra es negarnos la posibilidad de interactuar cara a cara.  En la mayoría de los proyectos con

He postulado una charla en la conferencia virtual de la revista Software Gurú llamada “¿Cómo organizar un equipo de pruebas usando Kanban?”. Para registrarse o conocer detalles pueden seguir este link . La conferencia será el 6 de abril próximo. Si les interesa el tema regístrense, es gratuita. Seguimos pensando..

Uno de mis socios siempre dice que un proyecto es exitoso cuando el cliente para el que trabajamos contrata el siguiente. Esto tiene que ver con que las empresas de consultoría exitosas saben que la fórmula para un negocio sustentable es construir relaciones de confianza en el largo plazo con sus clientes, y que dichas relaciones deben verificarse por medio de sucesivos proyectos conjuntos. A partir de esta premisa y, en el proceso de adquirir nuevos clientes, es normal ser sometido como proveedor a ciertas pruebas de confianza . Por ejemplo tendremos que mostrar habilidad técnica para el tema en cuestión o vocación de negocios a la hora de fijar los precios de nuestros primeros servicios. En respuesta a esta inversión del proveedor, el cliente lo recompensará con nuevos proyectos o menores exigencias en las siguientes contrataciones (por ejemplo no requiriendo procesos licitatorios para cada contratación). Se trata, como en tantos otros órdenes de la vida, de generar

En los mercados de deuda entre países se maneja el concepto de riesgo-país o riesgo soberano . Dicha medida permite a los inversores fijar una tasa de interés particular para ese país, a la hora de prestarle su dinero. La idea detrás de esto es que los países se van haciendo una cierta “fama” en el mundo, la cual repercute en el sobrecosto que pagarán sobre los prestamos que solicitan. Si el país hace las cosas mal, la tasa sube. Si hace las cosas bien, la tasa baja [1]. Mi hipótesis es que entre empresas ocurre algo similar a la hora de contratar servicios de consultoría: Cuando un cliente solicita una cotización por un servicio a un determinado proveedor, este último aplica una tasa de riesgo sobre la cotización del servicio en función de dos elementos clave: El historial de relación entre ellos , que tiene que ver con los proyectos conjuntos rodados en el pasado. Si fueron grandes, rentables, exitosos, etc. La fama del cliente en el mercado , que tiene que ver con la fama que

En los mercados de deuda entre países se maneja el concepto de riesgo-país o riesgo soberano . Dicha medida permite a los inversores fijar una tasa de interés particular para ese país, a la hora de prestarle su dinero. La idea detrás de esto es que los países se van haciendo una cierta “fama” en el mundo, la cual repercute en el sobrecosto que pagarán sobre los prestamos que solicitan. Si el país hace las cosas mal, la tasa sube. Si hace las cosas bien, la tasa baja [1]. Mi hipótesis es que entre empresas ocurre algo similar a la hora de contratar servicios de consultoría: Cuando un cliente solicita una cotización por un servicio a un determinado proveedor, este último aplica una tasa de riesgo sobre la cotización del servicio en función de dos elementos clave: El historial de relación entre ellos , que tiene que ver con los proyectos conjuntos rodados en el pasado. Si fueron grandes, rentables, exitosos, etc. La fama del cliente en el mercado , que tiene que ver con la

Hay mercados que intimidan. Estoy pensando en países-mercado y en industrias-mercado (dándole un sentido amplio a la palabra). Intimidan porque uno cree que no tiene nada “diferente” para ofrecer o que son muy grandes o que son muy exigentes o que tiene mucho para perder o todo al mismo tiempo. Pero no hay que dejarse. Siempre podemos extrapolar experiencia de otros lugares o empezar "en pequeño" mitigando los riesgos. La cuestión principal para entrar es animarse . Luego, lo demás viene. Dicho esto, también es cierto que hay que pensar en qué puedo darle yo a ese mercado . No se puede subestimar el problema y asumir que lo que funcionó en un lugar funcionará en otro o caer en un optimismo injustificado diciendo que "como me fue bien en XXX, seguro me va a ir bien acá". Para cada mercado target elegido hay que hacer el ejercicio de desarrollar una estrategia tomando decisiones y luego salir al ruedo a testearla. El Times ha hecho esto con su estrategia de suscr

Siempre ha sido difícil vender la necesidad de hacer testing sistemáticamente, y sobre todo en ciertas latitudes del mundo. Pero resulta más complicado aún cuando, además, no hay errores en el ambiente de producción [1] . Parte de la explicación puede encontrarse en esa idea de que “no hay nada mejor para facilitar un cambio que una buena crisis ”. En un contexto en el que se debe tomar la decisión inicial de introducir actividades de testing de software en un área de desarrollo o no, tener problemas en el ambiente productivo inclina la balanza hacia el sí. Dado un proceso de desarrollo que produce software con bajo nivel de errores en producción – es decir que el usuario no tiene grandes quejas respecto a lo entregado – ¿por qué sería necesario encarecer los costos del proceso introduciendo nuevos controles? A continuación ofrezco 3 argumentos: El primer argumento es el de la disminución de riesgo potencial . El hecho de tener un proceso de desarrollo que no haya producido softwar

Seguramente alguna vez llegaron al final del día laboral con esa sensación amarga de que no han logrado hacer todo lo que se habían propuesto. Bueno, a veces no es todo el día pero sí una mañana o una buena porción de tiempo. En situaciones como estas uno se pregunta ¿qué hizo con su tiempo? Hoy leyendo este de Harvard Business Review me encontré con un concepto interesante que creo puede ayudar a luchar contra este problema cambiando un poco el eje de la cuestión. El concepto en cuestión es el de “time-stealers” (o robadores de tiempo). Según el artículo los time-stealers “can be in the form of demanding people, routine or unnecessary meetings or tasks, or even your own bad habits” . Si bien todos los time-stealers mencionados son dignos de análisis, uno de ellos me hizo reflexionar: demanding people . ¿Quién no ha tenido un colega roba-tiempo? Es decir alguien que interrumpe constantemente para hacer preguntas off-topic . Pensando en esto tal vez la pregunta correcta debería ser

Todavía recuerdo la primera vez que me encargaron hacer una estimación de esfuerzo. Se trataba de un testing funcional que debíamos hacer sobre un desarrollo de otro proveedor. En retrospectiva fue divertido y desafiante pero en aquel entonces los primeros minutos de trabajo sobre la tarea fueron bastante tensos puesto que no tenía idea por donde empezar. Sin embargo, y luego de un rato de meditación sobre el asunto, la hoja en blanco se rompió y la cosa empezó a fluir [1]. La cantidad de métodos para estimar esfuerzo de testing funcional es inmensa. Particularmente a mi me gusta combinar siempre dos enfoques: top-down y bottom-up. Llamo enfoque top-down a calcular el esfuerzo de testing a partir del esfuerzo total del proyecto o el esfuerzo estimado de desarrollo. La forma de implementarlo es hacer una cuenta del estilo "el testing debe ser el XX% del esfuerzo estimado para desarrollo". Dependiendo del contexto de proyecto y el software a testear, este XX puede ir desde e

A lo largo de estos años trabajando en consultoría he llegado a la conclusión de que existen cierto patrones o templates de proyectos que tienden a repetirse a lo largo del tiempo y de los clientes. Un ejemplo de esto es el de tipo “rescate de…” . Este patrón implica tomar una situación descontrolada en un cliente, entenderla, controlarla paulatinamente y luego enmarcarla en un proceso de trabajo predecible. El valor agregado en estos casos pasa principalmente por tener la capacidad de rescatar al cliente de su lío interno y no tanto por el tipo de actividad en juego en dicho lío . Si hablamos de un mantenimiento de software por ejemplo, el valor no está tanto en desarrollar software sino en manejar la situación de cómo es el proceso alrededor de dicha actividad. El otro día leí aquí un párrafo que me recordó a esta idea que acabo de mencionar. Lo transcribo para clarificar: Let’s take a closer look at the SIT methodology for new product development (NPD). At the heart of this met

En la entrada anterior llamada 3 ejemplos de como presentar tu estrategia de negocio en una página mostré ejemplos de estrategias en una página. Aquí quiero contar el origen de la idea, que por supuesto no es mía. Hace algo más de un año atrás encontré un post del blog Church of the Customer en el que mostraba un business plan de exactamente una página. Se trataba de un diagrama jerárquico que relacionaba objetivos, metas, estrategias y tácticas en forma de árbol. Por ese entonces andaba leyendo mucho sobre estrategia y me pareció una idea excelente. Por un lado, si era capaz de lograr plasmar mi estrategia en una página, comunicarla iba a ser mucho más sencillo. Después de todo, ¿cuánto podía tardar en explicar una página a alguien? Y además, ¿no era que una imagen valía más que mil palabras? Por la negativa, si NO era capaz de plasmar mi estrategia en una página, tenía un problema "estratégico". A partir de eso tomé como regla que en cualquier análisis estratégico qu