Ha „termékkövetelmény-dokumentum” kéréssel járja végig a külföldi oldalakat, 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ípuskészítés sokkal érdekesebbnek és hatékonyabbnak tűnik, mint a rengeteg ügyfélnyilvántartás, 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ában ma - azokról a nagyon klasszikus technikai feladatokról, amelyeket a megvásárolt és telepített szoftverek véglegesítésére írnak. Röviden a sebről.

Az interakció oldalai

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ő beleesik a projekt indításakor.

Követelmények- a rendszer kívánt, a megrendelő vagy folyamatgazdálkodó által leírt, megvalósítandó viselkedése. 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. 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, ezt igazán megteheti 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álatra vonatkozó 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 a megrendelőnek nincs lehetősége annyit fizetni nekünk, hogy humán- és időerőforrást költsön át 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ő elvégzé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

Ez egy nagyon fontos belső vállalati folyamat, melynek során kiderül, hogy a potenciális felhasználók mit szeretnének a programtól (továbbiakban CRM-et vesszük, de a módszerek más típusú szoftverekkel működnek). Ha felveszi a kapcsolatot egy nagy szállítóval, például az SAP-val vagy egy rendszerintegrátorral, akkor nagy valószínűséggel üzleti tanácsadó szolgáltatásait fogják felkínálni (egyben személyi menedzser, ügyfélmenedzser is, ő is „ most az Ön képviselője cégünknél”). Valójában a legtöbb esetben ez egy közönséges, jól képzett eladó, akinek két feladata van: felszámolni a projekt költségeit, és nem engedni a horogról.

Már egy órája itt van, és még csak hozzá sem nyúlt a táblához. Nem igazi rendszerelemző

Senki sem ismeri jobban a cégét, 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.

Van egy nagyon egyszerű séma a követelmények összegyűjtésére.

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 demóverzióhoz.
2. A munkacsoport tagjainak teljesen ingyenes formában kell tájékoztatniuk a dolgozókat, és ki kell kérniük tőlük az új programra vonatkozó kívánságokat. 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. Például nem ritka, 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őket és entitásokat másként nevezik el 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. Időben teljesen eltérő feladatokról van szó, itt nagyon fontos a prioritás.

A követelmények összegyűjtése, elemzése és az alkalmazottakkal és a vezetőséggel való egyeztetése után megkezdheti a feladatmeghatározás létrehozását. 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.

• 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ó - a követelmények formális és részletes leírása, a műszaki előí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 funkcionalitás ellenőrzése a szállító munkatársai, az ügyfél belső szakértői és végfelhasználói által a revízió TOR-nak való megfelelőségének, a rendszer változtatásokkal való működőképességének megállapítása érdekében.

Általánosságban elmondható, hogy a feladatmeghatározás több szint követelményei alapján is megalkotható, amelyek átfedhetik egymást és együttműködhetnek a projekt létrehozásában, vagy egyáltalán nem hatnak egymásra.

Ü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 a megrendelővel való szoros együttműködéssel. 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 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. Például a felhasználó azt szeretné, ha egy ablak jelenik meg 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 több követelmény a marketing, a logisztika és a műszaki támogatás részlegétől.

funkcionalitási szint. Gyakran 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 történik, 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. Ideális esetben a szállítónak nem kellene ilyen fejlesztéseket végrehajtania – a vállalati szoftverek nem lassulhatnak le, 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. Ezek lehetnek a platformhoz, operációs rendszerhez vagy eszközökhöz kapcsolódó ügyfélkövetelmények. Például egy összeállítási kérelem 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ései alapján készítettük el 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 feladatkör 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 poszt elején kicsit furfangosak voltunk, osztályként tagadtuk meg 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. Egy cég bevezette a CRM-et, és az adatok meglehetősen nagy tömbjén kellett volna dolgoznia (több tízmillió rekord havonta, több százezer rekord naponta). Az értékesítési osztály vezetője ezen nyilvántartások „napi” gyakorisággal történő feltöltéséről jelentést kért. 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 indítható. Mondanom sem kell, idő és pénz elvesztegetett.

Minek? 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 rendszerrel szemben. És itt megtörténnek azok a gyöngyszemek, csodák és ütközések, amelyeket a bashorghoz illik küldeni, é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ékok - 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 szakaszokhoz külön-külön
4. A műszaki feladat 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, amelyet a Fejlesztő könnyei írnak

A felülvizsgálathoz a TOR-nak kell lennie a felülvizsgálathoz, és nem a CRM 300 oldalas leírása, amelyre az ügyfélnek szüksége van. A követelmények megfogalmazása előtt alaposan meg kell ismerkednie a rendszer interfészével, képességeivel, dokumentációjával - valószínűleg a "kívánságlista" nagy része már az alapcsomagban található. Második lépésként a beépített finomító eszközökre (jelentéstervezők, konfigurátorok stb.) való odafigyelést javaslom - talán egy főállású programozó is meg tudja tenni a szükséges változtatásokat (sok cégnél van ilyen).

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 a pénz, sem az üzlet szempontjából nem indokolt. Egy szállító általában néhány hétig nem létezik (a RegionSoft esetében - 15 év), és egy idő után is kapcsolatba léphet vele, 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 megvásárolta egy jól ismert orosz cég ERP-jét, és azt gondolta, hogy mivel működik a könyvelés, akkor ennek az eladó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 raktári könyveléssel és termeléssel 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 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. Nem, természetesen mindennek megvan az ára, de ismét - általános esetben ez a követelmény lehetetlen.

Nem szabad összetéveszteni azzal a helyzettel, amikor egyedi fejlesztésről van szó, és az alkalmazás elgondolása, logikája gyökeresen megváltozik, sőt, új szoftverek „saját maga számára” 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 leendő projekt minden lényeges részletét: a programhasználat 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 akkor érdemes odafigyelni a részletekre, 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 vállalatának.

Ü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.

Igen, a vállalati szoftverek valahogy így néznek ki, és sok fontos apróság van benne.

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 ő maga választja ki, hogyan csinálja. a rendszer jellemzői és az alkalmazott technológiák halma.

Idén újra kívánhat egyet. Csak kérem, ne pazarolja olyasmire, amit még én sem tudok teljesíteni, például egyértelmű üzleti követelményekre!

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 olyan konstrukciókat kerít, mint: „valósítson meg egy ablakot utalással a naptár törzsében, amely képes reagálni egy eseményhívásra...” ahelyett, hogy „ablaknak fel kell bukkannia a naptárban amelyben a feladatot befejezettként jelölheti meg”. Ha Ön vagy belső szakértője nem rendelkezik szakszöveg íráshoz szükséges készsé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 a megértés szintjén - akkor a fejlesztő már kód szinten 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 havi rendszerességgel, termékcsoportokkal összefüggésben elmenti”.

   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 ké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 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 leírások helyett leveleket, panaszokat, szerződéseket, újonnan írt CRM-re vonatkozó utasításokat vagy tárgyalási jegyzőkönyveket 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 egy mobilszolgáltató vagy egy nagy hipermarket folyamatainak automatizálásával kell szembenéznie. 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 elmélyülnie a technológiában, é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, amíg 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 tervezési szabályokról, a GOST 1989-ről, ami embertelenné teszi a TK-t, az IEEE szabványokról, amik kicsit jobbak, a prototípusokról és az ezeket kiegészítő TK-ról. De végül egy, a legfontosabb szabályra szeretnék korlátozni magam: a feladatmeghatározás nem jogállamiság, nem GOST és nem dogma, ezért, ha javíthat - javíthat, egyszerűsíthet - 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, nem a plafonról szedjük.

   Nos, ha szüksége van egy CRM-rendszerre (módosítással vagy anélkül), akkor lépjen a következőre 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.

Szakértőink segítettek a megrendelőnek az alkotásban A szellőzőrendszer korszerűsítésének feladatköre.

További részletek a vágás alatt..

Műszaki feladat

a Moszkva 451 452 számú laboratóriumi épület 17. számú épület szellőzőrendszereinek technológiai berendezéseinek korszerűsítésére

1. Általános rendelkezések

1.1. Jelen feladatmeghatározás a 17. számú épület 451 452. számú laboratóriumaiban a technológiai berendezések, vezérlőrendszerek és szellőzőberendezések automatizálásának korszerűsítésével kapcsolatos munkák végrehajtását írja elő.

1.2. A munka elvégzéséhez dolgozzon ki munkadokumentációt az AOV, EM, KhS, AHS, AK márkák szakaszaihoz, amelyeket az előírt módon kell egyeztetni.

1.3. A munkavégzés a szabályozási és műszaki dokumentáció követelményeinek megfelelően.

1.4. A munka befejezése után nyújtsa be a GOST és az SNiP követelményeinek megfelelően elkészített dokumentációt.

1.5. Az elkészült munkát beküldi a megrendelőnek.

1.6. A jelen Felhasználási Feltétel egyes rendelkezései a munkavégzés során a Megrendelővel egyetértésben rögzíthetők.

2. Műszaki követelmények

2.1. Szellőztető egységek hő- és hidegellátását szolgáló vezérlőegységek korszerűsítése.

2.1.1. A hőellátás szabályozásának csomópontjai.

A modernizáció a következőktől függ:

· a laboratórium 452., P1 számú laboratóriumának MIK-V, P2, P6 épületeinek K1, K2, K2a, K4 szellőztető egységeinek első fűtési hőellátási szabályozói.

· a MIK-V épület K1, K2, K2a szellőztető egységeinek második fűtésére szolgáló hőellátás szabályozó egységei.

A meglévő hőellátó vezérlőegységek szétszerelésre szorulnak, míg a vezérlőegységek (keringető szivattyúk, elzárószelepek) felszereltségének egy részét, állapotának és műszaki jellemzőinek megfelelő, szerelt vezérlőegységekben kell használni.

A szerelt vezérlőegységek berendezéseinek összetételét, valamint az alkalmazott berendezéseket az 1. számú melléklet tartalmazza.

A szellőzőberendezések fűtőköreinek és fűtőberendezéseinek hidraulikai vizsgálatainak elvégzése hidraulikus vizsgálati jegyzőkönyv elkészítésével.

Csővezetékek festési, hőszigetelési munkák elvégzése.

2.1.2 Szellőztető egységek hűtőellátásának szabályozására szolgáló csomók.

A 451. számú laboratórium „452, P1” MIK-V, P2, P6 épületeinek K1, K2, K2a, K4 szellőztető egységeinek hűtőberendezései korszerűsítésre szorulnak.

Munkakör:

· hűtőberendezések termosztatikus szelepeinek cseréje;

A K1 kompresszor-kondenzációs egység ventilátorának szétszerelése/beszerelése;

· K1, K2 kompresszor-kondenzációs egységek szűrői-szárítóinak leszerelése/beépítése;

K4 szellőztető egység párologtatójának szétszerelése/beszerelése;

· nyomáspróba inert gáz környezetben, vákuumozás, hűtőkörök freonnal történő feltöltése;

Csővezetékek hőszigetelésének helyreállítása.

2.1.3. Betápláló egységek párásító körökhöz.

Telepítsen hidegvíz-tisztító szűrőket a K1, K2, K2a klímaberendezések öntözőkamráinak tápegységeinél.

2.2. Szekrények szellőztető berendezések vezérléséhez és automatizálásához.

Vezérlőszekrények a 451. számú laboratórium MIK-V, P2, P6, V1, V2, V3 épületeinek K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8 szellőztető egységeihez, 452. sz. laboratórium V1.

Az újonnan telepített vezérlőpanelek elrendezése:

SHUA K1 - a K1 (MIK-V) klímaberendezés szellőzőegységének és kompresszor-kondenzátorának (KKB) kapcsolószekrénye és automatizálása;

SHUA K2 - kapcsolószekrény és a szellőztető egység automatizálása és a KKB klímaberendezés K2 (MIK-V);

SHUA K2 - a szellőztető egység és a KKB klímaberendezés K2a (MIK-V) kapcsolószekrénye és automatizálása;

SHUA K4 - a szellőztető egység és a KKB klímaberendezés K4 (MIK-V) kapcsolószekrénye és automatizálása;

SHUV - vezérlőszekrény RU3, V1, V2, V3, V6, V7, V8 kipufogóegységekhez (MIK-V);

ShUA P2, P6 - szellőztető egységek és P2, P6 kompresszor- és kondenzátoregységek vezérlőszekrénye és automatizálása (452. számú laboratórium);

SHUV - vezérlőszekrény V1, V2, V3 kipufogóegységekhez (452. számú laboratórium);

SHUA P1, V1 - P1, V1 szellőztető egységek kapcsolószekrénye és automatizálása (451. számú laboratórium).

A modernizált kapcsolószekrényeknek biztosítaniuk kell:

a szellőztető egység vezérlési módjának kiválasztása a szekrény előlapjáról (kézi/automatikus);

· szellőzőberendezések technológiai berendezései normál és vészhelyzeti üzemmódjának fényjelzése (üzem/baleset);

a szellőzőrendszerek leállítása tűz esetén;

a védelem automatikus működése és a berendezések működésének blokkolása vészhelyzet esetén.

A továbbiakban frekvenciaváltókat kell alkalmazni a ventilátorok és szivattyúk elektromos motorjainak vezérlésére.

2.3. Automatizálási és diszpécserrendszer

Az automatizálási és diszpécserrendszer a szellőztető egységek működésének irányítására és vezérlésére, valamint a bejövő információk összegyűjtésére, feldolgozására, bemutatására és tárolására szolgál.

2.3.1. Automatizálási rendszer.

Az automatizálási rendszernek általában biztosítania kell a szellőztető egységek autonóm működését, amely nem igényli a karbantartó személyzet beavatkozását és szükség esetén kézi vezérlésre való átállást. Bármilyen szabályozási lehetőségnél és a helyi vezérlő állapotától függetlenül fenn kell tartani az általános szellőzőrendszer tűz esetén történő automatikus leállításának feltételét. A leállítást minden rendszernél külön kell végrehajtani, miközben a fagyálló áramkörök tápellátását is fenn kell tartani.

A szellőzőrendszerek helyi automatizálásának tartalmaznia kell:

a befúvott levegő hőmérsékletének szabályozása a szellőztető egység kimeneténél, vagy szükség esetén a karbantartott helyiségekből távozó levegő hőmérsékletének szabályozása;

a befújt levegő páratartalmának szabályozása;

állítsa le a ventilátorokat és zárja el a légszelepeket, ha tűzriadó lép működésbe;

A légkondicionáló párásításának kikapcsolása, amikor a ventilátor leáll;

A levegőszelep nyitása és zárása a ventilátor indításakor és leállításakor;

· a fűtőtestek automatikus felfűtése a rendszerek beindítása előtt téli üzemmódban;

· a fűtőtestek levegő és víz általi fagyás elleni védelme (a ventilátor kikapcsolása, a légcsappantyú zárása, a fűtési szelep 100%-os nyitása);

a ventilátor leállítása nyomáskülönbség hiányában;

· a létesítmények szűrőinek szennyezésének ellenőrzése.

A munkaállomások helyi automatizálására gyakorolt ​​távoli hatást a következő kötet határozza meg:

· a hőmérséklet- és páratartalom-szabályozók beállításainak megváltoztatása;

· beállítások engedélyezése/letiltása.

Az automatizálási rendszer meglévő perifériáinak ellenőrzése, tisztítása és további felhasználása az alábbi sorrendben történik:

· a szellőzőberendezések hőmérséklet- és páratartalom-érzékelőit hitelesíteni kell;

· A nyomáskülönbségkapcsoló érzékelőit ellenőrizni, tisztítani kell;

· A légfűtők fagyás elleni védelmére szolgáló termosztátokat ki kell cserélni.

· A vezérlőegységek vezérlőszelepeinek működtetőelemeit a 2.1.1. pont szerint kell cserélni.

a levegőszelep működtetőit ellenőrizni kell és tovább kell használni;

A K1 klímaberendezés recirkulációjának szabályozásához cserélje ki a légszelepek ki-be állítóelemeit 0...10V vezérlőjelű szelepekre.

2.3.2. diszpécser rendszer.

Szerelje be a következő komponenseket a diszpécserrendszerbe:

a "Honeywell" szoftver- és hardvereszközökön alapuló mérőeszközök, aktuátorok és automatizálási eszközök komplexuma;

· többfunkciós kábelrendszer;

· a vezérlőterem szoftver- és hardvereszközeinek komplexuma.

A szellőzőrendszerek kiszállításához gondoskodjon a következő információk megjelenítéséről, archiválásáról és naplózásáról:

· berendezések grafikus ábrázolása hőmérséklet- és páratartalom-érzékelőkkel, fagyálló termosztátokkal, nyomáskülönbség-kapcsolókkal, vezérlőszelepekkel, légnedvesítőkkel, légszelepekkel;

telepítési számok;

hőmérséklet- és páratartalom-érzékelők leolvasása;

nyomáskülönbség-relé érzékelők leolvasása;

vezérlőszelepek helyzetének jelzései 0...100%;

ventilátor működési/leállítási mód;

· szivattyúk "munka / leállítás" üzemmódja;

a levegőszelepek helyzete "nyitva / zárva";

leállítja a rendszereket, ha tűzriasztás indul;

a rendszerek leállítása, ha fennáll a fűtőelem lefagyásának veszélye;

az egység leállítása nyomásesés hiányában a ventilátoron;

A légnedvesítő kikapcsolása, amikor a légkondicionáló ventilátor leáll;

Rendszerek működése adott időbeosztás szerint vagy anélkül;

· balesetek és vészhelyzetek jelzése berendezés meghibásodása esetén, valamint - a folyamatparaméterek megadott tartományon kívüli értékeinek kiadása;

balesetek és veszélyhelyzetek rögzítése az üzenetnaplóban;

· Paraméter regisztrációs napló az aktuális időhöz, amely tartalmazza a szabályozott paraméterek nevét, mértékegységeit, a vezérlő számát és a bemeneti/kimeneti csatornát.

2.3.3. Az automatizálási és diszpécserrendszer tápellátását 380/220 V feszültségű, 50 Hz frekvenciájú váltakozó áramú hálózatról kell táplálni, akkumulátoros szünetmentes tápegységekkel, és az első kategóriás fogyasztók tápellátásaként.

Ez közvetlenül attól függ, hogy az 1C véglegesítésére vonatkozó feladatmeghatározás milyen pontosan készül, hogy a fejlesztőkhöz rendelt feladatokat megoldják-e. Azonban, ha egy ilyen dokumentummal dolgozik, vannak nehézségek. Tág értelemben a TOR előírja az automatizált rendszer (AS) létrehozásának és korszerűsítésének normáit, valamint a munkavégzés menetét. Ez egy sor projektindítási szabványt is tartalmaz. A feladatmeghatározás szerepének ezt a megértését a GOST 19.201-78 és 34.602-89 követelményei határozzák meg, amelyek szerint az 1C TOR-ját fejlesztik. Ennek a dokumentumnak van egy másik, a gyakorlathoz közelebbi értelmezése is.

Egy másik definíció szerint az 1C véglegesítésére vonatkozó feladatmeghatározás egy olyan dokumentum, amely szabályozza a jövőbeli rendszer célját és paramétereit, valamint a dokumentáció és annak listája kidolgozásának folyamatát. Ez az értelmezés lehetővé teszi a programozók és a megrendelő érdekeinek figyelembevételét.

Mi legyen a TK?

Az 1C program fejlesztésével kapcsolatos bármely műszaki feladatot a vállalkozó hoz létre. De ez nem programozó, hanem elemző. Ez azért fontos szempont, mert a dokumentumot az ügyfél által értett nyelven kell megírni, rendkívül speciális szakkifejezések nélkül. Ha a projekt minden árnyalatát figyelembe veszik, és az információkat helyesen fogalmazzák meg, a TOR-t minden ügyféllel megállapodnak. Ha elfogadják, programozókat vonnak be a munkába. Ugyanakkor a kívánt eredményt egyértelműen fel kell vázolni a dokumentumban. Ez segít a fejlesztőknek abban, hogy kitűzzék a megfelelő célt, és különböző szakaszokban ellenőrizzék azt. Ezenkívül az 1C véglegesítésére vonatkozó feladatmeghatározás összeállításakor nagy figyelmet kell fordítani a megfogalmazásra. Gondoskodni kell arról, hogy kellően konkrétak legyenek, és ne tartalmazzanak más értelmezést. Ez az első dolog, amire emlékezni kell, amikor a TK-val dolgozik. A tervezést is felelősségteljesen kell megközelítenie. Ez vonatkozik a dokumentum címlapjára is.

A fő hibák az 1C fejlesztési feladatkörében

A feladatmeghatározás szerkezetét a GOST 34.602-89 szabályozza. Ez a dokumentum egyértelmű követelményeket tartalmaz a TOR-ban lévő információblokkok számára és sorrendjére vonatkozóan. Ugyanakkor nincsenek szigorú szabványok az előadásmódokra vonatkozóan. Ez a helyzet nagy lehetőségeket rejt magában az összetett problémák megoldásában, ugyanakkor számos hibához vezethet a dokumentum elkészítésében. A leggyakoribb pontatlanságok a következők:

1. Egyes szakaszok megismétlése eltérő értelmezésben.
2. Az információ véletlenszerűen történik. Ideális esetben egy adott struktúrára kell utalnia, például üzleti folyamatokra vagy rendszermodulokra.
3. A különböző szakaszokban található információk eltérő részletességgel jelennek meg.

Mindez megakadályozza, hogy az ügyfél megértse a TOR-ban szereplő információkat. Ez megnehezíti az együttműködés folyamatát, és időigényesebbé teszi azt.

Miután az ügyfél megtekintette, az 1C felülvizsgálatához használt TOR minta módosulhat, és nem mindig jobbra. Ez viszont általában megakadályozza, hogy a programozók helyesen érzékeljék az információkat. Ez különösen igaz a kevés tapasztalattal rendelkező szakemberekre. Ebben a szakaszban gyakran előfordulnak a következő hibák:

1. A különböző szakaszok követelményei ellentmondanak egymásnak.
2. A képletek pontatlanok.
3. Egyes helyeken túl részletesek az információk.

Mindezen hibák elhárítása egyszerű. Mindenekelőtt az eredményre kell összpontosítani, nem pedig a készítmények gondos felírására. Érdemes megjegyezni, hogy a TOR leírja a projekt funkcionalitását, fő paramétereit és célját.

Hogyan lehet elkerülni a hibákat a műszaki specifikációk kidolgozása során?

A fő szabály, amely minden további ajánlásra vonatkozik, az, hogy a megfogalmazásnak konkrétnak kell lennie. Ehhez a GOST-okra, más szabályozási dokumentumokra mutató hivatkozásokat kell használnia. Ez lehetővé teszi, hogy a vállalkozó és a megrendelő azonos módon érzékelje az információkat.

Egy példa az 1C véglegesítésének technikai feladatára annak az üzleti ágazatnak a nyelvhasználatát jelenti, amelyre a projektet végrehajtják. Ez mindenekelőtt az ügyfél számára szükséges. Ugyanakkor ne használjon összehasonlítást a szövegben, mivel azok többféleképpen értelmezhetők.

A jelentés és az 1C egyéb elemeinek kidolgozására vonatkozó feladatmeghatározás összeállításának alapvető szabályai:

1. A TK-t a vállalkozó és a megrendelő közösen hozza létre.
2. Csak objektív követelményeket szabad a programozók munkájával szemben támasztani. A sikeres projektfejlesztéshez a megrendelő szubjektív látásmódját minimálisra kell szorítani.
3. Részletesen le kell írni azt az eredményt, amelyre az ügyfélnek szüksége van. Ugyanakkor az 1C konfiguráció fejlesztésére vonatkozó feladatmeghatározás példájában elő kell írni az összes olyan paramétert, amellyel az elemnek működnie kell. Ellenkező esetben az eredmény nagyon eltérhet a kívánttól.
4. A vállalkozó és a megrendelő kockázatának megközelítőleg egyenlőnek kell lennie, és minimálisra kell csökkentenie.
5. Nem használhat olyan kifejezéseket, amelyeket az üzleti kommunikációban használnak, és amelyeket nem egy adott iparágban használnak.

Ahhoz, hogy TOR-t hozzon létre egy jelentés elkészítéséhez az 1C-ben vagy más elemben, az elemzőnek ismernie kell az ügyfél tevékenységi területének összes jellemzőjét. A követelményekben csak hasznos információkat kell megadnia, amelyek hasznosak az előadó számára. Tekintettel arra, hogy itt különös figyelmet fordítanak azokra a végső feladatokra, amelyeket a szoftvernek meg kell oldania, nincs egyetlen példa technikai feladatra.

A TOR helytelen elkészítésének veszélye

A fent felsorolt ​​hibák megnövelhetik a rendszer létrehozásához szükséges időt. Ez szükségtelen költségekkel és elégedetlenséggel jár. Az adatbázis vagy más 1C konfiguráció fejlesztésére vonatkozó feladatmeghatározást tapasztalt szakembereknek kell elkészíteniük. Az összes résztvevő előnye attól függ, hogy ez a dokumentum mennyire érthető. Az ügyfél hatékony automatizált rendszert kap az üzleti problémák megoldására. Ugyanakkor a vállalkozónak van egy másik elégedett ügyfele is. Az üzlettulajdonosoknak a lehető legóvatosabbnak kell lenniük az 1C partnervállalatok kiválasztásakor, mivel a szervezet hatékonysága nagymértékben függ attól, hogy a felülvizsgálatra vonatkozó feladatmeghatározás milyen jól van kidolgozva.

Pavel Moljanov

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 oldalkészítéssel: fejlesztők, tervezők, tördező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, annál jobban megérti a folyamat minden résztvevője, 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, hogy mi fog működni és hogyan. Gondolja át, hogy minden megfelel-e Önnek. Ha nem, akkor 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 bele a munkába.
• Ismerje meg egy komplex 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 is meg kell értenie, hogyan fog működni a szolgáltatás, és milyen funkciókat fog ellátni. 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 nézzük meg, 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 a dolgát? Alig.

Egy jó TOR-t mindig egy előadó készít: projektmenedzser vagy 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 jelenti azt, 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 szemétnek bizonyul, amelyet csendben a szemétbe dobnak.

Í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 semmit sem jelent:

• Az oldalt kedvelnie kell a vásárlónak. Mi van, ha rossz kedve van?
• Az oldalnak felhasználóbarátnak kell lennie. Mit jelent? Mire kényelmes?
• A helyszínnek ellenállnia kell a nagy terheléseknek. 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 meg kell értenie, hogy 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.

És érdemes az oldal célját is feltüntetni, és dióhéjban leírni a funkcionalitását - nehogy egy webáruházat kapjunk a 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ól. 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 másolás-beillesztés 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 fogod megtenni!”

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 követelményeket. a webhely betöltési sebessége, terhelésekkel szembeni ellenállás, hacker támadások elleni védelem és hasonló dolgok.

Adja meg a webhely szerkezetét

A terv és az elrendezés megrajzolása előtt meg kell állapodnia az ügyféllel a webhely szerkezeté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 vá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 ferde 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 objektív értékelési kritériumok oldal tervezése nehéz kitalálni. 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.
• Oldalak prototípusai vagy leírása azokról az elemekről, amelyeknek szerepelniük kell rajtuk.
• 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 még egy - 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, hivatkozhat a TK-ra, és kérheti, hogy csinálják újra.

A TOR-t a projektmenedzser állítja össze, miután az ügyféllel kommunikált, é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 megbizonyosodni arról, hogy minden csapattag megérti 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.