En una startup de tecnología, ¿es mejor enfocarse en la velocidad y ‘piratear’ pero acumular una gran cantidad de deuda tecnológica, o mejor construir las cosas correctamente desde el primer día?

Answer 1

Ninguno.

Cuanto más código escriba, ya sea que piense que es excelente o que es horrible (porque está HACKING!), Su software simplemente se vuelve más complejo. Si en algún momento traes un codificador más talentoso O un visionario diferente O ambos, sin importar lo que escribas, querrán cambiar algo “para mejor”. Esto es inevitable. A medida que explore su propio negocio, se dará cuenta de que la función X no tiene ningún valor, pero esa función Y, sobre la que habló y habló y habló, hubiera sido increíble que nunca lo haya implementado.

El hecho es que, mientras se encuentra en un inicio, y especialmente en los primeros días, debe obtener la validación de su base de usuarios (lo que podría cambiar porque es martes) tan rápido como sea posible que la dirección hacia la que se dirige es útil para ellos. Necesita priorizar el desarrollo de código para las cosas que ya ha hecho ALGUNA diligencia para poder probar.

Desea codificar lo menos posible hasta que sepa que lo que está por construir está en demanda. Cuando haces código, necesitas escribir código que no sea frágil, pero no necesita ser el mejor código. Necesita funcionar ahora, y necesita trabajar dentro de 2 meses. Eso no es un hack, ni es “alta calidad”.

Entonces, aquí hay un flujo básico:

• Cree una versión de tecnología extremadamente baja de lo que está imaginando; esta podría ser una página de destino que solo habla de ello; esto podría ser una encuesta que directamente pregunta sobre cierta funcionalidad; esto podría ser un cableado / prototipo increíblemente de baja fidelidad; o podría ser un código esqueleto
• Obtenga una respuesta inmediata de una muestra de su público objetivo. Esto podría ser el resultado de la encuesta, una llamada telefónica o llamadas telefónicas, o cara a cara con algunas personas.
• Iterate en los comentarios hasta que hayas creado una versión de baja tecnología de lo que estás imaginando que agrega valor (que tal vez sea en este punto, valor que se podría cambiar por dólares)
• Vaya a construir una versión liberable basada en el prototipo y las lecciones que ha aprendido, y solo compile lo que realmente ha sido el ámbito
• Suelte y vuelva al paso 1.

Esto se simplifica en exceso: hay toneladas de pasos intermedios, y una vez que haya pasado por ese ciclo, debe volver a pensar su arquitectura de nivel superior.

El punto es que probablemente no eres el programador más talentoso del mundo (sin ofender). Pero también está intentando crear un negocio en el que pueda ganar dinero sin que su producto / servicio se desmorone. Los extremos no funcionan, y lo que usted llama “mejor código” está extremadamente limitado a su ámbito específico de experiencia, ahora mismo.

Debe reunirse en el medio y construir para el futuro previsible real, no el que tiene palos de hockey y el crecimiento explosivo de las redes sociales de la noche a la mañana, pero tampoco el lugar donde agregó 1 usuario después de 2 meses.

Answer 2

Cortar. No hay duda.

Para la mayoría de las nuevas empresas de tecnología, el mayor problema es sobrevivir el primer año. Necesitas clientes. Necesitas inversores. Necesita un poco de entusiasmo para atraer empleados.

Tu primer objetivo es producir un mínimo de productos viables (MVP). Hasta que no tenga eso, no puede obtener clientes, no puede hacer mercadotecnia, no puede obtener financiamiento de VC fácilmente, y solo son algunas personas que escriben un programa de computadora en un garaje en algún lugar.

Por el contrario, si realmente tienes algún tipo de producto, estás en el juego. Puede mostrar a las personas parte de su visión demostrando el producto. Puede interesar a los clientes. Usted puede interesar VCs.

A menos que tenga reservas de capital muy grandes, y esté seguro de que alguien no va a colocar un producto en exactamente esta categoría mientras produce un código hermoso, sus esfuerzos deben ser para que este MVP salga por la puerta. Incluso se trata de humo y espejos para que funcione.

No tiene que ser perfecto. Ciertamente no necesita estar completo. Es una “prueba de concepto”, si lo desea. Es muy probable que su supervivencia y éxito dependan de que otras personas se interesen lo más rápido posible, y esto es mucho más fácil con una aplicación demostrable (pero tal vez mal escrita) que un caso de negocios y una promesa de que sabe lo que está haciendo.

Luego, en 18 meses, cuando tenga fondos de capital de riesgo y un conocimiento de lo que realmente necesita el mercado, puede regresar y solucionarlo.

Answer 3

Empieza con el hack y la velocidad. Gradualmente pasar a hacer las cosas de la mejor manera e ideal. Su código, arquitectura, etc. sufrirán muchos cambios y es posible que no esté en una posición o tenga la previsión de hacer una arquitectura que seguirá siendo válida por muchos años.

No comprometa la calidad del código. La arquitectura puede cambiar y es posible que tenga que desechar o refactorizar una gran parte de su trabajo. Puede parecer dinero a la basura, pero es así como se construyen arquitecturas robustas. Un código de buena calidad facilita la incorporación de nuevos ingenieros, pero aún no es necesario tener una arquitectura, un proceso de codificación, una documentación bien pensados, etc.

Hacer las cosas de la manera correcta importará una vez que tengas tracción. Escala de una aplicación que está llena de hacks probablemente no es la mejor manera.

No debe cruzar la línea de peligro de sus MVP rápidos y sucios que establecen expectativas sobre las futuras versiones. Hackea rápidamente a tus MVP pero asegura MVPs de muy buena calidad.

-Kash

Conectate conmigo en LinkedIn

Answer 4

Cree solo lo que sea necesario para alcanzar su próximo hito con un buen proceso de software y cobertura de prueba.

Todas las organizaciones para las que trabajé que trataron de agregar calidad más tarde dedicaron mucho más tiempo a la creación de lanzamientos iniciales y de seguimiento que si hubieran hecho las cosas bien la primera vez. Uno perdió su ventana de mercado donde un competidor llegó a un límite de mercado de $ 2B. Uno se acercó a la estasis de características donde se vuelve imposible agregar funciones mientras se mantiene la calidad vendible y tuvo que abandonar los horarios mientras se quema alrededor de $ 1M al mes. Ambos problemas ocurrieron en menos de un año.

Aún habrían sido más rápidos si hubieran tenido que deshacerse de los esfuerzos iniciales de mayor calidad.

Mientras que otras personas creen que el aforismo “puede tener dos de software rápido, económico y de alta calidad” durante décadas, he encontrado que generalmente puede tener los tres o ninguno de los anteriores.

A menudo, después del envío, usted encuentra que el mejor paso siguiente es diferente de lo que esperaba. Tengo un registro atrasado con entradas de cinco años que probablemente nunca conseguiré. Los ingresos crecerán más rápido que con más lanzamientos con todas las funciones cuando envíe el mínimo necesario antes, decida el siguiente paso según la respuesta del mercado e itere.

De vez en cuando, un poco más al principio puede ahorrar mucho tiempo más tarde y debe hacer una excepción.