Feb 16 2009
El programa de Ciencia y Tecnología (FINCyT) está organizando un concurso público de investigación sobre aplicación de tecnología en el entorno empresarial. Dentro los sectores priorizados se incluyen las TIC. Las caterogías son: Estudios de prácticas exitosas de innovación empresarial, y Estudios de comportamiento tecnológico empresarial. La fecha límite de entrega de trabajo es el 1ro de marzo 2009.
Oct 18 2008
Emprender, una palabra bastante popular en los últimos años; generalmente asociada al sector productivo e industria, en nuestro país poco se ha tratado sobre éste en relación al emprendimiento en tecnología. El jueves 16 tuve la oportunidad de ofrecer un charla en el marco de la III Semana de ciencia de la computación 2008 en la Universidad Nacional de Trujillo, evento organizado íntegramente por estudiantes de la carrera de computación.
En mi charla, que duró un poco más de lo que pensé, me propuse a hablar algo en lo que estoy particularmente interesado hace algunos años: el emprendimiento en tecnología desde Perú. Este es un resumen de lo tratado en espera de comentarios e interacción con los interesados en el tema, y que sea de utilidad a quienes están evaluando seguir este camino.
Sep 19 2008
Desde hace algunos meses un grupo de personas vinculadas al desarrollo de proyectos y empresas en Internet, específicamente en la web, estamos trabajando para tener un espacio en el cual compartir ideas, proyectos, conocimiento técnico sobre lo que sabemos a otros. Este tipo de espacios se conoce a nivel mundial como BarCamp.
barcamp
Un BarCamp es una conferencia cuyo objetivo importante es el compartir y aprender en un ambiente abierto. Es un evento intenso y productivo, con discusiones, demostraciones, e interacción muy enfocada entre los concurrentes. Es una reunión libre y flexible de personas para compartir, discutir y crear, en un ambiente que permita que todos participen y contribuyan al evento. Se busca que el evento tenga ciertos lineamientos generales, y que este se auto-organice en función a las necesidades y aptitudes de los mismos participantes. En un BarCamp, el objetivo es interactuar en una comunidad, no hay expectador pasivo, todos tienen que aportar algo.
Estamos buscando a ti que tienes ideas, proyectos, preguntas, deseos de hacer algo completamente revolucionario. Tu que quieres hacer el próximo Google, Facebook, Twitter, Last.fm y no sabes por donde ir, por donde empezar, donde buscar financiamiento, cuánto necesitas de capital, a quién vender, qué tipo de producto desarrollar, etc. Buscamos gente que quiera lanzarse y hacer cosas.
Te invito a ingresar a nuestra web e inscribirte para la primera reunión que tendremos, probablemente alojada en htu, la empresa que dirijo. ¡Te esperamos!
Jul 08 2008
El pasado 24 de junio a invitación del Chapter Lima del PMI ofrecí una charla respecto a los aspectos o practicas de gestión de proyectos que las organizaciones o empresas pueden rescatar del ecosistema de software libre e incorporarlos en sus proyectos, en específico los que tienen que ver con desarrollo de software.
La objetivo principal, más allá de dar a conocer el software libre como tal, era establecer y reconocer prácticas de gestión y procesos que se puedan rescatar e incorporarlos en el desarrollo de proyectos de software de las organizaciones.
La charla inicio ofreciendo un panorama general de los actores que participan en el desarrollo de proyectos de software libre, como podemos ver en el gráfico adjunto, a saber:
Luego de esto explique el esquema de trabajo y gestión de los proyectos de software libre, la forma de organización, su estructura jerarquica, infraestructura de trabajo, interacción entre el grupo humano, etc.
A partir de esta información rescatamos algunos valores o prácticas que las organizaciones que realizan desarrollo de software pueden incorporar para mejorar su gestión y procesos de desarrollo.
Entre estos podemos mencionar a los siguientes:
Confía en tu equipo
Esto se refiere básicamente a que la información acerca del desarrollo, incidencias y progreso del proyecto se maneje de manera abierta, sin ocultar información a nigún integrante del equipo. Todos deben estar claros de lo que ocurre. Un esquema bastante similar al definido por Debian y lo que conocemos como el rol de «dictador benevolente».
Revisa todo, prueba todo
Que trata de resumir la necesidad de incorporar y establecer prácticas de testing en el proceso de desarrollo y aprovechar las herramientas de software, o construir las necesarias, para establecer un ciclo constante de auditoria general y automatización del proceso de pruebas de software. De esta manera a medida que se va desarrollando el proyecto también se tiene a la par un proceso que puede garantizar la validación de su funcionalidad.
Todos los desarrolladores son iguales
Algo que no se refiere a las características personales o de formación, sino a la equidad y valoración de las ideas o aportes de los desarrolladores, sean los más experimentados en el equipo o novatos que se acaban de incorporar. Cualquiera de ellos debe ser escuchandos y sus aportes o ideas respecto al desarrollo o diseño de los proyectos se debe tener en cuenta de la misma manera.
Y finalmente, la premisa que no debemos olvidar:
La mejor manera de finalizar un proyecto de forma exitosa es hacerlo de la forma correcta
Que básicamente nos recuerda que aunque tengamos los procesos definidos, las herramientas necesarias y la infraestructura de soporte para el desarrollo de nuestros proyectos; si los primeros se ignoran y no se siguen desde el inicio del proyecto, por razones de tiempo, urgencia, etc; es mucho más probable que a medida que se desarrolle el proyecto ocurran problemas que si se empieza de la forma correcta.
Esto es lo que cuenta al final del día y puede ser el factor crítico que conduce a pérdidas de tiempo, dinero y time-to-market para una organización. Para que un proyecto sea exitoso se requiere la participación de todos los actores involucrados, que va desde la gerencia hasta el desarrollador. No se trata simplemente de dar indicaciones al programador y encerrarlo un número de días esperando que entregue un resultado maravilloso.
Fue interesante el aprovechar que me antecedio una charla sobre SCRUM, para vincular muchas de estas practicas que tambien son promovidas por frameworks de desarrollo ágil como éste, que fue expuesto por Tobias Mayer de AgileThinking.net.
Es posible que existan otras prácticas que los proyectos de desarrollo de software en las empresas puedan incorporar, si has identificado o aplicado alguno ¡dejanos saber!.
Existe más información sobre el tema que he tomado como referencia para esta charla. A continuación pongo algunos enlaces de referencia:
Jun 26 2008
Hoy tengo el agrado de compartir un gran momento de nuestra empresa con ustedes: clientes, amigos y familiares.
En htu networks venimos trabajando bajo una doble vida, por el día atendemos a nuestros clientes y por las noches nos sumergimos en una serie de actividades destinadas y enmarcadas en hacer de nuestra empresa un centro de desarrollo e innovación tecnologica, inscrita en el marco de la economía e industria de software global.
Fruto de estas actividades podemos anunciar, y mostrar, hoy lo que podrán conocer pronto quienes trabajan con nosotros en la actualidad y quienes todavía no tienen el placer. He aquí un technology preview (en el sentido free-as-in-freedom).
¿Qué ocurrirá?
htu networks estará gustoso de trabajar con empresas modernas que tengan como visión el aprovechamiento de la tecnología como base para la generación de valor para sus negocios, aprovechando hoy las tecnologías disponibles y aplicando los nuevos desarrollos e investigación del entorno académico, con quienes hemos fortalecido aún más nuestro vínculo, con el objetivo de generar rentabilidad.
Tenemos claro que la tecnología per-se no es el fin sino el medio a través del cual las nuevas empresas deben buscar el valor y el retorno de inversión orientando sus recursos al desarrollo del negocio y no a la gestión o desarrollo de tecnologías de la información.
Nuestro portafolio se basa fuertemente en el software, donde aplicamos todo el conocimiento y la formación académica de nuestro equipo para producir soluciones world-class bajo estándares, procesos y metodologías de desarrollo que permitan obtener los resultados esperados para el negocio en tiempos óptimos.
Para nuestros clientes esto significa un paso más adelante en la calidad de servicios que ofrecemos y una renovación de ser sus aliados en el desarrollo de sus negocios. Para los que todavía no lo son, esto significa que pueden confiar en nosotros para que usted se preocupe únicamente del desarrollo de su negocio.
¿Qué significa el nuevo logo?
El nuevo logo es la expresión de este enfoque renovado de la empresa. El color naranja significa que nos gusta el screwdriver y el turquesa que nos gustan las mujeres con estilo. Las formas dicen de manera más visual hacia donde vamos.
¿Porqué lo hacemos?
En htu nos gusta hacer nuestro trabajo de manera eficiente, pasar tiempo en casa, disfrutar de nuestro tiempo libre, llevar a nuestras parejas a una cena romantica, tomarnos el día libre, bailar, tomar pisco, y divertirnos el fin de semana. También investigamos y nos desarrollarnos profesionalmente en nuestra especialidad para ofrecerles lo mejor de nuestra capacidad.
Queremos que usted también pueda hacerlo, la tecnología no tiene que ser tan mala. Dejenos ayudarle.
May 25 2008
Hace unas semanas se ha publicado la actualización del Whitepaper «Software Development’s Classic Mistakes 2008» de la consultora Construx, que está disponible para descarga de manera gratuita.
Este trabajo de Steve McConnell, autor del libro «Rapid Development», recopila los errores más comunes en el proceso de desarrollo de software y tiene como objetivo el ofrecer un vistazo único a los factores de riesgo más comunes. Originalmente la lista se inició con 36 errores a partir de la publicación del libro en 1996, y a la fecha reune datos obtenidos del trabajo con más de 1000 clientes de Construx.
Entre las fuentes que han aportado para la elaboración de dicha actualización se encuentran Jefes o arquitectos de software (55%), gerentes (11%), Gerentes técnicos o con doble rol (6%), y técnicos (22%).
Entre los primeros 10 errores más frecuentes se identifico a los primeros 5 con el modo de «Casi siempre» y a los siguientes como «a menudo»:
Entre ellos se clasifico como de alto impacto con una criticidad de «Catastrófico» y «serio» en el siguiente orden.
Es particularmente interesante observar que 35 de los 42 errores clásicos se clasificaron como de impacto catastrófico o serio por mas del 50% de participantes.
El paper ofrece además métrica de exposión al riesgo (RE) que mide la severidad y el impacto de forma aproximada, básicamente obtenida del producto de ambos criterios bajo la fórmula RE = severidad * impacto.
Una de las cosas que me llamo la atención fue el tema de «Whishful thinking» o pensamiento iluso, que ha sido calificado en la posición 4. A veces ocurre que en la gestión del proyecto se cierra totalmente en la idea de que va algo va a funcionar cuando no se tiene base concreta o razonable para pensar que así será. Costrux indica que esto puede llevar a grandes problemas si se da al inicio del proyecto, pero lo mas grave es que menoscaba el planeamiento adecuado y puede ser la raíz se otros problemas.
Como tantos de los temas en gestión de proyectos de diversa índole, este no deja de tener al factor humano como clave, fuera de buenas prácticas, métricas, procesos o metodologías, si el personal que lidera el proyecto se cierra bajo una visión irreal esta puede tener consecuencias serias para la organización.
El otro tema que me parece interesante es el multi-tarea excesivo. Generalmente se suele confundir al desarrollo de proyectos usando metodologías ágiles y etiquetarlos con cierta metodología, sin tomar en cuenta todos sus aspectos. El problema con el excesivo uso de multi-tarea es que, según los estudios, cada «switch» entre tareas puede tomar de 5 a 30 minutos de «para» de desarrollo mientras la persona cierra el flujo de trabajo de un proyecto y se inserta en otro.
Finalmente el tema del ambiente laboral resulta vital, ya que un entorno ruidoso o demasiado hacinado evita la concentración y el estado necesario que se requiere para trabajar y obtener altos niveles de productividad. Se ha determinado que los trabajadores que tienen oficinas silenciosas y privadas tienden a deempeñarse sinificativamente mejor que aquellos que ocupan cubículos o bahías ruidosas y demasiado hacinadas.
Recomiendo leer este trabajo si trabajas o te interesa el tema de desarrollo de software, en especial si estas a cargo de proyectos o su gestión.
Apr 15 2008
El pasado 14 de marzo ofreci una charla en el Linux Week 2008 organizado por Linux-IDES de la PUCP. por invitación de Genghis. La temática estaba abierta asi que tuve un momento de incertidumbre acerca de qué hablar. Mis opciones estaban entre algo super técnico, tipo sistemas operativos, o algo relacionado con la empresa, por la naturaleza del evento académico.
Finalmente, y gracias a una sugerencia, decidi hablar sobre algunos temas relacionados a las cosas en las que estoy involucrado en estos últimos meses. Así que me propuse hablar del estado del arte del software libre en la empresa. Sin embargo, durante el proceso de trabajar mi charla, que también tuvo su propia historia, me animé por abrir un poco el panorama y hablar de innovación y las tendencias actuales en el sector de empresas de tecnología.
Ya había tocado el tema en la conferencia Día Debian en la UNI, así que esta vez tenía que escalar un poco más y ofrecer algo más interesante que sirva a los asistentes. Me propuse, entonces, ensayar el famoso método Lessig para las presentaciones de apoyo y con el fin de controlar mis tiempos.
En mis últimas charlas he ido dejando de utilizar presentaciones en forma progresiva, incluso la de la UNI la hice bajo el precepto de que: si voy a mostrar cosas de la red, las muestro directamente y no hago ninguna presentación. Mi presentación es la propia actividad que hay en la red. Aquella vez, solo fui con una lista de los enlaces que mostré.
Para esta charla quize apoyar mi «speech» con material visual que ayude a reforzar la idea que estoy transmitiendo. Estoy convencido de que el utilizar las presentaciones de una manera distinta, como por ejemplo para leer el «speech» u otros, es una falta de respeto al público (que también sabe leer).
Ya que iba a utilizar el método Lessig tendría que esforzarme más, primero para tener un mejor orden en la transmisión de las ideas y segundo para controlar los tiempos y tratar de estar sincronizado con la presentación de fondo. Asi que estuve ensayando dos días para tener eso bajo control, creo que el resultado ha sido bastante bueno para esto que llamo «experimento». Me gusta experimentar el hacer las cosas de mejor manera cuando se puede, y he quedado contento (no conforme) con el resultado.
Volviendo al tema de la charla, me ha gustado lo que preparé. Empece con una reseña del inicio del software libre (rms, Linus, Ian), el modelo de negocio que existía en ese momento, las primeras empresas que se formaron. Luego, explique el tema de innovación disruptiva, para posteriormente hacer la relación con el modelo de desarrollo y negocios que se ha formado en torno al software libre.
Posteriormente revisamos el uso de este tipo de esquemas de desarrollo en entornos empresariales, donde cada vez son más importantes los conceptos de e-R&D, innovación, desarrollo de comunidades, el cambio del rol del consumidor a pro-sumidor. Tome como ejemplo a los startups 2.0 y explique cómo estos emplean estos modelos y conceptos que han hecho que sean mucho más exitosos que sitios similares pero con el enfoque tradicional (digg vs. slashdot, myspace vs. mtv.com, etc).
Revisamos la relación empresa-academia, algo que particularmente me interesa, y fue uno de los motivos por los que esta charla en la PUCP fué de particular importancia para mi. También trate el tema del Microsoft de hoy, que parece muy animado a promover el software libre, junto a otras empresas tradicionales. Finalmente hubo una interesante rueda de preguntas donde conversamos sobre innovación, oportunidades para estudiantes, modelos de negocio, realidad virtual, teletrabajo y los beneficios del publicar código.
He quedado muy contento con esta charla, ya puedes notarlo, y espero que se vuelva a repetir en algún momento y sirva para acercarnos más entre academia y empresa. Nuevamente agradezco la oportunidad a Genghis y el grupo Linux IDES.
Hoy me enteré que ya se ha publicado el vídeo de mi presentación, asi que aquí lo pongo. Las diapositivas no son «usables», ya que han tenido otro enfoque y son cerca de 200 (una cada 5 segundos, y de acuerdo al cáculo termine en media hora).
Si te interesa el material o los datos de referencia de temas que trate dejame un mensaje y actualizaré este post o te escribiré directamente.
Charla en la PUCP, Linux Week 2008
www.flickr.com
|
Site Admin | Free WordPress ThemeRudy Godoy :: an act of subversive playful cleverness Copyright © 2010 All Rights Reserved .
