Hoy decimos

Resolvemos tus problemas - Conversá con nosotros

martes, 16 de septiembre de 2014

Gestión de Operaciones en IT

El artículo que sigue es parte de la "salsa secreta" o "ingrediente secreto" de mi carrera laboral en IT. Espero que este knowledge-transfer les sea útil.

Básicamente es un área de interés profesional fundamental en el desempeño del especialista IT, aunque muy pocos están capacitados en la temática porque no existe en muchos planes de estudio, y en los que existe, se le da una importancia mínima, ni siquiera suele tener práctica fuera de ejercicios escritos.

La gestión de operaciones es un campo extenso, y si bien muchas facetas se aplican muy bien a IT, yo comenzaría por aprender con un enfoque práctico, antes que teórico, y luego, ya sentadas las bases, la teoría aplicada a IT se va a entender mucho mejor (lo que es bueno, porque la mayoría de los ejemplos de la teoría de gestión de operaciones son de producción industrial de bienes).


Tampoco es imposible aprender la teoría de gestión de operaciones con ejemplos verosímiles para IT:

Throughtput: es la cantidad de resultados entregados (productos, partes, etc.) por unidad de tiempo;  Ejemplos de aplicación del concepto: 

a) En una organización hay 100 PCs teóricas con problemas por día. El "producto" es una PC reparada, que funciona. Entonces el througput óptimo para satisfacer los requerimientos del cliente (la organización), es poder reparar/solucionar el problema de 100 PCs por día.

b) El "producto" es un cambio exitoso en una configuración de red en la organización. En una organización se producen 100 cambios de configuración de red por día, pero la capacidad de producción de cambios es de 20 cambios por día, entonces, la priorización de actividades debe ajustarse para efectivizar los cambios indispensables/necesarios respetando - la realidad de los recursos disponibles en la - que solo se podrá cumplir con 20 de los 100 cambios solicitados por día. 



Pero veamos el enfoque práctico:

¿Cuantas veces participaron de un evento o actividad IT en una organización?

Se corta la luz y la DB "vuelve mal" del corte; se corta una fibra óptica en algún lugar y la mitad de la organización deja de estar conectada con la otra mitad; una vieja versión de un software muy usado en la organización se reemplaza por una nueva versión; se pone en producción un software que va a ser muy usado en la organización, pero hasta ahora no se usó nunca masivamente, etc. etc. 

Son comunes en el trabajo IT diario en muchas de sus especialidades: administración de sistemas, redes, bases de datos; las menos tradicionales adm. de infraestructura virtual, adm. de storage; adm. de cloud; soporte técnico, security; desarrollo, etc.

Sin embargo, a lo largo de mi experiencia he visto que inclusive especialistas muy buenos a nivel técnico, con años de experiencia inclusive, no tuvieron suficiente expertise en gestión de operaciones, y muchas operaciones fallaron estrepitosamente por fallas importantes de gestión operativa; aunque la gerencia general y la ejecución técnica de las tareas fueran muy buenas.

En gestión de operaciones la cuestión de fondo NO es lograr buenos resultados técnicos individuales (poder instalar y configurar un servidor de base de datos, por ejemplo), NI TAMPOCO una gerencia general efectiva (producir un ROI razonable, terminar un proyecto, por ejemplo), sino poder hacerlo todo con los recursos disponibles y dentro de las limitaciones insuperables del contexto (o del sistema total, aplicando teoría de sistemas).


Por qué falla la gestión de proyectos sin gestión operativa
La investigación operativa, la gestión de tiempo (GTGPomodoro), de proyectosde logística, de la cadena de suministros son a la vez ramas de la administración muy relacionadas (y muy interesantes de conocer), con la gestión de operaciones, pero NO son gestión de operaciones o adm. de la producción (como se la conoce mejor en AR).

* Por ejemplo, y aunque tienen puntos en común, la gestión de operaciones se diferencia de gestión de proyectos en  que la gestión de proyectos se da en un marco de tiempo limitado, mientras que la gestión de operaciones se ajusta a tareas habituales.

La diferencia más importante para para IT especialmente: la gestión de proyectos maneja muy pocos componentes y técnicas para gestionar recursos que no sean tiempo y presupuestos.

El rediseño de procesos que contempla la gestión operativa es vital para muchos proyectos IT: por ejemplo, 

Dado el proyecto "escribir una aplicación" y el proceso "escribir la aplicación en PHP" con un requerimiento: culminar en un tiempo X .

Si tenés un programador que es muy bueno en Python y no tiene experiencia en PHP, la práctica de gestión operativa recomendará modificar el proceso para hacerlo con Python, cuando para el mismo caso, la gestión de proyectos en gral. solo recomendará aumentar el tiempo X del proyecto para permitirle aprender al programador y escribir en PHP.

¿Qué pasa si no existe la posibilidad de aumentar el tiempo X del proyecto? Y si se sigue la práctica habitual de gestión de proyectos, la mismo no tendrá éxito en cumplir con el requerimiento de tiempo X, se va a terminar después.

Manejando la gestión operativa, SIN aumentar el tiempo X del proyecto, se modificará el proceso "escribir la aplicación en PHP" a "escribir la aplicación en Python" y se terminará con éxito el proyecto "escribir una aplicación" en el marco de los recursos disponibles (el tiempo pre-establecido para el proyecto).


Claro, si convertimos en requerimiento del cliente el escribir la aplicación en PHP entonces habrá que buscar otra solución que no sea cambiar el lenguaje. 

Vemos así que el concepto "requerimiento" es diferente de "proceso".

La solución operativa puede o no existir, por cierto.


Gestión Operativa
Para el concepto de gestión de operaciones me remito aquí a la Wikipedia en inglés, que tiene mucho mejor material que la página en español:

Operations management is an area of management concerned with overseeing, designing, and controlling the process of production and redesigning business operations in the production of goods or services. It involves the responsibility of ensuring that business operations are efficient in terms of using as few resources as needed, and effective in terms of meeting customer requirements.


"La gestión de operaciones un área de gerencia que se ocupa de supervisar, diseñar y controlar el proceso de producción y rediseño de operaciones de negocios para la producción de bienes y servicios. Involucra la responsabilidad de asegurarse que las operaciones de negocio son eficientes en términos de uso de tan pocos recursos como sea necesario, y efectivas en términos de alcanzar los requerimientos de los clientes."


En otras palabras, es el campo de especialidad de la administración que enseña a hacer que las cosas pasen. Que los resultados se logren, que los objetivos se cumplan, con lo que sea que se disponga de recursos para hacer el trabajo.


Práctica de gestión operativa para IT
La práctica de gestión de operaciones es fundamental, el mero estudio de situaciones prácticas, hacer "práctica" con ejercicios escritos, es 100% insuficiente, no sirve para enseñar cómo es gestionar operaciones IT en la vida real.

Sin embargo es fácil practicar; básicamente la aplicación de gestión de operaciones se va a dar en el trabajo diario en IT, así de frecuentemente.

Pueden ejercitar desarrollando, administrando, gerenciando, en cualquier nivel de práctica profesional van a encontrar las situaciones en que se vuelve necesario - o indispensable - la gestión de operaciones.

Así que podemos practicar desarrollando una aplicación, un script; configurando un router, levantando un servidor web; puede hacerse en una máquina virtual por ejemplo.

La clave de la práctica es que tenga límites en los recursos disponibles para realizar el trabajo, 

Ejercicio (adm. de sistemas): 

Un futuro servidor web tiene 5 GB de espacio libre en disco, que ahora es espacio vacío, 1 GB de RAM; y el cliente necesita ejecutar allí un CMS dentro de 1.5 horas (en una hora y media). 

No se puede ampliar los recursos disponibles, el tiempo disponible para ejecución tampoco es ampliable.

Brinde opciones de solución viables y factibles en ese contexto, descarte y fundamente opciones inviables, luego de planteada la solución viable, ejecutela según el plan y los recursos.


Solución ofrecida (al 2014): Instalar Ubuntu LTS (sin actualizarlo al instalar) y usar Wordpress como CMS.

Va a permitir una rápida instalación (incluída la descarga de la imagen mínima), y los requisitos para el CMS son mínimos, por lo que los 5GB de espacio van a alcanzar para instalar todo lo necesario.


La limitación de tiempo y recursos invalidaría otras opciones como por ejemplo:

- Usar Windows Server (ocupa más de 5GB y no se va a instalar con 1 GB de ram, de todos modos la instalación tardaría casi el plazo total de tiempo disponible, dejando solo minutos para instalar el CMS, si no se dispone previamente de la imagen de instalación - es un DVD de 4 GB aprox. - bajarla tomaría mucho tiempo)

- Usar Debian Linux (la instalación vía imagen mínima toma mucho tiempo porque la mayoría de sus servidores responden con lentitud - últimamente - lo que inclusive al realizar una instalación de pocos cientos de MBs, lo vuelve inviable)

- Etc.

Luego hay que ejecutar y lograr que efectivamente se consiga instalar y poner en producción el web server + CMS en un hora y media.

Como ven con el ejemplo de Debian, la práctica es indispensable para la gestión de operaciones, inclusive sabiendo los requerimientos técnicos de instalación de Windows Server (el tamaño mínimo de disco para instalar Win, una posible opción viable como Debian queda 100% invalidada por la práctica. Debian debería funcionar, pero cuando vamos a la ejecución, falla.


Para eso es la práctica técnica de gestión de operaciones. Para lograr saber cómo tener éxito en realizar lo que hace falta, no solo en lo técnico, sino en lo gerencial.


Training disponible
Como ya dije es un campo muy amplio, a duras penas se puede enseñar en un cuatrimestre o semestre, pero alcanza bien para enseñar la teoría básica de gestión de operaciones, algunas técnicas/prácticas habituales (como analizar y ajustar thoughputs, planificación y configuración de sistemas de producción, etc.), y dar algunas horas de práctica real.

Wharton es una de las mejores escuelas del mundo para enseñar administración, y este invierno van a dictar un curso introductorio de gestión de operaciones (arranca el 29 de septiembre), lo recomiendo para quien quiera iniciarse en la temática.



Sldos.

Libres Consultores
Dardo Valdez - ar.linkedin.com/in/dardovaldez/
Cel. 379-4316500
Skype: dardo_valdez

jueves, 12 de junio de 2014

Cómo estamos convirtiendo Solución de Monitoreo en un producto descargable

Estuvimos trabajando en un par de ideas, tal vez obvias viéndolo en retrospectiva, pero queríamos compartirlas porque creemos que pueden ser de utilidad para muchos lectores emprendedores IT.


Solución de Monitoreo
En Libres Consultores construímos hace un tiempo el software "Solución de Monitoreo". Este es un datasheet de Marzo de 2014, detallando sus capacidades.

Es una integración de software opensource, básicamente Check_MK (con un core Nagios) sumandole addons propios, desarrollados por Libres, volcando su expertise particular en monitoring, para adaptar Solución de Monitoreo a requerimientos muy específicos de usuarios corporativos y organizacionales típicos de sistemas de monitoreo, y que no están cubiertos en una implementación Nagios + Check_MK estándar.

Solución de Monitoreo corre necesariamente en un servidor Linux por lo tanto la manera inicial de venderlo se reducía a la típica oferta de casi cualquier producto de servidor que requiriera una implementación medianamente compleja.


Proyecto de Producto Descargable
La segunda etapa de desarrollo de producto de Solución de Monitoreo comenzó con una idea sencilla "Convertir Solución de Monitoreo en un producto descargable", que como tal, un cliente pudiera descargar e instalar rápidamente, sin asistencia técnica directa, solo siguiendo un tutorial simple y corto.

El objetivo comercial es poder vender Solución de Monitoreo vía Internet, a cualquier ubicación geográfica dada, en principio apuntando a Argentina, luego podría ser LATAM, etc.

Poder vender lucrativamente un producto como este consiste en lograr trasladar el valor agregado y el expertise de Libres al cliente, de un modo muy rápido y que insuma la menor cantidad de tiempo posible de implementación para el cliente y de tiempo de soporte directo para Libres, permitiendonos así multiplicar nuestra capacidad de provisión del producto y servicios asociados, sin necesidad de incorporar - mayores y nuevos - costos a la operación y pudiendo abarcar un número - potencialmente alto - de nuevos clientes.

Claro que el potencial y el desarrollo del producto de software descargable abarca más temáticas, pero quiero volver a foco técnico de este problema: 

¿Cómo se podría convertir un producto que requiera una instalación/implementación compleja en un producto descargable?



Convirtiendo Solución de Monitoreo en producto descargable

Tuve mi primera inspiración visitando un posible cliente y allí volví a ver los "paquetes" de Turnkey Linux. Los había visto antes, tenía el sitio guardado en bookmarks, pero no había pensado en esto:

Lo que tenemos son básicamente son máquinas virtuales pre-configuradas, appliances virtuales con determinados valores por defecto (muy cercanos a los defaults de las aplicaciones), que se puede descargar e implementar en hipervisores y/o software de virtualización (VMWare ESXi, KVM, Virtualbox, VMWare Workstation, OpenVZ, etc.):

La clave para convertir un producto de servidor en un software descargable es poder instalarlo, configurarlo, agregarle el valor agregado, y dejarlo listo para usar > dentro de una máquina virtual. Necesitábamos crear un appliance virtual.

Y eso fue todo, en este punto del desarrollo como producto, "Solución de Monitoreo" tiene más que suficiente valor agregado superando las prestaciones de cualquier implementación genérica del software opensource base que usamos (Nagios + Check_MK), y por ende, integrarlo todo en un appliance virtual descargable era una primera iteración casi obvia, trivial de realizar desde el punto de vista técnico*. 

*No implica que el desarrollo del producto deje de requerir una infraestructura logístico-comercial para soportar la venta en línea con buenos resultados.



Appliance virtual para clientes sin hipervisores 
La segunda iteración del proyecto de producto descargable se dió recientemente, y estamos trabajando en esto aún. La noción base es la misma de antes, pero el escenario de implementación cambia: tenemos un cliente tipo que no tiene hipervisores, pero sí tiene servidores Linux. 

  • Además el hardware ya estaría en uso, por lo que los recursos disponibles son limitados.
  • Además, el sistema Linux estaría en producción, se usaría intensivamente y requeriría un cuidado y administración importantes, el cliente no querría instalar manualmente allí el stack completo componentes de Solución de Monitoreo, incluso si esa oferta estuviera disponible.
Docker 
Era necesario disponer de una opción que brindara la posibilidad de descargar y usar Solución de Monitoreo, directamente en un servidor Linux ya en producción, con los mismos beneficios prácticos del appliance virtual.

La solución fue usar contenedores de Linux, y automáticamente desaparece la mayor parte de los requerimientos de hardware (que eran necesarios para ejecutar el appliance virtual completo, incluyendo el sistema Linux base para Solución de Monitoreo). 

La resultante del I+D al momento es que vamos a armar un appliance de Solución de Monitoreo en un contenedor Docker. El contenedor Docker añade las características que necesitamos: gestión de recursos del appliance con cero necesidad de administración del software (que corre dentro del appliance), y un alto grado de compartimentalización, previniendo así que Solución de Monitoreo interactúe más que superficialmente con el sistema Linux base.

En esta instancia de desarrollo del producto estamos trabajando por estos días.

Gtalk: yacolinux@gmail.com

sábado, 26 de abril de 2014

El playbook de Libres Consultores en la Flisol de Resistencia

Contento por lo de hoy - 26-04-2014 - a la mañana en la Flisol de Resistencia, Chaco (UTN FRRE), estuve promoviendo el uso de software libre / opensource para potenciar el desarrollo de la industria IT local.

Básicamente estuve compartiendo el "playbook" de Libres Consultores.

El playbook de una empresa, el "libro de jugadas" es el know-how puro de cómo funciona la empresa, la manera de trabajar que le permite generar la actividad que le resulta económicamente rentable y le permite alcanzar sus objetivos económicos.

No es poca cosa y muchas empresas guardan su playbook bajo "siete llaves", sin embargo, en el caso puntual de Libres, es conveniente y recomendable compartirlo.


En la Flisol fui muy bien recibido por los chicos de la organización y compartimos la charla con un grupo chico, pero prestaron mucha atención - durante mucho tiempo! - en un tema más bien aburrido, comparado con temáticas técnicas puras (aprendí un par de cosas nuevas también, que van a terminar actualizando el playbook por cierto).

El material completo de la charla - el playbook de hecho - con explicaciones detalladas, incluído el cheatsheet original, ya quedó disponible en línea; estoy armando los pdf para el lunes. Links al final.
        
Espero que aporte a la posibilidad de generar una industria local en - Ctes. / Resistencia - de productores de software que provean no solo al extranjero, sino que aporten más software y sistemas a las organizaciones y empresas locales, a costos pagables, que les permita a esas organizaciones a la vez, volverse mejores en el logro de sus objetivos y partiendo desde ahí saldríamos todos beneficiados: las empresas crecen, hay más clientes y más empleo, y obviamente más empresas nuevas (nuevos productores de software por ejemplo).

Simplemente quería cerrar comentándoles la respuesta a la pregunta que más escuché respecto del material y el playbook:
- "¿Eso funciona?"
- Sí, funciona. Ya funcionó varias veces de hecho.


Links
Que les sea útil.

Sldos.

Libres Consultores
Dardo Valdez - ar.linkedin.com/in/dardovaldez/
Cel. 379-4316500
Skype: dardo_valdez

viernes, 25 de abril de 2014

Cómo vender software opensource - con Anotaciones


Este material contiene la información a compartir en charla+taller del sábado 26/04/2014 en la Flisol de Resistencia, Chaco (UTN FRRE, 11.00 hs.)

Update: 26-04 - 10.06 hs. - Versión Final

 * Evidentemente, no todo lo escrito va a poder ser volcado en el taller, pero este documento sirve de guía para el mismo, y a la vez de documentación.


Cómo vender software opensource
Versión: 26-04-2014


Comentarios Introductorios:

El principal problema de vender productos de software en el NEA es tener que desarrollarlo.

La capacidad de provisión de productos y servicios de la industria IT local no creció a la misma velocidad que los requerimientos de las organizaciones de la región, por ende hay una capacidad productiva faltante importante, por ejemplo hay muy pocas empresas y recursos humanos con experiencia en desarrollo de productos IT, casi no hay un ecosistema local de producción de software asentado (inversores locales de riesgo, empresas ángeles, etc.).

La producción local de software vendible con buen nivel de ganancias, tiene un costo elevado: sueldos, inversiones considerables, importantes tiempos de proyecto (no menores a semanas o meses).

Probablemente sea mayor aún el costo debido al lucro cesante* asumido no avanzar en otras inversiones potencialmente mucho mejores (más rentables, con un ciclo de negocio repetible con seguridad).

* Lucro cesante: es el dinero que no se gana por haber dedicado recursos - tiempo por ejemplo - a otra actividad (otro trabajo por ejemplo).

Producir localmente un producto de software de nivel empresarial que se pueda vender por 6 cifras (varias veces), si es que se consigue un cliente luego de producido, cuesta un estimado de AR$ 120.000 como mínimo* pero el producto no estará listo antes de un mes o dos. Y su rentabilidad depende de conseguir más de un cliente si es que lo vendemos por AR$ 120.000.

*3 sueldos moderados de AR$ 10k para 3 ingenieros con mucha experiencia, a ser pagados durantes 2 meses, con los ingenieros trabajando desde su casa a jornada completa (8 hs. por día, de lunes a viernes), completando 960 hs. totales disponibles para terminar el proyecto, antes de superar el presupuesto o antes de que se termine la plata de la inversión, y no se pueda terminar el proyecto.

Incluso, luego de 960 hs. de trabajo, muchos proyectos no logran siquiera vender una copia del producto mínimo, o llegar a tener un producto mínimo para vender. Ni hablar del producto terminado.

Invertir en remises
En cambio, invertir AR$ 120.000 (o mucho menos en caso de usados), en la compra y puesta en producción de un vehículo 0 km. para hacerlo trabajar de remise, empieza a devolver la inversión casi de inmediato y comparativamente con invertir en desarrollo de software, la ganancia está prácticamente asegurada.

Fiat Siena El 0km Plan Nacional Fiat Especial Taxi Remís (a) - $ 105.750

Fiat Siena El 0km Plan Nacional Fiat Especial Taxi Remís(lm) - $ 100.850


Invertir en outsourcing de tecnología de la información (ITO)
Y no nos olvidemos del ratio de ganancias de hacer outsourcing de servicios IT: a 50-150 U$S la hora de trabajo*, cobrables inclusive durante el trabajo, de acuerdo al progreso logrado, se cubre en exceso el costo de sueldos de 3 ingenieros, y se tiene garantizada una ganancia al término de las horas del proyecto.

* Dados U$S 50 de costo por hora de outsourcing - a cotización de AR$ 8 = AR$ 400 por hora, a 160 hs. mensuales de trabajo, un ingeniero dedicado genera unos AR$ 64.000 totales, 54.000 pesos adicionales - la ganancia del inversor - a su costo en sueldo. En realidad, ni siquiera hay inversión, el ingeniero se paga a su propio trabajo. El "inversor" realidad solo necesita conseguir clientes en el extranjero.

* Dados U$S 8* por hora de outsourcing - a cotización de AR$ 8 = AR$ 64 por hora, a 160 hs. mensuales, se genera unos AR$ 10.240, y el costo del ingeniero - el sueldo - sigue estando cubierto.

Ecosistema local
Los productos y servicios IT locales son escasos y por lo tanto sus precios son altos, están en gral. muy arriba del precio de equilibrio del mercado local.

Otras inversiones son mucho mejores - inclusive en IT, debido a la oportunidad de negocios del outsourcing - y casi certeza, mucho más rentables.

En conjunto, es bastante difícil generar un ecosistema local favorable a la inversión privada en desarrollo de software para la venta en el mercado local, y mucho más difícil promover la inversión en creación de productos de software.


Sub-abastecimiento local de tecnología de la información
Por lo anterior, las organizaciones en gral. están sub-abastecidas de productos y servicios IT, porque estarían obligadas a pagar software a altos precios en dólares o altos precios en pesos, así que funcionan con el mínimo indispensable de software e infraestructura IT.

No es una situación local, sino nacional en Argentina:


La Argentina, en el puesto 100 del índice que mide el estado tecnológico mundial

"El índice compara la infraestructura de tecnologías de la información disponible en un país; el costo de acceso a la misma; su uso por parte de los gobiernos, empresas y ciudadanos; el marco político; el entorno empresarial; y el impacto de las tecnologías de la información en la economía y la sociedad.

Y destaca el desafío que enfrenta la región, que debe mejorar su infraestructura tecnológica todavía más para estar más cerca del resto, y evitar una nueva brecha digital entre los países que están viendo el impacto positivo de la tecnología en su sociedad y economía, y los que no están logrando hacerlo."


http://www.lanacion.com.ar/1684886-la-argentina-en-el-puesto-100-segun-un-indice-que-mide-el-estado-tecnologico


Hay un problema para resolver, es decir, una oportunidad

Existen importantes oportunidades de negocios si se puede proveer productos y servicios IT de alto nivel y calidad, a precios competitivos, en pesos, a precio de equilibrio del mercado (mucho más bajos que la media de la zona), y más bajos que el promedio de precios en dólares para software fabricado en el exterior del país.

Al proveer productos IT a precios competitivos, está la posibilidad de que muchas empresas y organizaciones de la región, que hoy no son prospectos de clientes para los actuales proveedores locales y otros, se vuelvan efectivamente clientes frecuentes.

Dada una organización cualquiera, una vez que se introduce correctamente un buen nivel productos IT y su infraestructura IT, y esto empieza a generar mejoras útiles, que se materializan en mayores ganancias y/o en mejor gestión de la organización, la infraestructura tiende a crecer naturalmente, y el presupuesto destinada a esta también.




Inicio del Taller

En el taller se aplicará el cheatsheet para diseño rápido y venta de productos basados en software opensource.



Nociones de desarrollo de productos IT de software:

- Se desarrolla un producto siempre intentando agregarle mayor valor para el cliente.
    - Por ejemplo, si el producto es difícil de instalar manualmente, se apunta a automatizar la instalación, pero, si los clientes nunca van a instalar por sí mismos el producto, la automatización no tendría valor adicional alguno para el cliente.
    - El valor del valor agregado depende de lo que opina y necesita el cliente.

- VAR de software
    - Qué es un VAR de tecnología de la información

- Consultoría vs. productos
    - Es más fácil vender un producto "tangible" que una idea "vaporosa".

- Desarrollo a medida vs. productos
    - El desarrollo a medida no es un proceso repetible
    - Los productos implican procesos repetibles,
        - tanto para el producto,
        - como para el negocio.

- Desarrollo de productos con software opensource
    - Se trata de intentar mejorar algo que ya funciona bien
        - "Lograr crear una mejor rueda, no reinventarla"
        - Si no se logra, no importa, el software ya funciona bien.

- Recursos disponibles y costos
    - Tenemos tiempo para producir "algo"?
    - Qué hace falta para hacerlo? Lo tenemos?
    - Si el costo es pagable o los recursos se pueden gastar en ese "algo",
        ¿Qué es lo que se obtiene?


Lo indispensable para poder vender un producto es tenerlo listo, terminado y funcionando. 
En la región en particular, no se puede vender un proyecto en papel, nadie compra ningún software del cual no puedan ver una demostración en vivo y en directo.

Generar un producto mínimo* es indispensable, así que lo necesario es llegar a delinear un producto, no necesariamente la máxima expresión de nuestra idea de cómo va a ser el producto, pero sí hace falta ensamblar el software de modo tal de poder cubrir requerimientos de un potencial cliente, de resolver con el producto un problema de este cliente.

*Producto Mínimo Viable:

Armar un producto IT para vender conlleva agregar diversas características y prestaciones útiles alrededor del relativamente simple software que será el núcleo del producto.



Beneficios de vender software opensource

    - Usar software ya desarrollado, testeado, incluso ya a la venta
    - Asociación de Marca

    - Siendo soft opensource se vende:

            - Consultoría, soporte, capacitación
            - Implementaciones particulares (paquetes pre-armados, implantación en entornos no estándares)
             - Suscripciones para actualización constante del software
           - Suscripciones para usar el soft vía SaaS (software como servicio en la nube)
            - Contrataciones particulares para extender el soft para que soporte determinadas características y/o nuevas funcionalidades.

    - Se aprovecha la experiencia colectiva de la comunidad, recetas técnicas (howtos), documentación oficial

    - La calidad del software ya desarrollado y con años de desarrollo+testing en entornos en producción es inevitablemente superior a cualquier desarrollo propio de pocas semanas o meses, incluso en producción.

    - Las opciones - y sus capacidades - disponibles desde el minuto 1 del inicio del desarrollo del producto son X - medidas en decenas, centenas o millares - mientras que las de un desarrollo propio son mucho más acotadas en capacidades y en número.

    - Etc.


Comentario:
El problema de desarrollar software para organizaciones es que hay muchos requerimientos para satisfacer, el software tiende a requerir importantes tiempos de proyecto, semanas, meses, incluso años. Implica que hace falta muchos recursos y una inversión inicial grande, sin retorno de inversión claro a corto plazo.

Usar software opensource que ya está desarrollado quita el obstáculo de largos períodos de desarrollo y el requerimiento de grandes inversiones en recursos.



Buscar el Problema a solucionar

     - Target de clientes

        - Vender a usuarios finales

        - Vender a empresas

     - Contexto y necesidades locales

         - Software interesante, para propulsar el I+D interno

         - Software que nadie más vende

Comentario:
En este ítem decidimos a qué clase, categoría, tipo de cliente se va a apuntar. En gral. siempre hablamos de elegir un tipo de comercio al cual se va a proveer un software que le va a resultar de utilidad para resolver un problema que están teniendo.

En este punto repasamos algunas cuestiones locales obvias: los altos precios de productos y servicios IT de los últimos años han dejado muchas organizaciones con poca infraestructura IT, con el mínimo, así que el potencial es grande en muchas áreas.

Es necesario además, elegir software que nos va a resultar interesante estudiar, aprender a configurar, usar, personalizar y posiblemente extender. De esa manera, llegado el momento, el indispensable interés personal en investigar y probar no va a estar ausente.

Una importante ventaja competitiva se logra simplemente eligiendo desarrollar un producto de software que nadie más esté vendiendo en la región. Ello es relativamente simple, por la ya mencionada escasa informatización de las organizaciones.



Investigación y Desarrollo

     - Recursos disponibles para el desarrollo del producto

     - Buscar el software que solucione el Problema

     - Extraer requerimientos de clientes

     - Workflow

        - Herramientas

        - Usar versiones estables

        - Se justifica o no usar versiones de desarrollo (NO inestables)

            - Características avanzadas necesarias

     - Instalar, configurar el software

     - Determinar Características Clave del software

     - Comparar características clave con requerimientos del cliente

         - Si hay pocas diferencias entre los requerimientos del cliente y las características clave, desarrollar el producto.

         - Si hay muchas diferencias, descartar y volver buscar un problema para solucionar.


Comentarios:

Investigación y Desarrollo:

Los recursos disponibles son importantes, antes de iniciar las tareas de I+D hace falta ver si están a nuestro alcance o no. En gral. la mayoría de las PCs medianamente potentes de los últimos años permiten manejar los requerimientos típicos de un laboratorio de pruebas de software: espacio en disco rígido, capacidad apropiada de CPU/procesador y memoria ram para poder ejecutar el software, e incluso, sin mayores problemas, la posibilidad de trabajar con máquinas virtuales para crear entornos del software completos, virtualizados, y así poder flexibilidad la forma de trabajar para el desarrollo del producto.

Una primer instancia hacia lograr el resultado de generar un producto IT vendible es averigüar qué uso van a darle los potenciales clientes, aproximarnos a cual o cuales son los problemas específicos y puntuales que el cliente necesita resolver mediante funcionalidades y/o características del software. Para esto hay que investigar el tipo de organización donde se instalará el software, el tipo de usuarios que lo van a usar, quienes van a administrar el software si fuera de mantenimiento complejo, etc.

Luego de obtenidas mínimas nociones al menos de lo anterior necesitamos establecer una mecánica de trabajo, esta mecánica va a generar iterativamente los resultados de la investigación y desarrollo del producto, hasta que logremos generar un producto que podamos llevar al mercado.

En principio, se buscará la información necesario que permita instalar y configurar básicamente al menos el software elegido, ya en esta instancia vamos a evaluar qué tan flexible o no es el software en sí, qué tantos requerimientos de hardware y contextos de software hay que cumplir para que pueda realizar bien sus funciones.

Luego de instalado el software elegido, hay que comparar las prestaciones que ofrece, las posibilidades de estas prestaciones, si son buenas, regulares, o exceden lo que los clientes van a pedir que pueda hacer el software cuando esté instalado.

De la información que se obtenga depende la decisión de continuar o no utilizando ese software en las siguientes etapas de desarrollo del producto.



I+D con Interacciones Interesantes

    - Registrar paso a paso todos los datos de la I+D

    - Muy Alto Valor potencial en resultados de I+D con usos múltiples

    - Evaluar tecnologías nuevas al desarrollar el I+D

    - Proveer un pool de posibles soluciones a problemas aún no definidos

        - Posible Solución: se define como aquella tecnología que dados los Recursos Disponibles, podríamos desarrollar como futuros productos.

Comentarios:
La investigación y desarrollo del producto va entregar un cúmulo creciente de información en bruto: links, documentación pre-armada (pdfs, etc.), instrucciones paso a paso para realizar diferentes tareas, estimaciones de tiempos necesarios, etc. 

Es vital registrar ordenadamente toda la información que resulte de interés, y documentar los procedimientos paso a paso según se vaya progresando en las tareas.

Otra resultante del I+D es el contacto con nueva tecnología, que antes no se conocía y cuyo manejo es necesario para poder implementar el software elegido.

Por ejemplo, si el software usa scripts Perl, una tecnología a manejar, al menos mínimamente es familiarizarse con scripting perl, entender cómo se satisfacen sus requerimientos (configurando vía MCPAN por ejemplo). Lo mismo se puede decir de las configuraciones típicas de los entornos donde correrá el software: hace falta configurar runtimes, servidores web, ftp, instalar paquetes de linux, instalar paquetes de componentes de lenguajes (Ruby, Python,etc), instalar y configurar bases de datos (MySQL, Postgresql, etc.), etc.

Ese conocimiento de base de tecnologías accesorias nos va a permitir desarrollar nuevos productos y nuevas capacidades técnicas en la siguiente iteración del ciclo productivo.



Desarrollo inicial - producto mínimo    

     - Marca

         - Marca de Empresa vs. Marca de Producto
         - No ponerle nombre al producto (todavía)
             - Evitar la asociación de marca a un prototipo

   - Fundamento del producto mínimo: Software Opensource + Valor Agregado (VA)

      - Configuración básica estándar
      - VA mínimo
      - Definir el VA: Consultoría,Soporte,Garantía,Capacitación,Características Diferenciadoras

     - Marketing inicial

         - Canales de información (Blog, Mail, Mensajería)
         - Presencia en línea (Fcbk, Twitter, Google Plus)
         - Presencia: updates cortos, diarios, anuncios

     - Recursos Disponibles: evaluación de Costos y Precios


Comentarios:
El desarrollo inicial de un producto de tecnología de la información, un producto IT, basado en el ensamble de software opensource con características y prestaciones que dan valor agregado implica diversas tareas.

Tenemos que ponerle un nombre al producto, dándole a los clientes potenciales un modo de distinguir el mero software opensource de nuestro producto en oferta, que consiste en el soft opensource y además suma el valor agregado (VA).

Tenemos un problema durante el desarrollo del producto mínimo: no tendrá el total de Valor Agregado que tendrá el producto final. Si ahora mismo lo nombramos, le podríamos quitar valor a la marca, asociandola con un producto menos potente - el producto mínimo - que el producto final que estará disponible al final del desarrollo del producto.

La alternativa es generar una marca, pero asociada al productor del producto, a la empresa que está desarrollando el producto, y reservar el nombre de la marca del producto final para el momento en que el mismo esté terminado.


El valor agregado del software opensource - ya desarrollado, probado, documentado, etc. - está dado por lo que el revendedor del software puede proveer: consultoría de diseño e implementación de la solución técnica, soporte técnico, garantía de la implementación realizada y capacitación en el uso de la herramienta.

Un valor adicional puede estar dado por la incorporación de nuevas características al software, este VA debe manejarse con cautela, debido a que a la vez incrementa la carga de trabajo considerablemente para el revendedor. La relación costo-beneficio de proveer o no nuevas características se debe analizar en detalle.

El producto mínimo va a estar formado también por requerimientos de entorno (qué hardware es necesario como mínimo), configuración, instalación e implementación estándar, repetible y totalmente documentada, del software.

Esto implica que los recursos a invertir en su venta estarán minimizados: tiempos de diseño (cero o casi),implementación (puede ser casi cero, con automatización vía scripting por ejemplo), mínimos tiempos a dedicar a soporte (en una instalación modelo, no debería haber imprevistos en gral.), y en garantía (una instalación modelo no va a fallar o va a fallar de modos previsibles, fáciles y rápidos de resolver); la capacitación va a estar totalmente limitada a un conjunto mínimo de características que son el núcleo de la oferta del producto: las características que el cliente va a utilizar, y ninguna adicional a ellas.

Una vez delineado y probado el producto mínimo, es necesario iniciar la difusión de la oferta, los medios típicos que atiende el potencial cliente objetivo típico siempre va a estar dado en alguna medida por los actuales medios de comunicación vía Internet. Los medios tradicionales: radios, televisión, diarios y revistas, en gral. no tienen la capacidad de llegar a los potenciales compradores de productos IT en la región NEA.

Es necesario crear una imagen en línea que se va a asociar en principio a los productores del producto y en segundo término al producto en sí (recordar la opción que tenemos al trabajar con productos mínimos).

La siguiente etapa es indispensable: hay buscar la validación del producto mínimo. Si no se puede validar el producto, es mandatorio suspender el progreso del desarrollo del producto.



Validación

         - Intentar venta a clientes y/o implantación a usuarios tempranos (early adopters)

             - Venta por anticipado: vender antes que el producto esté listo

         - Extraer información sobre satisfacción de requerimientos

    - Definir la oferta
        - Forma de venta del producto
        - Forma de pago del producto
            - Factura
            - Contrato
        - Precio
            - Precio de Equilibrio

    - Marketing
        - Lanzamiento Silencioso
        - Contactos proactivos
            - Elegir Audiencia correcta: Decision Makers, Purchasing Power
            - CapEx vs. OpEx

    - Si no hay validación, es un riesgo seguir. Es recomendable no continuar, esperar próximas oportunidades de validación y desarrollar un nuevo producto mínimo.

    - Recursos Disponibles: evaluación de Costos y Precios


Comentarios:

Apreciar: "Determinar de manera aproximada el valor de algo."

Oferta y Precios
Con el producto mínimo listo, tenemos que buscar implementarlo en la vida real, intentar venderlo a clientes reales que quieran pagar por él. La venta por anticipado, se puede iniciar en la etapa de marketing inicial, comentando, si es posible demostrando capacidades del producto.

Los clientes que adoptan primero el producto son lo más importante luego del producto en sí: le van a proveer a la empresa la información precisa y real de cuales son los requerimientos que va a tener que resolver el producto. Si alguno de esos requerimientos no está cubierto, se puede ampliar la I+D para completarlo. Si no se puede completar, el producto no va a tener esa característica y hay que prever esa dificultad.

Definir la oferta es muy importante, y depende de cómo se va a vender el producto. En productos IT de alto nivel, es habitual la necesidad de un contacto previo con el cliente, donde se recibirá información básica de los requerimientos del proyecto que quiere encarar el cliente: cómo usará el producto, cómo lo implementará, cuando, con qué nivel de dificultad, etc.


Así llegamos a cómo definir la oferta: en gral. el precio del producto IT debería tener un costo fijo; pero se puede ajustar según el nivel de dificultad del proyecto y la responsabilidad encarada en él a nivel de consultoría.


Otros ítems a apreciar son
- Garantía (se incluye en el precio del producto, tiene que definirse en un plazo concreto de tiempo, durante el cual estará disponible implícitamente tanto la consultoría como el soporte técnico), 

- Soporte técnico (resolver problemas relacionados con imprevistos ocurridos en la implementación ya terminada), y

- Capacitación.

En gral. un producto típico complejo incluye una mínima capacitación de operación, en gral. hablamos de 2 a 5 horas, demostrando y enseñando cómo operar el producto en el día a día.

Depende mucho de los requerimientos del cliente la apreciación de la capacitación intensiva, que implica posiblemente: diseño de la solución, implementación del software, operación avanzada del software, y resolución de problemas.


El precio de equilibrio* del mercado de un producto de software está siempre ligeramente por debajo del precio promedio del costo de varias herramientas similares: básicamente es el precio del producto incompleto más barato del mercado, más un adicional mínimo que los clientes estarían dispuestos a pagar para que tuviera disponibles funciones adicionales que lo completarían para sus requerimientos.

* Precio de equilibrio

La "completitud" no se define de ninguna manera como el total de las características del software más potente en el mercado, sino como el total de características mínimas que satisfacen los requerimientos de las organizaciones que son nuestro target de cliente.

De todos modos, ellos no querrían pagar más por características avanzadas que no van a usar.


Marketing
El marketing del producto de software opensource puede realizarse siguiendo las metodologías clásicas de publicidad para productos manufacturados, pero, es mejor si se adapta las estrategias a las particularides del diseño de la producción del producto (mínimo en esta etapa), algunas técnicas típicas son

- El lanzamiento silencioso, terminado el producto mínimo se inicia su comercialización, sin iniciar la publicidad de ese hecho
- Contactos proactivos, es vital sea que se elija o no realizar un lanzamiento silencioso, el realizar contacto con potenciales clientes. La forma de venta habitual de software nunca se realiza en el sentido cliente > vendedor, sino al revés, al estilo de transacciones B2B*.

B2B = "Business to Business", negocios entre empresas, a diferencia de B2C, "business to consumer", ventas a consumidor final.
http://en.wikipedia.org/wiki/Business-to-business
http://en.wikipedia.org/wiki/Business-to-consumer


Hay que elegir la audiencia correcta para realizar el contacto proactivo: si se le vende a empresas, contactar a los responsables encargados de decidir en qué se gasta el presupuesto de la organización.


CapEx vs. OpEx

CapEx:

OpEx:

CapEx son gastos grandes, inversiones de capital que realiza una empresa, en gral. son grandes gastos relacionados con necesidades de "una sola vez". Por ejemplo, la compra de un camión para reparto.

OpEx son gastos, que si bien pueden ser relativamente importantes, no lo son en gral., esos gastos están relacionados con el costo - relativamente estático - de mantener funcionando la empresa / organización. Por ejemplo, el pago de las facturas de servicios, del alquiler de locales, etc.

Los prepuestos de OpEx son limitados en gral., pero flexibles (mucho más que flexibles que los CapEx, porque los costos pueden evolucionar), y por normativa típica, suele haber un exceso de OpEx preparado para absorber nuevos gastos necesarios o costos más altos que lo previsto.


Si al momento de vender el producto de software, se lo puede encuadrar en precio dentro de un gasto manejado vía presupuestos de OpEx, la probabilidad de lograr una venta crece. A la vez, los precios definidos para el producto de software, no podrán ser demasiado altos, pero si lo fueran, se podría escalonar la oferta de tal modo que el pago se realice en cuotas, en varias etapas/partes (un precio por implantar el software, otro por consultoría, otro por capacitación, etc.), permitiendo así que el costo total del producto sea absorbido por el cliente vía OpEx.

En contraste, la mayoría de los productos de software que se adquiere en el NEA requiere de prespuestos CapEx, que son mucho más difíciles de conseguir, ya que hay que justificar el retiro de capital de las ganancias previstas (en empresas con fines de lucro), o de los presupuestos ya asignados (en organizaciones sin fines de lucro), para destinarlo a un (nuevo), gasto. Además, debido a las cuantiosas inversiones típicamente necesarias, el pago del precio se suele solicitar en un solo pago por el total.





Desarrollo de producto

    - Nombre

    - Material de promoción y propaganda

    - Plan de marketing inicial (incluye canales de contacto)
        - Canales de información (Blog, Mail, Mensajería, Teléfonos)
        - Presencia en línea (Fcbk, Twitter, Google Plus)
        - Canales: Artículos generales, información sobre la evolución del producto
        - Presencia: updates cortos, diarios, anuncios

    - Recursos Disponibles: evaluación de Costos y Precios


Comentarios:
Hay que ponerle un nombre al producto, para distinguirlo del software opensource utilizado como base; en base al nombre hay que armar material de promoción.

En gral. un simple archivo .pdf detallando de qué se trata y cómo funciona el producto será más que suficiente para iniciar el contacto proactivo con futuros posibles clientes. Una página web detallando el producto también puede ser recomendable.

El diseño e implementación de sitios completos destinados a presentar la oferta en Internet se reserva para los productores que cuenten con recursos propios y que no le resulte costoso, de modo tal de no encarecer artificialmente el costo del producto final (de todos las páginas de presentación solo sirven para guardar los archivos con información detallada de los productos, qué es lo que los potenciales clientes suelen buscar).

En relación con los lanzamientos silenciosos, los datos anteriores no se podrían a disposición del público en gral., sino solo para los potenciales clientes.

El plan de marketing completo implica la extensión del plan inicial de mercadeo, extendiendo la presencia en línea con mayor contenido relacionado directa y/o indirectamente al producto.

El contacto telefónico directo es muchas veces la opción de promoción más fuerte (dada una adecuada estructuración del mensaje que se pretende transmitir en el contacto con el posible cliente), pero hay que disponer de los teléfonos de los posibles clientes.

Mantener la actividad en línea y elevar la provisión de información, ya en este punto, directamente relacionada con el producto en oferta, es mandatorio.

La presencia constante proyecta el tipo de imagen precisa de productores estables y disponibles, que es no solo apreciada por los potenciales clientes, sino necesaria para poder acceder a niveles de valoración subjetiva en cuanto a estabilidad, compromiso con el cliente, compromisos a largo plazo y otras variables no relacionadas con lo técnico, pero muy importantes en la decisión final de avanzar o no en la adquisición de un producto de software.

Esa imagen proyectada debe estar plenamente respaldada en la práctica por un Valor Agregado consistente y efectivo en resolver los problemas del cliente.



Desarrollo del valor agregado (VA)

     - Consultoría
        - Integración del software opensource
        - Consultoría inicial
        - Diseño de la solución
        - Implementación de la solución

     - Soporte

     - Garantía

     - Capacitación

     - Documentación

     - Características Diferenciadoras

     - Recursos Disponibles: evaluación de Costos y Precios


Comentarios:

Valor Agregado
El Valor Agregado es la etapa más simple de emprender, sin embargo es la más importante para el potencial cliente que adquiere un producto basado en software opensource: si el software se puede descargar y usar sin costos, el Valor Agregado provisto por el productor es el 100% de la motivación para pagar un precio por la adquisición de ese software, para incorporarlo a la infraestructura informática de la organización.

El componente básico de Valor Agregado del producto basado en software opensource es la integración del software, el expertise del productor, sistematizado de modo tal que permite instalar, configurar e implementar el software opensource de modo tal que esté orientado y ajustado a los requerimientos de los clientes.

Por ejemplo, si el requerimiento es una rápida instalación, el valor agregado implícito en la integración se podría materializar en scripts y/o recetas que permitan automatizar la instalación compleja del software opensource.


Consultoría
La consultoría implica dos componentes, una componente es la consultoría inicial, que se realiza en forma gratuita, intentando proveerla sin que el cliente lo requiera, de este modo se lo puede aconsejar en cuanto a lo que podría ser la solución a sus problemas, en principio, ofertando el producto; pero - muy importante - si el producto propio no ofrece la solución total que el cliente busca es clave explicarle cuales son sus limitaciones y capacidades efectivas concretas.

Si el producto finalmente no puede satisfacer los requerimientos del cliente, hay que asesorarlo y explicarlo en forma clara y directa.

La consultoría de diseño e implementación de la solución es un servicio, componente del valor agregado del producto. En un primer contacto, adicional a la orientación general de la consultoría inicial, si ya se cuenta con los requerimientos del cliente, se podría ofrecer un diseño gral. de solución basado en el producto, sin realizar la implementación. Llegado el momento en que el cliente adquiere, compra efectivamente la consultoría, se procede a documentar el diseño, traspasar esa información al cliente y preparar el proyecto de implementación del producto.


Soporte
El soporte técnico del producto es la actividad por la cual el productor le brinda ayuda al cliente cuando el producto falla en condiciones normales de uso, cuando debería haber funcionado bien, y no lo hizo. En el caso de software complejo, muchas veces se encuentra que la causa es ajena al producto mismo, sin embargo el soporte permitirá colaborar con el cliente para detectar la causa real.

En caso de falla del producto, el soporte se encargará de buscar la solución a la cuestión planteada por el problema. En gral., dado un producto de software apropiadamente delineado y especificadas, probadas, testeadas esas funciones ofrecidas, los fallos en gral. son mínimos*

* Esta última característica es intrínseca al desarrollo del producto, y es una de las características más pertinentes a dar a publicidad en el marketing.

y - por múltiples razones técnicas, metodológicas y organizacionales de proyecto - NO tienden a producirse con la misma frecuencia y gravedad con que ocurren en el desarrollo de software a medida.


La forma habitual de ofrecer soporte es mediante correo electrónico, chat por mensajería instantánea y por teléfono. La forma de apreciar el nivel de soporte está dado por los tiempos de respuesta y por la disponibilidad horaria en la que se ofrezca el servicio de soporte.


Garantía
La garantía de un producto es un requisito legal y un requisito práctico requerido por los clientes. En la práctica el productor se hace cargo del costo del producto que no funciona, en gral. devolviendo el precio pagado por el cliente al recibir un producto que no funciona como se especificó en la oferta.

"GARANTÍAS

¿Cómo opera la garantía cuando falla un producto?
La garantía comienza a operar desde que se adquiere el producto y ante un defecto o mal funcionamiento. Para los productos nuevos el plazo de garantía es de seis meses, y para los usados de tres meses."

Fuente:


Capacitación
La capacitación implica también dos componentes mínimos: una capacitación básica en operación del producto, normalmente se incluye dentro del precio básico de adquisición del producto. Otro tipo de capacitación en operación avanzada del producto, en diseño e implementación de soluciones basadas en el producto, pueden ser desarrolladas dependiendo del productor.


Documentación
La documentación constituye un valor agregado importante en el software opensource, ya que típicamente para un software opensource viable de utilizar en el desarrollo de un producto, el cúmulo de información respecto a cómo se utiliza, cómo se implementa, cómo se puede extender el software, es muy importante, superando la mera documentación de uso e implementación disponible para el software comercial de licencia propietaria.

El Valor Agregado más importante que brinda la documentación es que le brinda la libertad de elegir nuevos proveedores del mismo producto al cliente. Aunque parezca contraintuitivo, es una característica favorable a la venta del producto.


Características Diferenciadoras
La capacidad de extender el software opensource le brinda al productor la posibilidad de poder extender sus capacidades técnicas. En gral. siempre se busca incorporar exclusivamente los requerimientos más solicitados y valiosos para los clientes actuales, que son la medida real práctica de cuan efectivo podría ser el producto de software en resolver problemas para potenciales nuevos clientes.



Iteración

      - Streamlining de Producto (Software y VA)

          - Software:
              - Versiones del producto
              - Características mínimas, medias y máximas (CMMM) a proveer
                  - Define subproductos

          - VA
              - Consultoría: CMMM
              - Soporte: CMMM
              - Garantía: CMMM

    - Mejoras al software opensource (estudiar updates, upgrades, aplicabilidad)

    - Mejoras al VA (más/menos Consultoría,Soporte,Carac. Difer.)

      - Recursos Disponibles: evaluación de Costos y Precios

    - Refinamiento de material de promoción y propaganda

      - Refinamiento de plan de marketing


Comentarios:

Streamlining:  "Hacer algo más aerodinámico." (en un avión por ejemplo, permite que vuele mejor, que gaste menos combustible, se deteriore más lentamente, etc.)

La iteración en el desarrollo de un producto implica el análisis del alineamiento de las prestaciones del producto con los requerimientos de los clientes, del mercado, y con su potencial para ampliar la cantidad de potenciales clientes.

En un producto de software basado en código opensource vamos a encontrarnos en gral. con decenas, centenares a miles de características técnicas disponibles, de las cuales solo una fracción son de interés para nuestros clientes. Lo mismo ocurre con el Valor Agregado, de todo lo es económicamente viable de ofrecer como VA de parte del productor, al cliente solo le interesa en gral. un subconjunto específico de prestaciones.

El trabajo de streamlining del producto consiste en aprovechar el conocimiento adquirido de los clientes en las etapas anteriores para limitar el desarrollo del producto de software a las características técnicas y valores agregados que son de interés para los clientes.

En general, dado un conocimiento - know-how - muy detallado y refinado de los requerimientos y necesidades de los clientes se puede redefinir el producto de modo tal de disponer de niveles de prestaciones: mínimas, medias y máximas.

Asimismo, en gral. ello implica diferentes costos de producción para el producto, según su nivel de prestaciones, lo que permite re-optimizar los precios, bajándolos en gral., y aún así manteniendo la rentabilidad.

The secret to how Amazon funds its low prices

La mismas nociones de prestaciones mínimas, medias y máximas pueden aplicarse en la iteración del diseño del valor agregado del producto.


Las mejoras efectivas incrementales al software y al valor agregado, no derivadas de reducciones, incrementos ni redefiniciones basadas niveles de prestaciones, constituyen el fundamento para crecimiento del producto y su potencial de rentabilidad para el productor.

Dado el uso de software opensource, y los niveles incrementales de mejoras típicos de los proyectos activos, el productor puede esperar poder disponer de un número importante de mejoras implícitas al software y del agregado de nuevas funciones y capacidades, incluso radicales, que le permitirán poder ofrecer nuevas versiones del producto de software muy mejoradas respecto a las anteriores.


Es necesario por supuesto mantener actualizada la campaña de marketing contínua respecto de las tareas de investigación y desarrollo, y con más énfasis, cuando el producto va a obtener una mejora incremental.



Opensource

    - Modificaciones al código deben (deberían) ser publicadas
    - No publicar código sin documentar
    - El código publicado es un representante no oficial de la empresa


Comentarios:
El título anterior nos lleva a contemplar que la explotación del software opensource como recurso básico de producción va a llevar en algún momento a que el productor tenga capacidad de retribuir al proyecto de código opensource o a los componentes de software opensource que forman su producto.

Es necesario prever que algunas cuestiones no son optativas, aunque en la práctica muchos productores elijan no publicar sus mejoras al código fuente por ejemplo, en realidad es un requerimiento de muchas licencias de código opensource (aunque no de todas, por ejemplo, la licencia BSD).

Sin embargo, colaborar e interactuar activamente con las comunidades que desarrollan el software opensource base de los productos siempre tiende a devolver un rédito económico para el productor, incluso aunque se comparta activos aparentemente muy valiosos, por ejemplo, código fuente desarrollado que extiende las capacidades del software opensource.

Es muy importante entender el modelo de negocios del producto de software opensource sin componentes de código fuente propietario; el producto adquiere su valor directamente del Valor Agregado que provee el productor, no del código fuente abierto, libremente disponible para el público en gral., incluídos los clientes.



Primeras Ventas

     - Clientes

     - Marketing de promoción y propaganda

     - Mejora Contínua

         - Iterar de vuelta


Comentarios
El contacto inicial con los cliente tempranos, que adoptan el producto mínimo, permite continuar el desarrollo del producto hasta alcanzar la madurez apropiada para el inicio de la producción masiva.

Las primeras ventas del producto terminado van a terminar de delinear el mercado objetivo real del producto ya terminado. Ello implicará reajustar las tareas de promoción y propaganda del producto.

La mejora contínua en este punto implica la repetición regular de la Iteración del desarrollo, para asegurar la permanente alineación del producto de software con la mayor expectativa de rentabilidad para el productor.



Evolución y expansión del producto

    - Marketing de Sostenimiento

        - Publicidad presencial: Eventos, Charlas, Presentaciones Privadas
        - Contactos Proactivos

    - Información para determinar nuevos Problemas

    - Investigación para nuevos productos


Comentarios:
La evolución del producto implica componentes obvias y la continuación de las actividades de promoción para realizar nuevas ventas.

En la adquisición de nuevos clientes está implícito el potencial de obtener la información de Otros Problemas - factibles de resolver mediante software - que puedan tener los clientes sin resolver, y esos problemas son el punto de partida para el inicio de nuevos desarrollos de productos de software.



Links de soporte

"Diseño rápido y venta de soluciones basadas en Software Libre"
del sábado 26 en la Flisol de Resistencia - UTN FRRE (11.00 hs.)

Playbook: Cómo vender software opensource

Compartir el Playbook (libro de jugadas)

Qué es un VAR de tecnología de la información

La caché III: La caché de código

La caché II: El buffer

La caché I: La carreta sin caballo

Demostración de Conceptos


Externos

"Why Blacksmiths are Better at Startups than You"

"How to Build a Thriving Startup Ecosystem"

"The products that exist suck so much, there is endless opportunity."

"7 Step Process to Repeat Success"

"Creativity can be routinized, if you don’t believe that — see the coffee-induced brainstorming process Jony Ive, Steve Jobs and the Apple design team has used over the past 20 years giving birth to the iMac, the iPod, the iPhone, and the iPad."


"Start by Building and Selling Small Products"

"Jony Ive’s Secret Coffee Ritual"

"How To Charge Money For Things That Don't Exist Yet"
  

"7 ways I’ve almost killed FreshBooks"

"The different kinds of money"