Archivos para 28 abril 2011

Las redes sociales – ¿Mercadeo o TI?

Social Networks

Últimamente he oído mucho sobre el debate existente sobre si las Redes Sociales, particularmente el caso de Facebook y Twitter, es un área que debe conocer, usar, aprovechar y especializarse desde el área de Marketing de una empresa o desde el área de Tecnología de Información (TI). Dicho de otro modo, la estrategia de Redes Sociales ¿debe ser guiada por Mercadeo o por TI? El debate es muy similar al que había hace unos años sobre los proyectos de Comercio Electrónico (debate en el que personalmente tengo la misma opinión que la que aquí escribo: el E-commerce es un tema de negocios).

Haciendo un breve descargo de responsabilidad, debo confesarles que están leyendo una opinión de un profesional de las ciencias computacionales y un apasionado de la tecnología de la información, incluyendo todo el movimiento de las aplicaciones sociales. En síntesis, me considero un especialista en tecnología Web e ingeniería de software y, aunque también tengo formación y experiencia en Negocios, no soy un mercadólogo. Mencionado esto, les comento mi percepción sobre este tema.

A mi me parece que TI debe estar al servicio de Marketing. Es decir, la estrategia de redes sociales, lo que se pretende con ella, los resultados, las mediciones, el propósito de las redes sociales, etc. debería ser guiada por el área de Mercadeo (quizá incluso por la misma dirección general). La estrategia de redes sociales es, en esencia, un subconjunto de las estrategias de mercadeo y comunicación de una empresa y, por tanto, debe estar alineada con ellas. Y este es un trabajo del Director de Mercadeo y/o Comunicación.

Sin embargo, para que una estrategia de redes sociales sea efectiva y aún bajo la suposición de que será dirigida por Mercadeo, es condición necesaria que el área de TI apoye 100% dichas estrategias, Entre otras cosas, veo necesario:

  • Que TI le presente (periódica pero permanentemente) a Marketing toda la gama de posibilidades y herramientas tecnológicas que las redes sociales tienen. Y este no es un trabajo menor porque las redes sociales (Facebook y Twitter particularmente) y todas las herramientas de terceros basadas en ellas, cambian vertiginosamente y es trabajo de TI conocer las especificidades técnicas para poder usar adecuadamente las redes sociales.
  • Que TI aconseje a Marketing (no que decida) qué cosas puede aprovechar. E inclusive, idealmente, debe mostrarle (con pruebas o demos sencillos) estas posibilidades porque no siempre las palabras o presentaciones Powerpoint son suficientes para dar a conocer cierto concepto tecnológico.
  • Importantísimo es que el área de TI o las personas de TI que se involucrarán en proyectos de redes sociales, hables el lenguaje de Mercadeo. Aunque no sean especialistas sí que entiendan el lenguaje de negocios de la empresa.
  • Que Marketing visualice nuevas posibilidades “escuchando” a su asesor de TI. Es decir, que esté abierto a la utilización de nuevas tecnologías pero enmarcándolas y aprovechándolas en el contexto estratégico de mercadeo de la empresa. No como iniciativas aisladas. Y que, en este sentido apruebe, o rechace, herramientas específicas de las redes sociales.
  • Que una vez que la empresa decida embarcarse en proyectos de redes sociales, marketing y TI trabajen muy cercanamente, muy frecuentemente, y de manera colaborativa.

Creo que de esa manera, las posibilidades de que los proyectos fracasen por falta de entendimiento de las tecnologías o por falta de alineamiento estratégico con la empresa se reducen significativamente.

¿Y qué con el caso de LinkedIn? Bueno, el tema me parece muy similar pero siendo dirigido esta vez por el área de Gestión del Talento de la empresa. O dicho de otro modo, siempre ¡la TI al servicio de los negocios y organizaciones!

, , , , , , ,

Deja un comentario

Desarrollo Ágil y sus posibilidades con Rails

Proceso SCRUM

Fuente: Scrum Alliance

El desarrollo de software para la Web ha venido a apuntalar y terminar por validar diversas metodologías de Ingeniería de Software conocidas como Metodologías de Desarrollo Ágiles. Aunque existan muchas, y con variantes entre sí, de las más conocidas está SCRUM, XP (Extreme Programming) y la de Desarrollo de software Lean (o delgado). Aunque existen muchas, todas ellas están basadas en el Manifiesto de Desarrollo Ágil:

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

En general, podemos decir que se intenta provilegiar la construcción iterativa e incremental de los productos de software, tomando mucho en consideración, en cada ciclo, el punto de vista de los usuarios o clientes. Todo esto se basa en la idea, que considero completamente correcta, de que el usuario o el cliente termina por definir los requerimientos del software únicamente después de que ve y “siente y prueba” el software que se está creando, y no antes.

Aunque el cliente previamente puede tener una idea, ya sea extremadamente vaga o bien imaginada, de lo que requiere en su software, es en el momento que ve en la pantalla de la computadora cuando el cliente realmente termina de definir bien lo que requiere. E inclusive podría requerir varios ciclos de mejora antes de que su necesidad haga “click” en su cabeza. Dicho de otro modo, se trata de ir construyendo y clarificando los requerimientos del software durante (y no antes) la construcción del mismo.

Hoy día se intenta ir incluso más allá con técnicas muy innovadoras como el Test Driven Development (TDD – Desarrollo dirigido por las Pruebas) ó el Behaviour Driven Development (BDD – Desarrollo dirigido por el comportamiento del software). A continuación, una brevísima explicación de ambas.

El TDD se basa en el concepto de que el desarrollador debe codificar primero la prueba o pruebas de algún requerimiento específico. Una vez codificada la prueba asegurarse de que la prueba en realidad es fallida y posteriormente realizar la programación para que la prueba pase. Ya que logró pasar la prueba entonces realizar un proceso de afinado del código para “limpiarlo”, optimizarlo y documentarlo. También en muchas ocasiones el developer o equipo de developers debe estar consciente de que antes de codificar la primera prueba de este ciclo primero debe decidir si el sistema tal como está en ese momento es el idóneo para codificar la prueba o si debe restructurarlo para que sea más adecuado para satisfacer el requerimiento que se va a probar/codificar. Algo así:

Técnica TDD = Refactoring (opcional) + Codificación de la primera prueba del requerimiento

Pero lo esencial del TDD es “First code the Test, then code to pass the test” ó “Primero codifica la prueba, luego codifica para pasar la prueba”.

El método BDD incluye TDD pero lo extiende de manera que las pruebas no sólo sean creadas por el Developer sino también por éste y el cliente o usuario final, utilizando para definir el requerimiento (cierto comportamiento específico del software) un lenguaje casi natural. Dicho de otro modo, el cliente en conjunto con el Developer definen (en un lenguaje específico legible para usuarios no técnicos) el comportamiento y tomando este como insumo el developer codifica la prueba y sigue el método TDD. Excelente, ¿eh?

¿Qué tiene que ver todo esto con la computación en la Nube? Bueno pues que el Software-as-a-Service tiene hoy día una matrimonio con las nuevas metodologías Ágiles de desarrollo, y con técnicas como BDD/TDD. La Web, o al menos la buena Web, se está construyendo alrededor de esta Ingeniería de Software. Un proyecto de construcción de un producto para la Nube debe tomar en consideración estos métodos más que los tradicionales métodos de Project Management.

En el caso de Ruby on Rails, el framework no sólo ya cuenta con mecanismos incluidos dentro de la plataforma (por ejemplo, un subsistema de pruebas) que apalancan métodos ágiles y TDD sino que también se han construido herramientas excelentes y que están ganando momentum en el mercado, tales como Cucumber, herramienta programada en Ruby, que automatiza de manera elegante y sencilla el método BDD para proyectos no sólo de Ruby on Rails sino también Java, Python y C#.

¡Bien por Rails y las metodologías ágiles! Si bien es cierto que esto no es exclusivo de Rails, sí es una razón más para seleccionar Rails como framework de desarrollo para la Nube.

, , , , , , , ,

Deja un comentario