¿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?

¿Menos creatividad con procesos?

Este es uno de los cuestionamientos o barreras para implementar un proceso para lo cual primero deberíamos de preguntarnos, ¿para que se contrató a la gente?, para innovar o para sacar el trabajo. La mayoría de los casos es por el segundo, por lo que con un proceso deberíamos ser capaces de sacar más trabajo.

Por otro lado un proceso debería ser capaz de hacer que lo que hacemos siempre lo hagamos de forma consistente con un resultado esperado, y que nos de tiempo de innovar en lo que necesita. Sin proceso, metidos en el caos, no podemos ni innovar, ni nada, lo que hacemos es sobrevivir. Así que el decir que el proceso mata a la creatividad no es un buen punto.

Moprosoft

La norma mexicana de calidad de software MOPROSOFT se puede encontrar en el NYSE (Normalización y Certificación Electrónica, A.C.), también aquí pueden ver las empresas verificadas en esta norma. http://www.nyce.org.mx/dictamenes.htm

¿Qué tanto analizar para la propuesta?

Me comentan que tienen el problema que lo que ponen en la propuesta muchas veces dista mucho de lo que realmente es, por lo que el proyecto inicia ya con problemas. ¿Cómo podemos disminuir esto?, haciendo más análisis. ¿Cuánto?, lo que estemos dispuestos a invertir de esfuerzo y tiempo, dado que no seguro que vendamos la propuesta.

Si este proceso de pre-análisis lo fortalecemos con guías, técnicas de entrevista, de búsqueda de información, así como criterios que nos digan cuando necesitamos analizar más, será más redituable. Por supuesto que la persona que hace esta actividad debe de estar capacitada.

El registro de estas actividades nos dirá si con el tiempo invertido esta siendo suficiente para hacer una buena propuesta, la efectividad de las propuestas y de la información que se recaba en primera instancia.

Los estimados de mi Jefe

Hacemos nuestro mejor esfuerzo en la estimación, utilizamos herramientas, puntos de función, casos de uso, etc, para sacar un estimado que más se ajuste a la realidad y resulta que cuando vamos por la autorización con el Jefe nos quita horas a diestra y siniestra, ¡Qué hacemos!. … DOCUMENTAR.

Esto sucede porque no tenemos historia para refutar los recortes del Jefe, si empezamos a documentar los estimados y como nos fue en la ejecución del proyecto, podemos ir generando la historia. Con estos datos podemos ir viendo cual estimado fue más parecido al resultado real, el de la propuesta, después de requerimientos, el estimado del Jefe. La más seguro que no sea el del Jefe, aún y cuando el siempre tenga la razón, pero ahora nosotros tenemos los DATOS.

Los cambios no son fáciles

Cuando vemos los beneficios que otras empresas han recibido por el uso de una metodología, de un proceso o herramienta se nos olvida por todo lo que la otra empresa tuvo que pasar para lograr los beneficios. Queremos los resultados pero no siempre queremos pasar por el proceso.

Antes de embarcarnos en la nueva aventura o de hacer el desembolso es necesario preguntarnos si lo que vemos es para nosotros, si nos va a funcionar, si es lo que buscamos como negocio y hasta donde seremos capaces de soportarlo. ¿Podemos perder algunos negocios?, ¿Alguna gente?, ¿Algún dinero?

Si estamos decididos el siguiente paso sería plantear los objetivos, hacer la estrategia, el plan para alcanzar, formar el equipo, los indicadores y empezar a trabajar. En la ejecución debemos de mantenernos en la estrategia y revisar nuestros indicadores par ir tomando las decisiones adecuadas.

Items de configuracion

Una actividad básica de la administración de la configuración es identificar los ítems de configuración o todos aquellos artefactos de los que mantendremos su integridad. Entre estos ítems están el plan de desarrollo, los requerimientos, el plan de pruebas, el plan de calidad o el plan de configuración mismo.

Generalmente se identifica como item de configuración cualquier artefacto o documento que es utilizado por el equipo o afecta el desarrollo de actividades posteriores. Al administrarlo y comunicar su estado podemos asegurar que todos estamos trabajando sobre la misma versión del mismo.

Otro punto a considerar es que aquellos ítems identificados solo pueden ser modificados a través de un control de cambios formal. No cualquier persona puede cambiar estos artefactos sin avisar ya que impactará al resto del equipo.