El Blog de Pablo Fernando Sanchez

Esta es mi bitácora personal, en la cual trato, sin limitarme a ello, sobre ingeniería de software, ingeniería de sistemas, gestión estratégica, modelado de procesos, metodología, aseguramiento de la calidad, gestión del conocimiento y todos esos asuntos que hacen, desde la gerencia y la técnica, a las empresas que asesoro.

Herramientas

KPI Dashboard

Blogs Amigos

En Otros Blogs

Estas son algunas entradas en otros blogs inscriptos en Bitacoras.com en las cuales me citan:

Seguro que el lector experimentado en la industria del software no necesita que se lo mencione, pero lo hago de todas formas para quienes no estén concientes del asunto: el viejo adagio que, refiriéndose a los posibles clientes de nuestro producto software, versa «constrúyelo y vendrán» es una completa falacia. Muchas veces, la gente de abstracción técnica fascinada por, precisamente, los retos, logros y demás cuestiones estrictamente ingenieriles, ni siquiera piensan en el resto o simplemente lo toman como un mal necesario menor en lo cual ocuparse «luego».

Pues... la experiencia dice otra cosa muy distinta. En lo personal y habiéndolo discutido miles de veces con empresarios del software, creo que el esfuerzo de construir software —escribir el código y hacerlo funcionar— es tal vez de entre un 15% y un 20% del esfuerzo requerido para tener un producto software exitoso. Las actividades de investigación, planeación, diseño, pruebas, mercadeo —o marketing— y comunicación son, en gran medida, aquellas a las cuales se debe dirigir la mayor parte del esfuerzo. Piensa «fuera de la caja». Piensa en el usuario y no sólo en la tecnología. Lo que te diferenciará, en definitiva, será proveer más que sólo una pieza de software.

Reconozcámoslo... no siempre se gana el mercado el mejor bolígrafo, sino que es el bolígrafo mejor mercadeado el que lo gana. Escribir el producto software es una parte muy pequeña de la batalla. El negocio, en realidad, es sobre mercadear y vender. Todos hemos visto pésimos productos software, repletos de defectos de todo tipo, siendo mundialmente reconocidos y haciendo toneladas de dinero, mientras que productos software técnicamente avanzados se pierden en el olvido porque la empresa simplemente asume que el producto es tan bueno que se venderá sólo.

En particular, el mercadeo debe ser visto como una actividad constante de tiempo completo, ya sea en línea, fuera de línea, a través de revendedores, correo directo, avisos publicitarios impresos, en línea, en Google, etcétera. El mercadeo, como sucesión de prueba y error, termina constituyendo la diferenciación en tu producto software mediante la construcción de la marca, marca que tienes que amar. Finalmente, lo que harás incansablemente para vender tu producto software al resto será vender tu marca al resto.

Sólo si tienes suerte y tienes el próximo YouTube o Digg, la gente instintiva y multitudinariamente se referirá a tu marca. Pero lo cierto es que la enorme mayoría no lo logra de esta manera, por lo cual hay que trabajar duro para conseguir una cantidad tal de clientes que te dé la suficiente cantidad de dinero para mantener tu negocio operando.

Tómate el tiempo de hacer un listado de tus competidores y sus productos. Para cada uno, considera datos básicos como precio, modelo de licenciamiento, una impresión superficial de su calidad —esa primera impresión—, popularidad y mercado objetivo, por ejemplo. A partir de ello puede hacerse un poco de inteligencia de negocios para llegar a dos conclusiones básicas:

  • qué es lo que funciona o qué hace exitosos a los productos exitosos y
  • cuál es el nicho de mercado insatisfecho al cual vas a tomar como objetivo o si tienes que crear un mercado.
Si llegas a estas conclusiones y encuentras un buen nicho, trabaja nuevamente en:
  • el plan de mercadeo de tu producto software,
  • el sitio web mediante el cual muestras lo que tienes y
  • tu producto software...
Sí... es muy probable que llegues a nuevas conclusiones relacionadas con la forma en que has construido tu producto, por lo cual debas hacerle reingeniería pues, entre otras cosas, ese nicho de mercado debe sentir que tu producto software fue diseñado especialmente para satisfacer sus necesidades.

En cuanto a la estrategia de comunicación, todo depende de lo anterior: las características del producto y el nicho de mercado. Muchas veces, por desconocimiento, se tiende a comunicar por comunicar y por el medio que sea, cosa que en la mayoría de los casos no es adecuada. Por ejemplo, productos como Skype o YouTube no necesitan de una fuerte campaña de comunicación, sino que dependen de las sugerencias dentro de redes sociales —en línea o fuera de línea—, lo que conocemos como el «boca a boca».

Si has construido un producto software sin tomar en cuenta consideraciones de este tipo, es tiempo de que te calces el sombrero de mercadeo y que te pongas a trabajar —o, si no te gusta el asunto, que alguien más lo haga por tí. Y espera que sea duro. Mucho más duro que escribir software...

Hace tiempo me preguntaron sobre los estándares que The Institute of Electrical and Electronics Engineers (IEEE) ha desarrollado en torno a la disciplina Ingeniería de Software, por lo cual aprovecho este espacio para responder.

Primero, cabe una aclaración. El IEEE desarrolla sus estándares a través de una de sus entidades, la IEEE Standards Association (IEEE-SA). Asimismo, este desarrollo se potencia mediante otras entidades técnicas abarcadas por el Instituto. En el caso puntual de este conjunto de estándares, estas entidades técnicas son la IEEE Computer Society (IEEE-CS) y el IEEE Technical Council on Software Engineering (TCSE), las cuales participan de esta actividad mediante un comité: el Software & Systems Engineering Standards Committee (S2ESC).

Lo mencionado es desde lo institucional relacionado directamente con el IEEE. Sin embargo, no debemos olvidar que en el desarrollo de estos estándares también participan organizaciones de todo tipo, como empresas del sector privado, universidades, otras organizaciones no gubernamentales y gobierno. He hablado sobre el procedimiento completo y cómo participar de estas actividades en alguna que otra de mis charlas en los diferentes eventos de los cuales he participado.

Este conjunto de estándares abarcan todos los aspectos técnicos relacionados con la Ingeniería de Software. Son un excelente complemento para modelos de alto nivel como el Capability Maturity Model Integration (CMMI) aunque, por supuesto, deben ser interpretados y adaptados a las necesidades particulares de cada organización para sacarles el máximo provecho.

Ahora bien, para quien desee tener un listado completo de este conjunto de estándares, siempre actualizado a la fecha con sus respectivos estados, puede acceder mediante este enlace. Se trata sólo del listado con su estado y descripción, no del texto completo pues, como ocurre con la mayoría de los estándares, acceder a ellos tiene un costo —el cual es preferencial para los miembros del IEEE.

Blog Widget by LinkWithin

Seguime

Suscribite al feed de mi blog Suscribite para recibir las actualizaciones de mi blog por correo electrónico Seguime en twitter

Seguidores

Etiquetas

Últimos Artículos

Herramientas

IBSN