de.interes

Publicaciones/articulos de interes, material que no debe pasarse por alto leer.  Material de distintos autores, que vale la pena tener una copia de sus articulos con referencias a los fuentes originales, porque difundir las palabras de estos excelentes autores es una lectura que nadie debe perderse de leer.


Buscar Empleo en el Siglo XXI – 10 Verdades sobre el trabajo en el mundo laboral actual

Articulo de Pedro Rojas (cuenta twitter SeniorManager), Articulo Original.

Si, …todo cambia, pero… ¿hasta que punto somos lo suficientemente rápidos como para asimilar los cambios y adaptarlos a nuestra vida cotidiana?

Es evidente que la mayoría de la gente sigue buscando empleo como hace diez años, y son pocos los que han descubierto otras alternativas dentro de las tendencias actuales.

Lo cierto es que ya se torna necesario que la mayoría abra los ojos y entienda que el mercado laboral ha dado un giro, y que podemos hablar ya de toda una nueva era laboral… y no sólo desde el punto de vista del que busca un cambio en su carrera, sino también de los profesionales de RRHH que apenas empiezan a experimentar con el Reclutamiento y Selección 2.0.

Para ayudar en ese sentido, les dejo con 10 verdades sobre lo que significa la palabra “trabajo” y el hecho de buscar empleo en el mundo laboral actual:

#1 – Todo trabajo es temporal.

La expectativa de permanecer en el mismo puesto de trabajo o en la misma empresa de por vida, ha quedado como una anécdota del siglo pasado.

Ahora mismo, las personas que buscan su primer trabajo, saben que será precisamente eso: “El Primero”, y están conscientes de que trabajarán para diferentes empresas y posiciones  a lo largo de sus vidas. Y no por   que sea una nueva tendencia; sino porque saben que tienen el derecho de buscar el trabajo que más les satisfaga, que mejor vaya con lo que saben hacer y el que les haga más felices.

#2 – Tu patrono es ahora tu cliente.

Las empresas se avocan cada vez más por contratar a las personas por lo que ofrecen.

Aunque no lo parezca, la verdad es que cada trabajador es en realidad un proveedor de servicios, y las empresas ya tienden a verlos así. De allí el éxito que ha tenido el sistema de “outsourcing” en los últimos años.

Si demuestras que eres un “proveedor de servicios” que ofrece valor a la empresa, en lugar de una persona que sólo busca un trabajo, las oportunidades de contratación aumentan.

#3 – Ahora cuenta el factor “empleabilidad”.

Empleabilidad es la capacidad que cada persona tiene para ser contratado por una empresa en particular, y está en función de lo que mejor sabe hacer.

Lo que se traduce en el uso de las capacidades, competencias y habilidades de una persona en la aplicación de un número “x” de funciones. Mientras más se posean, pues más nivel de “empleabilidad” se tendrá.

El hecho de que a la persona le guste hacer “x” tipo de trabajo, aumenta este factor.

#4 – Ser feliz en el trabajo no es una utopía. Es una opción.

Es un hecho cultural aceptado asociar al trabajo, y al acto de ir a trabajar, como algo “malo” y negativo. Este paradigma lo recibimos en principio en el hogar y luego se va reforzando en los diferentes ámbitos a los que nos vamos relacionando mientras nos desarrollamos como personas.

Es así como llegamos a nuestro primer empleo con la sensación de que la empresa es nuestro enemigo y que debemos hacer lo posible por hacer cumplir todos nuestros derechos laborales a rajatabla, intentando al mismo tiempo saltarnos la mayor cantidad posible de obligaciones contractuales.

La verdad es que si se puede ser feliz en el trabajo; pero para poder serlo, lo primero que debemos hacer es borrar estos absurdos paradigmas que empañan nuestra visión de lo que significa trabajar, lo segundo es intentar encontrar un empleo haciendo lo que mejor sabemos hacer y lo que nos gusta hacer.

#5 – Los portales de empleo estáticos están caducados.

Los portales estáticos ya no sirven para buscar empleo, y representan más una pérdida de tiempo que otra cosa.

Por otro lado, la gente ya deja de creer que pueda tener éxito buscando empleo en una oferta (por ejemplo de InfoJobs) a la que se han apuntado 300 personas, y de las que ya se sabe que hay muchas duplicadas, e incluso falsas.

No es un secreto que el 80% de las ofertas se cubren a través de contactos, así que lo mejor es potenciar los mismos. Otra buena opción es apuntarse a los nuevos portales de empleo 2.0, los cuales promueven el Networking y generan oportunidades reales: http://es.BuscoJobs.com, http://jobsket.com, http://infoempleo.com, http://quieroempleo.com

#6 – Un título ya no es garantía de un buen empleo.

Aunque en la cultura latina seguimos sufriendo de “titulitis”, está claro de que las empresas van a enfocarse cada vez más en las competencias, en la experiencia y en las habilidades de las personas antes de decidir contratarlas sólo por tener un título.

No obstante, las titulaciones siguen siendo un plus que no podemos desestimar; la pregunta es: ¿por cuánto tiempo?

#7 – Una carrera profesional no es una línea recta.

Con la reciente crisis, hemos evidenciado la desaparición de miles de puestos de trabajo y de empresas que no volverán a existir.

No podemos seguir viendo nuestra carrera profesional como una línea continua a seguir, sino como un camino con una serie de bifurcaciones en las que hemos de estar preparados para cambiar de rumbo, de dirección y de destino.

Incluso hemos de prepararnos para retroceder, lo que ahora mismo no significa un fracaso, sino una opción más dentro del complejo mundo laboral.

Llevar 10 años haciendo lo mismo, no te asegura una carrera. Lo mejor es estar preparado mentalmente para cambiar cuando la situación lo amerite.

#8 – Ahora lo que importa es aportar valor calculable para la empresa.

Un candidato ya no puede pretender obtener un trabajo diciendo que es responsable, que sabe trabajar en equipo, que es buen líder o que su mayor defecto es ser “perfeccionista”.

Ahora las empresas no contratan, “invierten”; por lo que el candidato ha de demostrar que es realmente una inversión, ya sea por que su trabajo represente un ahorro o más beneficios para la empresa.

#9 – El Reclutamiento y Selección son y seguirán siendo discriminatorios.

¡Alguien se ha preguntado por qué siguen pidiendo una foto reciente en la cabecera del currículo!, …¿realmente importa como luce una persona en relación a su capacidad para hacer algo? ¿Qué quiere decir “buena presencia”?

Somos humanos y nos dejamos guiar por lo que vemos; lo que significa que nuestros prejuicios, nuestros valores, nuestras experiencias y nuestra formación de hogar, siempre van a condicionar nuestras decisiones.

Mientras sigamos siendo “juzgados” laboralmente por lo que los demás perciben de nosotros, en lugar de por nuestras competencias. La discriminación seguirá presente.

#10 – La orientación laboral actual es una técnica obsoleta.

Siento mucho tener que afirmar que los orientadores de oficio en España, están aplicando técnicas del siglo XX para candidatos del siglo XXI.

Acudir a los servicios de empleo de cualquier provincia y pedir orientación, ya no representa una ventaja, ya que la mayoría de estos funcionarios basan sus orientaciones en situaciones de hace 10 años, y la verdad es que el mundo laboral ha cambiado mucho desde entonces.

Por otro lado, hay que preguntarse: ¿cómo puede servir el consejo de alguien que nunca ha contratado a nadie? …es para reflexionar.


La Usabilidad como metodologia para el desarrollo de una aplicacion

Olga Carreras Montoto
Articulo original
Consultora de accesibilidad y usabilidad.
Maquetación Web bajo estándares W3C y WAI.

Este es un resumen del articulo original, para mas detalle y una lectura completa del material, visita el link de Articulo original presente en la descripcion de su autor, el cual indica sus fuentes (referencias) para su articulo.

Muchas personas confunden además los términos “usabilidad” y “accesibilidad”, que sin bien están estrechamente relacionados, ni son sinónimos ni antónimos. Creo además que hay mucha más gente que sabe lo que es la accesibilidad (aunque lamentablemente lo reduzcan a “que los ciegos puedan acceder a una aplicación”) que los que saben realmente qué es la usabilidad.

Para la mayoría de los profanos la usabilidad se reduce a una serie de reglas, reglas como “que los enlaces estén subrayados”, “que los menús estén siempre en el mismo sitio”, “poner migas de pan y un mapa del sitio”.

Por supuesto es cierto que toda persona dedicada a la usabilidad debe, no ya conocer, sino tener interiorizadas unas pautas de usabilidad, pero la usabilidad es más que unas pautas, que unas leyes o que determinados estudios y personajes, la usabilidad supone toda una metodología de trabajo.

¿Por qué fracasó ese portal web?

Parecía el portal perfecto. Tanto los desarrolladores como los clientes estaban más que satisfechos. Era precioso, tenía mucha información, era rápido, no había errores, estaba exquisitamente programado, incluso era accesible doble-A. Y sin embargo, cada vez recibía menos visitas, éstas abandonaban rápidamente el portal, nadie realizaba trámites o compras online…

Ese portal fracasó por una única razón, porque estaba centrado “en el cliente”. El cliente redactó los textos, el cliente decidió cómo estructurar el portal, el cliente, el cliente, el cliente…

¿Y el usuario?

El portal no resultaba útil a los usuarios, quienes se sentían perdidos, incapaces de encontrar la información o realizar las tareas para las que entraron.

La usabilidad como metodología de trabajo: Diseño Centrado en el Usuario(UCD)

El Diseño Centrado en el Usuario(UCD) es una metodología estructurada de desarrollo de producto que implica a los usuarios a través de todas las etapas de desarrollo del mismo. El objetivo es crear un producto que aúne los objetivos de negocio de una organización y resuelva las necesidades de los usuarios.

Los beneficios son conocidos por todos: aumenta la productividad, la satisfacción del cliente y las ventas, se reducen costes, etc.
Podría basarme en muchas fuentes o citar mucha bibliografía para desarrollar el tema de la usabilidad como metodología de trabajo, pero voy a centrarme en una única fuente que me encanta y que creo que debería ser la web de cabecera de todo jefe de proyecto: la metodología desarrollada por el gobierno de EEUU en materia de usabilidad que se recoge en usability.gov

Esta metodología consta de 4 pasos:

  • Plan
  • Analyze
  • Design
  • Test & Refine

Voy a resumir brevemente cada paso. Para desarrollar cada apartado, ver ejemplos, etc. podéis acudir directamente a usability.gov

Plan

Think About the Process

Reflexiona sobre la audiencia que deseas atraer al portal y clasifícala por grupos, por roles en relación con el portal, etc.

Verifica tus presunciones previas acerca de los usuarios del portal: qué necesidades tienen, qué expectativas, qué nivel de conocimientos sobre el tema que trata, qué experiencia con sitios similares, etc.

Follow Research-Bases Guidelines

En este apartado se recogen las pautas de usabilidad que toda persona involucrada en la creación de un portal web (diseñadores, maquetadores, especialistas de usabilidad, etc.) debe interiorizar:

Develop a Plan

Se trata de realizar el Project Plan, establecer el alcance del proyecto, los objetivos, entender los requisitos, establecer el timeline, pensar en los recursos necesarios y los costes.

Assemble a Project Team

El siguiente paso lógico es crear el equipo de trabajo correctamente dimensionado y con los perfiles necesarios: especialistas en usabilidad y arquitectos de la información, diseñadores gráficos, escritores web, programadores, especialistas en la materia sobre la que trata el portal, etc.

Hold a Kick-Off Meeting

Kick-off meeting hace referencia aquí a la reunión interna de comienzo del proyecto, con tu equipo, para aunar criterios. Por kick-off meeting yo suelo entender la reunión con el cliente para hablar sobre los requerimientos del proyecto, los objetivos, sus usuarios, etc.

Lo más interesante de este apartado en la lista de preguntas que no pueden faltar en el kick-off meeting y que nos sirve para ambos casos.

Write a Statement of Work (SOW)

En este apartado se recoge el caso de que se vaya a subcontratar el diseño y las tareas de usabilidad, en cuyo caso es necesario redactar un SOW (se incluyen ejemplos) describiendo el trabajo que se debe realizar, el timeline, etc. de modo que el empresa aspirante pueda realizar una oferta. Se apunta también cómo valorar esa oferta.

Hire a Usability Specialist

Especifica cómo seleccionar a un experto cualificado en usabilidad, indicando qué conocimientos y experiencia es necesario que tenga.

Analyze

Evaluate Your Current Site

Se trata de evaluar el portal actual de la organización y contestar a tres preguntas: ¿cumple con los objetivos de la organización? ¿satisface las necesidades de los usuarios? ¿sigue las pautas de usabilidad?

Para contestar a estas preguntas se proponen distintas acciones: revisión de logs, test de usabilidad, revisión heurística, etc.

Learn About Your Users

Es este apartado se explican las diferentes técnicas para recopilar toda la información posible sobre los usuarios del portal: test de usabilidad, entrevistas contextuales, focus groups, etc.

Conduct Task Analysis

Se trata de estudiar las tareas que se pueden realizar en el portal, las que los usuarios intentar realizar y cómo las realizan. De este modo se puede establecer qué tareas son necesarias, refinando la navegación o la búsqueda para facilitar la manera más eficiente de realizarlas y emparejándolas con las metas de los usuarios.

Develop Personas

Este punto me encanta. Gracias a todo lo anterior tenemos claramente identificados a los grupos de usuarios de nuestro portal. Bien, pues se trata de que cada grupo sea representado por un personaje ficticio.

Se debe crear una ficha para cada uno de estos personajes, una ficha con foto, nombre y apellidos, datos personales (su edad, educación o etnia), datos profesionales (cargo y responsabilidades), datos referentes a sus objetivos, metas y tareas en relación con el portal, etc. Y por supuesto colgar estas fichas en la pared a la vista de todo el equipo.

¿Por qué se hace esto? Por muchas razones:

  • De este modo las metas y necesidades de los usuarios se convierten en el objetivo común de todo el equipo
  • El equipo se concentra en diseñar un portal para un número manejable de personajes que saben que representan las necesidades de muchos usuarios
  • Los diseños se evalúan constantemente contra los personajes
  • Los desacuerdos sobre el diseño se resuelven referenciándolos a los personajes
  • Etc.

Según Forrest muchas compañías como Microsoft desarrollan personajes porque permiten:

  • Una comprensión mejor de los clientes
  • Ciclos más cortos de diseño
  • Mejor calidad del producto

Write Scenarios

En este apartado se detalla cómo elaborar los escenarios. Un escenario es una historia corta sobre un usuario específico con una meta concreta en el portal, por qué viene al sitio y qué desea hacer.

Es crítico para el diseño del portal, puesto que si tienes los panoramas más comunes antes de construir el sitio, estarás centrándote en el usuario y las tareas que este desea realizar en el portal antes que en la organización y la estructura interna del mismo. Sabrás qué contenido debe tener el sitio y qué contenidos deben ser los más fáciles de encontrar y entender.

Set Measurable Usability Goal

Se trata de establecer metas mensurables de usabilidad en cuanto al tiempo para realizar una tarea, la exactitud con la que se realiza y el éxito en su realización.
Un ejemplo de meta mensurables sería: que el 95% de los viajeros sean capaces de realizar una reserva online en menos de dos minutos.

Design

Determine Web Site Requeriments

Antes de empezar el diseño, es necesario tener claros los requisitos, es decir, las características, las funciones y el contenido del portal, todo lo que debe tener y lo que debe admitir que los usuarios hagan.

El resto de pasos del diseño te ayudan a cerciorarte de que el sitio está organizado, escrito, y diseñado para satisfacer los requisitos

Conduct a Content Inventory

Se trata de realizar una lista de todo el contenido del sitio, que incluya todas las páginas, e indicar por cada contenido determinados datos: url, título, descripción, quién escribió la página, responsable de su actualización, etc.

Se puede organizar por categorías o por fechas, de manera que permita saber: en un portal nuevo, todo el contenido que es necesario desarrollar de una manera controlada y metódica; en la actualización de un portal nuevo, revisar qué contenidos faltan, sobran o deben ser revisados.

Perform Card Sorting

Descripción detalla de la técnica card sorting, técnica que permite construir la estructura del portal y etiquetar las categorías de forma que la organización del sitio sea lógica para los usuarios.

Define the Information Architecture

Da las claves para definir la navegación del sitio, de manera que refleje el propósito primario de la organización y ayude a los usuarios a encontrar rápidamente la información, por ejemplo recogiendo en la home lo más importante y las tareas más realizadas. Explica cómo crear un mapa del sitio y un wireframe.

Writing for the Web

Este es un punto fundamental que muchas veces se deja de lado: escribir para la web no es lo mismo que escribir para una publicación impresa, por ello necesitamos profesionales especialistas en la redacción para la web, que conozcan las particularidades de este medio. Asimismo es necesario reflexionar sobre el contenido que se incluye, ¿es relevante ese contenido para los usuarios, es lo que desean o necesitan? El usuario no quiere leer, quiere recabar información.

Use Parallel Design

Se propone preparar varios diseños de interfaz alternativos para que después el equipo los evalúe, compare y se puedan fusionar en un diseño final mejorado.

Develop a Prototype

Llega el momento de preparar el prototipo, bien de baja-fidelidad o de alta-fidelidad, que permita comprobar la usabilidad en una etapa temprana y poder realizar modificaciones a tiempo con el menor impacto en el proyecto.

Program the Site

Ya podemos llevar a cabo la maquetación y la programación de la aplicación. Hay que destacar que es en este punto donde se deben aplicar las pautas de accesibilidad de la WAI que aseguren un resultado accesible.

Test&Refine

Learn About Evaluations

Se explica la diferencia entre evaluaciones de usabilidad como la evaluación heurística, en la que no interviene los usuarios sino expertos en usabilidad y que predicen los problemas o éxitos que tendrán los usuarios con nuestra web, de los test o pruebas de usabilidad con usuarios que indicarán si las predicciones fueron válidas.

Se deben realizar en etapas tempranas del proyecto, desde el momento en que se tiene un prototipo.

Learn About Usability Testing

En este apartado se explica en profundidad qué es un test de usuarios.

Develop the Test Plan

Se desarrolla cómo preparar el plan de pruebas de usabilidad, en el que se ha de definir el número de participantes, el número de sesiones y su duración, etc.

Create Final Scenarios

Una vez establecido y aprobado el plan de pruebas, hay que preparar los escenarios, las tareas que los usuarios van a intentar realizar en el test de usuarios.

En este apartado se explica cómo crear un buen escenario, que se entienda sin dificultad, que podría ser por ejemplo ¿En qué edificio del Gobierno puedes encontrar el cuadro que pintó Bertrand Adams en 1937 denominado “Primeros Colonos de Dubuque”?, de manera que el usuario debe encontrar esa información en nuestro portal sin ninguna pista de cómo lograr la tarea.

Recruit Participants

Se explica qué tipo de usuarios deben participar en el test de usuarios y cómo preparar un cuestionarios para seleccionarlos, especialmente útil si se contrata para esta tarea los servicios de una empresa externa. Ejemplo de cuestionario.

Set Up for the Test Sessions

Antes de comenzar el test de usuarios, ¿qué revisar? Que el prototipo funciona, que los ordenadores van bien, que tenemos preparadas las autorizaciones mediante las cuales los participantes autorizan ser grabados, que las cámaras y micrófonos funcionan, etc. o incluso hacer una prueba piloto con uno de los usuarios.

Conduct the Usability Test

Da las claves para conducir un test de usuarios: cómo tratar a los participantes, cómo contestar a las preguntas permaneciendo neutral, cómo tomar las notas (ejemplo de notas), etc.

Analyze the Results

Detalla cómo analizar los resultados, tanto los datos cuantitativos que permitirán extraer datos estadísticos como los cualitativos, en los que habrá que buscar patrones y clasificarlos según su importancia y su carácter global o local.

Prepare the Usability Test Report

Explica como preparar el informe final del test de usuarios, en el que prive la concreción, los resultados y las recomendaciones (ver ejemplo de plantilla).

Implement and Retest

Llega el momento de aplicar las recomendaciones resultantes del test de usuarios y definir el número de iteraciones necesarias para asegurar que los usuarios logran las metas con eficacia.


¿Por qué no sales del barro productivo?

Berto Pena, escritor especializado en Organización, Gestión Personal y Productividad.

Blog y articulo.

El barro productivo es esa situación de ruina productiva en la que muchas personas viven a diario. Lo saben, lo admiten pero no hacen nada por salir de ahí. “Sí, el barro es sucio, sí, es repugnante, sí, lo impregna todo pero, al fin y al cabo, no me hundo del todo”.

¿Por qué no somos capaces de mejorar nuestra Productividad? ¿Por qué a diario nos ahogamos en el mar de tareas, estrés, compromisos y no somos capaces de salir de ahí? Sabemos que algo va mal, lo admitimos y somos capaces de formularlo y hasta escribirlo. Pero seguimos chapoteando en el barro lamentándonos y sin hacer nada.

Leía el otro día que el 95% de los libros de Productividad y Autoayuda se quedan en las estanterías de las casas y jamás son abiertos. De 100 personas que los compran sólo 5 los llegan a leer.

Pareciera como si el hecho de comprarlo y ponerlo junto al de recetas de cocina y la novela de moda fuera suficiente para cambiar las cosas. Lo compramos, y ya acallamos nuestra conciencia, o nuestro sexto sentido, o nuestra mente que un día sí y otro también nos dice que hay algo que va mal. O que van mal muchas cosas. “Me compro un libro… y ya mejoraré”.

“Berto, me he comprado tu libro… ahora a ver si encuentro tiempo para leerlo”. Esto es algo que más de una vez me han dicho. ¿Sabes qué? Que si de 1.440 minutos que tiene el día no encuentras 15 para leerlo es porque no te interesa en absoluto. Ni este libro ni ningún otro. Sencillamente no te interesa mejorar. Piensa en otra cosa.

Quienes viven en el barro productivo comparten una sintomatología común: su rendimiento es bajo o muy bajo, nadan a contracorriente en el mar de tareas, sufren el estrés, su creatividad está por los suelos, apenas tienen vida personal o familiar, etc. Ellos lo saben, se lamentan pero luego prefieren seguir chapoteando en el barro. No cambian, no mejoran. ¿Por qué demonios alguien así no quiere mejorar? Al fin y al cabo, ¡es su vida y sólo tienen una!

Aquí tienes mis 7 razones favoritas por las que alguien no sale del barro productivo:

1. Cambiar supone esfuerzo

La Productividad te cambia la vida por completo pero exige sacrificios, tomar decisiones y esforzarte. Desarrollar nuevos hábitos requiere afán de superación, espíritu positivo, optimismo, determinación y trabajo. ¿Estás dispuesto o no?

2. Estoy con la mayoría

Muchos creen que esto de la Productividad es de bichos raros, de geeks “raritos” o outsiders que van en contra de lo que hace la mayoría. Salirse del rebaño da miedo y más cuando trabajas en una oficina con más compañeros (”Van a pensar que quiero destacar”). Estar al calor de lo que hace la mayoría acalla tu conciencia.

3. Piensas demasiado pero no haces nada

Leer sobre ello ayuda, pensar sobre ello ayuda, meditar sobre ello ayuda, planear sobre ello ayuda… pero todo ello NO VALE PARA NADA si no mueves el culo y lo haces. Cualquier mejora exige un cambio. Deja de darle vueltas y más vueltas, traza un plan pero sobre todo ponte en marcha. Sencillamente… empieza.

4. Los demás tienen la culpa

(Esta es mi disculpa favorita) “Es que yo no trabajo solo y es muy difícil ser productivo con mis compañeros… tú no conoces mi empresa”. Distracciones, interrupciones, falta de compromiso, ausencia de motivación, procrastinación o poco rigor son cosas que SÍ pueden tener quienes te rodean pero que en modo alguno te impiden mejorar a ti. Es como decir “estoy gordo porque en mi barrio sólo hay McDonalds”. Esfuérzate y encontrarás.

5. Quejarse sale barato

Los “llorones productivos” o las “plañideras vitales” son ese tipo de gente que no para de quejarse por lo mal que le va pero no luego no hace ABSOLUTAMENTE NADA por cambiar. Son un auténtico coñazo, porque no sólo su vida es un desastre, sino que además no paran de contarlo a todos. Les saludas, les das un abrazo o chocas la mano con ellos, y tras un “¿qué tal te va?” empiezan a soltar el rosario de penurias. Viven para quejarse.

6. Estás rodeado de demasiadas cosas

Simplificar, soltar lastre, desprenderte de lo que sobra y conseguir una vida más sencilla libre de compromisos y cosas que están de más tiene un propósito claro. Y no es decir: “mira qué vida más zen llevo” sino concentrarte en lo IMPORTANTE. Cuando quitas las tonterías de tu alrededor ves lo importante, te concentras en lo importante, te esfuerzas en lo importante. Tenemos tantas cosas (tareas estúpidas, compromisos absurdos, hábitos innecesarios…) en nuestro día a día que es imposible salir de ese barro. Porque todo lo que no suma, resta.

7. Es más fácil decir que es imposible

“Lo que tú pides es imposible”, me han dicho en alguna ocasión. En primer lugar yo no pido nada. Sólo escribo y cuento cosas que me han ayudado a mí con el afán de que te puedan ayudar a ti.

Yo, a diferencia de otros, SÍ creo en el Pensamiento Positivo y en el Optimismo. Sencillamente porque un pensamiento positivo es mejor que uno neutro u otro negativo porque te EMPUJA a hacer y a mejorar las cosas. Lo he experimentado en mi propia revolución personal y lo sigo viviendo a diario. Y por eso lo cuento.

Decir que es imposible es el primer paso para que sea imposible.


Mi “eleccion magistral” – El Secreto del Exito!

Autor: S. McCoy

Experto financiero que escribe Valor Añadido. Es un incisivo analista que despertó el interés de nuestros lectores con sus brillantes y didácticos artículos sobre empresas, sectores y tendencias del mercado.

Articulo Original: Mi “eleccion magistral” ayer en el IE: el secreto del exito

Primero. El éxito sólo se puede medir en términos de felicidad, de estar a gusto con uno mismo, de ser capaz de enfrentarse a la vida con paz, alegría y optimismo. No son indicadores del mismo ni la cuenta corriente ni la tarjeta de visita. Insisto, no se puede confundir con un estatus, una apariencia que puede ser exitosa o encerrar el más absoluto de los fracasos. La felicidad, y por ende el éxito, se encuentran dentro de uno. Y exigen un trabajo constante que no hay que descuidar. Debe ser la prioridad. Sólo se vive una vez y que tu vida sea un éxito o un fracaso depende sólo de ti. No tanto de lo que pase sino de qué manera afrontas lo que te sucede, sea del color que sea.

Segundo. La primera condición del éxito para por el conocimiento de uno mismo. Haz un análisis DAFO de tus debilidades, amenazas, fortalezas y oportunidades. Si lo haces de cualquier compañía, cómo descuidar tu propia sociedad vital, la conjunción de la materia, alma y espíritu que eres. Descubre tus vicios y tus virtudes y, con base en ellos, sé dueño de tu destino, pon tus verdaderos talentos a trabajar. No te hagas trampas en el solitario. No te autoengañes. No tropieces 50 veces con la misma piedra. Reflexiona, párate y actúa. No te dejes llevar por las olas. Elige un camino y dirígete a él.

Tercero. Interrelaciónate. Al conocimiento de uno mismo no sólo se llega a través de un proceso de interiorización sino mediante el contraste que te proporciona la inserción en la sociedad en la que te ha tocado vivir. Analiza tus reacciones, vigila tus contestaciones. Sorpréndete de ti mismo y purifica lo que no te gusta. Compara tus expectativas con la realidad que te rodea, chequea tus límites y nunca te conformes. Recuerda, estás en camino, te has fijado una meta. Y el entorno, cualquier entorno, mejor o peor, no es el final de la ruta sino únicamente un medio para llegar a ella. No te dejes vencer por él. Todo lo que te rodea es útil para alcanzar el fin que te has propuesto.

Cuarto. Cualquier intento de alcanzar el éxito, así entendido, pasa por la conjunción de tres elementos mutuamente interconectados. En primer lugar, educa tu voluntad, invierte en ella. Renuncia a lo inmediato por obtener una mayor satisfacción en el futuro. De eso saben mucho ustedes. La capacidad de sacrificio es la condición necesaria para ponerse en marcha. Pero no es suficiente. Se necesitan otros dos requisitos. Veamos. Segundo, haz un uso adecuado de tu libertad que no supone, contra lo comúnmente aceptado, hacer lo que te viene en gana sino sabiendo dónde vas elegir el camino correcto. No es tener múltiples opciones, sino elegir la alternativa idónea para la meta fijada. Tres y último, sométete al único juez que importa que es el de tu conciencia. Sé coherente con el rumbo que te has trazado. No te dejes llevar por lo que opinen los terceros ni actúes condicionado por las apariencias. Voluntad, libertad y coherencia son los únicos elementos que has de llevar contigo a la hora de emprender este viaje.

Quinto. No tengas miedo al fracaso. Es una parte de tu proceso de aprendizaje. Nadie te ha prometido que la conquista del éxito sea un camino de rosas. Lo importante no es caer sino saber levantarse. Y no hacerlo acomplejado y abatido, sino con la cabeza bien alta. Sólo es indigno el que no lo intenta. Detente en los porqués, causas de lo que ha ocurrido y que hay que evitar en el futuro. Pero, sobre todo, escruta los paraqués, cuál es la utilidad que puedo sacar de este inconveniente que ha surgido. Sólo se puede mirar al pasado, para aprender de él. No cabe la resignación apocada, ni la rebelión sin fundamento frente a lo que pudo ser y no fue. Acepta lo sucedido que ya no puedes cambiar y pon tu mirada en lo que realmente importa: el mañana. No temas empezar de nuevo tantas veces como sea necesario.

Sexto. No limites tu reflexión al fracaso; analiza igualmente las causas de tus triunfos profesionales. Sé justo contigo mismo, discrimina qué parte de responsabilidad que te compete en tus victorias y cuál es el resultado de factores ajenos a ti como la coyuntura o la suerte. Sé humilde. El problema de los listos comienza cuando se creen los más listos, cuando empiezan a actuar como si estuvieran por encima del bien y del mal, de las fuerzas que mueven los mercados o sus ámbitos de actuación. El verdaderamente inteligente es aquél que aprende toda circunstancia, con independencia del carácter bondadoso o destructivo de la misma.

Séptimo. Emplea el sentido común, que se ha convertido en el menos común de los sentidos. Ten espíritu crítico, con independencia de cuál es la procedencia de la información. Cuestiona el origen, disecciona el contenido, actúa en consecuencia. Estamos en una sociedad que deja poco espacio para la reflexión. No renuncies a ella. Haz del análisis racional de las cosas un hábito. Conviértelo en costumbre. Te ayudará a mitigar los errores y conquistar la felicidad y, por ende, el éxito.

Octavo. Pon las cosas en perspectiva. No dejes que las ramas te impidan ver el bosque, ni que lo inmediato te aleje de los grandes fenómenos que se están produciendo a nivel mundial. Te pongo tres ejemplos, fuentes todos ellos de oportunidades para el observador avezado. Uno, internet como nuevo paradigma, un cambio tal que la sociedad no se reconoce en el estado anterior, similar al fuego, la rueda o la máquina de vapor. Aún veo a muchos directores de márketing entregados a los medios tradicionales cuando el futuro pasa por la Red como soporte multicanal. Cada día se abren nuevas vías de acción, como las aplicaciones móviles o las redes sociales, por poner sólo dos ejemplos. Dos, el nuevo capitalismo que supone la entrada en las dinámicas de oferta y demanda de dos gigantes del tamaño de India o China. Pocas veces se ha abierto un mercado potencial de 2.000 millones de personas de golpe. El futuro de muchas compañías pasa necesariamente por estar ahí, por investigar sus posibilidades y actuar en consecuencia. Tres, la definitiva separación entre economía financiera y real debido al excesivo tamaño adoptado por la primera frente a la segunda. De su importancia son buen ejemplo las políticas de rescate que se han adoptado desde el inicio de la crisis, muchas de las cuáles, sobre todo en el mundo anglosajón, se han concentrado en ella. Ahora con la crisis se inicia una etapa de austeridad y de recuperación de valores. Quien sea consciente de esta realidad y sus implicaciones partirá con mucha ventaja frente a sus competidores.

Noveno. Profundiza en el entendimiento, no en el conocimiento. No importa tanto estudiar, cuanto aprender, reconocer la utilidad práctica de aquello a lo que se dedica un esfuerzo intelectual. Cuida que tu curva de aprendizaje tenga pendiente positiva. Cumple con el nunca te acostarás sin saber una cosa más. Así te mantendrás vivo, despierto, alerta, tendrás un aliciente para seguir cada día. Vigila a diario tu productividad. Cuanto mayor sea, menos te pondrán imponer los demás tu rutina. Serás más dueño de tu tiempo y, por tanto, más feliz.

Décimo. No seas cortoplacista. Ya hemos comentado antes que la felicidad es un estado permanente. No olvides que la acción colectiva es la suma del resultado de las acciones individuales o, mejor dicho, el beneficio individual sólo crea valor si contribuye al bien colectivo. Si todos miramos por lo nuestro, el sistema se colapsa. Este mantra tiene dos implicaciones: la primera es vertical. Las acciones a corto tienen unas consecuencias a largo que han de ser tenidas en cuenta. No pueden ser pan para hoy y hambre para mañana. Se ve en la política en casos tan graves como la educación. O en la actuación como bomberos de los bancos centrales alimentando sucesivas burbujas. El futuro se alimenta con la experiencia del pasado pero se construye en el presente. Y si nuestras decisiones no contribuyen a su mejora de la sociedad, su deterioro nos arrastrará a nosotros con él.

Pero también tiene un efecto horizontal y es que nuestras decisiones hoy inciden en el conjunto de la sociedad: es el equilibrio entre maximización del beneficio y bienestar social el que garantiza la supervivencia común. De lo contrario, como hemos comprobado, el caos aparece a la vuelta de la esquina. El empresario de verdad es el que persigue el cambio a mejor del conjunto de la sociedad obteniendo un beneficio para sí mismo porque sólo así su vocación de permanencia en el tiempo se cumple. De lo contrario, la muerte económica o social será igualmente su propia muerte.


Nadie te va a montar un proyecto por un salario

19-02-2010 – Eduardo Manchón
Articulo Original: alzado.org – articulo.

Resumen: Un proyecto web se arranca escribiendo líneas de código, no con ideas, ni estrategia, ni contactos… Un programador que es socio con una participación sustancial en el proyecto es la clave, no nos sirve un asalariado ni un freelance. Este es el punto 0 de arranque de cualquier proyecto web viable. Si no tienes socio programador, no tienes nada.

Tengo una idea, solo me falta alguien que la programe

Estoy entrando en un blog de un participante en un evento de emprendedores cualquiera y leo “tengo una idea para un proyecto web, ahora solo necesito un programador que me monte la web”. La persona que escribe esto no sabe programar, pero está al día de todas las novedades en Internet y tecnología, sigue a muchos otros bloggers, a emprendedores online, twitea, se compra todos los gadgets de Apple, etc. y piensa que ese conocimiento le sirve para crear un proyecto web.

Lamentablemente esto no es así. Los viejecitos que se pasan el día mirando obras en la calle no se conviertien en arquitectos, ni en albañiles, por horas que pasen mirando y comentando la construcción. Igualmente para montar un proyecto web hace falta saber programar o al menos tener un socio, no un asalariado, ni un freelance, que programe y esté totalmente involucrado. Si no hay socio programador simplemente no hay proyecto web.

Este artículo se centra en el proceso de arranque desde 0 de un proyecto web viable con ambiciones de convertirse en un modo de vida para sus fundadores. El artículo no abarca diferentes tipos de proyectos diferentes: webs presenciales, experimentales, ni proyectos webs con apoyados en inversiones, sino a start-ups de garaje con un equipo de fundadores con pocos o nulos recursos económicos y solo el tiempo disponible para invertir en el proyecto.

La cabeza pensante

“Cabezas pensantes” son quienes creen que lo importante de un proyecto web es la estrategia, la visión, los contactos, o su capacidad especular sobre el futuro de Google o Apple, etc. En definitiva, personas se dedican a tareas que a efectos prácticos no contribuyen a la creación de un proyecto.

Una “cabeza pensante” es la típica persona que antes de tener ni una triste beta, ya cuenta todo su nuevo proyecto en el blog y su emoción en directo en twitter. Oigan, una cosa es marketing de guerrilla para generar expectacion y otra cosa es escribir una carta a los reyes magos en público.

La cabeza pensante está al día de todo y lo bloguea o lo retuitea, sin embargo estar al tanto de la últimas novedades y bloguear tiene un gran inconveniente, no deja tiempo para otra cosa, el día tiene 24 horas y o escribes, o haces cosas. A mi también me gusta marujear, pero reconozco que tiene el mismo valor práctico especular sobre el futuro del iPad sin haber tenido uno en las manos, como hablar del nuevo peinado de la vecina del quinto, o sea, cero. Lo reconozco, a mi también me gusta divagar, aunque intento limitarlo al máximo a la barra de un bar con amigos.

El cabeza pensante piensa que su idea es tan genial y el trabajo del programador tan irrelevante que ni siquiera hace falta que el programador tenga porcentaje de la empresa, un salario basta, o mejor aún, ese proyecto web podría ser implementado por un freelance externo y baratico si puede ser.

Una cabeza pensante justifica su trabajo dando vueltas y más vueltas a las cosas y generando PPTs de manera infinita. Sin embargo este trabajo es inútil, no produce nada y es contraproducente, en Internet las ideas se desarrollan en vivo y online, no sobre una ppt ni en la cabeza de nadie. Las cabezas pensantes en la mayoría de los casos se creen honestamente lo que dicen, simplemente no tienen ni idea de como funcionan las cosas en el mundo de la start-ups de Internet porque nunca han hecho un proyecto.

La idea es sencilla: Un proyecto web se arranca escribiendo líneas de código.

Nadie emprende por un salario

Si un proyecto se arranca escribiendo líneas de código el papel del programador capaz de hacerlo es crítico. Progamar no es como hacer chorizos ni poner ladrillos, programar es un trabajo puramente intelectual, quizás la tarea más intensiva intelectualmente que conozco. A más horas, no hay más producción, a veces un programador puede ser más productivo en una mañana que en 2 semanas y lo más fascinante, esto no es un problema a resolver, sino algo inherente a la tarea de programar y hay que aceptarlo. Si no te gusta te puedes dedicar al cultivo del champiñón o cualquier otro negocio donde el resultado sea más predecible.

Cada programador tiene unos ritmos personales de productividad e improductividad. Por tanto no se pueden poner horarios ni ser estrictos en las fechas de finalización, sino de crear un ambiente que favorezca la productividad de tareas intelectuales, algo que intenta hacer Google en sus oficinas. La imposibilidad de poner fechas también explica por qué Google nunca anuncia nada con antelación, poner una fecha es desconocer como se trabaja en el mundo de la programación. Si quieres que los programadores se involucren en tu proyecto hay que respetar su manera de funcionar y no hablarles como si la programación fuese como la tarea de construir una pared a un ratio de X ladrillos por hora.

Un programador trabajando solo o con un pequeño equipo en una start-up le toca quedarse hasta las tantas de la madrugada muchos días porque cuando estás a mitad de solucionar un problema no funciona lo de “son las 19:00, hora de irme, mañana más”. Cuando estás a mitad de concentración, motivado para acabarlo, dejarlo para mañana puede significar realmente mañana, un par de semanas o un mes. ¿Un programador ineficiente? No, es simplemente así, volver a concentrarse en esa tarea y acordarse de cada detalle conlleva una pre-tarea de varias horas y si hay otras tareas más urgentes que se cruzan, se postergará.

Nunca he programado, pero siempre he prestado mucha atención a cómo trabajan los progamadores por una razón muy simple, no se programar y siempre necesito un programador como socio. Tratar a un programador como un currito que hace sus horas y se va, es ignorar como funcionan las tareas intelectuales, la motivación humana, etc. Quizás se puedan tener curritos en proyectos consolidados, pero en proyectos web que arrancan, absolutamente no es posible.

Proponer a alguien programar un proyecto web viable solo a cambio de un salario o prespuesto cerrado (freelance) casi roza el insulto. Emprender conlleva un esfuerzo extra buscando un premio, por definición es incompatible pagar un salario fijo y pedir un esfuerzo extra.

Arrancar un proyecto web es escribir código

Hasta que se lanza la primera versión beta de un proyecto se requiere de un 90% de horas de programación y un 10% del resto (UI, estrategia, ideas, etc.). Eso quiere decir que el socio programador va a hacer la mayor parte del trabajo sin ni siquiera saber si el proyecto va a funcionar. Además el programador tampoco sabe a priori la implicación del no-técnico que inicialmente solo pone buenas palabras y pocas horas porque por definición inicialmente no hay mucho trabajo no-técnico que hacer. Todo es riesgo, incógnitas y mucho, mucho trabajo para el técnico.

Si la mayor inversión y riesgo es asumido por parte del programador, éste debe tener su recompensa. Hay muchas casuísticas, pero por ejemplo, en un proyecto de 2 personas, el programador debe tener algo que ronde el 70-30%, especialmente si inicialmente no hay salarios ni inversiones detrás. En el caso que haya inversión y se le pague un salario el porcentaje del técnico podrá ser menor, porque se arriesga menos, pero en cualquier caso debe ser lo suficiente para que si el proyecto vaya bien reciba un beneficio decente.

Una situación que yo he visto mucho es que el cabeza pensante ofrece al programador un porcentaje rídiculo y/o un salario muy bajo. Luego típicamente el cabeza pensante se lamenta de no encontrar un socio tecnológico o de que le abandonen, es evidente, un programador que tenga iniciativa propia, por mucho que sepa que necesita un socio complementario, es normal que prefiera trabajar solo y tener el 100%, que trabajar varios meses gratis arriesgándolo todo por una participación mínima y sin saber la fiabilidad de su socio no-técnico.

Hay casos que parecen funcionar bien y el “cabeza pensante” apartentemente consigue convencer al programador, lo que terminará en una de estas dos situaciones:

a) El programador es malo y piensa que es él quien se va a beneficiar del “cabeza pensante” que supuestamente tiene unos contactos de la leche y lo solucionará todo en dos patadas, así que uno por otro, nadie trabajará.

b) Un programador inteligente. Si es socio tecnológico se dará cuenta que el está echando el 90% de horas y el otro no pringa nada. Si es asalariado o freelance en cuanto se le pase la emoción inicial echará las horas convenidas, le hagan al proyecto falta más horas o no.

Cuando un técnico confía en un no-técnico

Descartada la opción de tener un freelance o un asalariado por insultante, solo queda la opción de un socio tecnológico con un porcentaje respetable, sin embargo esto no basta. Igualmente el programador es quien tiene que poner el 90% de las horas de trabajo iniciales y asumir todo el riesgo. ¿Cómo conseguir la confianza del técnico?

Es sencillo, el programador debe ver al no-técnico ejecutando y solucionando problemas concretos, en definitiva, manchándose las manos y teniendo una predisposición infinita a hacer tareas desagradables. Dada la enorme desproporción inicial en el trabajo ejecutado por uno y por otro, lo único que compensa al técnico es que otra persona le solucione las cosas que no le gustan o no sabe hacer. En ese contexto lo peor que un no técnico puede hacer es ponerse en plan “cabeza pensante”, interrumpiendo al programador, sugiriendo todo el rato modificaciones que resultan en más trabajo y dedicarse a generar una PPT tras otra. Por buenas ideas que contenga una PPT no pone un proyecto online . Tras haber definido los prototipos y funcionalidades básicas, de mejor o peor manera, cualquier cosa que interfiera en la ejecución es una molestia, un “cabeza pensante” que interrumpe es un peso muerto.

Que el no-técnico se manche las manos es lo único que puede hacer al programador confiar y arriesgarse. Mancharse las manos es por ejemplo hacer tareas técnicas, pesadas, pero sencillas, por ejemplo, que te pasen una base de datos mundial donde la lista de ciudades más importantes del mundo no está correctamente priorizada (ej. Madrid, Texas, sale antes que Madrid, Spain) y hay que primero encontrar un listado con las 1.000 ciudades más importantes del mundo (o generarlo a manija) y luego modificar la base de datos registro a registro. Mancharse las manos es dar la bienvenida personalizada a cada uno de los primeros usuarios con algo más que un “hola”. Mancharse las manos es subir un montón de contenidos realmente útiles al sitio web para hacerlo mínimamente funcional. Mancharse las manos es encontrar a los bloggers más relevantes de una temática relacionada y escribirles e-mails totalmente personalizados explicándoles tu proyecto. Mancharse las manos es no decirle al técnico “añade X cosa” sino decirle “Aquí tienes la lista X que tienes que añadir en la página X totalmente detallada” para que el programador no tenga que perder su valioso tiempo buscando la información.

Otra recomendación para el no-técnico es intentar entender como funciona la programación, es fácil, a los técnicos les encanta explicar porque algo es complejo, es cuestión de escucharles. Una tarea como enviar notificaciones via e-mail que parece sencilla, dependiendo del caso, puede tener una casuística muy compleja. Un técnico te respeta si tu muestras respeto a interés por su trabajo y viceversa.

En conclusión: El programador es el artista, “la prima donna” en el mundo de los proyectos web. La tarea de ser socio de un técnico significa ocuparte de todo lo demás, comerte cualquier marrón y hacerle la vida lo más sencilla posible.

Un buen equipo

Idealmente en un equipo los perfiles de sus miembros deben complementarse. Hay muchos flancos que cubrir y queremos gente que haga de todo. Al menos hacen falta dos personas, un perfil técnico y el otro perfil que hace “todo lo demás”.

Típicamente a quien le gusta programar no le gustan ciertas tareas, las que el socio no técnico tiene soluciona: desde gestión de comunidad (blog, foro, mails…) al soporte, la UI, encontrar un buen tagline, estrategia, producto, marketing de guerrilla, hasta comprar los dominios o simplemente cualquier gestión administrativa, repetitiva o burocrática. Es lo que Joel Spolsky llama el “Development Abstraction Layer”, algo que en algunos casos los programadores ignoran fatídicamente y que es un ingrediente clave para que un proyecto funcione.

No pasa nada que los perfiles se superpongan un poco, hay veces que los dos fundadores son técnicos, pero a uno le gusta programar y al otro no y le gusta el resto del trabajo no técnico. Hay veces incluso que los dos son técnicos, pero lo hacen tan bien que el resto de tareas se van haciendo entre los dos. No hay reglas respecto a equipos, hay que escoger bien, pero a fin de cuentas solo puedes escoger entre la gente que conoces.

Excepciones

Lo unico que se puede subcontratar de un proyecto viable y no del todo es el front CSS, html, etc. el logo, etc. Son cosas para las que inicialmente no hay trabajo todos los días, por tanto añadir a alguien asi al proyecto solo podría dársele un porcentaje muy pequeños. Por cierto, que en ocasiones un diseñador de front que también haga “todo lo demás” es un buen socio a un programador. Por supuesto subcontratar se puede hacer en proyectos tipo webs presenciales, Alzado.org, etc. pero eso no son proyectos grandes con proyección, son proyectos personales, experimentos, hobbies, etc.

¿Y hay gente con éxito subcontratando? Claro, típicamente proyectos con inversores detrás y donde lo crítico no es solo la web sino tener los contactos para conseguir acuerdos comerciales para conseguir clientes, proveedores con precios bajos en e-commerce, etc. es decir, proyectos donde la web es una herramienta más de una estrategia y donde el componenete offline es realmente el crítico.


Mi primer empleo

N.D. – César Martín
Resumen: El primer paso para cualquier licenciado es pasar por un periodo de prácticas en una empresa. Para que este periodo se pueda convertir en una relación más duradera, te recomendamos algunas ideas. Especialmente indicado para diseñadores web.

Articulo Original: Mi primer empleo

Paso 1. Has terminado o estas terminando la carrera. Tienes que buscar una empresa a la que ir a trabajar.

Has terminado Bellas Artes, algún master en diseño, diseño industrial o algo similar… Y ahora ¿qué?.
Seguramente una vez terminada la carrera te encuentras un poco sin saber hacia dónde ir, qué hacer, por dónde empezar.

Busca empresas que te gusten para ir a trabajar.
Si tus profesores no te recomiendan ninguna empresa a la que poder ir, lo mejor es que te busques una que te guste. Ya sea por sus trabajos, por lo que dice, por lo que hayas leido de ellos. Busca por todas partes. Desde la Universidad el mundo laboral puede verse lejano, pero busca en sitios de noticias que te gusten, referencias sobre empresas que parezcan interesantes. Lee blogs, mira foros, envía preguntas sobre empresas recomendables…

Mi experiencia. Un día leyendo una revista vi un artículo sobre Teknoland. Me gusto la foto que venía de su web y me metí a ver que hacían. Me encanto todo lo que vi y les mandé un mail. Ellos me hicieron una entrevista y a partir de ahí surgió la relación. Nadie me podría decir que esa empresa, que aparecía en una revista, sería una de las más grandes en internet en España pasados 3 años (y que luego cerró pasados otros 2 años).

Conclusión: No se puede predecir el futuro. Selecciona la empresa a la que te gustaría ir con tu instinto.

Paso 2. Antes de ir a hacer tu primera entrevista. Prepara tu curriculum.

Es importante no ir a hacer una entrevista sólo con el curriculum académico. Demuestra que tienes ganas e ideas para trabajar.

Dedícale un verano o una navidad a hacer tus experimentos web
Crea una revista con amigos, haz una web para la empresa de tu padre o para un amigo.
Es importante que puedas demostrar que sabes hacer una web (aunque sea rudimentaría). Que entiendes los pasos necesarios, el proceso, el código, la importancia del diseño.

Con estos experimentos pon en valor tu potencial. Si te gusta escribir, escribe en la web. Si te gustan los deportes, haz un blog sobre deportes. Si lo que te gusta es organizar una comunidad (si eres la típica persona a la que le gusta organizar fiestas, reuniones, este es el perfil) crea una comunidad para tus amigos, para la gente del barrio, para gente que le gusta una determinada actividad. Si lo que te gusta es el código y la programación, crea algún tipo de gestor para que la gente pueda publicar sus ideas, fotos, imágenes…

Puede ser que alguno de estos proyectos se convierta en algo más que un test de laboratorio. Haz algo donde tu pasión se vea reflejada.

No lo intentes todo a la vez. Poco a poco. Crea pequeñas cosas pero completas (mejor que cosas grandes que se quedan a medias).

De esta forma, tu curriculum se verá respaldado, de alguna forma, por trabajos que demostrarán como has puesto en práctica tus ideas.

No te preocupes por que estos ejemplos no sean profesionales. Eso es algo que aprenderás trabajando, pero si es importante que ellos vean que entiendes el proceso. El proceso básico suele ser: Tienes un objetivo, encuentras una idea, la materializas.
Más sobre el proceso creativo.

Como hacer tu curriculum

No se si alguien se lee los curriculums, pero por si acaso, hay que hacerlos.

Modelo convencional

  1. Empieza por quien eres. Nombre, edad, lugar de nacimiento.
  2. Tu expediente académico. Haz que brille. Todo lo que sea destacable, ponlo. Cursos, actividades, talleres, masters, etc…
  3. Idiomas. Esto es fundamental. Debes dominar el inglés.
  4. Herramientas que conoces. Nivel de dominio. (Más sobre esto en breve).
  5. Habla de las cosas que te gustan con pasión. No digas que te gusta leer, ir al cine y el deporte. Di que te gusta nadar, novelas históricas (la mejor que has leido es XXXXX) y la música del grupo llamado XXXXX entre otros.

El contenido es importante, pero es más importante el aspecto.

  1. Usa arial o georgia.
  2. Dale personalidad forzando algún aspecto de la maquetación. Haz que los márgenes sean grandes o raros o las dos cosas.
  3. No pongas tu foto. Si pones una foto que sea de un trabajo tuyo.

Modelo no-convencional
Cuenta tu historía de forma interesante (como si fuera un relato). Cuenta aquello qué te hace especial. Envía tu curriculum dentro de una caja de regalos. Envía tu curriculum en formato telegrama. Envía tu curriculum dentro de un libro… Haz algo diferente que te haga sobresalir del resto.

Paso 3. Primeros meses. Ganar la confianza.

Suponiendo que has pasado la entrevista y que estás trabajando en la empresa, el siguiente paso es ganarte la confianza de tus jefes, compañeros de trabajo, clientes.

En tu primer empleo por lo general no se espera de ti que seas capaz de resolver proyectos en su totalidad, pero si que demuestres capacidades básicas como honestidad, integridad, respeto, fidelidad, etc…

Si cumples con estas cualidades básicas, la empresa, compañeros (por lo general) se encargarán de darte la formación necesaria para que puedas desarrollar proyectos completos.

Aun así, hay tareas básicas que debería dominar para ser útil desde el día 1.

1. Comprar y poner en marcha un dominio. Esto es sencillo, pero es clave que mires y compares proveedores de servicio. Mira que ofrecen, cuanto cuesta, etc… En los comentarios a este artículo se comparaban y recomendaban proveedores de hosting.

2. Subir ficheros, editar y borrar desde un FTP. Es sorprendente hoy en día la cantidad de empresas que desconocen como manejar un FTP. Aprende a hacerlo pero sobre todo aprende a explicarlo. Hay muchos proveedores de servicio que incluyen servicio de FTP a través del navegador lo cual simplifica mucho las cosas de cara a usuarios. Aprende como crear carpetas para usuarios dentro de un FTP, protegerlas, etc.

3. Crear páginas web. Crear páginas web pasa por dominar un gestor de contenidos que te permita publicar y por saber controlar el aspecto visual del mismo. Los gestores de contenidos los puedes programar o encargar a un programador o los puede instalar a partir de una solución existente. WordPress es un gran gestor de contenidos que te permitirá experimentar. Podrás manipular gran cantidad de parámetros del mismo.

4. Convertir ficheros. Organizar ficheros. Trabajar con ficheros. La típica taréa de abrir una foto, limpiarla un poco y guardarla en diferentes formatos es un paso básico que debes dominar. Saber hacer vistas en miniatura, bajar el peso para que pasen por un mail, crear galerias de fotos para poder revisar y seleccionar, organizar ficheros en función de criterios… Todo lo que es gestión y organización.

Cuando eres un recien graduado la mejor forma de entrar en una empresa es haciendo tareas pequeñas, sencillas pero que sirvan para que la gente confie en ti. Si confian en ti para esas pequeñas tareas te iran dando tareas más importantes y más acordes con tu formación, pero uno de los pasos necesarios en la empresa es aprender a trabajar.

Todas estas tareas tienen un objetivo claro. En los estudios de diseño, un 30% del tiempo se dedica a diseñar, pero un 70% a producir, gestionar ese diseño. La gestión consume mucho tiempo y recursos y en muchos casos las tareas antes comentadas ayudan a gestionar a estos clientes. No creas que pierdes el tiempo. Serán de mucha utilidad.

Tu primer empleo, ¿será el último?

En la situación actual lo más probable es que no lo sea.
Procura aprender, se honetos, habla con claridad y de forma abierta. Expón tus ideas sin miedo a equivocarte y compártelas con tus compañeros. Si algo lo ves mal, explica como hacerlo bien. Si algo es caro, di como se puede hacer barato. Si algo pesa mucho, di como rebajar el peso. Si algo no se entiende, di como hacerlo más claro. No tengas miedo de hablar. Lo único, hazlo primero delante de los compañeros con los que tengas confianza, ellos te ayudarán a corregir lo que esté equivocado y a potencia lo que sea correcto.


Social Media: Como se si funciona?

Articulo de: Gaby Castellanos
Referencia: Articulo Original

Muchas veces me preguntan como se sabe que una estrategia en Social Media funciona, y aunque parezca obvia, es una buena pregunta.

A veces uno cree que con poner un par de tweets, status en FB, algun post en el Blog y alguna cosilla mas, significa que la cosa va bien. Y no es cierto. Social Media no es escribir de vez en cuando cosas sobre tecnologia y redes sociales. No es utilizar los terminos “sociables” para contar 4 cosas. Tampoco es ofrecerle a una marca : pon tu pagina en Facebook, create un Twitter y te desarrollamos un Blog. No, hay que hacer otras cosas.

Pero si hay algunas cosas que te hacen saber si la cosa va bien o mal. Hay indicios, hay datos, hay movimientos que te dicen que los estas haciendo bien.

Os voy a dar unos ejemplos basado en la realidad, mi realidad personal y la de SrBurns:

a.- Cada vez que pones un status en FB, genera conversaciones. Si genera conversaciones es que estas en contacto con la gente. Por que de que sirve hablar solo? Para hacer monologos ya esta Paramount Comedy. Si no hay accion y reaccion, la cosa va mal.

b.- Se han incrementado tus referencias en los buscadores. Ya no sale solo tu pagina web, sino tambien tu Facebook, tu twitter, tus tweets, tu linkedin, tu Xing. Lo has revisado? Tienes mas? No? Tus keywords?  Y aun estando en todas las redes sociales no tienes mas referencias en Google? Oh oh, algo no estas haciendo bien.

c.- Te congratulan y te critican. Eso es muy bueno. Si te critican es que algo has logrado en ellos. Si nadie te critica y mucho menos te lo hace saber, es que no has logrado la notoriedad debida. O es que has borrado las criticas? Muy mal.  Habra que revisar si has logrado reputacion, sino habra que currarsela.

d.- Se ha duplicado tu trafico al menos. No ha pasado asi? Entonces, es que no has sabido cruzar el trafico de un entorno a otro. En la mayoria de los casos aumenta notablemente el trafico gracias a Facebook y Twitter. Algo no esta saliendo bien.

e.- Tienes mas clientes. La exposicion ayuda a la captacion. Si estando en todos lados no has conseguido mas clientes, es que no has mostrado correctamente tus beneficios. Habra que revisar la estrategia.

f.- Tus followers crecen dia a dia. Aunque no es la mayor desmostracion de efectividad. Lo que importa aqui es con cuantos te relacionas y cuantos se relaciona contigo. Algun RT? Ninguno? Habra que generar contenido interesante para conseguirlo.

Bueno podria pasar horas contando como podeis saber si la cosa va bien. Aunque creo que esto ya lo conoceis, no es malo dejarlo escrito, por las dudas.


Principios Basicos (Guia de Estilos y Fundamentos Web)

Guia de estilos y fundamentos web v0.2

Por Kilian Barrera

Referencia: Frontend

Lo siguiente son unos consejos proveniente del material del disenador web Kilian Barrera.

Separa el contenido del diseno:

  • No marques con <table>, usa <div>.
  • CSS es tu vida, dominalo.
  • El espacio vacio es tu aliado, deja respirar cada elemento.
  • Usa una paleta de color reducida.
  • Crea una guia de Estilo, te dara consistencia, mejorala.

Navega en tu contenido:

  • Estructura tu contenido.
  • Navegalo mentalmente.
  • Crea mockups.
  • Crea casos de uso.
  • Crea arboles cortos de navegacion. Maximo 4 niveles, mejor 1.
  • Cuida tu lenguaje. Usa “tu perfil” no “Mi perfil”.

Piensa en SEO:

  • Cada pagina tiene un <title> y <description> unico.
  • Usa los H1, H2, H3,… para encabezar tu contenido.
  • Usa <ul> para menus y elementos repetidos (noticias, productos, etc).
  • Rutas URL con /nombre-largo-separado-con-guien.
  • Los buscadores son tus aliados. Posicionate naturalmente.
  • Usa Javascript no introsuvo.

No hagas pensar:

  • Crea menus legibles.
  • Crea contraste para los links.
  • Ten formularios equilibrados, ordenado y consistente.
  • Destaca los cambios. Sobretodo si usas AJAX.

Usa un Framework CSS. 960.gs, Blueprint:

  • Manten todo el CSS en un archivo aparte.
  • Usa un “reset” CSS.
  • Para los emails necesitas el CSS enbebido en las etiquetas.
  • Usa HAML+SAAS si puedes.
  • Proporcionalidad. Coherencia en los espacios y margenes.
  • Busca el equilibrio. Ni todo junto, ni todo separado.

Formularios (no hagas pensar):

  • Validacion en el cliente con JS pero siempre validar en el servidor.
  • Crea mensajes de error comprensibles, cortos y aporta la solucion.
  • Marca claramente la informacion requerida.
  • Informar siempre al usuario cuando fue completado correctamente.
  • Es mejor prevenir el error.  Usa ayuda contextual al tipo de campo.
  • Si usas una Captcha, tiene que soportar audio y un “recargar”.

Formulario (estudio de uso):

  • Link de registro en la esquina superior derecha (40%).
  • Formulario de registro tiene que ser simple y sin distracciones (61%).
  • 1 sola pagina de registro (93%).
  • Atraer al visitante con los beneficios por registrarse (41%).
  • Los <label>, <title> de los <input> en negrita (62%).
  • La alineacion del label a la derecha o sobre el input.
  • Usar como ayuda visual y contextual el “Placeholder text”.
  • Alinear los campos verticalmente (86%) e igualar los “width”.
  • No usar hover, active o focus effect (84%).
  • Usar ayuda contextual estatica (57%) o dinamica (33%) y que aparesca debajo o a la derecha del campo.
  • Puedes usar validacion estatica o dinamica.
  • No usar un email de confirmacion (82%).
  • Usar password de confirmacion (72%).
  • Captcha o no captcha. (48% vs 52%).
  • No usar boton de Cancelar (92%).
  • Boton de Submit alineado a la izquierda (56%) o centrado (26%).
  • Mensaje de agradecimiento ayuda a explorar el servicio (45%).

Protégete de los bots agresivos

Referencia original del Articulo: gallir.wordpress.com
Autor: Ricardo Galli

En los últimos días varias personas con servidores propios –fundamentalmente de wordpress– me pidieron ayuda para reducir la carga de sus servidor o mejorar los tiempos de respuesta. Una de las últimas frecuentes era “porqué a veces la carga del servidor subía mucho”. Asumiendo que el servidor está bien configurado y balanceado [1], el problema suele ser por los “bots demasiado agresivos”.

[1] Ver abajo Diez reglas básicas para servidores web bien ajustados

El aumento del ancho de banda en las conexiones hogareñas, las pruebas “académicas” y de prácticas desde universidades –en España sus líneas suelen superar creces los 100 Mbps– y los bots de los harvesters de spammers hace que debamos también monitorizarlos e impedir que su molestia sea persistente.

Aunque hay métodos en las iptables y Apache para controlar el número de conexiones –connection throttling– a veces es muy difícil encontrar un valor adecuado sin que genere problemas a conexiones válidas. Incluso puede haber problemas de memoria –de las iptables, que las asigna en el espacio del kernel– en servidores que no tienen suficiente.

Por ello a veces es más fácil analizar los logs de Apache en situaciones de alta carga para detectar desde qué direcciones IP se están haciendo tantas conexiones y agregar una regla a las iptables para hacer in drop a paquetes desde esa dirección.

En Menéame es bastante habitual que nos aparezca un bot de estos y que sus conexiones duren bastante tiempo mientras recorre absolutamente todos los posibles URLs. Como estos son centenares de miles, la “agresión” suele durar horas o días, así que me preparé un pequeño script en Python que me permite analizar el número de conexiones desde cada IP.

#! /usr/bin/python

import fileinput
import re

to_ignore = ['/img/', '/js/', '/css/'] # Los cgi o directorios a ignorar
ips = {}; res = []

try:
    for s in to_ignore:
        res.append(re.compile(re.escape(s)))
    for line in fileinput.input():
        words = line.split()
        for r in res:
            if r.search(words[6]): break
        else:
            try: ips[words[0]] += 1
            except KeyError: ips[words[0]] = 1
    tuples = ips.items()
    tuples.sort(lambda (k1,v1),(k2,v2):cmp(v2,v1))
    for ip, counter in tuples:
        print '%-8d\t%s' % (counter, ip)
except IOError:
    pass

El programa anterior analiza el logs del apache desde la entrada estándar o los ficheros que se indiquen en la línea de comandos e imprime una tabla de números de conexiones de cada IP.

Yo lo suelo usar de la siguiente forma:

tail -1000000 /var/log/apache2/meneame_net.access.log | ./freq-ip.py | less

aunque también se puede hacer:

./freq-ip.py fichero1.log fichero2.log …

Nota: aunque el ejemplo es con las últimas 1.000.000 de líneas, elige un valor adecuado a tu servidor, por ejemplo si te interesa analizar los últimos 5 minutos y tienes unas 100.000 conexiones en ese período, ese es el valor que debes poner como argumento del tail.

El resultado es una tabla ordenada de mayor a menor, por ejemplo:

22759           66.249.72.103
914             62.43.58. xxx
837             84.77.96.xxx
645             89.248.99.xx
522             65.214.44.xx
486             89.17.210.xx
483             72.14.199.xx
...

Las IPs que aparecen primeras son las sospechosas de bot agresivos, pero hay que analizarlas con el whois para asegurarse. En el resultado anterior se puede observar claramente que la dirección 66.249.72.103 es sospechosa, pero en este caso no hay que hacer nada porque es el bot de Google (el de búsquedas y el del AdSense). Pero si se trata de una IP que no pertenece a ningún buscador o directorio conocido, o que viene de países como China o Ucrania, seguramente se trate de un bot incontrolado o mal programado.

En todo caso siempre conviene analizar el historial de los logs para asegurarse:

tail -1000000 /var/log/apache2/access.log | grep ^66.249.72.103 | less

Una vez que estés seguro que quieres evitarle los accesos, basta agregarlo en las iptables. Yo tengo preparado un script que lee las IP “prohibidas” desde un fichero y ejecuta los comandos de las iptables:

#! /bin/sh

iptables -F

# START Drops from ip_forbiden
for ip in `cat /DIRECTORIO/ip_forbiden` ## AQUI el pathname del fichero
do
    if [[ "$ip" =~ "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" ]]
    then
        echo Dropping $ip
        iptables -i ethX -A INPUT -s $ip  -j DROP ### AQUI la interfaz que corresponda, eth0 o eth1, etc.
    fi;
done
# tus reglas propias
...

Diez reglas básicas para servidores web bien ajustados

Al principio mencioné que primero debemos asegurarnos que el servidor web está bien configurado y ajustado para nuestras necesidades. En realidad no es tan difícil ajustar los parámetros básicos del Apache.

  1. Asegúrate verificando en el error.log si el Apache no llega al número máximos de procesos. Si es así debes incrementar el máximo, por ejemplo: MaxClients 150
  2. Algunas distribuciones, como Debian, tiene el máximo “absoluto” en 256 procesos, si necesitas más debes cambiarlo: ServerLimit 512
  3. Habilita el KeepAlive, pero ponle un timeout bajo: KeepAliveTimeout 2
  4. StartServers debe tener un valor adecuado, que sea ≥ que MinSpareServers y ≤ que MaxSpareServers. Por ejemplo : StartServers 40, MinSpareServers 30, MaxSpareServers 50
  5. MaxSpareServers debe ser mayor en al menos un 50% el valor de MinSpareServers.
  6. El PHP puede consumir mucha memoria en algunas conexiones (subida de ficheros, compilación de muchos módulos, etc.) y no las libera hasta que “muera” el proceso. Por eso es mejor que los procesos de Apache tengan una “vida limitada” para permitir liberar esa memoria que no se necesita: MaxRequestsPerChild 10000. Ajusta el valord de 10.000 a tus propias necesidades, si tu servidor tiene muchas conexiones puedes subirlo, por ejemplo a 1.000.000 como en el caso del Menéame.
  7. Para saber mejor cuál es el problema de tu servidor usa los comando top y vmstat 2. El primero te dará el uso de CPU de los procesos, si es el mysqld el que aparece con casi el 100% de CPU, el problema es de base de datos, por el contrario se trata del PHP. El vmstat te dará más pistas, si los valores de la columna wait (la última, wa) son altos, es porque necesita mucha entrada salida, necesitas más memoria RAM. Si por el contrario las valores de la columna idle (la penúltima, id) son muy bajos necesitas más CPU.
  8. El WordPress no es un gran consumidor de CPU en base de datos (a menos que ésta sea inmensa), sino de CPU para compilar todos los módulos para cada conexión. Si tu problema es de carga alta de CPU lo más probable es que necesites usar “cache” de PHP compilados, por ejemplo el eaccelerator.
    • Si tienes instalado el WP-Cache, éste evita que se tengan que compilar todos los módulos en el caso de encontrarse la página en cache.
  9. Si el el Mysql del WordPress te consume mucha CPU lo más probable es que sea algún plugin (especialmente esos que guardan estadísticas en la base de datos) o que tengas muy poca memoria RAM disponible para cache de disco. Pero primero analiza o deshabilita los plugins sospechosos.
  10. Si has desarrollado tu propio programa y el Mysql te consume mucho, tienes problemas de SQLs, índices o problemas de estructura de la base de datos. recuerda la regla de oro en programas web con base de datos (general para cualquier gestor): debes evitar a toda costa los recorridos secuenciales en las tablas. Para eso debes ser muy cuidadoso en la creación de los índices adecuados o de cómo haces las consultas SQL. Si no puedes asegurarte de ello tienes dos opciones primordiales para el caso que las modificaciones a las tablas no sean muy frecuentes:
    1. Jugar con los valores de cache de queries sql en el propio gestor (query_cache_size y query_cache_type en el Mysql).
    2. Usar memcached.

No entiendo nada

Si lo que te comento arriba te suena a chino:

  • Quizás no deberías haber contratado un servidor dedicado si eres capaz de administrarlo y ajustarlo, o
  • deberías estudiar un poco de administración de servidores, especialmente del Apache, MySQL e iptables, o
  • podrías pedir ayuda a un amigo, o menor aún para evitar la proliferación de pringaos, contrata a un amigoo conocido de confianza por unos 50-60 euros la hora (tarifa española más o menos adecuada) que sepa del tema y te ajuste el servidor. Si tiene que hacer todo lo que explico aquí, le llevará más o menos una hora para ajustar, y monitorizar para asegurarse que los valores son adecuados.

Cómo informar de fallos de forma efectiva

por Simon Tatham, programador profesional y de software libre

Introducción

Cualquiera que haya escrito software para uso público probablemente haya recibido al menos un mal informe de fallo. Informes que no dicen nada (“¡No funciona!”); informes que no tienen sentido; informes que no dan información suficiente; informes que dan información errónea. Informes de problemas que acaban siendo un error del usuario; informes de problemas que acaban siendo un fallo del programa de un tercero; informes de problemas que acaban siendo fallos en la red.

Existe una razón por la cual el soporte técnico se ve como un empleo horrible, y esa razón son los malos informes de fallo. Sin embargo, no todos los informes de fallo son molestos: yo mantengo software libre, cuando no me estoy ganando la vida, y a veces recibo informes de fallos increíblemente claros, útiles e informativos.

En este ensayo intentaré dejar claro lo que hace bueno a un informe de fallo. Idealmente me gustaría que todo el mundo se leyera este ensayo antes de informar de un fallo a cualquiera. Ciertamente, me gustaría que todos los que vayan a informarme de fallos a se lo leyesen.

En pocas palabras, el objetivo de un informe de fallo es permitir al programador ver el programa fallando ante sus ojos. Puedes mostrárselo en persona, o darle instrucciones cuidadas y detalladas de cómo hacer que falle. Si pueden hacer que falle, podrán intentar recolectar información extra hasta que averigüen la causa. Si no pueden hacer que falle, tendrán que pedirte que tú recolectes esa información en su lugar.

En los informes de fallo, intenta dejar muy claro qué son hechos reales (“Estaba con la computadora y ocurrió esto”) y qué son especulaciones (“Creo que esto puede ser el problema”). Excluye las especulaciones si quieres, pero no excluyas nunca los hechos.

Cuando informas de un fallo, lo haces porque quieres que el fallo se arregle. No tiene sentido blasfemar al programador o ser deliberadamente inútil: puede que sea culpa suya que tú tengas el problema, y puede que tengas razón al estar enfadado con ellos, pero el fallo se arreglará antes si les ayudas proporcionándoles toda la información que necesitan. Recuerda también que si el programa es gratuito, entonces el autor lo proporciona amablemente, de modo que si mucha gente fuera ruda con ellos quizás deban dejar de sentirse amables.

“No funciona.”

Dale al programador algo de crédito en cuanto a inteligencia básica: si el programa no funcionase en absoluto, se hubieran dado cuenta. Si no se han dado cuenta, es que en su caso funciona. Por tanto, o bien estás haciendo algo diferente de lo que ellos hacen, o tu entorno es diferente del suyo. Necesitan información; proporcionar esa información es el objetivo de un informe de fallo. Más información casi siempre es mejor que menos.

Muchos programas, particularmente programas gratuitos, publican una lista de fallos conocidos. Si puedes encontrar una lista de fallos conocidos, merece la pena leerla para ver si el fallo que acabas de encontrar ya es conocido o no. Si lo es, probablemente no merezca la pena informar de él nuevamente, pero si piensas que tienes más información que la que aparece en el informe de fallo, puede que quieras contactar con el programador de todos modos. Puede que sean capaces de arreglar el fallo más fácilmente si les das información que todavía no tenían.

Este ensayo está lleno de consejos. Ninguno de ellos es una regla absoluta. Programadores concretos tienen formas concretas en las que les gusta que se les informe de fallos. Si el programa viene con su propio conjunto de consejos para informar de fallos, léelos. Si los consejos que vienen con el programa contradicen los consejos presentes en este ensayo, ¡sigue los que vienen con el programa!

Si no estás informando de un fallo sino simplemente pidiendo ayuda para utilizar el programa, deberías indicar en qué otros sitios has buscado ya la respuesta a tu pregunta. (“Miré el capítulo 4 y la sección 5.2 de la ayuda pero no encontré nada que me dijera si esto es posible.”) Esto permitirá que el programador sepa dónde espera la gente encontrar la respuesta, de forma que pueden hacer que la documentación sea más fácil de usar.

“Muéstrame.”

Una de las mejores maneras de informar de un fallo es mostrarlo al programador. Sitúalos delante de tu ordenador, lanza su software, y demuestra aquello que funciona mal. Deja que miren cómo arrancas la máquina, que miren cómo ejecutas el software, que miren cómo interactúas con el software y que miren lo que el software realiza como respuesta a tus entradas.

Conocen su software como la palma de su mano. Saben en qué partes confiar, y saben qué partes pueden tener más fallos. Saben intuitivamente lo que tienen que buscar. Cuando el software haya hecho algo obviamente erróneo, puede que hayan reparado en algo anterior sutilmente erróneo que pueda darles una pista. Pueden observar todo lo que el computador hace durante la ejecución de prueba, y pueden decidir lo que es importante por sí mismos.

Quizás esto no sea suficiente. Quizás decidan que necesitan más información, y te pidan que les muestres lo mismo una vez más. Puede que te pidan que les guíes en el proceso, de forma que puedan reproducir el fallo por sí mismos todas las veces que sean necesarias. Puede que intenten variar el proceso algunas veces más, y así conocer si el problema ocurre sólo en un caso o en una familia de casos relacionados. Si no tienes suerte, quizás necesiten sentarse durante un par de horas con un conjunto de herramientas de desarrollo y empezar a investigar de verdad. Pero lo más importante es que el programador esté mirando el computador cuando algo falla. Una vez que puedan ver el problema, normalmente podrán seguir solos a partir de ese punto para intentar arreglarlo.

“Enséñame a mostrar por mí mismo.”

Ésta es la era de Internet. Es la era de las comunicaciones globales. Es la era en la que puedo enviar mi software a alguien de Rusia pulsando un botón, y él puede enviarme sus comentarios de forma igualmente sencilla. Pero si tiene un problema con mi programa, no puede hacer que yo esté presente cuando falla. “Muéstrame” es bueno cuando puedes, pero muchas veces no puedes.

Si tienes que informar de un fallo a un programador que no puede estar presente personalmente, el objetivo del ejercicio es hacer que sean capaces de reproducir el problema. Quieres que el programador ejecute su propia copia del programa, haga lo mismo que tú, y haga que falle de la misma manera. Cuando no pueden ver que el problema ocurre delante de sus ojos, no pueden hacer nada con él.

Así que diles exactamente lo que hiciste. Si es un programa gráfico, diles qué botones pulsaste y en qué orden los pulsaste. Si es un programa que se ejecuta escribiendo una orden, múestrales de forma precisa la orden que usaste. Cuando sea posible, debes proporcionar una transcripción de la sesión, mostrando las órdenes que tecleaste y lo que la computadora mostró como respuesta.

Dale al programador toda la información que se te ocurra. Si el programa lee de un fichero, probablemente necesites enviarles una copia del fichero. Si el programa habla con otro computador a través de una red, probablemente no puedas enviarles una copia de ese computador, pero puedes al menos decir qué clase de computador es y, si es posible, qué software ejecuta.

“A mí me funciona. ¿Qué está mal?”

Si le das a un programador una larga lista de entradas y acciones y ellos lanzan su propia copia del programa y no ocurre nada malo, entonces es que no les has dado información suficiente. Posiblemente el fallo no ocurre en todos los computadores; tu sistema y su sistema puede diferir de algún modo. Quizás hayas malentendido lo que el programa supuestamente hace, y ambos estáis mirando exactamente la misma pantalla y tú piensas que está mal y ellos saben que está bien.

Así que describe también lo que ocurrió. Diles exactamente lo que viste. Diles por qué piensas que lo que viste está mal; aún mejor, diles exactamente lo que tú esperabas ver. Si dices “y entonces falló”, estás dejando fuera información muy importante.

Si viste mensajes de error entonces dile al programador, de forma clara y precisa, cuáles eran. ¡Son importantes! En este momento, el programador no está intentando arreglar el problema: sólo están intentando encontrarlo. Necesitan saber qué ha ido mal, y esos mensajes de error son el mayor esfuerzo del computador para decírtelo. Anota los errores si no tienes otra forma más sencilla de recordarlos, pero no merece la pena informar de que el programa generó un error a menos que puedas indicar cuál era el mensaje de error.

En particular, si el mensaje de error contiene números, asegúrate de informar de ellos al programador. Aunque tú no puedas encontrarles sentido no significa que no lo tengan. Los números contienen toda clase de información que puede ser leída por un programador, y probablemente contengan pistas vitales. Los números en los mensajes de error están ahí porque el computador está demasiado confundido como para informar del fallo con palabras, pero está intentando hacerlo lo mejor posible para darte la información importante.

En este punto, el programador está a efectos prácticos realizando el trabajo de un detective. No saben lo que ha ocurrido, y no pueden estar lo bastante cerca como para verlo por ellos mismos, así que están intentando encontrar pistas que les hagan ver el problema. Los mensajes de error, las incomprensibles cadenas de números, e incluso los retardos inesperados son todos tan importantes como las huellas dactilares en la escena de un crimen. ¡Guárdalos!

Si usas Unix, el programa puede producir un volcado de memoria. Los volcados de memoria son una fuente de pistas particularmente buena, así que no los elimines. Por otra parte, a la mayoría de programadores no les gusta recibir ficheros gigantes por correo electrónico sin una advertencia, así que pregunta antes de enviar un volcado a nadie. También, ten en cuenta que los volcados de memoria contienen un registro del estado completo del programa: cualquier “secreto” presente (quizás el programa estuviera manejando un mensaje personal, o trabajando con datos confidenciales) puede aparecer en el fichero del volcado.

“Y entonces intenté…”

Hay un montón de cosas que puedes hacer cuando aparece un fallo o un error. Muchas de esas cosas empeoran el problema. Una amiga mía en la escuela borró accidentalmente todos sus documentos de Word, y antes de pedir ayuda a un experto intentó reinstalar el Word y luego ejecutar el desfragmentador de disco. Ninguna de esas acciones ayudó a recuperar sus ficheros, y gracias a ambas el disco se dispersó de tal manera que ningún programa de recuperación hubiese podido hacer nada. Si no hubiese tocado nada, puede que hubiera tenido una oportunidad.

Usuarios como éste son como una mangosta atrapada en una esquina: con su espalda contra la pared y viendo la muerte inminente ante sus ojos, ataca salvajemente, porque hacer algo tiene que ser mejor que no hacer nada. Esto no se adapta bien al tipo de problemas que producen los computadores.

En lugar de ser una mangosta, sé un antílope. Cuando un antílope se enfrenta a algo inesperado o terrorífico, se para. Permanece completamente parado e intenta no atraer la atención, mientras se detiene a pensar y calcular qué es lo mejor que puede hacer. (Si los antílopes tuvieran una línea de atención técnica, probablemente llamarían a ella en ese momento.) Entonces, una vez que ha decidido qué es lo más seguro que puede hacer, lo hace.

Cuando algo va mal, inmediatamente deja de hacer nada. No toques ningún botón en absoluto. Mira la pantalla e intenta encontrar cosas fuera de lo normal, y recuérdalo o anótalo. Entonces quizás empieza cautelosamente a pulsar “Aceptar” o “Cancelar”, lo que te parezca más seguro. Intenta desarrollar un reflejo – si el computador hace algo inesperado, detente.

Si logras salir del problema, bien cerrando el programa afectado o bien reiniciando la computadora, sería bueno intentar hacer que el problema ocurra de nuevo. A los programadores les gustan los problemas que pueden reproducir más de una vez. Los programadores felices arreglan los fallos antes y de forma más eficiente.

“Creo que el modulador de taquiones tiene la polarización incorrecta.”

No sólo son los no-programadores los que producen malos informes de fallos. Algunos de los peores informes de fallos que he visto vienen de programadores, e incluso de buenos programadores.

Una vez trabajé con otro programador que no paraba de encontrar fallos en su código e intentaba arreglarlos. De vez en cuando encontraba un fallo que no era capaz de arreglar, y me llamaba para que le ayudase. “¿Qué ha pasado?”, le preguntaba. Él me respondía diciéndome su opinión sobre lo que necesitaba repararse.

Esto funcionaba bien cuando su opinión era correcta. Significaba que ya había hecho la mitad del trabajo y así podíamos terminarlo los dos juntos. Era eficiente y útil.

Sin embargo, muchas veces se equivocaba. Trabajábamos un tiempo intentando averiguar por qué una cierta parte del programa producía datos incorrectos, y eventualmente descubríamos que no los producía, y que habíamos estado media hora investigando un trozo de código que funcionaba perfectamente, y que el problema estaba en otra parte.

Estoy seguro de que tú no harías eso con un doctor. “Doctor, necesito que me prescriba hidroyoyodina.” La gente sabe que no debe hacer eso con un doctor: le describes los síntomas, las molestias y achaques y dolores y erupciones y fiebres, y dejas que el doctor haga el diagnóstico del problema y decida qué hacer al respecto. En otro caso el doctor te tomará por hipocondriaco y lunático, y con razón.

Ocurre lo mismo con los programadores. Proporcionar tu propio diagnóstico puede que a veces sea útil, pero siempre establece los síntomas. El diagnóstico es un extra opcional, y no una alternativa a describir los síntomas. Igualmente, enviar modificaciones del código para arreglar el problema es un suplemento útil en un informe de fallo, pero no un sustituto adecuado para el mismo.

Si un programador te pide información extra, ¡no te la inventes! Una vez alguien me informó de un fallo, y le pedí que ejecutara una cierta orden que yo sabía que fallaría. Le pedí que lo probase porque quería saber cuál de dos errores posibles surgiría. Conocer cuál era una pista vital. Pero no lo intentó – sino que me respondió diciendo “No, eso no va a funcionar”. Me llevó un tiempo persuadirle de que lo intentara de verdad.

Usar tu inteligencia para ayudar al programador está bien. Incluso si tus deducciones son incorrectas, el programador debería estar agradecido de que al menos hayas intentado hacerle la vida más fácil. Pero informa de los síntomas también, o quizás se la compliques.

“Vaya, lo hacía hace un momento.”

Dile “fallo intermitente” a un programador y fíjate la cara que ponen. Los problemas fáciles son aquellos en los que la realización de una secuencia simple de acciones hacen que surja el problema. El programador puede repetir esa secuencia de acciones en un entorno de pruebas cerrado y observable y ver lo que ocurre con gran detalle. Demasiados problemas no funcionan así: habrá programas que fallarán una vez a la semana, o una vez cada mucho tiempo, o nunca fallarán cuando los pruebes delante del programador pero sí cuando una fecha límite está a la vuelta de la esquina.

La mayoría de los fallos intermitentes no son verdaderamente intermitentes. La mayoría de ellos tienen alguna lógica en alguna parte. Algunos pueden ocurrir cuando la máquina se está quedando sin memoria, otros pueden ocurrir cuando otro programa intenta modificar un fichero crítico en el momento equivocado, y algunos pueden ocurrir ¡sólo en la primera media hora de cada hora! (Una vez vi uno de éstos).

También, si puedes reproducir el fallo pero el programador no puede, podría ser porque tu computador y su computador son diferentes en algo y ese algo es lo que provoca el fallo. Una vez tuve un programa cuya ventana se enrollaba en una pequeña bola en la esquina de la pantalla, se quedaba ahí y se enfurruñaba. Pero sólo hacía eso en pantallas de 800×600; en mi pantalla de 1024×768 estaba bien.

El programador querrá saber todo lo que puedas contarle del problema. Pruébalo en otra máquina, quizás. Pruébalo dos o tres veces y mira la frecuencia con la que falla. Si falla cuando estás trabajando en algo serio pero no cuando estás intentando demostrarlo, puede que sean los tiempos grandes de ejecución o ficheros grandes lo que lo hagan fallar. Intenta recordar todos los detalles que puedas acerca de lo que estabas haciendo cuando el programa falló, y si encontraste algún tipo de patrón, menciónalo. Cualquier información que puedas proporcionar será útil. Incluso si es sólo probabilística (como “falla con más frecuencia si estoy ejecutando el Emacs”), puede que no proporcione pistas directas acerca de la causa del problema, pero puede que ayude al programador a la hora de reproducirlo.

Más importante, el programador querrá estar seguro de si es un auténtico fallo intermitente o un fallo específico de esa máquina. Querrán conocer un montón de detalles acerca de tu computador, para intentar saber cómo difiere del suyo. Muchos de esos detalles dependerán del programa en particular, pero algo que deberías estar listo para proporcionar son los números de versión. El número de versión del propio programa, el número de versión del sistema operativo, y probablemente de cualquier otro programa que intervenga en el problema.

“Entonces cargué el disco en Windows…”

Escribir de forma clara es esencial en un informe de fallo. Si el programador no puede entenderte, quizás sea mejor no decir nada.

Recibo informes de fallos de muchas partes del mundo. Muchos de ellos de personas que no hablan inglés nativamente, y muchos de esos se disculpan por su pobre nivel de inglés. En general, los informes con disculpas por el pobre nivel de inglés son en realidad muy claros y útiles. La mayoría de informes confusos provienen de hablantes nativos de inglés que suponen que les entenderé aunque no hagan ningún esfuerzo por ser claros o precisos.

  • Sé específico. Si puedes hacer lo mismo de dos maneras, di cuál usaste. “Seleccioné Cargar” puede significar “Pulsé sobre Cargar” o “Pulsé Alt+L”. Di cuál usaste. A veces importa.
  • Se prolijo. Da más información en lugar de menos. Si dices muchas cosas, el programador puede ignorar parte de ellas. Si dices pocas, tienen que hacerte más preguntas. Una vez recibí un informe de fallo de una sola frase; cada vez que preguntaba más información, el informador respondía con otra frase suelta. Me llevó varias semanas obtener un volumen de información útil, porque respondía con una frase corta de cada vez.
  • Ten cuidado con los pronombres y los verbos sin sujeto. No uses referencias como “la ventana”, cuando no está claro lo que significa. Considera el siguiente ejemplo: “Lancé la AplicaciónCualquiera. Apareció una ventana con una advertencia. Intenté cerrarla y cascó.” No está claro lo que el usuario intentó cerrar. ¿Intentó cerrar la ventana de advertencia o la ventana de AplicaciónCualquiera? Hay una diferencia. En lugar de eso, podría decir “Lancé la AplicaciónCualquiera, la cual mostró una ventana de advertencia. Intenté cerrar la ventana de advertencia y AplicaciónCualquiera cascó.” Esto es más largo y repetitivo, pero es más claro y más difícil de malinterpretar.
  • Lee lo que has escrito. Léete el informe a ti mismo e intenta ver si crees que es claro. Si listas una secuencia de acciones a realizar para provocar el fallo, intenta seguirlas tú mismo para comprobar si has omitido algún paso.

Resumen

  • El primer objetivo de un informe de fallo es permitir que el programador vea el fallo por sí mismo. Si no puedes hacer que el programa falle delante de ellos, dale instrucciones detalladas para que ellos mismos puedan hacer que falle.
  • Si esto no surte efecto, y el programador no puede verlo fallar por sí mismo, el segundo objetivo del informe de fallo es describir lo que falló. Describe todo en detalle. Describe lo que viste, y lo que esperabas ver. Toma nota de los mensajes de error, especialmente cuando contengan números.
  • Cuando el computador haga algo inesperado, detente. No hagas nada hasta que estés tranquilo, y no hagas nada que creas que es peligroso.
  • Por todos los medios, intenta diagnosticar el problema tú mismo si crees que puedes, pero si lo haces, informa también de los síntomas igualmente.
  • Prepárate para proporcionar información extra si el programador la necesita. Si no la necesitasen no preguntarían por ella. No es que estén siendo retorcidos. Ten los números de versión preparados, porque probablemente harán falta.
  • Escribe de manera clara. Di lo que quieres decir, y asegúrate de que no se puede malinterpretar.
  • Por encima de todo, sé preciso. A los programadores les gusta la precisión.

Advertencia: nunca he visto en realidad una mangosta o un antílope. Mi zoología puede ser inexacta.

$Id: bugs.html 6719 2006-05-30 12:46:40Z simon $

Copyright © 1999 Simon Tatham.
Este documento es “ContenidoAbierto”.
Puedes copiarlo y usar el texto bajo los términos de la licencia OpenContent.

Link original de este articulo: Como informar de fallos de forma efectiva


Orientación a Calidad de los programadores en desarrollos de Sistemas Web

Publicado por Maribel Ravelo:

Cuando, en Gerencia de Proyectos, se habla de Calidad, nos referimos a cumplir con los requerimientos y necesidades del cliente, dentro del Alcance establecido, pero también se trata de precisión y veracidad. Precisión se relaciona con la consistencia de los resultados y veracidad con el resultado en sí, qué tan cercano a la realidad, al deber ser, se encuentra la solución desarrollada.

La Calidad en un Sistema Web tiene dos caras. Por lo general hay una de ellas que no es fácilmente visible y requiere de una evaluación más detallada y de ejecutores más conscientes de la importancia presente y futura de códigos fuentes bien elaborados. Presente por la salud del proyecto y futura por la salud del mantenimiento durante la operatividad.

Hay que tener muy presente que el cliente no posee, necesariamente conocimientos técnicos y las personas que elaboran las pruebas de certificación del producto son usuarios, y como tal hacen revisión del funcionamiento, muy probablemente con datos no reales y en un escenario que tampoco se ajusta al “día a día” del uso que debe darse a éste cuando se encuentre operacional.

Es por ello que cuando se trata de evaluar Calidad en los Sistemas que desarrollamos, no debemos dejar la responsabilidad de las pruebas del lado del cliente. La responsabilidad mayor del Aseguramiento de la Calidad se encuentra del lado del equipo de desarrollo, que no está formado sólo por los programadores, aclaro.

Por otra parte, la Gestión de Calidad es un proceso continuo que nos ayuda a mitigar riesgos y a evitar re-trabajo. Es por ello que las actividades que se deben llevar a cabo para ello se incluyen en la Planificación del Proyecto.

Es cierto que estas actividades incrementan los tiempos de ejecución en el plan, pero hay que tomar en cuenta que previenen los incrementos en tiempos de ejecución fuera del plan y por ende, los costos no considerados.

La acción clave es “probar”, palabra sencilla que bien analizada se expande en muchas más e incluiré algunas metáforas:

No dejar que los documentos se llenen de polvo.Tener siempre presente los requerimientos especificados y cualquier cambio sobre estos que se haya aprobado. El documento de especificaciones es la guía de viaje del programador.

  • Recorrer el camino sin pasar desapercibidos los detalles. No dejar para “después”. Realizar pruebas durante el desarrollo basadas en un plan que contemple los escenarios reales y posibles. Es necesario documentar los resultados y acciones correctivas. Aparece acá otra clave “no asumir”.
  • Ver el objeto desde lejos para ver el todo. Hacer una corrección no sólo afecta el módulo que se está probando. Por lo general los Sistemas están formados por partes interrelacionadas, al menos es parte de su etimología, por lo que alterar una parte puede afectar otras. Es por ello que debemos estar al tanto de qué partes se interrelacionan para hacer pruebas posteriores a cambios.
  • Luego de las partes, no olvidemos el todo. Lo que llamamos comúnmente Pruebas Integrales, se refiere a que luego de asegurarnos de que cada módulo funciona en las pruebas individuales, debemos asegurarnos de que el Sistema, los módulos en conjunto, funcionan.
  • Efectividad y Eficiencia.Lo más seguro es que el cliente se fije más en la efectividad en algunos escenarios, sin embargo, en el mundo de la tecnología sabemos cuán valioso es que un Sistema sea eficiente. Efectividad – que funcione y dé los resultados esperados. Eficiencia – que esos resultados los dé en un buen tiempo. Con buen tiempo me refiero a que se aprovechen los recursos de procesamiento y memoria adecuadamente, valiéndose de las bondades del lenguaje de programación con el que se esté trabajando.
  • El cocinero luego de varias pruebas tiene el paladar cansado y ya no saborea. Finalmente se necesita que un equipo de personas no involucradas en la programación, y con ayuda de su experiencia técnica y la documentación del proyecto, realice pruebas integrales del Sistema. Es sólo luego de esta actividad, y por supuesto de que se certifique que el producto pasa con éxito los chequeos de calidad – probablemente de más de un ciclo de corrección-pruebas, que se puede hacer la entrega al Cliente. Nos acerca a la obtención de un cliente satisfecho y los méritos de un buen trabajo a todo el equipo que participó en su desarrollo.

El tiempo que tomemos para ejecutar todo lo mencionado no es un gasto, es una inversión. Y sólo mencioné lo que respecta a las acciones por parte del proveedor del servicio de desarrollo del Sistema, podría generar otras líneas para dejar algunas lecciones en cuanto a la responsabilidad del cliente – quien debe tener el mayor conocimiento del objetivo del producto para su negocio o fin, no obstante, es otro tema.

Esto es sólo un breve resumen acerca del tema, pues sobre Calidad podemos encontrar mucho material teórico y normas. Con este artículo intento sólo dejar una semilla de consciencia a programadores, líderes y gerentes de proyectos tecnológicos.

“Una de las grandes desventajas de la prisa es que lleva demasiado tiempo.” Gilbert Keith Chesterton.

Fuente: Aticulo de GlobalWebTeck

Gerencia de Proyectos Web

Publicado por Listbeth Rojas:

La ejecución de proyectos para la construcción de Sitios Web, se ha convertido en una labor muy frecuente a nivel mundial. Todo individuo u organización que pretenda ofrecer los servicios de proyectos en el ámbito de Internet debe brindar las competencias necesarias para la gerencia, desarrollo, posicionamiento y mantenimiento de los mismos. Un proyecto para desarrollo de páginas web se diferencia de los tradicionales, porque están dirigidos, en su mayoría, a un público global, general, que no va a ser adiestrado en su uso y funcionalidad, por lo que se deben manejar ciertas técnicas y herramientas para asegurar el éxito del producto obtenido.

Podemos encontrar en el mercado, páginas web que no cumplen con ciertos estándares y elementos que nos garantizan que es un buen sitio web. Muchas veces esto se debe a que son desarrollados por profesionales del área de sistemas o de otras áreas, que no necesariamente tienen experiencia en tecnología Internet y no manejan las premisas fundamentales para la construcción de páginas web centradas en el usuario y en la usabilidad.

En este artículo me voy a enfocar en la Gerencia de Proyectos para construcción de páginas web, lo cual vale destacar que no se distancia de la gerencia de cualquier tipo de proyecto de tecnología de información. Sin embargo, vamos a visualizar aquellos aspectos de interés que recomiendo se tomen en cuenta en los procesos o actividades que conforman la metodología de ejecución del proyecto, con la finalidad de asegurar el éxito del mismo.

En el área de Gestión de Proyectos, es importante utilizar una metodología que sirva de guía para la organización, documentación y desarrollo del proyecto web. Esta metodología abarca el ciclo de vida del proyecto, los cinco (5) procesos que intervienen en la gerencia de proyectos y las nueve (9) áreas de conocimiento que establece el PMI (Project Management Institute) en el PMBOOK (Guía de los Fundamentos de Gerencia de Proyectos ). La gráfica a continuación muestra los 5 procesos que conforman la Gerencia de Proyectos.

Ahora bien, veamos algunos tips a considerar cuando de trata de un Proyecto WEB.

Proceso de Iniciación

Contempla la conformación del equipo de trabajo, análisis del alcance del proyecto, reunión para formalización de arranque (kickoff), entre otros. Este proceso es muy importante porque establece las bases para la ejecución de todo el proyecto. Aquí quiero destacar la importancia de la actividad de conformación del equipo. La ejecución de un proyecto web requiere un equipo multidisciplinario, ampliamente calificado. Las pericias o áreas requeridas en este tipo de proyecto se muestran en la siguiente figura:

  • Diseño Interacción: se refiere al rol responsable de la definición de la estructura y comportamiento de la página web. Enfatiza la estructura conceptual y la organización del  contenido. Se centra en cómo el usuario fluye a través de tareas definidas y los pasos para realizarlas, es decir, diseño centrado pensando en el usuario.
  • Diseño Gráfico: se refiere al rol de la persona responsable de la parte visual (imagen, color, texto, ubicación). Consiste en el proceso de programar, proyectar, coordinar, seleccionar y organizar una serie de elementos visuales destinados a comunicar los mensajes a incluir en la página web.
  • Edición WEB: responsable del contenido y de montar el sitio en tecnología Internet, bien sea utilizando HTML o CMS (Content Management Systems).
  • Programación: responsable del desarrollo y configuración de las facilidades que ofrecerá la página web.
  • Mercadeo: Aporta conocimientos para proponer o ejecutar los programas de promoción, lanzamiento y publicidad de la página web que se está desarrollando.

Proceso de Planificación

En esta etapa es importante madurar el alcance. Para ello se deben llevar a cabo sesiones detalladas de levantamiento de información que permitan conocer lo que quiere el cliente y nivelar sus expectativas. En este caso se puede validar realmente la razón por la cuál el cliente quiere una página web y el uso que le quiere dar. De esta manera podemos orientar los requerimientos del cliente a construir una página web con beneficios para él y sus usuarios. No podemos limitarnos a estar en Internet, que sea bonita y ya, nuestra tarea es orientarles en concebir una web de utilidad para los usuarios y que aporte beneficios al cliente. En estas sesiones de levantamiento de información, también es importante visualizar el objetivo de la página web, para quién va dirigido, el entorno, plataforma en la que será implantada, etc.

Proceso de Ejecución

En este proceso utilizamos la Metodología de Desarrollo de Soluciones, focalizando en este artículo la atención en el diseño y construcción, de manera que podamos ofrecer a nuestros clientes prototipos o entregas preliminares de diseño que le permitan visualizar, palpar, entender cómo está siendo concebida su página Web. Este es el momento decisivo, pues se debe crear una interfaz que, a pesar de lo complejo que pueda ser el proyecto resulte sencilla de entender, fácil de usar, atractiva visualmente y modular para permitir posteriores fases de desarrollo.

Haciendo uso de propuestas de diseño, vamos a montar la página web previa aprobación del Cliente. Eso por supuesto, minimiza tiempo y costo, de manera que con una propuesta visual aprobada, estamos listos para configurar las diferentes secciones e incluir la programación pertinente.

Seguidamente, en la Etapa de Evaluación, se deben realizar pruebas de funcionalidad y control de calidad de toda la página web, antes de ser publicada. Y finalmente, en la Etapa de Transición, con el visto bueno del Cliente y la certificación del equipo de proyecto, se procede a publicar la página y es en ese momento que todos los usuarios comienzan a tener contacto con la página web construida.

Procesos de Seguimiento y Cierre

Estos procesos al igual que en todos los proyectos, se componen de actividades realizadas para monitorear la ejecución y formalizar la finalización de actividades y entrega del producto final, respectivamente.

Fuente: Articulo de GlobalWebTeck

 



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Buscalo

Twitter

  • @abr4xas y que tengas hambre, ganas de orinar y un chinazo sentado al lado tuyo mirandote #WelcomeaToTheHELL 5 years ago
  • Oy tu! si tu chica... busca a un amigo y enseñale los senos para que te revise si presentas o no Cancer de Seno. Tocate o deja que te toquen 5 years ago
  • R.I.P. Dennis Ritchie, padre del Lenguaje C y del sistema UNIX goo.gl/H20h9 nuevamente estamos de luto. 5 years ago
  • @the_fricky steve en vida trato de reclutar a torvald y no pudo, tal vez pidio a dennis y ahora el cielo tendra buena cloudcomputing 5 years ago
  • Ojala que si :D RT @the_fricky: Mira que decidir que la computación en la nube va a estar basada en Unix... 5 years ago
  • +1 RT @Richzendy: Así como cuando haces todo como lo dice la documentación, has probado combinaciones no documentadas y aún así no funciona 5 years ago
  • @mapologo @EJDecena cuando hay reunion en python-ve 5 years ago
  • Se necesita un Apocalipsis Zombie 5 years ago
  • RT @ChiguireBipolar: Caída de BlackBerry hace que joven descubra novio e hijo que no conocía --> bit.ly/pEIX9j 5 years ago
  • Los malandros no te quitan el celular si este es chimbo, hoy tambien podrian devolverte igual tu Blackberry. Ahora si es un Blackburro. 5 years ago

%d bloggers like this: