¿Murió el desktop?


 


La respuesta rápida es NO, no murió. La explicación es algo más compleja. Sin considerar los cientos de aplicacioneslegacy que hay en mercado, nos concentraremos en el tema de nuevos desarrollos.

¿Quién encararía hoy en día un desarrollo en desktop en lugar de uno web?

Aunque no lo crean, existen varias situaciones en las que una aplicación desktop es más adecuada que un desarrollo web. 
Fundamentalmente, esto es aplicable cuando la aplicación va a ser consumida internamente por los usuarios locales de la empresa y no debería ser accedida desde el exterior. Esta premisa tiene que cumplirse sí o sí. Sin embargo, existen algunas otras consideraciones que le imprimen más fuerza a esta decisión, como ser:

  • Se debe realizar un desarrollo rápido (RAD): esto influye no sólo en los tiempos del proyecto, sino en los costos, los cuales bajan considerablemente.
  • La seguridad es un factor crítico: no tiene sentido subir una aplicación a la web y exponerse a ataques de usuarios no deseados.
  • La performance de la aplicación es un factor importante a considerar: no existe un entorno más rápido que el desktop.
  • Se requiere el uso de controles de usuario sofisticados: si bien existen hoy día controles web impresionantes, no llegan al nivel de los que existen para desktop.
  • La aplicación no puede depender de la conectividad a Internet para funcionar: por ejemplo, el caso de un sistema de facturación.

Conclusión:

Lo anterior no significa que siempre se deba desarrollar para entornos desktop ni que se deba tomar una decisión a nivel general de la empresa para toda su línea de sistemas, sino que hay casos en que un desarrollo web es ideal, otros en que lo es un desarrollo móvil y otros en que lo es uno desktop.

Anuncios
Publicado en NelsoN. Leave a Comment »

¿Visual Basic .NET ó C#?


 


Introducción

Este artículo ofrece un breve análisis acerca de Visual Basic .NET y C#, los dos lenguajes más utilizados de la plataforma .NET, desde un punto de vista no técnico, sino de lo que ambos lenguajes pueden ofrecer a los desarrolladores; su objetivo es brindar una referencia para los desarrolladores que recién se inician con la plataforma .NET, y aún no deciden qué lenguaje utilizar.

¿VB .NET vs. C#?

Pareciera que estos dos lenguajes de la plataforma .NET se basan en una misma especificación; que se traducen a un lenguaje común antes de ser convertidos en código máquina y utilizan los mismos recursos del ambiente de ejecución; las mismas librerías de clases y, sobre todo, que su performace es igual, que no ha sido todavía asimilada, sobre todo por aquellos desarrolladores que anteriormente ya utilizaban lenguajes basados en C.

Gran polémica es la que despierta este tema, cada vez que alguien hace la pregunta ¿Cuál lenguaje es mejor: Visual Basic .NET ó C#? Siendo que esta pregunta tan simple puede responderse con otra pregunta igual de sencilla, y que por lo general nosotros mismos nos podemos contestar: ¿Cuál te gusta más? O puesto de otra manera: ¿Con cuál de los dos te sientes más cómodo? Y no es que uno sea mejor que el otro, sino que uno puede acoplarse mejor a nuestras habilidades y necesidades. Ahora, y como anteriormente ha sucedido, no faltará quien suponga que C# es mejor por ser un lenguaje basado en C; sin embargo, ¿Con qué fundamento se hacen estas suposiciones? Si has estudiado un poco la plataforma .NET sabrás ya que todos los lenguajes se “compilan” a un mismo lenguaje intermedio (aún cuando los archivos resultantes de esta compilación sean .EXE ó .DLLl), al cual normalmente se hace referencia como MSIL ó IL; y que además la plataforma cuenta con un componente conocido como CLR (Common Language Runtime) el cual se encarga, entre otras cosas, de convertir estas instrucciones en IL hacia código de máquina justo antes de su ejecución haciendo uso de un compilador JIT. Ahora, el punto importante en este párrafo es que “todos los lenguajes se compilan a un mismo lenguaje intermedio”, pues en ningún momento da pie a suponer que una aplicación escrita en C# nos dará como resultado un mejor IL que la misma aplicación escrita en Visual Basic .NET, o viceversa; tomando el clásico programa de ejemplo “hola mundo”, se puede comparar el IL generado en Visual Basic .NET con el generado en C#.

VB .NET

Module Hola Sub Main()   Console.WriteLine("Hola mundo  desde una app en VB!!!")   Console.Read()   End Sub
 End Module 
1. .method public static void  Main() cil managed
    2.  {
    3.  .entrypoint
    4.  .custom instance void [mscorlib] System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
    5.  // Code size 20 (0x14)
    6.  .maxstack 8
    7.  IL_0000: nop
    8.  IL_0001: ldstr "Hola mundo desde una app en VB!!!"
    9.  IL_0006: call void [mscorlib]System.Console::WriteLine(string)
    10. IL_000b:  nop
    11. IL_000c:  call int32 [mscorlib]System.Console::Read()
    12. IL_0011:  pop
    13. IL_0012:  nop
    14. IL_0013:  ret
    15. } // end of method Hola::Main

C#

class Class1 {   [STAThread]   static void Main(string[] args) {     Console.WriteLine ("Hola mundo desde una app en C#!!!");     Console.Read();   }
}
1. .method private hidebysig static void  Main(string[] args) cil managed
    2.  {
    3.  .entrypoint
    4.  .custom instance void [mscorlib] System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
    5.  // Code size 17 (0x11)
    6.  .maxstack  1
    7.  IL_0000: ldstr "Hola mundo desde una app en C#!!!"
    8.  IL_0005: call void [mscorlib]System.Console::WriteLine(string) 
    9.  IL_000a:  call int32 [mscorlib]System.Console::Read()
    10. IL_000f: pop
    11. IL_0010: ret
    12. } // end of method Class1::Main

Lo primero que habrás notado es que el programa en Visual Basic .NET genera tres líneas más de código IL (las líneas 7, 10 y 13) que el programa en C#, y te preguntarás por qué. Esto es simplemente debido a que Visual Basic .NET permite agregar puntos de interrupción en líneas de código no ejecutable, como por ejemplo en un End Sub, y esto lo maneja agregando instrucciones nop (No Operation) al IL generado; sin embargo, estas instrucciones, de las cuales cabe mencionar que su consumo de ciclos de procesamiento es prácticamente nulo, solo son agregadas cuando la compilación se hace en modo de depuración, de manera tal  que si compilamos la misma aplicación utilizando la opción Release obtenemos el siguiente IL:

VB.NET

Module Hola  Sub Main()   Console.WriteLine("Hola mundo  desde una app en VB!!!")   Console.Read()   End Sub
End Module
1. .method public static void  Main() cil managed 
    2.  { 
    3.  .entrypoint 
    4.  .custom instance void [mscorlib] System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
    5.  // Code size 17 (0x11)
    6.  .maxstack 8
    7.  IL_0000: ldstr "Hola mundo desde una app en VB!!!"
    8.  IL_0005: call void [mscorlib]System.Console::WriteLine(string)
    9.  IL_000a: call int32 [mscorlib]System.Console::Read()
    10. IL_000f: pop
    11. IL_0010: ret
    12. } // end of method Hola::Main 

Como se puede ver, es prácticamente igual al IL generado por la aplicación escrita en C#, y esto se debe precisamente a que todos los lenguajes de la plataforma .NET son traducidos al mismo IL y a que todos los lenguajes, para poder formar parte de la plataforma, deben cumplir con el CLS (Common Language Specification), que son todas las especificaciones necesarias para ser considerado como compatible, y asegurar la compatibilidad entre componentes escritos en los diferentes lenguajes.

Nota: el código presentado en el ejemplo anterior fue generado con el Visual Studio 2003, y para la visualización del IL puedes utilizar la utilería ILDASM.exe incluida con el SDK del .NET Framework.

Aún cuando todos los lenguajes de la plataforma .NET son traducidos a un mismo IL, las diferentes opciones de compilación pueden generar un IL drásticamente diferente, con sus consecuentes diferencias en desempeño. Lo que es un hecho es que los diferentes compiladores, por defecto, tienen diferentes opciones de compilación; por esta razón, es importante comprender cual es el resultado de compilar un programa con las diferentes opciones que ofrece un determinado compilador. Entendido esto, se puede asegurar que programas equivalentes, compilados con opciones equivalentes y aún cuando hayan sido escritos en diferentes lenguajes, siempre generaran el mismo IL, que una vez compilado por el CLR, se comportara, y tendrá un desempeño igual.

¿Qué dice Microsoft?

Solo basta con echar un vistazo al White Paper "Differences Between Microsoft Visual Basic .NET and Microsoft Visual C# .NET" para darnos cuenta de que ambos lenguajes son considerados igualmente poderosos y que realmente no existen argumentos para suponer que alguno de ellos es superior. El siguiente párrafo ha sido extraído precisamente de la introducción de ese documento.

"Debido a las diferencias del pasado entre Microsoft Visual Basic , Microsoft Visual C , y Microsoft Visual C++ , muchos desarrolladores tienen la impresión de que Microsoft Visual C# .NET es un lenguaje mucho más poderoso que Microsoft Visual Basic .NET. Algunos desarrolladores asumen que muchas cosas que son posibles en Visual C# .NET son imposibles en Visual Basic .NET; de igual forma en que muchas cosas que son posibles en Microsoft Visual C 6.0 ó Microsoft Visual C++ 6.0 son imposibles en Microsoft Visual Basic 6.0. Asumir esto es incorrecto. Si bien existen diferencias entre Visual Basic .NET y Visual C# .NET , ambos son lenguajes de programación de primera clase basados en el Microsoft .NET Framework , y ambos son igual de poderosos."

Diferencias

Si revisamos un poco más este documento, encontraremos que muchas de las diferencias entre los lenguajes son puramente de sintaxis, y muchas tan triviales como que un entero se indica en en VB .NET con la palabra clave Integer, y en C# con la palabra clave int; como la forma de declarar variables, el uso de paréntesis, corchetes y llaves; y en general como las diferencias entre un lenguaje cuya sintaxis es heredada del C y otro cuya sintaxis es heredada del BASIC. Por otra parte también existen diferencias un poco más significativas tales como el chequeo de desbordamientos, el paso de parámetros y la vinculación tardía, puntos que son manejados de manera un poco diferente por ambos lenguajes; además VB .NET incluye, por facilidad y compatibilidad, un conjunto de funciones preconstruidas tales como: LEN, MID, CInt, IsDate, etc., y permite el uso de un manejo de errores estructurado; y por compatibilidad permite también el manejo de errores no estructurado.

¿Y el soporte?

He escuchado mucho decir que hay más ejemplos en C# que en Visual Basic.NET; que la mayoría del código escrito hasta ahora en .NET está en C#; que existen más y mejores tutoriales en la Web, y esto es algo que no puedo negar ni afirmar, sin embargo pienso que el grueso de los desarrolladores de Visual Basic, aún no han hecho la transición desde el Visual Basic 6 hacia el Visual Basic .NET, a diferencia de los desarrolladores de C y C++, quienes en su necesidad de poder utilizar una herramienta RAD que les permita aminorar los tiempos de desarrollo, han hecho esta transición lo antes posible.

¿Cómo decido?

Si ya has decidido utilizar .NET como plataforma de desarrollo, creo que el enfoque principal debe centrarse en aprender los aspectos del funcionamiento del .NET Framework, y la decisión acerca de cuál lenguaje a utilizar dependerá más de tu experiencia previa con otros lenguajes tales como el C, el C++ ó el Visual Basic, ya que la curva de aprendizaje será mucho menor si eres un desarrollador con experiencia en C y decides utilizar C#; de igual manera, si eres un desarrollador con experiencia en Visual Basic, esta curva de aprendizaje será menor si eliges Visual Basic .NET, ya que esto permite centrarse en aprender los aspectos nuevos y específicos del .NET Framework y no centrarse en aprender aspectos específicos del lenguaje tales como su sintaxis, por ejemplo. Esto no quiere decir que debamos cerrarnos a un solo lenguaje, sino que es más fácil aprender esta plataforma haciendo uso de un lenguaje con el que ya estás familiarizado.

Conclusión

Ya que ambos lenguajes están basados en la misma plataforma (.NET), y hacen uso de los mismos recursos (.NET Framework), podemos obtener los mismos resultados con uno y otro; lo que nos da la libertad de seleccionar el lenguaje que más se acomode a nuestras necesidades y experiencia previa sin sacrificar la potencia o la funcionalidad que el lenguaje nos ofrece, permitiéndonos esto centrarnos más en aprender los aspectos nuevos de la plataforma, que a fin de cuentas son comunes a todos los lenguajes.

Esto no quiere decir que debamos quedarnos con un solo lenguaje; al contrario, una vez que hayamos dominado uno, debemos empezar a aprender otro nuevo, ya que las condiciones en las que desarrollamos aplicaciones no siempre será las mismas pero eso sí, siempre hay que estar preparado.

 

 

Publicado en NelsoN. Leave a Comment »

Colección gratuita de libros Microsoft: Office, SharePoint, SQL Server, Windows Azure y Windows Server



En una reciente publicación Eric Ligman, presenta una gran colección de libros relacionados a tecnologías Microsoft. Encontramos libros sobre:

  • Office & Office 365
  • SharePoint
  • SQL Server
  • System Center
  • Visual Studio
  • Web Development
  • Windows
  • Windows Azure

Todos los libros estan disponibles en formato EPUB, MOBI y PDF

Colección de libros Microsoft

Publicado en NelsoN. Leave a Comment »

10 grandes programadores responden como aprendieron a programar



10 de los más reconocidos programadores y creadores de Linux, PHP, Python y Java nos cuentan como fueron sus primeros pasos en la programación.

Steve Yegge (Blogger): Aprendí por mi cuenta a programar en una calculadora HP usando el lenguaje de pila de notación polaca inversa (RPN) cuando tenía 17 años. Había intentado aprender a programar antes, pero nunca terminaba de “captar” el concepto. Las calculadoras científicas HP 28c y 48g eran bastante poderosas y tenían excelente documentación. Escribí un visualizador de mallas 3D para la 48g – tenía un libro de gráficos 3D y muy laboriosamente logré traducir un ejemplo desde Pascal al lenguaje de pila RPN. Fue muy inspirador verlo funcionar. Luego compré una PC y Turbo Pascal, y comencé a estudiar programación con ganas. Ya programaba bastante bien cuando ingresé a la universidad para el curso de Ciencias de la Computación.

Fui a la Universidad de Washington y conseguí un título terciario en Ciencias de la Computación. Definitivamente valió la apena, y le recomiendo a todos los programadores que consigan un título en sistemas si pueden.

Linus Torvalds (Linux): No aprendí a programar en la escuela, sino por mi cuenta leyendo libros y practicando (inicialmente en una Commodore VIC-20, más tarde en una Sinclair QL).

Dicho esto, creo que en especial la Universidad me resultó muy útil. En vez de ir a una universidad de ingeniería, fui a la Universidad de Helsinki, que es bastante teórica, así que la enseñanza no se centra mucho en la programación (que era una pequeña parte, y de todas formas terminé haciendolo “por otro lado”), sino que la mayoría de los cursos se enfocaban en los conceptos fundamentales y en cosas como análisis de complejidad.

Si bien puede parecer aburrido e incluso una pérdida de tiempo, creo que fue útil y lo disfruté la mayor parte del tiempo. Y probablemente soy un mejor programador gracias a eso.

David Heinemeier Hansson (Rails Framework): Aprendí a programar al crear mi primer página web en HTML. Después quise crear algunas partes dinámicas y elegí primero ASP, luego PHP. Luego de que aprendí a programar, comencé a estudiar a la vez una carrera de Ciencias de la Computación y Administración de Empresas.

Peter Norvig (Director de Investigación en Google): Hice cursos en la secundaria y en la universidad, pero siempre sentí que aprendí más por mi cuenta.

Dave Thomas (Escritor especialista en Ruby): Durante la secundaria tomé clases sobre computación. Me enganchó totalmente: me enamoré de la programación, y busqué universidades que dieran cursos de software. Eventualmente fui al Imperial College, parte de la Universidad de Londres. Era el segundo año que ofrecian un curso en software, y fue absolutamente maravilloso: el plantel y los estudiantes trabajaban juntos para hacer que los materiales resulten mejor, y todos aprendiamos un montón. Este curso me dio una excelente base para el desarrollo de software. Me quedé para comenzar un PhD, pero luego lo dejé por un proycto.

Pero la pregunta general es “¿cómo aprendí a programar?”. La respuesta real es que “todavía estoy aprendiendo a programar”. Creo que cualquier buen desarrollador sigue aprendiendo toda su carrera. No es sólo agarrar un lenguaje nuevo y sus librerías: los buenos programadores también refinan sus técnicas y prácticas durante los años.

Guido Van Rossum (Python): Fui a la universidad donde tenían un enorme mainframe y había varios cursos de computación. Fue muy importante para mi.

James Gosling (Java): Al principio aprendí por mi cuenta. Conseguí mi primer trabajo como programador antes de ir a la universidad. Pero estoy contento de haberlo hecho, me divertí un montón. Después seguí adelante hasta obtener un PhD.

Bjarne Stroustrup (C++): En la universidad (Aarhus y luego Cambridge). Las universidades me enseñaron muchas cosas útiles, incluso la mayoría de las bases que sería mi trabajo futuro. Además, aprendí bastante programando por dinero – donde comprender el problema real, mantenibilidad, entrega a tiempo, etc. son temas más importantes que en un entorno educacional.

Tim Bray (XML y ATOM): Pensaba que iba a ser maestro de matemáticas. El programa de matemáticas en la Universidad requería algunos cursos de computación.

Publicado en NelsoN. Leave a Comment »

10 Habilidades que todo desarrollador debe aprender



La siguiente publicación es un extracto del artículo original escrito por David Tucker (post original).

Determinar como invertir nuestro tiempo y energía para crecer como desarrollador es lo más importante que debemos tener en mente antes de emprender.

El siguiente listado recopila las diez destrezas clave que todo artesano de software debe invertir en el transcurso del 2014.

Aprender a desarollar para una plataforma móvil nativa

Existen varias formas de crear aplicaciones móviles, desde medios híbridos HTML  hasta lo que por renderizan controles nativos en otro lenguaje. Es conocido que estos métodos convierten todo en código nativo y si una empresa pretende desarrollar una aplicación debe buscar a una persona quien entienda este tipo de código.

Mejorar esta habilidad y ser quien entienda ese código incrementa su valor dentro de la organización ademas de mejorar su promoción personal como desarrollador.

Conocer un proceso de desarrollo ágil y sus herramientas relacionas

Para aclarar no estoy diciendo que todo desarrollador deba ser un gestor de proyectos. Digo que todo desarrollador necesita entender el proceso. Se necesita conocer como seguir cada proceso en las distintas tareas de un proyecto, además necesita saber como trabajar con otros desarrolladores para poder cumplir con los objetivos. Aún cuando un desarrollador trabaja solo en los proyectos el entender el desarrollo ágil y sus herramientas le permitirán mejorar al momento de medir las tareas y determinar como cumplir con sus compromisos.

Dentro del desarrollo ágil se encuentra Scrum, Kanban, Extreme Programming (XP) y otros. Las distintas herramientas relacionadas a estas metodologías son PivotalTracker o Trello.

Realizar estimaciones/cotizaciones efectivas

Es algo que todo desarrollador debe hacer y  al lograr un buen trato el éxito del mismo se basa no solo en nuestro trabajo sino en el costo final de nuestra cotización. Los jóvenes desarrolladores tienden a ser optimistas en el proceso de cotizar mientras que los desarrolladores más experimentados en el tema tienden a ser un tanto pesimistas.

Para ser realistas no existe una formula mágica que permita realizar esta tarea de una manera efectiva. La clave esta en aprender de cada proyecto, mientras que para cada equipo se debe buscar experiencias en proyectos anteriores y el tiempo de desarrollo para cada “story point”.

Cabe recordad que si se utiliza un proceso de desarrollo ágil se debe sacar provecho a las herramientas relacionadas a esta metodología y calcular nuestras cotizaciones.

Aprender JavaScript

Es algo que no lo hubiese escrito 3 años atras, pero es una verdad que JavaScript se ha vuelto universal. En la actualidad se lo utiliza para escribir aplicaciones móviles, aplicaciones servidor, crear plataformas de bloggin, en realidad casi cualquier cosa que puedas imaginar.

Uno de los mayores avances es la capacidad de utilizar JavaScript como una capa lógica  intermedia en iOS 7. La omnipresencia de las tecnologías web crece. Cabe denotar algo importante aquí, al hacer referencia de JavaScript no digo aprender jQuery. Me refiero a conocer y aprender el verdadero lenguaje.

Aprender un lenguaje de lado del servidor

Este es un elemento crucial, si eres un desarrollador front-end principalmente entonces necesitas conocer el funcionamiento de las cosas del back-end. Ser capaz de crear tanto el front y back-end además de la API y base de datos demuestra un conjunto único de habilidades. Afortunadamente existen varias opciones Java, .NET, Python y PHP. Una ventaja para quienes conocen JavaScript es el poder utilizar NodeJS, es increible la forma fácil de montar un servidor web, crear test simples o servicios para una aplicación móvil y el poder desplegar aplicaciones en la nube en servicios tal como Heroku y Nodejitsu.

Aprender HTML y CSS

Algo que podemos encontrar en casi toda tecnología web es su capacidad de renderizar contenido en HTML y aún cuando no trabaje en desarrollo web el entender HTML y CSS solo te beneficiará. Algo que recomiendo es que todo desarrollador deba tener un blog esto ayuda a mejorar su promoción personal y en muchas ocasiones se debe meter mano al código y modificar nuestra plataforma de bloggin.

Saber encontrar información de una manera rápida

Quiero analizar un dato importante y es la cantidad veces que dejamos de escribir código para dedicarnos a buscar información en internet, es verdad esto nos sucede y es en grandes cantidades. El poder encontrar información de una manera rápida nos ayudará a reducir el tiempo que pasamos lejos de nuestro ambiente de desarrollo.

Dar mantenimiento a un proyecto

Es necesario conocer como agregar código y en definitiva mejorar nuestro proyecto una vez que lo hayamos liberado. La clave es entender las distintas opciones  que tenemos como desarrolladores para cumplir con este objetivo y que no afecte la portabilidad y extensibilidad de nuestro código base. Como desarrollador o arquitecto debemos tomar en cuenta que cada opción tiene sus consecuencias.

Aprender Git (Y aprenderlo bien)

Git es más que un sistema de control de versiones ofrece un sistema eficiente de ramas (branching) lo que permite generar un nuevo flujo de desarrollo tanto para equipos de trabajo o desarrolladores independientes. Vincent Driessen propone una guía para el manejo de ramas dentro de Git.

Si eres nuevo en Git, dedicate a aprender!. Si eres un novato, mejora tus conocimientos de Git para convertirte en un mejor desarrollador.

Aprende a utilizar una herramienta de seguimiento de tareas y bugs

Realizar el seguimiento de tareas y bugs en un proyecto es esencial además de ser una tarea diaria para todo desarrollador. Existen un conjunto de herramientas gratuitas que cumplen esta función (Github Issues o Issue Tracker Bitbucket), en algunos casos los proyectos requieren herramientas mas sofisticadas como JIRA para su proceso de desarrollo.

Publicado en NelsoN. Leave a Comment »

El método simplificado de resolución de problemas


En su blog Henry Kniberg comparte su propia adaptación del método A3 para la resolución de problemas, que busca ser una metodología para entender y resolver cualquier problema que pueda surgirnos. Es un enfoque interesante y sistemático, muy interesante para tener a mano.

A continuación les dejo una traducción con los 17 pasos sobre esta técnica para resolver problemas.


  1. Darle un nombre al problema. Por ejemplo, "Bugs en producción". Más tarde lo podremos reformular. Mantenerlo neutral, sin hacer acusaciones.
  2. Identificar las distintas perspectivas del problema. Por ejemplo: desarrolladores, testers, operaciones.
  3. Reunir a las personas clave de estas perspectivas (personas que están afectadas por el problema y les importa), y armar una discusión informal delante de un pizarrón. Por ejemplo: un desarrollador, un tester, una persona de operaciones, y el Dueño del Producto. Queremos que haya pocas personas, y que cubran una perspectiva amplia.
  4. Describir el problema, y verificar que todos estén de acuerdo de que es un problema. Quizás pueda reformularse el nombre del problema.
  5. Si hay una solución simple y obvia, implementarla. A veces, el sólo hecho de reunir a las personas indicadas en una misma sala es la mitad de la solución. Si el problema es complejo, recurrente, o no tiene una solución obvia, continuar:
  6. Discutir si realmente vale la pena resolver el problema. No podemos resolver todos los problemas a la vez, por lo cual es importante asegurar la necesidad de dedicarle esfuerzo ahora. Si vale el esfuerzo, continuar:
  7. Hacer un análisis de causa-raíz usando los "5 porqué" o un diagrama de causa-efecto o similar, para comprender la naturaleza del problema y reducir el riesgo de resolver un síntoma en vez del problema real.
  8. Discutir cómo sería la situación "perfecta" (Definición de Inreíble). Si no tuvieramos este problema, ¿cómo serían las cosas? Por ejemplo: "cero bugs en producción". No es necesario ser realistas – la perfeccións es una dirección, no un lugar.
  9. Discutir cuál sería un paso importante hacia la perfección. Por ejemplo, "50% de reducción en los bugs en producción, y cuando se encuentra un bug se soluciona en 1 hora". Debe ser desafiante pero no imposible.
  10. Hacer una lluvia de ideas sobre cambios a realizar, cosas que harían para lograr este primer paso. Ser creativos, incluir ideas sin filtrar, ideas locas o imposibles.
  11. Para cada idea, listar las ventajas y desventajas más obvias.
  12. Decidir en la ejecución de un cambio. Recordar que es un experimento. Si resulta dificil decidirse por uno, votar con palitos o por consenso (todos escriben un número de 1-5 al lado de cada idea, para mostrar cuánto les gusta). No gastar mucho tiempo decidiendo, no sabemos por adelantado cómo va a funcionar. Sólo elijamos una idea que no parezca ser una porquería.
  13. Descubrir quienes se verán afectados por el cambio, y conseguir su apoyo. Si no logramos su apoyo, averiguar qué haría falta para lograrlo. O volver a elegir una de las otras ideas que tienen mejores posiblidades de apoyo. El cambio organizacional no va a ocurrir sin apoyo clave.
  14. ¡Ejecutar el experimento! Y agendar tiempo para hacer un seguimiento.
  15. … (experimentando) …
  16. En la reunión de seguimiento: llevar datos y evaluar lo ocurrido. Por ejemplo: ¿cuántos bugs en producción ocurrieron? ¿cuánto nos llevó arreglarlos?
  17. Compartir las lecciones aprendidas, y decidir si el problema sigue siendo un problema. Si sigue siendo un problema, volver al paso 10 u 11 y realizar otra iteración.
Publicado en NelsoN. Leave a Comment »

El color azul en el diseño Web – Infografia


La gente de TempleMonster ha diseñado una infografía muy interesante respecto del uso del color azul en marcas y el diseño Web. La infografía está muy bien diseñada y también nos da la posibilidad de copiar el código de color de distintos azules.


Temple-Monster-infografia

Publicado en NelsoN. Leave a Comment »