{"id":55846,"date":"2018-05-03T07:32:04","date_gmt":"2018-05-03T07:32:04","guid":{"rendered":"https:\/\/blog.salesflare.com\/?p=55846"},"modified":"2026-02-23T16:13:28","modified_gmt":"2026-02-23T15:13:28","slug":"how-to-organize-development-in-a-lean-software-startup-108bf51ab123","status":"publish","type":"post","link":"https:\/\/blog.salesflare.com\/es\/como-organizar-el-desarrollo-en-una-startup-de-lean-software-108bf51ab123-2","title":{"rendered":"C\u00f3mo organizar el desarrollo en una startup de software lean"},"content":{"rendered":"
\n
<\/header>\n

C\u00f3mo organizar el desarrollo en una startup de software lean<\/h1>\n

Interior Salesflare<\/h2>\n
\n
\n
\n
\n

Crear una empresa tecnol\u00f3gica puede ser un proceso ca\u00f3tico, estresante y gratificante.<\/p>\n

Pero una de las cosas que realmente puede ayudar desde el principio es disponer de estructuras que permitan a su equipo trabajar de forma eficaz y eficiente, especialmente en la parte de desarrollo. Lo \u00faltimo que necesita tu empresa es caos en torno a la construcci\u00f3n de tu producto. \ud83d\ude31<\/p>\n

\u00bfC\u00f3mo empezar? \u00bfY si contrata externamente o contrata internamente<\/a>?<\/p>\n

A continuaci\u00f3n encontrar\u00e1 una gu\u00eda r\u00e1pida para crear y estructurar su equipo de desarrollo de SaaS<\/a> - y si decide subcontratar, tambi\u00e9n puede utilizar esta gu\u00eda como marco de trabajo. \ud83e\udd29<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Categorizar el desarrollo en su empresa<\/strong><\/h4>\n

Una de las cosas que puede ayudar con la estructura de desarrollo es desglosar los diferentes tipos de tareas de desarrollo en la empresa en categor\u00edas, para que pueda tener una mejor idea de priorizaci\u00f3n, delegaci\u00f3n y organizaci\u00f3n dentro del equipo. \ud83e\udd1d<\/p>\n

A continuaci\u00f3n figuran las tres categor\u00edas de desarrollo que tenemos en Salesflare:<\/p>\n

Cuestiones <\/strong>son cosas que no funcionan y que hay que arreglar en el producto.<\/p>\n

Pero, \u00bfqu\u00e9 tiene prioridad? \u00bfY c\u00f3mo se organizan? Por eso hemos dividido las cuestiones en tres categor\u00edas adicionales: cuestiones instant\u00e1neas, puesta en escena instant\u00e1nea<\/a> y cuestiones no instant\u00e1neas.<\/p>\n

Los problemas instant\u00e1neos son los que -lo has adivinado- deben solucionarse de inmediato. Pueden ser cosas que est\u00e1n realmente<\/em> rotas, cosas que los usuarios notan, cosas de la app que hay que arreglar, etc. \ud83d\udea8<\/p>\n

<\/figure>\n

\"hombre<\/p>\n

La puesta en escena instant\u00e1nea no es tan \"instant\u00e1nea\" como los problemas instant\u00e1neos, pero son cosas que hay que arreglar antes de lanzar la versi\u00f3n m\u00e1s reciente del software al entorno de producci\u00f3n. Se trata sobre todo de problemas que detectamos en nuestro entorno de ensayo mediante pruebas internas.<\/p>\n

Los problemas no instant\u00e1neos son de menor prioridad y se debaten en la reuni\u00f3n de preparaci\u00f3n del sprint (m\u00e1s adelante hablaremos de ello).<\/p>\n

Mejoras en la experiencia del usuario <\/strong>tienen mayor prioridad que los problemas no instant\u00e1neos e incluyen cualquier cosa en desarrollo que tenga que ver con la experiencia y la usabilidad del producto. B\u00e1sicamente, se trata de cosas que mejoran la experiencia de los clientes.<\/p>\n

Caracter\u00edsticas <\/strong>son nuevas funcionalidades que queremos a\u00f1adir al producto, como acciones masivas, filtrado avanzado, etc. Son las tareas menos prioritarias de las planificadas durante un sprint.<\/p>\n

Aunque desglosar los tipos de desarrollo puede ayudarle a organizar mejor su equipo, \u00bfc\u00f3mo decidir qui\u00e9n se ocupa de qu\u00e9?<\/p>\n

\n
\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

\u00a1Support Hero est\u00e1 aqu\u00ed para salvar el d\u00eda!<\/strong><\/h4>\n

Como empresa de SaaS que somos, comprendemos la importancia de resolver los problemas r\u00e1pidamente para ofrecer a los clientes la mejor experiencia posible. Sin embargo, eso no significa que todo el equipo deba pasarse el d\u00eda ocup\u00e1ndose de los problemas, \u00a1nunca conseguir\u00edamos hacer ning\u00fan otro trabajo! \ud83d\udc68\u200d\ud83d\udcbb\ud83d\udc69\u200d\ud83d\udcbb<\/p>\n

Por eso utilizamos un sistema que elimina las distracciones y aumenta la productividad del equipo de desarrollo. Lo llamamos Support Hero.<\/p>\n

\n
<\/div>\n<\/figure>\n

\"superman\"<\/p>\n

El Support Hero es una persona del equipo de desarrollo, que rota a diario, que se centra en los problemas instant\u00e1neos que hay que resolver (y responde a preguntas m\u00e1s profundas y t\u00e9cnicas que tengan los usuarios), para que el equipo pueda seguir centrado en sus tareas. \ud83d\udcaa<\/p>\n

Cualquier problema que no pueda ser solucionado en ese preciso momento por el Support Hero se registra en GitHub, el software que utilizamos para la gesti\u00f3n de c\u00f3digo y problemas, y se aborda lo antes posible.<\/p>\n

Lo bueno de contar con un Support Hero es que, incluso con un equipo peque\u00f1o, puede ofrecer asistencia de alta calidad a sus clientes: cualquier problema t\u00e9cnico en profundidad puede solucionarse al momento, evitando el frustrante proceso de tener que pasar los problemas a la persona \"adecuada\".<\/p>\n

La mejor parte: tener un Support Hero acerca a tus desarrolladores a tus clientes. \ud83d\udc9b<\/strong><\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Todo es cuesti\u00f3n de estructura<\/strong><\/h4>\n

Ahora que hemos hablado de los tipos de desarrollo y de c\u00f3mo delegar asuntos, vamos a discutir c\u00f3mo organizar<\/em> su estructura. Todos los diferentes componentes a continuaci\u00f3n se unen para informar c\u00f3mo avanza el equipo.<\/p>\n

Una visi\u00f3n del producto y una hoja de ruta <\/strong>puede ayudarte a saber a d\u00f3nde quieres llevar el producto, para que luego puedas tener en mente caracter\u00edsticas que te lleven all\u00ed - esto idealmente se superpone con lo que recoges de tu apoyo. \ud83d\udc53<\/p>\n

Ayuda<\/strong> es todo sobre las opiniones de los clientes<\/a>. Esto incluye peticiones de funciones, problemas y mejoras de UX, que siguen la visi\u00f3n del producto y la hoja de ruta antes mencionadas. Reg\u00edstrelas y ll\u00e9velas a la reuni\u00f3n de preparaci\u00f3n del sprint.<\/p>\n

Un gestor de incidencias<\/strong> informa de errores tanto en el back-end como en el front-end. Tambi\u00e9n le permite ver qu\u00e9 problemas aparecen incluso sin que la gente se lo diga. Una sugerencia es Elastic APM - pero hay muchas opciones por ah\u00ed.<\/p>\n

Pruebas internas<\/strong> permite a todo su equipo probar nuevas funciones antes de que salgan al mercado. Realizamos pruebas de forma activa antes de pasar las actualizaciones de la fase de pruebas a la de producci\u00f3n. Y como utilizamos Salesflare internamente, tambi\u00e9n podemos detectar posibles problemas y mejoras en el producto. Siempre es bueno que su equipo utilice su producto siempre que sea posible para conocer de primera mano cualquier problema que pueda surgir y tener un conocimiento profundo de su propio producto.<\/p>\n

Hotjar <\/strong>Las sesiones de grabaci\u00f3n pueden ayudar a tu equipo a ver c\u00f3mo interact\u00faa la gente con el producto y d\u00f3nde van las cosas mal (o bien). Las grabaciones de usuarios, aunque no son necesarias a diario, pueden ofrecerte informaci\u00f3n adicional sobre c\u00f3mo utiliza la gente tu producto, ya que puedes ver lo que hacen sin necesidad de que te lo expliquen.<\/p>\n

\n
\n
<\/div>\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

\u00a1Hora de esprintar!<\/strong><\/h4>\n

Estructure el trabajo de su equipo de desarrollo en sprints, una metodolog\u00eda \u00e1gil. Como pauta general, los sprints de dos semanas de duraci\u00f3n son los m\u00e1s habituales para TI y desarrollo de productos de software.<\/a> \ud83c\udfc3\u200d<\/p>\n

Sin embargo, se recomienda prepararse antes de las reuniones del sprint, ya que de lo contrario las cosas pueden volverse un poco ca\u00f3ticas y salirse del tema.<\/p>\n

Esto puede solucionarse con reuniones de preparaci\u00f3n del sprint. El director de tecnolog\u00eda, el propietario del producto y el gestor del producto (m\u00e1s informaci\u00f3n sobre la diferencia entre propietario del producto y gestor del producto<\/a>) asisten a esta reuni\u00f3n y aprovechan el tiempo para analizar los problemas instant\u00e1neos pendientes, las mejoras de UX, los problemas no instant\u00e1neos y las caracter\u00edsticas. Esto ayuda a establecer la agenda y las prioridades para el pr\u00f3ximo sprint sin necesidad de sacar tiempo de la propia reuni\u00f3n del sprint. \u2705<\/p>\n

Despu\u00e9s, por supuesto, llega el momento de la reuni\u00f3n del sprint. La reuni\u00f3n del sprint se centra t\u00e9cnicamente en lo que se debati\u00f3 durante la reuni\u00f3n de preparaci\u00f3n del sprint, para que el equipo de desarrollo sepa exactamente c\u00f3mo van a hacer las cosas. Tambi\u00e9n proporciona una plataforma para revisar los problemas instant\u00e1neos juntos como un equipo. En esta reuni\u00f3n deben participar el CTO y el equipo de desarrollo<\/a>. El propietario del producto y el equipo de soporte tambi\u00e9n pueden participar, pero son menos necesarios en esta fase.<\/p>\n

Al comienzo de esta reuni\u00f3n, es una buena idea reflexionar sobre el sprint anterior: qu\u00e9 sali\u00f3 bien, qu\u00e9 sali\u00f3 mal, etc.<\/p>\n

\n
\n
<\/div>\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

\u00bfQu\u00e9 hay en tu caja de herramientas?<\/strong><\/h4>\n

Las herramientas que utiliza en su empresa pueden contribuir al \u00e9xito de su equipo de desarrollo. Ya hemos hablado de Hotjar y Elastic APM, pero algunas otras herramientas a considerar para una comunicaci\u00f3n m\u00e1s \u00e1gil y gesti\u00f3n de tareas<\/a> incluyen:<\/p>\n

Slack - <\/strong>para debates internos, actualizaciones\/notificaciones, intercambio de archivos y alg\u00fan que otro gif gracioso.<\/p>\n

Trello - <\/strong>para tarea\/gesti\u00f3n y seguimiento de proyectos<\/a> qui\u00e9n hace qu\u00e9 en un sprint determinado<\/p>\n

GitHub - <\/strong>donde registramos los problemas, las solicitudes de funciones, etc.<\/p>\n

Intercom - <\/strong>para comunicarse con los clientes<\/p>\n

Un aspecto estupendo del uso de estas herramientas es que pueden interactuar entre s\u00ed. Por ejemplo, recibimos actualizaciones de Trello y Github en Slack. Y en Trello usamos un potenciador de GitHub que integra la informaci\u00f3n de GitHub en Trello. \ud83c\udf10<\/p>\n

Adem\u00e1s, podemos vincular GitHub a las conversaciones de Intercom, de modo que siempre tengamos el contexto a mano; y cuando lanzamos funciones o solucionamos problemas, podemos comunicarnos al respecto sin fallos.<\/p>\n

\n
\n
<\/div>\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Independientemente de c\u00f3mo decidas estructurar el desarrollo en tu empresa, siempre es importante asegurarte de que tu equipo, por grande o peque\u00f1o que sea, pueda trabajar dentro de los procesos que decidas utilizar. \ud83d\ude80<\/p>\n

No tengas miedo de cambiar las cosas si no funcionan. La clave est\u00e1 en encontrar lo que funciona para ti y para tu empresa y seguir por ese camino.<\/p>\n

Esperamos que esta gu\u00eda r\u00e1pida le haya servido de inspiraci\u00f3n para crear y estructurar su equipo de desarrollo.<\/p>\n

\u00bfTienes m\u00e1s ideas? \u00a1Cu\u00e9ntanoslo en los comentarios! \u2728<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

\u00bfLe ha gustado este art\u00edculo? Consulte el resto de nuestros <\/em>Interior Salesflare<\/em><\/a> serie.<\/em><\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Para m\u00e1s informaci\u00f3n sobre startups, marketing de crecimiento y ventas<\/em><\/p>\n

\ud83d\udc49<\/em><\/strong>suscr\u00edbase aqu\u00ed<\/em><\/strong><\/a><\/p>\n

\ud83d\udc49sigue a @salesflare en <\/em><\/strong>Twitter<\/em><\/strong><\/a> o <\/em><\/strong>Facebook<\/em><\/strong><\/a><\/p>\n<\/div>\n<\/div>\n<\/section>\n<\/section>\n