Els gestors sense coneixements tècnics sovint pensen que el més important és escriure termes de referència detallats per als desenvolupadors, i després d'això, només queda demanar-los que compleixin els terminis estrictament. Sí, això és important.
A més de la descripció de la funcionalitat, els termes de referència han d'incloure les maquetes de pantalles amb un disseny totalment acabat i els textos de tots els missatges que es mostren a l'usuari perquè és una mala idea deixar el disseny i redacció al desenvolupament del programari. .
Però el pitjor de tot, després de discutir la funcionalitat amb els desenvolupadors, fer-se enrere i esperar tranquil·lament el resultat. El desenvolupament de programari és un procés continu i cal entendre clarament en què estàs treballant en aquest moment i què et queda per fer. Com més aprofundeixis en el procés, més probable és que te n'adonis quan alguna cosa va malament.
Centra't en les funcions principals
Com pot ajudar aquest tipus d'immersió? Una de les causes més comunes del lliscament de la data límit són les dificultats inesperades per implementar funcions petites i no tan importants. Els bons desenvolupadors s'esforcen per fer bons productes, la qual cosa significa implementar tots els elements especificats a les especificacions. Com a ideòleg de producte, podeu i hauríeu d'eliminar totes les característiques menors del pla si comencen a trigar massa temps, és a dir, més d'uns quants dies.
No afegiu tasques noves durant el desenvolupament de programari
Un cop us submergiu en el procés de desenvolupament i tingueu l'oportunitat de veure resultats intermedis, tindreu un fort desig d'afegir i canviar funcionalitats sobre la marxa. No ho facis mai! Afegir i modificar requisits en directe és el major fregament de la línia de temps de desenvolupament; la funcionalitat parcialment implementada és molt més difícil de canviar.
En el 95% dels casos, és millor mantenir-se dins del pla original i provar una nova funció concebuda als usuaris en directe. I després feu canvis en funció dels comentaris.
Controlar els esforços dels desenvolupadors
Amb el temps, estimaràs quant de temps triga una tasca i serà més precisa que la equip de desenvolupament de programariresultats de. Per exemple, s'afegeixen funcions noves amb relativa rapidesa, mentre que el redisseny de funcions antigues quan es converteixen les dades d'usuari existents sempre és lent i insoportable. Aprendre a presentar terminis més o menys realistes no és tan difícil; és més difícil influir-hi.
El perfeccionisme és una qualitat psicològica que distingeix els bons desenvolupadors dels dolents. S'aplica no només a les pantalles i botons de resultats visibles, sinó també a la implementació interna del producte, és a dir, el codi.
Per exemple, heu d'afegir una mecànica d'acció de bonificació a la pàgina de pagament. Un bon desenvolupador podria implementar en una setmana un mecanisme que suporti qualsevol acció administrada des del tauler d'administració, amb condicions personalitzables, temps, etc.
Però necessiteu una solució ràpida per llançar la promoció demà i llençar aquest codi per sempre una setmana després. Heu d'entendre quins components romandran al vostre producte durant molt de temps i quins es poden implementar amb finalitats d'utilització i comunicar-ho clarament a l'equip de desenvolupament de programari.
Ordena les tasques i no les configureu totes al mateix temps
Les tasques de l'equip de desenvolupament de programari es divideixen en grans (per fer una nova funció) i petites (per arreglar el formulari de registre). La regla general és mai distreure a un desenvolupador d'una tasca enorme per resoldre'n una de petita, fins i tot urgent.
Alguns professionals únics poden treballar de manera eficient en aquest mode, però la majoria dels desenvolupadors disminueixen dràsticament la productivitat a causa del canvi constant entre tasques. Per tant, té sentit tenir una alternança: primer una tasca enorme, després una setmana de petites tasques. Enregistreu les tasques petites a mesura que apareguin, però doneu-les al desenvolupament de programari per incloure-les en una llista quan es planifiqui la propera iteració o llançament.
Cada desenvolupador és diferent
La diferència de rendiment entre desenvolupadors individuals pot ser enorme. Per exemple, en alguns estudis, la versió dels millors i els pitjors programadors amb aproximadament la mateixa experiència va ser deu vegades diferent.
Heu d'entendre que la mateixa persona pot mostrar una velocitat excel·lent en tasques dins d'un pla (per exemple, extensions d'interfície) i una velocitat catastròficament baixa en altres tasques (tasques del costat del servidor a gran escala). Per tant, s'ha de donar a tothom tasques amb les quals se senti còmode treballant. En cas contrari, la productivitat caurà.
Ser assistent dels desenvolupadors
Una cosa important us ajudarà a parlar el mateix idioma que els desenvolupadors. La majoria de la gent tècnica té un cervell molt organitzat i racional; encaixen en un esquema lògic. Però aquest esquema no sempre serà convenient per als vostres usuaris.
Com a persona no tècnica, teniu un avantatge: us és més fàcil anar més enllà del marc que suggereix la implementació i comunicar-vos amb els desenvolupadors la visió correcta. Però recordeu: per transmetre el vostre punt de vista a l'equip de desenvolupament de programari, haureu de demostrar les vostres idees correctes amb arguments lògics.
Dedica temps als canvis interns
Heu de recordar que hi ha tasques que requereixen temps que no podeu veure des de fora en cap projecte, però que les heu de fer. És l'anomenat deute tècnic. Com es va formar? Mentre afegeix noves funcions, el projecte adquireix crosses i accessoris.
Moltes tasques es resolen ràpidament però d'una manera poc fiable. Per exemple, si no poseu regularment el vostre codi en ordre (aquest procés s'anomena refactorització) i no desenvolupeu l'arquitectura del projecte, augmentareu constantment els errors després d'un temps.
Es poden produir quan s'afegeixen funcions noves o fins i tot quan es corregeixen errors antics. Si no dediqueu temps a desenvolupar l'arquitectura del projecte, tard o d'hora no podreu fer front al nombre creixent d'usuaris.
Les tasques de deute tècnic s'han de planificar i executar, però com trobar l'equilibri adequat entre elles i el desenvolupament del producte? Naturalment, el vostre enfocament com a finançador i persona no tècnica es traslladarà a noves funcions. Però, d'altra banda, els desenvolupadors tendeixen a millorar el codi existent sense parar i estan menys entusiasmats amb les noves funcionalitats.
Per tant, encara heu d'entendre, almenys a nivell bàsic, la tecnologia i l'estructura del vostre producte per trobar un equilibri en les discussions amb els desenvolupadors. Les tasques tècniques han d'ocupar al voltant del 20% de les hores de treball de l'equip de desenvolupament de programari i acompanyar el desenvolupament de noves funcionalitats i la correcció d'errors.
Coneix la tecnologia
Per desenvolupar un producte, cal estudiar la seva estructura i la tecnologia en general, almenys a nivell bàsic. És vital perquè la tecnologia encara està viva, però no és adequada per a les vostres tasques. I sovint és impossible esbrinar-ho abans de llançar el sistema en mode batalla, amb usuaris reals i amb càrregues pesades.
En resum, encara no pots prescindir de la immersió en la tecnologia i el desenvolupament de programari com a finançador. A més, aquest coneixement us permetrà entendre millor com es desenvolupa el vostre projecte.
