Construye la solución más fácil
El enfoque normal de un programador es buscar una solución que cubra el 100% de los casos, usar algoritmos complejos de los que leemos en Hacker News y buscar utilizar el mismo grado de complejidad de soluciones que utiliza Google, Facebook y otras empresas de Silicon Valley y que vemos en conferencias por Youtube.
Estas soluciones pueden ser la opción cuando llevas desarrollando un par de años y poco a poco tu producto se ha convertido en un monstruo que debe cumplir con un número alto de escenarios y adicionalmente, el equipo de desarrollo ha crecido con el producto hasta llegar a un punto de madurez suficiente para implementarlas. Pero en la mayoría de proyectos una solución sencilla, implementando un par de modelos y un par de CRUDs suele resolver el problema. No hay por qué reinventar la rueda.
Cuando planees una aplicación y un feature, piensa cuál es la solución más sencilla de programar que resuelve el 80% de los casos que deseas resolver. Esta solución generalmente implica programar mucho menos que una solución que cumpla el 100% de los casos. Llama a esta solución "un prototipo" y muéstrala a otras personas. De esta manera podrás saber si vas en el camino correcto, con menos compromiso de que esta solución funcione perfectamente.
El crear un prototipo suele mostrar las limitaciones que existen en el proyecto. A veces estas limitaciones vienen de tu stack, de los conocimientos técnicos del equipo o de los tiempos de desarrollo. Todo es posible programarlo con suficiente tiempo y suficiente equipo, pero nunca tendrás suficiente tiempo y suficiente equipo, mejor busca cosas que sean accesibles en poco tiempo, con el equipo que tienes.
Muchas veces al llegar este punto, los casos iniciales a resolver cambian, un poco de feedback y un prototipo suelen dar mucha visibilidad y el proyecto que en abstracto hacia sentido suele cambiar a ser un producto distinto, un producto real y ejecutable.
Toma un poco de tiempo y planea qué piezas del prototipo se deben de pulir, que partes del prototipo se deben de descartar y replantea la lista de casos con los que vas a trabajar. Busca mantener tu feature o tu aplicación en el camino de resolver una sola cosa y hacer esa cosa muy bien.
Mientras menos flujos pueda tomar el usuario, más fácil es de realizar de la manera correcta. Mientras menos cosas haga tu aplicación, más fácil es de mantener. Decir que no a un feature o un caso de uso es una de las cosas más inteligentes que puedes hacer. Di que no seguido y explica por que no es necesario hacer eso, acabarás con una mejor aplicación.
Como nota al margen, recuerda a qué le has dicho que no muchas veces, puede que eso sea algo a lo que necesitas decir que si eventualmente.
Busca subir un poco de código a producción (o staging) todos los días y probar tu producto, mantén claro cual es el problema que quieres resolver y sé objetivo con lo que quieres resolver y sé altamente crítico tu producto y contigo mismo.
“If I had asked people what they wanted, they would have said faster horses.”
-- Henry Ford
Busca tener feedback loops muy cortos. Recolecta la mayor información posible de cómo se esta usando tu producto y entiende porqué pasa de esa manera. Muchas veces escuchar a tus usuarios al pie de la letra generará un producto mediocre, pero necesitas escucharlos y entender que muchas veces lo que te están diciendo es no saben como usar tu producto.
Una de las cosas mas complicadas de lograr es crear un producto que haga una sola cosa y que la haga bien, pero esto no es un objectivo, es un camino. No lo hagas más difícil caminando de la manera complicada, a oscuras y sin una forma de saber si vas en el camino correcto. Hazte la vida sencilla caminando con la gente correcta, con un stack de tecnología que conoces y con objetivos muy a corto plazo.
