El problema amb contractar desenvolupament a mida és que el resultat triga mesos a ser visible. Quan descobreixes que el proveïdor no treballa com prometia, ja portes 4 mesos de retards, 2 de canvis d'abast i un pressupost que ha crescut un 40%. Aquestes preguntes estan dissenyades per revelar com treballa realment un proveïdor abans que signis res.
Per què és difícil avaluar proveïdors de desenvolupament
Qualsevol proveïdor pot mostrar una demo impressionant, una llista de tecnologies i un portfolio de clients que sona bé. El que no pots veure en una primera reunió és si té un procés real de gestió de canvis, si documenta el que construeix, si el codi serà mantenible per algú diferent del que el va escriure, o si desapareixerà quan arribi el primer bug greu en producció.
Preguntes sobre el procés
- Com gestioneu els canvis d'abast durant el projecte? (Un proveïdor seriós té un procés definit, no 'ja ho veurem quan arribi')
- Amb quina freqüència tindré accés al codi en un entorn d'staging funcional?
- Qui és el meu interlocutor tècnic durant el projecte i quina càrrega de treball té en paral·lel?
- Com documenteu les decisions tècniques que preneu durant el desenvolupament?
- Què passa si el responsable tècnic del projecte deixa l'empresa durant el desenvolupament?
- Podeu mostrar-me el procés de QA real d'un projecte anterior?
Preguntes sobre el codi i la propietat
- El codi font és meu des del primer dia o només en acabar el projecte?
- Feu servir llibreries o components amb llicències restrictives que limitin el meu ús futur?
- Quina documentació tècnica entregareu en acabar el projecte?
- Quant de temps estimeu que tardaria un altre equip a entendre i continuar el codi sense vosaltres?
- Tinc accés al repositori de codi amb historial complet de commits?
Senyals d'alerta en les respostes
- Respostes vagues sobre el procés de gestió de canvis ('ho adaptem a cada projecte')
- No poden mostrar exemples concrets de documentació tècnica de projectes anteriors
- L'interlocutor tècnic canvia entre la reunió de venda i l'inici del projecte
- No tenen un entorn d'staging separat de producció
- Reaccionen de forma defensiva a preguntes sobre propietat del codi o auditoria
El que hauria d'incloure una proposta sòlida
- Fases amb fites verificables i criteris d'acceptació definits
- Procés de gestió de canvis amb impacte en cost i termini especificat
- Propietat del codi i accés al repositori des de l'inici
- Responsable tècnic identificat amb disponibilitat real estimada
- Pla d'entrega i transició en finalitzar el projecte
- Procés de garantia i suport post-llançament clarament definit
Fer aquestes preguntes en la fase d'avaluació no és desconfiança: és la diferència entre un projecte que acaba bé i un que acaba en disputa. Els proveïdors seriosos responen amb detall. Els que no poden respondre-les t'estan mostrant com serà treballar amb ells.
Si estàs avaluant proveïdors per a un projecte de desenvolupament, podem ajudar-te a definir els criteris d'avaluació i revisar propostes.
Veure com treballem el desenvolupament