Cómo equilibrar el diseño del software con la necesidad de documentar cómo usar el software

Para mí, la respuesta es simple, debe documentar lo que el cliente necesita saber. Cuanto más sepa sobre su cliente, más sabrá qué documentar (y qué no documentar).

Tal vez el cliente realmente necesita leer la documentación para usar el producto. Ahora, si el cliente quiere leer la documentación es un problema de desarrollo de producto / negocio para resolver, no un problema de documentación (lo abordaré en un minuto).

La usabilidad del software es como la usabilidad de cualquier otro producto. Si crea un producto que realiza algunas funciones obvias, pero importantes y útiles, no necesita mucha documentación. Toma un guante, por ejemplo. Su función es obvia y útil, pero limitada. ¿Cuánta documentación necesita?

Ahora toma una bola de estambre. Puede hacer mucho más que un guante. Se puede convertir en un suéter, una bufanda, un sombrero, calcetines, etc. Pero para hacer que el ovillo haga algo de eso, necesitará documentación, tal vez algo de capacitación y probablemente algunas herramientas adicionales.

Entonces, dados esos ejemplos como puntos finales, elija dónde cae su producto en el continuo entre ellos y ahí está su respuesta.

Desde la perspectiva del desarrollo del producto, desarrollar un guante es más difícil que desarrollar una bola de hilo, por lo que si ve un mercado de guantes, pero solo quiere gastar el esfuerzo para desarrollar bolas de hilo, agregar mucha documentación no servirá de puente Esa brecha por completo. Claro, proporcionará a los clientes la información y las herramientas para terminar con lo que quieren, pero se necesitará más que eso para que quieran hacer eso (en lugar de comprar guantes acabados de su competidor).

Del mismo modo, si ha creado una nueva bola de estambre, que la gente nunca ha visto antes y no tienen idea de qué hacer con ella, se necesitará más que solo documentación para mostrarles las posibilidades y despertar su imaginación. La documentación será un componente esencial de ese esfuerzo, pero no será, de hecho, no puede ser, el único componente.

Siempre debe hacer documentación para su software si su software no es tan básico o si no es necesario reutilizarlo.
Debe hacer la documentación para usted porque olvidará lo que hizo y por qué lo hizo y cómo lo hizo después de algún tiempo. Debe documentar para que otros entiendan y continúen desarrollando su software.