Technikai feladat a minta finomítására. Technikai feladat TK a szellőztetés korszerűsítéséről a kutatóintézetekben

Pavel Molanov

Emlékezz a Murphy törvényére? Ha nem lehet helyesen érteni, akkor biztosan helyesen érthető. Ez nem csak az emberek közötti kommunikációban, hanem a webhelyek létrehozásában is. Az ügyfél a második "Facebook" -t akarta, és megkapta a fiatal kutya tenyésztők fórumát. A fejlesztő nem kitalálta az ügyfél kívánságlistáját - a pazarolt időt töltötte.

Ebben az útmutatóban elmondom, hogy mit és miért kell írni a műszaki indításban. Ugyanakkor megmutatom, hogy nem szükséges írni, hogy a TK létrehozása nem csomagolódik el időben.

A cikk hasznos lesz:

• Mindenki, aki kapcsolatban áll a webhelyek létrehozásával: a fejlesztők, a tervezők, a kameramen.
• Projektmenedzserek.
• Didjital stúdiók vezetője.
• Vállalkozók, akik a webhely fejlesztését tervezik.

Annak érdekében, hogy az anyag jó legyen, összegyűjtöttem a Dijital Studios több fejlesztője, tervezője, projektvezetője és tulajdonosaiból. A cikk végéhez hozzáadott legértékesebb. Menjünk értem.

Mi az ömlesztett és miért van szükség

A technikai feladat olyan dokumentum, amelyben a webhelyre vonatkozó követelményeket rögzítik. A világosabb, ezek a követelmények részletesebben festettek, annál jobb a folyamat minden résztvevője megérteni, hogy mit kell tennie. Szóval, növeli az esélyt, hogy mindenki elégedett marad az eredménygel.

A technikai feladat fő célja: győződjön meg róla, hogy az ügyfél és a vállalkozó helyesen értette egymást.

Sok technikai feladat használata. Minden oldalra ez a saját.

Az ügyfél használatához:

• Értsd meg, mit fizet pénzt, és mi lesz az oldal. Azonnal láthatja a struktúrát, megértse, mit és hogyan fog működni. Gyakoriság, akár minden kielégítő. Ha nem, változhat a fejlesztés kezdete előtt.
• Lásd a művész kompetenciáját. Ha a technikai keret egyértelmű és világos - a fejlesztő felemelkedése. Ha a zabkása ott van írva - talán érdemes futni, és nem néz körül.
• Kiegyenesíti a művész gátlástalanságát. Amikor a webhely készen áll, a technikai feladat szerint ellenőrizhető. Van-e ellentmondások? A fejlesztőnek ki kell javítania őket. Ha hivatalosan együttműködsz és szerződést kötöttél - még a bíróságon keresztül is kényszeríthetsz.
• Egyszerűsítse az előadók cseréjét. Ha az ügyfél és a fejlesztő érett és elmenekült, a webhely létrehozása erősen késleltethető. Ha van egy részletes gazdaság, akkor át lehet adni egy új csapatnak - ez gyorsabban dolgozik.
• Ismerje meg a komplex termék fejlesztésének költségeit. Értékelje a pontos időt és a komplex webszolgáltatás fejlesztésének költségeit nem lehet kiválasztani. Először meg kell értened, hogy a szolgáltatás hogyan fog működni, és milyen funkciók lesznek benne. Ehhez, és fel kell készítenie az ügypiacot.

A művész előnyei:

• Értsd meg, mit akar az ügyfél. Az ügyfelet több tucat kérdést tesznek fel, példákat mutatnak, megoldásokat kínálnak. Ezután írjon mindent egyetlen dokumentumba és koordinátára. Ha minden rendben van, akkor jól értette.
• Kiegyenesíti az ügyfél hirtelen vizeit.Néha vannak olyan ügyfelek, akik meg akarják változtatni a félúton. Ha egyetértettél és aláírta a TK-t, akkor nem szörnyen hasonló. Ebben az esetben még a bíróság is az Ön oldalán lesz.
• Mutassa meg kompetenciáját. A hűvös előkészített karbantartás megmutatja az ügyfelet a fejlesztők költségeinek. Ha a vállalat kétségbe bocsátott, hogy megbízik-e a webhely fejlődésének, kétségei nagy valószínűségű eloszlással.
• Pénzt keresni. Egyes stúdiók és fejlesztők kínálnak a TK összeállítását külön szolgáltatásként.

• A fejlesztési folyamat megkönnyítése és felgyorsítása. A jó TK-ban a webhelyszerkezet, a szükséges funkciók és elemek minden oldalon szerepelnek. Amikor az összes követelmény már a szemünk előtt van - csak akkor marad, ha Sasy és írási kódot kell tennie.

Most adjuk meg, hogyan lehet olyan jó gazdaságot készíteni, amely ezeket a funkciókat elvégzi.

A karbantartás előadóművész

Általában a piactéren lehet senkit. "Szükségünk van egy névjegykártyára egy fogorvosi klinikára" - ez már az ömlesztett. De teljesíti a funkcióit? Valószínűtlen.

A Good Tz mindig a művész: projektmenedzser vagy fejlesztő. Nyilvánvaló, hogy a webfejlesztő megérti a webhelyek létrehozását, mint egy kávézó vagy fogorvosi klinika tulajdonosa. Ezért a projekt leírása lesz neki.

Ez nem jelenti azt, hogy az ügyfél eltűnik és megjelenik a végén az írás: "ZBS, jóváhagyva". Részt kell vennie a folyamatban:

Természetesen az ügyfél felhívhatja a TK saját verzióját. Talán ez felgyorsítja a végső gazdaság létrehozásának folyamatát. És talán kiderül a szemetet, amelyet csendben dobnak a szemétbe.

Írjon határozottan és pontosan

Ez a tanács az ügypiac fő céljából következik - "győződjön meg róla, hogy az ügyfél és az előadó helyesen értette egymást."

A technikai feladatban nem lehet magas színvonalú melléknevek: gyönyörű, megbízható, modern. Nem lehetnek egyértelműen megérteni. Mindenkinek saját a szépség és a modernitás fogalmai vannak.

Néz. Valaki végül is, úgy vélte, hogy ez a design szép és megengedte, hogy használja a honlapján:

Ugyanaz a dolog - a homályos készítményekkel, amelyek nem jelentenek semmit egyedül:

• Az oldalnak az ügyfélnek kell lennie. És ha rossz hangulata van?
• A webhelynek kényelmesnek kell lennie. Mit jelent? Kényelmes, hogy mi?
• A webhelynek ellen kell állnia a nehéz terheket.10 ezer látogató? Vagy 10 millió?
• Minőségi szakértői tartalom. Nos, megértetted.

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

• A webhelyet gyorsan le kell tölteni → A webhely bármely oldalának több mint 80 pontot kell tartalmaznia a Google Pagepeed Insights-ben.
• Nagy terhelések → 50 ezer látogató egyidejűleg.
• A főoldal a cikkek listáját jeleníti meg. → Az utolsó oldal megjeleníti az utolsó 6 közzétett cikk listáját.
• Minimalista felhasználóbarát előfizetési felület → "E-mail" mező és "Feliratkozás" → * rajzolt vázlat *.

Rájöttünk a megfogalmazásról, menjünk a szerkezetben.

Általános információk megadása

Minden csapat tagja helyesen meg kell értenie, hogy mit csinál a cég, és ki a célközönség. Annak érdekében, hogy senki sem zavarja, jobb regisztrálni az ügypiac kezdetén.

És még mindig meg kell adnia a webhely célját, és leírnia kell a funkcionalitását egy dióhéjban -, hogy ne kapjon online boltot a blog helyett.

Magyarázza el a komplex feltételeket

A technikai tervezés első szabálya - mindenki számára világosnak kell lennie, akinek szándékában áll. Ha meg fogja használni azokat a feltételeket, amelyek nem tudják megérteni az ügyfelet - a gyermekjáték tároló tulajdonosa - győződjön meg róla, hogy megmagyarázza őket. Érthető nyelv, nem másolat-paszta a Wikipedia-ból.

Ismertesse az eszközöket és a tárhely követelményeit

Képzeld el, hogy 2 hónapja volt hűvös helyszínen. Minden egyes szakaszot összehangolták az ügyféllel - örülök. És most itt az ideje, hogy munkát végezzen. Megmutatja az admin panelt, és az ügyfél kiabál: "Mi az? Modex?! Azt hittem, a "WordPress"! "

Annak érdekében, hogy nincsenek ilyen problémák, írják le az alkalmazott eszközöket, motorokat és könyvtárakat. Ugyanakkor adja meg a tárhely követelményeit. Soha nem tudhatod, hogy a PHP-nél fogsz tenni - és az ügyfél a szerveren található .net.

Sorolja fel az oldal követelményeit

A webhelynek a helyi verziók böngészőjében és minden típusú eszközön kell működnie. Igen, nyilvánvaló bármely fejlesztőnek és bármely ügyfélnek. De jobb írni, hogy megvédje az ügyfelet a tisztességtelenül befejeződött munkából.

A webhely letöltési sebességének követelményeit is meg fogja írni, a terhelések stabilitását, a hacker támadások elleni védelmet és hasonló dolgokat.

Adja meg a webhelystruktúrát

A tervezés és az elrendezés megtervezése előtt meg kell egyetértenie a webhely struktúrájának ügyféllel.

Munka az ügyféllel, megtudja, mit igényel. Gyűjtsd össze a fejlesztőket, a Soschechnikovot, a marketingeket, a parancsnokokat - és eldöntsék, hogy mely oldalakra van szükség a helyszínen. Gondoljuk, hogyan fognak összekapcsolni, melyiket lehet menni.

Megmutathatja a szerkezeti listát, rajzolhat egy blokkdiagramot. Ahogy szeretnéd.

Ez az egyik legfontosabb munka a munkahelyen. A struktúra alapja. Ha sikertelen - a webhely görbé lesz.

Magyarázza el, mi fog történni minden oldalon

Az Ügyfélnek meg kell értenie, hogy miért kell minden oldalra szüksége, és milyen elemek lesznek rajta. Két módja van megmutatni.

Prototípus - vizuális és egyértelmű módon. A művész az egyes oldalak vázlatait rajzolja, és technikai elindítást tesz lehetővé. Az ügyfél úgy látja, hogy a jövőbeni webhelyének felülete hogyan fog megjelenni, és azt mondja, hogy szereti, és mit érdemes megváltoztatni.

Az elemek felsorolása - lusta alternatíva a prototípushoz. Csak írja meg, hogy mely blokkoknak kell lenniük az oldalon, és mit csinálnak.

Szennyvízszíni felhasználási forgatókönyvek

Ha nem szabványos felületet végez, csak megmutatja az oldalak szerkezetét és vázlatait. Fontos, hogy az előadók és az ügyfelek teljes csapata megértse, hogy a látogatók hogyan fogják használni a webhelyet. Erre a célra a szkriptek nagyszerűek. A Script Scheme nagyon egyszerű:

• Felhasználói művelet.
• Helyszín válasz.
• Eredmény.

Természetesen, ha szabványos névjegykártyát vagy hiteleket készít, akkor nem kell írni parancsfájlokat. De ha vannak interaktív szolgáltatások a helyszínen - nagyon kívánatos.

További információ a Wikipédiában található forgatókönyvekről.

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

Néhány fejlesztő azonnal megtartja a webhelyet. Mások halat hoznak. A harmadik szövegeket írhat, de felár ellenében. Egyetértek erről a parton, és javítják a technikai indításban, milyen tartalmat kell készíteniük.

A szövegek minőségének értékeléséhez objektív kritériumok meglehetősen nehéz. Jobb, ha nem írunk semmit, mint a "kiváló minőségű, érdekes és eladási tartalmat, hasznos a célközönség számára". Ez a szemét, nincs szükség senkinek.

Jelölje meg, hogy a teljes tartalomnak egyedinek kell lennie - hasznos. Egy másik ügyfélvédelem a gátlástalan előadóktól.

Ismertesse a tervezést (ha lehet)

Mint az ügy esetében a szöveggel, a webhely kialakításának becslésére vonatkozó objektív kritériumok nehézségekbe ütköznek. Ha egyetértett az ügyféllel a színséma - írja meg. Ha van egy brandook, amelyben a betűtípusok előírása - Adja meg őket.

A gyönyörű és modern design írása nem szükséges. Nem jelent semmit, nincs ereje és általában Fu.

A visszavonás helyett a tömegszerkezet

Különböző feladatokhoz a TK szerkezete a sajátjuk lesz. Buta, hogy ugyanolyan technikai feladatokat végezzen egy új közösségi hálózatra és a sárgarépa nagykereskedelmére. De általában szükséged van ezekekre a szakaszokra:

• Információ a cégről és a célközönségről, célokról és célkitűzésekről.
• Olyan kifejezések szójegyzéke, amelyek az ügyfél számára érthetetlenek lehetnek.
• Az elrendezés és a munkahelyi technikai követelmények.
• A használt technológiák leírása és a tárolási követelmények listája.
• A webhely részletes felépítése.
• Az oldalak prototípusai vagy azok leírása, amelyeknek rájuk kell lenniük.
• A nem szabványos interfész használatának forgatókönyvei (opcionális).
• A fejlesztőt tartalmazó tartalom listája.
• Tervezési követelmények (opcionális).

• Szoftverkövetelmények összeállítására vonatkozó szabályok. Az SRS az ömlesztés fejlődésének következő lépése. Nagy és összetett projektekre van szükség.
• A TK szabványok és sablonok a szoftverfejlesztéshez. A különböző vendégek és módszerek leírása a technikai feladatok létrehozásához.

Ez az a vége, amelyet írtam. De van egy másik - észrevételei olyan szakemberek, akik segítettek Hyde-nek. Olvassa el, ez is érdekes.

Megjegyzések fejlesztők

Több fejlesztővel beszéltem, hogy megtudjam, hogyan alkotják az ömlesztettséget. Én továbbítom a mikrofont.

Először is, a TK-nek ügyfélnek kell lennie - úgyhogy megérti, mit fog tenni, és milyen pénz megy. Ha valami nem történik meg, akkor a TK-ra utalhat, és kérheti, hogy remake-t küldjön.

A TK a projektvezető, miután kommunikál az ügyféllel, és megvitatja a feladatot a tervezővel.

A nagy ügyfelek gyakran kérnek nagyon részletes TK-t, amelyben minden egyes gombot leírják. A kisvállalkozások, éppen ellenkezőleg, nem szeretik az aprólékos dokumentumokat 100 oldalra. Hosszú olvasás és könnyen hiányzik valami fontos. Gyakran 10-15 oldalra laconikus TK-t készítünk.

Megadjuk:

• Információkat a vállalatról és a webhely céljáról.
• Tervezési követelmények, színskála.
• Használt technológiák és CMS.
• Ki foglalkozik a tartalommal - mi vagy az ügyfél.
• A webhely struktúrája minden oldalra vonatkozik.
• Az egyes oldalak leírása. Nem prototípusunk, de jelezze, hogy mely elemeket kell az oldalon, és hogyan kell működniük.

Az utolsó 2 szakasz a legfontosabb. Ők, akik megértést adnak, amely lesz az oldal, és hogyan fog működni.

Nagyon fontos pont - lehetetlen csak a fejlesztőknek, és remélem, hogy mindent jól fognak tenni. A TK a webhelyek listája, nem helyettesítheti a kommunikációt. Fontos, hogy megbizonyosodjon róla, hogy a csapat minden tagja megérti a közös célt, és nem csak feladatot végez a patakon. Ha valami érthetetlen - meg kell magyarázni, megvitatni, részletes megjegyzéseket adni.

Ha külföldi helyszíneken megy keresztül a "Termékkövetelmények dokumentum" kérésére, akkor megtalálhatja a kreatív és meggyőző cikkeket arról, hogy a technikai feladat (TK, PRD) meghalt. Részben meg kell állapodni - egy termék nulla termékének fejlesztésekor a prototípusok sokkal érdekesebbnek és hatékonyabbnak tűnnek, mint az ügyfél nyilvántartásainak mennyisége, néha nagyon szakszerűtlen. Ha azonban az alaprendszer finomításáról beszélünk, akkor teljesen más fordulatot igényel. A finomítással és az egyéni fejlesztéssel konfigurálva van, így a kutya megette a kutyát, ha a szakács nem hazudik nekünk. Általában ma - a megvásárolt és telepített szoftver finomítására írt leginkább klasszikus technikai feladatokról. Röviden, a fájó.

Az interakció oka

Mielőtt folytatná a technikai megbízás létrehozásának folyamatát, beszéljünk egy négygyűrűről, amelyben az előadó és az ügyfél a projektbe esik.

Követelmények- a végrehajtandó folyamat vagy a végrehajtandó folyamat birtokosa által leírt rendszer kívánt viselkedése. Általában a követelmények a munkatapasztalat alapján alakulnak ki, a program megfelelő viselkedésének bemutatása. Ezek kulcsfontosságú információk a fejlesztő (eladó) számára azonban a gyűjtési követelmények összegyűjtése, hogy a legnagyobb számú ütközés, hibák, szükségtelen kérések és így tovább.

Erőforrások - emberek, gépek, berendezések, fejlesztési környezet, idő és pénz, amelyet a követelmények végrehajtására használnak. Az erőforrások világos tervezést és értékelést igényelnek a műszaki feladat jóváhagyásának szakaszában. Az illetékes elhelyezése prioritások az ügyfél és a munkamegosztás erőforrások eladóval lehetővé teszi, hogy ne szakadjon el az időzítés és minimalizálják az egyéb kockázatokat.

Képességek - Ha röviden, akkor ez az, amit az eladó is megtehet (előadóművész). Tekintsük a Regionsoft CRM példájáról. Az ügyfél vásárol a rendszer, és teszi fel a munkát a finomítás: létre kell hoznia integrációt a helyszínen, és kötelező események CRM az online áruház rendelési számot. Ez egy igazán végrehajtott követelmény, van egy erőforrásunk és a lehetősége, hogy ezt tegye. És még mindig szükség van a CRM CMS-re, a webhely tartalomkezelő rendszerére. Elméletileg ezt lehetünk, de nem rendelkezünk lehetőséget arra, hogy olcsóvá tegyük, és az ügyfélnek nincs lehetősége arra, hogy annyit fizessen nekünk, hogy emberi és ideiglenes erőforrásokat dobjon a feladathoz. Ennek eredményeképpen az Ügyfél megtagadja ezt a követelményt - és a CMS nem különösebben szükséges, minden olyan jó. De a "kapzsiság" Tz-ról.

Korlátozás - Egy sor akadály, hogy hogy a feladatokat a TK nehéz vagy lehetetlen: költségvetés, verem a technológia, engedéllyel problémák, jogszabályi tilalom, hardver konfigurációk és így tovább.

Így mind a négy entitást szorosan összefonják egymás között, és meghatározzák a projekt sikerét. Fontolja meg az egyes elemeket, és próbálja kiemelni a kritikus pillanatokat, amelyekre szükséged van, hogy szem előtt tartsa a technikai feladatot.

A követelmények összegyűjtése és elemzése

Ez egy nagyon fontos belső vállalati folyamat, amely során kiderül, hogy a programból (itt, majd CRM-t, de módszereket dolgozunk, más típusú szoftverekkel) potenciális felhasználókkal. Ha kapcsolatba lép egy jelentősebb gyártó típusú SAP-val vagy rendszerintegrátorral, akkor a valószínűség nagy valószínűségével felajánlja az üzleti tanácsadó szolgáltatásait (ez egy személyes menedzser, ő a fiókkezelő, ő "most a cégünk képviselője "). Valójában a legtöbb esetben egy rendes kereskedett értékesítési piac, akinek két feladata van: a projekt költségeinek megfordítása, és nem hagyja, hogy szálljon le a horogról.

Már itt van egy óra, és még csak nem érinti a fehér jelzőtáblát. Ő nem valódi rendszerelemző

Jobb, mint te és az alkalmazottai, senki sem ismeri a cégét. Tehát a követelmények összegyűjtése és elemzése kizárólag az Ön feladata, amelyben az eladó segíthet és elküldhet, de semmiképpen sem tud beavatkozni a folyamatba. Kérje meg a fejlesztőt a hasonló implementációkról, ellenőrizze, hogy mit kell fizetnie, és folytassa. By the way, egy jó asszisztens lehet a munkavállaló, aki jól ismeri a profil témáját, és megközelítőleg a szoftver architektúráját és a fejlesztési folyamat jeleit képviseli - elemzőként és belső szakértőként működhet, hogy lezárja a létrehozás folyamatát TK és kommunikál a szállítóval.

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

1. Hozzon létre egy munkacsoportot a vezetőktől és a CRM-t használó egységek tapasztalt szakembereitől. Mondja el nekünk a megoldást, amelyet választani kell, hozzáférést biztosít a demo verzióhoz.
2. A munkacsoport tagjai tájékoztatást kell adniuk az alkalmazottaknak, és feltétlenül szabad formában kérik az új programot. Ha valaki az alkalmazottaktól soha nem találkozott ilyen szoftverrel, és nem áll készen arra, hogy a jövőbeni használat aspektusában beszéljen, meg kell kérdeznie, hogy írja le az időszakos feladatait, ez egy univerzális megközelítés.
3. Ezután minden egyes egységkészlet, amely nem CRM-ben van, vagy ami nem egyezik meg, és aggregálja az információkat.
4. A munkacsoport elemzi az összegyűjtött követelményeket, ellenőrzi és kiküszöböli a metszéspontot. Például gyakran az értékesítési osztály és a marketing részleget ugyanazon jelentés rendezi, de a követelmények különböző módon nevezhetők és entitásoknak nevezhetők, bár a mögöttes adatok ugyanazok. Ennek megfelelően egyetlen formába kell jönnie.
5. A munkacsoport létrehozza a követelmények listáját, és prioritást ad. Ebben a szakaszban csatlakozhat az eladó, mert felelős az erőforrásokért. Például, akkor kérheti, hogy hozzon létre egy egyéni jelentést RegionSoft CRM, és tudod, hogy az integráció az oldalon. Ez teljesen más a feladat szempontjából, a prioritás nagyon fontos itt.

Miután a követelmények összegyűjtése, elemzése és összehangolják az alkalmazottak és a menedzsment, akkor kezdeni egy technikai feladat. Megkérdezheti az eladó alakját, vagy önmagát teszi magának - minden esetben több vas-szabály van, amely megmenti a fejfájástól és Öntől, és a CRM szolgáltatójától.

A technikai feladat anatómiája

Ha beszélünk a technikai feladat létrehozásának folyamatáról, akkor több szakasz van. Következetes áthaladása, és az ügyfelet a kívánt finomításhoz vezeti. Itt vannak.

• Felderítés - követelmények meghatározása, hibaelhárítási problémák, amelyeket meg kell oldani.
• Elemzés - A követelmények, a kulcsfontosságú igények elosztása, általánosítása.
• Az alkalmazkodás a CRM képességek és a meglévő üzleti folyamatok összefüggésében a követelmények értékelése.
• Dokumentáció - A követelmények formális és részletes leírása, a TK koordinációja.
• A szállítóval folytatott kommunikáció (fejlesztő) egy iteratív kölcsönhatás a gyártónak a komponens TK szerinti javításokkal kapcsolatban.
• A végrehajtás az eladó munkája a szükséges funkcionalitás létrehozásáról. Jobb, ha az eladó folyamatosan kapcsolódik az ügyféllel - a kijáratnál a termék legpontosabban megfelel az ügyfél látásának.
• Vizsgálat - Az eladó munkatársainak, az ügyfél belső szakértőinek és a végfelhasználóknak a finomítás és a TK, a rendszer teljesítményének módosítása érdekében.

Általában a műszaki feladat lehet létrehozni a követelményei alapján a több szinten, amelyek metszik, és együtt, amikor a projekt létrehozása vagy nem lép kölcsönhatásba egyáltalán.

Üzleti szint- A globális szint, amelyen összetett és elsőbbségi feladatok megoldódnak. E szintre az üzleti folyamatok integrációja, finomítása és modellezése tulajdonítható, új funkcionális modulok fejlesztése. Rendszerint az erőforrás-intenzív fejlődés, komoly konzultációkkal és szoros együttműködéssel az ügyféllel. Például egy időben a RegionSoft CRM-ben az ilyen testreszabott felülvizsgálat raktár, jegyiroda és gyártás volt. Fokozatosan változások léptek a kiadás, majd hagyjuk, hogy hozzon létre egy új termék nagykereskedelmi, kiskereskedelmi üzletek és a hipermarketek - RegionSoft Retail.

Felhasználói szint vagy felhasználói csoport.Ezen a szinten a feladatokat a meglévő interfész felülvizsgálatán keresztül hajtják végre. Például a felhasználó azt akarta, hogy ha egy kurzort lebeg, egy ablak jelenik meg az utolsó megrendelés számával és állapotával, vagy egyéni jelentés volt egy speciális adatcsoportokkal. A finomító ezen a szinten kevesebb időt foglal magában, de sok közülük is - például a marketing osztály, a logisztika és a technikai támogatás számos követelménye.

A funkcionalitás szintje. Gyakran nehéz elválasztani az előzőből, a formális kritérium itt működik - a finomítás nem az interfészen való megjelenítés szintjén, hanem a rendszer logika finomítása szintjén. Ez magában foglalja a különböző válogatás követelményeit, az integrációkat csevegési, telefonos képességekkel.

Szolgálati szint - Tény, hogy ennek a szintnek a követelményei az elsőnek kell lenniük, hogy új építéseket kapjanak a javításokkal. Ezek a rendszer válaszának sebessége, a nagy terhelés, a biztonság érdekében. Az ideális változatban a Venndornak nem kell ilyen javulása - a vállalati szoftvernek nem szabad lelassulnia, elveszíti az adatokat, az egyszintű engedélyek eloszlatását és terjesztését. De ha megjelent a követelmény, és ez nem kapcsolódik az ügyfél személyes parátyájához vagy problémáihoz a hardver oldalán, érdemes nagy figyelmet fordítani rá.

Technológiai szint - Utoljára a listán, de a fontosság és a nehézség előtt a többi. Ezek lehetnek a platformhoz, operációs rendszerhez vagy eszközökhöz kapcsolódó vevői követelmények. Például a MacOS alatti összegyűlés gyűjteménye. Nagyon hűvös, ha az ilyen követelmények fokozatosan felszabadulnak, de szükségszerűen javítások vannak. Ezen a szinten az ügyfelek kéréseiből származik, a Macos alatt egy Asoft CRM összeszerelést készítettünk, és a TRM technológiát a ritka, de meglévő mobilverziójú átmeneti megoldásként töröltük a TRM technológiát.

A technikai feladat anatómiája egyszerű, bármilyen esetben csontváz formájában. A technikai feladat kötelező részei segítenek az ügyfélnek a problémára összpontosítani, és helyesen megfogalmazzák a feladatot, és a vállalkozót - megérteni, mit akarnak tőle. Az útközben, a megértésről. Természetesen a hozzászólás kezdetén kissé túlélte, és az üzleti tanácsadókat osztályként tagadta. Ez az, amit: Minden gyártó működik a piacon több éve (nem vagyunk körülbelül CRM-egy nap), hanem a tizenkét év, ami azt jelenti, hogy egy sor esetben szinte minden iparágban. Ennek megfelelően a mérnökök, a programozók és az értékesítés ismeri a végrehajtás sajátosságait minden egyes cégtípusban. De ismét fontos, hogy a vállalkozásodra összpontosítson.

Kinek?Ebben a részben le kell írni, hogy ki lesz a finomítás véges felhasználója, milyen feladatokat és milyen gyakoriságot terveznek megoldani.

Adok egy példát. Ugyanabban a vállalatban bevezették a CRM-t, azt feltételezték, hogy meglehetősen nagy adatgyűjtéssel dolgozunk (több tízmillió rekord havonta, naponta több százezer rekordot). Az Értékesítési Osztály vezetője jelentést kért a rekordok kirakodásáról a "Daily" gyakorisággal. Természetesen egy ilyen jelentés egyidejűleg több száz felhasználó betöltötte a rendszert - döntéseket találtak a folyamat optimalizálására. Már a munka során kiderült, hogy az értékesítést újjáépítették, és a jelentést csak a hónap eredményeire kell szükség, majd éjszaka menetrendre indíthatják. Érdemes megmondani, hogy az idő és a pénz hiába költött.

Minek?Indokolás A finomítás szükségességét és helyét az üzleti folyamatban. Ez az elem magasabb az ügyfélnek, hanem az eladó is, hogy tudja, milyen más folyamatok érintettek. Néha segít megtalálni az alternatív megoldást.

Mit kell tennie?A leginkább informatívabb blokk - leírja a követelményeket, a rendszer elvárásait. És itt, a gyöngyök, csodák és ütközések, akik a bashomg-ba jönnek, és amelyek az élet nagyon bonyolultak. Mert egy - a felhasználó nem tudja, mit akar tenni. Még mindig van egy kis alprogram - a felhasználó nem tudja megfogalmazni a követelményeket. És akkor a feladat a fejlesztő (munkacsoport, elemzések, ha vannak ilyenek) segítségével megfogalmazzuk, hogy szükség van valódi, válasszon egy célszerű követelmény, adja meg a feladat keretében a rendszer. Ugyanebben a blokkban meg kell említeni a várt eredményt.

A technikai feladat paraméterei- feltételek, végrehajtás szakaszai, minden oldalról, a szükséges kapcsolatok és így tovább. Valójában ez egy olyan fontos formális dolgok kombinációja, amelyek technikai feladattal rendelkeznek egy dokumentumot. A technikai feladatot szükségszerűen összehangolják és aláírják a felek, hogy elkerüljék a fejlődés fejlődésének számos változást (továbbra is, de kisebb volumenben).

Az ideális verzióban a technikai feladatot az eladó aktív részvételével állítják össze, és összesen megközelítőleg egy ilyen szerkezet:

1. Az egyes mechanizmusok és az egyes funkciók követelményeinek leírása
2. A funkcionalitás megvalósításának leírása
3. Az egyes lépésekre vonatkozó munka költsége külön
4. A műszaki feladatok teljes költsége
5. A munkák végrehajtásának feltételei a színpadok lebontásával és a jelenet feltüntetésével
6. A telepítési feltételek és a tesztelés leírása
7. Fenntartások a technikai feladat és egyéb feltételek kimerítő jellegével kapcsolatban

10 a fejlesztő könnyei által írt szabályok

A finomításra vonatkozó technikai feladatnak a TK-nak kell lennie a finomításról, nem a CRM 300 oldalas leírása, amely az ügyfélhez szükséges. A követelmények kidolgozása előtt gondosan olvassa el a rendszer felületét, képességeit, dokumentációját - valószínűleg a legtöbb "kívánságlistát" már az alapellátásban van. Azt javaslom, hogy figyeljen a beépített finomítási eszközökre (jelentés tervezők, konfigurátorok stb.) - Talán a szükséges változások képesek lesznek rendszeres programozó (sok vállalatban).

A technikai feladat nem lehet mohó.Gyakran az üzleti túlbecsüli képességeit, vagy azt akarja, hogy "mindent azonnal". Az ilyen megközelítés nem indokolt a pénz vagy az üzleti szempontból. Eladó, mint általában nincs pár hetes (RegionSoft esetében - 15 év), és kapcsolatba léphet vele, és egy idő után tényleg megértheti, hogy a CRM-nek hiányzik.

A redundancia fényes példája szó szerint tegnap: az ügyfél megvásárolta az ERP egy híres orosz cég, azt gondolva, hogy a számviteli számviteli számvitel, akkor az ERP e szállító lesz jó. Az ERP nem volt annyira annyira, de nem megfelelő üzlet. De a REGIONSOFT CRM raktári számítással és termeléssel alkalmas. Van egy megoldás: elfelejteni az ERP-t, sírni, integrálja az 1c számvitelt egy új CRM-vel, és örül egy kényelmes megvalósításban. De a swatchless pénz szánalmas! És az ügyfél megköveteli a CRM integrációját az ERP-vel. Ezt nem tette meg, de miért ilyen hulladék, miért két viszonylag hasonló rendszer?

A technikai feladatnak reálisnak és teljesnek kell lennie - Mind a követelmények, mind az idő szerint. Fontos, hogy meghallgassuk az eladó véleményét, amint azt pontosan tudja, hogy mikor megy egy vagy egy másik feladat. Hidd el nekem, a fejlesztő nem nyereséges ahhoz, hogy húzza az időt és a szélet a kifejezésre - nyereséges ahhoz, hogy minél több projektet töltsön be, és hogy jól hozza meg, hogy ne fogadjon el a hírnevet. Ami a realizmust illeti, ne kerülje el a CRM-t az összeomtató-menedzsment rendszer szintjére való befejezéséhez, egyszerűen: azt kell bevonnia a folyamatban, ami valóban szükséges a jelenleg és a belátható jövőben.

Például a RegionSoft CRM asztali program, nincs böngésző ügyfele. Kérje meg minket, hogy hozzon létre egy webes alkalmazást egy vállalat számára értelmetlen, ez egy nagy fejlődés, most már folytatódik, és nem lehet finomítani egy vállalat számára. Nem, természetesen minden áron van, de ismét - általában - a követelmény szüntelen.

Nem kell összetéveszteni a helyzetet a szokásos fejlesztés során, és az alkalmazás ötlete és logikája megváltozik a gyökérben, egy új szoftver "önmagad" létrehozása gyakorlatilag egy új szoftver létrehozása. De ez egy másik történet.

A technikai feladatot részletezni kell. Meg kell adnia a jövőbeni projekt összes jelentős részletét: a program használatának gyakoriságától az interfész kívánságainak. Minél több követelményt állapítanak meg, a könnyebb és gyorsabb lesz végrehajtásra és tesztelésre. Különösen érdemes odafigyelni a részletekre, ha a munka egy adott ágazat (gyógyszer, biztosítás, bank) - részletes kimutatást az árnyalatok üzleti kapcsolatból és a program biztosítani fogja, hogy értik a feladatot, az eladó és a gyors alkalmazkodást a rendszernek a vállalatnak.

Ügyeljen arra, hogy figyeljen a számok formátumára, a mezők nevére, a legördülő listák jelenlétére vagy hiányára, a gombok és a tippek, az adattípusok viselkedésére. Ha az ügyfél saját formuláit használja, amelyet a CRM munkájának logikájában kell elhelyezni ( például a kereskedési bónuszok kiszámítása) Ezeket a képleteket meg kell határozni a megjelölések teljes dekódolásával és a számítási logikával.

Igen, a vállalati szoftver úgy néz ki, mint ez, és benne sok fontos trifles van

A technikai feladatnak egyértelműnek és pontosnak kell lennie. Elmosódott megfogalmazás, végrehajtási lehetőségek, fuzzy követelmények - mindezt halott végén. Ez megtörténik, hogy a jó szándékú ügyfél több lehetőséget ír a rendszer viselkedésére, közel, de nem egyenértékű a TP-vel. Ebben az esetben, ő biztos, hogy segít, mondja a programozó, de valójában, a jó szándék a pokolba vezető út A fejlesztő meg kell értenie, hogy pontosan mi van szüksége, és hogyan kell csinálni fog választani magának, tulajdonságai alapján a a használt technológiák rendszere és verem.

Ebben az évben újra adhatsz egy vágyat. Csak, ne pazarolja el azt, hogy még nem tudom teljesíteni, mint az érthető üzleti követelmények!

A technikai feladatot az emberi nyelven kell írni. És ez fontos, nem, fontos. Két helyzetet fogok felosztani, amikor a nyelvvel kapcsolatos problémák a projekt végrehajtásának szigorításához vezetnek.

1. Az Ügyfél megpróbálja bemutatni a technikai műveltségét és éget a típus típusát: "Egy ablak végrehajtása a naptár testébe, amelynek lehetősége van arra, hogy hívjon egy eseményhíváshoz ..." A naptárban " felbukkan egy ablakot, amelyben a feladatot elvégezheti. " Ha Ön vagy belső szakértője nem rendelkezik a technikai szövegek írásának készségeivel, ne a Google-t - írjon szokásos szavaknak, megértjük őket.

   A technikai feladat nem lehet panaszos könyv. Meg kell oldani a problémát, és nem írja le, figyelve a betűtípusokat, és elfelejtve a követelmények leírását. A TK-nak nemcsak maga a problémát kell tartalmaznia, hanem a megértés szintjén is - a fejlesztő már a kódszinten eldönti. Összehasonlítás "Értékesítési osztály tervek rosszul veszítenek számokat, már évente harcolnak" és "Hozzon létre egy jelentést, amely megtartja a terv értékeit és az értékesítési tényt, a nómenklatúra csoportjainak összefüggésében".

   A technikai feladatnak képesnek kell lennie arra, hogy megvizsgálja a jövőt.Nos, nem egészen, de az emberek mögötte állnak. Ha ismert, hogy hamarosan változások fordulnak elő az üzleti folyamatokban, figyelembe kell venni, hogy ne fizessen a felülvizsgálatért kétszer.

   A technikai feladat nem lehet bürokratikus. Ha legalább egyszer megegyezik ezt a dokumentumot, akkor valószínűleg úgy érezte, hogy milyen nehéz elkerülni a kísértést a bürokráciába, hogy elhalványuljon a belső szavakba, szigorú forradalmakba, és minden egyes elemet a büntető törvénykönyv (lehetőleg büntetném) mindenki megsértéséért). A bürokratikus megfogalmazások a TK létrehozásának célkitűzéseinek hiányos megértését maszkolják. Az eladó felelőssége a szerződésben szerepel, a költségvetés ott van. Ne hordozza ezeket a pontokat a technikai feladatban.

   A technikai feladatnak technikai feladatnak kell lennie. Paradox, de gyakran a TK helyett levéleket, panaszokat, szerződéseket, újra írott utasításokat olvasunk az ülés CRM-jére vagy percében. Természetesen lehetetlen dolgozni egy ilyen dokumentumban. Annak érdekében, hogy ne menjen el az űrlaptól és a tartalomtól, használja a régi iskolai trükköt: fontolja meg a kifejezést. Technikai - ez azt jelenti, hogy a finomítás diktált, a technika célja a probléma megváltoztatása a szoftver megváltoztatásával. Ez a feladat a szoftver kontextusában, és beszélnie kell. A feladat azt jelenti, hogy a kérdés, a problémák, tippek, tippek és előzetes becslések nélkül. Csak szöveges feladat.

   A parancsolatok véget értek, most jutalom

   A felsorolt \u200b\u200bszabályok mellett több dolog van, amelyekről érdemes megmondani. Beszélünk a célokról, tervekről és elvárásokról - mindazokról, akik elhagyják, amelyek a projektet sikeresek, és az eladó és az ügyfél kapcsolatai szinte barátságosak.

   Technikai feladat, amit gyorsan meg kell írniaMég ha feladata, hogy automatizálja a mobilszolgáltató vagy egy nagy hipermarket folyamatát. Ez annak a ténynek köszönhető, hogy a technológiák fejlődnek egy hatalmas sebesség és még a rendszer, amit hajtanak végre, hat hónapig, egy évig képes túlélni egy nagyobb kiadás (és néha kettő), hogy az új funkciókat. Talán meg kell vizsgálnod, hogy újra kell javítani és újra elindítani a folyamatot.

   

   
   Végül időt talált arra, hogy befejezze a TK-t. De sajnos, nincsenek fejlesztők ott, hogy végrehajtsák.

   Az ügyfél nem tudja a verem és a technikai korlátokról.És nem tudja - Ez az eladó feladata, aki a műszaki feladat összeállítása után értékeli a munkát. Az ügyfelet nem szabad elmélyíteni a technológiában, és megkérdezni minden vesszőt, ha az eladó egy vagy egy másik dolgot tehet. Tegyen átfogó TK és a fejlesztő kiválasztja a megfelelő építészetet - gyakran még jobb, mint gondolnád.

   Értékelje a költségvetést, és elkerülje a kellemetlen meglepetéseket - Majdnem közös feladat az első. NEM kell forgatnia az értékesítőt, és keresse meg a munka hozzávetőleges értékelését (nos, legalábbis az üreg, a szemen, és mint mások, jól, az ilyen típusú projektekben, valamint tapasztalaton belül, A hiba korlátai). A teljes költségvetési értékelés csak a technikai feladat olvasása, elemzése és végleges jóváhagyása után lehetséges. Ha a fejlesztő másképp jön - készen áll arra, hogy a finomítás legalább kétszer olyan drága lesz.

   Folytassa a változások és kiterjesztések objektív szükségességét - Azt írtam, hogy a fejlesztő nem tűnik el, és készen áll arra, hogy bármikor módosítsa és kiegészíti az Ön igényeit. Ezért ne próbálja meg létrehozni CRM / ERP álmok azonnal, nem igényel a gomb „Minden működik, amíg kávét iszom” - munka a rendszer határozza meg a megjegyzéseket kritikus számodra, és folytassa a gyűjtemény követelmények és összeállításának TK .

   A technikai feladatokról végtelenül írhatunk, ez egy igazi generátor nemcsak a mémek és a kickek, hanem fejfájás is. Beszélhet a Prioritásokról és a nyilvántartásba vételre vonatkozó szabályokról, a Vendégről 1989-ben, amely a TZ embertelen, az IEEE szabványokról szól, amelyek egy kicsit jobbak, a prototípusokról és a kiegészítő TK-ról. De a végén szeretnék korlátozni magunkat, a legfontosabb szabályt: a technikai feladat nem a törvény normája, nem pedig a gost és nem dogma, ezért, ha javíthat - javulhat, egyszerűsítheti, elegánsan teszi lehetővé, hogy lehetővé tegye. Biztos vagyok benne, hogy senki sem nyomja meg az orrát a TK-ben, és nem fogja azt mondani, hogy nincs ott írva. Vagy szinte senki.

   Minden december adunk kedvezményeket a RegionSoft CRM-ről és a saját fejlesztésünk egész szoftveréről. December 1-től 15-ig - 15% és meredek feltételei és bérlet. Nincs -70% -a és -90%, mert megtartjuk a gazdaságilag ésszerű árat az engedélyekért, és nem veszjük el a mennyezetről.

   Nos, ha szüksége van egy CRM rendszerre (finomítással vagy nélkül), akkor gyere be a honlapunk Sokat jelentenek a CRM-ről, előnyeiről és más vállalati szoftveréről.

   És igen, mi mindig keres partnereket, akik készek eladni CRM és egyéb termékek, finomított és eladni CRM, eladni szoftver és tanítsa felhasználók. A jövedelem megosztása őszinte és nyereséges partner. Megmutatjuk, mondd meg, tanítunk. Írni [E-mail védett]

   Diák, diákok. A http://www.modernanalyst.com/ és a Pinterest által vett képregények. Ha jobb fordítás van - örömmel fogjuk tenni a posztban.

Ha külföldi helyszíneken megy keresztül a "Termékkövetelmények dokumentum" kérésére, akkor megtalálhatja a kreatív és meggyőző cikkeket arról, hogy a technikai feladat (TK, PRD) meghalt. Részben meg kell állapodni - egy termék nulla termékének fejlesztésekor a prototípusok sokkal érdekesebbnek és hatékonyabbnak tűnnek, mint az ügyfél nyilvántartásainak mennyisége, néha nagyon szakszerűtlen. Ha azonban az alaprendszer finomításáról beszélünk, akkor teljesen más fordulatot igényel. A finomítással és az egyéni fejlesztéssel konfigurálva van, így a kutya megette a kutyát, ha a szakács nem hazudik nekünk. Általában ma - a megvásárolt és telepített szoftver finomítására írt leginkább klasszikus technikai feladatokról. Röviden, a fájó.

Az interakció oka

Mielőtt folytatná a technikai megbízás létrehozásának folyamatát, beszéljünk egy négygyűrűről, amelyben az előadó és az ügyfél a projektbe esik.

Követelmények- a végrehajtandó folyamat vagy a végrehajtandó folyamat birtokosa által leírt rendszer kívánt viselkedése. Általában a követelmények a munkatapasztalat alapján alakulnak ki, a program megfelelő viselkedésének bemutatása. Ezek kulcsfontosságú információk a fejlesztő (eladó) számára azonban a gyűjtési követelmények összegyűjtése, hogy a legnagyobb számú ütközés, hibák, szükségtelen kérések és így tovább.

Erőforrások - emberek, gépek, berendezések, fejlesztési környezet, idő és pénz, amelyet a követelmények végrehajtására használnak. Az erőforrások világos tervezést és értékelést igényelnek a műszaki feladat jóváhagyásának szakaszában. Az illetékes elhelyezése prioritások az ügyfél és a munkamegosztás erőforrások eladóval lehetővé teszi, hogy ne szakadjon el az időzítés és minimalizálják az egyéb kockázatokat.

Képességek - Ha röviden, akkor ez az, amit az eladó is megtehet (előadóművész). Tekintsük a Regionsoft CRM példájáról. Az ügyfél vásárol a rendszer, és teszi fel a munkát a finomítás: létre kell hoznia integrációt a helyszínen, és kötelező események CRM az online áruház rendelési számot. Ez egy igazán végrehajtott követelmény, van egy erőforrásunk és a lehetősége, hogy ezt tegye. És még mindig szükség van a CRM CMS-re, a webhely tartalomkezelő rendszerére. Elméletileg ezt lehetünk, de nem rendelkezünk lehetőséget arra, hogy olcsóvá tegyük, és az ügyfélnek nincs lehetősége arra, hogy annyit fizessen nekünk, hogy emberi és ideiglenes erőforrásokat dobjon a feladathoz. Ennek eredményeképpen az Ügyfél megtagadja ezt a követelményt - és a CMS nem különösebben szükséges, minden olyan jó. De a "kapzsiság" Tz-ról.

Korlátozás - Egy sor akadály, hogy hogy a feladatokat a TK nehéz vagy lehetetlen: költségvetés, verem a technológia, engedéllyel problémák, jogszabályi tilalom, hardver konfigurációk és így tovább.

Így mind a négy entitást szorosan összefonják egymás között, és meghatározzák a projekt sikerét. Fontolja meg az egyes elemeket, és próbálja kiemelni a kritikus pillanatokat, amelyekre szükséged van, hogy szem előtt tartsa a technikai feladatot.

A követelmények összegyűjtése és elemzése

Ez egy nagyon fontos belső vállalati folyamat, amely során kiderül, hogy a programból (itt, majd CRM-t, de módszereket dolgozunk, más típusú szoftverekkel) potenciális felhasználókkal. Ha kapcsolatba lép egy jelentősebb gyártó típusú SAP-val vagy rendszerintegrátorral, akkor a valószínűség nagy valószínűségével felajánlja az üzleti tanácsadó szolgáltatásait (ez egy személyes menedzser, ő a fiókkezelő, ő "most a cégünk képviselője "). Valójában a legtöbb esetben egy rendes kereskedett értékesítési piac, akinek két feladata van: a projekt költségeinek megfordítása, és nem hagyja, hogy szálljon le a horogról.

Már itt van egy óra, és még csak nem érinti a fehér jelzőtáblát. Ő nem valódi rendszerelemző

Jobb, mint te és az alkalmazottai, senki sem ismeri a cégét. Tehát a követelmények összegyűjtése és elemzése kizárólag az Ön feladata, amelyben az eladó segíthet és elküldhet, de semmiképpen sem tud beavatkozni a folyamatba. Kérje meg a fejlesztőt a hasonló implementációkról, ellenőrizze, hogy mit kell fizetnie, és folytassa. By the way, egy jó asszisztens lehet a munkavállaló, aki jól ismeri a profil témáját, és megközelítőleg a szoftver architektúráját és a fejlesztési folyamat jeleit képviseli - elemzőként és belső szakértőként működhet, hogy lezárja a létrehozás folyamatát TK és kommunikál a szállítóval.

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

1. Hozzon létre egy munkacsoportot a vezetőktől és a CRM-t használó egységek tapasztalt szakembereitől. Mondja el nekünk a megoldást, amelyet választani kell, hozzáférést biztosít a demo verzióhoz.
2. A munkacsoport tagjai tájékoztatást kell adniuk az alkalmazottaknak, és feltétlenül szabad formában kérik az új programot. Ha valaki az alkalmazottaktól soha nem találkozott ilyen szoftverrel, és nem áll készen arra, hogy a jövőbeni használat aspektusában beszéljen, meg kell kérdeznie, hogy írja le az időszakos feladatait, ez egy univerzális megközelítés.
3. Ezután minden egyes egységkészlet, amely nem CRM-ben van, vagy ami nem egyezik meg, és aggregálja az információkat.
4. A munkacsoport elemzi az összegyűjtött követelményeket, ellenőrzi és kiküszöböli a metszéspontot. Például gyakran az értékesítési osztály és a marketing részleget ugyanazon jelentés rendezi, de a követelmények különböző módon nevezhetők és entitásoknak nevezhetők, bár a mögöttes adatok ugyanazok. Ennek megfelelően egyetlen formába kell jönnie.
5. A munkacsoport létrehozza a követelmények listáját, és prioritást ad. Ebben a szakaszban csatlakozhat az eladó, mert felelős az erőforrásokért. Például, akkor kérheti, hogy hozzon létre egy egyéni jelentést RegionSoft CRM, és tudod, hogy az integráció az oldalon. Ez teljesen más a feladat szempontjából, a prioritás nagyon fontos itt.

Miután a követelmények összegyűjtése, elemzése és összehangolják az alkalmazottak és a menedzsment, akkor kezdeni egy technikai feladat. Megkérdezheti az eladó alakját, vagy önmagát teszi magának - minden esetben több vas-szabály van, amely megmenti a fejfájástól és Öntől, és a CRM szolgáltatójától.

A technikai feladat anatómiája

Ha beszélünk a technikai feladat létrehozásának folyamatáról, akkor több szakasz van. Következetes áthaladása, és az ügyfelet a kívánt finomításhoz vezeti. Itt vannak.

• Felderítés - követelmények meghatározása, hibaelhárítási problémák, amelyeket meg kell oldani.
• Elemzés - A követelmények, a kulcsfontosságú igények elosztása, általánosítása.
• Az alkalmazkodás a CRM képességek és a meglévő üzleti folyamatok összefüggésében a követelmények értékelése.
• Dokumentáció - A követelmények formális és részletes leírása, a TK koordinációja.
• A szállítóval folytatott kommunikáció (fejlesztő) egy iteratív kölcsönhatás a gyártónak a komponens TK szerinti javításokkal kapcsolatban.
• A végrehajtás az eladó munkája a szükséges funkcionalitás létrehozásáról. Jobb, ha az eladó folyamatosan kapcsolódik az ügyféllel - a kijáratnál a termék legpontosabban megfelel az ügyfél látásának.
• Vizsgálat - Az eladó munkatársainak, az ügyfél belső szakértőinek és a végfelhasználóknak a finomítás és a TK, a rendszer teljesítményének módosítása érdekében.

Általában a műszaki feladat lehet létrehozni a követelményei alapján a több szinten, amelyek metszik, és együtt, amikor a projekt létrehozása vagy nem lép kölcsönhatásba egyáltalán.

Üzleti szint- A globális szint, amelyen összetett és elsőbbségi feladatok megoldódnak. E szintre az üzleti folyamatok integrációja, finomítása és modellezése tulajdonítható, új funkcionális modulok fejlesztése. Rendszerint az erőforrás-intenzív fejlődés, komoly konzultációkkal és szoros együttműködéssel az ügyféllel. Például egy időben a RegionSoft CRM-ben az ilyen testreszabott felülvizsgálat raktár, jegyiroda és gyártás volt. Fokozatosan változások léptek a kiadás, majd hagyjuk, hogy hozzon létre egy új termék nagykereskedelmi, kiskereskedelmi üzletek és a hipermarketek - RegionSoft Retail.

Felhasználói szint vagy felhasználói csoport.Ezen a szinten a feladatokat a meglévő interfész felülvizsgálatán keresztül hajtják végre. Például a felhasználó azt akarta, hogy ha egy kurzort lebeg, egy ablak jelenik meg az utolsó megrendelés számával és állapotával, vagy egyéni jelentés volt egy speciális adatcsoportokkal. A finomító ezen a szinten kevesebb időt foglal magában, de sok közülük is - például a marketing osztály, a logisztika és a technikai támogatás számos követelménye.

A funkcionalitás szintje. Gyakran nehéz elválasztani az előzőből, a formális kritérium itt működik - a finomítás nem az interfészen való megjelenítés szintjén, hanem a rendszer logika finomítása szintjén. Ez magában foglalja a különböző válogatás követelményeit, az integrációkat csevegési, telefonos képességekkel.

Szolgálati szint - Tény, hogy ennek a szintnek a követelményei az elsőnek kell lenniük, hogy új építéseket kapjanak a javításokkal. Ezek a rendszer válaszának sebessége, a nagy terhelés, a biztonság érdekében. Az ideális változatban a Venndornak nem kell ilyen javulása - a vállalati szoftvernek nem szabad lelassulnia, elveszíti az adatokat, az egyszintű engedélyek eloszlatását és terjesztését. De ha megjelent a követelmény, és ez nem kapcsolódik az ügyfél személyes parátyájához vagy problémáihoz a hardver oldalán, érdemes nagy figyelmet fordítani rá.

Technológiai szint - Utoljára a listán, de a fontosság és a nehézség előtt a többi. Ezek lehetnek a platformhoz, operációs rendszerhez vagy eszközökhöz kapcsolódó vevői követelmények. Például a MacOS alatti összegyűlés gyűjteménye. Nagyon hűvös, ha az ilyen követelmények fokozatosan felszabadulnak, de szükségszerűen javítások vannak. Ezen a szinten az ügyfelek kéréseiből származik, a Macos alatt egy Asoft CRM összeszerelést készítettünk, és a TRM technológiát a ritka, de meglévő mobilverziójú átmeneti megoldásként töröltük a TRM technológiát.

A technikai feladat anatómiája egyszerű, bármilyen esetben csontváz formájában. A technikai feladat kötelező részei segítenek az ügyfélnek a problémára összpontosítani, és helyesen megfogalmazzák a feladatot, és a vállalkozót - megérteni, mit akarnak tőle. Az útközben, a megértésről. Természetesen a hozzászólás kezdetén kissé túlélte, és az üzleti tanácsadókat osztályként tagadta. Ez az, amit: Minden gyártó működik a piacon több éve (nem vagyunk körülbelül CRM-egy nap), hanem a tizenkét év, ami azt jelenti, hogy egy sor esetben szinte minden iparágban. Ennek megfelelően a mérnökök, a programozók és az értékesítés ismeri a végrehajtás sajátosságait minden egyes cégtípusban. De ismét fontos, hogy a vállalkozásodra összpontosítson.

Kinek?Ebben a részben le kell írni, hogy ki lesz a finomítás véges felhasználója, milyen feladatokat és milyen gyakoriságot terveznek megoldani.

Adok egy példát. Ugyanabban a vállalatban bevezették a CRM-t, azt feltételezték, hogy meglehetősen nagy adatgyűjtéssel dolgozunk (több tízmillió rekord havonta, naponta több százezer rekordot). Az Értékesítési Osztály vezetője jelentést kért a rekordok kirakodásáról a "Daily" gyakorisággal. Természetesen egy ilyen jelentés egyidejűleg több száz felhasználó betöltötte a rendszert - döntéseket találtak a folyamat optimalizálására. Már a munka során kiderült, hogy az értékesítést újjáépítették, és a jelentést csak a hónap eredményeire kell szükség, majd éjszaka menetrendre indíthatják. Érdemes megmondani, hogy az idő és a pénz hiába költött.

Minek?Indokolás A finomítás szükségességét és helyét az üzleti folyamatban. Ez az elem magasabb az ügyfélnek, hanem az eladó is, hogy tudja, milyen más folyamatok érintettek. Néha segít megtalálni az alternatív megoldást.

Mit kell tennie?A leginkább informatívabb blokk - leírja a követelményeket, a rendszer elvárásait. És itt, a gyöngyök, csodák és ütközések, akik a bashomg-ba jönnek, és amelyek az élet nagyon bonyolultak. Mert egy - a felhasználó nem tudja, mit akar tenni. Még mindig van egy kis alprogram - a felhasználó nem tudja megfogalmazni a követelményeket. És akkor a feladat a fejlesztő (munkacsoport, elemzések, ha vannak ilyenek) segítségével megfogalmazzuk, hogy szükség van valódi, válasszon egy célszerű követelmény, adja meg a feladat keretében a rendszer. Ugyanebben a blokkban meg kell említeni a várt eredményt.

A technikai feladat paraméterei- feltételek, végrehajtás szakaszai, minden oldalról, a szükséges kapcsolatok és így tovább. Valójában ez egy olyan fontos formális dolgok kombinációja, amelyek technikai feladattal rendelkeznek egy dokumentumot. A technikai feladatot szükségszerűen összehangolják és aláírják a felek, hogy elkerüljék a fejlődés fejlődésének számos változást (továbbra is, de kisebb volumenben).

Az ideális verzióban a technikai feladatot az eladó aktív részvételével állítják össze, és összesen megközelítőleg egy ilyen szerkezet:

1. Az egyes mechanizmusok és az egyes funkciók követelményeinek leírása
2. A funkcionalitás megvalósításának leírása
3. Az egyes lépésekre vonatkozó munka költsége külön
4. A műszaki feladatok teljes költsége
5. A munkák végrehajtásának feltételei a színpadok lebontásával és a jelenet feltüntetésével
6. A telepítési feltételek és a tesztelés leírása
7. Fenntartások a technikai feladat és egyéb feltételek kimerítő jellegével kapcsolatban

10 a fejlesztő könnyei által írt szabályok

A finomításra vonatkozó technikai feladatnak a TK-nak kell lennie a finomításról, nem a CRM 300 oldalas leírása, amely az ügyfélhez szükséges. A követelmények kidolgozása előtt gondosan olvassa el a rendszer felületét, képességeit, dokumentációját - valószínűleg a legtöbb "kívánságlistát" már az alapellátásban van. Azt javaslom, hogy figyeljen a beépített finomítási eszközökre (jelentés tervezők, konfigurátorok stb.) - Talán a szükséges változások képesek lesznek rendszeres programozó (sok vállalatban).

A technikai feladat nem lehet mohó.Gyakran az üzleti túlbecsüli képességeit, vagy azt akarja, hogy "mindent azonnal". Az ilyen megközelítés nem indokolt a pénz vagy az üzleti szempontból. Eladó, mint általában nincs pár hetes (RegionSoft esetében - 15 év), és kapcsolatba léphet vele, és egy idő után tényleg megértheti, hogy a CRM-nek hiányzik.

A redundancia fényes példája szó szerint tegnap: az ügyfél megvásárolta az ERP egy híres orosz cég, azt gondolva, hogy a számviteli számviteli számvitel, akkor az ERP e szállító lesz jó. Az ERP nem volt annyira annyira, de nem megfelelő üzlet. De a REGIONSOFT CRM raktári számítással és termeléssel alkalmas. Van egy megoldás: elfelejteni az ERP-t, sírni, integrálja az 1c számvitelt egy új CRM-vel, és örül egy kényelmes megvalósításban. De a swatchless pénz szánalmas! És az ügyfél megköveteli a CRM integrációját az ERP-vel. Ezt nem tette meg, de miért ilyen hulladék, miért két viszonylag hasonló rendszer?

A technikai feladatnak reálisnak és teljesnek kell lennie - Mind a követelmények, mind az idő szerint. Fontos, hogy meghallgassuk az eladó véleményét, amint azt pontosan tudja, hogy mikor megy egy vagy egy másik feladat. Hidd el nekem, a fejlesztő nem nyereséges ahhoz, hogy húzza az időt és a szélet a kifejezésre - nyereséges ahhoz, hogy minél több projektet töltsön be, és hogy jól hozza meg, hogy ne fogadjon el a hírnevet. Ami a realizmust illeti, ne kerülje el a CRM-t az összeomtató-menedzsment rendszer szintjére való befejezéséhez, egyszerűen: azt kell bevonnia a folyamatban, ami valóban szükséges a jelenleg és a belátható jövőben.

Például a RegionSoft CRM asztali program, nincs böngésző ügyfele. Kérje meg minket, hogy hozzon létre egy webes alkalmazást egy vállalat számára értelmetlen, ez egy nagy fejlődés, most már folytatódik, és nem lehet finomítani egy vállalat számára. Nem, természetesen minden áron van, de ismét - általában - a követelmény szüntelen.

Nem kell összetéveszteni a helyzetet a szokásos fejlesztés során, és az alkalmazás ötlete és logikája megváltozik a gyökérben, egy új szoftver "önmagad" létrehozása gyakorlatilag egy új szoftver létrehozása. De ez egy másik történet.

A technikai feladatot részletezni kell. Meg kell adnia a jövőbeni projekt összes jelentős részletét: a program használatának gyakoriságától az interfész kívánságainak. Minél több követelményt állapítanak meg, a könnyebb és gyorsabb lesz végrehajtásra és tesztelésre. Különösen érdemes odafigyelni a részletekre, ha a munka egy adott ágazat (gyógyszer, biztosítás, bank) - részletes kimutatást az árnyalatok üzleti kapcsolatból és a program biztosítani fogja, hogy értik a feladatot, az eladó és a gyors alkalmazkodást a rendszernek a vállalatnak.

Ügyeljen arra, hogy figyeljen a számok formátumára, a mezők nevére, a legördülő listák jelenlétére vagy hiányára, a gombok és a tippek, az adattípusok viselkedésére. Ha az ügyfél saját formuláit használja, amelyet a CRM munkájának logikájában kell elhelyezni ( például a kereskedési bónuszok kiszámítása) Ezeket a képleteket meg kell határozni a megjelölések teljes dekódolásával és a számítási logikával.

Igen, a vállalati szoftver úgy néz ki, mint ez, és benne sok fontos trifles van

A technikai feladatnak egyértelműnek és pontosnak kell lennie. Elmosódott megfogalmazás, végrehajtási lehetőségek, fuzzy követelmények - mindezt halott végén. Ez megtörténik, hogy a jó szándékú ügyfél több lehetőséget ír a rendszer viselkedésére, közel, de nem egyenértékű a TP-vel. Ebben az esetben, ő biztos, hogy segít, mondja a programozó, de valójában, a jó szándék a pokolba vezető út A fejlesztő meg kell értenie, hogy pontosan mi van szüksége, és hogyan kell csinálni fog választani magának, tulajdonságai alapján a a használt technológiák rendszere és verem.

Ebben az évben újra adhatsz egy vágyat. Csak, ne pazarolja el azt, hogy még nem tudom teljesíteni, mint az érthető üzleti követelmények!

A technikai feladatot az emberi nyelven kell írni. És ez fontos, nem, fontos. Két helyzetet fogok felosztani, amikor a nyelvvel kapcsolatos problémák a projekt végrehajtásának szigorításához vezetnek.

1. Az Ügyfél megpróbálja bemutatni a technikai műveltségét és éget a típus típusát: "Egy ablak végrehajtása a naptár testébe, amelynek lehetősége van arra, hogy hívjon egy eseményhíváshoz ..." A naptárban " felbukkan egy ablakot, amelyben a feladatot elvégezheti. " Ha Ön vagy belső szakértője nem rendelkezik a technikai szövegek írásának készségeivel, ne a Google-t - írjon szokásos szavaknak, megértjük őket.

   A technikai feladat nem lehet panaszos könyv. Meg kell oldani a problémát, és nem írja le, figyelve a betűtípusokat, és elfelejtve a követelmények leírását. A TK-nak nemcsak maga a problémát kell tartalmaznia, hanem a megértés szintjén is - a fejlesztő már a kódszinten eldönti. Összehasonlítás "Értékesítési osztály tervek rosszul veszítenek számokat, már évente harcolnak" és "Hozzon létre egy jelentést, amely megtartja a terv értékeit és az értékesítési tényt, a nómenklatúra csoportjainak összefüggésében".

   A technikai feladatnak képesnek kell lennie arra, hogy megvizsgálja a jövőt.Nos, nem egészen, de az emberek mögötte állnak. Ha ismert, hogy hamarosan változások fordulnak elő az üzleti folyamatokban, figyelembe kell venni, hogy ne fizessen a felülvizsgálatért kétszer.

   A technikai feladat nem lehet bürokratikus. Ha legalább egyszer megegyezik ezt a dokumentumot, akkor valószínűleg úgy érezte, hogy milyen nehéz elkerülni a kísértést a bürokráciába, hogy elhalványuljon a belső szavakba, szigorú forradalmakba, és minden egyes elemet a büntető törvénykönyv (lehetőleg büntetném) mindenki megsértéséért). A bürokratikus megfogalmazások a TK létrehozásának célkitűzéseinek hiányos megértését maszkolják. Az eladó felelőssége a szerződésben szerepel, a költségvetés ott van. Ne hordozza ezeket a pontokat a technikai feladatban.

   A technikai feladatnak technikai feladatnak kell lennie. Paradox, de gyakran a TK helyett levéleket, panaszokat, szerződéseket, újra írott utasításokat olvasunk az ülés CRM-jére vagy percében. Természetesen lehetetlen dolgozni egy ilyen dokumentumban. Annak érdekében, hogy ne menjen el az űrlaptól és a tartalomtól, használja a régi iskolai trükköt: fontolja meg a kifejezést. Technikai - ez azt jelenti, hogy a finomítás diktált, a technika célja a probléma megváltoztatása a szoftver megváltoztatásával. Ez a feladat a szoftver kontextusában, és beszélnie kell. A feladat azt jelenti, hogy a kérdés, a problémák, tippek, tippek és előzetes becslések nélkül. Csak szöveges feladat.

   A parancsolatok véget értek, most jutalom

   A felsorolt \u200b\u200bszabályok mellett több dolog van, amelyekről érdemes megmondani. Beszélünk a célokról, tervekről és elvárásokról - mindazokról, akik elhagyják, amelyek a projektet sikeresek, és az eladó és az ügyfél kapcsolatai szinte barátságosak.

   Technikai feladat, amit gyorsan meg kell írniaMég ha feladata, hogy automatizálja a mobilszolgáltató vagy egy nagy hipermarket folyamatát. Ez annak a ténynek köszönhető, hogy a technológiák fejlődnek egy hatalmas sebesség és még a rendszer, amit hajtanak végre, hat hónapig, egy évig képes túlélni egy nagyobb kiadás (és néha kettő), hogy az új funkciókat. Talán meg kell vizsgálnod, hogy újra kell javítani és újra elindítani a folyamatot.

   

   
   Végül időt talált arra, hogy befejezze a TK-t. De sajnos, nincsenek fejlesztők ott, hogy végrehajtsák.

   Az ügyfél nem tudja a verem és a technikai korlátokról.És nem tudja - Ez az eladó feladata, aki a műszaki feladat összeállítása után értékeli a munkát. Az ügyfelet nem szabad elmélyíteni a technológiában, és megkérdezni minden vesszőt, ha az eladó egy vagy egy másik dolgot tehet. Tegyen átfogó TK és a fejlesztő kiválasztja a megfelelő építészetet - gyakran még jobb, mint gondolnád.

   Értékelje a költségvetést, és elkerülje a kellemetlen meglepetéseket - Majdnem közös feladat az első. NEM kell forgatnia az értékesítőt, és keresse meg a munka hozzávetőleges értékelését (nos, legalábbis az üreg, a szemen, és mint mások, jól, az ilyen típusú projektekben, valamint tapasztalaton belül, A hiba korlátai). A teljes költségvetési értékelés csak a technikai feladat olvasása, elemzése és végleges jóváhagyása után lehetséges. Ha a fejlesztő másképp jön - készen áll arra, hogy a finomítás legalább kétszer olyan drága lesz.

   Folytassa a változások és kiterjesztések objektív szükségességét - Azt írtam, hogy a fejlesztő nem tűnik el, és készen áll arra, hogy bármikor módosítsa és kiegészíti az Ön igényeit. Ezért ne próbálja meg létrehozni CRM / ERP álmok azonnal, nem igényel a gomb „Minden működik, amíg kávét iszom” - munka a rendszer határozza meg a megjegyzéseket kritikus számodra, és folytassa a gyűjtemény követelmények és összeállításának TK .

   A technikai feladatokról végtelenül írhatunk, ez egy igazi generátor nemcsak a mémek és a kickek, hanem fejfájás is. Beszélhet a Prioritásokról és a nyilvántartásba vételre vonatkozó szabályokról, a Vendégről 1989-ben, amely a TZ embertelen, az IEEE szabványokról szól, amelyek egy kicsit jobbak, a prototípusokról és a kiegészítő TK-ról. De a végén szeretnék korlátozni magunkat, a legfontosabb szabályt: a technikai feladat nem a törvény normája, nem pedig a gost és nem dogma, ezért, ha javíthat - javulhat, egyszerűsítheti, elegánsan teszi lehetővé, hogy lehetővé tegye. Biztos vagyok benne, hogy senki sem nyomja meg az orrát a TK-ben, és nem fogja azt mondani, hogy nincs ott írva. Vagy szinte senki.

   Minden december adunk kedvezményeket a RegionSoft CRM-ről és a saját fejlesztésünk egész szoftveréről. December 1-től 15-ig - 15% és meredek feltételei és bérlet. Nincs -70% -a és -90%, mert megtartjuk a gazdaságilag ésszerű árat az engedélyekért, és nem veszjük el a mennyezetről.

   Nos, ha szüksége van egy CRM rendszerre (finomítással vagy nélkül), akkor gyere be a honlapunk Sokat jelentenek a CRM-ről, előnyeiről és más vállalati szoftveréről.

   És igen, mi mindig keres partnereket, akik készek eladni CRM és egyéb termékek, finomított és eladni CRM, eladni szoftver és tanítsa felhasználók. A jövedelem megosztása őszinte és nyereséges partner. Megmutatjuk, mondd meg, tanítunk. Írni [E-mail védett]

   Diák, diákok. A http://www.modernanalyst.com/ és a Pinterest által vett képregények. Ha jobb fordítás van - örömmel fogjuk tenni a posztban.

Annyira pontosan az 1C véglegesítésének technikai feladata, közvetlenül attól függ, hogy a fejlesztők előtt beállított feladatok megoldódnak-e. Ugyanakkor, amikor egy ilyen dokumentummal dolgozik, nehézségek vannak. A TK széles körű megértésében a normákat az automatizált rendszer (AC) létrehozása és fejlesztése során írják elő, valamint a munkahelyet. Ez magában foglalja a projekt elindítási szabványait is. A technikai feladat szerepének megértését a GOST 19.201-78 és 34.602-89. Sz. A dokumentum értékének egy másik értelmezése van, közelebb a gyakorlathoz.

Szerint a másik definíció szerint a műszaki feladat véglegesítésére 1C olyan dokumentum, amely szabályozza a célját és paramétereit a jövő rendszer, valamint a folyamat kidolgozása a dokumentáció és a listában. Az ilyen értelmezés lehetővé teszi számunkra, hogy figyelembe vegyük a programozók és az ügyfél érdekeit.

Mit kell tk?

Az 1c program fejlesztésére szolgáló technikai feladatot a vállalkozó hozta létre. De ez nem végez programozót, hanem elemzőt. Ez fontos pont, mivel a dokumentumot az ügyfél számára érthető nyelven kell kidolgozni, anélkül, hogy magasan specializált technikai feltételeket alkalmaznának. Ha figyelembe veszik az összes projekt árnyalatát, és az információkat helyesen definiálják, a TK összhangban van az ügyfelekkel. Elfogadása esetén a programozók csatlakoztatva vannak. Ugyanakkor a kívánt eredményt egyértelműen felvázolni kell a dokumentumban. Segít a fejlesztőknek helyesen helyezni a célt, és különböző szakaszokban ellenőrzik. Az 1c véglegesítéséről szóló technikai feladat előkészítésében is érdemes megfizetni a készítményeket. Azt kell követni, hogy kellően specifikusak lesznek, és nem vállalnak más értelmezéseket. Ez az első dolog, amit meg kell emlékezni, amikor a TK-val dolgozik. Szükség van a tervezésre is. Ez a dokumentum címlapjára vonatkozik.

Az 1c-es fejlesztés technikai feladata fő hibái

Az ügypiac szerkezetét a GOST 34.602-89 szabályozza. Ez a dokumentum egyértelmű követelményeket tartalmaz a TK-ban lévő információcsomagok számára és sorrendjére. Ugyanakkor nincs szigorú előírások a bemutató módszereire. Ez a helyzet nagy lehetőséget biztosít a komplex feladatok megoldására, és ugyanakkor számos hibát vonhat le a dokumentum előkészítésében. Leggyakrabban a következő pontatlanságok:

1. Egyes szakaszok ismétlése különböző értelmezésekben.
2. Az információ véletlenszerűen van. Ideális esetben egy adott struktúrára, például üzleti folyamatokra vagy rendszermodulokra kell hivatkoznia.
3. A különböző szakaszokban lévő információk különböző részletességgel szolgálnak fel.

Mindez megakadályozza az ügyfél általi információk megértését, amelyet a TK-ban tartalmaz. Ez bonyolítja az együttműködés folyamatát, ami több időt fogyaszt.

Az ügyfél megtekintése után a TK minta az 1C véglegesítésénél változhat, és nem mindig jobb. Ez viszont megakadályozza, hogy a programozók helyesen érzékeljék az információkat. Ez különösen igaz a kis élményekkel 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ással.
2. A készítmények pontatlanok.
3. Helyek Az információ felesleges részletes.

Szabaduljon meg minden felsorolt \u200b\u200bhibától egyszerűen. Először is navigálni kell az eredményre, és nem a gondos előírásra. Érdemes emlékezni arra, hogy a TK leírja a projekt funkcionalitását, fő paramétereit és célját.

Hogyan lehet elkerülni a hibákat a TK fejlesztésében?

Az összes későbbi ajánlásra vonatkozó fő szabály a készítménynek specifikusnak kell lennie. Ehhez a GOST-hez, más szabályozási dokumentumokhoz kapcsolódnia kell. Ez lehetővé teszi a vállalkozó és az ügyfelek számára, hogy egy módon érzékeljék az információkat.

Az 1c-es finomításra szolgáló technikai feladat példája az iparág nyelvének használatát jelenti, amelyre a projektet elvégzik. Először is, az ügyfél számára. Ugyanakkor a szövegben nem érdemes összehasonlításokat használni, mivel különböző módon értelmezhetők.

A technikai megbízás kidolgozásának fő szabályai egy jelentés és más elemek fejlesztéséhez 1c:

1. A TK-t a vállalkozó és az ügyfél közösen hozta létre.
2. Csak objektív követelményeket kell helyezni a programozók működésére. A projekt sikeres fejlődéséhez az ügyfél szubjektív elképzeléseit minimálisra kell csökkenteni.
3. Az eredménynek részletesen le kell írnia az ügyfél igényeit. Ugyanakkor az 1C konfiguráció fejlesztésének technikai feladata példájában minden olyan paramétert kell előírnia, amelyre az elemnek működnie kell. Ellenkező esetben az eredmény nagymértékben eltérhet a kívánt közül.
4. A művész és az ügyfél kockázata megközelítőleg egyenlő és minimálisra kell lennie.
5. Nem lehet használni olyan kifejezéseket, amelyeket üzleti kommunikációban használnak, és nem alkalmazzák egy adott iparágban.

Ahhoz, hogy tk-t hozzon létre egy jelentést az 1C-ben vagy egy másik elemben, az elemzőnek ismernie kell az ügyfél tevékenységének összes jellemzőjét. A követelményeknek csak olyan hasznos információkat kell adnia, amelyek hasznosak a vállalkozó számára. Tekintettel arra, hogy különös figyelmet fordítanak a végfeladatokra, amelyek megoldaniuk kell a szoftvert, a technikai feladat egységes példája nem létezik.

A TK hibás összeállításának veszélye

A fent felsorolt \u200b\u200bhibák az idő növekedéséhez vezethetnek, amelyet a rendszer létrehozására fordítanak. Ezenkívül extra költségekkel és elégedetlenséggel jár. Az adatbázisfejlesztés vagy más konfiguráció technikai feladata az 1C-nek tapasztalt szakembereknek kell lennie. Mennyire áll rendelkezésre ez a dokumentum megértéséhez, az összes résztvevő előnye. Az ügyfél hatékony automatizált rendszert kap az üzleti feladatok megoldására. Ugyanakkor a vállalkozó egy másik elégedett ügyfél. Az üzleti tulajdonosoknak a lehető legközelebb kell lenniük az 1C partner cégek kiválasztásához, mivel a szervezet hatékonysága attól függ, hogy mennyire minőségi, a szervezet hatékonysága függ.