Preparación para el desarrollo web y flujo de trabajo completo del proyecto


9

Trabajo como programador solitario en proyectos de desarrollo web (front-end y back-end): he completado un par de proyectos, así que soy bastante nuevo en esto, he leído y probado algunos enfoques y he llegado a un camino a cerca de ellos. La pregunta y mi descripción son bastante largas, así que tenga paciencia.

Lo que estoy buscando es:
1. Preparación / planificación que normalmente se realizaría antes de comenzar el desarrollo, una vez que sepa exactamente qué se necesita construir.
2. Por su experiencia, por favor deme comentarios / sugerencias sobre el proceso que sigo actualmente.

Los clientes con los que trabajo son generalmente nuevas empresas y tienen presupuestos limitados, por lo que no puedo cobrarles por hora (creo que así es como las grandes empresas suelen facturar a sus clientes [por hora / hombre] por proyectos de desarrollo) y tienen que Trabajar con un presupuesto fijo.

Este es el proceso que sigo actualmente:
1. Calcule el alcance del proyecto e intente comprender lo que están tratando de lograr en un par de reuniones.
2. Dales una cifra aproximada del estadio de béisbol con una cita que describa en general lo que esperan obtener del proyecto. Intento ser específico sobre las características, pero no estoy dedicando demasiado tiempo a esto porque sé que Es posible que el cliente solo solicite cotizaciones y no convierta realmente.
3. Sigo la sugerencia de Jeff Atwood para pago y trabajo:

Pago del 15%: por adelantado antes de comenzar cualquier trabajo
Durante esta fase, se realiza una maqueta HTML del sitio web final, un diagrama de flujo (con yEd ) que describe el sitio web con el mayor detalle posible y un documento que menciona otras características que no están allí en el diagrama de flujo . Esto se hace al entrar en todos los detalles del proyecto y finalizar los bits que encajarán y cosas que es demasiado trabajo para implementar por el precio acordado. Debido a que los detalles no se discuten anteriormente, partes de estos también son más o menos una negociación sobre lo que realmente obtendrán. Debido a que este es un proyecto de presupuesto fijo, debe haber requisitos fijos, de lo contrario, mi precio sigue bajando a medida que se agregan más funciones.
También se finaliza un esquema de color, estructura metálica de diseño y PSD de diseño.

Pago del 35% : inicio del desarrollo
El proyecto es fijo, comienza el desarrollo. Alojo el sitio en mi servidor, donde el cliente puede acceder al front-end, pero no tiene acceso a ningún código.

Pago del 30% : transfiera el código al servidor del cliente / proporcione al cliente los detalles de acceso al servidor
Haga que el sitio funcione.

Pago del 20% : un par de semanas después de que el sitio se active, una vez que se hayan solucionado todos los errores.


Preguntas:
1. Una vez que sepa exactamente lo que va a construir, ¿qué tipo de planificación haría antes de comenzar a codificar?

2. Según tu experiencia, ¿qué partes de todo el proceso harías de manera diferente?


Desafortunadamente, muchos clientes nunca llegan al punto de saber exactamente lo que quieren que construyas. El mejor enfoque que he encontrado es hacer maquetas de algunas de las páginas importantes y luego sentarlas y comenzar a contar historias de usuarios. Deliberadamente, creo que algunas de las historias son erróneas para obligar al cliente a decir: "No, quiero que funcione de esta manera ..." Esto eventualmente nos lleva a algo que se acerca a una especificación de proyecto, pero invariablemente cambia más adelante. Suspiro.
Peter Rowell

@Peter, presentar intencionalmente historias de usuario falsas a veces puede ser contraproducente y hacer que el cliente pierda la confianza en ti. Esa técnica debe usarse con cuidado.
maple_shaft

@maple_shaft: me doy cuenta de eso. Cuando digo 'obviamente equivocado', me refiero a Blatantly Bogus® que normalmente recibo más que unas pocas risas. Lograr que un cliente invierta completamente en su sitio web (visión / tiempo / dinero) es fundamental para un proyecto exitoso. Es sorprendente (al menos para mí) cuántas personas piensan que un nuevo sitio es algo que pueden agitar a mano y aparecerá mágicamente.
Peter Rowell

También estoy de acuerdo con las maquetas, ninguna cantidad de texto escrito hará que el cliente entienda lo que obtendrá (la mayoría no puede entenderlo o no quiere entenderlo): una maqueta aclarará las cosas para el cliente, también cierta documentación (especificación) + un contrato o algo que diga: "Obtendrá todo esto, y exactamente esto, nada más" ayuda. Durante el desarrollo, creo que puede haber cierta flexibilidad para cambiar las cosas, pero si surge algo que se muestra como más trabajo del que representaba, creo que los simulacros y los documentos de especificaciones deben eliminarse y el trabajo adicional también implica costos adicionales.
DMin

Respuestas:


10

Grandes puntos para la discusión!

Para calificar: trabajo en GRANDES proyectos de desarrollo web en la industria de defensa. Generalmente tenemos un equipo de 10-40 personas que respaldan a un solo cliente, proyectan los últimos años y el cliente tiene tanto dinero como altas demandas. Por lo tanto, el kilometraje puede variar: ¡no desea sobre planificar!

1 Una vez que sepa exactamente lo que va a construir, ¿qué tipo de planificación haría antes de comenzar a codificar?

Esto es después de la sección del 15%, al comienzo del 35%, ¿verdad?

  • Decidir sobre el servidor web y el idioma de destino
  • Decidir sobre el almacenamiento de datos: XML, Base de datos, ¿qué base de datos?
  • Decida sobre las principales API: persistencia de datos, GUI, registro, inyección de dependencias, etc.
  • Decida los mecanismos de inicio de sesión, teniendo en cuenta los riesgos y la información que está tratando de proteger. Puede incluir mecanismos de pago.
  • Planifique una arquitectura de alto nivel y convenciones de nomenclatura
  • Elija un orden de despliegue de funciones, para que conozca un buen lugar para comenzar
  • Decida una estrategia de prueba y realice un marco de prueba automatizado, si corresponde
  • Configurar el sistema CM

2 Según su experiencia, ¿qué partes de todo el proceso haría de manera diferente?

No sobre planearía. Centraría mi trabajo de planificación en hacer las cosas, como el entorno de compilación, el servidor, el banco de pruebas, el CM, y dedicaría solo una pequeña cantidad de tiempo a planificar una arquitectura, elegir herramientas y decidir por dónde empezar. Siento que pase lo que pase, la etapa de planificación amorfa siempre implica mucho más tiempo deambulando en un desierto de despistados de lo que realmente debería.

Si está lidiando con tarifas fijas y clientes que no están haciendo demandas técnicas (como el idioma o las API que usa), planearía en 1 elemento que siempre es un impulso para usted, técnicamente. Solo 1 y mantén el resto igual. Creo que en cada proyecto, desea ampliar sus habilidades, pero no quiere volverse tan salvaje que no esté trabajando en nada que sepa o entienda bien.


2

Mi mayor consejo para usted es ser extremadamente cuidadoso con un trabajo de desarrollo de precio fijo. Si no maneja bien los requisitos antes de que comience el trabajo, puede ocurrir una de dos cosas.

  1. Las estimaciones sobre el alcance resultaron ser insuficientes y usted pierde su camisa.
  2. El cliente no conoce o no puede conocer todo el alcance antes de que comience, lo que hace que no esté satisfecho con el resultado final.

Para usted, el número 2 es una mejor situación porque si firman el alcance y luego cambian de opinión, pueden renegociar por más dinero. Solo asegúrese de que USTED comprenda el alcance antes de estimar y que ELLOS entiendan el alcance y lo que entregará.

¡Asegúrese de que firmen en el alcance! Las empresas que insisten en un precio fijo y se niegan a firmar el alcance son MALOS CLIENTES y no desea perder su tiempo con eso. Siempre perderás

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.