Nilalaman
- Kailangan mo pa ba ng isang spec?
- Ano ang punto ng mga pagtutukoy?
- Ano ang hitsura ng mga panoorin sa mga araw na ito ...
- Ano ito dapat?
- Panatilihin itong totoo, kahit na nagbago ang katotohanan
- Ganun ba
Ang mga spec, kasama ang pagsubok at pamamahala ng mga pag-deploy, ay mga oras na lumubog. Nilamon nila ang mga araw ng buhay ng isang proyekto at hindi ginagawa ang ipinangako nila.
Ngunit kailangan sila. Kung kailangan mo ng isang maikling maikling o isang bagay upang mag-sign off sa pinuno ng marketing, ang pagkakaroon ng isang dokumento na maaari mong gamitin ng koponan sa araw-araw ay nagpapanatili ng momentum ng proyekto.
Kinuha namin ang ulo na ito. Sinuri namin ang lahat ng mga spec na mayroon kami. Inalis namin ang lahat ng crud. Nalaman namin na ang mga pagtutukoy ay maaaring maging sama-sama ng app na iyong binubuo.
Kailangan mo pa ba ng isang spec?
Ang mga pagtutukoy ay hindi magandang paglalarawan kung ano ang gusto ng totoong mundo. Ang mga ito ay mga shortcut para sa pagbuo ng isang gumaganang bagay, kaya't sinabi ng 37signals sa loob ng maraming taon na palaging mas mahusay na magkaroon ng gumaganang code na maaaring mai-tweak.
Minsan ang isang hindi magandang paglalarawan ay mas ligtas na isang mamahaling mock, ngunit huwag mong hayaang ibalik ka sa paggawa ng 100 mga pahinang dokumento na nais ng bawat isa na sunugin.
Sa trabaho ng ahensya, kung saan nakikipagtulungan ka sa mga koponan, kumpanya, timezone at bansa, imposible ang pagkuha ng napagkasunduang plano. Ang huling bagay na kailangan mo mula sa isang spec ay isang bagay na gumugugol ng kalahati ng pagsisikap ng koponan bago pa man nila simulan ang pag-unlad.
Kaya, oo. Iwasan ang mga pagtutukoy sa tuwing makakaya mo ngunit kung kailangan mong magsulat ng isa, paano mo ito pinapanatili?
Ano ang punto ng mga pagtutukoy?
Magsimula tayo sa kung ano ang punto ng mga pagtutukoy. Habang maraming at magkakaibang ideya tungkol sa kung paano dapat isulat ang mga detalye o kahit na bakit, ang sinumang nagtatrabaho sa isang ahensya o koponan ay kailangang magtanong:
- Ano ang bagay na ito at ano ang ibig sabihin nito na gawin?
At pagkatapos ay tatanungin nila:
- Paano ko magagawa ang aking kaunti upang magawa ko ito sa bagay na nais gawin?
Mas maging utopian pa tayo.
Ang mga pagtutukoy ay hindi dapat maging mahirap isulat, o mahirap basahin. Kung sila ay, ang mga nagsusulat o nagbabasa ng mga ito ay masasayang na enerhiya sa pagkuha ng kanilang ulo sa format kaysa sa proyekto.
Ang mga detalye ay hindi dapat maging mas malaki kaysa sa kinakailangan. Itapon ang kasaysayan ng bersyon at anumang paunang salita.
Ang mga pagtutukoy ay hindi maaaring maging malabo o hindi komit. Kung mayroon kang isang pangkalahatang ideya ngunit walang tumpak na plano kung paano ito ipapatupad pagkatapos ay mayroon kang isang katanungan, hindi isang spec. Maging tapat.
Dapat ay mayroon kaming isang mas magaan na dokumento na kung saan ay mas madaling basahin at isulat, at isa na kung saan ay mas matapat. At kapaki-pakinabang.
Ano ang hitsura ng mga panoorin sa mga araw na ito ...
Iyon ang aming pangarap na utopian ngunit ano ang mga bagay ngayon?
Ang pagkabigo na nagtulak sa akin upang itapon ang paraan ng aming mga pagtutukoy, at pagkumbinse ng aming mga kliyente na sundin ang suit ay nagmula sa magkakasalungat, kalahating binasa na mga dokumento na tila pangunahin nang nakasulat upang maging mabuti ang manunulat kaysa tulungan ang mambabasa na magawa ang anumang bagay.
Sa isang industriya kung saan ang komunikasyon ay lahat, at ang mga tao ay sumusulat para sa mambabasa sa lahat ng oras nakakagulat na kaya ilang tao ang maaaring magsulat para sa isang pangkat ng mga developer at taga-disenyo.
Karamihan sa mga proyekto ay nagsisimula sa isang Venn diagram ng mga pansariling interes. Ang bawat bahagi ng koponan ay nagsusulat ng kanilang dokumento, alinman sa pagtukoy sa iba pang mga dokumento o pagpasa ng responsibilidad.
Ang spec ng antas ng negosyo ay mula sa isang pares ng mga pangungusap hanggang sa mga hangarin na mayroon ang negosyo para sa proyekto. Ang maikling marketing ay nagsisimula sa mga layunin ng mga conversion, nadagdagan pagbisita o pagbabago sa tatak. Pagkatapos ay mayroong functional spec, ang IA, ang mga disenyo at teknikal na spec.
Ang bawat isa sa mga ito ay sumasagot sa ilang mga katanungan, nagtataas ng iba ngunit wala sa kanila ang may kapangyarihan dahil tumutukoy sila sa bawat isa. Halimbawa, "ito ay gagamitin sa mga disenyo" o "ang teknikal na spec ay magdaragdag ng karagdagang detalye dito" at "ang istrakturang TBC sa IA docs".
Idinagdag sa mga email, attachment, Basecamp thread, Google Docs, gistub sa Github at higit pa na ginagawang mahirap hanapin ang orihinal na hangarin. Kaya ang mga tao ay hindi. Gumagawa sila ng pinakamahusay na hula o trabaho mula sa dokumento na mayroon sila at pagkatapos ay nagkamali ang mga bagay.
Sa wakas, ang problema sa bawat isa sa mga detalye at salawal ay hindi na-update. Kapag napagtanto ng isang nag-develop ang isang bagay na dapat gawin nang iba, o ang tweak ng taga-disenyo ng disenyo hindi kami nag-aalala na i-update ang dokumento upang ito ay maging, sa pinakamahusay, walang silbi at, sa pinakamasamang, nakakasama sa sinumang nagsisimula sa proyekto.
Ito ay tulad ng isang paunang salita para sa isang mabibigat na format ng spec, daan-daang mga pahina ng makapal na may 20 mga appendice. Hindi naman. Kailangan pa rin naming panatilihing payat at praktikal ang aming format.
Ano ito dapat?
Tulad ng pagbuo ng isang app na nangangailangan ng pagsulat ng kopya, nagpapakain ang JSON mula sa isang bagong API, pag-coding sa frontend at katutubong programa na ang spec ay hindi dapat maging domain ng isang tao lamang. Makipagtulungan sa pagsasapalaran hindi lamang sa produkto.
Susunod, panatilihin ang isang may kakayahang dokumento na ini-edit ng lahat sa buong proyekto. Erehe ito sa pamamahala ng proyekto at alam kong wala ako sa mabuting kumpanya. Alinmang paraan ...
Lumikha tayo ng dokumentong ito at ilagay ito sa Dropbox. Mabuti ang Google Docs o anumang iba pang lugar na nagtutulungan, ngunit huwag hayaan ang tagapamahala ng proyekto na magkaroon ng tanging kopya anumang oras.
Ngayon kailangan namin ng isang format na nakabalangkas ngunit nangangailangan ng halos zero segundo upang maunawaan. Sinuri namin ang mga taon ng mga detalye, salawal, disenyo at wireframes at ididikit ito sa: UX, pamamahala sa nilalaman, pagpapatupad at mga katanungan. At isang larawan.
Magsimula sa isang larawan. Ang bawat pahina ay may larawan sa gitna. Isang scribble mula sa pulong ng kickoff (na marahil ang mas tumpak na larawan ng proyekto), isang wireframe o disenyo na mock up. Tratuhin ang bawat pahina bilang isang kuwento, at ipakita sa amin kung ano ang makikita ng gumagamit kapag nabuhay sila sa kwentong iyon.
Saklaw ng UX kung ano ang ginagawa ng bagay para sa anumang gumagamit. Ang nilalamang lilitaw sa pahina, ang paraan ng slide ng video, anong impormasyon ang mahahanap ng gumagamit. Karaniwan ito sa IA wireframes at sa mga functional spec, kaya madalas isinulat ng IA o mga manager ng proyekto.
Inilalarawan ng pamamahala ng nilalaman kung paano maaaring baguhin ng mga gumagamit ng negosyo ang nilalaman sa pahina. Ang pagpapatupad ay kung saan napupunta ang pagtutukoy ng teknikal, mga sanggunian sa code at mga tala ng API. Kahit na ang domain ng mga coder, ang pagbabahagi nito ay nagpapanatili ng mga ideya at prototype na umuunlad sa buong proyekto.
Panghuli, mga katanungan. Anumang bagay na hindi napagpasyahan o hindi malinaw ay pupunta dito. Dapat maging mahigpit ka. Ang unang kasalanan ng maraming mga salawal at pagganap na specs ay na nabasa nila tulad ng mga dokumento sa pagbebenta.
"Ang mga editor ng nilalaman ay maaaring mag-edit ng anumang bahagi ng homepage."
Hindi, hindi nila gagawin. Marahil ay makakapagtaguyod sila ng ilang mga kwento ng balita at binabago ang mga banner, kaya sabihin ito.
"Ang mga form ng pag-book ay ipapatupad gamit ang umiiral na system ng pag-book. Disenyo ng TBC."
Parang isang tanong na: "Kunin ang Dean upang tingnan ang mga pagpipilian sa disenyo ng system ng pag-book at gawin ang disenyo". Maging praktikal.
Ang pagiging matapat tungkol sa mga katanungan ay may dalawang bagay: mas matapat ka tungkol sa hindi pagkumpleto ng spec (sa madaling salita ay may mga katanungan pa rin para sa karamihan ng proyekto), at maaari mong ibahagi ang pasanin ng pagsagot sa kanila dahil nakikita ng ibang tao sa koponan kung ano ang kailangang magpasya.
Panatilihin itong totoo, kahit na nagbago ang katotohanan
Patay ang mga spec na hindi na-update, kaya't panatilihing buhay ang iyo sa pamamagitan ng pag-update ng mga larawan sa spec na may anumang pinakamahusay na sumasalamin sa katotohanan.
Kung nagsimula ka sa isang sketch, i-update ito sa ibang bagay kapag ang bagay na iyon nagdadagdag ng impormasyon. Iniiwasan ang walang kabuluhan at mamahaling pagsisikap na muling mabago ang bawat pahina mula sa maikli hanggang sa pagganap na spec, wireframes at pagkatapos ay disenyo.
Tuwing mayroong isang mas mahusay na representasyon ng iyong mga intensyon, palitan agad ang lumang representasyon. Palitan ang sketch ng disenyo at hindi na muling gagamitin ang sketch, at maiiwasan mo ang tanong na "aling bersyon ang tama".
Narito kung paano namin ilalapat ito sa isang mayroon nang pahina:
Ganun ba
Ang nagawa lang namin ay gawing mas mabilis ang pagtatrabaho ng koponan. Sa halip na ang diagram ng Venn ng mga digmaang ispesipikasyon, nagtutulungan kami mula sa simula ang lahat ng tumutukoy at pag-update ng isang bagay.
Ang mga detalye na ginawa ng mga propesyonal sa UX, IA at taga-disenyo ay pinagsama sa mga tala ng pag-unlad upang mapanatili ang isang solong ideya ng katotohanan sa buong proyekto. At kapag ang mga natapos na pahina o app ay isang mas mahusay na salamin ng kung ano ang gusto namin, sa halip ay gamitin mo ang mga ito.
Huwag dogmatika isipin na ang Visio, Photoshop o kopya ang pinakamahusay.
Marami sa mga narito ang ginagawa ng mga startup at koponan ng Agile, ngunit ang mga ahensya ay dapat na matatag sa pinakamahusay na paraan ng pagtukoy ng mga proyekto.
Sa sobrang sukdulan, binawasan namin ang oras ng pag-unlad mula sa mga linggo hanggang sa ilang araw at pinutol ang mga araw ng pagtutukoy na naging sanhi ng pagkamuhi ng proyekto ng proyekto.
Hindi ito magiging isang bala ng pilak, ngunit sino ang ayaw ng pagkakataon na maiwasan ang pagbabasa ng isa pang 50 pahina na paglalarawan kung paano gumagana ang isang blog?
Larawan na "Pagtukoy" mula sa Bigstock.
