Nos cambiamos

Ahora estoy publicando en WordPress por lo que este blog quedará sin actividad.

Visitarnos en: SWNotes

Los espero

Gracias

Brazil: IT's next India?

En este artículo se menciona que Brazil puede convertirse en la siguiente Indía en cuanto a servicios de TI en outsourcing, que por cierto de México no se hace ninguna referencia.

Brazil: IT's next India?

En México el gobierno apoya mucho a la industria de TI, ¿faltará algo?

Un cambio que quita requerimientos

Un cambio que quita requerimientos puede ser igual de complicado que uno que añade un requerimiento si estamos en una etapa avanzada. Entre las cosas que hay que observar en el impacto es la modificación a los requerimientos, los planes, las pruebas, los diseños, etc para dejar el producto congruente con la documentación y su diseño.

El impacto que resulte de dicho cambio lo debe de autorizar el comité de cambios así como el usuario. Este tipo de cambio no quiere decir que vamos a dejar de hacer actividades relacionadas con lo que se quitó, debemos de dejar los productos acorde con las nuevas circunstancias y comunicarlos.

Y la productividad?

En tiempos de sequía es cuando la eficiencia, la productividad y la calidad nos ayudan. Si en nuestra organización somos productivos y hacemos las cosas bien a la primera no deberíamos tener problemas para continuar, a menos claro, que nos quedemos sin proyectos.

Siendo productivos y eficientes no tenemos desperdicios, como por ejemplo, código que no se usará, corrección de errores que no nos dejan atender a otro proyecto. Es entonces cuando si nos pega, por que los flujos de efectivo se van cortando, y nos encontramos haciendo cosas que no aportan o no son rentables.

¿Documentar o no documentar?

Este es un tema típico que vemos en las empresas y sobre el cual es necesario aplicar el sentido común. Cuando una empresa es pequeña con equipos reducidos la documentación puede ser un peso si lo tratamos de hacer como una gran corporación, debemos de analizar que documentos nos son de utilidad, cuales tenemos compromiso de entregar y hacer esos. Todos participamos en el mismo proyecto, todos sabemos como vamos, así que no debemos de tener dificultades de comunicación.

El problema se enfrenta cuando queremos crecer y seguir trabajando como antes, el líder participa en mas de un proyecto, el desarrollador igual y ya no tenemos toda la información que necesitamos para avanzar, necesitamos DOCUMENTAR. Cuando dejamos algo a medio documentar, quien va a tener el tiempo de explicarle al que recibe el documento, y lo que no esta allí, ¿Se lo dejamos a su creatividad?, mmm problemas.

¿Cuánto es su retrabajo?

Pasado un tiempo de que inicio su mejora, ¿sabe ahora cuanto es su retrabajo en dinero y en esfuerzo?, si no lo sabe no ha avanzado mucho. El retrabajo es un buen indicador que tan bien estamos haciendo las cosas. Puede ser que estemos entregando a tiempo pero mal, o con mucho esfuerzo.

Si no mide el retrabajo, ¿Sabe en donde están mal las cosas?, ¿Está haciendo los cambios en donde deben de ser o en donde supone que son?

Generación de Líneas Base

Tocando el tema de la generación de las líneas base las he visto implementadas de dos formas, por paquetes o incremental. En por paquetes se define una línea para requerimientos o análisis, una de diseño, código, pruebas y proyecto. Aquí cada una tiene documentos propios de cada actividad, en análisis están los requerimientos, en diseño solo documentos de diseño. En la línea base de proyecto se encuentran las ultimas versiones de las líneas base generadas durantes el proyecto (análisis + diseño + etc.). La ventaja aquí es que el código queda en un paquete de línea base, el contra es que hay que mantener varias líneas base hasta terminar el proyecto.

Cuando la línea base se hace incremental en cada línea base se van sumando nuevos elementos, así en la línea base de diseño se tienen los requerimientos y los documentos de diseño. En la de código están los documentos de análisis, diseño y el código. Al final del proyecto tenemos todos los documentos del proyecto en una línea base. El detalle aquí es el manejo del código junto con todos los documentos del proyecto. Otra opción es solo sacar la línea base de código y el resto líneas base que contienen puros documentos.

Importante recordar que los documentos que están en línea base solo se actualizan por un procedimiento formal de cambios.

El iPhone disponible en México?

Esperaba la llegada el iPhone a México pero con esos precios me da pena ajena, nada que ver con lo que se paga en Estados Unidos, no esperaba que fuera igual pero el precio que tiene, el tipo de contrato, y con los servicios que se ofrece están demasiado caros. Así que tendrá que esperar.

Lo que si es que como todo en México existirán personas que lo coprarán para decir que ellos si pueden pagarlo, aún y cuando el uso que le den sea poco. Con esto se mantiene el esquema del precio caro, como sucede con el resto de los planes de celulares, la red de banda ancha, etc, etc.

¿Qué tanta formalidad tiene?

¿Qué puede repetir de proyecto a proyecto?, ¿Algo mas que el caos?. Por mas extraño que parezca existe por allí gente que aplica el modelo de cascada sin saber solo hace análisis, diseño, construye, si se puede prueba y entrega. Claro después corrige. Esto porque así siempre lo han hecho en la empresa, el objetivo es entregar no importa como.

¿Qué es lo que se le pide a un proyecto, un calendario, algo de documentación, una firma del cliente?. Puede parecer increíble pero uno de los primeros éxitos visibles de un proyecto de mejora resultan ser los requerimientos documentados. Así, con que cuenta en su organización, es muy formal o muy informal. Si no tiene nada creo que es tiempo dar formalidad a ciertos puntos que pueden ser importantes y empezará a ver cambios. De todólogos sin sentido a todólogos comprometidos.

Apuestan por el Desarrollo de Software

La semana pasada se anuncio que Motorota instalará en Monterrey un centro de desarrollo de software y con esto se incrementa la demanda de gente de sistemas, mientras que cada día hay menos gente que le interese. He preguntado a los que saben algunas de las razones de este abandono y mencionan que el fracaso de las punto Com. No se si algo tenga que ver largas jornadas de trabajo por malas estimaciones, por querer ganar el cliente o el proyecto, será?. Sobre los programas de apoyo para lograr reclutar y entusiasmar a que la gente le interese el desarrollo de software están: www.csoftmty.org, www.ti.org.mx . Ya el estado de Coahuila se unió también a esta iniciativa.

Algunos problemas con el cambio...

La mayoría de nosotros y las organizaciones aspiramos a estar mejor de lo que estamos ahora, sin embargo, no todos tenemos la voluntad de hacer las cosas necesarias para mejorar, y es un hecho que tenemos que hacer algo diferente a lo que estamos haciendo, es decir, debemos cambiar la forma de hacer las cosas.

Aún teniendo las ganas de cambiar e iniciar un cambio nos enfrentamos a muchos problemas para lograrlo, entre los que están: miedos a perder lo que hemos logrado como poder, dinero, destreza, o privilegios, salir de nuestra zona de confort, falta de seguridad, falta de información, falta de motivación, necesidades diferentes, resistencia al cambio, fallas en cambios anteriores, falta de credibilidad, falta de participación, ambiciones personales, grupos de interés, estructura, incapacidad.

Antes de iniciar un cambio en la empresa es importante ver el entorno y cuales son las condiciones, en qué nos vamos a apoyar, cuál será la estrategia, si lo que estamos buscando realmente aplica a nuestra organización y va de acuerdo a los objetivos de la misma. ¿Han existido otros intentos de cambiar?, ¿Sabemos quienes están mas dispuestos a cambiar y quienes no?, ¿Sabemos a donde queremos llegar?, ¿Tenemos un plan?

Todo esto nos lleva a aceptar nuestra realidad, en dónde estamos como organización, qué somos capaces de hacer y qué no, cuáles son nuestras debilidades y nuestras fortalezas, y a partir de allí, empezar construir.

Lo más difícil para un Sponsor en la mejora …

Un proyecto de mejora siempre debe iniciar desde arriba, con la Dirección, de otra forma sería un revolución. Si contamos con el apoyo de la Dirección, y que en muchos casos en la pequeña empresa es el dueño, ¿Qué más podríamos necesitar?

Pues resulta que no todo se mueve con el apoyo, hay que romper barreras y paradigmas en la organización, pero sobre todo aceptar la realidad. Siempre es más fácil eliminar obstáculos que empujar y en este tipo de proyectos hay que empujar un poco. Y lo primero es que la dirección acepte la realidad de que sus proyectos tardan más, que requieren más tiempo. Ponemos por ejemplo tiempos de tres meses cuando en realidad entregamos en cinco meses, ¿Por qué no decir cinco meses desde un inicio?, mm, eso es parte de la dificultad y lo tenemos que demostrar con algunos proyectos antes de que sea aceptado.

HLB

Registro de Pruebas

Me he encontrado en algunas empresas que hacen pruebas de software de manera bastante rudimentaria, muy ad-hoc. Un buen comienzo es empezar a organizarse y una de las formas es a través de una herramienta como lo es mantis (http://www.mantisbt.org/). De esta forma pueden ir aprendiendo por lo menos de los errores que comenten y que no los hagan mas, mientras trabajan en diseñar e implementar un buen proceso de pruebas.

Porque tanta complicación ...

Me he preguntado y se lo he preguntado a diferente gente, por qué si vivimos en un país en el que manejamos nombres y dos apellidos no podemos tener un estándar para no complicarnos la vida. De aplicación a aplicación vemos que unos piden un solo nombre, que otros capturan los apellidos separados, otros todo el nombre en un campo y así.

Lo mismo pasa con las direcciones y ciudades, que se supone que sería más sencillo pero es igual de complicado. Si nos vamos por el código postal resulta que no es garantía de dar con la misma colonia que nos da un cliente. Si manejamos esto en nuestro sistema podemos vivir un buen rato, pero que no nos pidan una migración a otro sistema o una interfase porque tenemos que maromas para poder transferir los datos de un sistema a otro.

Mi pregunta es, ¿Por qué no existe un estándar nacional para este tipo de cosas?, ¿Por qué perdemos tiempo definiendo cuantos caracteres tendrá un campo de nombre?

¿Cuánto se dedica al re-trabajo?

Tristemente las empresas de desarrollo miden algo más que los flujos de efectivo, muchas veces no tienen ni idea del costo del re-trabajo que se da en los proyectos. Hablan de productividad en relación a cuanto pueden hacer los equipos, pero no se fijan en la calidad con que lo hacen, por lo tanto toda esa “productividad” se pierde en la cantidad de veces que se tiene que corregir el producto que se entrego.

¿Su empresa sabe el costo del re-trabajo?, ¿Cuántas veces regresa un producto que fue entregado y cuanto tiempo se le dedico a corregir los errores?, esto tomando un solo punto de vista, otra parte esta en los cambios que suceden antes de la entrega y el tiempo que le dedicamos a ellos.

Una buena tarea es empezar a tomar esta métrica por lo menos, cuantos cambios se reciben y cuanto cuestan, cuantas veces se regresa un producto ya entregado y cuanto le dedicamos a corregirlo, así como las correcciones que se hacen resultado de las pruebas. El dato va a ser revelador e impresionante.

Una vez escuche en una platica una buena definición de calidad – “Calidad es cuando el cliente regresa y el producto no”.

Tantos problemas con la Calidad

Si hacemos la tarea de investigar de porque las cosas no salen como esperábamos, creo que todo se centra en que la gente no tenía la información necesaria para hacer sus tareas, ni contaba con la capacitación necesaria para hacerlas. Resulta que los requerimientos no estaban bien porque le que los documento, si es que lo hizo, no sabía como hacerlo de la manera correcta, el que programó resulta que no tienen una capacitación formal, no conoce se estándares, el líder de proyecto no sabe estimar, el implementador no conoce bien las plataformas en donde va a instalar. ¿El resultado?, puede que funcione, puede que no.

Si las personas que van a desarrollar el producto conocen bien que es lo que va ha ser construido, cómo va ha ser construido y tienen las habilidades técnicas para hacer el resultado será muy diferente. El detalle es que pocos quieren invertir en capacitación, en seguir un proceso, en utilizar un estándar, todo esta en función de la fecha de entrega. El punto es que otros si están haciendo la tarea y la forma artesanal de construir el software para las empresas, negocios y productos pasará a la historia.

Mejora con sentido común

Al momento de implementar las mejores prácticas de acuerdo a un modelo en ocasiones perdemos de vista el porqué lo estamos haciendo y es por el negocio y no por el modelo. Hay que aplicar el sentido común. Lo que estamos implementando como beneficia a los objetivos del negocio, como beneficia al producto o al servicio que le damos al cliente y luego como estamos cumpliendo con el modelo y no al revés. No perder de vista esto.

Calidad por convicción

Las iniciativas de calidad hay que hacerlas por convicción más que por necesidad, en el sentido de que lo hacemos por que el cliente lo exige o el mercado lo demanda. Si no hay convicción de lo que se hace resultará muy difícil de implementar y mucho más de mantener.

El esfuerzo que se le dedica para que después al final del día algún proyecto se salte los procesos por entregar a tiempo y después se premie el equipo por cumplir con el cliente no motiva a nadie. Si no hay acciones por no cumplir con nuestros compromisos es una clara señal de que esto no es importante.

Si lo hacemos por convicción estaremos enviando la señal correcta a la organización, la visión corresponde con las acciones y el compromiso es visible. Los resultados vendrán y los cambios se verán.

¿Cuantas empresas que se han certificado en algún modelo lo reafirma actualizando su certificación?