Բովանդակություն
- Ձեզ նույնիսկ սպեկտրի կարիք կա՞:
- Ի՞նչ իմաստ ունի ակնոցը:
- Ինչպիսի տեսք ունեն այս օրերին ...
- Ինչ պետք է լինի:
- Այն պահեք ճշմարտացիորեն, նույնիսկ այն ժամանակ, երբ ճշմարտությունը փոխվում է
- Դա՞ է
Հատկությունները, տեղակայման փորձարկումների և կառավարման հետ մեկտեղ, ժամանակի խորտակիչներ են: Նրանք կուլ են տալիս նախագծի կյանքի օրերը և չեն կատարում այն, ինչ խոստանում են:
Բայց դրանք անհրաժեշտ են: Անկախ նրանից, թե ձեզ հարկավոր է կարճ ամփոփագիր կամ ինչ-որ բան շուկայավարման ղեկավարի հետ ստորագրելու համար, ունենալով փաստաթուղթ, որը դուք և թիմը իրականում կարող եք օգտագործել օրեցօր, պահպանում է ծրագրի թափը:
Մենք այս գլուխը վերցրինք: Մենք վերանայեցինք մեր ունեցած բոլոր բնութագրերը: Մենք հանեցինք ամբողջ հումքը: Մենք հայտնաբերեցինք, որ բնութագրերը կարող են նույնքան համագործակցային լինել, որքան ձեր կառուցած հավելվածը:
Ձեզ նույնիսկ սպեկտրի կարիք կա՞:
Տեխնիկական բնութագրերը վատ նկարագրությունն են այն բանի, թե ինչպիսին կարող է լինել իրական աշխարհը: Դրանք աշխատանքային բան կառուցելու դյուրանցումներ են, ուստի, ինչպես տարիներ շարունակ ասում են 37 ազդանշանները, միշտ ավելի լավ է ունենալ գործող կոդ, որը հնարավոր է շտկել:
Երբեմն աղքատ նկարագրությունն ավելի անվտանգ է, քան թանկ ծաղրը, բայց թույլ մի տվեք, որ դա ձեզ հետ գցի 100 էջանոց փաստաթղթեր արտադրելու, որոնք բոլորը ցանկանում են այրել:
Գործակալության աշխատանքում, որտեղ համագործակցում եք թիմերի, ընկերությունների, ժամային գոտիների և երկրների միջև, համաձայնեցված ծրագիր ստանալն անհնար է: Վերջին բանը, որ ձեզ հարկավոր է առանձնահատկությունից, այն է, ինչ սպառում է թիմի ջանքերի կեսը, նախքան նրանք նույնիսկ կսկսեն զարգացումը:
Այսպիսով, այո: Խուսափեք ակնոցներից, երբ կարող եք, բայց երբ անհրաժեշտ է գրել մեկը, ինչպե՞ս եք այն նիհար պահում:
Ի՞նչ իմաստ ունի ակնոցը:
Եկեք սկսենք նրանից, թե որն է բնութագրերի կետը: Չնայած կան բազմաթիվ ու տարբեր գաղափարներ այն մասին, թե ինչպես պետք է գրել ակնոցը կամ նույնիսկ ինչու, որևէ մեկը, ով աշխատում է գործակալությունում կամ թիմում, պետք է հարց տա.
- Ի՞նչ է այս բանը և ի՞նչ էր նախատեսվում անել:
Եվ հետո նրանք կհարցնեն.
- Ինչպե՞ս անեմ իմ բիտը, որպեսզի այն կատարի այն բանը, ինչ նախատեսված էր:
Եկեք էլ ավելի ուտոպիստ լինենք:
Տեխնիկական պայմանները չպետք է լինեն դժվար գրելու, ոչ էլ դժվար ընթերցելու համար: Եթե դրանք լինեն, նրանք, ովքեր գրում են դրանք կամ կարդում, ավելի շատ էներգիա կվատնեն, քան իրենց նախագիծը մտցնելու ձևաչափը:
Տեխնիկական պայմանները չպետք է լինեն ավելի մեծ, քան անհրաժեշտ են: Նետեք վարկածի պատմությունը և ցանկացած նախաբան:
Ակնարկները չեն կարող լինել անորոշ կամ ոչ պարտավորեցնող: Եթե ունեք ընդհանուր գաղափար, բայց չունեք հստակ ծրագիր, թե ինչպես է այն կյանքի կոչվելու, ապա ձեզ մոտ հարց է առաջանում, այլ ոչ թե հստակեցում: Ազնիվ եղիր.
Մենք պետք է ունենանք ավելի թեթեւ փաստաթուղթ, որն ավելի հեշտ է կարդալ և գրել, և մեկը, որն ավելի ազնիվ է: Եվ օգտակար:
Ինչպիսի տեսք ունեն այս օրերին ...
Դա մեր ուտոպիստական երազանքն է, բայց ինչպիսի՞ն են հիմա բաները:
Հիասթափությունը, որն ինձ դրդում էր դուրս նետել մեր ակնարկները և համոզել մեր հաճախորդներին հետևել այդ օրինակին, բխում էին իրարամերժ, կիսընթերցված փաստաթղթերից, որոնք, կարծես, գրված էին հիմնականում գրողին լավ զգալու համար, քան օգնելու ընթերցողին անել ինչ որ բան:
Արդյունաբերության մեջ, որտեղ հաղորդակցությունն ամեն ինչ է, և մարդիկ անընդհատ գրում են ընթերցողի համար, զարմանալի է, որ այդքան քիչ մարդիկ կարող են գրել մշակողների և դիզայներների թիմի համար:
Projectsրագրերի մեծ մասը սկսվում է Վեննի սեփական շահերի գծապատկերից: Թիմի յուրաքանչյուր մաս գրում է իր փաստաթուղթը ՝ կամ հղում անելով մյուս փաստաթղթերին կամ անցնելով պատասխանատվություն:
Բիզնեսի մակարդակի բնութագիրը տատանվում է մի քանի նախադասությունից մինչև բիզնեսի նպատակները նախագծի համար: Շուկայավարման ամփոփագիրը սկսվում է ապրանքանիշի փոխարկումների, այցելությունների ավելացման կամ ապրանքային փոփոխությունների նպատակներից: Այնուհետև կա գործառութային բնութագիր, IA, նմուշներ և տեխնիկական բնութագիր:
Սրանցից յուրաքանչյուրը պատասխանում է որոշ հարցերի, առաջացնում այլ հարցեր, բայց ոչ մեկը հեղինակավոր չէ, քանի որ դրանք վերաբերում են միմյանց: Օրինակ ՝ «սա կտարածվի նախագծերում» կամ «տեխնիկական բնութագիրն այստեղ ավելի մանրամասն կավելացնի» և «TBC կառուցվածքը IA փաստաթղթերում»:
Դրան գումարվում են էլ. Նամակները, հավելվածները, Basecamp- ի թեմաները, Google Docs- ը, Github- ի ակնարկները և ավելին ՝ աննպատակահարմար է գտնում բնօրինակը մտադրությունը: Այսպիսով մարդիկ չեն անում: Նրանք լավագույն գուշակություն են անում կամ աշխատում իրենց ունեցած փաստաթղթից, և հետո ամեն ինչ սխալ է ընթանում:
Վերջապես, ակնոցներից և համառոտագրերից յուրաքանչյուրի խնդիրն այն է, որ դրանք թարմացված չեն: Երբ մշակողը գիտակցում է, որ ինչ-որ բան պետք է այլ կերպ արվի, կամ դիզայները փոխի ձևավորումը, մենք չենք ձգտում թարմացնել փաստաթուղթը, որպեսզի այն դառնա, լավագույն դեպքում, անօգուտ և վատթարագույն `վնաս հասցնողին, ով սկսում է նախագիծը:
Սա հնչում է որպես նախաբանի ծանր տեխնիկական ձևաչափի, հարյուրավոր էջերի հաստությամբ `20 հավելվածով: Դա այդպես չէ: Մենք դեռ պետք է մեր ձևաչափը նուրբ և գործնական պահենք:
Ինչ պետք է լինի:
Likeիշտ այնպես, ինչպես ծրագիր ստեղծելը, որը պահանջում է պատճենահանման գրառում, JSON- ը թարմացվում է նոր API- ից, առջևի կոդավորմամբ և տեղական ծրագրավորմամբ, բնութագիրը չպետք է լինի միայն մեկ անձի տիրույթ: Համագործակցեք ակնարկի վերաբերյալ, ոչ միայն արտադրանքի մասին:
Հաջորդը պահեք մեկ հեղինակավոր փաստաթուղթ, որը բոլորը խմբագրում են նախագծի ողջ ընթացքում: Սա ծրագրի կառավարման հերետիկոսությունն է, և ես գիտեմ, որ լավ ընկերություն չեմ անում: Երկու դեպքում էլ ...
Եկեք ստեղծենք այս փաստաթուղթը և տեղադրենք այն Dropbox- ում: Google Փաստաթղթերը կամ համագործակցության ցանկացած այլ վայր լավ է, բայց թույլ մի տվեք, որ ծրագրի ղեկավարն ունենա միակ օրինակը ցանկացած պահի:
Այժմ մեզ պետք է մի ձևաչափ, որը կառուցվածքային է, բայց հասկանալու համար պահանջվում է գրեթե զրո վայրկյան: Մենք վերլուծեցինք տարիների ակնարկները, համառոտագրերը, նախագծերը և մետաղալարերը և դրանք թորեցինք `UX, բովանդակության կառավարում, իրականացում և հարցեր: Եվ նկար:
Սկսեք նկարից: Յուրաքանչյուր էջի մեջտեղում կա նկար: Խզբզոց մեկնարկային հանդիպումից (որը, հավանաբար, նախագծի առավել ճշգրիտ պատկերն է), մետաղալար կամ դիզայնի ծաղրում: Յուրաքանչյուր էջին վերաբերվեք որպես պատմություն և մեզ ցույց տվեք, թե ինչ կտեսնի օգտվողը, երբ ապրի այդ պատմության միջով:
UX- ն ընդգրկում է այն, ինչն անում է ցանկացած օգտվողի համար: Էջում հայտնվող բովանդակությունը, տեսանյութի սահելու եղանակը, օգտվողը ինչ տեղեկություններ կարող է գտնել: Սա բնորոշ է IA լարային շրջանակների և ֆունկցիոնալ բնութագրերի վրա, ուստի հաճախ այն գրվում է IA- ի կամ ծրագրի ղեկավարների կողմից:
Բովանդակության կառավարումը նկարագրում է, թե ինչպես գործարար օգտվողները կարող են փոխել էջի բովանդակությունը: Իրականացումն այն վայրն է, որտեղ գնում են տեխնիկական բնութագրերը, կոդերի հղումները և API նշումները: Չնայած կոդավորողների տիրույթում, այն տարածելը պահպանում է գաղափարներն ու նախատիպերը առաջընթացի ընթացքում:
Վերջապես, հարցեր: Thingանկացած բան, որը անվճռական է կամ անորոշ, գնում է այստեղ: Պետք է խիստ լինել: Շատ համառոտագրությունների և ֆունկցիոնալ բնութագրերի առաջին մեղքն այն է, որ դրանք կարդում են վաճառքի փաստաթղթերի նման:
«Բովանդակության խմբագրողները կկարողանան խմբագրել հիմնական էջի ցանկացած հատված»:
Ոչ, նրանք չեն անի: Նրանք, հավանաբար, կկարողանան գովազդել որոշ նորություններ և փոխել պաստառները, այնպես որ ասեք դա:
«Ամրագրման ձևերը կիրականացվեն առկա ամրագրման համակարգի միջոցով: Նախագծեք TBC»:
Կարծես թե հարց է. «Ստացեք Դինին ուսումնասիրել ամրագրման համակարգի նախագծման տարբերակները և կատարել դիզայն»: Եղեք գործնական:
Հարցերի վերաբերյալ անկեղծ լինելը երկու բան է բերում. Դուք ավելի ազնիվ եք բնութագրի անավարտության վերաբերյալ (այլ կերպ ասած ՝ նախագծի մեծ մասի համար դեռ հարցեր կան), և կարող եք կիսել դրանց պատասխանելու բեռը, քանի որ թիմի մյուս մարդիկ տեսնում են ինչ պետք է որոշվի:
Այն պահեք ճշմարտացիորեն, նույնիսկ այն ժամանակ, երբ ճշմարտությունը փոխվում է
Չբարեկարգված տեխնիկական պայմանները մեռնում են, այնպես որ ձերն ապրեք ՝ թարմացնելով նկարում նկարներն այն ամենով, ինչն ավելի լավ է արտացոլում իրականությունը:
Եթե դուք սկսել եք ուրվագիծով, ապա թարմացրեք սա ինչ-որ այլ բանի հետ, երբ դա ինչ-որ բան է տեղեկատվություն է ավելացնում, Խուսափում է անիմաստ և թանկ ջանքերից `վերամշակելով յուրաքանչյուր էջ` սկսած հակիրճից մինչև ֆունկցիոնալ առանձնահատկություններ, մետաղալարեր և ապա ձևավորում:
Երբ որ ձեր մտադրության ավելի լավ ներկայացում լինի, անմիջապես փոխարինեք հին ներկայացուցչին: Էսքիզը փոխարինեք դիզայնով և այլևս երբեք մի օգտագործեք ուրվագիծը, և դուք ամբողջությամբ կխուսափեք «որն է տարբերակը ճիշտ» հարցից:
Ահա, թե ինչպես մենք դա կօգտագործենք գոյություն ունեցող էջի վրա.
Դա՞ է
Այն ամենը, ինչ մենք արել ենք, այն է, որ թիմն ավելի շուտ աշխատի միասին: Փոխանակ ճշգրտման պատերազմների Վեննի դիագրամը, մենք ի սկզբանե միասին աշխատում ենք ՝ բոլորը հղում կատարելով և թարմացնելով մի բան:
UX- ի մասնագետների, IA- ի և դիզայներների արտադրության առանձնահատկությունները միավորվել են զարգացման նոտաների հետ `ծրագրի ողջ ընթացքում ճշմարտության վերաբերյալ մեկ գաղափար պահելու համար: Եվ երբ ավարտված էջերը կամ հավելվածն ավելի լավ արտացոլում են մեր ուզածը, փոխարենը օգտագործում եք դրանք:
Դոգմատիկորեն մի կարծեք, որ Visio- ն, Photoshop- ը կամ պատճենը լավագույնն են:
Այստեղ շատ բան արվում է սկսնակ և Agile թիմերի կողմից, բայց գործակալությունները պետք է ամուր լինեն ՝ նախագծերը ճշգրտելու լավագույն ձևով:
Theայրահեղ դեպքում, մենք զարգացման ժամանակը կրճատեցինք շաբաթներից մի քանի օր և կտրեցինք հստակեցման օրերը, ինչը ծրագրի ղեկավարին ստիպեց ատել նախագիծը:
Սա չի լինի արծաթե փամփուշտ, բայց ո՞վ չի ցանկանում, որ հնարավորություն ունենա խուսափել բլոգի գործելու եւս 50 էջի նկարագրությունը կարդալուց:
«Հստակեցում» պատկերը Bigstock- ից:
