Productizate Esto
Hace años, y como regalo de bienvenida en un nuevo trabajo, me tiran por la cabeza un bodoque de código—el cual había sido originalmente concebido como una cosa interna—para transformarlo en un producto que, habría de enterarme en ese preciso momento, tenía clientes esperando y cuya entrega destrababa el cronograma de pagos de un proyecto. Linda presión.
Además del revoleo de código, acto seguido me piden “cerrarlo” para proteger la propiedad intelectual, pero con la condición de dejarlo lo suficientemente abierto como para que el cliente pudiera desarrollar su propia magia arriba (o sea, crear una especie de SDK). Me piden además documentar todo con un manual de usuario que explique bien cómo usarlo.
Desconcertado, y sin mucho tiempo para patalear porque recién llegado, me embarqué en tal vez una de las más curiosas tareas que a uno le pueden tocar: transformar en producto algo que claramente no nació como tal. Los genios de las palabras lo llaman: productizar.
Cuando uno “productiza” algo es cuando uno se da cuenta de la distancia entre un coso parido para estricto consumo interno versus un producto (tema ya tocado en algún momento, aunque ahí hablo más sobre la brecha prototipo-producto1).
Pero además uno se da cuenta que todo producto hijo de buen vecino requiere:
Tener un alcance definido: qué debe incluir y que no
Tener un precio que no sea un número mágico ni una expresión de deseo
Tener pensado el post venta: a diferencia de cuando se vende un pancho, muchos productos requieren definir qué pasa después que la cosa se entrega. Si el cliente tiene consultas, quién atiende el teléfono? Quién le paga al que tiene que atender el teléfono? También hay que pensar en garantías: documentación que sirva de marco para cuando el producto tenga fallas inesperadas y deba ser reparado o reemplazado por otro mismo producto nuevo, la cual debería tener un tiempo límite y no durar para siempre así nos podemos sacar de encima al cliente en algún momento.
Incluir información para usarlo: manuales, guías, ICDs, etc.
Algo que refleje cierto aseguramiento de calidad, incluyendo cuestiones lógicas de seguridad: no sería conveniente que el cliente se muera o se lastime usando el producto
Tener pensadas cuestiones de shipment, integración y deployment. Si el producto se supone se va a encastrar en una arquitectura superior que el cliente maneja; cómo se va a dar esa integración? Quién hace qué?
Pensar en licencias y dependencias de terceros: se puede vender algo que usa librería X o Y con licencia tipo Z?
Permisos de exportación y otras yerbas leguleyas. Que pasa si el cliente se lo revende a Pyongyang?
Pensar al menos algo, ALGO, de user experience (UX): darle al menos una mínima dosis de usabilidad e intuitividad
Que la configuración no sea un rejunte de archivos XML fantasma que haya que editar a mano en Vim
Esquivar promesas deformes y ambiguas de transferencia de conocimiento entre productizador y productizado
Evitar prometer niveles de servicio (service-level agreements, o SLAs) imposibles de cumplir
Ser bautizado con un buen nombre, que no sea presuntuoso y que sea fácil de pronunciar, no como hace IKEA que para pronunciar el nombre de una silla te tienen que cortar la lengua.
Todo aquello que no nace como producto y accidentalmente se convierte en uno, va por la vida mostrando las costuras que asoman ni bien se lo mira de cerca.
El desastre se materializa cuando la productización improvisada incluye rediseños o redefiniciones de la arquitectura a las apuradas, lo cual indefectiblemente termina, tarde o temprano, en situaciones caricaturescas.
Notar que un prototipo suele tener intención de convertirse en producto. Acá hablo de cosas que nunca tuvieron tal intención.