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.
martes, enero 15, 2008
viernes, enero 11, 2008
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.
miércoles, enero 09, 2008
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?
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?
jueves, noviembre 22, 2007
¿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.
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.
miércoles, noviembre 14, 2007
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
viernes, noviembre 09, 2007
¿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.
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.
miércoles, noviembre 07, 2007
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.
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.
martes, junio 26, 2007
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.
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.
martes, mayo 01, 2007
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.
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.
sábado, septiembre 23, 2006
Bases para el Desarrollo
Es muy frecuente que no se documenten correctamente los requerimientos y que estos sean acordados formalmente. Sucede porque no tenemos tiempo de documentar lo que el usuario quiere y brincamos directamente a diseñar o a programar con las consecuentes fallas. Al ser esta la primera etapa del proceso de desarrollo esta también es la primera oportunidad de incluir errores por lo que debemos de tomar las medidas necesarias para realizarla correctamente.
Para hacer bien esta tarea debemos de tener los elementos para ello, como las personas adecuadas para la obtención de los requerimientos, capacitadas en los métodos, el proceso y los artefactos a desarrollar. Debemos no solo de dejar documentados los requerimientos sino tratar de identificar todo aquello que esta entre líneas y que el usuario no nos transmite, que al considerarlos completos alguien los revise para ver si se pueden implementar, si están completos, claros y consistentes.
Con un conjunto de requerimientos documentados, completos y revisados, podemos establecer un compromiso con el cliente y con el equipo, lo que nos permite tener una base para el trabajo posterior. Aquí encontramos otro problema, no todos queremos asumir este compromiso. Si se nos olvida algo, ¿Cómo puedo cambiarlo?.
El obtener un compromiso sobre los requerimientos no significa que estos ya no se puedan cambiar, es imposible conocer con anticipación todo lo que pudiera hacer el nuevo producto o los cambios en el mercado. Lo que debemos hacer después de este compromiso es realizar los cambios de manera formal y controlada, es decir, cada requerimiento de cambio deberá ser analizado en su impacto en el proyecto y como estos pueden ser incorporados sin que el proyecto salga de control.
Con un buen proceso de obtención de requerimientos y una buena administración de los mismos podemos establecer las bases hacia una planificación, estimación y desarrollo del producto más estable y con mayores probabilidades de éxito.
Para hacer bien esta tarea debemos de tener los elementos para ello, como las personas adecuadas para la obtención de los requerimientos, capacitadas en los métodos, el proceso y los artefactos a desarrollar. Debemos no solo de dejar documentados los requerimientos sino tratar de identificar todo aquello que esta entre líneas y que el usuario no nos transmite, que al considerarlos completos alguien los revise para ver si se pueden implementar, si están completos, claros y consistentes.
Con un conjunto de requerimientos documentados, completos y revisados, podemos establecer un compromiso con el cliente y con el equipo, lo que nos permite tener una base para el trabajo posterior. Aquí encontramos otro problema, no todos queremos asumir este compromiso. Si se nos olvida algo, ¿Cómo puedo cambiarlo?.
El obtener un compromiso sobre los requerimientos no significa que estos ya no se puedan cambiar, es imposible conocer con anticipación todo lo que pudiera hacer el nuevo producto o los cambios en el mercado. Lo que debemos hacer después de este compromiso es realizar los cambios de manera formal y controlada, es decir, cada requerimiento de cambio deberá ser analizado en su impacto en el proyecto y como estos pueden ser incorporados sin que el proyecto salga de control.
Con un buen proceso de obtención de requerimientos y una buena administración de los mismos podemos establecer las bases hacia una planificación, estimación y desarrollo del producto más estable y con mayores probabilidades de éxito.
sábado, septiembre 16, 2006
Sitios
Algunos buenos sitios sobre mejora de procesos y temas de ingeniería de software son www.davidfrico.com, www.processimpact.com, o el mismo sitio del SEI http://www.sei.cmu.edu
sábado, septiembre 09, 2006
¿Funciona la mejora?
Existen múltiples artículos, investigaciones y evidencia sobre el retorno de inversión resultado de un proceso de mejora, sin embargo no hay nada mejor que verlo en nuestra propia empresa para decirlo.
Tanto se habla de los resultados que es común que la dirección se apresure a verlos cuando todavía no existe información suficiente. Para poder ver resultados necesariamente tenemos que tener mediciones, así sean básicas, pero hay que tenerlas para poder ver el avance. ¿Qué tanto retrabajo hacemos?, ¿Qué errores cometemos?, ¿Cuánto se desvían nuestros proyectos?, ¿Qué tantos errores recibimos una vez entregado al cliente el producto?.
A través de la ejecución de algunos proyectos con las mejoras implementadas y con la obtención de mediciones, tendremos la información necesaria para analizar y ver que cómo nos están ayudando las nuevas prácticas. Algo importante, es que debemos de implementar las prácticas tal y como las diseñamos para ver los resultados esperados, no hay otra forma.
Tanto se habla de los resultados que es común que la dirección se apresure a verlos cuando todavía no existe información suficiente. Para poder ver resultados necesariamente tenemos que tener mediciones, así sean básicas, pero hay que tenerlas para poder ver el avance. ¿Qué tanto retrabajo hacemos?, ¿Qué errores cometemos?, ¿Cuánto se desvían nuestros proyectos?, ¿Qué tantos errores recibimos una vez entregado al cliente el producto?.
A través de la ejecución de algunos proyectos con las mejoras implementadas y con la obtención de mediciones, tendremos la información necesaria para analizar y ver que cómo nos están ayudando las nuevas prácticas. Algo importante, es que debemos de implementar las prácticas tal y como las diseñamos para ver los resultados esperados, no hay otra forma.
viernes, junio 23, 2006
¿CMMI, Moprosoft, ISO?
Esta es una pregunta que se hacen organizaciones sobre que modelo deben se seguir, pero lo primero que debemos de preguntarnos no es sobre los modelos, sino para que los queremos.
Si estamos buscando seguir un modelo para obtener alguna acreditación, diploma o reconocimiento las probabilidades de fracaso son muy altas, más que nada por que un proyecto de mejora implica un cambio en la forma de hacer las cosas. Si queremos obtener el diploma sin cambiar la forma de hacer las cosas, simplemente no hay forma.
Así que primero debemos de preguntarnos porque queremos cambiar, ¿Qué nos duele?, ¿Qué nos hace falta?, ¿Qué queremos mejorar?, ¿Qué esperamos ser en un futuro?. Si no podemos resolver esto, si no sabemos porqué queremos cambiar, ¿Cómo vamos a soportar el cambio?
Si estamos buscando seguir un modelo para obtener alguna acreditación, diploma o reconocimiento las probabilidades de fracaso son muy altas, más que nada por que un proyecto de mejora implica un cambio en la forma de hacer las cosas. Si queremos obtener el diploma sin cambiar la forma de hacer las cosas, simplemente no hay forma.
Así que primero debemos de preguntarnos porque queremos cambiar, ¿Qué nos duele?, ¿Qué nos hace falta?, ¿Qué queremos mejorar?, ¿Qué esperamos ser en un futuro?. Si no podemos resolver esto, si no sabemos porqué queremos cambiar, ¿Cómo vamos a soportar el cambio?
sábado, mayo 20, 2006
CM - Administración de la configuración
Este tema es quizá uno de los más importantes que nadie le toma importancia hasta que empieza a relacionar algunos de los errores que suceden durante el desarrollo.
¿Alguna vez se ha topado con alguna de las siguientes situaciones?
• El producto no fue entregado completo.
• Probó un módulo equivocado.
• Estimó en una especificación que no era la última.
• Un cambio que había hecho ya no está.
• El proyecto ha tenido tantos cambios que ya no sabe cual fue el pedido original.
Estos son problemas que serían solucionados fácilmente con una buena administración de la configuración, algunos de ellos muy simples.
La administración de la configuración nos ayuda a mantener la integridad de los productos de software a través de todo el ciclo de desarrollo, esto significa que la administración de la configuración nos permite a mantener a todos nuestros productos (sistema, fuentes, documentación, manuales) consistentes con la información que contienen. Si existe un cambio este cambio se verá reflejado en todos y cada uno de los documentos afectados.
¿Alguna vez se ha topado con alguna de las siguientes situaciones?
• El producto no fue entregado completo.
• Probó un módulo equivocado.
• Estimó en una especificación que no era la última.
• Un cambio que había hecho ya no está.
• El proyecto ha tenido tantos cambios que ya no sabe cual fue el pedido original.
Estos son problemas que serían solucionados fácilmente con una buena administración de la configuración, algunos de ellos muy simples.
La administración de la configuración nos ayuda a mantener la integridad de los productos de software a través de todo el ciclo de desarrollo, esto significa que la administración de la configuración nos permite a mantener a todos nuestros productos (sistema, fuentes, documentación, manuales) consistentes con la información que contienen. Si existe un cambio este cambio se verá reflejado en todos y cada uno de los documentos afectados.
jueves, mayo 18, 2006
Revisión de los estimados
Un hecho es que no conocemos todo al inicio del proyecto. Se hace un estimado en la propuesta el cual tiene cierta probabilidad de cumplirse y dependerá de muchas condiciones, entre ellas, que tanto conocemos a nuestra organización y como hacemos uso de la historia.
Una realidad es que el estimado no debería de quedar allí, a medida que avanza el proyecto contamos con más información y por lo tanto nuestro estimado puede ser mejorado o en el peor de los casos verificar el anterior que teníamos.
Algunos puntos en donde podríamos verificar nuestro estimado serían al terminar los requerimientos y al terminar los requerimientos. Si hacemos antes un estudio de factibilidad podemos incluir un estimado en dicha actividad. Lo importante es identificar en forma anticipada los estimados que vamos a realizar en el proyecto y así como la metodología a utilizar.
Las métricas alrededor de los estimados son muy útiles para ir aprendiendo de ellos y saber cuál es nuestra desviación contra los valores reales comparando contra la propuesta, contra la estimación de requerimientos y contra la estimación de diseño, así como las desviaciones entre las diferentes técnicas utilizadas.
Una realidad es que el estimado no debería de quedar allí, a medida que avanza el proyecto contamos con más información y por lo tanto nuestro estimado puede ser mejorado o en el peor de los casos verificar el anterior que teníamos.
Algunos puntos en donde podríamos verificar nuestro estimado serían al terminar los requerimientos y al terminar los requerimientos. Si hacemos antes un estudio de factibilidad podemos incluir un estimado en dicha actividad. Lo importante es identificar en forma anticipada los estimados que vamos a realizar en el proyecto y así como la metodología a utilizar.
Las métricas alrededor de los estimados son muy útiles para ir aprendiendo de ellos y saber cuál es nuestra desviación contra los valores reales comparando contra la propuesta, contra la estimación de requerimientos y contra la estimación de diseño, así como las desviaciones entre las diferentes técnicas utilizadas.
domingo, mayo 14, 2006
¿40 hrs = 1 Semana?
¿Porque no alcanza el tiempo para terminar el programa a tiempo?, es común ver equipos que se comprometen a entregas que difícilmente van a cumplir creyendo que si lo van a hacer y además bastante convencidos. Al final resulta que no se termina a tiempo o se hizo pero a raíz de trabajar el fin de semana o quedarse más tiempo. ¿Porque no alcanza el tiempo?, simplemente porque hacemos otras actividades durante el día.
Es prácticamente imposible entregar 8 horas efectivas al proyecto durante un día y si lo hiciéramos no lo pudiéramos repetir el resto de la semana y no digamos del mes. Esto es simplemente porque realizamos otras actividades durante el día entre las que están reuniones, tomamos café, recibimos una llamada, contestamos el correo, resolvemos una duda, tantas y tantas cosas que pueden surgir en un día que hace que no tengamos toda la atención en el proyecto.
Algo aceptable a considerar que pudiéramos dedicar al proyecto sin comprometer al mismo serían 120 horas de 160 horas de un mes considerando 4 semanas. Esto da que tenemos que dar al proyecto 30 horas a la semana, es decir 6 horas la día. Quiere decir que debemos de dedicarnos el 75% del tiempo al proyecto. ¿Poco?, ¿Cuánto dedicamos en nuestra organización hacia los proyectos?, hacia actividades que son productivas, es decir, que generan dinero.
Cuando hagamos un compromiso no tomemos 40 horas de esfuerzo igual a una semana de trabajo. Es importante distinguir primeramente entre el esfuerzo y el calendario, entre el esfuerzo que podemos generar y el que podemos entregar. Conociendo esto números seguramente estaremos cumpliendo mejor con nuestros compromisos.
Es prácticamente imposible entregar 8 horas efectivas al proyecto durante un día y si lo hiciéramos no lo pudiéramos repetir el resto de la semana y no digamos del mes. Esto es simplemente porque realizamos otras actividades durante el día entre las que están reuniones, tomamos café, recibimos una llamada, contestamos el correo, resolvemos una duda, tantas y tantas cosas que pueden surgir en un día que hace que no tengamos toda la atención en el proyecto.
Algo aceptable a considerar que pudiéramos dedicar al proyecto sin comprometer al mismo serían 120 horas de 160 horas de un mes considerando 4 semanas. Esto da que tenemos que dar al proyecto 30 horas a la semana, es decir 6 horas la día. Quiere decir que debemos de dedicarnos el 75% del tiempo al proyecto. ¿Poco?, ¿Cuánto dedicamos en nuestra organización hacia los proyectos?, hacia actividades que son productivas, es decir, que generan dinero.
Cuando hagamos un compromiso no tomemos 40 horas de esfuerzo igual a una semana de trabajo. Es importante distinguir primeramente entre el esfuerzo y el calendario, entre el esfuerzo que podemos generar y el que podemos entregar. Conociendo esto números seguramente estaremos cumpliendo mejor con nuestros compromisos.
miércoles, mayo 10, 2006
¿Cómo vender los estimados?
Siempre que nos llega una solicitud de un nuevo sistema o requerimiento generamos un estimado del esfuerzo, tiempo y costo que nos va a tomar solucionar dicha necesidad. Este estimado, el cual es nuestra mejor aproximación a la realidad, es parte de nuestra propuesta o control de cambios que presentado al cliente. ¿Cómo manejamos esto?
El problema inicial surge en como presentamos este estimado, y no tiene nada que ver con el estimado en sí mismo. Típicamente se presenta el estimado como tal, entendiendo que quedará claro al usuario con la explicación que podamos hacer al presentarlo. Se incluyen como valores estimados las horas, tiempo y costo, lo que generalmente se toma como el deber ser, no importa que tanto conversemos con el usuario al respecto.
Para trasmitir mejor el mensaje podemos poner indicar que lo mostrado es un estimado y tiene un porcentaje de desviación o certeza (p.ej. +/- 20%) de lo que se esta indicando. Sería mejor si se incluye el porcentaje de certeza y los rangos de los estimados en estos porcentajes de certeza. Siempre indicando que de surgir algún cambio en estos estimados serían comunicados al cliente para tomar acciones correctivas o un plan de acción.
Parte del trabajo es también vender estos estimados para que quede claro y acordado entre el equipo y el cliente que se esta trabajando sobre un estimado y que este puede bajar o subir dependiendo de cómo se va ejecutando el proyecto y los ajustes que se van presentando y que su presupuesto se base en estos estimados.
Es posible que no nos funcione a la primera pero hay que trabajar con los clientes en función de esto y nunca dar estimados al aire por que esto nos tira por los suelos todo nuestro trabajo ganado.
El problema inicial surge en como presentamos este estimado, y no tiene nada que ver con el estimado en sí mismo. Típicamente se presenta el estimado como tal, entendiendo que quedará claro al usuario con la explicación que podamos hacer al presentarlo. Se incluyen como valores estimados las horas, tiempo y costo, lo que generalmente se toma como el deber ser, no importa que tanto conversemos con el usuario al respecto.
Para trasmitir mejor el mensaje podemos poner indicar que lo mostrado es un estimado y tiene un porcentaje de desviación o certeza (p.ej. +/- 20%) de lo que se esta indicando. Sería mejor si se incluye el porcentaje de certeza y los rangos de los estimados en estos porcentajes de certeza. Siempre indicando que de surgir algún cambio en estos estimados serían comunicados al cliente para tomar acciones correctivas o un plan de acción.
Parte del trabajo es también vender estos estimados para que quede claro y acordado entre el equipo y el cliente que se esta trabajando sobre un estimado y que este puede bajar o subir dependiendo de cómo se va ejecutando el proyecto y los ajustes que se van presentando y que su presupuesto se base en estos estimados.
Es posible que no nos funcione a la primera pero hay que trabajar con los clientes en función de esto y nunca dar estimados al aire por que esto nos tira por los suelos todo nuestro trabajo ganado.
domingo, febrero 19, 2006
¿Qué hacemos con los tecnólogos?
El desarrollo de la tecnología en los últimos años ha tenido un crecimiento impresionante lo que ha hecho que prácticamente hagamos uso de ella en todas nuestras actividades diarias, desde lo más sencillo como puede ser para atender un semáforo, un cajero automático, una caja registradora en el supermercado hasta los sofisticados sistemas médicos, bancarios o de control aéreo.
El que la tecnología este presente en muchas actividades nos ha llevado en algunos casos a enfrentarnos a ella, o bien para utilizarla o para implementarla. Esto nos lleva a que nos demos cuenta de que no siempre la utilicemos u obtengamos el provecho necesario para realizar nuestras tareas o para facilitarlas. Es común ver, por ejemplo, filas de gente para pagar servicios pudiendo pagar estos por Internet, o bien siendo atendido por un empleado de mostrador el cual no nos puede encontrar en el Sistema.
El desconocer la tecnología de los sistemas de información nos lleva también a no saber como estos nos pueden ayudar, que podemos obtener de ellos y como nos pueden facilitar nuestras actividades. El problema se agrava al tener que nosotros solicitar o desarrollar un sistema de información que soluciones nuestros problemas en el que este desconocimiento nos lleva a no saber que pedir, como hacerlo o que esperar. Gran parte de esta incertidumbre se genera porque lo que manejamos es un intangible, no como hacer un mueble o una casa en los que podemos sentir y ver lo que se esta construyendo.
El propósito aquí es ver todo lo que involucra el desarrollar un sistema de información, cuál es su proceso, cómo podemos asegurarnos que nos va a ser de utilidad, como interactuar con las personas que nos van a ayudar a lograr la solución y ver que estamos en el camino correcto a lograrlo. Estaremos tocando diferentes temas para ir entendiendo los diferentes términos, métodos y herramientas que es utilizada por los tecnólogos para desarrollar los sistemas y de esta manera poder lograr un mejor entendimiento con ellos logrando mejores resultados.
El que la tecnología este presente en muchas actividades nos ha llevado en algunos casos a enfrentarnos a ella, o bien para utilizarla o para implementarla. Esto nos lleva a que nos demos cuenta de que no siempre la utilicemos u obtengamos el provecho necesario para realizar nuestras tareas o para facilitarlas. Es común ver, por ejemplo, filas de gente para pagar servicios pudiendo pagar estos por Internet, o bien siendo atendido por un empleado de mostrador el cual no nos puede encontrar en el Sistema.
El desconocer la tecnología de los sistemas de información nos lleva también a no saber como estos nos pueden ayudar, que podemos obtener de ellos y como nos pueden facilitar nuestras actividades. El problema se agrava al tener que nosotros solicitar o desarrollar un sistema de información que soluciones nuestros problemas en el que este desconocimiento nos lleva a no saber que pedir, como hacerlo o que esperar. Gran parte de esta incertidumbre se genera porque lo que manejamos es un intangible, no como hacer un mueble o una casa en los que podemos sentir y ver lo que se esta construyendo.
El propósito aquí es ver todo lo que involucra el desarrollar un sistema de información, cuál es su proceso, cómo podemos asegurarnos que nos va a ser de utilidad, como interactuar con las personas que nos van a ayudar a lograr la solución y ver que estamos en el camino correcto a lograrlo. Estaremos tocando diferentes temas para ir entendiendo los diferentes términos, métodos y herramientas que es utilizada por los tecnólogos para desarrollar los sistemas y de esta manera poder lograr un mejor entendimiento con ellos logrando mejores resultados.
Suscribirse a:
Entradas (Atom)
Entradas
