Cómo hacer una especificación técnica competente para el desarrollo del sitio

¿Recuerdas la ley de murphy? Si puedes hacerlo mal, definitivamente lo harás mal. Esto es cierto no solo en la comunicación entre personas, sino también en la creación de sitios web. El cliente quería un segundo "Facebook" y recibió un foro para criadores de perros jóvenes. El desarrollador no adivinó el deseo del cliente, perdí el tiempo.

En esta guía, le diré qué y por qué necesita escribir las especificaciones técnicas. Al mismo tiempo, mostraré cómo escribirlo, no es necesario para que la creación de los conocimientos tradicionales no se convierta en tiempo perdido.

El artículo será de utilidad:

  • Cualquiera que tenga que ver con la creación de sitios: desarrolladores, diseñadores, diseñadores de diseños.
  • Jefes de proyecto.
  • Jefes de estudios digitales.
  • Emprendedores que planean ordenar el desarrollo del sitio.

Para hacer el material útil, recabé comentarios de varios desarrolladores, diseñadores, gerentes de proyectos y propietarios de estudios digitales. El más valioso añadido al final del artículo. Vamos a resolverlo.

¿Qué es una tarea técnica y por qué es necesaria?

Los términos de referencia es un documento que establece los requisitos para el sitio. Cuanto más claros y detallados sean estos requisitos, mejor comprenderán los participantes en el proceso. Por lo tanto, hay una posibilidad cada vez mayor de que todos estén satisfechos con el resultado.

El principal objetivo de la tarea técnica: asegurarse de que el cliente y el intérprete se entiendan correctamente.

Los beneficios de las especificaciones técnicas mucho. Para cada lado tiene su propio.

Beneficios para el cliente:

  • Entienda por qué paga el dinero y cómo será el sitio. Inmediatamente puede ver la estructura, entender qué funcionará y cómo. Para estimar si todo encaja. Si no es así, cambie sin ningún problema incluso antes del inicio del desarrollo.
  • Ver la competencia del intérprete. Si los términos de referencia son claros y claros, la credibilidad del desarrollador aumenta. Si hay gachas escritas, tal vez valga la pena correr y no mirar alrededor.
  • Asegurarse contra la mala fe del intérprete. Cuando el sitio está listo, se puede verificar de acuerdo con la tarea técnica. ¿Alguna inconsistencia? El desarrollador está obligado a arreglarlos. Si cooperas oficialmente y entras en un acuerdo, incluso puedes ser forzado a través del tribunal.
  • Simplificar la sustitución de los artistas intérpretes o ejecutantes. Si el cliente y el desarrollador se pelearon y huyeron, la creación del sitio puede demorarse mucho. Cuando hay una tarea técnica detallada, se puede transferir a un nuevo equipo, se involucrará en el trabajo muchas veces más rápido.
  • Aprenda el costo de desarrollar un producto complejo. Calcule la hora exacta y el costo de desarrollar un servicio web complejo totalmente imposible. Primero debe comprender cómo funcionará el servicio y qué funciones tendrá en él. Para esto, necesitas preparar una tarea técnica.

Beneficio para el artista:

  • Entender lo que quiere el cliente. Al cliente se le hacen docenas de preguntas, muestra ejemplos, ofrece soluciones. Luego escribe todo en un solo documento y acuerda. Si todo está bien, hurra, lo haces bien.
  • Asegurarse contra un repentino deseo del cliente. A veces hay clientes que quieren cambiar la tarea a medio camino. Si aceptaste y firmaste el TK, no tienes miedo de esto. En cuyo caso, incluso la corte estará de su lado.
  • Demuestra tu competencia. Un proyecto técnico bien preparado mostrará al cliente la experiencia de los desarrolladores. Si la compañía dudaba si confiarle el desarrollo del sitio, es probable que las dudas se desvanezcan.
  • Gana dinero Algunos estudios y desarrolladores ofrecen la compilación de TK como un servicio separado.
  • Facilitar y agilizar el proceso de desarrollo.. Un buen TK indica la estructura del sitio, las funciones y elementos necesarios en cada página. Cuando todos los requisitos ya están ante sus ojos, solo queda diseñar y escribir el código.

Ahora veamos cómo realizar una buena tarea técnica que realice todas estas funciones.

Términos de referencia son intérprete.

En general, el proyecto técnico puede hacer que cualquiera. "Necesito un sitio de tarjetas de visita para una clínica dental": esta es una tarea técnica. ¿Pero cumplirá sus funciones? Difícilmente

Un buen TK es siempre un ejecutor: un gerente de proyecto o un desarrollador. Obviamente, el desarrollador web entiende la creación de sitios más que el propietario de una cafetería o clínica dental. Por lo tanto, tendrá que describir el proyecto.

Esto no significa que el cliente desaparezca y aparezca al final para escribir: "ЗБс, yo apruebo". También debe estar involucrado en el proceso:

  • Familiarizar al artista con la empresa, los productos y el público objetivo.
  • Explique por qué el sitio.
  • Di lo que quiere, comparte ideas.
  • Mostrar ejemplos de buenos sitios desde su punto de vista.
  • Responde cualquier otra pregunta al artista.

Por supuesto, el cliente puede esbozar su versión de los conocimientos tradicionales. Quizás esto acelere el proceso de crear una tarea técnica final. Y tal vez resulte la basura, que se arroja silenciosamente a la basura.

Escribe de forma única y precisa

Este consejo se deriva del objetivo principal del proyecto técnico: "Asegurarse de que el cliente y el intérprete se entendieron entre sí correctamente".

En la tarea técnica no debe haber adjetivos de calidad: hermosos, confiables, modernos. No se pueden entender claramente. Cada uno tiene sus propios conceptos de belleza y modernidad.

Echar un vistazo Alguien pensó que este diseño era hermoso y le permitió usarlo en su sitio web:

Lo mismo ocurre con las formulaciones vagas que en sí mismas no significan nada:

  • El sitio debe apelar al cliente. ¿Y si tiene mal humor?
  • El sitio debe ser fácil de usar. ¿Qué significa esto? Conveniente para qué?
  • El sitio debe soportar cargas pesadas. 10 mil visitantes? ¿O 10 millones?
  • Contenido experto de alta calidad. Bien entiendes

Compruebe si hay ambigüedades en el texto. Si hay - reescribir. Su redacción debe ser clara y precisa:

  • El sitio debe cargarse rápidamente → Cualquier página del sitio debe tener más de 80 puntos en Google PageSpeed ​​Insights.
  • Grandes cargas → 50 mil visitantes al mismo tiempo.
  • La página principal muestra una lista de artículos. La página principal muestra una lista de los últimos 6 artículos publicados.
  • Interfaz de suscripción minimalista y fácil de usar → Dejar campo de correo electrónico y botón Suscribir → * boceto dibujado *.

Con la redacción ordenada, repasemos la estructura.

Introduce información general

Todos los miembros del equipo deben entender correctamente lo que está haciendo la empresa y quién es su público objetivo. Para que nadie se confunda, es mejor registrarse al principio del proyecto técnico.

Y vale la pena indicar el propósito del sitio y describir su funcionalidad en dos palabras, para no tener una tienda en línea en lugar de un blog.

Explicar los términos difíciles

La primera regla de una tarea técnica es que debe quedar claro para todos a quienes está destinado. Si va a utilizar términos que su cliente, el propietario de una tienda de juguetes para niños, puede no entender, asegúrese de explicarlos. Lenguaje comprensible, no copiar y pegar de Wikipedia.

Describir las herramientas y requisitos de alojamiento.

Imagina que has estado haciendo un sitio web genial durante 2 meses. Cada etapa fue coordinada con el cliente - él estaba encantado. Y ahora es el momento de tomar el trabajo. Muestras el área de administración y el cliente grita: "¿Qué es eso? ¿Modex? ¡Pensé que lo harías en WordPress!"

Para evitar tales problemas, describa las herramientas, los motores y las bibliotecas utilizadas. Al mismo tiempo especifique los requisitos para el alojamiento. Nunca se sabe, lo hace en PHP, y el cliente tiene un servidor en .NET.

Lista de requisitos del sitio

El sitio debería funcionar en todos los navegadores de versiones actuales y en todos los tipos de dispositivos. Sí, es obvio para cualquier desarrollador y cualquier cliente. Pero es mejor escribir para proteger al cliente de un trabajo injusto.

Aquí, escriba los requisitos para la velocidad de carga del sitio, la resistencia al estrés, la protección contra ataques de piratas informáticos y cosas similares.

Especifique la estructura del sitio

Antes de comenzar a diseñar y diseñar, debe acordar la estructura del sitio con el cliente.

Comunícate con el cliente, averigua lo que quiere. Reúna a los desarrolladores, SEO, comercializadores, Glavred y decida qué páginas se necesitan en el sitio. Piense en cómo se interconectarán, a cuál puede ir.

Puede mostrar la estructura de la lista, puede dibujar un diagrama de bloques. Como prefieras.

Esta es una de las etapas más importantes del trabajo en el sitio. La estructura es la base. Si no tiene éxito, el sitio se convertirá en una curva.

Explica qué habrá en cada página.

El cliente debe entender por qué se necesita cada página y qué elementos estarán en ella. Hay dos formas de mostrarlo.

Prototipo - Una forma más visual e inequívoca. El artista dibuja bocetos de cada página y los adjunta a los términos de referencia. El cliente ve cómo se verá la interfaz de su futuro sitio y dice qué le gusta y qué se debe cambiar.

Enumeración de elementos. - Alternativa perezosa al prototipo. Solo escribe qué bloques deberían estar en la página y qué hacen.

Escribe los escenarios de uso del sitio.

Si está haciendo algún tipo de interfaz no estándar, no es suficiente mostrar la estructura y las miniaturas. Es importante que todo el equipo de actores y el cliente entiendan cómo los visitantes utilizarán el sitio. Los scripts son geniales para esto. El guión es muy simple:

  • Acción del usuario
  • Respuesta del sitio.
  • Resultado.

Por supuesto, si está realizando una tarjeta de visita estándar o un aterrizaje, no necesita escribir scripts. Pero si hay algún servicio interactivo en el sitio, es muy deseable.

Lea más sobre los escenarios de uso en Wikipedia.

Determine quién es responsable del contenido.

Algunos desarrolladores hacen el sitio inmediatamente con contenido. Otros ponen pescado. Otros pueden escribir textos, pero por una tarifa adicional. Acuerde esto en tierra y registre en las especificaciones técnicas qué contenido debe preparar.

Proponer criterios objetivos para evaluar la calidad de los textos es bastante difícil. Mejor no escribir nada que "Calidad, contenido interesante y de venta útil para el público objetivo". Esto es basura, nadie lo necesita.

Es útil indicar que todo el contenido debe ser único. Otra protección del cliente contra los artistas sin escrúpulos.

Describa el diseño (si puede)

Como en el caso del texto, es difícil establecer criterios objetivos para evaluar el diseño. Si está de acuerdo con el cliente sobre el esquema de color, escríbalo. Si tiene un libro de marca en el que están escritas las fuentes, indíquelas también.

Escribir sobre el hermoso y moderno diseño no es necesario. No significa nada, no tiene el poder y generalmente fu.

En lugar de salida: la estructura de la tarea técnica.

Para diferentes tareas, la estructura del TOR será diferente. Es absurdo hacer los mismos términos de referencia para una nueva red social y aterrizar en la venta al por mayor de zanahorias. Pero en general, necesitas estas secciones:

  • Información sobre la empresa y el público objetivo, las metas y objetivos del sitio.
  • Glosario de términos que pueden no ser claros para el cliente.
  • Requisitos técnicos para el diseño y funcionamiento del sitio.
  • Descripción de las tecnologías utilizadas y una lista de requisitos para el alojamiento.
  • Estructura detallada del sitio.
  • Prototipos de páginas o descripciones de los elementos que deben figurar en ellas.
  • Escenarios para utilizar una interfaz personalizada (opcional).
  • Listado de contenidos que realiza el desarrollador.
  • Requisitos de diseño (opcional).

Tambien recomiendo leer

  • Reglas para compilar la especificación de requisitos de software. SRS - el siguiente paso en la evolución de las especificaciones técnicas. Necesario para proyectos grandes y complejos.
  • Estándares y plantillas para el desarrollo de software. Descripciones de diferentes GOSTs y metodologías para la creación de especificaciones.

Este es el final de la parte que escribí. Pero hay otro: los comentarios de los especialistas que ayudaron a hacer la guía. Leer, esto también es interesante.

Comentarios del desarrollador

Hablé con varios desarrolladores para averiguar cómo componen los términos de referencia. Les paso el micrófono.

Asha Sahakyan, diseñador web, freelancer

El proyecto técnico debe ser escrito por el gerente del proyecto, el líder del equipo o el desarrollador mismo (si es un profesional independiente y trabaja solo). El cliente no entiende los sitios, no puede tener en cuenta todo lo importante.

Escribo TZ para que sea comprensible para el cliente. Explico los términos, describo la estructura, diseño, funcionalidad, tecnologías utilizadas. A menudo adjunto prototipos de páginas para que el cliente entienda cómo se verá su sitio. Luego creo una tarea separada para el diseñador de diseño, con detalles técnicos y explicaciones que lo ayudarán en su trabajo.

Cuanto más difícil sea la tarea, más debería ser la TZ. Cuando participé en grandes proyectos, vi especificaciones técnicas de 30 páginas.

Guram Sipki, fundador de Udix Media Digital Studio.

En primer lugar, TK necesita un cliente, para que él entienda cómo será su sitio y cuánto costará el dinero. Si algo se hace mal, puede referirse a los conocimientos tradicionales y solicitar una nueva versión.

TK es el gerente del proyecto después de hablar con el cliente y discutir el problema con el diseñador.

Los clientes grandes a menudo solicitan TZ muy detallados, en los que se describe cada botón. Las pequeñas empresas, por el contrario, no les gustan los documentos meticulosos en 100 páginas. Mucho para leer y fácilmente se pierda algo importante. Más a menudo hacemos términos de referencia concisos para 10-15 páginas.

Nosotros indicamos:

  • Información sobre la empresa y el propósito del sitio.
  • Requisitos de diseño, gama de colores.
  • Tecnologías utilizadas y CMS.
  • Quién está involucrado en el contenido, nosotros o el cliente.
  • La estructura del sitio baja a cada página.
  • Descripciones de cada página. No hacemos prototipos, pero indicamos qué elementos deben estar en la página y cómo deben funcionar.

Las 2 últimas secciones son las más importantes. Proporcionan una comprensión de lo que será el sitio y cómo funcionará.

Un punto muy importante: no solo puede asignar la tarea técnica a los desarrolladores y esperar que lo hagan todo bien. TK es una lista de requisitos del sitio, no puede reemplazar la comunicación. Es importante asegurarse de que cada miembro del equipo entienda un objetivo común y no solo realice las tareas en la secuencia. Si algo no está claro, es necesario explicar, discutir y dar comentarios detallados.

Dmitry Kuzmin, Gerente de Proyecto

Un proyecto técnico debe ser escrito por un desarrollador o un gerente de proyecto. Es necesario indicar solo formulaciones completas completas que no puedan ser impugnadas. Y evitar los adjetivos evaluativos: bellos, eficaces y así sucesivamente.

Si algo no se especifica en el TOR, es necesario aclararlo con el cliente o implementarlo a discreción del desarrollador. Pero separadamente reportamos este momento al cliente. Es necesario discutir con anticipación, e incluso mejor registrarse al final de las especificaciones técnicas.

Y aún falta dibujar bocetos aproximados de lo que debería suceder. Con comentarios detallados.

Alexander Kurochkin, el fundador del estudio Etalon Idea.

La tarea técnica es siempre, sin ella no hay trabajo. "Necesito una tienda en línea": esta es una tarea técnica. El problema es que este es un TK muy vago, casi no da entendimiento.

La tarea del gerente de proyecto es recopilar toda la información necesaria, idear una solución, crear un sitio web en su cabeza. Y luego describirlo en el documento. De hecho, los conocimientos tradicionales ya están a medio camino del producto terminado.

Los términos de referencia son un punto de referencia con el que usted y sus clientes compararán un sitio. Es necesario para todos:

  • El desarrollador está en las cosas descritas en los conocimientos tradicionales.
  • El probador comprueba si todo funciona según lo previsto.
  • El cliente entiende que recibirá al final.
  • El gerente del proyecto puede estimar el costo y el tiempo de desarrollo.

Con un sitio de tarjeta de visita o tienda todo es simple. Es poco probable que haya algo nuevo, por lo tanto, es fácil estimar su costo en la etapa de discusión. Si hacemos algo similar, podemos hacerlo sin TK en absoluto. Discutimos el problema, escribimos una formalidad en el contrato, lo hicimos. Todos están felices.

Si un cliente necesita un producto complejo, nadie puede estimar de inmediato el tiempo y el costo. Primero necesitas averiguar qué es exactamente lo que se necesita. Entonces, cómo funcionarán las cosas. Luego averigua cómo hacerlo. Y solo después de eso quedará claro cuántas horas-hombre se gastarán en la implementación.

En TK indicamos:

  • el propósito del sitio;
  • requisitos del servidor;
  • descripción del sitio y sus elementos individuales;
  • tecnologías utilizadas y bibliotecas;
  • diseño de interfaz de diseño;
  • Estructura y lógica de las transiciones internas.
  • roles y escenarios de trabajo con el sitio para cada uno de ellos;
  • Arquitectura de base de datos (opcional).

Mi consejo para los lectores es, ante todo, establecer la comunicación. Si los miembros del equipo no pueden entenderse entre sí y con el cliente, ningún término de referencia no le ayudará.

Yuri Ketov, desarrollador frontend, freelancer

No me gusta trabajar en TK. La mayoría de los conocimientos tradicionales que he visto son demasiado engorrosos e ineficaces. Para mí, la situación ideal es cuando el cliente en un párrafo formula la tarea del sitio y el contexto en el que se usará.

Por ejemplo:

Sitio para el teatro de marionetas. La tarea es informar a los visitantes sobre el teatro y el repertorio, para brindar la oportunidad de reservar un boleto en línea.

En este caso, lo principal para mí son las referencias. Veré lo que Studio Lebedev Studio, Nimax, RedCollar, ONY, Sibiriks y otras 10 compañías han hecho sobre este tema, elegir 2-3 proyectos más exitosos, estar de acuerdo con el cliente y se guiarán por ellos.

O algo así:

Página promocional para la venta de henna para biotatuazha.

Aquí lo principal es hacer un sitio web con el que pueda lograr el KPI necesario. Смотрим, какие сайты делают IT-Agency и Convert Monster и делаем также, не надо ничего изобретать.

Чем больше контента дает клиент, тем лучше. Если вы дадите мне 1000 фотографий, 20 видео, 50 страниц текста - супер. Я сам все отфильтрую и выберу то, что нужно. Я немного утрирую, но, в общем, это так. Чем больше контента на входе, тем лучше, но оставьте за мной право выбирать.

Александр Белов, проект-менеджер Texterra

La tarea técnica es necesaria para cualquier proyecto. Cada TZ debe incluir:

  • Metas y objetivos que realizará el sitio.
  • Público objetivo
  • Se trabajó en detalle, la estructura del sitio.
  • Elementos de la interfaz del sitio.

El cliente debe representar claramente su sitio en la versión final, su apariencia y la estrategia de desarrollo futuro.

La tarea técnica no debe decirles a los desarrolladores "cómo hacerlo, qué hacer y qué código insertar", esto es fundamentalmente incorrecto. En general, debe describir cómo debe ser el sitio y no cómo hacerlo. Esto debe tenerse en cuenta como mínimo porque el cliente, en la mayoría de los casos, no tiene la experiencia adecuada.

En cuanto al enfoque, siempre escuchamos la opinión del cliente, pero hay ocasiones en que entendemos que no vale la pena hacerlo. En este caso, intentamos convencer al cliente, sobre la base de datos de expertos. En general, damos la bienvenida a cualquier visión del cliente.

Cómo preparamos el proyecto técnico:

  • Analizamos los TK enviados por el cliente.
  • Estudiamos el diseño del prototipo y diseño del sitio.
  • Sobre la base de los datos obtenidos, comenzamos a seleccionar módulos funcionales para el sitio que se utilizarán al 100% y que pueden ser necesarios.
  • Registramos elementos que serán necesarios durante el trabajo con la interfaz.
  • Sobre la base de estos datos y de la evaluación del "peso" del sitio, calculamos los requisitos del sistema adecuados para el alojamiento del sitio.
  • Después de estos puntos básicos, comenzamos a pintar el TOR con más detalle para cada página.
Guarde este artículo y vuelva a leerlo cuando decida ordenar un sitio. Por cierto, esto se puede hacer en nuestra agencia. kak-sostavit-gramotnoe-tekhzadanie-na-razrabotku-sayta
#
Desarrollo web

Loading...

Deja Tu Comentario