Puede escribir especificaciones técnicas impecables, pero ¿de qué sirve si su desarrollador está llorando?

El propietario de un producto esférico está trabajando en una galaxia muy, muy lejana. Escribe notas con fluidez en una servilleta y se las da en silencio a los desarrolladores. Y pronto recibe un producto terminado que cumple al 100% con sus expectativas. Incluso si este producto es un servicio multiplataforma complejo con blackjack y adaptabilidad.



¿Es esto posible en la práctica?



“¡No, hermano, no puedes engañarnos! Los términos de referencia deben redactarse de manera extensa y meticulosa ”, dicen las personas mayores de cabello gris. "¡TK es serio!" - los Juns de boca amarilla se hacen eco de ellos. “Mi esposa me dejó debido a una breve asignación técnica”, admite un experimentado analista de negocios.



Déjame estar en desacuerdo.



Escribir un TK no tiene por qué consumir mucho tiempo. Además, los buenos términos de referencia son más fáciles de escribir que los malos. Si conoces algunos trucos, claro. Te lo contaré hoy. Sin embargo, en lugar de servilletas, todavía recomiendo usar confluence .

¿Qué pasa?

He estado escribiendo problemas para desarrolladores durante más de 11 años. En base a ellos se crearon aplicaciones, juegos, servicios web, sistemas CRM, plataformas de formación y otros productos. Durante este tiempo, pasé de escribir documentos de diseño de 200 páginas a términos de referencia lacónicos en varios pasos. Y, por supuesto, llenó todos los baches posibles.



Año tras año, en diferentes empresas, observé cómo los diseñadores de productos, juegos y especialistas en marketing establecían tareas. Y cuáles son las consecuencias de las distintas "características" del diseño de estas tareas. Cómo se cambia el inicio del sprint en una semana, averiguando qué quiere exactamente el cliente. Como si estuvieran en pánico, corrigen la funcionalidad que se acaba de agregar al producto. Qué tan rápido se cae la puntuación de la aplicación debido a casos no contabilizados. Cómo caen las ventas y los usuarios leales se van. Cómo los desarrolladores se agotan cuando tienen que jugar con tareas problemáticas.



Tengo la impresión de que muchos de los que establecen tareas de desarrollo no saben cómo hacerlo bien . Y la cuestión de la calidad de los conocimientos tradicionales en sí está fuera del foco de atención: dicen, escribieron una tarea y normas, no lo resolverán, ¿o qué? Además, siempre hay cosas más interesantes que hacer: discusión de nuevas hipótesis, reuniones, coffee breaks. Como resultado, todo el mundo sufre: clientes, desarrolladores y empresas.

Hay dos extremos al escribir TK

Cuanto mayor sea el producto en el que está trabajando, mayor será el costo de un error y más importante será la calidad de la especificación técnica (¡gracias, límite!). Por lo tanto, ambas opciones no son adecuadas si está haciendo algo más serio que una página de destino. En productos grandes y competitivos, escribir TOR debe ser rápido, inteligente, rock and roll . Veamos cómo llegar.

,

1. 
   
   – , , . , ( ).
2. 
   
   – , . , – , . .. , , . , – , .
3. PM-
   
   – , , . «», , .
4. QA
   
   – , . user journey . , , , .
5. Los CC.TT. deben complacer al líder del equipo,
   
   lo que significa que no requiere ningún ritual especial y explicaciones para ser transferidos al desarrollo. Por ejemplo, si un producto completó la asignación técnica y fue atropellado por un autobús allí mismo, en la oficina, esto no debería impedir que la asignación técnica se realice de la mejor manera posible.

¿Es difícil cumplir con todos estos requisitos? De ningún modo.



Por el contrario, si los recuerda, no podrá escribir TK francamente malos. Porque todos estos requisitos se reducen a una sola cosa: cuidar de las personas que interactúan con este TK.

Mi formato TK

Este formato es una mezcla bastante flexible de historia de usuario + definición de hecho .



Apareció como resultado de muchos años de evolución: cada vez que veía un problema sistemático, cambiaba el formato de mis conocimientos tradicionales para que este problema no surgiera en el futuro. El resultado es un formato lacónico y visualmente limpio que incluso los junio pueden captar fácilmente. Además, cumple con los requisitos descritos anteriormente.



Así es como se ve una historia típica en mi TK:







y no importa cuán grande y complejo sea el producto que estamos desarrollando, cualquier TK consistirá en historias tan simples (su número solo aumentará).





Importante: las historias no deben describir una funcionalidad demasiado grande (por ejemplo, varias pantallas) o demasiado pequeña (por ejemplo, un botón). Normalmente, una historia es una característica o una mecánica de producto. Por ejemplo, una historia puede describir completamente el registro de un nuevo usuario. Para establecer una tarea para el diseño de una nueva página de destino, como regla, una historia también es suficiente para mí.



Si la especificación técnica es grande y significativa, entonces antes de la lista de historias escribo brevemente: por qué lo estamos haciendo y qué resultados queremos lograr . Solo para que los desarrolladores tengan una visión general.

En general, resulta algo como esto:

Ejemplo

De acuerdo, para entender cómo funciona esto, dividamos un producto en tales historias. Por ejemplo, decidimos hacer una aplicación llamada "arranque neuronal". En él, la red neuronal llevará a cabo conversaciones íntimas con productos que no han tenido un día (y no tienen amigos).



Para simplificar, asumimos que ya tenemos una red neuronal entrenada y necesitamos crear una interfaz para ella en forma de aplicación.



Probablemente, el TK constará de las siguientes líneas:

1. Autorización de usuario
2. Perfil del usuario
3. Pantalla de comunicación con neuroboot
4. Pantalla "Catálogo Neuroboot"
5. Pantalla de perfil y configuración
6. Ventana emergente de pago
7. Conexión analítica

Queda por pintar cada historia (en el formato anterior) y enviarla a desarrollo. Te dije que sería fácil.

---

Trucos complicados de la vida

Hay una serie de técnicas que me ayudan a trabajar en un producto todos los días. Estos son los que se relacionan con la redacción de los términos de referencia.

Life hack # 1: Detalle iterativamente

Ahora no escribo especificaciones técnicas en absoluto: ellas mismas, en el fondo, aparecen en el proceso de trabajo. Cuando aparece una nueva tarea, me doy cuenta de inmediato: ¿qué subtareas se necesitan para hacer esto? Y luego arreglo cada subtarea en el formato de la historia (solo el nombre, los detalles vendrán más adelante).



Por lo tanto, tengo listos inmediatamente los términos de referencia generalizados. Solo queda detallar la historia en la medida en que sea posible dar el encargo técnico para el desarrollo.



Los detalles también van en segundo plano: mientras investigo y pienso en los detalles, inmediatamente tomo notas dentro de las líneas correspondientes. En lugar de diseño, inserto prototipos de NinjaMock .



Este enfoque acelera significativamente el trabajo. Además, le permite no perderse el panorama general y no profundizar en los detalles antes de tiempo.

Truco de vida n. ° 2: no trabajar con genios

Había una película tan antigua en la que el genio hacía realidad los deseos de la peor manera.



Por supuesto, un desarrollador cuerdo no buscará específicamente una oportunidad para hacer daño. Pero a veces a la gente no le importa en qué están trabajando. Luego hacen la tarea "como está escrita", sin profundizar realmente en por qué es necesaria. Periódicamente, esto dará como resultado archivos grandes y pequeños. Bueno, sí, la producción se estableció ... pero nadie ha escrito en la tarea lo que debe verificarse: si tal implementación romperá todo lo demás.



No diré sobre la subcontratación, pero este enfoque no es aceptable en el producto. Un buen desarrollador está construyendo un templo, no solo colocando ladrillos. Es decir, ve el panorama general y profundiza en lo que está sucediendo. Estos tipos a menudo ofrecen soluciones alternativas y advierten ellos mismos sobre las trampas.



Por lo tanto, si desea que su TK se realice de la mejor manera posible, a veces necesita mejorar no TK, sino la cultura de desarrollo en el equipo. En general, esta es la tarea de un PM, pero el producto también puede influir en la situación. Sobre todo si el equipo confía en él (gracias a sus especificaciones técnicas bien pensadas y bien diseñadas, por ejemplo).

Life hack # 3: asignación técnica separada de la documentación

Los términos de referencia responden a la pregunta "¿qué hay que hacer?" Y la documentación - a la pregunta "¿cómo se hace / cómo funciona?" El TK se escribe antes de la implementación de la tarea y la documentación se escribe después.



Si necesito reorganizar el gabinete, escribiré una tarea con el espíritu de "reorganizar desde aquí -> aquí". Pero no dibujaré el plan arquitectónico de la casa en la que hay un armario.



A veces existe la opinión de que los CC.TT. deberían redactarse de modo que sean , por así decirlo, la documentación . Ésta es una teoría perniciosa. La documentación completa aún no funcionará, porque no se sabe de antemano cómo exactamente se implementarán los términos de referencia. Además, los desarrolladores necesitan espacio para maniobrar, que la documentación no proporciona. Y lo principal es escribir un TK muchas veces más y resultará engorroso.



Hay diferentes productos y diferentes startups. Alguien puede prescindir de la documentación. Pero si aún necesita documentación, contrate a un junio que describirá la funcionalidad en detalle después de su implementación. No necesita habilidades especiales para describir la funcionalidad existente, pero ahorrará tiempo y nervios a los empleados hábiles: desarrolladores de productos y desarrolladores.

Life hack # 4: aprende a programar

Una observación puramente empírica: los productos que saben programar son mejores para formular tareas. Además, no es necesario convertirse en un operador de backend senior, es suficiente dominar cualquier lenguaje de programación y comprender la esencia del pensamiento algorítmico.



Hubo un tiempo en que todavía codificaba incontrolablemente en el espectro ctónico , y en mis años de estudiante incluso tuve que escribir controladores en Assembler. Es decir, estoy familiarizado con la programación de primera mano y esto, por supuesto, ayuda a encontrar un lenguaje común con los desarrolladores.

Truco de vida n. ° 5: pensar mucho, escribir un poco

Los mayores problemas siempre surgen con tareas que el propio cliente no comprende completamente. Por ejemplo, necesita un nuevo informe en el área de administración, pero no comprende bien cómo se formará este informe. Ustedes los programadores lo resolverán. No, no funciona de esa manera.



La única forma de redactar un buen problema que se haga bien es comprender. Idealmente, comprenda el problema lo suficiente como para poder hacerlo usted mismo ... si supiera cómo programar.



Pero cuando lo descubra, no necesita volcar toda la información que se encuentra en el TK. Es solo una comprensión profunda de la tarea que le permite descartar cosas innecesarias y escribir solo lo que importa.

---

PS TK es un medio, no un fin. Por lo tanto, a veces el mejor CT es su ausencia. Algún día te contaré cómo lancé un par de productos sin ninguna especificación técnica.



PPS Si tiene su propio formato de términos de referencia o trucos de vida al escribirlos, comparta los comentarios.