La Reteja Triangulo

Ĉiuj niaj kontraktoj kun niaj klientoj daŭras ĉiumonate. Tre malofte ni celas fiksan projekton kaj preskaŭ neniam garantias la templinion. Tio eble sonos timiga por iuj, sed la afero estas, ke la celo ne estu la dato de eldono, ĝi estu la komercaj rezultoj. Nia tasko estas akiri niajn klientajn komercajn rezultojn, ne preni ŝparvojojn por lanĉi datojn. Dum Healthcare.gov lernas, tio estas vojo, kiu kondukos al maltrafitaj atendoj.

Provi konservi projektojn de klientoj akurata, ni apartigas postulojn en devas havi (plenumi la komercajn rezultojn) kaj agrable havi (laŭvolaj plibonigoj). Ni ankaŭ ne iam planas kompletigon dum la eldono, ĉar ni scias, ke ĉiam necesos iuj ŝanĝoj.

Robert Patrick estas ĉefoficisto de Doktoraj Laboratorioj, agentejo, kiu projektas, konstruas kaj lanĉas retejojn por multaj ĉefaj kompanioj de Fortune 500. Robert observis la malfacilaĵojn, kiujn renkontis Healthcare.gov, kaj donis 5 ŝlosilajn kialojn por la malsukcesa lanĉo.

  1. Neniam, iam malobservu la Tempo, Kosto & Trajto Agordi regulon. Pensu pri tio kiel triangulo, vi devas elekti unu punkton por esti fiksita kaj la aliaj du variabloj. En ĉi tiu mondo, preskaŭ ĉio povas esti kreita kondiĉe ke sufiĉas tempo kaj mono. Tamen ĉiu, kiu konstruas retprogramon, devas elekti antaŭe, kiu estas la plej alta prioritato. Ĉi tio difinas la tonon kaj fokuson pri kiel projekto devas esti lanĉita. Ekzemple,
    • Ĉu ĝi estu lanĉita nur post kiam specifaj funkcioj estas faritaj (mono kaj tempo varias).
    • Ĉu ĝi estu lanĉita rapide (mono kaj funkcioj estas ŝanĝiĝemaj).
    • Ĉu ĝi estu lanĉita kun buĝeto en la menso (tempo kaj funkcioj varias).
  2. Lanĉante kun la cellinio en menso anstataŭ la komenca linio. Retaj programoj devas esti vidataj kiel projekto komenco kaj tiam evoluu. Konstrui tion, kio hodiaŭ gravas kaj estas deviga, konsiderante kreskon kaj evoluon, ĉiam pli bonas ol konstrui kun la intenco fini ĉe la komenca punkto.
  3. Tro multaj vendistoj implikita. Oni informis, ke la retejo Obamacare havis proksime 55 vendistojn implikitajn. Aldonado de multaj vendistoj al iu ajn projekto povas esti glita deklivo. Vi preskaŭ povas garantii, ke estos problemoj pri versiado de dosieroj, artaj dosieraj diferencoj, artaj opiniaj diferencoj, forlasado de projekto, kaj la listo daŭras. Imagu, se ni havus po 55 senatojn taskitajn solvi parton de la ĝenerala problemo.
  4. Informo Arkitekturo ne prenita serioze. Ofte grandaj agentejoj petos al vendistoj submeti oferton pri RFP kaj tute transsalti la procezon de Informarkitekturo saltante rekte al disvolviĝo sen kompreni aŭ konsenti pri amplekso. Ĉi tio estas grandega, malbela, tempoperdo, mono perdanta, eraro. Ĝi estas ege valora por arkitekti tiom multe de la aplikaĵo, kiom vi povas antaŭenigi kaj esti preta esti lerta kaj fleksebla pri la aferoj, kiujn oni ne povis antaŭvidi bone antaŭ ol vi komencas programi ĝin (ĉi tio estas kiel konstrui domon sen skizoj). Vendistoj estas destinitaj elĉerpigi buĝeton kaj komenci tranĉi angulojn se ĉi tio ne fariĝas ĝuste.
  5. Ne sufiĉas tempo por kvalito Assurance. Estas evidente, ke ĉi tio estis granda falo al la lanĉo de HealthCare.Gov. Ili laboris pri malfacila lanĉa dato (la tempo estas la fiksa variablo de la triangulo ĉi-kaze) kaj la trajtoj kaj buĝeto devus esti modifitaj por plenumi la lanĉdaton kun tempo por taŭga Kvalita Certigo enmetita en la planon. Ĉi tio estas kerna eraro kaj probable kostas multajn laborojn al multaj homoj.

Kion vi pensas?

Ĉi tiu retejo uzas Akismeton por redukti spamon. Lernu, kiel via komento datiĝas.