Si necesitan trabajar con previsión , y con una herramienta simple task coach es de lo mejor
Organizo mi tiempo , prioridades , con calificaciones , filtros y todo lo habitual pero de una manera sencilla. pueden bajarlo de www.taskcoach.org , es gratuito
Requerimientos de software ,desarrollo de software,business process,ingenieria de software, servicios a empresas,consultores,software factory,estrategia
viernes, 28 de enero de 2011
martes, 25 de enero de 2011
proyectos imposibles quick kill
En una vieja drdobbs journal encontré el concepto quic-kill project o proyecto de calendario imposible
Un proyecto imposible es una aberración conceptual.
porque solo se hacen proyectos factibles o posibles los otros no .
independientemente de lo que ese buen articulo quiso decir (todavía lo encuentran si se busca quick kill project) Se trata de un proyecto:
1-recargado
2-mal planificado
Siempre la excusa es la urgencia , y la urgencia es eso: una excusa . El articulo de la revista plantea una organizacion alrededor de tres "documentos"
1-vision and socpe document que no es mas que la formulación de los objetivos del proyecto
2-estructuración de las actividades en red jerárquica
3-revisiones de código
Un proyecto recargado es (traducido a algún concepto conocido ) un proyecto donde todos los caminos se han vuelto críticos. es decir no hay ningún camino con holguras , si se atrasa cualquier actividad todo el proyecto se atrasara por lo menos en esa cantidad de atraso (mínimo)
Entendamos: los recursos están saturados todo el tiempo , es decir el contenido de las actividades es solo el básico (core) cualquier aspecto de coordinación o plantificación u entumezcan es inaplicable porque no hay tiempo!. Y los jefes consideran que deberían estar terminados ayer !
En el ámbito del software dicen que son proyectos sin gerenciacion , es decir llevado adelante por programadores (es que no queda otra no hay tiempo para trabajos de managment)
Estos proyectos son una verdadera calamidad , no puede salir nada bueno al final de ellos.
Los escritores confían en que con la ayuda espiritual de los objetivos, con la concentración en actividades esenciales y con la disciplina de las revisiones estructuradas , quizás puedan completarse exitosamente.
Exitosamente porque conseguirán los resultados (nada mas), es decir se hará código que ejecuta lo requerido , pero segurisimo no es el mejor programa posible . Porque todo es incertidumbre.
Dice: que en estos proyectos un miembro no sabe ni por donde empezar.
Mi interpretación es simple: aunque nada tiene sentido , porque los objetivos no son claros , las actividades no las podemos completar y tampoco podemos dar una mínima garantía de calidad de lo que estamos haciendo . En ese desorden hay un sentido: seguramente los objetivos están confusos entonces busquemos los resultados y/o metas para adivinar los objetivos . Solo encaremos actividades posibles o sea que tienen un principio , un fin , un esfuerzo posible y un producto tangible (en nuestro mundo intangible). Y ya que los plazos no dan para control de calidad , hagamos lo mínimo : revisiones de código.
Todo esta mal porque los elementos esenciales de un proyectos son los resultados esperados , una red de actividades factibles que aseguran el producto o resultado y un método que sea verificable. En medio de todo esto hablan de las estimaciones
Recodemos que las actividades humanas están enmarcadas en un contexto social y de necesidades personales. Oralmente el que no conoce tiende a tomar como buena una estimación del trabajo de robot o maquina . Ese es el contenido esencial o básico o mecánico de la actividad (si hiciéramos solo eso durante las 24 hs habría que tener en cuenta por ejemplo que vamos al baño , que necesitamos hidratarnos , que hay que desentumeserse y así .....) Y como sabremos entonces cuales son las restantes ? aparte de estudiar , hay que basarse en observaciones por lo menos de actividades parecidas y ejecutadas por un tiempo considerable . Caso contrario históricamente la subestimacion es de un 50% , en el caso de gente con experiencia alrededor del 30%
Tenga en cuenta también que el paso de una actividad a otra requiere (para software ) entre 11 a 30 minutos (tiempo de preparación)
Un proyecto imposible es una aberración conceptual.
porque solo se hacen proyectos factibles o posibles los otros no .
independientemente de lo que ese buen articulo quiso decir (todavía lo encuentran si se busca quick kill project) Se trata de un proyecto:
1-recargado
2-mal planificado
Siempre la excusa es la urgencia , y la urgencia es eso: una excusa . El articulo de la revista plantea una organizacion alrededor de tres "documentos"
1-vision and socpe document que no es mas que la formulación de los objetivos del proyecto
2-estructuración de las actividades en red jerárquica
3-revisiones de código
Un proyecto recargado es (traducido a algún concepto conocido ) un proyecto donde todos los caminos se han vuelto críticos. es decir no hay ningún camino con holguras , si se atrasa cualquier actividad todo el proyecto se atrasara por lo menos en esa cantidad de atraso (mínimo)
Entendamos: los recursos están saturados todo el tiempo , es decir el contenido de las actividades es solo el básico (core) cualquier aspecto de coordinación o plantificación u entumezcan es inaplicable porque no hay tiempo!. Y los jefes consideran que deberían estar terminados ayer !
En el ámbito del software dicen que son proyectos sin gerenciacion , es decir llevado adelante por programadores (es que no queda otra no hay tiempo para trabajos de managment)
Estos proyectos son una verdadera calamidad , no puede salir nada bueno al final de ellos.
Los escritores confían en que con la ayuda espiritual de los objetivos, con la concentración en actividades esenciales y con la disciplina de las revisiones estructuradas , quizás puedan completarse exitosamente.
Exitosamente porque conseguirán los resultados (nada mas), es decir se hará código que ejecuta lo requerido , pero segurisimo no es el mejor programa posible . Porque todo es incertidumbre.
Dice: que en estos proyectos un miembro no sabe ni por donde empezar.
Mi interpretación es simple: aunque nada tiene sentido , porque los objetivos no son claros , las actividades no las podemos completar y tampoco podemos dar una mínima garantía de calidad de lo que estamos haciendo . En ese desorden hay un sentido: seguramente los objetivos están confusos entonces busquemos los resultados y/o metas para adivinar los objetivos . Solo encaremos actividades posibles o sea que tienen un principio , un fin , un esfuerzo posible y un producto tangible (en nuestro mundo intangible). Y ya que los plazos no dan para control de calidad , hagamos lo mínimo : revisiones de código.
Todo esta mal porque los elementos esenciales de un proyectos son los resultados esperados , una red de actividades factibles que aseguran el producto o resultado y un método que sea verificable. En medio de todo esto hablan de las estimaciones
Recodemos que las actividades humanas están enmarcadas en un contexto social y de necesidades personales. Oralmente el que no conoce tiende a tomar como buena una estimación del trabajo de robot o maquina . Ese es el contenido esencial o básico o mecánico de la actividad (si hiciéramos solo eso durante las 24 hs habría que tener en cuenta por ejemplo que vamos al baño , que necesitamos hidratarnos , que hay que desentumeserse y así .....) Y como sabremos entonces cuales son las restantes ? aparte de estudiar , hay que basarse en observaciones por lo menos de actividades parecidas y ejecutadas por un tiempo considerable . Caso contrario históricamente la subestimacion es de un 50% , en el caso de gente con experiencia alrededor del 30%
Tenga en cuenta también que el paso de una actividad a otra requiere (para software ) entre 11 a 30 minutos (tiempo de preparación)
jueves, 28 de octubre de 2010
sin compresion no hay acuerdos
hoy un programador decia:"...no hay comprension de textos ....digo una cosa interpretan otras", muchos se solidarizaron
Pero el problema no esta bien formalizado y eso dara lugar a incompresion , porque no es comprension de texto(una cosa del colegio) sino semantica lo que falla.
Es decir y en un dialgo deberia haber un diccionario comun , yo escribo algo y el que lo lee interpreta exactamente lo que quise decir
Suena bien?
IMPOSIBLE !!!!
Cada termino citado por mi , es referenciado a mi diccionario, tiene el sentido que yo conozco y no otro...... algo mal? , algo nuevo? ,algo sobervio?, nada de eso
Es el viejisimo problema de los estudiantes de ingenieria (masa-peso,fuerza , sistema , energia etc) en un viejisimi libro cuando estudiaba termodinamica el autor al principio hacia una cita de "Alicia en el pais de las maravillas" algo que dijo un personaje:"...cuado yo digo algo digo exactamente lo que yo quiero decir..." creo que eso decia un conejo.
Somos todos conejos hoy ! cada uno con su diccionario y sus lamentos por la incompresion de los otros y sin hacer mucho esfuerzo por entender.
Mientras escribo esto vi de reojo el traste de un libraco de access 97 , enorme ,el autor empezaba diciendo :"tanto para escribir y tan poco timpo para leer....."
En muchas cosas estamos abrumados por la data , el volumen de datos disponible es impresionante. Los manuales tecnicos nunca mas los leo, se leen las busquedas sobre versiones digitalizadas , sino impòsible, eso hace que no entienda los conceptos del autor , solo sus datos , pero es lo minimo que se puede hacer. Para que esos datos tengan algun sentido los filtro a traves de mi modelo de eso . Y si no tuviera modelo? fuiste! hoy no se puede aprender de cero
Esto no es mas que catarsis , creo que en los dominios en los que somos expertos no debemos tener este problema (o no somos expertos). Hay programadores escribiendo manuales para usuarios (el usuario no es experto y el programador tampoco en el medioambiente del usuario)
Hay programadores escribiendo convenios con clientes
Todo eso es mucha bulla (entropia) solo se minimiza si utilizamos medios formales de comunicacion. por ejemplo para convenios utilizar estandares de ISO , ITIL etc dejar los manuales a especialidstas funcionales y hacer guias los programas (causa->efecto, casos de uso)
Escribir algo , no significa que tenga sentido para otro , un escrito se hace para afirmar un acuerdo.Un acuerdo o convenio implica una negocisacion deonde debemos aclarar los terminos utilizados y quizas llegar a un final feliz
y que es :feliz ...... de nuevo!!!!!!!!!!!!!!!!!!
Pero el problema no esta bien formalizado y eso dara lugar a incompresion , porque no es comprension de texto(una cosa del colegio) sino semantica lo que falla.
Es decir y en un dialgo deberia haber un diccionario comun , yo escribo algo y el que lo lee interpreta exactamente lo que quise decir
Suena bien?
IMPOSIBLE !!!!
Cada termino citado por mi , es referenciado a mi diccionario, tiene el sentido que yo conozco y no otro...... algo mal? , algo nuevo? ,algo sobervio?, nada de eso
Es el viejisimo problema de los estudiantes de ingenieria (masa-peso,fuerza , sistema , energia etc) en un viejisimi libro cuando estudiaba termodinamica el autor al principio hacia una cita de "Alicia en el pais de las maravillas" algo que dijo un personaje:"...cuado yo digo algo digo exactamente lo que yo quiero decir..." creo que eso decia un conejo.
Somos todos conejos hoy ! cada uno con su diccionario y sus lamentos por la incompresion de los otros y sin hacer mucho esfuerzo por entender.
Mientras escribo esto vi de reojo el traste de un libraco de access 97 , enorme ,el autor empezaba diciendo :"tanto para escribir y tan poco timpo para leer....."
En muchas cosas estamos abrumados por la data , el volumen de datos disponible es impresionante. Los manuales tecnicos nunca mas los leo, se leen las busquedas sobre versiones digitalizadas , sino impòsible, eso hace que no entienda los conceptos del autor , solo sus datos , pero es lo minimo que se puede hacer. Para que esos datos tengan algun sentido los filtro a traves de mi modelo de eso . Y si no tuviera modelo? fuiste! hoy no se puede aprender de cero
Esto no es mas que catarsis , creo que en los dominios en los que somos expertos no debemos tener este problema (o no somos expertos). Hay programadores escribiendo manuales para usuarios (el usuario no es experto y el programador tampoco en el medioambiente del usuario)
Hay programadores escribiendo convenios con clientes
Todo eso es mucha bulla (entropia) solo se minimiza si utilizamos medios formales de comunicacion. por ejemplo para convenios utilizar estandares de ISO , ITIL etc dejar los manuales a especialidstas funcionales y hacer guias los programas (causa->efecto, casos de uso)
Escribir algo , no significa que tenga sentido para otro , un escrito se hace para afirmar un acuerdo.Un acuerdo o convenio implica una negocisacion deonde debemos aclarar los terminos utilizados y quizas llegar a un final feliz
y que es :feliz ...... de nuevo!!!!!!!!!!!!!!!!!!
sábado, 4 de septiembre de 2010
STOCKS ideas y conceptos
Uno de los principios basico de la organizacion de actividades en una empresa es lo que se conoce como principio de la "casi independencia". Esta es la imagen del concepto de administracion que ya conocemos :una unidad para poder administrarse debe tener un grado de libertad que le permita adaptarse al entorno con requerimientos cambiante y hasta corregir los errores cometidos.
Si no tuvieramos holgura , una unidad de una empresa creada con un proposito no tendria osibilidad de existir convenintemente en un ambito en los cuales de muchiosimas formas se exige flexibilidad!.
Si un negocio no tuviera stocks tendria que salir a comprar cada material o componente que necesite para conseguir sus ventas.
Un punto des stock es un amortiguador , una componente que crea un grado de libertad.
Imaginen un tren con locomotora y vagones soldados en una sola estructura!
Ya se que existe! , en Salta lo llamaban coche motor , tiene la restriccion de curvas muy abiertas o cero curvas en el camino! , por eso hoy ya no queda ninguno!
Es una buena solucion en busca de un problema adecuado.
La solucion gral , adaptable a muchos problemas es el clasico convoy de locomotoras y vagones acoplados por uniones flexibles que`permiten encarar curvas diversas.
Volvamos: sin amortiguadores es muy dificil conducir un automovil , sin amortiguadores una central hidraulica de energia dependeria del nivel de agua del rio, para independizar la produccion de energia se hace stock de energia potencial en los embalses.
O sea pequeño saltamontes... Control de stocks es asegurar la supervivencia de una unidad de una organizacion controlando los flujos , coordinando entradas y salidas , optimizando la cantidad y velocidad para beneficio de un sistema que es mayor.
O sea programador , lo de inventarios es una cuestion muy poco trascendente , solo es una de tantas y cuando agregas el aviso de controles minimos ni siquiera sabes cuanto desorden puedes estar causando , la cosa es mas profunda!
Estudiar administracion de stocks , control y planificacion , programacion de la produccion etc ayudaran a ponerse en onda!
Si no tuvieramos holgura , una unidad de una empresa creada con un proposito no tendria osibilidad de existir convenintemente en un ambito en los cuales de muchiosimas formas se exige flexibilidad!.
Si un negocio no tuviera stocks tendria que salir a comprar cada material o componente que necesite para conseguir sus ventas.
Un punto des stock es un amortiguador , una componente que crea un grado de libertad.
Imaginen un tren con locomotora y vagones soldados en una sola estructura!
Ya se que existe! , en Salta lo llamaban coche motor , tiene la restriccion de curvas muy abiertas o cero curvas en el camino! , por eso hoy ya no queda ninguno!
Es una buena solucion en busca de un problema adecuado.
La solucion gral , adaptable a muchos problemas es el clasico convoy de locomotoras y vagones acoplados por uniones flexibles que`permiten encarar curvas diversas.
Volvamos: sin amortiguadores es muy dificil conducir un automovil , sin amortiguadores una central hidraulica de energia dependeria del nivel de agua del rio, para independizar la produccion de energia se hace stock de energia potencial en los embalses.
O sea pequeño saltamontes... Control de stocks es asegurar la supervivencia de una unidad de una organizacion controlando los flujos , coordinando entradas y salidas , optimizando la cantidad y velocidad para beneficio de un sistema que es mayor.
O sea programador , lo de inventarios es una cuestion muy poco trascendente , solo es una de tantas y cuando agregas el aviso de controles minimos ni siquiera sabes cuanto desorden puedes estar causando , la cosa es mas profunda!
Estudiar administracion de stocks , control y planificacion , programacion de la produccion etc ayudaran a ponerse en onda!
prioridades
Las prioridades califican el orden en que debo encarar mis pendientes
En mi programa de ordentes tadavia me falta agregar que se almacene la calificacion de una orden pendiente con la posibilidad de recalculo automatico para recalcular la urgencia
Segun ITIL , se define a Prioridad como: secuencia en que se tratarán los incidentes.
Se determina por el impacto, la urgencia y el esfuerzo.
Impacto: desde el punto de vista del negocio.
Urgencia: es la velocidad con la que debe resolverse el incidente.
La prioridad y la urgencia no se definen en base a la presión del usuario
sino según los procedimientos y los acuerdos de servicio. Deben usarse
códigos uniformes y preestablecidos
En mi programa de ordentes tadavia me falta agregar que se almacene la calificacion de una orden pendiente con la posibilidad de recalculo automatico para recalcular la urgencia
Segun ITIL , se define a Prioridad como: secuencia en que se tratarán los incidentes.
Se determina por el impacto, la urgencia y el esfuerzo.
Impacto: desde el punto de vista del negocio.
Urgencia: es la velocidad con la que debe resolverse el incidente.
La prioridad y la urgencia no se definen en base a la presión del usuario
sino según los procedimientos y los acuerdos de servicio. Deben usarse
códigos uniformes y preestablecidos
viernes, 21 de mayo de 2010
algo de responsbilidad
En esta actividad , las responsabilidades son las derivadas del contrato entre el cliente y nosotros
Eso es distinto de otras ?
En algunos casos si , porque en algunas el estado regula la relacion contractual con el cliente , la mayoria de las veces delegando a consejos profesionales el control de actividades y regulando honorarios. en nuestro caso ni lo uno ni lo otro
PERO.... resulta que entidades como el afip nos ha involucrado sin consulta desde hace años en las responsabilidades por la programacion de las impresoras fiscales
Creo que con ese criterio , hoy deberian estar presos los fabricantes de armas , el invenntor de la polvora , los fisicos
Eso es distinto de otras ?
En algunos casos si , porque en algunas el estado regula la relacion contractual con el cliente , la mayoria de las veces delegando a consejos profesionales el control de actividades y regulando honorarios. en nuestro caso ni lo uno ni lo otro
PERO.... resulta que entidades como el afip nos ha involucrado sin consulta desde hace años en las responsabilidades por la programacion de las impresoras fiscales
Creo que con ese criterio , hoy deberian estar presos los fabricantes de armas , el invenntor de la polvora , los fisicos
miércoles, 31 de marzo de 2010
Del metodo
CONFUSIONES , METODOS , HERRAMIENTAS
En una vieja fabrica de papel , la rubia secretaria nos repetia "no confundan , sabana con funda!"
Porque no es lo mismo!
Ej: el KANBAN no es un metodo , es una herramienta ... son etuiquetas y tablero!!!
Para hacer las cosas todos tenemos una receta
Cualquiera , de ualquier profesion o sin ella puede recomendar una receta para hacer las cosas
PERO las unicas reetas con validez son las que consiguen impactar en la calidad y el costo de lo que hacemos: resultados-costo-productividad es una ecuacion que debe fundamentar una receta y una receta asi ,la podremos rotular de metodo
En el ambito de la programacion de computadoras, han tratado de avanzar sobre este tema y asi descubrieron formas de trabajar que parece que no saben que estan fundamentadas en antiguos principios. La mas conocida antiguedad moderna es el KANBAN , una etiqueta en un tablero que proporciona inforacion al personal a cera de su siguiente tarea. Es parte del metodo de trabajo de la industria manufacturera japonesa basada en JIT y LEAN (Difundido como parte del metodo toyota de produccion). La tecnologia modrna hizo posible facilitar la implementacion y manejo de esos tableros
Pero si estudiaran a fondo los fundamentos reales del kanban , descubriran que su ambito es la produccion repetitiva de productos estandarizados y en puestos de trabajo en linea. Obvio que las viejas etiquetas del kanban son ridiculas al lado de lo que podemos comunicar ahora con un simple codigo qr!
Pero .... porque solo el kanban ... y el ANDON? pa cuando?
Este concepto se maneja desde hace nuuucho tiempo como un objetivo de los ingenieros industriales.
Los objetivos eran utilizar al máximo las habilidades de las personas , aprovechar las facilidades de las maquinas , balancear el trabajo en todos los puestos involucrados en una tarea y obvio racionalizar el trabajo y además optimizar los costos
Teníamos una palabra que resumía casio todo PRODUCTIVIDAD
Ahora veo que se paso de moda el termino , pero no desapareció su necesidad y lo malo es que cualquiera promete trabajar sobre esos aspectos sin una formulación
Y estos recuerdos me traen a la memoria una cosa antiquísima :Just In Time y Kanban y BOM y MRP y ERP y ROI y ... etc.
Además ,un principio básico básico básico grabado en ROM
Eliminar-combinar-simplificar
Que se haga algo distinto no quiere decir que sea mejor
Que se haga algo que hacen los otros no siempre es lo mejor para nuestra empresa
La tecnología puede difundir errores a velocidades espantosas ..... Recordemos que los métodos de trabajo son parte de los sistemas de la empresa , si lo alteras ya sabes que :otras cosas cambiaran solo porque cambiaste algo allí
para cambiar algo hay que evaluar costos y beneficios
Existen métodos standard para hacerlo
continuare..............
Suscribirse a:
Entradas (Atom)