Volviendo de a poco a escribir, quisiera comentarles como estuvo el taller de Inception que se brindo el 18 y 19 de Marzo en Grupo Esfera. El taller fue facilitado por Ariel Ber y Alan Cyment, y la verdad es que fue muy rico en cuanto a contenidos.
A mi entender hacer una Inception es un muy buen punto de partida para cualquier proyecto/startup, ya que facilita la comunicacion entre el grupo que va a estar comprometido, fijando prioridades sobre ciertos puntos clave que tiene un proyecto como Alcance, Tiempos, Calidad del Producto, etc.
Es bueno que se genere al principio ya que una de las actividades de la Inception es discutir que es lo que cada uno tiene en mente cuando se hablo de la idea del proyecto, y con esto hacer surgir dudas dentro del equipo que mas adelante deberan ser resueltas.
Un buen concepto de que es una Inception seria... "Eliminar lo implicito para generar lo explicito." Acá dejo las fotos del taller:
Vuelvo a escribir despues de un periodo largo. Estos meses estuve intentando empezar un startup con todo el aprendizaje que eso conlleva. Gracias a dios he aprendido bastante este ultimo
tiempo. La primera gran leccion que podria compartir en este blog es "Just do it". Se que suena igual que el slogan de Nike, pero es lo cierto. Pasamos mucho tiempo haciendo un overthink
de una idea y muchas veces no llegamos a verla tomar vida.
La otra gran leccion seria "Nada de lo que hagas sera perfecto". No se trata de abrir el paraguas de antemano, se trata de saber que lo que hacemos, siempre se podra mejorar, y es mejor darle vida al producto y mejorarlo en el camino a que el producto tenga siempre algun retoque pendiente y no este productivo nunca.
Creo que por ultimo podria poner en este pequeño post, "if you don't know how to do it, outsource it" (o en español, "si no sabes como hacerlo, tercerizalo"). Si no sabes hacer algo, y quieres un producto profesional, entonces tendras que contratar un profesional que pueda hacer ese trabajo. Grandes sitios webs empiezan con diseños pocos amigables y despues caen en la cuenta que necesitan modificarlos, y darle un estilo un poco mas profesional.
Quería empezar este post a modo de centralizar varias opiniones encontradas y otras no tanto de ciertas caras del rubro laboral de sistemas. Es penoso que el promedio que un empleado, permanece en una misma empresa en Argentina sea de 2 años. A lo largo de los años las causas siguen siendo las mismas:
El sueldo no es acorde a las tareas que se hacen.
Los aumentos suelen ser muy pobres
Nos contratan para hacer una tarea
determinada, pero cuando empezamos a
trabajar nos encontramos haciendo
absolutamente, de todo.
Estas causas de migración del personal, existen y son reales. Es triste que hace mas de 5 años, sigan siendo las mismas. Algunas empresas se jactan de tener un "buen ambiente laboral" o piensan que por poner videojuegos, esto automáticamente los convierte en Google. La realidad, es que según mi opinión un empleado, y acá si me atrevo a generalizar, busca lo siguiente:
Un buen ambiente laboral: Se ha
demostrado mas de una vez que el
desarrollo de un producto en sistemas
no se mide en toneladas la hora. El
aumento de la cantidad de recursos a
un proyecto no es inversamente
proporcional a la reducción del
tiempo de desarrollo. Debemos
sacarnos de una vez por todas esta
idea.
Sueldo acorde a las
responsabilidades: Escucho y veo
constantemente que los sueldos se
estancan luego del primer año de
antigüedad, y los "aumentos" se
licúan con la inflación anual.
Desarrolladores que, ademas de
desarrollar, son líderes de proyecto,
y en algunos casos líderes técnicos.
El único problema con lo anterior es
que, en general, el sueldo solo
corresponde al de un desarrollador.
Capacitaciones: ¿Que pasaría si te
dijera que capacitar a un empleado
tiene un retorno de inversión
inmediato para una empresa?
Desarrollar producto también es
desarrollar recursos humanos. Elevar
el conocimiento de los recursos
humanos también es aumentar el
alcance del mercado de una empresa.
Este es un concepto que se tiene que
entender, porque es el único que
elevara la calidad de nuestros
recursos humanos.
Me gustaría leer comentarios, de empleadores y empleados de IT. ¿Es este modelo, utópico?
Este post va dedicado a tratar de entender si sirve calcular un presupuesto de tiempo a la documentación del proyecto.
Esta fase, del proceso de desarrollo de software, se estudia y se repite una y otra vez pero la realidad es que nadie la implementa.
Por momentos es difícil entender que escribir un manual de 300 paginas que describe cada porción de código, será util. Y la pregunta acá es ¿es util?. Es cierto que muchas veces los comentarios en el código, anidados a una función/método/procedimiento/etc ayuda, y mucho, a entender cual es el problema que se esta resolviendo y el "como", por sobre todo. Sin bien existen manuales de usuario, no son especialmente a los que este post se refiere, sino mas específicamente a los manuales "técnicos", aquellos que seguramente existan en tu empresa y que seguramente hacen referencia a una versión obsoleta de un producto. Hace un tiempo un colega me comento de una metodología que utilizaban en la empresa donde trabajaba, que consistía en comentar el código incrementalmente a medida que cada uno de los integrantes tenia que lidiar con una determinada porción de código no comentada. De este modo, en cada commit debería existir, por lo menos, una función comentada. La idea es clara, comentar incrementalmente, hasta que todo el código este aceptablemente descripto. Si pudieramos elegir entre esta opcion y la primera, sin dudas me quedaria con esta ultima, pero volviendo a la pregunta ¿es util?.
Sabemos que los desarrolladores de codigo, son amantes de resolver problemas solo por el hecho de que pueden hacerlo. A lo cual aca se plantea una contradiccion, ¿sera mejor leer y releer el codigo una y otra vez hasta entenderlo o solo bastaria con leer unas lineas bien descriptivas? En mi caso pienso que... las dos.
Para tener una mejor calidad de codigo debemos comprender que es lo que estamos haciendo, y fundamentalmente cual es el problema que estamos resolviendo. De esta manera, con leer los comentarios podemos introducirnos al codigo, y leyendo y analizando el codigo podemos entender a fondo que es realmente lo que esta sucediendo en esa porcion del producto.
Empiezo este post tratando de compartir mi desagrado con las leyes SOPA y PIPA. Internet nacio para compartir información y no para privarla. El conocimiento tiene que seguir siendo libre.
Pero remontémonos un poco hacia atrás, cuando muchas personas creemos que esto empezó. Caso Wikileaks. Todos conocimos este caso en donde se filtraron documentos diplomáticos. El caso que no muchos conocen es que cuando Julian Assange fue detenido por abuso sexual y se bajaron los documentos diplomáticos del sitio oficial, muchos hackers empezaron a recrear mirrors para que esta información se siga manteniendo en la red, incluso en servidores locales cuyo único propósito era almacenar estos documentos y que no dependieran mas de un sitio que llegaría a caer en la censura inminentemente. Estas fueron algunas de las invitaciones que aparecian por la red:
Luego se empezó a bloquear contenidos por ISP, es decir ciertas paginas proveedoras de estos leaks, se encontraban caídas/bloqueadas por nuestro proveedor de servicios de internet.
Ademas seguimos luchando contra las patentes del software, por lo menos sobre lo que es de conocimiento publico (algoritmos, etc).
Hoy nos encontramos peleando la denegación de una ley que se camufla bajo la premisa de “proteger la actividad intelectual” pero lo único que pretende es el exterminio del conocimiento libre y subyugar a una sociedad que no esta regida por ninguna ley.
Internet debe permanecer como es, libre para todos.
Estos últimos días estuve tratando de realizar un desarrollo web “productivo” (con lo de productivo me refiero a no solo jugar con el lenguaje, sino que además hacer un deploy de la app en un entorno productivo). Hace bastante tiempo que estoy familiarizado con el desarrollo de aplicaciones en Java y Python, pero esta vez quería probar algo simplemente diferente. Navegue por las aguas de PHP, tratando de utilizar Symfony nuevamente, me acorde porque era que no me había gustado la primera vez. El caso es que symfony tiene una gran cantidad de configuraciones, los errores son poco amigables y siempre pensé que PHP debería ser más fácil.
Luego escuche que Kohana, proponía un codigo bastante seguible, y ademas era bastante minimalista. Además de esto, kohana utiliza herencia “real” y PHP 5. Luego de jugar bastante, me topé con un problema, la documentación. Algunos ejemplos no eran claros o estaban desactualizados (hay una gran diferencia entre ko2 y ko3). Por lo que mi motivación con este framework disminuía poco a poco.
Particularmente, me gusta bastante aprender nuevos lenguajes, pero con el tiempo me he dado cuenta de que tienen que tener una mezcla exacta entre practicidad y buena documentación. Cuando digo buena documentación no me refiero solamente a poner un glosario de las funciones del lenguaje o del framework, sino a exponer ejemplos y ejercicios. Alguna vez probaron el Rails For Zombies? Dios…es simplemente excelente. No solo posee un video introductorio, sino que además podemos interactivamente codear y practicar algunos ejercicios que brinda el tutorial.
Edgar Dale una vez expuso el cono del aprendizaje, demostrando la importancia de practicar sobre leer en el aprendizaje.
Es por eso que encuentro difícil de encontrar un lenguaje como Python, o mejor dicho su framework web Django. No es simplemente comodidad, sino que desde el principio, Django, empieza con un tutorial muy práctico de cómo hacer un Blog. Toca las partes más importantes de este framework. La documentación está abierta a comentarios por los usuarios de la comunidad y aclaraciones MIENTRAS SE LEE (esto es simplemente excelente). Además, detalles como anchors en los títulos de cada tópico, permite leer y encontrar más fácil ciertos temas. Pero sin duda Django cuenta con una buena comunidad de programadores, la cual expone apps open-source para ver cómo se pueden encarar determinados problemas comunes. Otra cosa que me llama la atención de Django es que tiene un web-server integrado (solo de prueba) para probar las aplicaciones lo cual es excelente.
Sinceramente, tendría que observar como se comportaría un framework como este en una app grande, pero sin duda es la mejor herramienta que encontré para desarrollar aplicaciones pequeñas/medianas.
No te olvides del import antigravity! ( solo para curiosos )
Por lo poco que estuve viendo, Grails posee un estilo bastante parecido a Django, pero sinceramente no lo he podido probar a fondo todavía.
Volviendo un poco a escribir, hoy quisiera hablar un poco de cómo empresas líderes en el mercado pueden caer en bancarrota sin ningún problema.
Si uno se detuviera a pensar, lo primero que se preguntaría seria ¿Cómo es posible que con tanto dinero una empresa quiebre?, en mi opinión la causa principal se puede encontrar en la siguiente premisa “adáptate al negocio o muere en el intento”.
Un caso de estudio es la empresa Blockbuster. Todos recordamos ese ticket azul con letras amarillas tan conveniente que nos invitaba a alquilar películas. En un principio, realmente era un buen negocio, alquilar películas estreno en DVD, pero luego el negocio fue cambiando lentamente. Esto quizás se debe a que sitios como YouTube no solo ofrecían ver videos online, sino que además permitía a los usuarios poder subir los suyos. Cuando YouTube fue adquirido por Google, el sitio inevitablemente tuvo una aceptación masiva en los usuarios. Pero pensándolo mejor, uno podría decir “YouTube no es un sitio para ver películas, solamente son videos subidos por usuarios”. Esta idea sería la musa inspiradora de Netflix. Esta empresa ofrece, mediante una cuota mensual, ver películas y series via streaming-online, no hay que rebobinar ni “devolver” el video.
Lo que antes era ir al Blockbuster y buscar la película que queríamos para darnos cuenta que ya estaba alquilada, hoy es conectarse a Netflix y mirarla cuando queramos, sin la preocupación de tener que regresarla.
A todos estos motivos podríamos sumarle, la piratería y el file-sharing excesivo de contenido copyright en internet. Las leyes que rechazan estas prácticas no tienen los elementos suficientes como para manejar esto y prácticamente ya es algo común o normal en estos días aunque ilegal.
Un ultimo intento de Blockbuster fue cuando sugirió una alianza con Netflix, a lo que esta última rechazo.
Empiezo a escribir este artículo con ánimo de reflexionar acerca de la frustración. Ese estado de animo que sentimos todos alguna vez. Es difícil tener buenos resultados cuando uno se encuentra frustrado, y esto afecta directamente a los resultados finales.
Dentro del desarrollo de software, la frustración es una sensación frecuente, pero que pocas veces se “trata” (no es una enfermedad). Lo que quiero decir con esto es que, me ha tocado trabajar con gente que conformaba un equipo de bugfixing y que la falta de motivación dentro de lo que hacia, lo llevaba a frustrarse mas y mas, a tal punto de no querer hacer su trabajo.
Existen varios motivos, algunos más frecuentes que otros, para que una persona llegue a sentirse frustrada. En mi opinión, la frustración esta ligada directamente a la motivación. Una persona motivada, en todos sus sentidos, siente el deseo de lograr la superación personal.
¿Pero entonces como podemos superar este estado? Uno de los consejos que podría dar, es focalizarse en las metas que hemos logrado. Esta es una observación que deberíamos hacer seguido. Que todo un equipo recuerde las cosas que hizo, refuerza la satisfacción personal de cada uno de ellos.
En esas típicas películas “hollywoodenses” en donde el entrenador de futbol le dice a su equipo, que han ganado 29 partidos y que solo queda uno mas, es una técnica muy buena. Es necesario, en un equipo, que el que direcciona, ese equipo, sepa si algún integrante se encuentra frustrado. Conocer que lo motiva, es la mejor herramienta para atacar el problema.
Resumiendo este articulo, crease o no, la frustración es parte del proceso de superación personal, y es inevitable. La mejor herramienta que poseemos, es saber que es lo que nos motiva y que es lo que nos mantiene con ganas de seguir.
Después de un largo tiempo sin escribir, vuelvo al ruedo. Me gustaría hablar en este articulo de los Bugs, si, Bugs esa palabra que no nos gusta decir. Según Wikipedia un bug es:
Un defecto de software (computer bug
en inglés), es el resultado de un
fallo o deficiencia durante el proceso
de creación de programas de ordenador
o computadora (software). Dicho fallo
puede presentarse en cualquiera de las
etapas del ciclo de vida del software
aunque los más evidentes se dan en la
etapa de desarrollo y programación
¿Algunas veces, tuvieron la sensación de que por alguna razón, obvia o no, nos terminamos acostumbrando a ellos?
La pregunta que se debe hacer acá seria ¿Es correcto acostumbrarse a ellos?
Una vez escuche una frase que decía: “La perfección es algo que sabemos que no podemos alcanzar, pero siempre debemos buscarla”.
Obviamente es imposible, en mi opinión, no tener Bugs en un sistema, pero ¿que hacemos cuando los identificamos o encontramos? Muchos dirían “Arreglarlos”, pero aquí entra en juego la formula de la vida, costo/beneficio.
Existen momentos en donde las prioridades son otras, o los Bugs están demasiados arraigados a la arquitectura del sistema y esto genera una complejidad extra.
Ahora, por un momento no pensemos en Bugs como un defecto del software, sino que extrapolémoslo un poco mas, hagamos de cuenta que un bug es un problema del sistema, cualquiera fuese.
Podríamos segmentar estos problemas o “bugs” en dos grupos bien definidos, solucionables con un esfuerzo medio o pequeño y los que decidimos no solucionar (nuestra formula costo/beneficio fue desfavorable).
En el paper No silver bullet, Fred Brooks explica que existen dos tipos de complejidades bien diferenciadas. La complejidad esencial y la accidental.
Básicamente enuncia que debemos concentrarnos en resolver la accidental, ya que la esencial es, muy difícil o imposible de resolver.
Brooks cuenta que mucha gente invierte tiempo y esfuerzo en solucionar problemas que, quizás no tienen solución (volverán a surgir), y recomienda invertir ese esfuerzo y tiempo en los otros.
Existen metodologías que tienen como practica resolver cierta cantidad de Bugs en un determinado tiempo, y lograr de esta manera una mejora continua.
Por ultimo, la resolución de Bugs debería ser parte del proceso de desarrollo/creación/producción de un sistema y no un proceso independiente que se agregue al final como muchas veces sucede.
En muchas ocasiones me he preguntado ¿Que es lo que debería hacer un líder para motivar a su equipo?
A mi pensar, no creo que exista un checklist a seguir para lograr esto. Muchas personas pensaran que quizás el dinero es una fuente indudable de la motivación, pero yo discrepo de esa idea.
De hecho el video a continuación, muestra como a través de estudios científicos se ha llegado a la conclusión de que el dinero solamente es un motivador en tareas mecánicas y relativamente simples, caso contrario en tareas que requieren creatividad o son un poco mas complejas.
Creo que la motivación, como explica el video, se reduce a unos pocos factores. Coincido totalmente con que la Autonomía es uno de ellos. A que nos referimos con Autonomía? A decir, por ejemplo, “Ok, las dos ultimas horas de cada día, podes desarrollar lo que vos quieras.” Seguramente uno debe pensar “¿Tener un miembro del equipo haciendo absolutamente nada? Definitivamente no haría eso”, aquí se encuentra el primer error.
Antes que nada, quisiera tratar de explicar que la industria del software, a mi pensar, poco tiene que ver con la antigua industria manufacturera con la que hemos sido educados (a mi pensar todos). En donde la filosofía es “Mientras mas trabaje, mas productos voy a generar, mas dinero voy a obtener”. Eliyahu Moshe Goldratt explica un concepto bastante interesante en su libro The Goal.
Volviendo a la Autonomía como factor en la motivación, un claro ejemplo de exito de esto, es Google. Los empleados de esta empresa, pueden invertir ciertas horas de las que trabajan en proyectos que ellos quieran. Cuando digo éxito, me refiero a que herramientas como Gmail, han sido fruto de esta política.
Otro caso interesante, es el que se explica en el video, el caso Atlassian. Una compañía de Software australiana, en donde se llevo a cabo una simple tarea: “Durantes las siguientes 24 hs, pueden dedicar su tiempo a los que ustedes quieran con quienes ustedes lo deseen, solamente que al final de esas 24 hs deben mostrar los resultados” Como resultados surgieron proyectos interesantes e ideas que solucionaban problemas que no se pudieron haber detectado sin pasar un buen tiempo.
El segundo factor a nombrar es, lo que el video enuncia como Mastery o Maestría. Este factor es explicado básicamente con una pregunta ¿Por qué alguien que trabaja toda la semana, pierde tiempo en contribuir a proyectos open-source? Digo, no les genera un dinero extra, y estan invirtiendo horas de su vida. ¿Porque la gente ha generado sitios como Wikipedia, sistemas operativos como Linux y otros tantos proyectos open-source?
La respuesta es simple: Es un desafío que les genera satisfacción a la hora de intentar resolverlo. El Propósito, el tercer requisito nombrado en el video, es tomar este desafío y de alguna manera poder llevarlo a cabo.
Hoy quiero dedicar este post a tratar de explicar la metodologia scrum. Si no conoces esta metodologia, es muy probable que cuando diga scrum te imagines esto:
Pero no, la metodologia scrum hace referencia a la gestion y desarrollo de software como un proceso, comúnmente, agil.
Algunos terminos frecuentes que se emplean al utilizar scrum:
Scrum Master: Referente o encargado de hacer que el proceso se cumpla y se respete
Sprint: Medida de tiempo. Generalmente es corta, 3 a 4 semanas.
Backlog: Lista de requerimientos priorizados por el Product Owner
Product Owner: Cliente
Si estas pensando que scrum es meramente una forma sofisticada de renombrar entidades que intervienen en nuestro proceso, deberias seguir leyendo.
Scrum básicamente propone ejecutar un proceso e ir ajustándolo durante esa ejecución. Para esto debemos tener una excelente comunicación no solo con el cliente sino tambien con el equipo.
Pregunta: ¿Cómo es posible que un gran
proyecto de software se atrase un año
entero? Respuesta: ¡De a un día a la
vez! Pequeñas demoras incrementales en
variados frentes eventualmente se
acumulan para producir un enorme
retraso. Permanente atención al
alcance de pequeñas metas individuales
se requiere en todos los niveles del
proyecto.
Scrum interviene casi inmediatamente, con daily meetings(reuniones diarias cuyo unico proposito deberia ser decir que tareas que hicimos, que es lo que estamos haciendo y con que vamos a trabajar en un futuro proximo), lo que permite conocer la existencia de estos retrasos a todo el equipo y modificar el backlog, si fuese necesario, de acuerdo a la resolubilidad de los mismos.
Estas reuniones no deberian demorar mas de 15 minutos, ya que no se deberian tocar otros temas mas que los mencionados anteriormente.
Esta metodologia tambien propone un momento en donde el equipo puede hacer una catarsis y decir que fue, para cada miembro del equipo, lo que se estuvo haciendo bien y debe mantenerse y lo que debe ajustarse un poco mas. Esto permite aprender de las fallas e ir mejorando el proceso.
Siempre deberiamos recordar que no existen balas de plata y que estas metodologias tienen que aplicarse a nuestro trabajo, no nuestro trabajo a ellas. Pero mientras mas conozcamos, mayor va a ser nuestra capacidad para elegir la mejor herramienta para cada tarea.
Cuantas veces hemos escuchado en una entrevista, preguntas del estilo ¿Podrías nombrarme cual es la falla mas grande que has tenido?, o peor aun, ¿Cómo has solucionado la misma?
Lo primero que uno piensa es ¿Que se supone que debo contestar?, quiero decir, el razonamiento lógico de cualquiera seria pensar que si tuvimos alguna falla demasiado grande, automáticamente no calificamos para un determinado trabajo. Pero esto no es así.
He leído muchos libros que mencionan la falla, como principal punto de aprendizaje. Pero hubo un libro, con el que me identificado profundamente: The Art of Project Managment by Scott Berkun
Un concepto bastante simple (simple is not easy) es el que Scott Berkun dice:
Learn as much as possible from others peoples failures
Scott, cuenta en su libro acerca de que muchas fallas son relativamente comunes entre proyectos, o mejor dicho, se pudieron haber evitado. Propone observar las fallas ajenas y aprender de las mismas.
Si bien hay que destacar que este proceso, no solo debe hacerse cuando las cosas fueron mal o se pudieron mejorar, sino también cuando las cosas fueron bien. Obviamente, resulta difícil hacer un análisis de que aprender, cuando todo va bien. Esto me recuerda a otro libro llamado: To engineer is human by Henry Petroski
En el que Henry Ptrosky dice:
Failures force us to pay attention
Si bien la falla es el disparador principal para prestar atención al proceso, no debería ser el único.
Scott también cuenta acerca de un famoso libro de la empresa Boeing, llamado Black Book
The Black Book, o el libro negro, es un libro en el que se escribe, desde los inicios de la empresa. Básicamente relata todos los diseños de aviones, que fueron un fracaso. Detallando específicamente el porque. Este libro pretende dejar asentado por los problemas que pasaron los ingenieros de la empresa y de alguna manera no volver a repetirlos.
Conclusion:
No tengas miedo a la hora de
responder ¿Cual ha sido la falla mas
grande que has tenido? El que te este
haciendo esta pregunta quiere saber
como lo has resuelto, no le interesa
que hallas fallado, seguramente el
también lo ha hecho.
Seria una buena practica que
recuerdes periódicamente los
principales motivos que te han
llevado a que un proyecto falle o
haya sido exitoso. Esto te ayudara a
corregir ciertos procesos del mismo.
