Tehniskās specifikācijas ventilācijas modernizācijai pētniecības institūtā. Tehniskās specifikācijas ventilācijas modernizācijai izpētes objektā Tehniskās specifikācijas uzglabāšanas servera pārveidošanai

Kāpēc ir nepieciešama tehniskā specifikācija?

Programmētāja tehnisko specifikāciju piemērs

Pārejot pa ārzemju vietnēm ar pieprasījumu “preces prasību dokuments”, var atrast radošus un pārliecinošus rakstus par to, ka tehniskās specifikācijas (TOR, PRD) ir beigušās. Tam daļēji jāpiekrīt - izstrādājot produktu no nulles, prototipēšana izskatās daudz interesantāka un efektīvāka nekā klientu piezīmju sējumi, kas dažkārt ir ļoti neprofesionāli. Taču, ja runājam par pamatsistēmas pabeigšanu, tad lietas uzņem pavisam citu pagriezienu. Saskaramies gan ar modifikācijām, gan pēc pasūtījuma izstrādi, tāpēc tehniskā specifikācija ir suns-ēds, ja šefpavārs mums nemelo. Kopumā šodien mēs runājam par tiem klasiskajiem tehniskajiem uzdevumiem, kas tiek rakstīti, lai pabeigtu iegādāto un uzstādīto programmatūra. Īsāk sakot, par sāpīgām lietām.

Mijiedarbības aspekti

Resursi- cilvēki, mašīnas, iekārtas, izstrādes vide, laiks un nauda, ​​kas jāizmanto prasību ieviešanas procesā. Resursiem ir nepieciešama skaidra plānošana un novērtēšana tehnisko specifikāciju apstiprināšanas posmā. Pareiza prioritāšu noteikšana no klienta puses un darbaspēka resursu sadale no pārdevēja puses ļauj izvairīties no termiņu nokavēšanas un samazināt citus riskus.

Iespējas- Īsāk sakot, tas ir tas, ko pārdevējs (izpildītājs) faktiski var darīt. Apskatīsim mūsu RegionSoft CRM piemēru. Klients iegādājas sistēmu un sastāda modifikācijas tehnisko specifikāciju: nepieciešams izveidot integrāciju ar vietni un saistīt notikumus CRM ar interneta veikala pasūtījuma numuru. Tā ir reāla prasība, mums ir resursi un iespējas to izdarīt. Tāpat ir jāizstrādā un CRM jāpievieno vietņu satura pārvaldības sistēma CMS. Teorētiski mēs to varam, bet mums nav iespēju to izdarīt lēti, un klientam nav iespējas samaksāt mums tik daudz, lai mēs atvēlētu cilvēka un laika resursus uzdevuma veikšanai. Rezultātā klients atsakās no šīs prasības - un viņam CMS īsti nav vajadzīga, viss ir kārtībā. Bet par TK “alkatību” vēlāk.

Ierobežojumi- šķēršļu kopums, kas apgrūtina vai padara neiespējamu tehnisko specifikāciju uzdevumu izpildi: budžets, tehnoloģiju kopums, licencēšanas problēmas, likumdošanas aizliegumi, aparatūras konfigurācijas utt.

Tādējādi visas četras būtības ir cieši saistītas un nosaka projekta panākumus kopumā. Apskatīsim katru elementu un mēģināsim izcelt kritiskos punktus, kas jāpatur prātā, strādājot pie tehniskajām specifikācijām.

Prasību apkopošana un analīze

Neviens nezina jūsu uzņēmumu labāk kā jūs un jūsu darbinieki. Tas nozīmē, ka prasību apkopošana un analīze ir tikai un vienīgi jūsu uzdevums, kurā pārdevējs var palīdzēt un vadīt, taču nekādā gadījumā netraucē procesu. Jautājiet izstrādātājam par šādām ieviešanām, uzziniet, ko meklēt, un sāciet darbu. Starp citu, labs palīgs var būt jūsu darbinieks, kurš labi pārzina specializēto tēmu un kuram ir aptuvens priekšstats par programmatūras arhitektūru un pārzina izstrādes procesu - viņš var darboties kā analītiķis un iekšējais eksperts, pārrauga tehnisko specifikāciju izveides un saziņas ar pārdevēju process.

Ir ļoti vienkārša ķēde savākšanas prasības.

1. Izveidojiet darba grupu no vadītājiem un pieredzējušiem speciālistiem no nodaļām, kas izmantos CRM. Pastāstiet mums par risinājumu, kuru plānojat izvēlēties, nodrošiniet piekļuvi demonstrācijas versijai.
2. Darba grupas dalībniekiem ir jāsniedz informācija darbiniekiem un jālūdz viņu ieteikumi jauna programma pilnīgi brīvā formā. Ja kāds no darbiniekiem nekad nav saskāries ar šādu programmatūru un nav gatavs runāt par turpmāko izmantošanu, jums jālūdz viņam aprakstīt savus periodiskos uzdevumus; tā ir universāla pieeja.
3. Pēc tam katra nodaļa nosaka, kas CRM nav vai kas neatbilst, un apkopo informāciju.
4. Darba grupa analizē apkopotās prasības, pārbauda un likvidē krustojumus. Piemēram, bieži vien pārdošanas nodaļa un mārketinga nodaļa pasūta vienu un to pašu pārskatu, taču prasībām var būt atšķirīgi nosaukumi laukiem un entītijām, lai gan aiz tiem esošie dati ir vienādi. Attiecīgi mums ir jānonāk pie vienotas formas.
5. Darba grupa veido prasību sarakstu un nosaka prioritātes. Šajā posmā varat iesaistīt pārdevēju, jo viņš ir atbildīgs par resursiem. Piemēram, varat lūgt izveidot pielāgotu pārskatu RegionSoft CRM vai pasūtīt integrāciju ar vietni. Tie ir uzdevumi ar pilnīgi atšķirīgiem termiņiem, prioritāte šeit ir ļoti svarīga.

Tehniskās specifikācijas anatomija

• Identificēšana - prasību noteikšana, risināmu problēmu atrašana.
• Analīze - prasību analīze, galveno vajadzību noteikšana, vispārināšana.
• Adaptācija – prasību izvērtēšana CRM iespēju un esošo biznesa procesu kontekstā.
• Dokumentācija - formāla un Detalizēts apraksts prasības, tehnisko specifikāciju apstiprināšana.
• Komunikācija ar pārdevēju (izstrādātāju) - iteratīva mijiedarbība ar pārdevēju par uzlabojumiem saskaņā ar sastādītajām tehniskajām specifikācijām.
• Ieviešana ir pārdevēja darbs, lai izveidotu nepieciešamo funkcionalitāti. Labāk, ja pārdevējs pastāvīgi sazinās ar klientu – tādā veidā galaprodukts visprecīzāk atbildīs klienta redzējumam.
• Testēšana - funkcionalitātes pārbaude, ko veic pārdevēja darbinieki, klienta iekšējie eksperti un gala lietotāji, lai noteiktu atbilstību izmaiņām un tehniskajām specifikācijām, kā arī sistēmas darbspēju ar izmaiņām.

Biznesa līmenis- globālākais līmenis, kurā tiek risināti sarežģīti un prioritāri uzdevumi. Šajā līmenī ietilpst biznesa procesu integrācija, uzlabojumi un modelēšana, jaunu funkcionālo moduļu izstrāde. Kā likums, šī ir resursietilpīga attīstība, ar nopietnām konsultācijām un tuvu strādāt kopā ar klientu. Piemēram, savulaik RegionSoft CRM šādas pielāgotas modifikācijas bija noliktavas uzskaite, kases aparāts un ražošana. Pakāpeniski izmaiņas tika iekļautas laidienā, un vēlāk ļāva izveidot jaunu produktu vairumtirdzniecībai, mazumtirdzniecības veikaliem un hipermārketiem - RegionSoft Retail.

Lietotāja vai lietotāju grupas līmenis.Šajā līmenī tiek īstenoti uzdevumi esošās saskarnes uzlabošanai. Piemēram, lietotājs var vēlēties, lai, virzot kursoru virs klienta, tiktu parādīts logs ar pēdējā pasūtījuma numuru un statusu vai pielāgotu pārskatu ar īpašu datu grupu. Uzlabojumi šajā līmenī aizņem mazāk laika, taču to var būt daudz - piemēram, vairākas prasības no mārketinga, loģistikas un tehniskā palīdzība.

Funkcionalitātes līmenis. Bieži vien ir grūti to nošķirt no iepriekšējā, šeit darbojas formāls kritērijs - uzlabojumi notiek nevis interfeisa kaut kā parādīšanas līmenī, bet gan sistēmas loģikas pabeigšanas līmenī. Tas var ietvert prasības dažāda veida šķirošanai, tērzēšanas integrācijai un telefonijas iespējām.

Servisa līmenis- patiesībā šī līmeņa prasībām vajadzētu būt pirmajām, kas jāiekļauj jaunbūvēs ar labojumiem. Tie ir uzdevumi, kas saistīti ar sistēmas reakcijas ātrumu, darbību ar lielu slodzi un drošību. IN ideāls Pārdevējam nevajadzētu veikt šādas modifikācijas - korporatīvajai programmatūrai nevajadzētu palēnināt, zaudēt datus, sakļaut veidlapas un izplatīt tāda paša līmeņa piekļuves tiesības. Bet, ja parādās prasība, un tā nav saistīta ar klienta personīgo paranoju vai problēmām no sāniem aparatūra, ir vērts pievērst tam īpašu uzmanību.

Tehnoloģiju līmenis- pēdējā sarakstā, bet svarīguma un sarežģītības ziņā apsteidz pārējos. Tās varētu būt ar platformu saistītas klientu prasības, operētājsistēma vai ierīcēm. Piemēram, pieprasījums izveidot operētājsistēmai MacOS. Būs lieliski, ja šādas prasības pakāpeniski pārtaps laidienos, taču tām obligāti jābūt labojumiem. Pamatojoties uz klientu pieprasījumiem šajā līmenī, mēs izveidojām RegionSoft CRM operētājsistēmai MacOS un pievienojām attālā piekļuve izmantojot TRM tehnoloģiju kā pagaidu risinājumu retam, bet esošam mobilās versijas pieprasījumam.

Tehniskās specifikācijas anatomija ir vienkārša, vismaz skeleta formā. Tehniskās specifikācijas obligātās daļas palīdz pasūtītājam koncentrēties uz problēmu un pareizi formulēt uzdevumu, bet darbuzņēmējam saprast, ko no viņa vēlas. Starp citu, par sapratni. Protams, ieraksta sākumā mēs nedaudz melojām, noliedzot biznesa konsultantus kā klasi. Lieta ir šāda: katrs pārdevējs ir strādājis tirgū vairākus gadus (mēs nerunājam par vienas dienas CRM) vai pat gadu desmitiem, kas nozīmē, ka viņiem ir noteikts lietu kopums gandrīz katrā nozarē. Attiecīgi inženieri, programmētāji un pārdevēji ir iepazinušies ar katra veida uzņēmuma ieviešanas specifiku. Bet atkal ir svarīgi koncentrēties uz savu biznesu.

Priekš kura?Šajā sadaļā jāapraksta, kas būs uzlabojuma galalietotājs, kādus uzdevumus plānots risināt un ar kādu biežumu.

Ļaujiet man sniegt jums piemēru. Viens uzņēmums ieviesa CRM, un tam bija paredzēts strādāt ar diezgan lielu datu masīvu (vairāki desmiti miljonu ierakstu mēnesī, vairāki simti tūkstošu ierakstu dienā). Pārdošanas nodaļas vadītājs pieprasīja ziņojumu par šo ierakstu augšupielādi “ikdienas” biežumā. Likumsakarīgi, ka šāds ziņojums, vienlaikus strādājot simtiem lietotāju, noslogoja sistēmu – tika atrasti risinājumi procesa optimizēšanai. Jau darba laikā atklājās, ka pārdevējs ir nospēlējis un atskaite bija nepieciešama tikai mēneša beigās, un tad to varētu palaist pēc grafika naktī. Lieki piebilst, ka laiks un nauda tika izšķiesti.

Par ko? Uzlabojumu nepieciešamības pamatojums un vieta biznesa procesā. Šis punkts ir vairāk nepieciešams pašam klientam, bet arī pārdevējam ir noderīgi zināt, kādi citi procesi tiks ietekmēti. Dažreiz tas palīdz atrast alternatīvu risinājumu.

Ko tai vajadzētu darīt? Informatīvākais bloks - tas apraksta prasības un cerības no sistēmas. Un te notiek tās pašas pērles, brīnumi un sadursmes, kuras ir tieši tā, lai sūtītu uz bashorgu un kas, nu, ļoti apgrūtina dzīvi. Iemesls ir tikai viens – lietotājs nezina, ko viņš grib, kas ir jādara. Ir vēl viens neliels apakšiemesls – lietotājs nevar formulēt prasības. Un šeit izstrādātāja (darba grupas, analītiķa, ja tāda ir) uzdevums ir palīdzēt pareizi formulēt vajadzību, izvēlēties atbilstošu prasību un iekļaut uzdevumu sistēmas darbības kontekstā. Tajā pašā blokā jums jāmin gaidāmais rezultāts.

Specifikācijas parametri- termiņi, īstenošanas posmi, atbildība no visām pusēm, nepieciešamie kontakti utt. Faktiski tas ir svarīgu formālu lietu kopums, kas padara dokumentu par tehnisko specifikāciju. Darba uzdevums ir jāsaskaņo un jāparaksta pusēm, lai izstrādes gaitā izvairītos no daudzām izmaiņām (tās joprojām notiks, bet mazākā mērā).

Ideālā gadījumā tehniskā specifikācija tiek izstrādāta, aktīvi piedaloties pārdevējam, un tās rezultāts ir aptuveni šāda struktūra:

1. Katra mehānisma un katras funkcionalitātes prasību apraksts
2. Šīs funkcionalitātes ieviešanas apraksts
3. Darba izmaksas katram posmam atsevišķi
4. Kopējās darbu izmaksas šai tehniskajai specifikācijai
5. Darba pabeigšanas termiņi, kas sadalīti pa posmiem un norādot prioritāti
6. Uzstādīšanas apstākļu apraksts un modifikāciju pārbaude
7. Atrunas attiecībā uz darba uzdevuma un citu nosacījumu izsmeļošu raksturu

10 noteikumi, kas rakstīti izstrādātāja asarās

Tehniskā specifikācija nedrīkst būt mantkārīga. Bieži vien uzņēmums pārvērtē savas iespējas vai vēlas iegūt “visu uzreiz”. Šāda pieeja nav attaisnojama ne no finansiālā, ne biznesa viedokļa. Pārdevējs, kā likums, neeksistē pāris nedēļas (RegionSoft gadījumā - 15 gadus), un jūs varat sazināties ar viņu pēc kāda laika, kad patiešām saprotat, kas trūkst CRM.

Spilgts atlaišanas piemērs burtiski no vakardienas: klients iegādājās ERP no viena labi pazīstama Krievijas uzņēmums, domājot, ka tā kā grāmatvedība darbojas, tad šī pārdevēja ERP būs labs. ERP izrādījās ne tikai ne pārāk laba pati par sevi, bet arī ļoti nepiemērota biznesam. Bet RegionSoft CRM ar noliktavas grāmatvedība un piemērots ražošanai. Ir risinājums: aizmirstiet par ERP, raudiet, integrējiet 1C grāmatvedību ar jauno CRM un izbaudiet ērtu ieviešanu. Bet žēl par iztērēto naudu! Un klientam ir jāintegrē CRM ar ERP. Mēs to nedarījām, bet kāpēc tāda izšķērdība, kāpēc divas salīdzinoši līdzīgas sistēmas?

Darba uzdevumam jābūt reālistiskam un sasniedzamam- gan prasību, gan termiņu ziņā. Šeit ir svarīgi uzklausīt pārdevēja viedokli, jo viņš precīzi zina, cik daudz laika tiks pavadīts šim vai citam uzdevumam. Tici man, attīstītājam nav izdevīgi tērēt laiku un palielināt termiņus - viņam ir izdevīgi pabeigt pēc iespējas vairāk projektu un izdarīt to labi, lai neciestu uz savu reputāciju. Runājot par reālismu, ir viegli izvairīties no pieprasījumiem jaunināt CRM līdz sadursmes pārvaldības sistēmas līmenim: prasībās jāiekļauj tas, kas patiešām ir nepieciešams Šis brīdis un pārskatāmā nākotnē.

Piemēram, RegionSoft CRM ir darbvirsmas programma; mums nav pārlūkprogrammas klienta. Lūgt mums izveidot tīmekļa aplikāciju vienam uzņēmumam ir bezjēdzīgi, tā ir liela attīstība, šobrīd notiek un nav iespējama attīstība vienam uzņēmumam. Nē, visam, protams, ir sava cena, bet atkal - vispārīgā gadījumā prasību izpildīt nav iespējams.

To nevajadzētu jaukt ar situāciju, kad runa ir par individuālu izstrādi un aplikācijas ideja un loģika tiek radikāli mainīta, patiesībā tiek sponsorēta jaunas programmatūras izveide “sev”. Bet tas ir cits stāsts.

Darba uzdevumam jābūt detalizētam. Ir jānorāda visas būtiskās nākotnes projekta detaļas: no programmas lietošanas biežuma līdz interfeisa vēlmēm. Jo detalizētākas ir prasības, jo vieglāk un ātrāk būs ieviešana un testēšana. Īpaši ir vērts pievērst uzmanību detaļām, ja strādājat konkrētā nozarē (medicīna, apdrošināšana, bankas) - detalizēts biznesa un programmas mijiedarbības nianses izklāsts nodrošinās, ka pārdevējs sapratīs uzdevumu un ātri pielāgos sistēmu Tava kompānija.

Noteikti pievērsiet uzmanību skaitļu formātiem, lauku nosaukumiem, nolaižamo sarakstu esamībai vai neesamībai, pogu un ieteikumu darbībai un datu veidiem. Ja klients izmanto savas formulas, kas jāiekļauj CRM darbības loģikā ( piemēram, dīleru bonusu aprēķināšana), šīs formulas ir jāraksta ar pilnu to apzīmējumu un aprēķinu loģikas skaidrojumu.

Tehniskajai specifikācijai jābūt nepārprotamai un precīzai. Nekonkrēti formulējumi, ieviešanas iespējas, neskaidras prasības – tas viss ir ceļš uz strupceļu. Gadās, ka klients labu nodomu dēļ tehniskajā specifikācijā ieraksta vairākus sistēmas darbības variantus, tuvus, bet ne līdzvērtīgus. Šajā gadījumā viņš ir pārliecināts, ka palīdz, pamudina programmētāju, bet patiesībā ceļš uz elli ir bruģēts ar labiem nodomiem, izstrādātājam ir jāsaprot, kas tieši ir vajadzīgs, un viņš pats izvēlēsies, kā to izdarīt, pamatojoties uz par sistēmas īpašībām un izmantoto tehnoloģiju kopumu.

Tehniskajai specifikācijai jābūt uzrakstītai cilvēku valodā. Un tas ir svarīgi, nē, SVARĪGI. Izcelšu divas situācijas, kad valodas problēmas noved pie projektu īstenošanas aizkavēšanās.

1. Klients cenšas demonstrēt savu tehnisko pratību un veido tādas konstrukcijas kā: “ieviest logu ar mājienu kalendāra pamattekstā ar iespēju reaģēt uz notikumu izsaukšanu...”, nevis “kalendārā jāparādās logam. kurā varat atzīmēt uzdevumu kā izpildītu.” Ja jums vai jūsu iekšējam ekspertam nav prasmju rakstīt tehniskos tekstus, nemeklējiet Google - rakstiet ar parastajiem vārdiem, mēs tos saprotam.

   Darba uzdevumam nevajadzētu būt sūdzību grāmatai. Problēma ir jāatrisina, nevis jāapraksta, pievēršot uzmanību fontiem un aizmirstot par prasību aprakstīšanu. Tehniskajā specifikācijā jābūt ne tikai pašai problēmai, bet arī tās risinājumam izpratnes līmenī - tad izstrādātājs to atrisinās koda līmenī. Salīdzināt "Pārdošanas nodaļa neplāno labi, tā zaudē numurus, mēs jau gadu cīnāmies" Un “nepieciešams izveidot atskaiti, kurā tiks saglabātas plānotās un faktiskās pārdošanas vērtības mēnesī, sadalot pa preču grupām”.

   Darba uzdevumā jāspēj ieskatīties nākotnē. Nu ne gluži tā, bet cilvēki aiz tā. Ja zināms, ka drīzumā notiks izmaiņas biznesa procesos, tas ir jāņem vērā, lai par modifikācijām nebūtu jāmaksā divreiz.

   Darba uzdevumiem nevajadzētu būt birokrātiskiem. Ja kādreiz esat sastādījis šo dokumentu, droši vien jutāt, cik grūti ir izvairīties no kārdinājuma ieslīgt birokrātijā, pievienot ievadvārdus, striktas frāzes un katru punktu raksturot kā Kriminālkodeksa pantu (vēlams ar sodu ikvienam par pārkāpumu). ). Birokrātiski formulējumi maskē nepilnīgu izpratni par tehnisko specifikāciju izveides mērķiem. Pārdevēja atbildība ir noteikta līgumā, un tur ir arī rakstīts budžets. Šos punktus nevajadzētu pārnest uz tehniskajām specifikācijām.

   Darba uzdevumam jābūt tehniskajām specifikācijām. Izklausās paradoksāli, bet bieži vien tehnisko specifikāciju vietā mēs lasām vēstules, sūdzības, līgumus, jaunrakstītus CRM norādījumus vai sanāksmes protokolus. Protams, pēc šāda dokumenta strādāt nav iespējams. Lai nepārspētu formu un saturu, izmantojiet vecās skolas viltību: apskatiet vārdu pa vārdam. Tehniskais nozīmē, ka tā nosaka modifikācijas, tehnoloģiju un ir vērsta uz problēmas risināšanu, mainot programmatūru. Tas ir tas, par ko mums jārunā programmatūras kontekstā. Uzdevums nozīmē uzdot jautājumu, problēmu bez padoma, padomiem vai iepriekšējiem novērtējumiem. Tikai problēmas izklāsts.

   Baušļi beigušies, tagad pārmetums

   Papildus uzskaitītajiem noteikumiem ir vēl dažas lietas, par kurām ir vērts runāt. Mēs runājam par mērķiem, plāniem un cerībām - visiem tiem elementiem, kas padara projektu veiksmīgu, un attiecības starp pārdevēju un klientu gandrīz draudzīgas.

   Tehniskās specifikācijas jāraksta ātri, pat ja jūs saskaraties ar uzdevumu automatizēt procesus mobilo sakaru operators vai liels hipermārkets. Tas ir saistīts ar faktu, ka tehnoloģijas attīstās milzīgā ātrumā un pat jūsu ieviestā sistēma var izturēt lielu izlaidumu (vai dažreiz divus) sešos mēnešos vai gadā un iegūt jaunu funkcionalitāti. Iespējams, jums būs jāpārskata nepieciešamība veikt izmaiņas un jāsāk process no jauna.

   

   
   Beidzot viņš atrada laiku, lai pabeigtu tehnisko uzdevumu. Bet diemžēl nav neviena izstrādātāja, kas to ieviestu.

   Klients nezina par steku un tehniskajiem ierobežojumiem. Un viņam nevajadzētu zināt - tas ir pārdevēja uzdevums, viņš ir tas, kurš novērtē darbu pēc tehnisko specifikāciju sastādīšanas. Klientam nevajadzētu iedziļināties tehnoloģijā un pie katra komata jautāt, vai pārdevējs var darīt to vai citu. Sastādiet visaptverošu tehnisko specifikāciju, un izstrādātājs izvēlēsies piemērotu arhitektūru – bieži vien pat labāku, nekā jūs varētu domāt.

   Novērtējiet savu budžetu un izvairieties no nepatīkamiem pārsteigumiem- gandrīz kopīgs uzdevums numur viens. Nevajag uzspiest pārdevēju un prasīt no viņa aptuvenu darba novērtējumu (labi, vismaz aptuveni, klātienē, pēc acs, bet tāpat kā citos, nu, šāda veida projektos, bet pēc pieredzes, labi, kļūdas robeža). Pilns budžeta novērtējums ir iespējams tikai pēc darba uzdevuma izlasīšanas, analīzes un galīgās apstiprināšanas. Ja jūsu izstrādātājs rīkojas citādi, sagatavojieties tam, ka pārskatīšana maksās vismaz divas reizes vairāk.

   Pamatojoties uz objektīvu izmaiņu un paplašināšanas nepieciešamību- Iepriekš rakstīju, ka izstrādātājs nepazūd un ir gatavs jebkurā laikā veikt izmaiņas un papildinājumus atbilstoši jūsu prasībām. Tāpēc nemēģiniet uzreiz izveidot savu sapņu CRM/ERP, nepieprasiet pārdevējam pogu “Viss darbojas, kamēr es dzeru kafiju” - strādājiet sistēmā, identificējiet jums kritiskos komentārus un sāciet apkopot prasības un zīmēt. uzlabot tehniskās specifikācijas.

   Jūs varat bezgalīgi rakstīt par tehniskajiem uzdevumiem, tas ir īsts ne tikai mēmu un pasaku, bet arī galvassāpju ģenerators. Var runāt par prioritātēm un projektēšanas noteikumiem, par GOST 1989, kas padara tehniskās specifikācijas necilvēcīgas, par IEEE standartiem, kas ir nedaudz labāki, par prototipiem un tehniskajām specifikācijām, kas tos papildina. Bet galu galā es gribētu aprobežoties ar vienu, vissvarīgāko noteikumu: tehniskā specifikācija nav likuma norma, nevis GOST un nav dogma, tāpēc, ja varat to uzlabot, uzlabojiet, ja varat vienkāršot. to, vienkāršojiet, ja varat to izdarīt graciozi un tā, lai visiem tas patiktu, dariet to. Esmu pārliecināts, ka pēc tam neviens nebāzīs degunu tehniskajās specifikācijās un neteiks, ka tur nav rakstīts. Vai gandrīz neviens.

   Visu decembri mēs piedāvājam atlaides RegionSoft CRM un visai mūsu programmatūrai. No 1. decembra līdz 15. decembrim - 15% un stāvi nosacījumi nomaksai un nomai. Mums nav -70% un -90%, jo licenču cenas saglabājam ekonomiski pamatotas un neņemam no zila gaisa.

   Nu, ja jums ir nepieciešama CRM sistēma (ar vai bez izmaiņām), dodieties uz mūsu vietne, ir daudz par CRM, tā priekšrocībām un citu korporatīvo programmatūru.

   Un jā, mēs vienmēr meklējam partnerus, kuri ir gatavi pārdot CRM un citus produktus, modificēt un pārdot CRM, pārdot programmatūru un apmācīt lietotājus. Ienākumu sadale ir godīga un izdevīga partnerim. Mēs jums parādīsim, pastāstīsim, iemācīsim. Rakstīt [aizsargāts ar e-pastu]

   Slaidi, slidkalniņi. Komiksi ņemti no http://www.modernanalyst.com/ un Pinterest. Ja būs labāks tulkojums, ar prieku iekļausim to ierakstā.

Es bieži pievienoju lapu prototipus, lai klients saprastu, kā viņa vietne izskatīsies. Tad maketētājam sastādu atsevišķu uzdevumu - ar tehniskām detaļām un paskaidrojumiem, kas noderēs viņa darbā.

Jo sarežģītāks uzdevums, jo detalizētākai jābūt tehniskajai specifikācijai. Kad es piedalījos lielos projektos, es redzēju tehniskās specifikācijas, kas bija 30 lapas garas.

Guram Sipki, digitālās studijas Udix Media dibinātājs

Pirmkārt, klientam ir nepieciešamas tehniskās specifikācijas – lai viņš saprastu, kāda būs viņa mājaslapa un par ko tiks tērēta nauda. Ja kaut kas ir izdarīts nepareizi, viņš var atsaukties uz tehniskajām specifikācijām un lūgt to pārtaisīt.

Tehnisko specifikāciju sastāda projekta vadītājs pēc komunikācijas ar klientu un uzdevuma apspriešanas ar projektētāju.

Lielie klienti bieži prasa ļoti detalizētas tehniskās specifikācijas, kurās ir aprakstīta katra poga. Mazajiem uzņēmumiem, gluži pretēji, nepatīk rūpīgi izstrādāti 100 lappušu dokumenti.

Tehniska uzdevuma piemērs mājas lapas uzlabošanai

Galvenā informācija

Automatizētās sistēmas nosaukums

"AS Sbyt"

Klients

Izpildītājs

Pamats darbam

Plānotie datumi sistēmas izveides darbu sākumam un beigām

Darba sākums: 01.09.2010

Darba pabeigšana: 31.12.2010

Sistēmas izveides mērķis un mērķi

Sistēmas mērķis

Izstrādes stadijā automatizēta sistēma izstrādāts, lai automatizētu uzņēmuma pārdošanas procesus.

Sistēmas izveides mērķi

Automatizētas sistēmas izveides mērķi

"AS Sbyt" attīstības mērķi ir:

1. 3. Automatizācijas objekta raksturojums

3.1 Uzņēmuma biznesa procesi

3.1. 1 Biznesa process “Līguma slēgšana”

Tas kļūs par jūsu vairogu; šajā dokumentā, ja kaut kas notiks, jūs varēsiet rādīt ar pirkstu uz negodīgu izstrādātāju un pieprasīt, lai jūsu vietne tiktu saskaņota ar to.

Tehniskais uzdevums(īsi sakot, “TOR”) ir dokuments, kas pēc iespējas detalizētāk un nepārprotami atspoguļo prasības jūsu topošajai vietnei.

Mājas lapa ir izveidota tieši pamatojoties uz tehniskajām specifikācijām. Jo detalizētāka un nepārprotamāka tā ir, jo vairāk jūsu jaunā vietne atbildīs jūsu cerībām.

Darba uzdevums tīmekļa vietnes izveidei - kā likums, nedrīkst pieļaut interpretācijas un neatbilstības.

Izstrādātājs visu, kas nav norādīts tehniskajās specifikācijās, dara pēc saviem ieskatiem.

· Administratora rokasgrāmata;

· Satura pārvaldnieka rokasgrāmata;

· Uzstādīšanas rokasgrāmata;

· Programmētāja rokasgrāmata.

2.20. Mācību organizēšana un vadīšana Krievijas Federācijas Prokuratūras Izmeklēšanas komitejas speciālistiem

Tiek piemērotas šādas apmācības prasības:

· Izpildītājam jāvada Prokuratūras Izmeklēšanas komitejas darbinieku apmācība Krievijas Federācija kurā ir ne vairāk kā 10 cilvēki.

· Apmācībai jānotiek krievu valodā.

· Mācību telpas nodrošina Pasūtītājs.

· Apmācību vieta un laiks jāsaskaņo ar Pasūtītāju.

Apmācība jāveic par visām Sistēmas funkcionalitātēm.

Apmācības ietvaros ir nepieciešams veikt informācijas saturu vienā Krievijas Federācijas Prokuratūras Izmeklēšanas komitejas vietņu loka izmēģinājuma vietnē.

3.

Tehnisko specifikāciju paraugi vietnes uzlabošanai

Svarīgs

Ieviešanas procesā Izpildītājam ir jāsniedz palīdzība Pasūtītājam Ieviešanas grafika ietvaros.

6.1.11. Gadījumā, ja Pasūtītāja personāls ir vāji sagatavots ieviešanai un nepieciešama Izpildītāja papildu palīdzība programmatūras veiksmīgai ieviešanai, ir jāsastāda papildu protokols, lai vienotos par informācijas un konsultāciju darba līgumcenām.

6.2.AS “SALES” uzdevumu turpmākā atbalsta kārtība.

TOR ir jānorāda darba sarežģītība un izmaksas, lai ieviestu papildu prasības.

6.2.2. Izpildītājs apņemas uzturēt tālruņa uzticības līniju programmatūras atbalstam.

Mijiedarbības aspekti Pirms sākam šķetināt tehniskās specifikācijas izveides procesu, parunāsim par četrstūri, kurā atrodas darbuzņēmējs un pasūtītājs, uzsākot projektu. Prasības- vēlamā sistēmas darbība, ko aprakstījis klients vai procesa turētājs un kas jāievieš. Parasti prasības tiek veidotas, pamatojoties uz darba pieredzi un izpratni par programmas pareizu uzvedību.

Šī ir galvenā informācija izstrādātājam (pārdevējam), tomēr tieši prasību apkopošanas stadijā rodas vislielākais sadursmju, kļūdu, nevajadzīgu pieprasījumu utt. skaits.

Resursi- cilvēki, mašīnas, iekārtas, izstrādes vide, laiks un nauda, ​​kas jāizmanto prasību ieviešanas procesā. Resursiem ir nepieciešama skaidra plānošana un novērtēšana tehnisko specifikāciju apstiprināšanas posmā.

Tas var ietvert prasības dažāda veida šķirošanai, tērzēšanas integrācijai un telefonijas iespējām.

Servisa līmenis- patiesībā šī līmeņa prasībām vajadzētu būt pirmajām, kas jāiekļauj jaunbūvēs ar labojumiem. Tie ir uzdevumi, kas saistīti ar sistēmas reakcijas ātrumu, darbību ar lielu slodzi un drošību.

Uzmanību

Ideālā gadījumā pārdevējam nevajadzētu veikt šādas modifikācijas - korporatīvajai programmatūrai nevajadzētu palēnināt, zaudēt datus, sakļaut veidlapas un izplatīt tāda paša līmeņa piekļuves tiesības. Bet, ja parādās prasība un tā nav saistīta ar klienta personīgo paranoju vai problēmām aparatūras pusē, ir vērts tai pievērst pastiprinātu uzmanību.

Tehnoloģiju līmenis- pēdējā sarakstā, bet svarīguma un sarežģītības ziņā apsteidz pārējos.

Microsoft World vai Microsoft Excel.

Personīgi, izstrādājot galveno lapu, mēs izmantojam īpašus programmatūras produktus.

Ar viņu palīdzību jūs varat ātri un vienkārši izveidot projektus pat sarežģītām vietnēm - piemēram, Balsamiq. Tomēr tas, kā mēs izgatavojam visu prototipu, jau ir aprakstīts rakstā.

Par tēmu: Vietnes prototipēšana: izveide, rīki un programmas.

Pirmsprojekta projektēšanu var veikt kopīgi ar izstrādātāju vai pilnībā nodot viņa pleciem.
Galvenais, neaizmirstiet, ir panākt vienošanos un parakstīšanu abām pusēm.

DZĪVES HACKS TOR IZSTRĀDĀŠANAI

Šie punkti vienlīdz attiecas gan uz īsziņas aizpildīšanu, gan tehnisko specifikāciju sastādīšanu.

Un tajos es jums atklāšu nelielus trikus, kā noformēt mājas lapas tehniskās specifikācijas un atvieglot jau tā grūto uzņēmēja dzīvi:

1.

Pārliecinieties, vai klients un izpildītājs saprot viens otru pareizi.

Darba uzdevumā nedrīkst būt kvalitatīvi īpašības vārdi: skaists, uzticams, moderns. Tos nevar skaidri saprast. Katram ir savs skaistuma un mūsdienīguma jēdziens.

Skaties. Kāds uzskatīja, ka šis dizains ir skaists, un atļāva to izmantot savā vietnē:

Tas pats notiek ar neskaidriem formulējumiem, kas paši par sevi neko nenozīmē:

• Vietnei ir jāpatīk klientam. Ko darīt, ja viņam ir slikts garastāvoklis?
• Vietnei jābūt ērtai. Ko tas nozīmē? Ērti priekš kam?
• Vietnei jāiztur lielas slodzes. 10 tūkstoši apmeklētāju? Vai 10 miljoni?
• Augstas kvalitātes ekspertu saturs. Nu, jūs sapratāt domu.

Pārbaudiet, vai tekstā nav neskaidrību. Ja ir, pārrakstiet to.

Vai esat nolēmis pasūtīt vietni (aka galveno lapu)? Kā liecina prakse, tas nav tik vienkārši. Simtiem klientu, ieraudzījuši savu gatavo mājaslapu, atklāj, ka tā viņiem neder: nepareizs dizains, klibs izkārtojums, nepareizi teksti, pievienota kaudze nevajadzīgu funkciju.

Lai izvairītos no šādām sekām, ir nepieciešamas vietnes izstrādes tehniskās specifikācijas.

VAI MAN TO VAJAG?!

Nav svarīgi, kurš vietni vadīs - jūs pats, jūsu radinieks, ārštata darbinieki par nelielu samaksu, specializēts uzņēmums par milzīgu naudas summu...

Vietnei jābūt tehniskajām specifikācijām.

Piemēram, varat lūgt izveidot pielāgotu pārskatu RegionSoft CRM vai pasūtīt integrāciju ar vietni. Tie ir uzdevumi ar pilnīgi atšķirīgiem termiņiem, šeit ļoti svarīga ir prioritāte, pēc tam, kad prasības ir apkopotas, izanalizētas un saskaņotas ar darbiniekiem un vadību, var sākt veidot tehnisko specifikāciju.
Veidlapu varat lūgt pārdevējam vai izveidot to pats – jebkurā gadījumā ir vairāki dzelžaini noteikumi, kuru ievērošana ietaupīs jūs un jūsu CRM piegādātāja galvassāpes.

Tehniskās specifikācijas anatomija

Ja runājam par tehniskās specifikācijas izveides procesu, tad ir vairāki posmi. To secīgā pāreja noved pie klienta vēlamā uzlabojuma.
Šeit tie ir.

Šeit ir svarīgi uzklausīt pārdevēja viedokli, jo viņš precīzi zina, cik daudz laika tiks pavadīts šim vai citam uzdevumam. Tici man, attīstītājam nav izdevīgi tērēt laiku un palielināt termiņus - viņam ir izdevīgi pabeigt pēc iespējas vairāk projektu un izdarīt to labi, lai neciestu uz savu reputāciju.

Runājot par reālismu, izvairīties no pieprasījumiem uzlabot CRM līdz sadursmes pārvaldības sistēmas līmenim ir vienkārši: prasībās jāiekļauj tas, kas šobrīd un pārskatāmā nākotnē ir patiešām nepieciešams.

Piemēram, RegionSoft CRM ir darbvirsmas programma; mums nav pārlūkprogrammas klienta. Lūgt mums izveidot tīmekļa aplikāciju vienam uzņēmumam ir bezjēdzīgi, tā ir liela attīstība, šobrīd notiek un nav iespējama attīstība vienam uzņēmumam.

Informācijas sistēmas pilnie un īsie nosaukumi

Sistēmas pilns nosaukums ir Krievijas Federācijas Prokuratūras Izmeklēšanas komitejas oficiālā vietne.

Sistēmas īsais nosaukums ir "SKP vietne", "sistēma", "vietne".

1.2. Sistēmas klienta nosaukums un viņa rekvizīti

Nosaukums: Izmeklēšanas komiteja pie Krievijas Federācijas Prokuratūras

Atrašanās vieta:

Informācija

Maskava, Tehničeskij josla, 2. ēka

Faktiskā adrese: A

Klienta kontaktpersona:

Tālrunis: (4, (4;

Epasta adrese

1.3. Dokumentu saraksts, uz kuru pamata tiek veidota Sistēma

Valsts līgums Nr.________________, kas datēts ar 2010. gada _______ ___________

1.4.

Noteikts saskaņā ar Līgumu.

2. Sistēmas prasības

2.1.

maksājuma datums

Maksājuma numurs

Maksājuma numurs maksājumu sistēmā

Maksājuma summa

1. Atlasiet datu pārsūtīšanas faila rindas
2. Sāciet cilpu cauri datu pārsūtīšanas faila rindām
3. Lasīt datu pārsūtīšanas faila rindu
4. Iegūstiet līguma kodu no datu pārsūtīšanas faila rindas
5. Atrodiet atbilstošo elementu pēc koda direktorijā “Darījuma partnera līgumi”; ja elements nav atrasts, parādiet ziņojumu “Līgums ar kodu netika atrasts...”
6. Ja elements ir atrasts, pievienojiet vērtību tabulai rindiņu, kur: “Līgums” - atrastais elements, “Datums” - “Data_plat”, “Payment Number” - “Nomer_plat”, “Summa” - “Summa_plat”
7. Pēc datu pārsūtīšanas faila pēdējās rindiņas saņemšanas pabeidziet ciklu
8. Katrai vērtību tabulas rindai izveidojiet dokumentu “Maksājuma uzdevums naudas līdzekļu saņemšanai”.

Aizpildot īsu dokumentu vai sastādot mājas lapas dizaina darba uzdevumu, neatstājiet tajā nekādas nepilnības.

Jums jāsaprot, ka “Pēc izstrādātāja ieskatiem” nozīmē “es daru to, ko vēlos” vai “Viss, kas nav norādīts, tiek darīts pēc izpildītāja ieskatiem”. Un ticiet man, tā nav tikai nepilnība, bet gan vesels logs uz Eiropu izstrādātājam.

Un, protams, tas ne vienmēr notiek.

Ja jūs saskaraties ar kompetentu speciālistu, jums nav jāuztraucas par rezultātu.

Bet šeit rodas cita problēma: viņš patiesībā var to izdarīt pareizi, bet jums tas nepatiks tikai subjektīvi. Un viss būs kā daudziem izstrādātājiem zināmajā jokā:

ĪSUMĀ PAR GALVENĀM LIETĀM

Jūs noteikti nenožēlosiet laiku, kas pavadīts, izstrādājot un vienojoties par mājas lapas vai galvenās lapas izveides darba uzdevumu.

Galu galā šis ir jūsu labākais instruments, lai uzraudzītu un atrisinātu procesā radušās domstarpības.

Noklikšķinot uz konkrēta rajona, tam vajadzētu atvērt lapu ar šī rajona teksta aprakstu.

· Bloks "Priekšsēdētāja emuārs"- jābūt trīs jaunāko emuārā izveidoto tēmu sarakstam tēmas nosaukuma un publicēšanas datuma veidā. Tēmas nosaukums būs saite, uz kuras noklikšķinot, tiks novirzīts uz emuāra lapu, kurā ir aprakstīta šī tēma. Šajā blokā jābūt arī videoklipam, kuru var atskaņot, neizejot mājas lapa. Videoklipam ir jābūt saitei "Komentāri", kas atspoguļo komentāru skaitu pie dotā video attēla. Saitei “Komentāri” jānovirza uz emuāra lapu ar komentāriem par iesniegto videoklipu.

Kājenē jāiekļauj meklēšanas lodziņš, informācija par autortiesībām utt.

2.3.

Īsumā ir anketa ar jautājumiem par saturu, dizainu, tehniskās iespējas Jūsu nākotnes vietne.

Protams, darba uzdevumu var aizstāt ar detalizētu instrukciju, ko parakstījušas abas puses.

Galu galā tas ir praktiski viens un tas pats, vienīgā atšķirība ir tā, ka instruktāža ir jūsu redzējums, un tehniskā specifikācija ir gala dokuments, kas balstīts uz jūsu īso ziņojumu un pašiem izstrādātāja komentāriem.

Ja daži punkti rada grūtības, nevilcinieties uzdot izstrādātājam tādus jautājumus kā “Ko tas nozīmē?”, “Kā tas ietekmēs manas vietnes darbību?”, jo ne visi izstrādātāji saprot to pašu, ko jūs.

Vai nu slejā “ Papildus informācija“Noteikti norādiet visas savas vēlmes, kas nebija iekļautas atbildēs uz jautājumiem.

Ja šīs slejas trūkst, vienkārši pievienojiet tās īsuma beigās.

VK, Google, Facebook.

3.2.2 V personīgais konts pasūtījumu sadaļā pievienojiet lauku reklāmas koda pievienošanai.

3.2.3. Lapas vietā, ko lietotājs saņem pēc paroles atkopšanas pieprasījuma (piemēram, name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), izveidojiet lapu (piemēram, name.com/login/forgot /change_password=yes&lang =ru&USER_CHECKWORD=), kurā tiks parādīts vietnes saturs, būs lauks “E-pasts reģistrācijas laikā”, vadības līnija, jauna parole, paroles apstiprinājums un poga sūtīt datus.

3.2.4 Pievienojot preces grozam, jāparādās paziņojumam, kas norāda, ka prece ir pievienota grozam.

3.2.5 Reģistrējot jaunu lietotāju, pievienojiet ziņojuma izvadi, kas norāda, ka parole neatbilst drošības parametriem.

"_" __________________ 2010. gads

Pakāpeniski izmaiņas tika iekļautas laidienā, un vēlāk ļāva izveidot jaunu produktu vairumtirdzniecībai, mazumtirdzniecības veikaliem un hipermārketiem - RegionSoft Retail.

Lietotāja vai lietotāju grupas līmenis.Šajā līmenī tiek īstenoti uzdevumi esošās saskarnes uzlabošanai. Piemēram, lietotājs var vēlēties, lai, virzot kursoru virs klienta, tiktu parādīts logs ar pēdējā pasūtījuma numuru un statusu vai pielāgotu pārskatu ar īpašu datu grupu.

Pārstrādāšana šajā līmenī aizņem mazāk laika, taču to var būt daudz - piemēram, vairākas prasības no mārketinga, loģistikas un tehniskā atbalsta departamenta.

Funkcionalitātes līmenis. Bieži vien ir grūti to nošķirt no iepriekšējā, šeit darbojas formāls kritērijs - uzlabojumi notiek nevis interfeisa kaut kā parādīšanas līmenī, bet gan sistēmas loģikas pabeigšanas līmenī.

Ja tur ir rakstīts putra, varbūt jāskrien un neatskatīsies.

• Apdrošināties pret izpildītāja negodīgumu. Kad vietne ir gatava, to var pārbaudīt atbilstoši tehniskajām specifikācijām. Vai ir kādas neatbilstības? Izstrādātājam tās ir jālabo. Ja jūs sadarbojaties oficiāli un esat noslēdzis līgumu, jūs pat varat to piespiest caur tiesu.
• Vienkāršojiet izpildītāju nomaiņu. Ja klients un izstrādātājs strīdējās un aizbēga, vietnes izveide var aizņemt daudz laika. Kad būs detalizēta tehniskā specifikācija, to var pārcelt uz jaunu komandu – viņi darbos iesaistīsies daudzkārt ātrāk.
• Uzziniet sarežģīta produkta izstrādes izmaksas. Nav iespējams uzreiz novērtēt precīzu sarežģīta tīmekļa pakalpojuma izstrādes laiku un izmaksas. Vispirms jums ir jāsaprot, kā pakalpojums darbosies un kādas funkcijas tam būs.

Ir root piekļuve, jūsu IP adreses, porti, filtrēšanas noteikumi un maršrutēšanas tabulas.

Google PageSpeed ​​​​Insights ir bezmaksas pakalpojums ieteikumus vietnēm, lai paātrinātu lapas rādīšanu lietotāja pārlūkprogrammā (https://developers.google.com/speed/pagespeed/insights/).

Meklētājprogrammu optimizācija (jeb SEO) ir pasākumu kopums iekšējai un ārējai optimizācijai, lai palielinātu vietnes pozīciju meklētājprogrammu rezultātos pēc konkrētiem lietotāju pieprasījumiem.

Vietnes ārējā optimizācija ir vietnes reģistrācija meklētājprogrammas, veicināšana in sociālajos tīklos, saišu veidošana, piesaistot saites no citiem resursiem uz reklamēto vietni, baneru reklāma, kontekstuālā reklāma.

Vietnes iekšējā optimizācija ir teksta, URL optimizācija, vietnes struktūras rediģēšana, saišu veidošana, servera atbilžu pārbaude.

Pieejamie materiāli Saites uz jūsu iecienītākajām vietnēm, kā arī bukleti, žurnāli, fotogrāfijas - neatkarīgi no tā, vai arī jums ir gatava zīmola grāmata. Pievienots kā atsevišķs arhīvs. Minimālās izšķirtspējas un displeja ierīces Šajā rindkopā norādiet, no kurām ierīcēm plānojat skatīt vietni - personālie datori, klēpjdatori, viedtālruņi... Datoru monitori no 19 līdz 27 collām; Portatīvie datori no 15,6 līdz 17,3 collām; Viedtālruņi no 3,5 līdz 6 collām; Tabletes no 7 līdz 12 collām Vai man vajag mobilā versija? Jā FUNKCIONĀLĀS PRASĪBAS Aptuvenais moduļu komplekts (lietotājiem) Šajā sadaļā ir jāuzrāda visi funkcionalitāte, kuru vēlaties redzēt vietnē.

Tas varētu būt iepirkumu grozs, katalogu filtri pēc dažādiem parametriem, iespēja veikt pasūtījumu tiešsaistē, atstāt pieprasījumu atpakaļzvans, abonēt biļetenu un jebkuras citas iespējas Kataloga filtri pēc cenas, alfabēta, pēc ražotāja.
Cruпtcj9b: s »xvzhb╟▌╤└u╟j_ ■ e╘dj» j ■ ╛eхhjя (gtt┬pb╟▌╤└u╟╛#╜┘al+ka kqяk3┴i≈² & f╒#┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ┐█ ts╜IWA▓BOь└vOZb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:╜┘al+KaXG[ b:╜┘al+KaXG ┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜│ts&V█7┬m3aqNYJy╕°Vzhb╟▌╤└u╟╛#╜└u╟╛#╜└u╟╛#╜┘al+╟╟╜┘al+│Vzhu ╛ #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb┥al+KaXG[ b:bVzhb╤└u╟╛#╜┘al+KaXG ≈≈K&ОQТе╦▒'%[н╓≥Lк"[Ц(b╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~у╚б╖~у ╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚bD'═\┘*NлkZ┐⌡ ©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈D7i$╔≥ И∙?БjЛ?Ч╜∙╤SQ≥╒°еNFх═с╒°еNFх═с╒°еNFх═с╒°еNFх═с╒°еNFх═с┬├6≤≤⌠ьЕР≤⌠ьЕ├6ыСыB C╪ ┬ 7┴+iSo(╦°rБ╒┴■E4SCg┬╨ z╖ ┘╤m°с÷Уm╦Wыmdр'%R^&╔gt╖yхDA]zт╪L╝i▌▀s) ©E4SCg┬╨ ▌▀s OlM²K%j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡и<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Atcerieties Mērfija likumu? Ja jūs varat tikt pārprasts, jūs noteikti tiksiet pārprasts. Tas attiecas ne tikai uz komunikāciju starp cilvēkiem, bet arī veidojot tīmekļa vietnes. Klients vēlējās otru Facebook, bet ieguva forumu jaunajiem suņu audzētājiem. Attīstītājs neuzminēja, ko klients vēlas - viņš tērēja savu laiku.

Šajā rokasgrāmatā es jums pastāstīšu, kas un kāpēc jums jāieraksta darba uzdevumā. Tajā pašā laikā es jums parādīšu, kā nerakstīt, lai tehnisko specifikāciju veidošana nepārvērstos par lieku laiku.

Raksts būs noderīgs:

• Visiem, kas iesaistīti vietņu veidošanā: izstrādātājiem, dizaineriem, maketētājiem.
• Projektu vadītāji.
• Digitālo studiju vadītāji.
• Uzņēmēji, kuri plāno pasūtīt mājas lapas izstrādi.

Lai materiāls būtu noderīgs, apkopoju komentārus no vairākiem izstrādātājiem, dizaineriem, projektu vadītājiem un digitālo studiju īpašniekiem. Vērtīgākos pievienoju raksta beigās. Iesim noskaidrot.

Kas ir tehniskā specifikācija un kāpēc tā ir vajadzīga?

Tehniskā specifikācija ir dokuments, kurā noteiktas prasības vietnei. Jo skaidrākas un detalizētākas ir šīs prasības, jo labāk visi procesa dalībnieki saprot, kādam tam vajadzētu būt. Tas nozīmē, ka palielinās iespēja, ka visi būs apmierināti ar rezultātu.

Tehniskās specifikācijas galvenais mērķis ir pārliecināties, ka pasūtītājs un darbuzņēmējs saprot viens otru pareizi.

Tehniskajām specifikācijām ir daudz priekšrocību. Katrai pusei tas ir atšķirīgs.

Ieguvumi klientam:

• Saprotiet, par ko viņš maksā naudu un kāda būs vietne. Uzreiz var redzēt struktūru, saprast, kas un kā darbosies. Noskaidrojiet, vai viss jums ir piemērots. Ja nē, nav problēmu to mainīt pirms izstrādes sākuma.
• Skatiet izpildītāja kompetenci. Ja darba uzdevums ir skaidrs un precīzs, pieaug uzticība izstrādātājam. Ja tur ir rakstīts putra, varbūt jāskrien un neatskatīsies.
• Apdrošināties pret izpildītāja negodīgumu. Kad vietne ir gatava, to var pārbaudīt atbilstoši tehniskajām specifikācijām. Vai ir kādas neatbilstības? Izstrādātājam tās ir jālabo. Ja jūs sadarbojaties oficiāli un esat noslēdzis līgumu, jūs pat varat to piespiest caur tiesu.
• Vienkāršojiet izpildītāju nomaiņu. Ja klients un izstrādātājs strīdējās un aizbēga, vietnes izveide var aizņemt daudz laika. Kad būs detalizēta tehniskā specifikācija, to var pārcelt uz jaunu komandu – viņi darbos iesaistīsies daudzkārt ātrāk.
• Uzziniet sarežģīta produkta izstrādes izmaksas. Nav iespējams uzreiz novērtēt precīzu sarežģīta tīmekļa pakalpojuma izstrādes laiku un izmaksas. Vispirms jums ir jāsaprot, kā pakalpojums darbosies un kādas funkcijas tam būs. Lai to izdarītu, jums ir jāsagatavo tehniskās specifikācijas.

Ieguvumi izpildītājam:

• Saprast, ko klients vēlas. Klientam tiek uzdoti desmitiem jautājumu, parādīti piemēri un piedāvāti risinājumi. Tad viņi visu pieraksta vienā dokumentā un vienojas par to. Ja viss ok - urrā, pareizi saprati.
• Apdrošiniet sevi pret klienta pēkšņajām vēlmēm. Dažreiz jūs saskaraties ar klientiem, kuri vēlas mainīt uzdevumu pusceļā. Ja esat vienojies un parakstījis darba uzdevumu, jūs no tā nebaidāties. Ja kaut kas notiks, pat tiesa būs jūsu pusē.
• Parādiet savu kompetenci. Labi sagatavota tehniskā specifikācija parādīs klientam izstrādātāju zināšanas. Ja uzņēmums šaubījās, vai uzticēt jums mājas lapas izstrādi, šaubas, visticamāk, tiks kliedētas.
• Lai nopelnītu naudu. Dažas studijas un izstrādātāji piedāvā tehnisko specifikāciju sagatavošanu kā atsevišķu pakalpojumu.

• Veicināt un paātrināt izstrādes procesu. Laba tehniskā specifikācija norāda vietnes struktūru, nepieciešamās funkcijas un elementus katrā lapā. Kad visas prasības jau ir acu priekšā, atliek tikai izstrādāt un uzrakstīt kodu.

Tagad izdomāsim, kā izveidot labu tehnisko specifikāciju, kas pilda visas šīs funkcijas.

Darba uzdevumu sastāda izpildītājs

Parasti tehniskās specifikācijas var izstrādāt ikviens. “Mums ir vajadzīga vizītkaršu vietne zobārstniecības klīnikai” - tas jau ir tehnisks uzdevums. Bet vai tas pildīs savas funkcijas? Diez vai.

Labu tehnisko specifikāciju vienmēr sagatavo izpildītājs: projekta vadītājs vai izstrādātājs. Acīmredzot tīmekļa izstrādātājs par vietņu izveidi saprot vairāk nekā kafejnīcas vai zobārstniecības klīnikas īpašnieks. Tāpēc viņam būs jāapraksta projekts.

Tas nenozīmē, ka klients pazūd un parādās pašās beigās, lai uzrakstītu: "Zbs, es apstiprinu." Viņam arī jāpiedalās šajā procesā:

Protams, klients var ieskicēt savu tehnisko specifikāciju versiju. Iespējams, tas paātrinās galīgo tehnisko specifikāciju izveides procesu. Vai varbūt rezultāts būs atkritumi, kas tiks slepeni izmesti miskastē.

Rakstiet skaidri un precīzi

Šis padoms izriet no darba uzdevuma galvenā mērķa - "Pārliecināties, ka klients un darbuzņēmējs saprot viens otru pareizi."

Darba uzdevumā nedrīkst būt kvalitatīvi īpašības vārdi: skaists, uzticams, moderns. Tos nevar skaidri saprast. Katram ir savs skaistuma un mūsdienīguma jēdziens.

Skaties. Kāds uzskatīja, ka šis dizains ir skaists, un atļāva to izmantot savā vietnē:

Tas pats notiek ar neskaidriem formulējumiem, kas paši par sevi neko nenozīmē:

• Vietnei ir jāpatīk klientam. Ko darīt, ja viņam ir slikts garastāvoklis?
• Vietnei jābūt ērtai. Ko tas nozīmē? Ērti priekš kam?
• Vietnei jāiztur lielas slodzes. 10 tūkstoši apmeklētāju? Vai 10 miljoni?
• Augstas kvalitātes ekspertu saturs. Nu, jūs sapratāt domu.

Pārbaudiet, vai tekstā nav neskaidrību. Ja ir, pārrakstiet to. Jūsu formulējumam jābūt skaidram un precīzam:

• Vietnei ir jāielādējas ātri → Jebkurai vietnes lapai Google PageSpeed Insights ir jābūt vairāk nekā 80 punktiem.
• Smagas slodzes → 50 tūkstoši apmeklētāju vienlaicīgi.
• Galvenajā lapā tiek parādīts rakstu saraksts → Galvenajā lapā tiek parādīts pēdējo 6 publicēto rakstu saraksts.
• Minimālistisks lietotājam draudzīgs abonēšanas interfeiss → lauks “Atstāt savu e-pastu” un poga “Abonēt” → *uzzīmēta skice*.

Mēs esam sakārtojuši formulējumu, iesim pāri struktūrai.

Lūdzu, sniedziet vispārīgu informāciju

Visiem komandas dalībniekiem ir pareizi jāsaprot, ar ko uzņēmums nodarbojas un kas ir tā mērķauditorija. Lai neviens neapjuktu, labāk to pierakstīt pašā darba uzdevuma sākumā.

Ir arī vērts norādīt vietnes mērķi un īsumā aprakstīt tās funkcionalitāti, lai emuāra vietā nenonāktu tiešsaistes veikals.

Izskaidrojiet sarežģītus terminus

Darba uzdevuma pirmais noteikums ir tāds, ka tam jābūt saprotamam ikvienam, kam tas paredzēts. Ja grasāties lietot terminus, kurus jūsu klients, bērnu rotaļlietu veikala īpašnieks, iespējams, nesaprot, noteikti paskaidrojiet tos. Skaidrā valodā, nevis copy-paste no Vikipēdijas.

Aprakstiet rīkus un mitināšanas prasības

Iedomājieties, ka esat pavadījis 2 mēnešus, veidojot foršu vietni. Katrs posms tika saskaņots ar klientu – viņš bija sajūsmā. Un tagad ir pienācis laiks nodot darbu. Jūs parādāt administratora paneli, un klients kliedz: “Kas tas ir? Modeks?! Es domāju, ka jūs to darīsit, izmantojot WordPress!

Lai izvairītos no šādām problēmām, aprakstiet izmantotos rīkus, dzinējus un bibliotēkas. Tajā pašā laikā norādiet savas hostinga prasības. Jūs nekad nezināt, jūs to darīsit PHP — un klientam ir serveris .NET.

Uzskaitiet vietnes darbības prasības

Vietnei ir jādarbojas visās pašreizējās pārlūkprogrammās un visu veidu ierīcēs. Jā, tas ir skaidrs ikvienam izstrādātājam un jebkuram klientam. Bet labāk ir rakstīt, lai aizsargātu klientu no ļaunprātīga darba.

Šeit ierakstiet prasības vietnes ielādes ātrumam, slodzes izturībai, aizsardzībai pret hakeru uzbrukumiem un tamlīdzīgām lietām.

Norādiet vietnes struktūru

Pirms sākat zīmēt dizainu un izkārtojumu, ar klientu jāvienojas par vietnes struktūru.

Runājiet ar klientu un uzziniet, kas viņam nepieciešams. Apkopojiet izstrādātājus, SEO speciālistus, mārketinga speciālistus, galveno redaktoru un izlemiet, kuras lapas ir nepieciešamas vietnē. Padomājiet par to, kā tie tiks savienoti viens ar otru, no kura jūs varat pārslēgties.

Var parādīt struktūru ar sarakstu, var uzzīmēt blokshēmu. Kā vēlaties.

Šis ir viens no svarīgākajiem vietnes darba posmiem. Struktūra ir pamats. Ja tas ir neveiksmīgs, vietne izrādīsies greiza.

Paskaidrojiet, kas būs katrā lapā

Klientam ir jāsaprot, kāpēc katra lapa ir vajadzīga un kādi elementi tajā būs. Ir divi veidi, kā to parādīt.

Prototips- vizuālāks un nepārprotamāks veids. Darbuzņēmējs uzzīmē katras lapas skices un pievieno tās darba uzdevumam. Klients redz, kā izskatīsies viņa topošās mājas lapas interfeiss un pasaka, kas viņam patīk un kas jāmaina.

Elementu uzskaitījums- slinka alternatīva prototipam. Vienkārši pierakstiet, kādiem blokiem jābūt lapā un ko tie dara.

Aprakstiet vietnes izmantošanas scenārijus

Ja veidojat kādu nestandarta interfeisu, nepietiek tikai ar struktūras un lapu sīktēlu parādīšanu. Ir svarīgi, lai visa izpildes komanda un klients saprastu, kā apmeklētāji izmantos vietni. Skripti tam ir lieliski piemēroti. Scenārija diagramma ir ļoti vienkārša:

• Lietotāja darbība.
• Vietnes atbilde.
• Rezultāts.

Protams, ja veidojat standarta vizītkarti vai galveno lapu, jums nav jāraksta skripti. Bet, ja vietnē ir daži interaktīvi pakalpojumi, tas ir ļoti vēlams.

Vairāk par lietošanas gadījumiem lasiet Vikipēdijā.

Nosakiet, kurš ir atbildīgs par saturu

Daži izstrādātāji uzreiz izveido vietni ar saturu. Citi ievieto zivis. Vēl citi var rakstīt tekstus, bet par papildus samaksu. Vienojieties par to krastā un pierakstiet darba uzdevumā, kāds saturs jums jāsagatavo.

Ir diezgan grūti izdomāt objektīvus kritērijus tekstu kvalitātes novērtēšanai. Labāk nerakstīt neko citu kā vien “Kvalitatīvs, interesants un pārdodams saturs, kas noder mērķauditorijai”. Tā ir miskaste, nevienam tā nav vajadzīga.

Ir noderīgi norādīt, ka visam saturam ir jābūt unikālam. Vēl viena klienta aizsardzība no negodīgiem izpildītājiem.

Aprakstiet dizainu (ja varat)

Tāpat kā ar tekstu, ir grūti noteikt objektīvus kritērijus vietnes dizaina novērtēšanai. Ja jūs un klients esat vienojušies par krāsu shēmu, pierakstiet to. Ja viņam ir zīmola grāmata, kurā ir norādīti fonti, norādiet arī tos.

Par skaistu un modernu dizainu nav jāraksta. Tas neko nenozīmē, tam nav spēka un vispār ugh.

Secinājuma vietā: darba uzdevuma struktūra

Tehnisko specifikāciju struktūra dažādiem uzdevumiem būs atšķirīga. Ir muļķīgi izveidot vienādas tehniskās specifikācijas jaunam sociālajam tīklam un burkānu vairumtirdzniecības galvenajai lapai. Bet kopumā jums ir vajadzīgas šīs sadaļas:

• Informācija par uzņēmumu un mērķauditoriju, vietnes mērķiem un uzdevumiem.
• Terminu glosārijs, kas klientam var nebūt skaidrs.
• Tehniskās prasības vietnes plānojumam un darbībai.
• Izmantoto tehnoloģiju apraksts un hostinga prasību saraksts.
• Detalizēta vietnes struktūra.
• Lapu prototipi vai to elementu apraksti, kuriem tajās jābūt.
• Scenāriji nestandarta interfeisa izmantošanai (pēc izvēles).
• Izstrādātāja izveidotā satura saraksts.
• Dizaina prasības (pēc izvēles).

• Programmatūras prasību specifikācijas sastādīšanas noteikumi. VID ir nākamais solis tehnisko specifikāciju evolūcijā. Nepieciešams lieliem un sarežģītiem projektiem.
• Programmatūras izstrādes tehnisko specifikāciju standarti un veidnes. Dažādu GOST apraksti un tehnisko specifikāciju veidošanas metodikas.

Šīs ir manis rakstītās daļas beigas. Bet ir vēl viens - komentāri no speciālistiem, kuri palīdzēja sagatavot ceļvedi. Izlasi, arī interesanti.

Izstrādātāju komentāri

Es runāju ar vairākiem izstrādātājiem, lai noskaidrotu, kā viņi veido tehniskās specifikācijas. Es nododu viņiem mikrofonu.

Pirmkārt, klientam ir nepieciešamas tehniskās specifikācijas – lai viņš saprastu, kāda būs viņa mājaslapa un par ko tiks tērēta nauda. Ja kaut kas ir izdarīts nepareizi, viņš var atsaukties uz tehniskajām specifikācijām un lūgt to pārtaisīt.

Tehnisko specifikāciju sastāda projekta vadītājs pēc komunikācijas ar klientu un uzdevuma apspriešanas ar projektētāju.

Lielie klienti bieži prasa ļoti detalizētas tehniskās specifikācijas, kurās ir aprakstīta katra poga. Mazajiem uzņēmumiem, gluži pretēji, nepatīk rūpīgi izstrādāti 100 lappušu dokumenti. Tas ir garš, un ir viegli palaist garām kaut ko svarīgu. Biežāk veidojam kodolīgas tehniskās specifikācijas 10–15 lappušu garumā.

Mēs norādām:

• Informācija par uzņēmumu un vietnes mērķi.
• Prasības dizainam, krāsu shēmai.
• Izmantotās tehnoloģijas un CMS.
• Kas veido saturu – mēs vai klients.
• Vietnes struktūra līdz katrai lapai.
• Katras lapas apraksti. Mēs neveidojam prototipus, bet mēs norādām, kādiem elementiem jābūt lapā un kā tiem jādarbojas.

Pēdējās 2 sadaļas ir vissvarīgākās. Viņi ir tie, kas sniedz izpratni par to, kāda būs vietne un kā tā darbosies.

Ļoti svarīgs punkts - jūs nevarat vienkārši dot izstrādātājiem darba uzdevumu un cerēt, ka viņi visu izdarīs labi. Tehniskā specifikācija ir vietnei izvirzīto prasību saraksts, tā nevar aizstāt komunikāciju. Ir svarīgi pārliecināties, ka katrs komandas dalībnieks saprot kopējo mērķi un neveic tikai uzdevumus lidojumā. Ja kaut kas ir neskaidrs, ir nepieciešams paskaidrot, apspriest un sniegt detalizētus komentārus.

Dzīvē nereti gadās, ka cilvēks pat ikdienas lietās nevar izskaidrot, ko vēlas. Kad programmētājam jāskaidro savas “vēlas”, cilvēks vienkārši iekrīt stuporā.

Ideālā gadījumā tehniskās specifikācijas būtu jāsastāda pasūtītājam – tikai viņš zina, kas viņam vajadzīgs. Taču praksē, ņemot vērā klienta zemo kompetenci 1C jomā, tas bieži ir jādara darbuzņēmējam. Klients mutiski izsaka savas vajadzības, un programmētājs (konsultants) to noformē rakstiski.

Kāpēc jums ir nepieciešamas tehniskās specifikācijas?

Ideālā gadījumā jebkuram būtu jāpievieno tehniskās specifikācijas. Tā, pirmkārt, ir skaidra uzdevuma, termiņu un īstenošanas metodes definīcija. Otrkārt, šis ir dokuments, ar kura palīdzību tiek atrisināti visi strīdīgie jautājumi nākotnē. Rakstīt tehniskās specifikācijas vai nē, protams, ir jūsu darīšana, man personīgi tehniskās specifikācijas atvieglo darbu un komunikāciju ar klientu.

Saņemiet 267 video nodarbības 1C bez maksas:

Kas jāiekļauj darba uzdevumā?

Tie. uzdevumā jāiekļauj:

• mērķis— problēma, kuru atrisināsim, ieviešot šo specifikāciju;
• apraksts— gaidāmo uzlabojumu kopsavilkums;
• īstenošanas metode— detalizēts mērķa risināšanas metožu apraksts. Šajā brīdī ir jāapraksta visas uzdevuma nianses programmētāja valodā: kādus uzdevumus veidojam/rediģējam, kādam vajadzētu izskatīties saskarnei utt. Ja jūs nerunājat "programmētāju valodā", bet "kaut ko esat dzirdējis", labāk nemēģiniet rakstīt tehniskajā valodā - tas izrādās diezgan jautri. Aprakstam jābūt nepārprotamam un neradot jautājumus. Tajā var būt arī piemērs līdzīga risinājuma ieviešanai citā jomā;
• darbības novērtējums- ļoti svarīgs punkts, darbaspēka izmaksu apraksts.

Ir arī valsts standarti tehnisko specifikāciju rakstīšanai - GOST. Praksē tos izmanto reti, bet dažreiz klients uz to uzstāj.

No pieredzes, nododot darbu, ļoti bieži rodas situācijas, piemēram, “mēs toreiz teicām...”, kas nav īpaši patīkami, un bieži vien nākas pārtaisīt visu darbu. Tāpēc labi uzrakstīta tehniskā specifikācija ievērojami atvieglo abu pušu dzīvi.

1C tehnisko specifikāciju piemēri un paraugi

Neliela izlase, kuru atradu brīvi pieejamu internetā. Sākot no vienkāršākajiem un pieejamākajiem līdz diezgan sarežģītiem dokumentiem.