Na jedné straně při neformálním přístupu k implementaci je často nutné řešit změny ve formulaci úkolů zákazníka již v průběhu implementace. Na druhou stranu můžete často slyšet prohlášení jako „máme hodně naléhavé práce – pokud tomu věnujeme čas také, tak. „Zdá se, že hlavním spotřebitelem technických specifikací je vývojář, a proto by se měl ujmout úkolu psát technické úkoly.
úspěšnost přejídání prudce klesá, pokud existují předpoklady pro sabotáž
mouchy zvlášť, řízky zvlášť. Technické specifikace píše developer, za nějaké peníze, pokud se bavíme o realizačním projektu (zákazník zpravidla neví, co chce). Technické specifikace jsou odsouhlaseny se zákazníkem a práce začnou. Změna podmínek znamená dodatečné peníze a/nebo změnu termínů.
Pokud taková otázka vyvstane, měla by být okamžitě vznesena otázka testování. Například stanovit, že zákazník je povinen strávit testováním minimálně 20 člověkohodin.
Technické specifikace sepisuje zákazník.
Teprve díky nutnosti formulovat své požadavky na papír začíná Zákazník zapínat mozek. Zapnutím mozku sám Zákazník začíná chápat, co přesně chce. Díky tomu do budoucna odpadá situace, kdy „se změnami ve formulaci úkolů zákazníka musíte často potýkat již při realizaci“.
Další otázkou je, že při psaní technických specifikací musí zákazník zapojit do konzultací metodika, aby neztrácel čas vymýšlením kol s hranatými koly.
(3) proč vývojář?
Technická specifikace musí být napsána v jazyce zákazníka a v terminologii srozumitelné zákazníkovi.
Je nutné oddělit technické specifikace a technický projekt, který popisuje podrobnosti realizace technických specifikací.
(8) Setkal jsem se se spoustou jednoduchých problémů – technické specifikace samozřejmě psal vývojář za nějaké peníze, a ne na krátkou dobu. Zákazníci zpravidla nemají lidi, kteří jsou toho z principu schopni. Jde o to, najmout si jednu kancelář na technické specifikace a druhou na realizaci – bude to hloupě dražší
(8) Zákazník by měl napsat něco jako následující
Podmínky
1. Transakce – společenství obchodních transakcí souvisejících s hlavní činností společnosti (obchodem), které mají předvídatelný konečný finanční výsledek. Transakce obvykle zahrnuje prodej pevného seznamu zboží/služeb v rámci jedné smlouvy nebo jednoho účtu. Transakce nemůže mít neznámý finanční výsledek (např. nelze stanovit finanční výsledek pro rámcovou smlouvu s pevnými cenami, ale bez pevného objemu, v takovém případě je každá dodávka samostatnou transakcí).
2. FRC (Centrum finanční odpovědnosti) – strukturální jednotka (nebo několik), která provádí určitý soubor obchodních operací, je schopna přímo ovlivňovat výdaje a/nebo příjmy z těchto operací a odpovídá za výši těchto výdajů a/nebo příjmů. . Za výsledky činnosti odpovídá vedoucí centrálního federálního okruhu.
3. MOL – Finančně odpovědná osoba
Cíle projektu
Cílem projektu je vytvořit jednotnou databázi, která vám umožní udržovat:
1. Obchodujte vzájemné vyrovnání s kupujícími (v rublech, měně a EU) v rámci protistrany, právnické osoby, dohody, transakce (včetně transakcí s více účty). Obchodní vypořádání zahrnuje odraz (a úplné podrobnosti) komoditních a finančních obchodních transakcí mezi organizací (nebo jejími přidruženými společnostmi) a kupujícími.
2. Provádění skladové činnosti v kvantitativním a peněžním vyjádření z hlediska skladů, nomenklatury, šarží s různými náklady, sériovými čísly. Při vedení skladové evidence se předpokládá zavedení čárových kódů. Zavedení dvou druhů nákladů, nákupní a plné (včetně nákladů na logistiku). Zavedení mechanismu osobní odpovědnosti manažerů za skladové položky přestěhované do kanceláře nebo na testování.
3. Automatizace plánování a účtování skutečné ziskovosti transakcí a finančních výsledků manažerů. Automatizace výpočtu odměn pro manažery včetně reportů o manažerech a transakcích.
4. Zavedení pohodlného systému pro rezervaci zboží a dočasného převodu rezerv.
5. Provádění nákupních operací v rámci obchodního obratu (úplné vzájemné vypořádání s dodavateli nyní není možné realizovat, možná bude realizováno „později“). V Ruské federaci plné řízení vzájemných vypořádání, v zahraniční ekonomické činnosti pouze komoditní část.
6. Udržování finančních výsledků (s určitými omezeními) pro Centrální federální okruh.
7. Kontrola všech plateb, včetně plateb za neobchodní transakce (přihlášky k platbám).
8. Zajištění tisku prvotních dokladů o obchodních transakcích v souladu s požadavky účetnictví a zákazníků obchodními útvary. V tomto případě mohou existovat rozdíly mezi tištěnými a účetními daty.
9. Integrace s účetním programem.
10. Vedení a plánování splátkového kalendáře.
11. Rozpočtování činnosti podniku.
12. Zohlednění skutečných podmínek transakcí kromě smluvních.
Základní účetní systém přívěsů
1. Systémové rozhraní by mělo umožňovat provádění 80 % všech operací přímo z plochy a na ploše by nemělo být mnoho objektů.
2. U obchodních operací je hlavním předmětem práce „Transakce“, transakce má různé statusy. Při reflektování obchodních transakcí souvisejících s transakcí se stav transakce mění a ze samotné transakce lze prohlížet všechny dokumenty, sestavy a další data související s transakcí.
3. Pro operace nákupu je základem vždy transakce nebo několik transakcí. Nákup mimo transakce je zakázán, pro nákupy na skladě je vytvořen speciální typ transakce. Hlavním objektem nákupních operací jsou dva objekty „Objednávka dodavateli“ a „Faktura“. Objednávka slouží k plánování a faktura slouží k vyjádření skutečnosti odeslání dodavatelem a dalšího logistického zpracování až po příjem na sklad.
4. Skladové účetnictví by mělo umožňovat jednoznačnou identifikaci STK, která přijala zboží (včetně zboží, které nepatří organizaci, například zboží předané k opravě klientem) v jakékoli fázi pohybu nebo umístění zboží. . MOL může být manažer, který převzal zboží k předvedení klientovi nebo přepravce. Systém by neměl umožňovat odepsání zboží z jednoho MOL bez podpisu dokumentu přijímající stranou.
5. Všechny primární dokumenty předané klientům musí být vytištěny až po ověření údajů účetním oddělením nebo PEO. Seznam dokumentů a inspektorů musí být udržován v databázi.
6. Vzájemná vypořádání musí být provedena pomocí dvou účetních systémů, v systému řízení a v identickém účetním systému (pro správný zápočet záloh a tisk dokumentů na základě smluv v EU a měně). Mezi těmito dvěma účetními systémy mohou být nesrovnalosti.
7. Pevné oddělení přístupových práv, hlavní parametry oddělení jsou Central Federal District, Transaction.
Fáze projektu
1. Sběr informací, analýza, psaní technických specifikací
2. Zápis alfa konfigurace
3. Zkušební testování alfa konfigurace uživateli, finalizace technických specifikací na základě jejich připomínek
4. Zápis pilotní konfigurace
5. Implementace minimální funkčnosti
6. Další vylepšení
Kritéria hodnocení a přijetí
1. Minimální funkčnost – systém umožňuje uživatelům provádět samostatně (bez cizí pomoci či konzultace) 80 % úkonů na obchodních operacích, a to: příjem, realizace, rezervace, pohyb, tisk prvotních dokladů, zbývajících 20 % systém to umožňuje nebo je „nepohodlný“ nebo „abnormální“. Systém umožňuje uživatelům získat nezávisle (bez pomoci nebo konzultace třetí strany) 50 % analytických informací, které potřebují, zbývajících 50 % analytických informací lze získat „z krabice“ nebo mechanismy pro jejich získání v určitém čase. lze přidat rámec přijatelný pro firmu (například do konce čtvrtletí).
2. .
Otázka vývoje nebo nevyvíjení technických specifikací se někdy stává bodem, kdy mezi zákazníkem a dodavatelem vzplanou rozpory. Tím, že se vrhnete do propasti vzájemného nedorozumění, můžete nejen zpomalit vývoj projektu, zhoršit výsledek práce, ale také se obecně nedaří najít mezi sebou společnou řeč a jít každý svou cestou, aniž byste něco začali.
Návrh na vypracování technických specifikací se často setkává s nepřátelstvím a my dokonale chápeme neochotu klienta věnovat další čas a zdroje „zbytečné“ práci. No, například:
- Zahájení projektu se opožďuje a termíny již běží. A na tomto pozadí strávit několik týdnů nebo dokonce měsíc shromažďováním, vyjasňováním a zaznamenáváním požadavků jako zbytečné plýtvání. A proč, protože klient je vždy v kontaktu a vy stačí napsat/zavolat a dozvědět se více!
- Nechci vytvářet zbytečnou byrokracii – obecně jde o pokračování předchozího argumentu. “Pokud máte nějaké dotazy, napište mi, odpovím.”
- Projekt je již pro klienta jasný a zcela srozumitelný, takže není potřeba nic popisovat. A pokud je něco nejasné, opět můžete vždy mluvit a vyřešit jakékoli problémy, které se objevily.
- Celkově: proč potřebujeme tento „zbytečný“ dokument, když už se můžeme na všem dohodnout přímo mezi sebou? Obzvláště pokud vás také požádají, abyste za to zaplatili!
I já při psaní tohoto textu do jisté míry solidárně cítím se zákazníkem, protože argumenty jsou vážné. Proč je tedy stále potřeba technická specifikace? Nebo spíše, kdy je to skutečně nutné a kdy je argument proti více než spravedlivý? Zkusme na to přijít.
Abychom pochopili, kdy potřebujeme TK, pojďme zjistit, jaké bolesti by měl pokrývat. Koneckonců, pokud to neřeší žádné konkrétní problémy, pak to opravdu nemá smysl dělat. Na základě zkušeností našeho týmu můžeme vytvořit následující seznam:
1. Detailní abstraktní myšlenky. Často, i když je obecně problém skutečně jasný a poměrně přesně vyjádřen, mohou být v prohlášení určité nejasnosti. Konkrétní a srozumitelné cíle se navíc mohou stát vágními kvůli různým metodám provádění.
Vezměme si příklad: potřebujeme vyvinout produktovou kartu pro internetový obchod. Zdá se, že jsme všichni viděli, jak vypadá internetový obchod, a zde by neměly být žádné otázky. Ale jsou tu maličkosti jako:
Jak má vypadat náhled produktu, zda se má obrázek zvětšit po kliknutí, jak má vypadat posuvník.
Co bude v bloku popisu: jen volný text, nebo tabulka s charakteristikami? Mají být charakteristiky převzaty ze speciálních polí na kartě produktu, nebo by měl správce obsahu jednoduše zadat libovolný text sám?
Obecně si můžete vymyslet nekonečný seznam upřesňujících otázek a stejně nakonec na něco zapomeneme. Ale minimálně je potřeba vyjasnit a zaznamenat klíčové body.
Nebo jiná možnost: úkol je jednoduchý a srozumitelný, ale má několik způsobů, jak jej realizovat. Vyviňte například modul zpětné vazby: zde můžete skutečně vyvinout nějaký systém pro práci s požadavky na straně webu, vytvořit osobní účet manažera, nastavit zasílání upozornění na nové zprávy atd. Nebo můžete jednoduše nainstalovat nějaký hotový modul, jako je JivoSite, a z hlediska nákladů a pracovní náročnosti vývoje jsou tyto dva úkoly radikálně odlišné!
2. Rozumnější výběr technického zásobníku pro projekt. Předchozí příklad lze extrapolovat na mnohem složitější úkoly, než je formulář zpětné vazby. Obecně se může ukázat, že část funkčnosti, kterou klient vyžaduje, je již implementována nějakou službou nebo knihovnou a zde můžete ušetřit na vývoji od nuly. Nebo naopak dojde k pochopení, že požadovaný business proces v hotových řešeních vůbec nefunguje tak, jak klient potřebuje, a vše si budete muset napsat sami.
K provedení takové analýzy potřebujete mít potřebná data a detailně porozumět klientově úkolu. V naší praxi se bohužel vyskytly případy, kdy jsme se v prognózách zmýlili, původně jsme spolu s klientem doufali, že funkčnost v hotové podobě již byla implementována v modulu třetí strany, „zbývá jen přidat malé doladění.“ Když došlo na implementaci, ukázalo se, že požadované chování bylo obtížné/nákladné nebo dokonce prakticky nemožné implementovat pomocí navržené technologie. Výsledek je tristní: přesčasy, nedodržené termíny, zvýšené náklady. Pro obě strany je lepší snažit se takovým situacím „onshore“ vyhnout.
3. Lepší pochopení projektu pro zadavatele i zhotovitele. Detailním požadavkem může nejen vývojář, ale i samotný klient lépe pochopit, jak má jeho projekt fungovat, jaká funkcionalita je prvořadá a co lze zanedbat.
Problém je v tom, že všechny projekty jsou omezeny rozpočtem a termíny. A často se v průběhu ujasňování požadavků ukáže, že kompletní realizace všeho požadovaného bude buď trvat dlouho, nebo bude drahá, nebo najednou. Zkušený vývojový tým samozřejmě může najít způsoby, jak urychlit proces paralelizací vývoje několika modulů, ale to není vždy možné.
V důsledku toho si musíte vybrat, kterou funkci chcete provést jako první, protože. To je hlavní myšlenka celého projektu a kterou lze doplnit dalšími iteracemi nebo úplně vynechat.
4. Přesnější předpovědi rozpočtů a termínů. Toho lze dosáhnout, pokud technická specifikace pokrývá výše popsané body. Jako každá dobrá analytika i dobře propracovaná technická specifikace výrazně snižuje možné nejistoty při realizaci projektu.
5. Technické specifikace – jako základ, na kterém se budují smluvní vztahy pro vývoj projektu. Podrobný popis toho, jak by měl projekt fungovat, je vlastně fixací povinností zhotovitele vyvinout přesně popsaný systém a ne žádný jiný. Přítomnost takového dokumentu je dobrým plusem pro dodavatele i zákazníka, protože umožňuje oběma stranám chránit se před nepřiměřenými požadavky nebo neplněním závazků.
Je zřejmé, že technické specifikace, které řeší tyto úkoly, již nemohou být pouze formálním kusem papíru a nelze je „jakkoli“ provést. Navíc největšího efektu lze dosáhnout při účasti na vývoji technických specifikací týmu, který bude následně vyvíjet samotný produkt.
Bohužel se občas setkáváme se situacemi, kdy technické specifikace klienta již napsal nějaký „dodavatel na sepsání technických specifikací“, který s tím obecně neměl v úmyslu nic dělat. V takových úžasných dokumentech najdeme spoustu vody, extrémně pečlivě a precizně napsané části „termíny a definice“ a skromný, chabý popis samotných obchodních procesů, které musí produkt implementovat. Jako třešničku na takovém dortu občas narazíme na předepsané „technické požadavky“ na projekt v podobě náhodného seznamu softwaru, na kterém by mělo vše fungovat. A vrcholem této třešničky je, že verze softwaru jsou buď zastaralé, nebo neodpovídají tomu, co lze s tímto softwarem udělat a co je pro projekt skutečně potřeba udělat.
Tady by se dalo smát, ale ve skutečnosti tato situace bolí, protože za prvé klient již zaplatil za odvedenou práci a někdy i spoustu peněz. V důsledku toho je velmi obtížné smířit se s myšlenkou, že z takových technických specifikací není žádný užitek a je třeba dělat vše znovu. Pro interpreta je ale přihlášení se k takové technické specifikaci poměrně značné riziko a někdy musíte velmi zajímavý a žádaný projekt odmítnout. Navíc takové situace v očích klienta obecně diskreditují týmy navrhující začít s vývojem technických specifikací a automaticky u nich vzbuzují podezření.
Ne všechny projekty však skutečně vyžadují pečlivě sestavené technické specifikace a extrémně hloubkovou analýzu. Ve společnosti DigitalWand se v tomto snažíme najít rovnováhu a nedělat více, než je nutné pro úspěch projektu.
Podívejme se na příklady webů, od jednoduchých po složité.
- Jednoduché vstupní stránky. V tomto případě je důležité mít prototyp pro vývoj designu, abyste pochopili, zda je potřeba úprava pro mobilní zařízení, a také nějaký popis požadovaných „zvláštních efektů“ na stránce, pokud existují. V opačném případě není nutná žádná podrobná dokumentace k projektu, protože Celý projekt zpravidla končí vizuálem.
Informační portál, blog. I zde je vše obvykle velmi jednoduché a s vizuálním designem nebo prototypy webových stránek obecně můžete pochopit, co a jak by se mělo dělat.
Online obchod. To je dnes celkem standardní úkol a pokud se na to plánuje použít nějaké hotové řešení prakticky bez úprav, třeba obchod od Bitrixu, tak se bez technických specifikací opravdu obejdete. V ostatních případech stojí za to analyzovat a sepsat ty body, které odlišují nový obchod od všech ostatních – z hlediska rozhraní, obchodní logiky, struktury katalogu a procesu nákupu zboží. Obchodně orientované obchody například nemusí na webu vůbec poskytovat platební metody, ale na konci nákupu je nutné vygenerovat soubor PDF s fakturou. Navíc se u tohoto druhu projektů rozhodně vyplatí věnovat pozornost výměně dat s externími systémy, taková pravděpodobně bude, alespoň u účetního programu jako 1C.
Klasifikace je samozřejmě dost hrubá, ale je potřeba si informace nějak uspořádat. Náš tým má zkušenosti s vývojem všech těchto typů projektů, ale co je důležitější, tato zkušenost nebyla vždy úspěšná. Při analýze našich chyb a potíží, se kterými jsme se setkali, jsme si často všimli, že u problematických projektů byla předběžná analýza na nedostatečné úrovni, což vedlo ke změnám plánů za chodu, náhlým hledáním řešení, kde se dříve zdálo být vše jasné, implementaci toho, co nebylo předpokládaná funkčnost. hromadila se jako sněhová koule a vedla k překročení rozpočtu a termínů.
Je těžké psát o konkrétních cenách na neustále se měnícím trhu. Tyto informace již nemusí být relevantní den po zveřejnění. Pokusím se vás proto provést mzdovými náklady.
V nejjednodušším případě, kdy nebyl vyžadován úplný popis projektu, ale bylo potřeba pouze zaznamenat hlavní body, jsme to udělali jednoduše: vytvořili jsme malý dokument o několika stránkách, kde jsme obrysově popsali nebo se snímky obrazovky, co bylo potřeba, a dohodli se s klientem. Tento dokument podepsali. Samozřejmě to není ideální varianta, ale rozhodně je to lepší než vůbec nic. Z hlediska mzdových nákladů to není příliš drahé: obvykle stačí, aby projektový manažer strávil den nebo dva komunikací s klientem a týmem a zaznamenáváním požadavků. Toto schéma je vhodné pro krátké projekty, trvající do měsíce, kdy je úkol v zásadě jednoduchý a srozumitelný pro všechny účastníky a hlavním rizikem je zde nedodržení nepřesností v maličkostech.
Pokud je projekt větší, pak je práce více. Například pro vypracování technických specifikací pro vývoj internetového obchodu může celkový tým od klienta i vývojáře vypadat takto:
- Produktový manažer ze strany klienta.
- Projektový manažer ze strany zhotovitele.
- Vedoucí vývojář.
- Designér, UI/UX.
- SEO specialista.
- Specialisté z externích systémů (například 1C).
- Je možné, že do koordinace nebo vytváření seznamu obchodních požadavků jsou zapojeny další osoby.
Ani samotná organizace efektivní interakce takového týmu již není triviálním úkolem, zejména s ohledem na to, že jeho členové mohou pracovat v různých společnostech.
V tomto případě může vývoj technických specifikací trvat 1–2 měsíce, v závislosti na efektivitě interakce a podrobnosti požadavků.
I když se však na vývoji podílí jen pár lidí z interního vývojového týmu, proces může trvat dlouho. Například u jednoho z našich projektů bylo v rámci vývoje technických specifikací nutné nejen navrhnout a popsat architekturu, ale předběžně otestovat několik hypotéz, zahodit nesprávná architektonická řešení a vyvinout detailní prototypy uživatelského rozhraní. . A pečlivě korigovat a učesat výsledný dokument, protože. Klient jej potřeboval k registraci produktu v ruském softwarovém registru. Na úkolu pracovali pouze 3 lidé z naší strany: manažer, hlavní vývojář, designér. A implementace trvala více než 2 měsíce.
Obecně platí, že načasování a náklady na vývoj technické specifikace jsou zcela individuální v závislosti na projektu a požadovaném výsledku.
Aby byl výsledek vysoce kvalitní, musíte pochopit: technické specifikace nejsou jen N stránek nějakého složitého textu, který je potřeba pouze k připojení ke smlouvě. Zadání je výsledkem analytické práce prováděné specialisty z různých oborů podílejících se na vývoji. V tomto případě je důležitý nejen výsledný dokument, ale i samotný fakt, že analytickou práci provedl klient a vývojový tým, a jasnější pochopení produktu, použitých technologií, priorit, termínů a přístupů. se objevil vývoj. Přesto i v IT primárně pracujeme s lidmi a nelze opomíjet lidský faktor.
Při analýze našich chyb a potíží jsme si často všimli, že předběžná analytika „trpěla“ v problematických projektech. V důsledku toho jsme vyvinuli vyvážený přístup k vývoji technických specifikací. Snažíme se šetřit rozpočet klienta a neustrnout v „hookworku“. Ale hodně záleží na klientovi: na jeho ochotě poskytnout potřebné informace, diskutovat o obchodní logice, přemýšlet o obchodních prioritách atd. Zde bez úzké interakce mezi zákazníkem a zhotovitelem není kam. Obecně jako vždy platí, že klíčem k úspěchu je úzká spolupráce ve prospěch společného cíle. Ostatně i my jako dodavatel nemáme o kvalitní realizaci cool projektů o nic menší zájem než naši zákazníci. Pro náš tým je to nejen příjem, ale také opravdu oblíbená práce.
