tipos software proyectos pmi pmbok para metodologia manager gratis gestión gestion español caracteristicas administracion project-management communication requirements summary

project management - software - ¿La mejor forma de comunicarse con un programador para definir un proyecto?



software gestion de proyectos gratis español (26)

¿Cuál es el mejor conjunto de detalles para dar a un programador para definir un proyecto?

En pocas palabras, sé lo que quiero hacer, pero no sé nada de programación y, entonces, ¿cuál es la mejor manera de definir mi proyecto para un programador para que me dé lo que necesito? es decir, resumen del proyecto, resumen de diseño, diagramas de flujo?

¿Cuál es el mejor conjunto de detalles para dar a un programador para definir un proyecto?

esto depende del proyecto, de su comprensión de lo que desea y de la comprensión del programador sobre el dominio comercial. Las historias de usuario, los casos de uso y las descripciones de las pruebas de unidad son geniales, pero la comprensión del programador sobre el dominio comercial es una base fundamental para todos estos.

En pocas palabras, sé lo que quiero hacer, pero no sé nada de programación

excelente, el primer paso es admitir que necesitas ayuda ;-)

y entonces, ¿cuál es la mejor manera de definir mi proyecto a un programador para que me dé lo que necesito? es decir, resumen del proyecto, resumen de diseño, diagramas de flujo?

ninguno de los anteriores: dado que usted no es un programador, no podrá escribir estas descripciones técnicas con precisión. ¡Tampoco deberías!

como otros han notado, debe decirle al programador lo que usted, el usuario, desea poder hacer. No cómo hacerlo, sino lo que el software le permitirá hacer. "Qué" son los requisitos, "cómo" es el diseño.

Primero y principal, sin embargo, el programador debe comprender el dominio comercial que subyace a los requisitos. Sin esta conexión a tierra, él / ella está operando en un vacío conceptual.

Una vez que el programador tenga una pista sobre su negocio, hable sobre la (s) aplicación (es) que necesita.

Proceda lentamente, escriba historias de usuarios, dibuje pantallas y haga maquetas de papel, acuerde los detalles de cómo hacerlo funcionar (con respecto al usuario) juntos . Explique al programador que, dado que este es su primer proyecto, realmente desea involucrarse en cada paso del proceso de inicio, pero una vez que ambos entiendan y acuerden cómo se debe hacer la aplicación, incluyendo qué pruebas debe aprobar para ser aceptado, entonces usted lo dejará solo para codificar mientras todavía esté disponible para preguntas.

No use un desarrollador sin experiencia para este primer proyecto , ya que dependerá de él para que le enseñe buenas prácticas.

EDITAR: y si tiene que crear más de una aplicación a lo largo del tiempo, elija un desarrollador que le guste y con el que cree que podría trabajar a largo plazo. Establezca una relación con él / ella basada en la confianza y el respeto mutuos. Hay muchos programadores realmente buenos con habilidades de personas cero; evítelos, ya que a la larga lo volverán loco.

  1. Un buen resumen / resumen de lo que necesita que haga la aplicación.
  2. Un buen resumen de los conocimientos específicos del negocio que el programador necesitaría para escribir la aplicación (por ejemplo, si necesita una calculadora de tasas de pólizas de seguro, el programador debería saber algo sobre cómo se calculan las tasas en general).
  3. Una descripción de los datos que se utilizarán / requerirán, y muestras si los tiene (por ejemplo, muestras de hojas de cálculo de Excel, archivos de datos, etc.).
  4. Si el nuevo proyecto es un reemplazo de una aplicación anterior, las copias de la aplicación anterior (el código fuente es bueno si la tiene) son una fuente de información invaluable para un programador.

Algunos pueden estar en desacuerdo, pero generalmente encuentro que los diagramas de flujo generalmente no son muy valiosos.

Algunas buenas sugerencias anteriores de los otros carteles.

Definir lo básico de lo que quieres es un comienzo obvio. Pero en mi experiencia, lo que también puede perjudicar el proceso aguas abajo es cuando las excepciones no son consideradas. Estos casi siempre se olvidan hasta después de que el software se haya desarrollado o se haya demorado en las pruebas. Así que ponte un poco de esfuerzo para pensar cómo quieres que el software o el proceso funcionen cuando las cosas no van bien. Ejemplos:

  • ¿De dónde provienen los datos fundamentales? Cuando los datos no están donde se espera que estén, ¿qué quieres hacer?
  • ¿Cuánto quiere que haga el software con respecto a la validación? Si el usuario ingresa datos incorrectos, ¿tiene un proceso manual para que ellos lo reparen, o espera que el software sea lo suficientemente inteligente como para facilitar la corrección? El nivel de inteligencia que desea que tenga el software al abordar excepciones puede cambiar significativamente la complejidad.
  • ¿Cuánta transparencia de datos necesita? Es posible que solo necesite algunos elementos, pero si hay una excepción, proporcionar datos adicionales puede significar la diferencia entre que el usuario sea capaz de autoayudarse, y que tenga que ponerse en contacto con un servicio de ayuda, otros usuarios y un programador. que es considerablemente más caro

A los programadores les gusta ayudar, pero no tanto ... preferirían trabajar en la próxima función que no sea la de producción. Pero si las especificaciones de manejo de excepciones son deficientes, eso es exactamente lo que todos los integrantes del proyecto terminarán haciendo.

Definitivamente puede ayudar a difundir su proceso de requisitos sobre el ciclo de desarrollo a través del desarrollo iterativo. No siempre sabes qué tipo de excepciones necesitarás manejar. Algunos no son impulsados ​​por el negocio, sino por problemas técnicos, como el comportamiento de la interfaz de usuario, la integración con otros sistemas, etc. Sin embargo, aun con esto, cuanto mejores sean los requisitos de calidad que pueda entregar antes, mejor será el proceso general.

Déles los pasos que serán necesarios para que pueda obtener el resultado deseado de la página. Si ha visto otras páginas que se parecen a lo que quiere, déselo como ejemplo. ¡Pero lo más importante es ser específico sobre lo que quieres! Si no sabes lo que quieres, no puedes esperar que lo hagan.

Desde mi punto de vista técnico:

Lo más obvio es que no hacen suposiciones sobre cómo la característica X debería diseñarse / implementarse.

Pero más importante aún, según mi experiencia reciente, lo que sucede es que el propietario / cliente del producto tiene algunos hábitos o usa algunas herramientas para lograr ciertas tareas. Luego, en lugar de explicar su experiencia práctica, abstrae lo que él piensa como un concepto general, y esto lleva a una falla de comunicación donde ambos lados (el dueño del producto y los técnicos) se miran unos a otros como dorks desorientados. No puede lograr nada juntos hasta que todos tengan un vocabulario común. Detenga la conversación tan pronto como algo no parezca claro e intente definir cada palabra.

Algunos ejemplos :

  • El cliente quiere la aplicación "al igual que MS Word", cuando lo que necesita son solo unos pocos accesos directos para formatear su texto. El técnico debe colocar al cliente frente a un documento de MS Word y hacer que muestre exactamente qué características necesita.
  • mi experiencia personal reciente: el cliente sigue preguntando "¿qué CMS usa?" - aunque realmente ningún CMS listo para usar satisfaría sus necesidades, además, o bien A) simplemente está repitiendo "CMS" como un loro porque le dijeron que B) que ha usado, o ha oído hablar de, algún software que se llamó a sí mismo un "CMS". Realmente, el técnico no debe tratar de evitar este malentendido mintiendo (que es la salida más fácil, pero el contratiempo lo empeorará). Nuevamente, la demostración práctica de alguna característica existente de lo que el cliente tiene en su cabeza sin poder poner palabras en ella debería conducir a una solución, y, de nuevo, a un vocabulario común.

Y, finalmente, no trates de pensar en todo por adelantado, son demasiadas suposiciones para hacer. Trabaja iterativamente El software es "suave", esto significa que puede cambiar. Es mejor hacer pequeños cambios a lo largo del tiempo que ser obstinado con las suposiciones iniciales.

En cuanto a la gestión de proyectos, recientemente la metodología SCRUM me ayudó a resolver todo tipo de fallas de comunicación. Al menos, debido a su transparencia, dicha metodología permite ver lo que podría causar una falla antes de perder demasiado tiempo o dinero.

Diseña tus requisitos. ¿Qué es lo que necesita hacer? No solo le diga lo que quiere como producto final, sino una lista de objetivos a corto y largo plazo.

Como dije ... Requisitos, Requisitos, Requisitos.

En mi experiencia, es una mala idea tratar de definir lo que quieres por adelantado, tirarlo al otro lado de la pared y esperar que un programador te brinde exactamente lo que quieres. Lo más difícil de crear software es su complejidad, si especifica exactamente lo que desea, probablemente haya proporcionado tantos detalles como cuando lo había programado usted mismo.

Lo mejor que puede hacer es tratar de trabajar junto con el programador. Encuentre a alguien que pueda entregar software en incrementos cortos, una vez al mes o una vez cada dos semanas. Y da tu opinión sobre lo que te gusta, lo que no te gusta y lo que más quieres. Intente asegurarse de que el programador le proporcione software probado y en funcionamiento cada vez para que pueda ver realmente cuánto se está haciendo.

Esta forma de trabajar le brinda la posibilidad de priorizar exactamente qué características considera importantes. Usted los ha implementado primero. El inconveniente es que esto le costará más tiempo y esfuerzo.

Es difícil obtener una idea compleja como una porción entera de software en palabras, para eso es un documento de requisitos. Se ha dicho en otras publicaciones; necesita especificar exactamente lo que quiere que se haga, sin dejar absolutamente ninguna suposición. Dos personas pueden imaginar algo de maneras muy diferentes a partir de la misma explicación, por eso es tan importante especificar qué es exactamente lo que quieres que se haga.

También los requisitos previos. Asegúrese de decirle al programador en qué entorno debe ejecutarse, ¿es para un escritorio o un servidor y cuánto RAM y qué sistema operativo?

No tiene que especificar CÓMO funciona, ese es realmente el trabajo de los programadores para averiguarlo. Puede guiarlo en eso si tiene algunas ideas, pero el programador debe tener suficiente experiencia o entrenamiento para diseñar las partes internas.

Realmente se trata de lo externo, debe ser muy claro sobre las entradas requeridas y las salidas requeridas, ya sean interfaces gráficas de usuario o interfaces programáticas. ¡Necesitas saber lo que quieres antes de que pueda saber lo que quieres!

Esto es realmente una especificación de requisitos y un problema de gestión. Yo les daría lo que sea que tengas. Trate de describirlo claramente en inglés simple (o en el idioma que sea apropiado). Si puedes hacer un diagrama de flujo, hazlo también.

Debería esperar que el programador haga algunas preguntas y luego se vaya a pensar, pero también debe esperar que vuelvan con más preguntas para usted, para aclarar los requisitos. Si no hacen eso dentro de una semana más o menos, debe consultar con ellos para darles la oportunidad de preguntar.

Si el proyecto es compatible con él, puede configurarse para ver prototipos tempranos que funcionen.

Hagas lo que hagas, escríbelo y fírmalo .

Luego, entrégueselas, y acepte que se las retenga con las instrucciones en el papel.

El mayor problema que tenemos como desarrolladores son especificaciones incompletas o mal traducidas, y lo que realmente nos gustaría es una hoja de papel que sea clara como el cristal, y usted debería poder acudir a nosotros con cualquier problema en el proyecto, y debe remitirse a en el documento en terminología cristalina-como-usada-por-abogados.

Al menos de esa manera podemos decir "mira, hicimos lo que pediste, aquí está por escrito, no se puede esperar de mí nada que no esté escrito aquí, no está sucediendo".

Puede que esto no suene muy bien, pero confía en mí, no te gusta, te hará esforzarte más para aclararlo. Y si un objetivo no se incluye en el documento, no intente algo así como deslizarlo más tarde, reescribir la especificación después de que los requisitos lo hagan obtener cosas exageradas.

Planee un hito, apúntelo, hágalo. Algo se pierde, va a un hito posterior. No puedes hacer esto, y nunca se enviará.

De aquellos que me han bajado la votación FYI, todos los que conozco tienen este problema. Apesta. Tengo asociados que fueron chantajeados por empresas que sobregiraban las especificaciones tratando de deslizarse en cosas que nunca se discutieron. No puede esperar que alguien haga algo que no fue recetado. Ni siquiera es posible. Tal vez sea en tierra de fantasía o en esa cosa de "realidad corporativa" sobre la que siempre estás hablando, pero no en el mundo real.

Al construir una casa, uno no "ala".

Una casa construida por una familia hogareña que se hace a medida que toman una decisión sobre cómo hacerlo lleva años construirla. </ rant>

La mejor manera de especificar sus requisitos es desde la perspectiva del usuario. Si describes casos de uso específicos para tus programadores, esto lo hace mucho más claro. Para nosotros es útil saber qué está tratando de lograr el usuario con nuestro software, por lo que no construimos ninguna de nuestras suposiciones.

Necesita encontrar un programador que tenga experiencia escribiendo aplicaciones personalizadas para personas no técnicas. Esta persona también debe tener experiencia técnica en administración de proyectos. Él (o ella) debería crear, con su ayuda, un documento de requisitos y una especificación funcional, que se cerrará antes de que comience el desarrollo real. Una persona que es realmente buena en esto tiene mucha experiencia y no será barata, pero tratar con clientes no técnicos es tan difícil para muchos desarrolladores como tratar con desarrolladores es para ti.

Incluso si lo aprueba, eso no significa que las cosas no se puedan cambiar más adelante. Si desea cambios, actualizará sus documentos y su desarrollador le dará una nueva estimación del costo y el tiempo.

Ahora para el problema de la gallina o el huevo. Si no eres técnico, ¿cómo encuentras un buen desarrollador de software? Pregunta a las personas que conoces para recomendaciones. Si necesita entrevistar a alguien, pídales que traigan un documento de requisitos de muestra y especificaciones funcionales. Visite los sitios web que han desarrollado. Sin duda, esto eliminará a muchos programadores totalmente calificados, ya que muchos no pueden compartir este tipo de cosas debido a problemas de confidencialidad. Pero está en una posición en la que necesita saber que puede comprender las necesidades de su negocio y crear un producto para resolver esas necesidades.

Si no está satisfecho con el documento de requisitos y la especificación funcional, no continúe con esa persona. Las cosas empeorarán, no mejorarán. Terminarás arrojando un buen dinero después de malo.

Es realmente difícil comunicarse con muchos desarrolladores. Como encontrar un médico, encuentre uno con el que se sienta cómodo, que lo escuche a usted y a sus inquietudes, y pueda repetir esas inquietudes con sus propias palabras.

¡Buena suerte!

No hay una forma particular que use para comunicarse con un programador. Es una pregunta muy genérica y necesita agregar más detalles sobre lo que quiere, qué tipo de aplicación está buscando, etc.

Yo personalmente trabajo mucho en el nivel de interfaz de usuario de un sitio web y prefiero capturas de pantalla con cada solicitud que recibimos. Una imagen vale más que mil palabras en mi caso. Una persona que escribe un motor de búsqueda o un rastreador no necesitaría una captura de pantalla en absoluto. También prefiero las especificaciones técnicas bien redactadas sobre lo que espera, cuándo lo quiere y algunos ejemplos.

Además, asegúrese de revisar lo que haya especificado. Algunas veces, sus necesidades pueden no coincidir con la descripción inicial.

Por sus auriculares :)

Solo para agregar a lo que otros han dicho aquí, tienes que ser MUCHO más específico si se trata de un proyecto subcontratado en comparación con un proyecto interno. Y no me importa si subcontratas a India, China o los muchachos de la calle. Si no eres específico, es probable que obtengas algo que satisfaga lo mínimo de lo que pones en papel, pero no que querías. Es más probable que los programadores internos soliciten una aclaración y hagan lo que usted quiere decir en lugar de solo lo que solicitó.

Su mejor opción es encontrar un programador que tenga talento para desarrollar especificaciones de clientes no técnicos. Las recomendaciones de boca en boca de otros clientes probablemente sean la forma más confiable de encontrar programadores que puedan hacer esto.

En serio, este es en realidad el escenario típico para todos los desarrolladores. El cliente generalmente no tiene experiencia técnica y muy poco deseo de profundizar en problemas de programación. A menudo ni siquiera saben realmente lo que quieren, y mucho menos lo que es posible. Por lo tanto, recae sobre los hombros del desarrollador cerrar la brecha, conectarse con el cliente y convertir las ideas del cliente en consideraciones técnicas.

Para mantener el rumbo, recomendaría hacer el trabajo en T & M de manera iterativa. Haga revisiones y demostraciones frecuentes del sistema a medida que se desarrolla, haga comentarios sobre lo que ve y vuelva a evaluar el valor del sistema y la calidad del desarrollo que ve. Jale el enchufe si siente que tiene forma de pera.

Estoy constantemente atónito por lo mal que la mayoría de las personas no técnicas prevén soluciones de software antes de que se entreguen. Me he sentado en innumerables reuniones tempranas del proyecto en las que podía garantizar que cada programador en la sala estaba construyendo la misma imagen en su cabeza, incluyendo la visión de cómo se necesitarán las llamadas de subrutina para ciertas funciones, pero los clientes en la misma reunión no están t en la misma página en absoluto. Con demasiada frecuencia, este abismo no se conoce hasta que el cliente realmente ve el producto, que es exactamente lo que los programadores describieron en la reunión de lanzamiento, y señalan algún defecto obvio (para ellos).

Eso solo duele si el cliente no puede ver el producto hasta el final del desarrollo. Así que búscalo temprano, míralo a menudo y da tu opinión.

USB 2.0 (o RS232 para los más antiguos).

Usa la metodología SCRUM.

Describa cosas en términos de "Historias de usuarios" (Lo que un usuario quiere hacer).
Describa cómo "Historias de usuarios" interactúan entre sí.

Deje que el desarrollador descubra cómo.

Haga que él / ella demuestre lo que han hecho a intervalos regulares. Si cambias de opinión o no está yendo como a ti te gusta, entonces puedes actualizar al desarrollador sobre dónde estaba yendo mal y él puede actualizar su dirección.

Las especificaciones / requisitos y la metodología de cascada han demostrado una y otra vez que no funcionan (o debería decir proporcionar un método para planificar con precisión un proyecto).

<sarcasm> Proporcione detalles y detalles y obtendrá exactamente lo que pidió, no lo que quería .</sarcasm>

En serio, los detalles son buenos hasta cierto punto.

Nunca suponga que el desarrollador entiende su oficio o incluso quiere aprenderlo. He descubierto que muchos desarrolladores no quieren comprender las ciencias de la contabilidad, la radiología o cualquier otro tipo de comercio en el que estén involucrados. Si se toman algún tiempo para aprender, es solo en el nivel más superficial.

Los detalles o decisiones mundanas que son fundamentales para su comercio o flujo de trabajo no serán obvios para los desarrolladores. Algo tan simple como el orden de campo o tabulación en una página puede perderse en el desarrollador porque nunca tuvieron que ingresar sus datos. O el hecho de que dos datos estén relacionados puede ser obvio para ti, pero pueden parecer completamente desconectados del desarrollador. Tal vez el flujo de trabajo se ajusta a un cierto patrón, excepto cuando ocurre un evento o situación específica ...

Esté preparado para enseñarles piezas de su oficio (incluso si no lo desean) y asegúrese de que entiendan qué es lo que realmente hace. Esta es el área en la que he tenido más resistencia por parte de los desarrolladores: tienden a pensar que entienden cuando en realidad no lo hacen. Esto no es por malicia de su parte, solo la simple realidad de que muchos trabajos son fáciles de aprender, pero difíciles de dominar.

  • Da ejemplos detallados. Los programadores los llaman casos de uso o historias de usuarios.
  • Indique claramente sus requisitos. Necesito obtener el nombre del empleado, la dirección y el número de teléfono de la base de datos, es mucho mejor que el que necesito para obtener información sobre el empleado.
  • Incluye todo lo que quieras que haga ahora y lo que crees que podrías querer en el futuro.
  • Priorizar Háganos saber lo que se requiere, lo que le gustaría y lo que no es importante.

Muchos de los programadores que conozco aprenden muy rápido y tienen una habilidad innata para detectar inconsistencias, alternativas y simplificaciones.

Puede hacer lo mejor para enseñarle acerca de su dominio: si usted mismo tuvo una buena intuición sobre lo que se debe construir, él descubrirá lo mismo, y luego podrá analizar los detalles.

Es muy posible que, al conocer tu dominio, te sugiera una solución más simple o radicalmente diferente a un nivel superior que haga desaparecer tu primer problema, o una herramienta existente que puedas usar fácilmente.

Si está tratando de definir un proyecto para construir manubrios con calefacción, una hora hablando con un buen programador lo llevará a sugerir guantes.

Me sucedió esto a mí: un cliente estaba dispuesto a pagarme para construir algo, y después de una conversación de 20 minutos, les indiqué una herramienta de código abierto existente que resolvía su problema en el caso general. Simplemente no tenían el conocimiento o la mentalidad para analizar su problema en esa medida.

El punto más importante de todo esto es que se trata de un diálogo : necesitas compartir tus conocimientos con el desarrollador y trabajar juntos para encontrar una solución. Lanzar un brief de diseño y una especificación sobre la pared no es suficiente, porque no está aprovechando sus habilidades para atacar el problema.

¿La mejor forma de comunicarse con un programador para definir un proyecto?

Buena pregunta. Un par de soluciones.

  • Descripción general del proyecto / resumen de diseño - (herramienta gratuita www.createbrief.com )
  • Crear un alcance de proyecto (yo uso Evernote para esto)
  • Problemas abiertos en Github Scrum Boards (Via Zenhub )

El resumen es para ayudar a darle al desarrollador una gran visión general de trazos de pincel, mientras que el alcance del proyecto entrará en mucho más detalle. En los ámbitos del proyecto, normalmente bosquejo las vistas y el procesamiento uno junto al otro. Después de crear ambos documentos, abro problemas en Github con Zenhub Scrum Boards para administrar cada tarea y prioridad. Esto también le ayuda a asignar múltiples problemas a múltiples programadores.

¡La mejor de las suertes!

Paso 1. Describe tu problema en oraciones simples en inglés. No tiene que ser detallado, pero debe cubrir todos los aspectos de su problema.

Paso 2. Extraiga todos los sustantivos en las declaraciones de problemas anteriores y proporcione definiciones precisas de los términos. Cuanto más simple es el término, más precisa es la definición porque las personas significan cosas diferentes.

Paso 3. En un pedazo grande de papel, dibuja cajas para cada término y conecta las cajas con líneas o flechas donde se relaciona. Ignore la cosa (0 .. *), pero el diagrama debería verse como el siguiente. Recuerde, sin una buena definición de los términos, los diagramas no significan mucho.

Paso 4. A continuación, proponga escenarios simples que un usuario final puede llevar al programa junto con los resultados esperados del programa. Por ejemplo:

  1. El usuario presiona 1 botón.
  2. El sistema debe mostrar "1" (sin comillas, pero incluye el período).
  3. El usuario presiona el botón +.
  4. El usuario presiona el botón 2.
  5. El sistema debe mostrar "2" (sin comillas, pero incluye el período).
  6. El usuario presiona = botón.
  7. El sistema mostrará la suma de 1 y 2 con un período, que es "3". .

Una tarea puede referirse a otras tareas, y debe especificar que el sistema lo haga cuando el usuario ingrese un mensaje inválido (como enviar un correo electrónico a los administradores). La idea es crear escenarios comprobables con los que usted y el programador puedan verificar el programa. Estos mini escenarios se llaman casos de uso.

Paso 5. Reúnase con el programador regularmente (cada dos semanas, por ejemplo) y especifique en qué tarea debe trabajarse y en qué tarea NO se debe trabajar. Es importante especificar qué NO hacer, ya que sin tales instrucciones los programadores tienden a hacer lo que creen que es correcto , lo que se conoce como Codificación Cowboy. Actualice los términos, diagramas o casos de uso si es necesario.

Paso 6. Cuando se reúna con los programadores, exija que quiera ver el programa y jugar con él. Verifique si el programa hace lo que acordó. Diles lo que te gusta y lo que no te gusta.

Evita suposiciones. Explicar con tanto detalle como puedas lo que quieres que se haga. Asegúrese de que todas las preguntas se puedan responder con "sí", "no" o X, donde X es un valor definitivo. No deje nada a la interpretación o cualquiera de sus instrucciones.

Especifique cada elemento que debería estar disponible para el usuario final, su comportamiento y estilo. Asegúrese de que USTED sepa exactamente lo que desea, antes de pedirle a alguien que lo codifique.

Y asegúrese de que su documentación esté bien organizada. Estoy seguro de que puede encontrar muchos informes sobre requisitos comerciales en línea.