viernes, 11 de noviembre de 2011

Organizaciones R&D en Software: Quién hace qué en una empresa de software

¿Quién hace qué en una empresa de software?[1]


Se necesita una aldea para criar a un niño, y ocupan muchos roles profesionales hacer una compañía de software con éxito, o para traer un producto de software con éxito en el mercado. En las empresas más pequeñas, usted encontrará que las personas puedan usar muchos sombreros (muchas tareas por cada persona). En una sociedad de dos, el arquitecto de producto, programador jefe, director general y el equipo de marketing de todo pueden ser casi con seguridad las mismas personas. He aquí un resumen rápido de las funciones principales que podría ver en una organización típica del software. La mayoría de las compañías de software tienen las personas que efectivamente realizan más de una de estas funciones. Sólo las empresas más grandes tienen distintas posiciones de trabajo para cada uno de las funciones descritas en la Tabla 1.

Tabla 1. ¿Quién hace qué en una empresa de software?
Rol
Descripción
Director general (Chief Executive Officer):

Papel: ejecutivo responsable por el éxito comercial de la empresa.
Antigüedad: Jefe de la organización.
Ámbito de aplicación: la estrategia de negocios global y el éxito. Las respuestas a la junta directiva.
CTO (Chief Technological Officer):  

Papel: función ejecutiva con la dirección general técnica de la empresa.
Antigüedad: más alto miembro del personal técnico, sin rendir cuentas a otros ejecutivos de nivel C y vicepresidentes (VP).
Ámbito de aplicación: la estrategia técnica, a menudo llamados a apoyar las oportunidades de negocio.
Asociado (Fellow)

Papel: un pensador estratégico técnico e innovador. Este suele ser el más alto nivel técnico en una compañía de software. Por lo general menos de 1 por ciento de los empleados pueden llegar a este nivel.
Esto es a menudo una posición ejecutiva.
Antigüedad: La parte superior de la cadena técnica. Dependiendo de la compañía, esta posición no puede ser mayor que la CTO. Sin embargo, a diferencia de un CTO, los becarios no pueden controlar directamente los equipos técnicos.
Alcance: de dominio específico, basado en la experiencia. Por ejemplo, los becarios se suelen asociar a un campo específico, como compiladores, sistemas operativos, informática móvil, etc.
Vicepresidente (de desarrollo, marketing, ventas, etc)
Rol: Un ejecutivo responsable del éxito de una función entera dentro de una marca o una gran parte de la empresa, como la I + D, marketing o ventas.
Antigüedad: rinde cuentas a un ejecutivo de nivel C o un vicepresidente de mayor rango.
Ámbito de aplicación: nivel de producto o marca.
Director de ingeniería

Papel: Un ejecutivo responsable del equipo de I + D, en parte, a la ingeniería de garantizar que la estrategia está bien definida, pero más específicamente para asegurar que el desarrollo del producto está bien administrado.
Antigüedad: Informa a un vicepresidente. La mayoría del equipo de desarrollo estará bajo control del director.
Alcance: Toda la organización del I + D.
Director de marketing  

Función: Responsable del equipo de marketing, en parte para asegurar que la estrategia de marketing está bien definida, pero más específicamente para asegurar que la ejecución de la estrategia esté bien administrada.
Antigüedad: Reporta a un vicepresidente. La mayoría del equipo de desarrollo estará bajo control del director.
Ámbito de aplicación: Una organización de marketing completa.
Arquitecto jefe

Papel: la responsabilidad de arquitectura para un producto o marca.
Antigüedad: Un alto cargo, de forma similar en estatura al Director. A veces se denomina ingeniero distinguido si el papel es un cargo ejecutivo.
Alcance: El arquitecto en jefe es el arquitecto de los arquitectos. Todas las decisiones técnicas de diseño se encuentran bajo su / su ámbito de competencia.
Gerente de distribución

Rol: Un jefe de proyecto que tiene la responsabilidad general de asegurar que un producto se entregue.
Antigüedad: Por lo general, depende del alcance de lo que se está manejando. Para que un producto pequeño que puede ser similar a un programador senior o jefe de departamento. Para que un producto muy grande esto puede ser equivalente a un gerente de segunda línea.
Ámbito de aplicación: nivel de producto.
Gerente de segunda línea
Rol: Un gestor de gestores. Segunda línea, los gerentes por lo general director de administrar una organización de 50 a 200 personas.
Antigüedad: Un papel de la alta dirección, por lo general la presentación de informes a un director o vicepresidente.
Ámbito de aplicación: el responsable del éxito del equipo (s) administrados, así como las necesidades de personal de los informes directos.
Arquitecto

Papel: la responsabilidad de arquitectura para una gran parte de un producto o un producto completo. Refiere a veces como miembro del personal técnico superior (no ejecutivos) o Ingeniero Distinguido (ejecutivo).
Antigüedad: Al igual que un gerente de segunda línea o primera superior jerárquico, según el alcance.
Ámbito de aplicación: Todas las decisiones de diseño técnico de un dominio específico están bajo su / su ámbito de competencia. Uno de los componentes del producto o el arquitecto es responsable ante el Jefe de Arquitectura de la integridad del diseño y la eficiencia.
Director técnico

Papel: Gestiona el personal de trabajo productivo real, sino también actúa como el líder técnico senior en el equipo.
Antigüedad: gerente de nivel medio, la presentación de informes ya sea a un gerente de segunda línea o de otro miembro del personal de alto nivel.
Alcance: Se encarga de las prestaciones de los empleados, la dirección técnica para el departamento, y las necesidades del departamento de personal. Los directores técnicos tienden a manejar un poco más pequeños departamentos de los jefes de departamento ordinario, ya que su función incluye la dirección técnica.
Director del programa

Función: Combina las funciones de Gerente de Producto y gestores de proyectos. Asegura que los recursos que se aplican a las cosas correctas y, en menor medida, de que las cosas se están construyendo justo.
Antigüedad: Por lo general, una posición de nivel medio, similar a un jefe de departamento, aunque hay una amplia gama en función de su alcance. Esto puede ser una posición muy alta, comparable a un Director.
Ámbito de aplicación: nivel de producto o marca.
Director de departamento

Papel: Gestiona el personal de trabajo productivo real.
Antigüedad: gerente de nivel medio, la presentación de informes ya sea a un gerente de segunda línea o de otro miembro del personal de alto nivel.
Alcance: Se encarga de las prestaciones de los empleados en el departamento, así como sus necesidades de personal. Se encarga de reclutamiento y entrenamiento.
Miembro del personal de investigación

Función: a tiempo completo investigador. Esta posición requiere generalmente un doctorado, aunque hay excepciones.
Antigüedad: de gran prestigio, pero con moderado a escaso control sobre los equipos de personas. Esto es el equivalente corporativo de un investigador universitario.
Ámbito de aplicación: Por lo general se centró en un área de experiencia de investigación, tales como sistemas operativos, optimización matemática, la base de datos, etc El éxito se mide tanto por su impacto en la innovación de productos reales y las métricas tradicionales de investigación, tales como patentes y publicaciones de nivel  1.
Gerente de producto (o planificador de producto)

Función: Define la estrategia y el contenido de un producto con el aporte de múltiples fuentes (I + D, marketing y ventas). También ayuda a definir los precios y el embalaje (términos de la licencia y la agrupación).
Antigüedad: Por lo general, una posición de nivel medio, similar a un jefe de departamento.
Ámbito de aplicación: nivel de producto.
Ingeniero de usabilidad

Rol: Un rol interdisciplinario que ayuda a diseñar y / o validar de la facilidad de uso de un producto o una característica.
Antigüedad: Una gama de niveles, incluidos los intermedios asociados, y de alto nivel. El grado de responsabilidades de diseño y liderazgo de equipos aumenta en cada nivel.
Alcance: El producto o el nivel de prestaciones, responsabilidades.
Programador

Rol: Diseño de software y nuevos programas.
Antigüedad: Una gama de niveles, incluyendo programadores, intermedio y superior. El grado de responsabilidades de diseño y liderazgo de equipos aumenta en cada nivel.
Ámbito de aplicación: especificaciones, el diseño, el desarrollo de código, y las tareas asociadas
Función de probador de verificación

Papel: verificación funcional.
Antigüedad: Una gama de niveles, incluyendo probador, intermedio y superior. El grado de responsabilidades de diseño y liderazgo de equipos aumenta en cada nivel.
Alcance: Ensayo de planes, ensayo de diseños, desarrollo y ejecución de pruebas, y tareas asociadas y centradas específicamente en la verificación funcional.
Medidor de verificación de sistema

Papel: la verificación del sistema. A diferencia de verificación funcional, que examina la función de un producto, la verificación de sistema examina las interacciones de los componentes cuando se integran y operado bajo estrés. Las pruebas del sistema incluye la prueba de perfil de usuario, las pruebas de estrés (concurrencia, volumen, escala), y las pruebas de integración.
Antigüedad: Una gama de niveles, incluyendo probador, intermedio y superior. El grado de responsabilidades de diseño y liderazgo de equipos aumenta en cada nivel.
Alcance: Ensayo de planes, ensayo de diseño, desarrollo y ejecución de pruebas, y las tareas asociadas y centradas específicamente en la verificación sistémica.
Vendedor técnico

Papel: Las ventas a socios de negocios o bien, distribuidores, proveedores de software independientes (ISV), o clientes
Antigüedad: Una gama de niveles, incluyendo especialista asociado de ventas, intermedio y superior.
Alcance: personal de ventas técnicas representan un subgrupo del equipo de ventas. Por lo general son más profundamente expertos en líneas específicas de productos y ayudar al equipo de ventas más amplia en el manejo de las cuentas detalladas.
Puede trabajar con una comunidad más amplia para llevar una prueba de concepto de las implementaciones.
Vendedor directo

Papel: Las ventas a clientes.
Antigüedad: Una gama de niveles, incluyendo especialista asociado de ventas, intermedio y superior.
Ámbito de aplicación: presenta los productos y marcas a los clientes potenciales. El viaje es común, y puede ser regional o internacional.
Vendedor de canal

Papel: Las ventas a los socios comerciales, distribuidores, y los ISVs
Antigüedad: Una gama de niveles, incluyendo especialista asociado de ventas, intermedio y superior.
Ámbito de aplicación: presenta los productos y marcas a las empresas que revenden el producto, ya sea directamente (distribuidor) o en conjunción con sus propios (como agrupación de una base de datos con un paquete de contabilidad). Los  viajes, ya sea regional o internacional, es común.
Técnico evangelista

Papel: Evangelista tecnológico, realza el entusiasmo de la comunidad para un producto o marca. Apoya la comercialización y los equipos de ventas. Un evangelista técnico o de tecnología es una persona que intenta construir una masa crítica de apoyo para una determinada tecnología con el fin de establecerlo como una norma técnica en un mercado que está sujeto a los efectos de red
Antigüedad: Una gama de niveles, incluidos los intermedios asociados, y de alto nivel.
Ámbito de aplicación: nivel de producto o marca. Ámbito de aplicación es a la vez hacia el interior mirando hacia la I + D, marketing, y equipos de ventas, así como hacia el exterior orientada hacia las comunidades de usuarios. A menudo responsables de la creación de demos, white papers, y la garantía de publicidad.




[1] Making It Big in Software por Sam Lightstone, Prentice Hall, 2010.

Steve McConnell habla sobre organizaciones exitosas en el sector de software

Steve McConnell, CEO de Construx Software habla sobre como las formas de las organizaciones de las empresas de software pueden ser claves para entender el éxito o no de las mismas...










Organización: Introducción a la organización de una empresa de software

La organización en una empresa de software[1]

En esta sección se analizan algunos de los aspectos de una organización que afectan a la forma de sistemas de software llegado a ser. Esta es un área grande, que tiene trabajos de investigación (Allen 1997a, 1997b;. Allen et al 1998) y libros enteros (Weinberg, 1991; Brooks 1975) dedicado a ella, por lo que sólo mencionaré algunos de los factores más relevantes aquí.
El desarrollo de software es, en muchos aspectos, una disciplina social. La organización puede influir significativamente en cómo se diseña un producto y cómo se estructuran los equipos. Las cosas pueden ponerse difíciles cuando sus conflictos con enfoque de desarrollo de las estructuras de la organización imponen. Cambio de la estructura de la organización es a menudo la mejor, lo más difícil, fijar. Incluso si el cambio de la organización es imposible, el verdadero peligro está en no reconocer estas influencias y en centrarse únicamente en las tareas de programación inmediata.

La organización tiene una influencia desde la perspectiva de la estructura de espacio de trabajo y de control de versiones, porque la estructura de la organización limita la comunicación. La organización afecta a la comunicación por la distancia entre las personas y equipos. La distancia es una medida de lo difícil que es para los equipos y los miembros del equipo de interactuar. Puede ser por la distancia física, pero no siempre. Estructura de la organización reparte las responsabilidades, que también pueden hacer la comunicación más si las responsabilidades no están divididas de manera consistente con las necesidades de la aplicación.
La organización puede ser más sutil en su influencia sobre la arquitectura y la forma de trabajar. La naturaleza de la organización y su cultura limitan la dinámica del equipo, la arquitectura, los objetivos del proceso de desarrollo, y cómo se manejan los problemas.
La distancia es aproximadamente la siguiente:
·         Ubicación física. Los equipos que no están físicamente cerca puede tener un menor ancho de banda de comunicación.
·         La dinámica de la cultura y el equipo. Una cultura adecuada puede dar lugar a equipos que están separadas físicamente con muy buena comunicación y también puede dar lugar a la gente en la misma habitación que la comunicación muy pobre.
·         Estructuras organizativas que determinan las vías de comunicación. Este es un aspecto de la cultura ya la comunicación no tiene por qué seguir las estructuras corporativas, pero si se trata de una ética en su organización, usted haría bien en tener las vías de comunicación de arquitectura sigue las fronteras de la organización.
¡Tienes que ser consciente de los efectos de la distancia de la organización, y le invitamos a ser un agente de cambio para mejorar la visión a largo plazo, sino que simplemente la construcción de las estructuras de trabajo para que sean robustas frente a estas cuestiones de organización va a generar una ganar a lo grande.
Algunas influencias de la organización incluyen otros
·         Conjuntos de habilidades de las personas
·         Distancia, que abarca muchas cosas, como la distancia física
·         Valores y la cultura
·         Ubicación del personal y otros recursos
·         Equipo de la estabilidad
·         Tipo de empresa: la empresa de consultoría en comparación producto de la empresa frente a la empresa de productos específicos de los clientes con los cambios

La estructura de una organización puede tener un gran impacto en cómo el software se construye y por lo tanto en las necesidades de coordinación. Las fuerzas de la organización pueden tener un impacto muy fuerte en la arquitectura del producto y pueden controlar aspectos del proceso tales como cuándo y cómo se crean versiones, probado, y así sucesivamente. Está más allá del alcance de este libro que le diga cómo para que coincida con el proceso de producción y la arquitectura para adaptarse y aprovechar la estructura de la organización. Se describen brevemente algunas de las cuestiones de modo que usted pueda entender mejor.
Aunque muchos dicen que un entorno de desarrollo ideal tiene desarrolladores que están cerca unos de otros y que se comunican con eficacia, muchas organizaciones tienen recursos reales que se encuentran geográficamente distribuidos, y hay que ayudarlos a trabajar bien juntos. Una forma es distribuir las responsabilidades para que los grupos a distancia puedan tener interfaces muy bien definidos entre ellos y pocas dependencias. También es necesaria la estructura del sistema de control de versiones para que la gente en todos los lugares se pueda ver todo el código fácilmente.
Algunas influencias de la organización en la arquitectura que son particularmente relevantes son los siguientes.


Estructura del módulo (Bass et al. 1998). Los módulos deben ser desarrollados por personas que pueden trabajar bien juntos, y aspectos como la geografía o la experiencia de la tecnología pueden determinar que ciertos componentes deben ser desarrolladas por ciertos grupos. Hay una interacción con la arquitectura del producto aquí, puede que tenga que tomar la decisión de asignar un componente a un grupo con la experiencia técnica más adecuada, por ejemplo, o un grupo con menos habilidades técnicas, sino en una mejor posición para interactuar (por todos los medios apropiados, esto no es un argumento a favor de la proximidad geográfica) con los grupos que interactúan con el producto del trabajo.


Política de integración: ¿Con qué frecuencia todos los componentes de un sistema se integran a menudo en función de la política de la organización.


Gestión  de espacio de trabajo: ¿Cómo configurar el entorno de desarrollo local y la forma en que su espacio de trabajo se relaciona con los demás.


Control e identificación de versiones: ¿Cómo utilizar las herramientas de control de código fuente y otros medios para coordinar los cambios con los demás, publicar los cambios, y se reproducen los ambientes, como por ejemplo cuando se necesita para corregir un error en una versión anterior. Esto incluye cuestiones tales como la ramificación y etiquetado, que a menudo causa una gran consternación.


Coordinación: ¿Cómo se trabaja en conjunto con otros equipos y desarrolladores.


Identificación y Auditoría: ¿Cómo sabes lo que has construido?.


[1] Software Configuration Management Patterns: Effective Teamwork, Practical Integration por Stephen P. Berczuk, Brad Appleton

domingo, 30 de octubre de 2011

Tercera nota sobre fijación de precios...


La ciencia de fijar precios al software

Una de las partes más intrincadas de lanzar un software es determinar cuál es el precio ideal.  ¿No le gustaría acaso saber cuál es el número mágico que duplica sus beneficios?
Fijar precios no es una ciencia exacta, pero tampoco es magia – es influenciada por percepción que se tenga de su software, las condiciones del mercado y su valor. ¿Entonces cuál es el proceso de encontrar el precio ganador?

El precio ganador en números

Cuando fijamos precios a productos, nuestro objetivo es (usualmente) obtener el máximo de beneficio – queremos que nuestra ecuación de ventas x precio sea igual al máximo valor posible.
La teoría económica sugiere que a medida que elevamos el precio nosotros disminuimos los cantidades vendidas. Cada intersección de precio y cantidad vendida puede ser dibujada en un gráfico, creando lo que se da en llamar  curva de demanda.

El punto ganador es cuando la intersección dibuja el rectángulo más grande. Este rectángulo representa el cálculo de ventas x precio, y el rectángulo más grande representa el beneficio más grande.
Esto tiene sentido hasta que uno considera que los consumidores son gente – y las personas no hacen decisión de compra racional frecuentemente. Citando al excelente libro electrónico  “Don’t just roll the dice” por Neil Davidson:
Una vez que usted ha determinado cuál es su producto, usted necesita considerar cuál es el valor para sus consumidores. En el caso del Time Tracker 3000, digamos que le ahorrará a un cliente particular, digamos Willhelm, tres horas de trabajo siendo que Willhelm valora su tiempo en $50 la hora. Eso significa que Willhelm debería comprar el Time Tracker 3000 a cualquier precio por debajo de $150, suponiendo que no tenga nada mejor que hacer con su dinero.
Por supuesto, esto supone que Willhelm es la máquina tomadora de decisiones racional que los economistas aman. De hecho, Willhelm es un ser humano de carne y hueso irracional que no fija precios a su tiempo ni calcula costos y beneficios todo el tiempo. Él tiene un valor percibido del Time Tracker 3000, el cual puede o no estar asociado a su valor objetivo.
Neil entra en muchos mayores detalles de lo que yo lo voy a hacer en este artículo, pero para una recapitulación rápida – el valor percibido puede diferir del valor objetivo, y el valor percibido puede afectar las ventas en modos en que la curva de demanda no predice. Por ejemplo, cuando se compra un producto de marca se está pagando una prima ó premium por encima del propósito en sí del producto dado que el valor en sí del producto es mayor incluso si el valor objetivo es el mismo. Algunas marcas en forma deliberada fijan precios mayores para vender más dado que el valor percibido se incrementa.

Fijando precios más altos a los mismo productos

Volviendo de nuevo a la aplicación ficticia del libro de Neil:
Volviendo a Willhelm y el Time Tracker 3000. Si usted quiere hacer cambiar la cantidad que Willhelm pagará por su producto, entonces hacerle cambios al producto es una opción, pero sólo si usted es capaz también de hacerle cambiar su percepción también. De hecho, se da que usted puede cambiar la percepción de Willhelm sobre la valía de su producto sin tocar el producto en lo más mínimo. Esto es una de las razones por las que el marketing existe.
Eso es. Usted puede pedir un precio más alto sin cambiar su producto, sólo cambiando la percepción que el cliente potencial tiene sobre éste. Uno de nuestros proposiciones de valor en Binpress es que ayudará con los aspectos de marketing. Con el permiso [de los autores], editamos la descripción y sumario cuando sea posible para representar mejor el valor del contenido, y al escribir artículos como éste incrementamos la percepción de cuán importante el marketing es tanto para las ventas como para maximizar los beneficios.
Por lo que proveeremos de servicios de diseño y UI para nuestros vendedores de modo de mejorar en enlace más débil del marketing con la mayoría de los desarrolladores – diseño. Una bien conocido compañía de software con una fruta se ha convertido en un gigante por descollar en el diseño y de ese modo imponerse a sus competidores, y no es por mera  coincidencia. Apple carga una prima por sus productos debido al valor percibido de sus productos.
Uno de las maneras más comunes de entender el precio percibido es chequear a la competencia. ¿Está usted vendiendo un plug-in de para un newsletter de gestión empresaria? Googléelo y vea que más hay en el mercado. Si usted tiene suerte, usted proveerá la única solución en este espacio – pero si no, usted tiene que considerar que sus clientes van a googlear del mismo modo que usted y tendrán en consideración rápidamente a los precios de sus competidores.
¿Qué hace usted cuando hay productos gratuitos que hace lo mismo que su producto? Usted tiene cuatro opciones entonces:
  1. Demuestre que su producto es claramente superior ó que tiene características únicas que el producto gratuito no tiene.
  2. Cree esos factores diferenciales.
  3. Gane en el marketing.
  4. Provea ayuda al cliente.
Dar ayuda al cliente es un diferenciación importante – una de las principales detractores para las empresas de usar productos desarrollados sobre menos conocidas fuente de código libre es la preocupación acerca de problemas actuales y necesidades futuras. Un producto comercial ofreciendo soporte puede muchas veces ganar clientes que desean esa cobertura de seguridad. Pronto nosotros añadiremos una prestación de rastreador de temas a cada componente, con nuestros vendedores teniendo la opción de marcar un paquete para aceptar tickets de soporte. Esto podría ser otra forma de diferenciar los paquetes o incrementar el valor percibido.
Dar soporte tiene un beneficio añadido aparte de incrementar el valor del producto – ¡es una chance de obtener retroalimentación real de su producto! Usando el feedback de los requerimientos de soporte le ayudará a mejorar su producto y venderá incluso mejor (ó incrementará el precio) en el futuro.

Determinando el precio justo

Hasta ahora he hablado acerca del valor percibido y objetivo y maximizando la curva de demanda. ¿Pero cual es la etiqueta de precio real?
Cuando vamos a fijar el precio de nuestro producto, deberíamos repasar los siguientes ejercicios :
  1. Determine el valor objetivo del producto. Cuánto costaría tu producto si de hecho la gente fuese máquinas racionales volitivas. Cuando hablamos de vender código fuente, el cálculo puede ser tan simple como : valor = (costo hora de trabajo x tiempo de desarrollo en horas) - precio. Este cálculo simplista determina el valor al cliente, si éste hiciera una decisión completamente lógica (por supuesto varía dependiendo del costo de la hora de trabajo y de la experiencia del desarrollador afectado a la tarea, pero esos dos números están usualmente relacionados).
  2. Entender el valor percibido del producto. ¿Cuál es su audiencia objetivo? ¿De qué modo su producto los ayuda? (ie, les ahorra tiempo, les mejora su producto/negocio etc.)? ¿Quién realizará la tarea de vendedor? (el desarrollador, un gerente de proyecto, un flaco de la gerencia de la compañía que tiene una tarjeta de crédito en Puerto Madero?, etc.) Para saber esto usted debiera investigar su mercado – ¿cuales son los productos de la competencia? ¿cuál es su demanda? ¿quién necesitaría esta solución y qué tan única es? ¿Qué tan difícil fue desarrollarla desde cero? Esta discusión sobre intercambio de opiniones entre programadores da una buena revisión de estas consideraciones. Usted puede encontrar respuestas a aquellas preguntas para casi excepto para las necesidades más oscuras sólo usando Google y visitando sitios tales como los programmers stackexchange y Quora, donde la gente postea preguntas tales como  “donde puedo encontrar x para  y (reemplace x e y con requerimientos y lenguaje).
  3. ¿Cuál es el valor que quiero transmitir a través del precio? Hay una gran diferencia en el mensaje que usted está mandando a un cliente potencial cuando el precio es $1.99 que cuando el precio es $19.99 – la diferencia de valor transmitido es increíble. No intente minimizar el precio en un primer momento con la esperanza de generar más ventas, dado que usted le está diciendo a sus clientes que no vale mucho más. Tuvimos una oleada de enviados a publicación recientemente con un precio de cerca de $1.99 el cual parecía estar más relacionado a copiar el precio de otros editores con la esperanza de tener más éxito en vez del valor actual del producto. Añadimos un precio mínimo de $4.99 para este propósito específicamente, y creemos que la vasta mayoría de los componentes debiera ser preciado a valores más altos.
Luego de determinar el valor percibido del producto, podemos ir un paso más adelante e intentar optimizarlo para alcanzar nuestro mejor precio haciendo lo siguiente:
  1. Mejorando el valor percibido vía marketing. El tópico del marketing de productos de software es amplio y será cubierto en futuras entradas, pero resumámoslo en unos pocos puntos – enfocarse en los beneficios, reduciendo los posibles miedos y destacando el diseño del producto. Considere estos elementos intentando incrementar de ese modo el valor percibido. Se encontramos que el valor percibido está debajo de nuestro valor objetivo, entonces es casi cierto que podemos elevarlo al menos al punto del valor objetivo, y probablemente con marketing creativo lo podemos pasar.
  2. Mejorando el valor objetivo. Citando al excelente artículo sobre Simplicity de Joel Spolsky :
    Con seis años de experiencia dirigiendo mi propia compañía de software les puedo decir que nada que hayamos hecho jamás en Fog Creek ha incrementado nuestros ingresos más que liberar una nueva versión con más capacidades. Nada. El flujo desde nuestras versiones más simples a las versiones más nuevas con nuevas características es absolutamente innegable. Es como la gravedad. Cuando intentamos los avisos de Google, cuando implementamos varios esquemas de afiliación, ó cuando cuando un artículo acerca de FogBugz apareció en la prensa, apenas vimos efectos en las ventas. Cuando una nueva versión aparecía con nuevas capacidades, veíamos un rápido, innegable, sustancial y permanente incremento en los ingresos.
    Volviendo al punto que hice mención antes – usted puede incrementar el precio proveyendo factores de diferenciación entendiendo lo que la gente busca y atacando las debilidades de su competencia. Todos está usando Magento porque provee un montón de valor, pero siguen quejándose acerca de la velocidad entre otras cosas. Suponga que usted construye una plataforma de eCommerce similar que sea mucho más rápida? Bingo, usted se enfocó en la principal falla que los competidores de sus clientes tienen. Algunas veces es bueno tener competencia sólo para saber lo que la gente realmente necesita.
  3. Ensayando. Cuando todo está dicho y hecho, es muy difícil determinar un punto de precio ideal hacia donde ir. Usted necesita ensayar diversos esquemas de precios e intentar construir algo como una curva de demanda e intentar encontrar cual es el precio ganador. Nosotros vamos a ofrecer un aditamento automático que hará esto por usted pronto – variará el precio luego que un número de componentes observen y comparen los números de ventas para cada precio y luego corra diversos sub-tests alrededor de los mejores precios a fin de encontrar el precio ideal. Esto puede ser hecho manualmente ahora, pero el seguimiento automático lo hará mucho más preciso y eficientemente.
  4. Creación de niveles de precios. Esto es muy importante desde el punto de vista psicológico – cuando uno ofrece sólo un nivel de precios a su producto, no se da ningún punto de referencia (excepto a su competencia). Usted puede incrementar el valor aparente de su fijación de precios regular añadiendo un paquete de precios premium que es más caro que el resto. El punto del paquete premium no es de hecho que produzca ventas (si bien de hecho hará algunas ventas – uno siempre tiene que darle a la gente la opción de pagar si así lo desean), sino que haga que el precio regular parezca un buen negocio. Cuando fijamos los precios de los componentes en Binpress, usualmente sugerimos a los vendedores que añadan la opción de “Licencia sublicenciable” para un precio mucho más alto – no sólo de hecho algunas personas lo comprarán, sino que también hará a los precios regulares mucho más valorados.

Empiece con una buena intuición y pruebe, pruebe, pruebe

A este punto usted debiera tener el proceso básico de cómo fijar precios a su producto. No hay una verdad universal en la fijación de precios – es mejor empezar con una buena suposición y luego pruebe y evalúe tanto como sea posible. A fin de ayudarlo en su evaluación (y por supuesto, en generar más ventas), nos enfocamos en generar mucho más tráfico para Binpress sobre los próximos dos meses. Estamos ahora empezando a correr campañas PPC y SEO que ayudarán a mantener la pelota rodando, pero su paciencia será recompensada.
Espero saber que piensa a través de los comentarios. Veamos que piensa acerca de cómo fijar precios a sus productos de software.

bin press

Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Best Hostgator Coupon Code