1. La estrategia tecnológica tras el modelo de la Startup:
Lo mínimo que deberías saber siendo emprendedor sin formación técnica y con una startup de base tecnológica
Te decidiste, diste uno de los pasos más importantes de tu vida: ser emprendedor, trabajar en tu propia empresa, tu startup.
Ya tienes clara tu idea de negocio, el plan para llevarla acabo, has expuesto varios pitch e incluso cuentas ya con financiación.
Lo tienes todo listo para que alguien comience a construir un software que implemente tu innovador producto. Pero cuando vas a arrancar… una gran inquietud se apodera de tu mente.
Algo que ya había rondado por tu cabeza, algo que te había provocado miedo e inseguridad cuando contabas a inversores tu proyecto: cómo se construirá la tecnología que soportará tu proyecto, el futuro de tu startup.
El tema tecnológico te provoca inseguridad porque lo desconoces, porque no tienes formación técnica.
Hasta ahora habías podido lidiar con este escollo, como con tantos otros que tiene esto de emprender. Pero ya no puedes postergar mas este punto, la construcción tecnológica de tu producto debe comenzar ya.
Quizás no te sientas solo, porque ya has visto a otros emprendedores presentar su proyecto sin tener apenas idea de tecnología, presentando un “PowerPoint” que recuerda a aquellas casas de los platós donde rodaban los “western”, sólo una fachada sin nada detrás.
Quizás incluso te hayan hablado sobre algún negocio que contó con gran financiación e ilusión al comienzo, pero que algo invisible y poderoso lo tiró abajo. Algo llamado software, que recuerda al viento, invisible pero con fuerza para arrasar con cualquier cosa.
Quizás ya lo sepas, si no, te lo digo yo: la tecnología incorrecta, inapropiada o mal construida arruina la mejor idea de negocio. Pero la tecnología apropiada es un motor capaz de dejar atrás a tus competidores. Esta es la clave de las empresas líderes de base tecnológica. Créeme, no hace falta que te aburra con centenares de estudios que corroboran esto.
Si me aceptas un primer consejo, recuerda: el aparentemente intranscendente momento en que se escribe la primera línea de código, marcará tu startup para siempre. Esa aparentemente intranscendente primera línea de código, lleva consigo haber seleccionado, correcta o incorrectamente, una tecnología, una arquitectura, un equipo humano, un lenguaje de programación, etc., decisiones que dictarán el futuro de tu empresa.
JOBANDTALENT
Un mal software puede acabar con una startup
Nosotros, que somos técnicos de formación y profesión, creemos tener bastante claros los criterios que utilizaríamos, y utilizamos, a la hora de seleccionar a un técnico. Pero, si no tuviésemos formación técnica, ¿cómo lo haríamos?
Esa aparentemente simple pregunta se la hace cada vez más gente de perfil no técnico. Bien sea por la crisis, porque el mundo ha cambiado o porque simplemente está de moda, cada vez hay más emprendedores, startups e inversores, etc., sin conocimientos técnicos, cuya idea de negocio se basa en alguna solución software que implemente su idea.
En este contexto, conviene que no olvidemos que el sobrecoste de un mal software siempre lo paga alguien. Otra cosa es que quien finalmente lo paga sea consciente de que lo está haciendo. En grandes corporaciones, con grandes presupuestos, ese sobrecoste probablemente se diluye. Pero en un negocio en ciernes, una empresa emprendedora, o startup, un mal software puede acabar con la empresa, y de hecho en muchas ocasiones se convierte en una bomba de relojería para las startups que ven como un mal desarrollo, una mala decisión técnica, o una incorrecta selección de tecnología, puede echar abajo el negocio y obligar a dar difíciles explicaciones a los inversores.
Por lo que nos toca, últimamente no hay un mes en que alguien sin conocimientos técnicos nos pida consejo al respecto. Y más allá de prestar esa ayuda puntual, no tenemos clara una respuesta genérica que aplique para todos los casos. A veces imaginamos que si nosotros tuviésemos una idea revolucionaria, como por ejemplo un nuevo modelo de espacios en edificios, y tuviésemos que buscar un buen arquitecto que la pusiese en práctica, no tendríamos ni idea de cómo seleccionarlo. ¿Atendiendo a su currículum? Probablemente acabaríamos por guiarnos por el "peso" del CV de cada seleccionable. ¿Atendiendo a sus referencias? Estaríamos ante un problema similar ¿cómo identificamos las referencias en las que confiar? ¿viendo el número de palabras de buzzwords de su perfil en LinkedIn? ¿a partir de la confianza que nos transmita la foto de la persona que actua como avalista?
Si nosotros fuéramos inversores o business angels, además de todos los análisis y estudios demográficos y de mercado pertinentes para evaluar el potencial de cualquier idea de negocio, contaríamos siempre con algo o alguien que nos permitiese evaluar la solidez técnica de un proyecto antes de decidir invertir en él. Muy probablemente contaríamos incluso con un equipo técnico de confianza para apoyar los proyectos que financiásemos.
El tema es serio, porque te aseguramos que si contratas a un mal técnico o, para ser más exactos, a un técnico no adecuado para tu proyecto, y el proyecto crece, éste contratará a otros malos técnicos y el problema crecerá exponencialmente (como en las películas de vampiros o zombies): lo hemos vivido y sufrido.
Y un mal software te puede sacar del negocio, haznos caso, también lo hemos visto y vivido.
Tipos de Apps: nativas, híbridas y Web Apps
Si tu proyecto necesita o se basa en una aplicación para móvil (una App), hay varias decisiones estratégicas que vas a tener que tomar. Una de ellas es qué tipo de aplicación necesitas:
- 1. Apps nativas
- 2. Apps híbridas
- 3. Apps webs
1. Applicaciones nativas
Son las que se desarrollan usando el lenguaje nativo de cada terminal. Su potencia en lo que refiere a integración con el terminal será mayor. El problema es que hay que usar un lenguaje de programación diferente según el tipo de terminal, concretamente según su sistema Operativo: Java para Android, Objective C para iOS, .NET para Windows Phone, etc.
Esta opción tiene las siguientes ventajas:
- Tener acceso a todo el hardware del dispositivo (GPS, cámara, etc.)
- Estas Apps estarán disponibles y se descargarán de las tiendas virtuales de cada sistema operativo: App Store, Google Play, etc.
Y los siguientes inconvenientes:
- Desarrollo más costoso: necesitarás un desarrollo o producto diferente para cada plataforma (con el consiguiente mantenimiento).
- Derivado de lo anterior, es muy probable que necesites más desarrolladores y mejos preparados (más "caros").
2. Aplicaciones híbridas
Son aplicaciones basadas en tecnología web, que se ejecutan en el navegador web del dispositivo, pero no necesitan de una conexión a Internet para ejecutarse. Son por tanto multiplataforma: no dependen del sistema operativo del dispositivo, si bien no son capaces de aprovechar tanto los recursos del mismo como las aplicaciones nativas, y por tanto tienen un rendimiento algo peor.
3. Aplicaciones Web
En este caso, hablamos simplemente de una página web a la que se accede desde el navegador del dispositivo como a cualquier otra. El desarrollo puede abaratarse bastante, pero existen muchas limitaciones a la hora de interactuar con el hardware del dispositivo. Además, en esta tercera opción la App no se obtendrá desde las tiendas virtuales.
ENTREVISTA SOLID GEAR
Importancia de tener conocimientos sobre el cloud
“Cuando teníamos las respuestas nos cambiaron las preguntas”Mario Benedetti
La evolución en el desarrollo software
Trabajar siguiendo el desarrollo tradicional no era altamente determinante para el negocio, ya que, en cualquier caso, la entrega del prototipo final del producto al cliente era obligatoriamente después de muchos meses, años, dado que por aquellos tiempos nuestro producto era “instalado”, era un paquete que el cliente descargaba e instalaba en sus sistemas, en su CPD (Centro de Proceso de Datos), al que nuestros protagonistas no tenían acceso (salvo caso puntual, yendo físicamente hasta allí para hacer la instalación) o, simplemente, nuestro software se vendía en los kioscos, una vez al año sacábamos nueva versión, etc. Ya sabes de lo que te hablo.
Pero el tiempo pasó y llegó lo que los modernos llaman “cloud” y los más modernos aún “nube”. La llegada del cloud supuso que las aplicaciones pasaron a estar instaladas en un único CPD, el nuestro, el del proveedor, dando servicio desde una única instalación que gestiona el proveedor a todos los clientes.
Entre decenas de cambios que esto supuso, voy a detenerme en uno crucial: en la época cloud ya no había excusa para demorar meses la entrega de una nueva, pequeña, aparentemente mínima funcionalidad, como sucedía en la época del software instalado.
Uniendo cloud + gestión ágil (iteraciones cortas, velocidad, requisitos cambiantes, etc.) + una potente y sólida base técnica (integración continua, testing del bueno, etc.), cosa que muchos de los que venían del software instalado desconocían totalmente (o desconocen) se podía añadir casi al instante nuevas funcionalidades para todos nuestros clientes. Se podía incluso experimentar con nuevas funcionalidades.
Se podía hasta hacer que en real fuesen los clientes los que nos dijesen qué funcionalidades querían y cuáles no. Se podía ver que pasar a producción 10 veces al día no era una locura sino una ventaja competitiva.
Y la situación es que en el modelo cloud la competitividad entre empresas de software en el mismo sector se ha desatado cruelmente.
¿Qué es eso del Big Data?
El término big data se usa generalmente para referirse a grandes cantidades de datos no estructurados o semi-estructurados. Y que, por su tamaño, el esfuerzo de incorporarlos a una base de datos relacional supondría demasiado coste. Otra definición más clara aún: hablamos de “big data cuando el tamaño de los datos se convierte en parte del problema”. O, como dice Edd Dumbill, “cuando los datos son lo suficientemente grandes como para poder ser procesados con métodos tradicionales”. Cuando en este contexto se habla de “grandes volúmenes de datos” no existe una cantidad específica sobre la cual se pueda empezar a hablar de big data, aunque el término se utiliza normalmente cuando estamos ante petabytes o exabytes.
Hay que tener en cuenta que esto del big data es un tema que la tecnología aún no tiene resuelto del todo, y que aún se encuentra en investigación.
Si quieres seguir con el tema, te dejo y recomiendo este artículo que Adam Jacobs publicó en Comunications of ACM: The Pathologies of Big Data.
Francisco Javier Cervigon Ruckauer
No hay comentarios:
Publicar un comentario