Los diez principios fundamentales para construir un DAO
1. Sistema simple y efectivo primero
Los sistemas complejos efectivos suelen surgir de sistemas simples y efectivos. Al diseñar un producto mínimo viable, se debe comenzar desde lo simple y evolucionar gradualmente hacia lo complejo.
2. Enfocarse en los motores clave
Aproximadamente el 80% de los resultados provienen del 20% de los esfuerzos clave. Al diseñar un producto mínimo viable, se deben identificar y centrarse en aquellos elementos centrales que pueden aportar el mayor valor.
3. Distribución razonable de recursos temporales
El trabajo a menudo se expande para llenar el tiempo o el presupuesto disponibles. Establecer plazos moderadamente urgentes pero alcanzables para los proyectos ayuda a mejorar la eficiencia.
4. Advertencia sobre la desnaturalización de indicadores
Cuando un indicador se convierte en un objetivo, puede que ya no sea una buena medida. Al construir sistemas complejos ( como la recaudación de fondos para bienes públicos o la verificación de identidad ), se debe tener cuidado al establecer los indicadores de evaluación.
5. Mantener un equipo pequeño
Aumentar la mano de obra para un proyecto retrasado puede agravar aún más la demora. Mantener un equipo de tamaño reducido suele ser más beneficioso para el avance del proyecto.
6. Aprovechar las tendencias de desarrollo tecnológico
La capacidad de cálculo se duplica cada dos años, mientras que el costo se reduce a la mitad. Esta tendencia crea enormes oportunidades en el campo de la tecnología, que vale la pena observar y aprovechar.
7. Buscar el efecto de red
El valor de la red es proporcional al cuadrado del número de usuarios. Al construir un sistema, se debe tener en cuenta la creación de un crecimiento de valor exponencial.
8. Preste atención a las limitaciones del tamaño social
La cantidad de relaciones sociales estables que los humanos pueden mantener tiene un límite cognitivo. A menos que sea necesario, se debe mantener un tamaño de equipo reducido. Si es necesario expandirse, se debe prestar atención a los mejores modelos de confianza en cada nivel.
9. Pensamiento de diseño modular
Hacer que cada módulo se concentre en una función y lograr una buena colaboración entre los módulos. Al construir software, se debe adoptar un enfoque modular.
10. La estructura organizativa afecta el diseño del sistema
El diseño del sistema a menudo refleja la estructura de comunicación de la organización. Se debe diseñar la organización como se diseña el software, pero prestando atención a las limitaciones de escalabilidad de la estructura general.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
9 me gusta
Recompensa
9
5
Compartir
Comentar
0/400
PancakeFlippa
· 07-20 15:13
Con tener manos es suficiente, no hay que hacer tantas teorías.
Ver originalesResponder0
EyeOfTheTokenStorm
· 07-17 22:10
La alienación de los indicadores es demasiado real, he visto demasiados DAO de cero valor.
Ver originalesResponder0
ProxyCollector
· 07-17 22:09
La regla del 80/20, ¿está bien?
Ver originalesResponder0
ForkThisDAO
· 07-17 22:06
Solo el camino recto puede llevarte lejos.
Ver originalesResponder0
EntryPositionAnalyst
· 07-17 22:06
Se habla de cosas ya conocidas, no hay muchos DAO que puedan sobrevivir.
Diez principios fundamentales para la construcción exitosa de un DAO - El camino de la evolución de lo simple a lo complejo
Los diez principios fundamentales para construir un DAO
1. Sistema simple y efectivo primero
Los sistemas complejos efectivos suelen surgir de sistemas simples y efectivos. Al diseñar un producto mínimo viable, se debe comenzar desde lo simple y evolucionar gradualmente hacia lo complejo.
2. Enfocarse en los motores clave
Aproximadamente el 80% de los resultados provienen del 20% de los esfuerzos clave. Al diseñar un producto mínimo viable, se deben identificar y centrarse en aquellos elementos centrales que pueden aportar el mayor valor.
3. Distribución razonable de recursos temporales
El trabajo a menudo se expande para llenar el tiempo o el presupuesto disponibles. Establecer plazos moderadamente urgentes pero alcanzables para los proyectos ayuda a mejorar la eficiencia.
4. Advertencia sobre la desnaturalización de indicadores
Cuando un indicador se convierte en un objetivo, puede que ya no sea una buena medida. Al construir sistemas complejos ( como la recaudación de fondos para bienes públicos o la verificación de identidad ), se debe tener cuidado al establecer los indicadores de evaluación.
5. Mantener un equipo pequeño
Aumentar la mano de obra para un proyecto retrasado puede agravar aún más la demora. Mantener un equipo de tamaño reducido suele ser más beneficioso para el avance del proyecto.
6. Aprovechar las tendencias de desarrollo tecnológico
La capacidad de cálculo se duplica cada dos años, mientras que el costo se reduce a la mitad. Esta tendencia crea enormes oportunidades en el campo de la tecnología, que vale la pena observar y aprovechar.
7. Buscar el efecto de red
El valor de la red es proporcional al cuadrado del número de usuarios. Al construir un sistema, se debe tener en cuenta la creación de un crecimiento de valor exponencial.
8. Preste atención a las limitaciones del tamaño social
La cantidad de relaciones sociales estables que los humanos pueden mantener tiene un límite cognitivo. A menos que sea necesario, se debe mantener un tamaño de equipo reducido. Si es necesario expandirse, se debe prestar atención a los mejores modelos de confianza en cada nivel.
9. Pensamiento de diseño modular
Hacer que cada módulo se concentre en una función y lograr una buena colaboración entre los módulos. Al construir software, se debe adoptar un enfoque modular.
10. La estructura organizativa afecta el diseño del sistema
El diseño del sistema a menudo refleja la estructura de comunicación de la organización. Se debe diseñar la organización como se diseña el software, pero prestando atención a las limitaciones de escalabilidad de la estructura general.