12 Dahilan ng Pagkabigo sa Analytics At Business Intelligence
Ang numero 9 ay maaaring mabigla sa iyo
Sa analytics at business intelligence, maraming bagay ang maaaring magkamali. Kami ay, pagkatapos ng lahat, naghahanap para sa nag-iisang bersyon ng katotohanan. Ulat man ito o proyekto – para maging pare-pareho ang data at mga resulta, mabe-verify, tumpak at, pinakamahalaga sa lahat, tinatanggap ng end user – maraming link sa chain na dapat tama. Ang pagsasagawa ng Continuous Integration, na naimbento ng mga developer ng software at hiniram ng analytics at business intelligence community, ay isang pagtatangka na mahuli ang mga pagkakamali o pagkakamali nang maaga.
Gayunpaman, ang mga pagkakamali ay gumagapang sa panghuling produkto. Bakit mali? Narito ang ilan paghingi ng tawad mga dahilan kung bakit mali ang dashboard, o nabigo ang proyekto.
- Ito ay magiging mas mabilis. Oo, ito ay malamang na totoo. Ito ay isang bagay ng tradeoffs. Ano ang gusto mo? Gusto mo ba itong mabilis o gusto mo itong gawin nang tama?
Sa totoo lang, minsan nalalagay tayo sa ganoong posisyon. Kailangan ko ito sa Biyernes. Kailangan ko ngayon. Hindi, kailangan ko ito kahapon. Hindi na tinanong ng amo kung gaano katagal. Siya Sinabi sa amin kung gaano katagal namin kailangang gawin ito. Dahil doon kailangan ng Sales. Kasi kapag yun ang gusto ng customer. - Ito ay magiging sapat na mabuti. Ang pagiging perpekto ay imposible at bukod sa pagiging perpekto ay ang kaaway ng mabuti. Ang imbentor ng air raid early warning radar ay nagmungkahi ng "kulto ng hindi perpekto". Ang kanyang pilosopiya ay "Laging magsikap na bigyan ang militar ng ikatlong pinakamahusay dahil ang pinakamahusay ay imposible at ang pangalawang pinakamahusay ay palaging huli na." Iiwan natin ang kulto ng hindi perpekto para sa militar. Sa tingin ko ang punto ng maliksi, incremental na pag-unlad patungo sa huling resulta ay napalampas dito. Sa pamamaraang Agile, mayroong konsepto ng Minimum Viable Product (MVP). Ang pangunahing salita dito ay mabubuhay. Hindi dead on arrival at hindi pa tapos. Ang mayroon ka ay isang waypoint sa paglalakbay patungo sa isang matagumpay na destinasyon.
- Ito ay magiging mas mura. Hindi naman. Hindi sa katagalan. Laging mas mahal ang pag-aayos nito mamaya. Mas mura kung gawin ito ng tama sa unang pagkakataon.
Para sa bawat hakbang na inalis mula sa paunang coding, ang gastos ay isang order ng magnitude na mas mataas. Ang kadahilanang ito ay nauugnay sa una, ang bilis ng paghahatid. Ang tatlong panig ng tatsulok ng pamamahala ng proyekto ay saklaw, gastos, at tagal. Hindi mo mababago ang isa nang hindi naaapektuhan ang iba. Ang parehong prinsipyo ay nalalapat dito: pumili ng dalawa. Mabuti. Mabilis. mura. https://www.pyragraph.com/2013/05/good-fast-cheap-you-can-only-pick-two/ - POC lang yan. Hindi naman kasi natin ilalagay itong Proof of Concept sa production, di ba? Ang isang ito ay tungkol sa pagtatakda ng mga inaasahan nang naaangkop. Ang isang POC ay karaniwang nakatali sa oras na may isang tiyak na hanay ng mga layunin o mga kaso ng paggamit upang suriin ang aplikasyon o kapaligiran. Ang mga use case na iyon ay kumakatawan sa mga kritikal na kailangang-kailangan o karaniwang pattern. Kaya, ang pagsusuri ng POC, ayon sa kahulugan, ay isang hiwa ng mas malaking pie kung saan maaari tayong magbatay ng mga karagdagang desisyon. Ito ay bihira hindi magandang ideya na maglagay ng POC sa produksyon, software man ito o hardware.
- Ito ay pansamantala lamang.
Kung mali ang resulta, hindi maganda ang performance nito, o sadyang pangit lang, hindi dapat ito nakatakas sa production. Kahit na ito ay pansamantalang output, kailangan itong maging presentable. Hindi ito tatanggapin ng mga end user at stakeholder. Gayunpaman, ang caveat ay maaaring katanggap-tanggap kung ito ang mga inaasahan na itinakda bilang bahagi ng proseso. “Tama ang mga numero, ngunit gusto namin ang iyong feedback sa mga kulay sa dashboard.” Gayunpaman, hindi ito dapat sa produksyon; ito ay dapat sa isang mas mababang kapaligiran. Kadalasan, ang “pansamantala lang” ay nagiging mabuting hangarin ng isang permanenteng problema. - Ito lang ang alam kong paraan. Minsan mayroong higit sa isang tamang sagot. At, kung minsan mayroong higit sa isang landas upang makarating sa isang destinasyon. Minsan dinadala natin ang ating mga dating gawi. Mahirap silang mamatay. Gamitin ito bilang isang sandali ng pag-aaral. Alamin ang tamang paraan. Maglaan ng oras. Humingi ng tulong.
- Ito ang paraang palagi naming ginagawa. Ang isang ito ay mahirap ayusin at mahirap makipagtalo. Nangangailangan ng tunay na pamamahala sa pagbabago ng organisasyon upang mabago ang mga proseso at ang mga taong gumaganap nito. Kadalasan, ang isang bagong proyekto, bagong software, isang pag-upgrade o isang paglipat, ay maglalantad ng matagal na mga nakatagong isyu. Oras na para magbago.
- Oops, Ginawa ko ulit.
Ako ay isang manggagawa sa kahoy at mayroon kaming motto dahil napakaraming pagkakamali: sukatin nang dalawang beses at isang beses na gupitin. Alam ko ang aphorism na ito. inuulit ko sa sarili ko. Ngunit, nahihiya akong sabihin, may mga pagkakataon pa rin na masyadong maikli ang aking board. Ito ba ay kawalang-ingat? siguro. Gayunpaman, mas madalas kaysa sa hindi, ito ay isang bagay na mabilis at madali. Hindi ko naman talaga kailangan ng plano. Pero, alam mo kung ano? Kung naglaan ako ng oras upang ilabas ito sa isang plano, malaki ang posibilidad na ang mga numero ay naisagawa. Ang piraso ay masyadong maikli ay maaaring nasa papel at isang pambura ang nag-aayos nito. Totoo rin ito sa analytics at business intelligence, ang isang plano - kahit na para sa isang bagay na mabilis at madali - ay maaaring mabawasan ang mga ganitong uri ng pagkakamali. - Mga Kaguluhan. Nakatingin pero hindi nakikita. Hindi sinasadyang Pagkabulag. Maaaring nakita mo ang video kung saan bibigyan ka ng gawain, tulad ng bilang ng mga pass sa basketball para sa isang koponan. Habang ginagambala ka sa pagsasagawa ng simpleng gawaing iyon, [SPOILER ALERT] hindi mo napapansin ang moon-walking gorilla. Alam ko kung ano ang mangyayari at gagawa pa rin ako ng isang kakila-kilabot na saksi kung may nagawang krimen. Ang parehong bagay ay nangyayari sa pagbuo ng mga ulat. Ang mga kinakailangan ay tumatawag para sa isang pixel-perfect alignment, ang logo ay dapat na napapanahon, ang legal na disclaimer ay dapat isama. Huwag hayaan na makagambala sa iyo mula sa pagtiyak na ang mga kalkulasyon ay mapatunayan.
- Sinadya mo.
O, inaasahan na. Hindi bababa sa, ito ay palaging isang pagpipilian. Sinabi ni Thomas Edison na "Hindi ako nabigo. Nakakita lang ako ng sampung libong paraan na hindi gagana.” Ang kanyang pilosopiya ay na sa bawat pagkabigo, siya ay isang hakbang na palapit sa tagumpay. Sa isang kahulugan, binalak niyang mabigo. Nag-aalis siya ng mga posibilidad. Trial and error lang ang ginawa niya nang maubusan siya ng mga teorya. Wala akong higit sa isang libong patent sa aking pangalan tulad ng Edison, ngunit sa palagay ko ay maaari tayong magkaroon ng mas mahusay na mga diskarte para sa pagbuo ng analytics o mga ulat. (Thomas Edison Patent Application para sa Incandescent Electric Lamp 1882.) - Katangahan. Huwag mong ipagkaila. Ito ay umiiral. Ang katangahan ay nasa isang lugar sa pagitan ng "Inanais mong gawin" at "Oops". Ang ganitong uri ng epic failure ay ang watch-this-hold-my-beer, Darwin Award variety. So, siguro, minsan may kasamang alak. Sa kabutihang palad, sa aming propesyon, sa pagkakaalam ko, ang isang lasing na dashboard ay hindi pumatay ng sinuman. Ngunit, kung pareho lang ito sa iyo, kung nagtatrabaho ka sa isang nuclear power plant, mangyaring gawin ang iyong analytics nang matino.
- Hindi mahalaga ang tagumpay.
Ang maalamat na stuntman na si Evil Knievel ay binayaran para sa pagsasagawa ng mga stunt na lumalaban sa kamatayan. Tagumpay o kabiguan - natigil man siya sa landing, o hindi - nakakuha siya ng tseke. Ang layunin niya ay mabuhay. Maliban na lang kung mabayaran ka para sa mga baling buto – si Knievel ay nagkaroon ng Guiness World Record para sa karamihan ng mga baling buto sa buong buhay – mahalaga ang tagumpay.
