Finalmente este fin de semana la vi.
Soy aficionado al cine , .... y me pareció aburrida y poco demostrativa de cualquier cosa que espero encontrar en una película , es decir .... como dice un personaje : no capto mi atención
Pero como había escuchado y leído comentarios (no recuerdo si bueno o malos0) l volvi a ver con la atención de un profesional del área de software y pensando que quizás tenga el valor de un testimonio de un fenómeno cultural..... me gusto menos
Porque por donde la mire es una "hoguera de vanidades" , allí el ego mas débil es el del personaje Eduardo, preocupado por el dinero. Los egos de los hermanos xxxxx (esos que lo demandaban por plagio) muestran el ego del tonto importante , ni siquiera van por el dinero , ellos van por el triunfo y el éxito predestinado (recuedan de un país que según ellos tienen el destino manifiesto .....? ) y la gloria que suele derivarse . Pensé en los vergonzosos Bush (padre hijo y espíritu maligno) . La gloria es para ellos , el sudor debe ser de otros (ellos no deben sudar) y se quisieron aprovechar del nefasto Mark .
Mark es insufrible el no esta por el dinero , ni por la gloria ni por el triunfo . el tipo hace todo por la vanidad menor , por el desprecio que siente por los poderosos , por el complejo de inferioridad supremo que lo hace actuar como un buen perrito y en realidad es el mayor de los zorros.
Bueno , todos sabemos , después dicen ... si al final de cuentas es un hacker
Observen que nadie "creo" el concepto de facebook , no se trataba de una sagaz mente de negocios ni de un genio que sintetizo el mandato gregario de la sociedad en FACEBOOK , se trata de un astuto programador , ineescrupuloso que ni siquiera sabia como asociar; ni siquiera sabia lo del bello problema matemático que Eduardo le soluciono , ese Edurado si que es grande! y muy humano , simplemente quiere ganar dinero con su esfuerzo.
Ese Mark es como los iluminados de hace muchos siglos o como los reyes que eran los únicos que podían conversar con Dios , y nadie podía pedirle cuentas. Esa siempre fue la astucia de la dominación.
Me enojo mucho razonar sobre esta película , porque vi de nuevo a Bill Gates mintiendo y robando a otros y a IBm aplicando el poder del dinero.
Todavía quedan por alli tipos que si pueden ser paradigmas , me acuerdo de dos muchachos en un garage y también de uno que se fue pero antes comprimió al mundo y otros de otras áreas porque en computación hay muchos mas egos comerciantes y egos sublimados
lunes, 7 de febrero de 2011
viernes, 28 de enero de 2011
organizador de actividades
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
Organizo mi tiempo , prioridades , con calificaciones , filtros y todo lo habitual pero de una manera sencilla. pueden bajarlo de www.taskcoach.org , es gratuito
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
Suscribirse a:
Entradas (Atom)