Kutatóintézeti szellőztetés korszerűsítésének feladatköre. A kutatóintézetek szellőztetésének korszerűsítésére vonatkozó feladatmeghatározás A szerver tárolási véglegesítésének feltételei

Miért van szükség specifikációra?

Példa a TOR-ra egy programozó számára

Ha „termékkövetelmény-dokumentum” kéréssel megy végig a külföldi oldalakon, kreatív és meggyőző cikkeket találhat arról, hogy a technikai feladat (TOR, PRD) elhalt. Ezzel részben egyet kell értenünk - amikor egy terméket a semmiből fejlesztünk ki, a prototípusok készítése sokkal érdekesebbnek és hatékonyabbnak tűnik, mint a rengeteg ügyfélnyilvántartás, amely néha nagyon nem professzionális. Ha azonban az alaprendszer véglegesítéséről beszélünk, akkor teljesen más fordulatot vesznek a dolgok. Revízióval és egyedi fejlesztéssel is állunk szemben, így a TK-ban megették a kutyát, ha a szakács nem hazudik nekünk. Általánosságban elmondható, hogy ma - azokról a nagyon klasszikus műszaki előírásokról, amelyeket a megvásárolt és telepített véglegesítéshez írnak szoftver. Röviden a sebről.

Az interakció oldalai

Erőforrások- a követelmények megvalósítása során felhasználandó emberek, gépek, készlet, fejlesztői környezet, idő és pénz. Az erőforrások világos tervezést és értékelést igényelnek a feladatmeghatározás jóváhagyásának szakaszában. A vevő kompetens priorizálása és a szállítói munkaerő-elosztás lehetővé teszi a határidők elmulasztását és az egyéb kockázatok minimalizálását.

Lehetőségek- röviden ennyit tud igazán megtenni egy eladó (előadó). Tekintsük a RegionSoft CRM-ünket példaként. Az ügyfél megvásárolja a rendszert és elkészíti a felülvizsgálathoz szükséges technikai feladatot: létre kell hozni az integrációt az oldallal, és az eseményeket a CRM-ben összekapcsolni az online áruház rendelési számával. Ez reális követelmény, megvan hozzá az erőforrás és a képesség. Ezenkívül ki kell fejlesztenie és kapcsolódnia kell a CRM CMS-hez, egy webhelytartalom-kezelő rendszerhez. Elméletileg ezt megtehetjük, de nincs lehetőségünk olcsón megcsinálni, és az ügyfélnek sincs annyi fizetése, hogy humán- és időerőforrást tudjunk áthelyezni a feladatra. Ennek eredményeként az ügyfél megtagadja ezt a követelményt - és nincs is igazán szüksége CMS-re, minden rendben van. De a TK "kapzsiságáról" - később.

Korlátozások- akadályok halmaza, amelyek megnehezítik vagy lehetetlenné teszik a feladatok TOR-ból történő végrehajtását: költségvetés, technológiai halom, licencelési problémák, jogi tilalmak, hardverkonfigurációk stb.

Így mind a négy entitás szorosan összefonódik, és meghatározza a projekt egészének sikerét. Vegyük fontolóra az egyes elemeket, és próbáljuk meg kiemelni azokat a kritikus pontokat, amelyeket szem előtt kell tartani, amikor a feladatmeghatározáson dolgozunk.

Követelmények összegyűjtése, elemzése

Senki sem ismeri jobban a cégedet, mint te és az alkalmazottaid. Ez azt jelenti, hogy a követelmények összegyűjtése és elemzése kizárólag az Ön feladata, amelyben a szállító tud segíteni, irányítani, de semmi esetre sem zavarja a folyamatot. Kérdezze meg a fejlesztőt az ilyen megvalósításokról, adja meg, mit kell keresnie, és folytassa. Egyébként a profiltémában jól járatos, a szoftverarchitektúrát nagyjából reprezentáló, a fejlesztési folyamatot járatos munkatársa jó asszisztens lehet - tud elemzőként és belső szakértőként működni, lezárni a műszaki specifikációk elkészítésének folyamatát. és kommunikáció az eladóval.

Vannak nagyon egyszerű áramkör gyűjtési követelmények.

1. Hozzon létre egy munkacsoportot vezetőkből és a részlegek tapasztalt szakembereiből, akik CRM-et fognak használni. Mondja el nekünk a választandó megoldást, biztosítson hozzáférést a demo verzióhoz.
2. A munkacsoport tagjainak tájékoztatást kell adniuk az alkalmazottaknak, és kérniük kell tőlük a kívánságokat új program teljesen szabad formában. Ha az egyik alkalmazott soha nem találkozott ilyen szoftverrel, és nem hajlandó beszélni a jövőbeni felhasználásról, meg kell kérnie őt, hogy írja le az időszakos feladatait, ez egy univerzális megközelítés.
3. Ezután minden részleg meghatározza, hogy a CRM mi nem vagy nem egyezik, és összesíti az információkat.
4. A munkacsoport elemzi az összegyűjtött követelményeket, ellenőrzi és megszünteti a kereszteződéseket. Nem ritka például az sem, hogy egy értékesítési osztály és egy marketing osztály ugyanazt a jelentést rendeli meg, de előfordulhat, hogy a mezők és entitások elnevezése eltérő a követelményekben, bár a mögöttük lévő adatok ugyanazok. Ennek megfelelően egyetlen formára kell jutni.
5. A munkacsoport követelménylistát készít és prioritásokat határoz meg. Ebben a szakaszban csatlakoztathatja a szállítót, mivel ő felelős az erőforrásokért. Például kérhet egyéni jelentést a RegionSoft CRM-hez, vagy megrendelheti a webhely integrációját. Ezek időben teljesen eltérő feladatok, itt nagyon fontos a prioritás.

A feladatmeghatározás anatómiája

• Azonosítás - követelmények meghatározása, megoldásra váró problémák keresése.
• Elemzés - követelmények elemzése, kulcsszükségletek azonosítása, általánosítás.
• Adaptáció - a követelmények felmérése a CRM-képességekkel és a meglévő üzleti folyamatokkal összefüggésben.
• Dokumentáció - formális és Részletes leírás követelmények, műszaki leírások jóváhagyása.
• Kommunikáció a szállítóval (fejlesztővel) – iteratív interakció a szállítóval az összeállított TOR-nak megfelelő fejlesztésekkel kapcsolatban.
• Megvalósítás - az eladó munkája a szükséges funkcionalitás megteremtése érdekében. Jobb, ha az eladó folyamatosan kapcsolatban áll a vevővel – így a kimeneti termék leginkább az ügyfél elképzeléséhez fog illeszkedni.
• Tesztelés - a szállító alkalmazottai, az ügyfél belső szakértői és a végfelhasználók működőképességének ellenőrzése a revíziós és műszaki követelményeknek való megfelelés, a rendszer teljesítményének változása érdekében.

Üzleti szinten- a legglobálisabb szint, amelyen összetett és kiemelt feladatokat oldanak meg. Ez a szint magában foglalja az üzleti folyamatok integrációját, finomítását és modellezését, új funkcionális modulok fejlesztését. Általában ez egy erőforrás-igényes fejlesztés, komoly konzultációkkal és szorosan közös munka az ügyféllel. Például egy időben a RegionSoft CRM-ben a raktári könyvelés, a pénztárgép és a gyártás ilyen egyedi módosítások voltak. A változások fokozatosan megjelentek a kiadásban, és később lehetővé tették egy új termék létrehozását a nagykereskedelmi, kiskereskedelmi üzletek és hipermarketek számára - a RegionSoft Retail.

Felhasználó vagy felhasználói csoport szintje. Ezen a szinten olyan feladatokat hajtanak végre, amelyek a meglévő felület finomítását célozzák. Előfordulhat például, hogy a felhasználó egy ablakot szeretne megjeleníteni az utolsó rendelés számával és állapotával, amikor egy vevő fölé viszi az egérmutatót, vagy egy egyedi jelentést szeretne az adatok speciális csoportosításával. Ezen a szinten a fejlesztések kevesebb időt vesznek igénybe, de sok lehet - például a marketing, a logisztika és a műszaki támogatás részlegének több követelménye.

funkcionalitási szint. Sokszor nehéz elválasztani az előzőtől, itt egy formai kritérium működik - a finomítás nem a felületen való megjelenítés szintjén van, hanem a rendszerlogika finomításának szintjén. Ide tartoznak a különféle rendezési, csevegési integrációs és telefonos lehetőségek követelményei.

Szolgáltatási szint- tulajdonképpen ennek a szintnek a követelményei kellene elsőként bekerülni a javításokkal ellátott új buildekbe. Ezek a feladatok a rendszer válaszideje, a nagy terhelés melletti munka és a biztonság szempontjából. BAN BEN ideál a szállítónak nem szabad ilyen fejlesztésekkel rendelkeznie - a vállalati szoftver nem lassíthat, nem veszíthet el adatokat, nem csukhatja össze az űrlapokat és nem oszthat ki azonos szintű hozzáférési jogokat. De ha olyan követelmény jelentkezett, amely nem kapcsolódik az ügyfél személyes paranoiájához vagy oldalproblémákhoz hardver nagyobb figyelmet kellene fordítani rá.

Technológiai szint- az utolsó a listán, de fontosságban és összetettségben megelőzi a többieket. Ezek lehetnek a platformmal kapcsolatos ügyfélkövetelmények, operációs rendszer vagy eszközöket. Például egy összeállítási kérés a MacOS számára. Nagyon jó, ha az ilyen követelmények fokozatosan kiadásokká fejlődnek, de ezek javítása szükséges. Ezen a szinten a kliensek kérése alapján állítottuk össze a RegionSoft CRM-et MacOS-hoz, és egy ritka, de létező mobil verzió iránti kéréshez ideiglenes megoldásként adtuk hozzá a TRM technológiát használó távoli hozzáférést.

A feladatmeghatározás anatómiája egyszerű, legalábbis csontváz formájában. A feladatmeghatározás kötelező részei segítik a megrendelőt abban, hogy a problémára koncentráljon és helyesen fogalmazza meg a feladatot, az előadó pedig megértse, mit akar tőle. Egyébként a megértésről. Persze a bejegyzés elején kicsit ravaszkodtunk, osztályként megtagadtuk az üzleti tanácsadókat. A lényeg a következő: mindegyik gyártó több éve működik a piacon (most nem egynapos CRM-ekről beszélünk), sőt évtizedek óta, vagyis szinte minden iparágban van egy sor esete. Ennek megfelelően mind a mérnökök, mind a programozók, mind az értékesítők ismerik az egyes cégtípusok megvalósításának sajátosságait. De ismét fontos, hogy a vállalkozására összpontosítson.

Kinek? Ebben a részben le kell írni, hogy ki lesz a revízió végfelhasználója, milyen feladatokat és milyen gyakran tervezik megoldani.

Mondok egy példát. Az egyik cég bevezette a CRM-et, és meglehetősen nagy adattömbön kellett volna dolgoznia (több tízmillió rekord havonta, több százezer rekord naponta). Ezen nyilvántartások feltöltéséről az értékesítési osztály vezetője „napi gyakorisággal” kért jelentést. Természetesen egy ilyen jelentés, miközben több száz felhasználó dolgozott egyszerre, feltöltötte a rendszert - megoldások születtek a folyamat optimalizálására. Már a munka során kiderült, hogy az eladó eljátszotta, és csak a hónap végén volt szüksége a jelentésre, majd az éjszakai ütemterv szerint indulhat. Mondanom sem kell, idő és pénz elvesztegetett.

Miért? A fejlesztés szükségességének indoklása és helye az üzleti folyamatban. Erre az elemre inkább magának a vevőnek van szüksége, de a szállítónak is hasznos tudnia, milyen egyéb folyamatokat érint. Néha segíthet alternatív megoldást találni.

Mit kell tenni? A leginkább informatív blokk - leírja a követelményeket, elvárásokat a rendszertől. És itt megtörténnek azok a gyöngyszemek, csodák és ütközések, amelyeket a bashorgnak küldeni illik, és amelyek nagyon megnehezítik az életet. Csak egy oka van - a felhasználó nem tudja, mit akar, mit kell tennie. Van még egy kis mellék-ok - a felhasználó nem tud követelményeket megfogalmazni. És itt a fejlesztő (munkacsoport, elemző, ha van) feladata, hogy segítsen helyesen megfogalmazni az igényt, kiválasztani a megfelelő követelményt, és a feladatot a rendszer kontextusába illeszteni. Ugyanebben a blokkban meg kell említeni a várt eredményt.

A referencia paraméterek feltételei- határidők, megvalósítás szakaszai, minden fél felelőse, szükséges elérhetőségek stb. Valójában ez olyan fontos formai dolgok összessége, amelyek a dokumentumot technikai feladattá teszik. A feladatmeghatározást a feleknek meg kell állapodniuk és alá kell írniuk, hogy elkerüljék a sok változást a fejlesztés során (ma is lesznek, de kisebb mennyiségben).

Ideális esetben a megbízás az eladó aktív közreműködésével készül, és ennek eredménye hozzávetőlegesen a következő struktúra:

1. Az egyes mechanizmusok és funkciók követelményeinek leírása
2. E funkció megvalósításának leírása
3. A munka költsége az egyes szakaszokra külön-külön
4. Ezen a műszaki feladaton végzett munka teljes költsége
5. A munkavégzés határideje szakaszonkénti bontásban és a fontossági sorrend megjelölésével
6. A telepítési és vizsgálati feltételek leírása
7. Fenntartások a feladatmeghatározás és egyéb feltételek kimerítő jellegével kapcsolatban

10 szabály írva a Fejlesztői könnyekben

A technikai feladat nem lehet mohó. Egy vállalkozás gyakran túlbecsüli képességeit, vagy „mindent egyszerre” akar beszerezni. Ez a megközelítés sem pénz, sem üzleti szempontból nem indokolt. Egy eladó általában néhány hétig nem létezik (a RegionSoft esetében - 15 év), és egy idő után felveheti vele a kapcsolatot, amikor valóban megérti, mi hiányzik a CRM-ből.

A redundancia szemléletes példája szó szerint tegnapról: egy ügyfél vett egy ERP-t egy jól ismert cégtől orosz cég, arra gondolva, hogy mivel a könyvelés működik, akkor ennek a szállítónak az ERP-je jó lesz. Kiderült, hogy az ERP önmagában nem túl jó, de üzleti célra nagyon alkalmatlan. De a RegionSoft CRM-mel raktári könyvelésés a termelés megfelelő. Van megoldás: felejtse el az ERP-t, sírjon, integrálja az 1C könyvelést az új CRM-mel, és élvezze a kényelmes megvalósítást. De kár a duzzadt pénzért! Az ügyfél pedig megköveteli, hogy integrálja a CRM-et az ERP-vel. Nem ezt tettük, de miért ekkora pazarlás, miért két viszonylag hasonló rendszer?

A feladatmeghatározásnak reálisnak és megvalósíthatónak kell lennie- mind a követelmények, mind a határidők tekintetében. Itt fontos meghallgatni az eladó véleményét, hiszen ő pontosan tudja, hogy egy adott feladat mennyi időt vesz igénybe. Higgye el, egy fejlesztőnek nem kifizetődő az időre való játék és a határidő lehúzása - előnyös, ha minél több projektet teljesít, és ezt jól csinálja, hogy ne csorbuljon a hírnevén. Ami a realizmust illeti, könnyű elkerülni a CRM-nek az ütközővezérlő rendszer szintjére történő befejezésére irányuló kéréseket: a követelményekbe bele kell foglalni azt, amire valóban szükség van. Ebben a pillanatbanés belátható jövőben.

Például a RegionSoft CRM egy asztali program, böngészőkliensünk nincs. Értelmetlen arra kérni minket, hogy készítsünk webalkalmazást egy cég számára, ez egy jelentős fejlesztés, jelenleg folyamatban van, és egy cégnél nem lehetséges finomítás. Nem, természetesen mindennek megvan az ára, de ismét - általános esetben ez a követelmény lehetetlen.

Nem szabad összetéveszteni a helyzettel, amikor egyedi fejlesztésről van szó, és az alkalmazás elgondolása, logikája gyökeresen megváltozik, sőt, egy új szoftver „magának” létrehozását szponzorálják. De ez egy másik történet.

A specifikációt részletezni kell. Fel kell tüntetni a jövőbeni projekt minden lényeges részletét: a program használatának gyakoriságától a felülettel kapcsolatos kívánságokig. Minél részletesebbek a követelmények, annál könnyebb és gyorsabb lesz a megvalósítás és a tesztelés. Különösen érdemes a részletekre odafigyelni, ha egy adott iparágban (gyógyászat, biztosítás, bankok) dolgozik - a vállalkozás és a program közötti interakció árnyalatainak részletes bemutatása biztosítja, hogy az eladó megértse a feladatot és gyorsan alkalmazkodjon a rendszert a cégének.

Ügyeljen a számformátumokra, a mezőnevekre, a legördülő listák meglétére vagy hiányára, a gombok és tippek viselkedésére, valamint az adattípusokra. Ha az ügyfél saját képleteket használ, amelyeket bele kell foglalni a CRM logikába ( például a kereskedői bónuszok kiszámítása), ezeket a képleteket jelölésük és számítási logikájuk teljes magyarázatával együtt kell megírni.

A feladatmeghatározásnak egyértelműnek és pontosnak kell lennie. Homályos megfogalmazás, megvalósítási lehetőségek, homályos követelmények – mindez egy zsákutcába vezető út. Előfordul, hogy egy ügyfél jó szándékból a TOR-ba több lehetőséget is beír a rendszer viselkedésére, amelyek közel állnak, de nem egyenértékűek. Ebben az esetben biztos abban, hogy segít, felszólítja a programozót, de valójában a pokolba vezető út is jó szándékkal van kikövezve; a fejlesztőnek meg kell értenie, hogy pontosan mire van szükség, és hogyan kell csinálni, ő maga választja ki a rendszer jellemzőiről és az alkalmazott technológiák halmazáról.

A feladatkört emberi nyelven kell megírni.És ez fontos, nem, FONTOS. Két olyan helyzetet emelek ki, amikor a nyelvi problémák a projekt megvalósításának késleltetéséhez vezetnek.

1. Az ügyfél igyekszik bemutatni műszaki jártasságát és a kerítéskonstrukciókat, mint például: „valósítson meg egy ablakot utalással a naptár törzsébe, amely képes reagálni egy eseményhívásra…” ahelyett, hogy „ablaknak fel kell bukkannia a naptár, amelyben a feladatot befejezettként jelölheti meg”. Ha Ön vagy belső szakértője nem rendelkezik szakszövegírási képességekkel, ne guglizzon – írjon hétköznapi szavakkal, mi megértjük őket.

   A feladatmeghatározás nem lehet panaszkönyv. Meg kell oldani a problémát, nem leírni, odafigyelve a betűtípusokra és megfeledkezve a követelmények leírásáról. A TOR-nak nem csak magát a problémát kell tartalmaznia, hanem annak megoldását is megértés szintjén - akkor a fejlesztő már kódszinten megoldja. Hasonlítsa össze "az értékesítési részleg rosszul tervez, számokat veszít, egy éve harcolunk"És „Szükséges egy olyan jelentés elkészítése, amely a terv értékeit és az értékesítés tényét havonta, termékcsoportok összefüggésében menti el”.

   A feladatmeghatározásnak képesnek kell lennie a jövőre tekinteni. Nos, nem pontosan az, hanem a mögötte álló emberek. Ha ismert, hogy az üzleti folyamatokban hamarosan változások következnek be, akkor ezt figyelembe kell venni, hogy ne kelljen kétszer fizetni a felülvizsgálatért.

   A feladatmeghatározás nem lehet bürokratikus. Ha valaha is elkészítette ezt a dokumentumot, biztosan érezte, milyen nehéz elkerülni a kísértést, hogy belecsússzon a bürokráciába, hogy bevezető szavakat, szigorú fordulatokat írjon be, és minden egyes tételt a Btk. cikkelyeként írjon le (lehetőleg mindenkit büntetéssel, megsértése). A bürokratikus megfogalmazás elfedi a TK létrehozásának céljainak hiányos megértését. Az eladó felelőssége a szerződésben le van írva, oda van írva a költségvetés is. Ezeket a pontokat nem szabad átvinni a technikai feladatra.

   A feladatmeghatározásnak a feladatmeghatározásnak kell lennie. Paradoxon hangzik, de gyakran a műszaki előírások helyett leveleket, panaszokat, szerződéseket, újonnan írt utasításokat a CRM-hez vagy ülés jegyzőkönyveit olvasunk. Természetesen lehetetlen ilyen dokumentumon dolgozni. Annak érdekében, hogy ne térjen el a formától és a tartalomtól, használja a régi iskola trükkjét: nézze meg a kifejezést szóról szóra. A technikai azt jelenti, hogy finomítást, technikát diktál, a probléma megoldására irányul a szoftver megváltoztatásával. Ez a feladat a szoftverrel kapcsolatban, és beszélnie kell. A feladat egy kérdés, probléma felvetése tanácsok, tippek és előzetes becslések nélkül. Csak egy kijelentés a problémáról.

   A parancsolatoknak vége, most a feddésnek

   A fenti szabályokon kívül van még néhány dolog, amiről érdemes beszélni. Célokról, tervekről és elvárásokról beszélünk - mindazokról a távozókról, amelyek sikeressé teszik a projektet, és szinte baráti a kapcsolat a szállító és az ügyfél között.

   Gyorsan meg kell írni a feladatkört, még akkor is, ha a folyamatok automatizálásának feladatával áll szemben mobilszolgáltató vagy nagy szupermarketben. Ez annak a ténynek köszönhető, hogy a technológiák óriási sebességgel fejlődnek, és még az Ön által megvalósított rendszer is túlélhet egy nagyobb kiadást (és néha kettőt is) hat hónap vagy egy év alatt, és új funkciókat kaphat. Lehetséges, hogy át kell gondolni a fejlesztések szükségességét, és újra kell kezdeni a folyamatot.

   

   
   Végül talált időt a TK befejezésére. De sajnos nem maradtak fejlesztők a megvalósításban.

   Az ügyfél nincs tisztában a verem és a technikai korlátokkal.És nem szabad tudnia - ez az eladó feladata, ő értékeli a munkát a feladatmeghatározás elkészítése után. Az ügyfélnek nem szabad belemerülnie a technológiába, és minden vesszőt megkérdeznie, hogy az eladó meg tudja-e csinálni ezt vagy azt a dolgot. Készítsen átfogó TOR-t, és a fejlesztő kiválasztja a megfelelő architektúrát – gyakran még jobban, mint gondolná.

   Becsülje meg költségvetését, és kerülje el a kellemetlen meglepetéseket- szinte az első számú közös feladat. Nem szabad meghúzni az eladót, és megkövetelni tőle a munka hozzávetőleges értékelését (jó, legalább megközelítőleg, közvetlenül, szemmel, de mint mások, nos, az ilyen típusú projekteknél, de tapasztalatból, jól, jól, belül hibahatár). Teljes költségvetési becslés csak a feladatmeghatározás elolvasása, elemzése és végleges jóváhagyása után lehetséges. Ha a fejlesztője mást tesz, készüljön fel arra, hogy a felülvizsgálat legalább kétszer annyiba kerül.

   A változtatások és bővítések objektív igényéből induljon ki- Fentebb írtam, hogy a fejlesztő nem tűnik el, és bármikor készen áll az Ön igényeinek megfelelő változtatásokra, kiegészítésekre. Ezért ne próbáljon meg azonnal CRM / ERP álmokat létrehozni, ne követelje meg az eladótól a „Minden működik, miközben kávézom” gombot - dolgozzon a rendszerben, azonosítsa a kritikus megjegyzéseket, és kezdje el a követelmények összegyűjtését és a műszaki specifikációk elkészítését. .

   Technikai feladatokról vég nélkül lehet írni, ez nem csak mémek és mesék igazi generátora, hanem fejfájás is. Lehet beszélni a prioritásokról és a tervezési szabályokról, a GOST 1989-ről, ami embertelenné teszi a TK-t, az IEEE szabványokról, amelyek kicsit jobbak, a prototípusokról és az ezeket kiegészítő TK-ról. De végül egy, a legfontosabb szabályra szorítkoznék: a feladatmeghatározás nem jogállamiság, nem GOST és nem dogma, ezért ha javítani tud - javítani, egyszerűsíteni - leegyszerűsítve meg tudod csinálni kecsesen és úgy, hogy mindenkinek tetsszen – csináld. Biztos vagyok benne, hogy ezek után senki nem fogja beütni az orrát a TK-ba és azt mondani, hogy ez nincs odaírva. Vagy szinte senki.

   Egész decemberben kedvezményt adunk a RegionSoft CRM-re és minden saját fejlesztésű szoftverre. December 1-től december 15-ig - 15% és hűvös részletfizetési és bérleti feltételek. Nálunk nincs -70% és -90%, mert a jogosítványokért gazdaságilag indokolt árat tartunk, és nem a plafonról szedjük.

   Nos, ha CRM-rendszerre van szüksége (módosítással vagy anélkül), akkor lépjen a következő oldalra a honlapunk, sok minden van a CRM-ről, annak előnyeiről és egyéb vállalati szoftverekről.

   És igen, mindig olyan partnereket keresünk, akik készek CRM és egyéb termékek értékesítésére, CRM fejlesztésére és értékesítésére, szoftverek értékesítésére és felhasználók képzésére. A jövedelem megosztása igazságos és előnyös a partner számára. Mutasd, mondd, taníts. Írj neki [e-mail védett]

   Csúszdák, csúszdák. A képregények a http://www.modernanalyst.com/ oldalról és a Pinterestről származnak. Ha lesz jobb fordítás, szívesen beletesszük a posztba.

Gyakran csatolok oldalprototípusokat, hogy az ügyfél megértse, hogyan fog kinézni az oldala. Ezután a tördelőnek külön feladatot írok össze - technikai részletekkel és magyarázatokkal, amelyek segítik a munkáját.

Minél összetettebb a feladat, annál részletesebbnek kell lennie a TOR-nak. Amikor nagy projektekben vettem részt, láttam a feladatmeghatározást és 30 oldalt.

Guram Sipki, az Udix Media digitális stúdió alapítója

Először is, az ügyfélnek szüksége van TK-ra - hogy megértse, milyen lesz az oldala, és mire költik a pénzt. Ha valamit rosszul csinálnak, fordulhat a TK-hoz, és kérheti, hogy csinálják újra.

A TOR-t a projektmenedzser állítja össze, miután kommunikált a megrendelővel és megbeszélte a feladatot a tervezővel.

A nagy ügyfelek gyakran nagyon részletes specifikációkat kérnek, amelyek leírják az egyes gombokat. A kis cégek éppen ellenkezőleg, nem szeretik az aprólékos 100 oldalas dokumentumokat.

Példa egy webhely véglegesítésének technikai feladatára

Általános információ

Az automatizált rendszer neve

"AS SALES"

Vevő

Végrehajtó

A munka alapja

A rendszer létrehozásával kapcsolatos munka megkezdésének és befejezésének tervezett időpontja

A munkálatok kezdete: 2010.09.01

A munkák befejezése: 2010.12.31

A rendszer létrehozásának célja és céljai

A rendszer célja

Fejlett automatizált rendszer egy vállalat értékesítési folyamatainak automatizálására tervezték.

A rendszeralkotás céljai

Az automatizált rendszer létrehozásának céljai

Az AS SBYT fejlesztésének céljai a következők:

1. 3. Az automatizálási objektum jellemzői

3.1 A vállalkozás üzleti folyamatai

3.1. 1 Üzleti folyamat "Szerződés megkötése"

Ez lesz az Ön pajzsa, ebben a dokumentumban Ön, ebben az esetben ujjal mutogathat egy gátlástalan fejlesztőre, és követelheti, hogy az oldalát hozzák összhangba.

Műszaki feladat(röviden „TOR”) egy olyan dokumentum, amely a legrészletesebben és legegyértelműbben tükrözi az Ön jövőbeli webhelyére vonatkozó követelményeket.

Az oldal a TK alapján készült. Minél részletesebb és egyértelműbb, az új webhely annál jobban megfelel az elvárásoknak.

Az oldal létrehozására vonatkozó feladatmeghatározás - mint jogszabály - nem engedhet meg értelmezéseket és eltéréseket.

Mindent, ami nincs kiírva a TOR-ban, a fejlesztő saját belátása szerint végez.

· Adminisztrátori útmutató;

· Tartalomkezelő útmutató;

· Telepítési útmutató;

· Programozói útmutató.

2.20. Az Orosz Föderáció Ügyészsége alá tartozó Vizsgáló Bizottság szakemberei számára képzés szervezése és lebonyolítása

A következő képzési követelmények érvényesek:

A végrehajtónak képzést kell tartania az Ügyészség alá tartozó Vizsgáló Bizottság alkalmazottai számára Orosz Föderáció legfeljebb 10 főből áll.

· A képzést orosz nyelven kell lefolytatni.

· Az oktatáshoz szükséges helyiséget a Megrendelő biztosítja.

· A képzés helyét és idejét a Megrendelővel egyeztetni kell.

A képzést a rendszer minden funkciójáról el kell végezni.

A képzés részeként el kell végezni az Orosz Föderáció Ügyészsége alá tartozó Vizsgálóbizottság Ring of Sites egy kísérleti oldalának információtartalmát.

3.

Minta weboldal fejlesztési feladatmeghatározás

Fontos

A kivitelezés során a Vállalkozó a Megvalósítási ütemterv keretében segítséget nyújt a Megrendelőnek.

6.1.11. Abban az esetben, ha a Megrendelő személyzete nem megfelelően felkészült a megvalósításra, és a Vállalkozó további segítségre van szüksége a szoftver sikeres megvalósításához, kiegészítő jegyzőkönyvet kell készíteni a tájékoztatási és tanácsadói munkák szerződéses árának egyeztetésére.

6.2.Az AS "SALES" feladatainak további támogatására vonatkozó eljárás.

A TOR-nak fel kell tüntetnie a munka intenzitását és a munka költségét a további követelmények végrehajtásához.

6.2.2. Vállalkozó vállalja, hogy a szoftver karbantartásához telefonos "forró vonalat" tart fenn.

Az interakció szempontjai Mielőtt rátérnénk a műszaki feladat létrehozásának folyamatának előkészítésére, beszéljünk arról a négyszögről, amelybe a kivitelező és a megrendelő kerül a projekt indításakor. Követelmények- a rendszer kívánt viselkedése, ahogyan azt a megrendelő vagy a folyamatgazdálkodó leírta, és azt megvalósítani. A követelményeket általában a tapasztalatok, a program helyes viselkedésének bemutatása alapján alakítják ki.

Ez kulcsfontosságú információ a fejlesztő (szállító) számára, azonban a követelmények begyűjtésének szakaszában fordul elő a legtöbb ütközés, hiba, redundáns kérés stb.

Erőforrások- a követelmények megvalósítása során felhasználandó emberek, gépek, készlet, fejlesztői környezet, idő és pénz. Az erőforrások világos tervezést és értékelést igényelnek a feladatmeghatározás jóváhagyásának szakaszában.

Ide tartoznak a különféle rendezési, csevegési integrációs és telefonos lehetőségek követelményei.

Szolgáltatási szint- tulajdonképpen ennek a szintnek a követelményei kellene elsőként bekerülni a javításokkal ellátott új buildekbe. Ezek a feladatok a rendszer válaszideje, a nagy terhelés melletti munka és a biztonság szempontjából.

Figyelem

Ideális esetben a szállítónak nem kellene ilyen fejlesztéseket végrehajtania – a vállalati szoftverek nem lassíthatnak, nem veszíthetnek el adatokat, nem csukhatják össze az űrlapokat és nem oszthatnak ki azonos szintű hozzáférési jogokat. De ha megjelent egy igény, és nem a vevő személyes paranoiájához, vagy hardveroldali problémákhoz kapcsolódik, arra érdemes külön odafigyelni.

Technológiai szint- az utolsó a listán, de fontosságban és összetettségben megelőzi a többieket.

Microsoft World vagy Microsoft Excel.

Személy szerint a céloldal fejlesztése során speciális szoftvertermékeket használunk.

Segítségükkel gyorsan és egyszerűen készíthet akár összetett webhelyeket is – ez például a Balsamiq. A teljes prototípus elkészítésének módját azonban már leírtuk a cikkben.

A témában: Oldal prototípus készítése: készítés, eszközök és programok.

A projekt előtti tervezés történhet a fejlesztővel közösen, vagy teljesen a vállára tolva.
A legfontosabb, hogy ne felejtsd el, majd állapodj meg benne és írd alá mindkét fél.

LIFE HACKS A TOR FEJLESZTÉSÉHEZ

Ezek a pontok egyformán vonatkoznak mind a tájékoztató kitöltésére, mind a feladatmeghatározás megfogalmazására.

Ezekben pedig elárulok néhány trükköt, hogyan készítsünk műszaki specifikációt az oldalhoz, és könnyítsük meg a vállalkozó amúgy is nehéz életét:

1.

Győződjön meg arról, hogy a kliens és az előadó helyesen érti-e egymást.

A feladatmeghatározás ne tartalmazzon minőségi jelzőket: szép, megbízható, modern. Nem lehet őket egyértelműen megérteni. Mindenkinek megvan a maga koncepciója a szépségről és a modernitásról.

Néz. Végül is valaki azt gondolta, hogy ez a dizájn gyönyörű, és megengedte, hogy felhasználják a webhelyén:

Ugyanez – elmosódott megfogalmazással, ami önmagában nem jelent semmit:

• Az oldalt kedvelnie kell az ügyfélnek. Mi van, ha rossz kedve van?
• Az oldalnak felhasználóbarátnak kell lennie. Mit jelent? Mire kényelmes?
• A helyszínnek nagy terhelésnek kell ellenállnia. 10 ezer látogató? Vagy 10 millió?
• Minőségi szakértő tartalom. Nos, érted az ötletet.

Ellenőrizze, hogy a szövegben nem található-e kétértelműség. Ha van - írd át.

Úgy döntött, hogy weboldalt (más néven landing oldalt) rendel? Ahogy a gyakorlat mutatja, ez nem olyan egyszerű. Több száz ügyfél, látva elkészült oldalát, rájön, hogy nem illik hozzájuk: nem ugyanaz a dizájn, sántít az elrendezés, hiányoznak a szövegek, egy rakás felesleges funkciót csavartak el.

Az ilyen következmények elkerülése érdekében az oldal fejlesztéséhez technikai feladatra van szükség.

VAN SZÜKSÉGEM RÁ?!

Nem számít, ki lesz a webhely végrehajtója - te magad, rokonod, szabadúszók szerény fizetésért, egy speciális cég hatalmas pénzért ...

Az oldal feladatmeghatározása legyen.

Például kérhet egyéni jelentést a RegionSoft CRM-hez, vagy megrendelheti a webhely integrációját. Időben teljesen eltérő feladatokról van szó, itt nagyon fontos a prioritás, a követelmények összegyűjtése, elemzése, valamint a munkatársakkal és a vezetőséggel való egyeztetése után megkezdődhet a technikai feladat elkészítése.
Kérheti az űrlapot az eladótól, vagy létrehozhatja saját maga – mindenesetre van néhány szigorú szabály, amely megkíméli Önt és CRM-szolgáltatóját is a fejfájástól.

A feladatmeghatározás anatómiája

Ha egy technikai feladat létrehozásának folyamatáról beszélünk, akkor több szakaszból áll. Következetes átjárásuk elvezeti az ügyfelet a kívánt javuláshoz.
Itt vannak.

Itt fontos meghallgatni az eladó véleményét, hiszen ő pontosan tudja, hogy egy adott feladat mennyi időt vesz igénybe. Higgye el, egy fejlesztőnek nem kifizetődő az időre való játék és a határidő lehúzása - előnyös, ha minél több projektet teljesít, és ezt jól csinálja, hogy ne csorbuljon a hírnevén.

Ami a realizmust illeti, a CRM ütközővezérlő rendszer szintjére történő befejezésére irányuló kérések elkerülése egyszerű: a követelményekbe bele kell foglalni azt, amire jelenleg és a belátható jövőben valóban szükség van.

Például a RegionSoft CRM egy asztali program, böngészőkliensünk nincs. Értelmetlen arra kérni minket, hogy készítsünk webalkalmazást egy cég számára, ez egy jelentős fejlesztés, jelenleg folyamatban van, és egy cégnél nem lehetséges finomítás.

Az információs rendszer teljes és rövid neve

A rendszer teljes neve az Orosz Föderáció Ügyészsége alá tartozó Vizsgáló Bizottság hivatalos honlapja.

A rendszer rövid neve "Site SKP", "System", "Site".

1.2. A rendszer ügyfelének neve és adatai

Név: Az Orosz Föderáció Ügyészsége alá tartozó Vizsgálati Bizottság

Helyszín: Mr.

Info

Moszkva, Műszaki sáv, 2. épület

Valós cím: A

Az Ügyfél kapcsolattartója:

Telefon: (4, (4;

Email cím

1.3. Azon dokumentumok listája, amelyek alapján a Rendszer létrejön

2010. ___________________________________________________________________________________________________ számú állami szerződés

1.4.

Megállapodás szerint határozzák meg.

2. Rendszerkövetelmények

2.1.

fizetés nap

Fizetési szám

Fizetési szám a fizetési rendszerben

A fizetés összege

1. Válassza az Adatátviteli fájlsorok lehetőséget
2. Kezdje el az adatátviteli fájl sorain keresztüli hurkolást
3. Olvassa el az adatátviteli fájl sorát
4. Szerezze le a szerződés kódját az adatátviteli fájl sorából
5. Keresse meg a megfelelő elemet kódonként a "Szerződéses felek megállapodásai" könyvtárban, ha az elem nem található, akkor jelenítse meg a "A kóddal kötött megállapodás nem található ..." üzenetet.
6. Ha az elem megtalálható, akkor adjon hozzá egy sort az értéktáblázathoz, ahol: "Szerződés" - a talált elem, "Dátum" - "Data_plat", "Fizetési szám" - "Nomer_plat", "Amount" - "Summa_plat"
7. Miután megkapta az adatátviteli fájl utolsó sorát, fejezze be a hurkot
8. Az értéktáblázat minden sorához hozzon létre egy „Fizetési megbízás átvétele” dokumentumot.

A tájékoztató kitöltésekor vagy az oldal kialakítására vonatkozó specifikáció összeállításakor ne hagyjon benne szóközt.

Meg kell értenie, hogy „a fejlesztő belátása szerint” azt jelenti, hogy „amit akarok, azt visszafordítom” vagy „Minden, ami nincs megadva, az előadó belátása szerint történik”. És hidd el, ez nem csak egy kiskapu, hanem egy egész ablak Európába a fejlesztő számára.

És persze ez nem mindig van így.

Ha hozzáértő szakembert kapott, akkor nem aggódhat az eredmény miatt.

De itt egy másik probléma merül fel, tényleg meg tudja csinálni jól, de pusztán szubjektíven nem fog tetszeni. És minden olyan lesz, mint egy sok fejlesztő által ismert viccben:

RÖVIDEN A FŐRŐL

Biztosan nem fogja megbánni a weboldal vagy a landing oldal összeállítására és a feladatmeghatározásra fordított időt.

Végül is ez a legjobb eszköze a folyamat során felmerülő nézeteltérések ellenőrzésére és megoldására.

Ha egy adott kerületre kattint, annak egy olyan oldalra kell jutnia, amelyen a kerület szöveges leírása található.

· "Elnök blogjának" blokkolása- a blogon az utolsó három témakör listája legyen a téma neve és a megjelenés dátuma formájában. A téma címe egy link lesz, rákattintva a blog oldalára kell vinnie, ahol a téma leírása található. Ezenkívül ennek a blokknak tartalmaznia kell egy videót, amelyet kilépés nélkül le lehet játszani kezdőlap. A videónak tartalmaznia kell egy „Megjegyzések” linket, amely a videóhoz fűzött megjegyzések száma. A "Megjegyzések" linknek a beküldött videóhoz fűzött megjegyzéseket tartalmazó blogoldalra kell vezetnie.

A láblécnek tartalmaznia kell egy keresőmezőt, szerzői jogi információkat stb.

2.3.

rövid egy kérdőív a tartalomra, a kialakításra, technikai lehetőségeket leendő webhelyét.

Természetesen mindkét fél által aláírt részletes tájékoztató helyettesítheti a feladatmeghatározást.

Hiszen ez gyakorlatilag ugyanaz, csak annyi a különbség, hogy a tájékoztató a te elképzelésed, a feladatmeghatározás pedig a záródokumentum, amely az Ön tájékoztatóján és magukon a fejlesztői megjegyzéseken alapul.

Ha bizonyos pontok nehézségeket okoznak, ne habozzon feltenni a fejlesztőnek olyan kérdéseket, mint „Mit jelent ez?”, „Hogyan érinti ez a webhelyemet?”, mivel nem minden fejlesztő érti ugyanazt, mint te.

Akár az oszlopban további információ"Minden olyan kívánságát feltétlenül jelezze, amely nem szerepelt a kérdésekre adott válaszokban.

Ha ez az oszlop hiányzik, egyszerűen adja hozzá őket a tájékoztató végéhez.

VK, Google, Facebook.

3.2.2 B személyes fiók a rendelések részben adjon hozzá egy mezőt a promóciós kód hozzáadásához.

3.2.3 A jelszó-helyreállítási kérés után a felhasználóhoz érkező oldal helyett (a name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD= űrlapon) készítsen egy oldalt (az űrlap nevével). com/login/forgot/change_password=yes&lang =ru&USER_CHECKWORD=), amely megjeleníti az oldal tartalmát, tartalmazza az "E-mail regisztráció során" mezőt, egy vezérlőkarakterláncot, egy új jelszót, egy jelszó megerősítést, egy adatküldő gombot. .

3.2.4 Tételek kosárba tételekor egy üzenetet kell megjeleníteni arról, hogy az árut a kosárba helyezték.

3.2.5 Új felhasználó regisztrálásakor adjon hozzá egy üzenetet, amely szerint a jelszó nem egyezik a biztonsági beállításokkal.

» _» __________________ 2010

Fokozatosan a változtatások bekerültek a kiadásba, és később lehetővé tették egy új termék létrehozását nagykereskedelmi, kiskereskedelmi üzletek és hipermarketek számára - RegionSoft Retail.

Felhasználó vagy felhasználói csoport szintje. Ezen a szinten olyan feladatokat hajtanak végre, amelyek a meglévő felület finomítását célozzák. Előfordulhat például, hogy a felhasználó egy ablakot szeretne megjeleníteni az utolsó rendelés számával és állapotával, amikor egy vevő fölé viszi az egérmutatót, vagy egy egyedi jelentést szeretne az adatok speciális csoportosításával.

Ezen a szinten a fejlesztések kevesebb időt vesznek igénybe, de sok lehet - például a marketing, a logisztika és a műszaki támogatás részlegének több követelménye.

funkcionalitási szint. Sokszor nehéz elválasztani az előzőtől, itt egy formai kritérium működik - a finomítás nem a felületen való megjelenítés szintjén van, hanem a rendszerlogika finomításának szintjén.

Ha oda van írva zabkása, akkor érdemes lehet futni és nem visszanézni.

• Biztosítani kell az előadó becstelensége ellen. Ha az oldal elkészült, a feladatmeghatározás szerint ellenőrizhető. Vannak következetlenségek? A fejlesztőnek ki kell javítania őket. Ha hivatalosan együttműködik és megállapodást köt, akár bírósági úton is kényszeríthetik.
• Az előadók cseréjének egyszerűsítése. Ha az ügyfél és a fejlesztő veszekedett és elmenekült, az oldal létrehozása sokáig eltarthat. Ha megvan a részletes feladatmeghatározás, átvihető egy új csapathoz - sokszor gyorsabban fog bekapcsolódni a munkába.
• Ismerje meg egy összetett termék fejlesztésének költségeit. Lehetetlen azonnal megbecsülni egy komplex webszolgáltatás fejlesztésének pontos időzítését és költségeit. Először meg kell értenie, hogyan fog működni a szolgáltatás, és milyen funkciói lesznek.

Vannak root hozzáférések, privát IP-címek, portok, szűrési szabályok és útválasztási táblák.

A Google PageSpeed ​​​​Insights az ingyenes szolgáltatás ajánlások a webhelyeknek, hogy felgyorsítsák az oldal megjelenítését a felhasználó böngészőjében (https://developers.google.com/speed/pagespeed/insights/).

A keresőoptimalizálás (vagy SEO) olyan belső és külső optimalizálási intézkedések összessége, amelyek célja a webhely pozíciójának emelése a keresőmotorok eredményei között bizonyos felhasználói kérések esetén.

A külső webhely optimalizálás a webhely regisztrációja kereső motorok, spin-up in a közösségi hálózatokon, linképítés más forrásokból származó linkek bevonásával a reklámozott oldalra, szalaghirdetés, kontextuális hirdetés.

A belső webhely optimalizálás a szövegek, URL-ek optimalizálása, az oldal szerkezetének szerkesztése, újrahivatkozás, szerver válaszok ellenőrzése.

Rendelkezésre álló anyagok Linkek az Ön által kedvelt oldalakra, valamint füzetek, magazinok, fényképek – bármi, vagy esetleg van egy kész márkakönyve. Külön archívumban csatolva. Minimális felbontás és megjelenítő eszközök Ebben a bekezdésben adja meg azokat az eszközöket, amelyekről meg kívánja tekinteni a webhelyet - PC-k, laptopok, okostelefonok ... PC-monitorok 19-27 hüvelyk között; 15,6-17,3 hüvelykes notebookok; Okostelefonok 3,5 és 6 hüvelyk között; 7-12 hüvelykes tabletták mobil verzió? Igen FUNKCIONÁLIS KÖVETELMÉNYEK A modulok hozzávetőleges készlete (felhasználók számára) Ebben a szakaszban fel kell sorolni az összes funkcionalitás amit látni szeretne az oldalon.

Ez lehet bevásárlókosár, katalógusszűrők különféle paraméterekhez, online rendelés lebonyolítása, kérés hagyása visszahívás, feliratkozás a hírlevélre és minden egyéb lehetőség Katalógusszűrők ár szerint, betűrendben, gyártó szerint.
CRUпtCj9B:s»XVzhb╟▌╤└u╟J_■E╘Dj»J■╛EXHJya(gTT┬Pb╟▌╤└u╟╛#╜┘al╟╛#╜┘al╟▌╤└u╟┙┙┐┐┐i ╜IWA▓BOЬ└vOЗb╟▌╤└u╟╛#╜┘al+КaXG[ b:ьVzhb╟▌╤└u╟╛#╤└u╟╛#╜┘al+Пь┖#╤└u╟╛#╜┘al+КaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+Кь┖# #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┥al+KaXG[ b:bVzhb╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┥al+KaXG ≈≈K&ОQТё╦▒'%[n╓≥Lk"[Ts(b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~y╚b╚b╖~y╚b╚ ╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚bD'═\┘*NlkZ ⌡ . . ©OlM²K%j ┼╖`СsА≈K▐f²Yh▐Hd╟Fg╬lн∙╥е#⌡i<Т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▓З╨?.

Emlékszel Murphy törvényére? Ha félreérthető, akkor biztosan félreérthető lesz. Ez nemcsak az emberek közötti kommunikációra igaz, hanem az oldalak létrehozására is. Az ügyfél szeretett volna egy második Facebookot, de kapott egy fórumot fiatal kutyatenyésztőknek. A fejlesztő nem találta ki az ügyfél kívánságlistáját – vesztegette az idejét.

Ebben az útmutatóban elmondom, mit és miért kell beírnia a feladatkörbe. Ugyanakkor megmutatom, hogyan ne írj úgy, hogy a műszaki specifikáció elkészítése ne legyen elvesztegetett idő.

A cikk hasznos lesz:

• Mindenki, aki kapcsolatban áll az oldalak létrehozásával: fejlesztők, tervezők, elrendezéstervezők.
• Projektmenedzserek.
• Digitális stúdiók vezetői.
• Vállalkozók, akik az oldal fejlesztését tervezik megrendelni.

Az anyag működőképessé tétele érdekében több fejlesztőtől, tervezőtől, projektmenedzsertől és digitális stúdiótulajdonostól gyűjtöttem össze a hozzászólásokat. A legértékesebbeket a cikk végére adjuk. Menjünk kitalálni.

Mi az a specifikáció és miért van rá szükség

A feladatmeghatározás egy dokumentum, amelyben rögzítik a webhely követelményeit. Minél világosabbak és részletesebbek ezek a követelmények, a folyamat minden résztvevője annál jobban megérti, hogyan kell ennek lennie. Ez azt jelenti, hogy egyre nagyobb az esélye annak, hogy mindenki elégedett lesz az eredménnyel.

A feladatmeghatározás fő célja, hogy a megrendelő és az előadó helyesen megértse egymást.

A műszaki előírásoknak számos előnye van. Mindegyik oldalnak megvan a maga.

Előny az ügyfél számára:

• Értsd meg, miért fizet pénzt, és milyen lesz az oldal. Azonnal láthatja a szerkezetet, megértheti, mi fog működni és hogyan. Gondolja át, hogy minden megfelel-e Önnek. Ha nem - nem probléma a fejlesztés megkezdése előtt változtatni.
• Lásd az előadó kompetenciáját. Ha a feladatmeghatározás érthető és világos, nő a fejlesztőbe vetett bizalom. Ha oda van írva zabkása, akkor érdemes lehet futni és nem visszanézni.
• Biztosítani kell az előadó becstelensége ellen. Ha az oldal elkészült, a feladatmeghatározás szerint ellenőrizhető. Vannak következetlenségek? A fejlesztőnek ki kell javítania őket. Ha hivatalosan együttműködik és megállapodást köt, akár bírósági úton is kényszeríthetik.
• Az előadók cseréjének egyszerűsítése. Ha az ügyfél és a fejlesztő veszekedett és elmenekült, az oldal létrehozása sokáig eltarthat. Ha megvan a részletes feladatmeghatározás, átvihető egy új csapathoz - sokszor gyorsabban fog bekapcsolódni a munkába.
• Ismerje meg egy összetett termék fejlesztésének költségeit. Lehetetlen azonnal megbecsülni egy komplex webszolgáltatás fejlesztésének pontos időzítését és költségeit. Először meg kell értenie, hogyan fog működni a szolgáltatás, és milyen funkciói lesznek. Ehhez műszaki feladatot kell készíteni.

Előnyök az előadó számára:

• Értsd meg, mit akar az ügyfél. Több tucat kérdést tesznek fel az ügyfélnek, példákat mutatnak be, megoldásokat kínálnak. Ezután mindent egyetlen dokumentumba írnak le és egyeztetnek. Ha minden rendben van - üdv, jól értetted.
• Biztosítani az ügyfél hirtelen kívánságlistája ellen. Néha vannak olyan ügyfelek, akik félúton szeretnének változtatni a feladaton. Ha beleegyezett és aláírta a TOR-t, nem fél ettől. Ebben az esetben még a bíróság is az Ön oldalán áll.
• Mutasd meg kompetenciádat. Egy jól elkészített feladatmeghatározás megmutatja az ügyfélnek a fejlesztők szakértelmét. Ha a cég kételkedett abban, hogy rád bízza-e az oldal fejlesztését, a kételyek valószínűleg eloszlanak.
• Pénzt keresni. Egyes stúdiók és fejlesztők külön szolgáltatásként kínálják a műszaki specifikációk elkészítését.

• A fejlesztési folyamat megkönnyítése és felgyorsítása. A jó TOR minden oldalon jelzi az oldal szerkezetét, a szükséges funkciókat és elemeket. Amikor már minden követelmény a szeme előtt van, már csak a kód megtervezése és megírása van hátra.

Most kitaláljuk, hogyan írjunk egy jó TOR-t, amely végrehajtja ezeket a funkciókat.

A feladatkört az előadó határozza meg

Technikai feladatot általában bárki végezhet. „Szükségünk van egy névjegykártya weboldalra egy fogászati ​​klinikához” – ez már technikai feladat. De vajon megteszi-e a dolgát? Alig.

A jó TOR-t mindig egy előadó készíti: egy projektmenedzser vagy egy fejlesztő. Nyilvánvaló, hogy egy webfejlesztő többet ért a webhelyek létrehozásához, mint egy kávézó vagy egy fogászati ​​klinika tulajdonosa. Ezért le kell írnia a projektet.

Ez nem azt jelenti, hogy az ügyfél eltűnik, és a legvégén megjelenik, és azt írja: "Zbs, jóváhagyom." Neki is részt kell vennie a folyamatban:

Természetesen az ügyfél felvázolhatja a TK saját verzióját. Talán ez felgyorsítja a végleges feladatmeghatározás elkészítésének folyamatát. És talán kiderül, hogy szemét, amelyet csendben dobnak a szemétbe.

Írj világosan és pontosan

Ez a tanács a feladatmeghatározás fő céljából következik - "Győződjön meg arról, hogy a megrendelő és a vállalkozó helyesen megértette egymást."

A feladatmeghatározás ne tartalmazzon minőségi jelzőket: szép, megbízható, modern. Nem lehet őket egyértelműen megérteni. Mindenkinek megvan a maga koncepciója a szépségről és a modernitásról.

Néz. Végül is valaki azt gondolta, hogy ez a dizájn gyönyörű, és megengedte, hogy felhasználják a webhelyén:

Ugyanez – elmosódott megfogalmazással, ami önmagában nem jelent semmit:

• Az oldalt kedvelnie kell az ügyfélnek. Mi van, ha rossz kedve van?
• Az oldalnak felhasználóbarátnak kell lennie. Mit jelent? Mire kényelmes?
• A helyszínnek nagy terhelésnek kell ellenállnia. 10 ezer látogató? Vagy 10 millió?
• Minőségi szakértő tartalom. Nos, érted az ötletet.

Ellenőrizze, hogy a szövegben nem található-e kétértelműség. Ha van - írd át. A megfogalmazásnak világosnak és pontosnak kell lennie:

• A webhelynek gyorsan be kell töltenie → A webhely bármely oldalának több mint 80 ponttal kell rendelkeznie a Google PageSpeed ​​​​Insights szolgáltatásban.
• Nagy terhelés → 50 ezer látogató egyszerre.
• A főoldalon a cikkek listája látható → A főoldalon megjelenik a legutóbbi 6 publikált cikk listája.
• Minimalista, felhasználóbarát előfizetési felület → Hagyjon meg egy e-mail mezőt és a Feliratkozás gombot → *rajzolt vázlat*.

Kitaláltuk a megfogalmazást, menjünk át a szerkezeten.

Adja meg az általános információkat

A csapat minden tagjának pontosan meg kell értenie, mit csinál a vállalat, és ki a célközönsége. Hogy senki ne keveredjen össze, jobb, ha a feladatmeghatározás legelején előírja.

Illetve érdemes megjelölni az oldal célját és dióhéjban leírni a funkcionalitását – nehogy egy webáruházat kapjunk blog helyett.

Magyarázza el a nehéz kifejezéseket

A feladatmeghatározás első szabálya, hogy mindenki számára világos legyen, hogy kinek szánják. Ha olyan kifejezéseket fog használni, amelyeket ügyfele – egy gyermekjátékbolt tulajdonosa – esetleg nem ért, feltétlenül magyarázza el őket. Egyszerű nyelven, nem copy-paste a Wikipédiából.

Ismertesse az eszközöket és a hosting követelményeket

Képzeld el, hogy 2 hónapja csinálsz egy menő weboldalt. Minden szakaszt egyeztettünk az ügyféllel – örül. És most itt az ideje átadni a munkát. Megmutatod az adminisztrációs panelt, és az ügyfél felkiált: „Mi ez? Modex?! Azt hittem, hogy ezt a WordPress-en csinálod!”

Az ilyen problémák elkerülése érdekében írja le a használt eszközöket, motorokat és könyvtárakat. Ugyanakkor adja meg a hosting követelményeit. Soha nem tudhatod, PHP-ben fogod megtenni – és a kliensnek van szervere .NET-ben.

Sorolja fel a webhely követelményeit

A webhelynek működnie kell minden jelenlegi verziójú böngészőben és minden típusú eszközön. Igen, ez minden fejlesztő és vásárló számára nyilvánvaló. De jobb írni, hogy megvédje az ügyfelet a tisztességtelenül végzett munkától.

Írja ide a webhely betöltési sebességére, a terhelés ellenállására, a hacker támadásokkal szembeni védelemre és hasonló dolgokra vonatkozó követelményeket.

Adja meg a webhely szerkezetét

A terv és az elrendezés megrajzolása előtt meg kell állapodnia az ügyféllel a webhely felépítéséről.

Csevegés az ügyféllel, megtudja, mire van szüksége. Gyűjtsön össze fejlesztőket, keresőoptimalizálókat, marketingeseket, főszerkesztőket – és döntse el, mely oldalakra van szüksége az oldalon. Gondolja át, hogyan kapcsolódnak majd egymáshoz, ahonnan átválthat.

Megmutathatja a szerkezetet listaként, rajzolhat blokkdiagramot. Ahogy szeretnéd.

Ez a munka egyik legfontosabb szakasza az oldalon. A struktúra az alap. Ha nem sikerül, a webhely görbe lesz.

Magyarázza el, mi lesz az egyes oldalakon

Az ügyfélnek meg kell értenie, miért van szükség az egyes oldalakra, és milyen elemek lesznek rajta. Ezt kétféleképpen lehet megmutatni.

Prototípus- vizuálisabb és egyértelműbb módon. A vállalkozó minden oldalról vázlatot készít, és csatolja a feladatmeghatározáshoz. A kliens látja, hogyan fog kinézni leendő oldalának felülete, és elmondja, hogy mi tetszik neki és min kellene változtatni.

Elemek felsorolása a prototípus lusta alternatívája. Csak írja meg, hogy milyen blokkok legyenek az oldalon, és mit csinálnak.

Írja le a webhely használatának forgatókönyveit

Ha valamilyen nem szabványos felületet készítesz, akkor nem elég a szerkezet és az oldal miniatűrök megjelenítése. Fontos, hogy a teljes implementációs csapat és az ügyfél megértse, hogyan fogják használni a látogatók az oldalt. A forgatókönyvek erre kiválóak. A forgatókönyv vázlata nagyon egyszerű:

• Felhasználói művelet.
• Weboldal válasz.
• Eredmény.

Természetesen, ha szabványos névjegykártyát vagy nyitóoldalt készít, akkor nem kell szkripteket írnia. De ha van néhány interaktív szolgáltatás az oldalon, az nagyon kívánatos.

Olvasson többet a használati esetekről a Wikipédián.

Határozza meg, ki a felelős a tartalomért

Egyes fejlesztők azonnal létrehoznak egy webhelyet tartalommal. Mások rakják a halat. Megint mások írhatnak szöveget, de felár ellenében. Ezt a parton egyezzetek meg, és rögzítsétek a feladatkörben, hogy milyen tartalmat kell elkészíteni.

Elég nehéz objektív kritériumokat felállítani a szövegek minőségének értékelésére. Inkább ne írj mást, mint "jó minőségű, érdekes és eladható, a célközönség számára hasznos tartalom". Ez egy szemét, senkinek nem kell.

Hasznos annak meghatározása, hogy minden tartalomnak egyedinek kell lennie. Az ügyfél újabb védelme a gátlástalan előadókkal szemben.

Írja le a dizájnt (ha lehet)

A szöveghez hasonlóan nehéz objektív kritériumokat találni a webhely kialakításának értékeléséhez. Ha Ön és az ügyfél megegyezett a színsémában, írja le. Ha van márkakönyve, amelyben betűtípusok vannak regisztrálva, akkor azokat is jelezze.

Nem szükséges szép és modern dizájnról írni. Nem jelent semmit, nincs ereje, és általában fu.

Konklúzió helyett: a feladatmeghatározás szerkezete

A különböző feladatoknál a TOR felépítése eltérő lesz. Hülyeség ugyanazokat a műszaki előírásokat megadni egy új közösségi hálózathoz és a nagykereskedelmi sárgarépa nyitóoldalához. De általában ilyen szakaszokra van szükség:

• Információk a cégről és a célközönségről, az oldal céljairól és célkitűzéseiről.
• Olyan kifejezések szószedete, amelyeket az ügyfél esetleg nem ért.
• A telephely elrendezésének és üzemeltetésének műszaki követelményei.
• Az alkalmazott technológiák leírása és a hosting követelmények listája.
• Részletes webhelyszerkezet.
• Az oldalak prototípusai vagy azokon az elemek leírása.
• Forgatókönyvek nem szabványos interfész használatához (opcionális).
• A fejlesztő által készített tartalom listája.
• Tervezési követelmények (opcionális).

• A Szoftverkövetelmény-specifikáció összeállításának szabályai. Az SRS a feladatmeghatározás fejlődésének következő lépése. Nagy és összetett projektekhez szükséges.
• A TOR szabványai és sablonjai a szoftverfejlesztéshez. Különböző GOST-ok leírása és a műszaki előírások létrehozásának módszerei.

Itt a vége annak a résznek, amit írtam. De van egy másik is - a szakértők megjegyzései, akik segítettek az útmutató elkészítésében. Olvasd el, az is érdekes.

Fejlesztői megjegyzések

Beszéltem több fejlesztővel, hogy megtudjam, hogyan írnak specifikációkat. Átadom nekik a mikrofont.

Először is, az ügyfélnek szüksége van TK-ra - hogy megértse, milyen lesz az oldala, és mire költik a pénzt. Ha valamit rosszul csinálnak, fordulhat a TK-hoz, és kérheti, hogy csinálják újra.

A TOR-t a projektmenedzser állítja össze, miután kommunikált a megrendelővel és megbeszélte a feladatot a tervezővel.

A nagy ügyfelek gyakran nagyon részletes specifikációkat kérnek, amelyek leírják az egyes gombokat. A kis cégek éppen ellenkezőleg, nem szeretik az aprólékos 100 oldalas dokumentumokat. Hosszú olvasmány, és könnyű kihagyni valami fontosat. Gyakrabban 10-15 oldalra készítünk tömör műszaki leírást.

Jelezzük:

• Információk a cégről és az oldal céljáról.
• Tervezési követelmények, színek.
• Használt technológiák és CMS.
• Ki foglalkozik a tartalommal – mi vagy az ügyfél.
• A webhely szerkezete az egyes oldalakig.
• Az egyes oldalak leírása. Nem prototípusokat készítünk, hanem megadjuk, hogy milyen elemek legyenek az oldalon és hogyan működjenek.

Az utolsó 2 rész a legfontosabb. Megértést adnak arról, hogy milyen lesz a webhely és hogyan fog működni.

Egy nagyon fontos pont - nem lehet csak megadni a feladatkört a fejlesztőknek, és remélni, hogy mindent jól csinálnak. A TK egy követelménylista az oldallal szemben, nem helyettesítheti a kommunikációt. Fontos, hogy minden csapattag megértse a közös célt, és ne csak a folyamatban végezzen feladatokat. Ha valami nem világos - meg kell magyarázni, megvitatni, részletes megjegyzéseket kell tenni.

Az életben gyakran előfordul, hogy az ember még a hétköznapi dolgokban sem tudja megmagyarázni, mit akar. Amikor el kell magyarázni a „kívánságait” egy programozónak, az ember egyszerűen kábulatba esik.

Ideális esetben a TK-t az ügyfélnek kell elkészítenie - csak ő tudja, mire van szüksége. De a gyakorlatban az ügyfél alacsony kompetenciája miatt az 1C területén ezt gyakran a vállalkozónak kell megtennie. A megrendelő szóban hangot ad igényeinek, a programozó (tanácsadó) ezt írásban formalizálja.

Miért van szükség specifikációra?

Ideális esetben bármelyiket technikai feladatnak kell kísérnie. Ez egyrészt a feladat, a határidők és a végrehajtás módjának egyértelmű meghatározása. Másodszor, ez egy dokumentum, amelynek segítségével a jövőben minden vitát megoldanak. Természetesen Önön múlik, hogy megírja-e a műszaki specifikációt vagy sem, számomra személy szerint a műszaki specifikáció megkönnyíti a munkát és az ügyféllel való kommunikációt.

Ingyenes 267 1C videóleckéket kaphat:

Mit kell tartalmaznia a feladatmeghatározásnak?

Azok. A feladatnak tartalmaznia kell:

• cél- a feladat, amelyet a TOR megvalósításával fogunk megoldani;
• leírás- a közelgő fejlesztések összefoglalása;
• végrehajtási módszer- a cél megoldási módszereinek részletes leírása. Ezen a ponton le kell írni a feladat minden árnyalatát a programozási nyelven: mit, létrehozunk / szerkesztünk, hogyan kell kinéznie a felületnek stb. Ha nem ismeri a „programozási nyelvet”, de „hallott valamit”, akkor jobb, ha nem próbálja meg szaknyelven írni – elég szórakoztatónak bizonyul. A leírás legyen egyértelmű, és ne okozzon kérdéseket. Példát is tartalmazhat egy hasonló megoldás más területen való megvalósítására;
• teljesítményértékelés- egy nagyon fontos pont, a munkaerőköltségek leírása.

Vannak állami szabványok is a műszaki előírások írására - GOST-ok. A gyakorlatban ritkán használják őket bárhol, de előfordul, hogy a vásárló ragaszkodik ehhez.

Tapasztalatból adódóan a munka átadásakor nagyon gyakran adódnak olyan helyzetek, hogy „akkor mondtuk…”, ami nem túl kellemes, és sokszor teljesen újra kell csinálni a munkát. Ezért egy jól megírt TOR nagyban megkönnyíti mindkét fél életét.

Példák és minták TK-ra 1C-hez

Egy kis válogatás, amit szabadon elérhetőnek találtam a neten. Kezdve a legegyszerűbb és leginkább hozzáférhető dokumentumokkal, egészen bonyolult dokumentumokig.