Stadier av projektplanering. Planera ett projekt Steg för att skapa ett schema

Planeraär processen att allokera och tilldela resurser (materiella och mänskliga) med hänsyn till kostnaden och tiden för projektet. Planering är en av de viktigaste processerna för ett projekt, eftersom resultatet av dess genomförande vanligtvis är ett unikt objekt, produkt eller tjänst.

Main planeringsfunktioner listas nedan.

Omvandla behov till hanterbara uppgifter. Inledningsvis framträder projektet i form av krav utvecklade och överenskomna med kunden. Syftet med planeringen är att presentera dessa krav som en uppsättning individuella uppgifter som kan kontrolleras.

Bestämma de nödvändiga resurserna. Detaljerade planer kommer att avgöra antalet personer, nödvändig utrustning och arbetsförhållanden som kommer att behövas för att genomföra projektet.

Koordinering av teamarbete på projektet. Mycket ofta bryts genomförandet av ett projekt upp i separata aktiviteter som kan utföras parallellt. Planer gör det möjligt att samordna dessa aktiviteter genom att definiera vem som gör vad och när.

Bedömning av potentiella risker.Även om vissa risker kan identifieras under kravformuleringen, identifieras många fler efter att detaljplanering har genomförts. Genom att veta om förekomsten av dessa risker kan du märka dem tidigare (om de har förverkligats) och förbereda dig för att ta itu med dem.

Problemvarning. Avvikelse från planen fungerar som en signal om problem. Planer är inte en dogm som villkorslöst måste följas. För projektledaren är de mer en gissning och ett jämförelseunderlag. Om genomförandet av projektet inte lever upp till förväntningarna är det nödvändigt att göra en lämplig justering av planen.

Grupp planeringsprocesser visad i fig. 3.10. Dessa processer kan upprepas och vara en del av en iterativ procedur som utförs tills ett visst resultat uppnås. Till exempel, om det ursprungliga slutdatumet för projektet är oacceptabelt, de nödvändiga resurserna, kostnaden och ibland ( Processgrupper ^Projektledning

Planeringsprocessgrupp

Projekt Human Resource Management

Planera

Utveckling av en personalplan Resurser

Definition

Projekttidsplanering

Definition

operationer

Kontrollera

integritet

Planering av upphandling

Projektkostnadshantering^

Kostnadsberäkning

Projektkvalitetsledning

Utveckling av en projektledningsplan

Definition

sekvenser

operationer

verksamhetsresurser

Planera

kvalitet

varaktighet

operationer

Utveckling

scheman

Projektriskhantering

Definition

Planera

förvaltning

risk

Genomföra en kvalitativ riskanalys

Genomföra en kvantitativ riskanalys

Riskresponsplanering

Ris. ONDSKA. Planeringsprocesser

projektet måste ändras. Resultatet i detta fall kommer att vara överenskomna villkor, volymer, nomenklatur av resurser, budget och innehåll för projektet, som motsvarar dess mål.

Planering är en nödvändig förutsättning för genomförandet av alla, även den enklaste uppgiften. Otillräcklig planering kan göra att projektet misslyckas eller ge otillräckliga resultat i projektmiljön.

Planering i en eller annan form genomförs under hela projektets livslängd. I början av ett projekts livscykel utvecklas vanligtvis en informell initial plan - en ungefärlig uppfattning om vad som kommer att behöva göras om projektet genomförs. Beslutet att välja ett projekt baseras till stor del på utvärderingarna av denna initiala plan. Formell och detaljerad projektplanering påbörjas efter att beslutet att genomföra den har fattats.

Planeringen består i att upprätta följande planer:

• utförandet av arbetet, inklusive en bedömning av deras arbetsintensitet och tidsfrister;
• hantering av innehållet och omfattningen av arbetet;
• organisationsstruktur;
• konfigurationshantering;
• kvalitetshantering;
• riskhantering;
• upphandlingshantering;
• certifiering av designresultat och utförares aktiviteter.

Definition planeringsnivåerär också föremål för planering och genomförs för varje specifikt projekt, med hänsyn till dess särdrag, skala, geografi, tidpunkt, etc. Under denna process bestäms typen och antalet planeringsnivåer som motsvarar de tilldelade arbetspaketen för projektet, deras materiella och tidsmässiga samband.

Planer (grafer, nätverk) som ett uttryck för resultaten av planeringsprocesser bör sammantaget bilda en viss pyramidformad struktur som har egenskaperna att aggregera information, differentierad av nivåer av medvetenhetshantering, och bör vara ekelonerad i termer av utvecklingstid (kort -sikt, medellång och lång sikt). Planeringsnivåerna och plansystemet måste byggas med principerna om "feedback", vilket säkerställer en konstant jämförelse av planerade data med faktiska data, de måste vara mycket flexibla, relevanta och effektiva.

Nätverksplaner är agglomererade på grund av att den allmänna nätverksplanen består av många privata nätverksplaner. I var och en av dessa privata planer bestäms den längsta vägen. Dessa vägar sätts sedan i stället för enskilda delar av nätverket. Med hjälp av sådan gradvis aggregering erhålls nätverksplaner på flera nivåer (Fig. 3.11). Vanligtvis finns det en konceptuell plan, en strategisk plan för genomförandet av projektet, taktiska (detaljerade, operativa) planer.

Nätverksplan med flera projekt (för högsta ledningen)

Nivå 1

Nivå 3

Nivå 2

Nätverksplan med milstolpar

Detaljerad nätverksplan

Ris. 3.11.Nivåbaserade nätverksplaner

Konceptuell planering, som resulterar i en konceptuell plan, är processen att utveckla den huvudsakliga projektdokumentationen, specifikationer, uppskattningar, huvudscheman, kontroll- och ledningsprocedurer. Konceptuell planering utförs i den inledande perioden av projektets livscykel.

Strategisk planeringär en process för att utveckla strategiska, utökade, långsiktiga planer.

Detaljerad (operativ), taktisk) planering kopplat till utvecklingen av taktiska, detaljerade planer (scheman) baserade på en hierarkisk arbetsstruktur (WBS) för operativ ledning

på nivån för ansvariga utförare.

Content management planering. En av de vanliga "sjukdomarna" i mjukvaruprojekt kallas "krypande särdrag", när ett skjul för förvaring av trädgårdsredskap först kopplas till en ursprungligen designad monter för en älskad hund, och sedan ett hus i flera våningar för sin ägare. Och de försöker bygga allt detta på samma grund och från samma material. Detta tillvägagångssätt har lett till döden för många programvaruutvecklingsprojekt. Därför, så snart det var möjligt att stabilisera och enas om WBS - den hierarkiska strukturen i arbetet, är det nödvändigt att utveckla förvaltningsplan för projektomfattning, för vilket du bör:

• identifiera källor till ändringsförfrågningar;
• upprätta ett förfarande för att granska, utvärdera och godkänna/förkasta innehållsändringar;
• fastställa förfarandet för att dokumentera innehållsändringar;
• fastställa förfarandet för att informera om ändringar i innehållet. Den första uppgiften som måste lösas vid analys av en fråga

för ändringar - för att identifiera förändringsobjekten: krav, arkitektur, datastrukturer, källkoder, testskript, användardokumentation etc. Sedan krävs det att man designar och i detalj beskriver förändringarna i alla identifierade objekt. Slutligen bör kostnaderna för att göra dessa ändringar, testa ändringarna och deras inverkan på projektets tidslinje bedömas. Detta arbete kommer att kräva utgifterna för arbetstid, och ibland betydande, för olika specialister: analytiker, designers, utvecklare, testare samt en projektledare, och därför måste det beaktas i planen.

Planering av organisationsstruktur.Organisationsstruktur- detta är en överenskommen och godkänd fördelning av roller, ansvar och mål för nyckelprojektdeltagares aktiviteter. Det måste nödvändigtvis innehålla följande:

• ett system för arbetsrelationer mellan projektets arbetsgrupper;
• rapporteringssystem;
• utvärdering av projektets framsteg;
• beslutsfattande system.

Man bör komma ihåg att projektets organisatoriska struktur är en "levande" organism. Det börjar ta form på planeringsstadiet och måste förändras allt eftersom projektet fortskrider. Instabiliteten i organisationsstrukturen (frekvent byte av utförare) kan bli ett allvarligt problem i projektledning, eftersom det finns ett ersättningspris som bestäms av den tid då en ny deltagare går in i projektsammanhanget.

Planering av konfigurationshantering. En av de viktiga processerna för mjukvaruproduktion är konfigurationshantering. Mer än en bok har skrivits om detta kunskapsområde. Det kommer bara att tala om hur detta arbete ska planeras. Hanteringsplanen för projektkonfigurationen bör innehålla:

• arbeta för att tillhandahålla ett enda arkiv för all projektdokumentation och utvecklad programkod, för att säkerställa säkerheten och återställningen av projektinformation efter ett misslyckande;
• arbete med att sätta upp arbetsstationer och servrar som används av medlemmar i projektgruppen;
• det arbete som krävs för att organisera sammansättningen av mellanliggande versioner av systemet, såväl som dess slutliga version.

Detta arbete utförs vanligtvis av en konfigurationsingenjör. Om projektet är litet kan den här rollen vara ytterligare för en av programmerarna eller projektledaren. Att ”smutsa” detta arbete på alla projektdeltagare är för det första ineffektivt. Att installera och konfigurera utvecklingsmiljöer, såsom databaser och applikationsservrar, kräver viss kompetens och kunskap om egenskaperna hos specifika produktversioner. Om alla utvecklare måste behärska dessa färdigheter kommer det att ta för mycket arbetstid. För det andra kan "smetande" konfigurationshanteringsarbete leda till kollektivt ansvarslöshet, när ingen vet varför projektet "inte går" och hur man "rullar tillbaka" till den tidigare versionen.

Konfigurationshantering kan bli mycket mer komplicerad om projektgruppen måste stödja flera releaser av denna produkt som tidigare installerats av olika kunder parallellt med utvecklingen av ny produktfunktionalitet, men allt detta arbete bör beaktas i projektplanen.

Kvalitetsledningsplanering. Ett annat av de grundläggande kunskapsområdena inom mjukvaruteknik är kvalitetssäkring. Det finns olika åsikter om vad mjukvarukvalitet är och hur man säkerställer den effektivt. Vi kommer att begränsa oss till påståendet att kvalitetssäkring är ett ganska viktigt arbete som bör planeras i förväg och genomföras under hela mjukvaruprojektet, och inte bara under acceptanstest.

När man planerar detta arbete måste man förstå att projektets produkt inte ska vara av högsta möjliga kvalitet, vilket är ouppnåeligt på en begränsad tid. Den erforderliga kvaliteten på produkten bestäms av kraven för den. Kvalitetssäkringens huvuduppgift är inte att hitta fel i den färdiga produkten (output control), utan att förhindra dem i produktionsprocessen.

Kvalitetsledningsplan bör innehålla följande aktiviteter:

• objektiv verifiering av att mjukvaruprodukter och tekniska funktioner överensstämmer med tillämpliga standarder, procedurer och krav;
• fastställande av avvikelser i kvalitet, identifiering av deras orsaker, tillämpning av åtgärder för att eliminera dem, samt kontroll över genomförandet av de vidtagna åtgärderna och deras effektivitet;
• förse högsta ledningen med oberoende information om avvikelser som inte kan lösas på projektnivå.

Förtydligande av arbetets innehåll och omfattning. Förfining av projektets omfattning (sönderdelning) är en av de viktigaste komponenterna i disciplinen projektledning. Detaljering gör att du kan utvärdera, till exempel, den totala kostnaden för projektet genom den totala kostnaden för dess enskilda arbeten. Resultatet av att detaljera projektets omfattning är arbetsfördelningsstruktur(Work Breakdown Structure - WBS). I de flesta fall är denna struktur hierarkisk. Samtidigt är processen för detaljering arbetsfördelningsstruktur, dvs. aktiviteten att skapa en detaljerad arbetsstruktur eller projektuppgift.

Verkens hierarkiska struktur(WBS) är en resultatorienterad nedbrytning av det arbete som utförs av projektgruppen för att uppnå projektets mål och önskade resultat. Med dess hjälp struktureras och definieras hela projektets innehåll. Varje nästa nivå i hierarkin återspeglar en mer detaljerad definition av delarna i projektet. Grunden för utvecklingen av WBS är konceptet för projektet, som definierar projektets produkter och deras huvudsakliga egenskaper. WBS säkerställer att alla aktiviteter som krävs för att uppnå projektmålen identifieras. Många projekt misslyckas inte för att de inte har en plan, utan för att planen utelämnar viktigt arbete som att testa och fixa buggar, samt projektprodukter som användardokumentation. Därför, om WBS är korrekt sammanställt, kan allt arbete som inte ingår i det inte betraktas som arbete på projektet. WBS delar in projektet i delprojekt, arbetspaket, delpaket. Varje nästa nivå av nedbrytning ger en konsekvent detaljering av projektets innehåll, vilket gör att du kan uppskatta tidpunkten och omfattningen av arbetet. WBS bör inkludera alla mellanprodukter och slutprodukter.

Du kan dekomponera arbetet i ett projekt på olika sätt. Till exempel tillhandahåller GOST 19.102-77 vattenfall närmar sig och definierar följande stadier av mjukvarusystemutveckling.

• 1) uppdragsbeskrivning;
• 2) utkast till design;
• 3) tekniskt projekt;
• 4) arbetsutkast;
• 5) genomförande.

Om du följer denna standard bör dessa projektprodukter vara på första nivån i WBS. Om det vore nödvändigt att utveckla ett automatiserat kontrollsystem för att styra en kärnreaktor eller en bemannad rymdfarkost, så är det precis vad som borde ha gjorts. Men i kommersiell mjukvaruutveckling är detta tillvägagångssätt ineffektivt.

Den moderna kommersiella mjukvaruutvecklingsprocessen måste vara inkrementell. Detta innebär att på den översta nivån av projektnedbrytningen bör det finnas projektprodukterna, och på nästa nivå - de komponenter som dessa produkter består av. Komponenter kan sedan dekomponeras till "funktioner" - de funktioner som de måste implementera.

Valet av komponenter som utgör en mjukvaruprodukt är ett designelement på hög nivå som bör utföras i projekteringsfasen, utan att vänta på utvecklingen av alla funktionskrav för den mjukvara som utvecklas. Komponenter kan vara både applikationsdelsystem och infrastruktur eller nukleära sådana, till exempel ett autentiseringsundersystem, säkerhet, ett bibliotek med visuella komponenter i det grafiska gränssnittet (GUI). När du gör upp en grundläggande arbetsplan bör du inte sträva efter att detaljera allt arbete med IBS så mycket som möjligt, 3-5 nivåer räcker.

I samband med detaljering används ofta termerna "uppgifter" och "arbeten" omväxlande. Ändå är det mer korrekt att säga att uppgiften bestämmer uppnåendet av ett mellanresultat, och arbetet är en uppsättning åtgärder för att uppnå dessa resultat. Eftersom varje uppgift kräver att visst arbete utförs under givna begränsningar, kan man säkert tala om den otvivelaktiga "kartläggningen" av uppgifter till arbete och vice versa. Detta är anledningen till utbytbarheten av termer i vardagen. Samtidigt, genom att förstå skillnaderna mellan dessa koncept, kan du känna nyanserna i en processvy av produktskapande, och följaktligen av livscykeln för projekt, inklusive programvarusystemprojekt.

Generellt kan man tala om detaljering: "program - projekt - uppgiften är en operation. På fig. 3.12 visar ett exempel på sådan detaljering (endast funktionerna för uppgiften visas A).

Ris. 3.12.Ett exempel på användning av termer: program, projekt, uppgift, operation

Varje element i en sådan struktur har begränsningar och andra betydande egenskaper och data som är associerade med den. Betydelse hänvisar till deras nödvändighet eller användbarhet för beslutsfattande. Detaljdjupet och tillämpningsnivån för vissa termer beror på det specifika projektet, ledningskulturen, livscykelstandarder, projektets särdrag och omfattning, såväl som andra faktorer som är unika både för en viss organisation och för en viss projekt.

Alla delar av projektet (delprojekt och arbetspaket) ska hållas personligt ansvariga. För varje arbetspaket måste utgången vara tydligt definierad. Projektaktiviteter och uppskattningar bör överenskommas med nyckelteammedlemmar, ledningen för det implementerande företaget och, vid behov, med kunden. Som ett resultat av samordningen åtar sig teammedlemmarna skyldigheter för genomförandet av projektet och ledningen tar ansvar för att förse projektet med nödvändiga resurser.

WBS är ett av huvudverktygen (medlen) i projektledningsmekanismen, som mäter graden av uppnående av projektresultat. Dess viktigaste funktion är att säkerställa att alla projektdeltagare förstår och förstår hur projektet ska genomföras. Därefter kommer baslinjen att fungera som ett riktmärke för jämförelse med det nuvarande genomförandet av projektet för att identifiera avvikelser.

Kostnadsuppskattning av projektet. Processen att hantera ett mjukvaruprojekt börjar med en uppsättning aktiviteter som gemensamt kallas projekt planering. Den första av dessa åtgärder är göra en kostnadsberäkning för projektet. Det lägger grunden för andra projektplaneringsaktiviteter. När man utvärderar ett projekt är priset för misstag extremt högt. Det är mycket viktigt att göra en bedömning med minimal risk.

Den största svårigheten i den algoritmiska modelleringen av projektkostnaden är beroendet av kostnadsberäkningen på egenskaperna och parametrarna för den färdiga produkten. I ett tidigt skede av projektet är det omöjligt att exakt bestämma dessa egenskaper och parametrar. Det finns många metoder för att uppskatta kostnaden för PP, som bör användas parallellt. Om de erhållna resultaten är mycket olika betyder det att otillräcklig eller olämplig information använts för analysen. Programvarans pris ofta bestämt i förväg i syfte att tilldela ett kontrakt, vilket leder till att systemets funktionalitet i efterhand skräddarsys till dem som skulle motsvara detta pris.

Känd projektkostnadsuppskattningsmodell B. Boehma SOSOMO tar hänsyn till designegenskaperna, egenskaperna hos programvaran som skapas, hårdvara och personalkapacitet. Denna modell innehåller också verktyg för att bestämma varaktigheten av arbetet med projektet. Tiden för att slutföra arbetet är inte direkt proportionell mot antalet specialister som anlitats för projektet. Att involvera fler personer i ett projekt som ligger efter schemat kan ytterligare försena dess slutförande.

Algoritmiska projektkostnadsmodeller används för att hantera programvaruprojekt eftersom de stöder kvantitativ analys av parametrar. Dessa modeller låter dig utvärdera bidraget från varje enskild parameter till den totala kostnaden för projektet och att göra en objektiv (men inte immun mot fel) jämförelse av dessa parametrar.

Projektkostnadsuppskattning- ett av de viktigaste arbetena på projektet, som bestäms utifrån kostnaden för enskilda delar av projektet, förutsättningarna för att utföra arbetet, den faktiska personalen hos utförare, de metoder och verktyg som används. I kostnaden för projektet ingår även kostnaden för att underhålla projektet, d.v.s. datorer, mjukvara, rutor, möbler, telefoner, modem och mycket mer. Dessutom måste man ibland ta hänsyn till extra kostnader (till exempel för säkerhet). Ytterligare kostnader för projektet inkluderar inköp av testsystem, SABE-system etc. Huvuduppskattningen i projektet är projektkostnadsberäkning, uttryckt i dagsverken av artisters arbete med projektet. Denna bedömning görs i ett tidigt skede av underhåll och planering.

Den totala kostnaden för projektet bestäms av erfarna specialister med ett fel på upp till 10%. Kostnadsuppskattningar kan vara top-down, bottom-up eller baserade på kostnaden för ett tidigare tillverkat projekt. Experterna gör en pessimistisk, optimistisk och verklig bedömning genom att intervjua alla medlemmar i arbetsgruppen och justera varje bedömning för att få den mest rimliga. I vissa arbetsgrupper kan de pessimistiska och optimistiska bedömningarna vara mycket olika.

Algoritmiska metoder för att uppskatta kostnaden för ett projekt visa samband mellan projektkostnader och de faktorer som påverkar dem.

Det finns olika empiriska tillvägagångssätt för att uppskatta kostnaden för ett projekt, till exempel föreslås kostnaden för ett projekt bestämmas av formeln

PRIS = (a + b?)m(X),

där 5 är en uppskattning av systemets storlek; a, b, c - empiriska konstanter; X - vektor av kostnadsfaktorer med dimension fre - justeringsfaktor baserad på kostnadsfaktorer.

En mer förenklad uppskattning erhållen experimentellt uttrycks enligt följande:

KOSTNAD = 5,255 0,91 .

Dessa uppskattningar härleddes från analys av projekt där program varierade i storlek från 4 000 till 467 000 rader kod och skrevs på 28 olika programmeringsspråk för 66 datorer. Från 12 till 11 758 manmånader ägnades åt utveckling. Andra empiriska modelleringstekniker är också kända.

De första modellerna använde prisindikatorer, tog hänsyn till personal och egenskaper hos projektet, produkten och miljön. I modellerna ingår en bedömning av de tre stadierna av projektledning. I det första skedet byggs en prototyp för högriskuppgifter (användargränssnitt, mjukvara, interaktionssystem, implementeringar etc.) och kostnader uppskattas (exempelvis antal tabeller i databasen, skärmar och rapporteringsformulär etc.) .). I det andra skedet görs en bedömning av kostnaderna för att utforma och genomföra projektets funktionella punkter, vilket återspeglas i kraven på projektet. I det tredje steget avser utvärdering den färdiga konstruktionen, då storleken på systemet kan bestämmas i termer av färdiga programlinjer och andra faktorer.

Följande ekvation fungerar som grundmodell för den experimentella utvärderingen av projektkostnaden idag:

KOSTNAD = bS c m(X),

Var bS c - den initiala uppskattningen, som justeras med hjälp av kostnadsvektorn m(X) och redovisning av antalet gamla och nya anläggningar; Med- en parameter som ändras från noll till en för den första etappen av projektet och från 1,01 till 1,26 - för de återstående stegen.

Med ett formaliserat tillvägagångssätt baseras projektutvärderingen på användningen av LOC- och FP-mått.

Konstruktiv värdemodell(COSOMO - Constructive cost model), föreslagen av B. Boehm, kombinerar de mest välkända formaliserade projektutvärderingsteknikerna - LOC uppskattningar(LOC - Kodrader), som baseras på antalet rader med programkod. I processen att tillämpa denna modell bildas preliminära uppskattningar som gör att kunden kan presentera korrekta krav på kostnad och kostnader för att utveckla mjukvara, och det ger även möjlighet att upprätta en mjukvaruplan.

Funktionsorienterade FP-mått istället för att beräkna LOC-poängen mäts mjukvaruprodukten indirekt. Det är inte storleken som avses, utan produktens funktionalitet eller användbarhet. Författaren till detta mått är A. Albrecht. Att bestämma funktionsstorleken består av flera steg och börjar med att identifiera de funktioner som en applikation ska ha. International Function Point Users Group (IFPUG) har publicerat kriterierna för vilka applikationsfunktioner bestäms. Vid beräkning av FP-metriken används fem informationskarakteristika: antalet externa ingångar; antal externa stift (stift betyder rapporter, skärmar, utskrifter, felmeddelanden); antal externa förfrågningar; antal interna logiska filer; antal externa gränssnittsfiler.

Efter att ha samlat in all nödvändig information, fortsätt till metrisk beräkning - bestämma antal funktionspekare FP (Function Points) enligt en viss formel, där värdena för ingångskoefficienterna för att justera komplexiteten (varje koefficient kan ta följande värden: 0 - ingen påverkan; 1 - slumpmässigt; 2 - liten; 3 - medelvärde; 4 - viktigt; 5 - huvud) väljs empiriskt i som ett resultat av svar på 14 frågor som kännetecknar applikationens systemparametrar.

Metoden består i att mäta alla möjligheter hos en applikation på ett enhetligt sätt för alla projekt och att uttrycka applikationens storlek som ett enda tal, som sedan kan användas för att uppskatta antalet kodrader, kostnad och projekttid. Baserat på det bildas mätvärden för prestanda, kvalitet etc.

Fördel funktionsorienterade mått är att de inte är beroende av programmeringsspråket och är lätta att beräkna i vilket skede som helst av projektet.

Brister funktionellt orienterade mått - resultaten baseras på subjektiva data, inte direkta, utan indirekta mätningar används. Dessutom måste du ha vissa färdigheter för att tillämpa denna metod exakt och konsekvent.

Med hjälp av standardtabeller kan FP-uppskattningar enkelt omvandlas till LOC-uppskattningar, d.v.s. beräkna antalet kodrader efter funktionell storlek. Omräkningsresultaten beror dock på vilket programmeringsspråk som används för att implementera programvaran (till exempel i Java är en funktionell storleksenhet lika med 53 rader källkod). I sin tur låter antalet kodrader dig bestämma den totala arbetsintensiteten, uttryckt i manmånader, och tidpunkten för projektet.

När man utför en bedömning finns det två alternativ för att använda LOC- och FP-data: som bedömningsvariabler som bestämmer storleken på varje del av produkten, eller som mätvärden som samlats in under arbetet med tidigare projekt och som ingår i företagets metriska bas.

Exempel 3.1. Låt oss överväga proceduren för att utföra proceduren för att utvärdera arbete baserat på GC-metriken.

Steg 1. Destinationsområdet för den designade produkten är uppdelat i ett antal funktioner / i, / 2 , / 3 , som var och en kan vara

utvärdera individuellt

Steg 2. För varje funktion / schemaläggare genererar det bästa LOC n, det värsta YUS X och troligt YUS V uppskattningar. I processen att skapa uppskattningar används experimentella data från en metrisk bas eller intuitiva representationer av planeraren. Omfånget av möjliga värden för uppskattningarna motsvarar graden av den förutsedda osäkerheten.

Steg 3. För varje funktion med det förväntade värdet av uppskattningen bestäms:

YUS I + YUS X + 4 LOC^ oj=6"

yus.

Steg 4. Värdet på GC-prestandan för funktionsutvecklingen beräknas i enlighet med en av de tre reglerna.

Regel L. För alla funktioner tas samma värde, lika med den genomsnittliga produktiviteten för PR, jfr, taget från den metriska basen, dvs.

PR, = PR jfr; / = 1, 2, ..., P.

regel b. För /-th-funktionen beräknas ett anpassat prestandavärde baserat på det genomsnittliga prestandavärdet:

ys medel

MS coolt ’

Var USA onsdag - genomsnittlig LOC-poäng hämtad från den metriska basen (motsvarar genomsnittlig produktivitet).

Regel B. För /-th-funktionen beräknas det justerbara prestandavärdet enligt den valda analogen (tagen från den metriska basen):

LOSdays

ms vänta

Användningen av regel A i de efterföljande stegen ger minimal noggrannhet med maximal enkelhet i beräkningar. Regel B låter dig uppnå maximal noggrannhet med maximal komplexitet i beräkningarna.

Skede 5. Den totala kostnadsuppskattningen (manmånad) för projektet beräknas om regel A används:

om regel B eller C används:

b1y ^exp/

Steg 6. Beräknar den totala kostnadsuppskattningen för projektet om regel A eller B används:

KOSTNAD \u003d UDST jfr? YuS 0F /;

om regel B används:

KOSTNAD \u003d UDST an / ^YUS 0J / ,

där UDST cf är måtten för den genomsnittliga kostnaden för en rad med programkod; UDST en, - måttenhet av kostnaden för en linje av analogen (båda måtten tas från den metriska basen).

Utveckling av projektschema. Efter att ha bestämt arbetets arbetsintensitet är det nödvändigt att bestämma schemat för deras genomförande och den övergripande tidpunkten för projektet, d.v.s. upprätta ett projektschema Grundläggande schema representerar ett godkänt schema med de angivna tidsfaserna för projektet, milstolpar och delar av arbetsnedbrytningsstrukturen.

Grundschemat är i de flesta fall en del av kontraktet med kunden. Kontrollpunkter (milstolpar) fungera som punkter för analys av projektets tillstånd och beslutsfattande i formatet "§o eller 1 §О", därför bör de synligt visa projektets status. Det finns vissa krav för val och bildande av kontrollpunkter, till exempel är kontrollpunkten "Design färdig" oinformativ, metoden för sekventiella leveranser anses vara ett mer effektivt tillvägagångssätt: ovanstående kontrollpunkt är formulerad i formen " Krav 1, 3, 5 och 7 testning genomförd”.

Om verken inte är sammankopplade, kan vilket som helst av dem startas och slutföras när det är lämpligt för oss; alla jobb kan utföras parallellt, i vilket fall den minsta varaktigheten för projektet är lika med varaktigheten för det längsta jobbet. Men i praktiken finns det oftast beroenden mellan jobb, som kan vara "hårda", som "analys - design - kodning - testning - dokumentera" en specifik funktion, eller "mjuk", som kan ses över eller mjukas upp t.ex. , det sekventiella utförandet av uppgifter av en specifik utförare kan schemaläggas på en annan utförare, och istället för att utveckla grundläggande programvara, som bör föregå utvecklingen av applikationsprogramvara, kan du skapa "stubbar" som emulerar dess arbete.

Utvecklingen av en arbetsplan med deadlines för deras implementering kan utföras med CPM-kritiska vägmetoden eller PERT-programanalys- och utvärderingsmetoden. Projektplanen presenteras stegvis: "Planering", "Design", "Kodning", "Testning" och "Underhåll". Planering innefattar definition av specifikationer, budget och tidsplan, såväl som utvecklingen av projektplanen som helhet.

I projektkritisk väg metod(Kritisk väg) använder den längsta arbetskedjan i projektet. En ökning av varaktigheten av alla arbeten i denna kedja leder till en ökning av varaktigheten för hela projektet. Ett projekt har alltid minst en kritisk väg, men det kan finnas fler än en. Den kritiska vägen kan ändras under genomförandet av projektet.

När man utför ett projekt bör chefen först och främst vara uppmärksam på utförandet av uppgifter längs den kritiska vägen och övervaka uppkomsten av andra kritiska vägar. Som en tumregel bör den kritiska vägen ha mjukkopplade aktiviteter som alltid kan ställas om om deadlines riskerar att missas. Arbetsschemat är upprättat enligt schemat som visas i fig. 3.13.

Kravschema

till projektet

Ris. 3.13.Steg för att schemalägga arbete med ett projekt

När man planerar för programanalys och utvärderingsmetod PERT-händelse eller datum i planen är någon slags milstolpe (checkpoint) på vägen till genomförandet av enskilda projektaktiviteter och används för att visa/markera status för slutförande av vissa aktiviteter. I samband med ett projekt använder chefer milstolpar för att indikera viktiga milstolpar som ska uppnås under ett projekts gång.

Den sekvens av milstolpar som definieras av chefen kallas ofta milstolpeplan (enligt händelser). Att definiera en plan för att uppnå relevanta milstolpar skapar ett milstolpebaserat schema.

Nätverksuppdelningen av arbetet och Gantt-diagrammet kan också användas i planeringsfasen.

Nätverksuppdelning av verk(СРР) är en hierarkisk struktur för uppdelningen av projektuppgifter till deluppgifter. På den lägre nivån finns arbeten detaljerade om aktivitetselementen i CPP-nätverksmodellen.

Nätverksmodellen låter dig dela upp arbetet i huvudkomponenter och delkomponenter, bestämma verksamhetsområden som syftar till att uppnå komplexa mål, fördela de ansvariga för att utföra individuellt arbete på projektet och utföra rapportering med en generalisering av information om projektets resultat.

I det här fallet bör arbetsplanen återspegla de huvudsakliga stadierna av arbetet och det erforderliga arbetstillståndet i varje steg, uppdelningen av varje arbete i separata uppgifter, såväl som kopplingarna mellan arbetet, tidsintervallen för varje aktivitet, start- och sluttider för arbetet. Arbetsplanen innehåller olika typer av demonstrationer av projektets funktioner, delsystem, tillförlitlighet, skyddsutrustning etc. Plandokumenten innehåller även en uppsättning riktlinjer och metoder för att utföra specificerade operationer, upprätthålla systemkopplingar med andra delsystem m.m.

Arbetsplanen i form av en CPP-graf innehåller faser (stadier), steg och aktiviteter, inklusive de inledande och sista aktiviteterna i processen (Fig. 3.14).

Fas Och

Steg 1 Steg 2

Ris. 3.14.Projektplan steg för steg graf

En annan form av visuell presentation av arbetsplanen kan vara nätverksdiagram, inställd i form av en graf, vid vars hörn arbetspunkterna är belägna, och på bågarna - antalet dagar (veckor) som krävs för att slutföra dem (fig. 3.15). Dessa etiketter anger processexekveringstiden. En båge som växer fram från initialen

Ris. 3.15.

vertex och ingår i den slutliga vertexen, motsvarar tidsstämpeln "noll".

Grafen kan innehålla cykliska banor. Enligt grafen genomförs analysen av kritiska vägar, d.v.s. fastställa uppgifterna om varaktigheten av varje process.

Utvecklingen av ett schema består i att bestämma startpunkten (en händelse eller en uppsättning händelser som inträffade före början av exekveringen av ett processsteg och för vilken en uppsättning villkor beskrivs, inklusive början av processen), varaktighet ( tidsintervallet för vilket processen måste slutföras framgångsrikt), tidsperiod (datum, tills dess att processen helt eller delvis avslutar sin utförande) och slutpunkten för processen (kontrollpunkten där kunden kontrollerar kvaliteten på resultaten av processen).

Det mest visuellt grundläggande schemat kan representeras Gantt-diagram- Ett linjediagram, där projektuppgifterna representeras av tidsintervall, inklusive start- och slutdatum för deras genomförande, med hänsyn till eventuella förseningar. I det här diagrammet är schemalagda aktiviteter (delarna av strukturen för arbetsuppdelning) listade på vänster sida, datum visas överst och aktiviteternas varaktighet visas med horisontella staplar från startdatumet för denna operation till datumet för dess färdigställande (Fig. 3.16).

Projekt plan			L Elvest K., Goricheva R., Ivannikova O., Plotnikova O.
Kravspecifikation
2.1. Primär lista över krav				Goricheva R.
2.2. Krav modeller			Plotnikova O.
2.3. Systemarkitektur på hög nivå				till Sorokina O., Elvest K.
2.4. Kriterier för systemvalidering				Ivannikova O.
2.5. Mytologisk databasmodell				Chetchikova A.
2.6. Ordlista				Goricheva R., Plotnikova O.
Designdokumentation
3.1. arkitekturprojekt			N Elvest K.
3.2. Användargränssnittsprojekt			| Räknare A., Plotnikova O.
3.3. Delsystemsprojekt			Jag Sorokina O.
3.4. Databasmodell			N Ivannikova O.
3.5. Testplan				b Goricheva R.
Genomförandedokument
4.1. Implementeringsöversikt					Räknare A., Soroki		sha O., Iva
4.2. Användarguide					Elvest K., Goricheva
Testexekveringsdokument
5.1. Testning av vit box				N Counterchikova A.,			Sorokin
5.2. Integrationstestning		1^ Elvest K					En snickare
5.3. Certifieringstestning							cheva R., II
Slutförande och leverans av projektet							Disken

Ris. 3.16. Gantt-diagram

Utförandeprocessgrupp

Projektledningsprocessgrupper

Projektkvalitetsledning

säkerhet

kvalitet

Moderna verktyg för projektledningsprogram ger visualisering av projektets grafstruktur och arbetsprocesser, till exempel det allmänt kända och ganska ofta använda projektledningssystemet. Detta gör det möjligt för utvecklaren eller projektledaren att se hur olika aktiviteter utförs - sekventiellt eller parallellt, oavsett om de är på den kritiska vägen.

Projektledning är en symbios av teknik och konsten att lösa en unik uppgift i tid inom den budget som avsatts för dess mål. För att projektet ska bli framgångsrikt är det nödvändigt att nå en förståelse mellan företagets ledning och RM, hur det ska genomföras, av vem, när och vilken typ av arbete som ska utföras. Projektplanen ses inte som ett dokument, utan som en hel uppsättning dokumenterade beslut som besvarar ovanstående frågor. Jag presenterar för din uppmärksamhet en recensionsartikel som undersöker grunderna i projektplaneringsteknik.

Kärnan i projektplanering

Projektplanering involverar många sammankopplade iterationer, varav resultatet är en enda översiktsplan. Under projektplanen kommer vi att ytterligare förstå systemet med planerade aktiviteter, dokumenterade som ett resultat av sammanställning. Detta system består av parametrar kopplade på ett speciellt sätt, förutsatt att ett separat utvecklingsproblem löses. Dessa parametrar bildas baserat på ett antal funktionella områden av projektaktiviteter:

• innehåll;
• villkor;
• kosta;
• personal;
• leveranser;
• kommunikation;
• risker osv.

Planen är en viktig del av projektledningssystemet. Om RM lyckades utarbeta en detaljerad uppsättning planeringsdokument, har han rätt att förvänta sig garanterat mottagande av de erforderliga resultaten i slutet av arbetet. För detta måste tidslinjer, resurser och andra aspekter vara välplanerade. Innan en plan är framtagen är det omöjligt att veta hur mycket pengar och tid det kommer att ta att slutföra en unik uppgift. Utan en plan har chefen liten eller ingen riktning för att matcha arbetet med projektets mål.

Det måste förstås att planering inte alltid ger positiva resultat i slutändan, men negativa slutsatser kan inte ge mindre, och ibland fler, fördelar. Hur som helst ökar effektiviteten i investeringarna, och "spridningen" av den intjänade vinsten sker inte. Projektplanering lägger grunden för produktivt arbete och löser följande tillämpade problem.

1. Förtydliga, specificera målen och resultaten av evenemanget.
2. Bestäm sammansättningen och omfattningen av arbetet.
3. Uppskatta tidslinjer och budgetkostnader.
4. Gör upp ett schema och budget för huvudfaserna eller hela projektet.
5. Gör en uppdaterad bedömning av resursbehov för varje fas eller för hela uppgiften.
6. Gör en plan för resursförsörjning.
7. Utför en riskbedömning och skapa en riskhanteringsplan.
8. Förklara detaljerna i händelsen för kunden.
9. Kom överens om planen med nyckelintressenter.
10. Fördela ansvaret för arbete och uppgifter mellan deltagarna.
11. Godkänn översiktsplanen.
12. Förtydliga interaktionsplaner, planera förvaltningsprocedurer.

Platsen för projektledningsplanen i dess livscykel. Källa: PMBOK Guide 5

Platsen för planeringsprocesser bland andra processer för projektgenomförande. Källa: PMBOK Guide 5

Projektplanering kan inte vara "uppe i luften". Det föregås av initiering, och resultatet av dessa processer är själva genomförandet av projektet. Och vi är medvetna om ett antal viktiga punkter om vad planering är:

• knuten till en specifik tidpunkt i livscykeln för en unik uppgift och till dess betydande period (se diagrammen som visas ovan);
• iterativ - slutar inte efter att planerna är skrivna, kräver regelbunden uppdatering fram till den aktiva stängningsfasen;
• komplex - är inte begränsad till ett verktyg och inkluderar ett antal verktyg och relaterade utdatadokument.

Utvidgad sammansättning av planprocesser

Projektplanen är skild från projektledningsplanen och relaterade planeringsprocesser. Som vi redan har bestämt, i vid mening, menar vi med en plan ett förplanerat system av aktiviteter för vilka ordningsföljd, ordningsföljd och tidpunkt för arbetet är fastställda. I en snäv mening är en plan ett dokument som återspeglar ordningen på planerade åtgärder och tidsfristerna för genomförandet. Projektledningsplanen är resultatet av reglerade planeringsprocedurer (processer), där chefen tar på sig regelbundna, reglerade rutiner för att skapa planer som dokument.

Definitioner av grundläggande planeringskoncept från PMI. Källa: PMBOK Guide 5

Eventplanering inkluderar två grupper av processer: processer för direkt utveckling av planer och hjälpprocedurer. Utdata från ett utvecklingsblock är ett dokument som kallas en projektöversiktsplan. Den innehåller en kalenderplan, evenemangsbudget och ett antal andra dokument. Sammansättningen och innehållet i arbetet, de nödvändiga resurserna för deras genomförande bestämmer sekvensen, varaktigheten och mängden av kostnaderna för deras produktion.

Riskplanering (identifiering, identifiering och bedömning) och riskhantering påverkar inte bara utvecklingen av kalenderplanen utan även budgetkraven. Att klargöra mål, definiera gränserna för en unik uppgift och strukturera teamet och ansvarsskyldigheten lägger grunden för ett meningsfullt projektplaneringsarbete. Därefter uppmanas din uppmärksamhet till en modell av relationer mellan de viktigaste procedurerna för de processer som övervägs.

Modell av planeringsprocesser i projektledning

Det är känt att enligt PMI-standarden, i nästan varje avsnitt av PMBOK-riktlinjerna, allokeras ett helt block till planering. Baserat på diagrammet ovan är detta ganska naturligt. Den mest holistiska bilden av att hantera planering och skapa en enda översiktsplan visas av PMBOK-sektionen "Project Integration Management". Nedan visas en ruta för utvecklingsdataflödesdiagram för lokal händelsehanteringsplan.

Projektledningsplan Utvecklingsdataflödesdiagram Lokalt block

Det visuella blocket som presenteras ovan är anmärkningsvärt av ett antal anledningar. Kunskapsbasen om projektledning, all erfarenhet som vunnits i denna riktning, regelverk är avgörande för att planeringen ska lyckas. Detta gäller i lika hög grad standarder, mjukvara, organisationsstrukturer och kultur, förvaltningspraxis, infrastruktur och så vidare. Stadgan är en nyckelreferens för planering. Dessa processer är grunden för integrationen i översiktsplanen och erbjuder som input för utvecklingen av dess slutliga version:

• planer för hantering av projektparametrar;
• grundläggande planer för innehåll, kostnad och schema;
• planuppdateringar.

Stadier av utvecklingen av kalenderplanen

Som vi minns bygger projektledning på de "tre pelarna": arbetets innehåll, restriktioner och risker. Om en chef vet hur man arbetar bra med dessa tre parametrar, så finns det inga olösliga uppgifter för honom. Överväg utvecklingen av en kalenderplan från positionen för dessa tre positioner och dela upp denna process i etapper. Vi kommer att tillskriva det första och andra steget till arbetets innehåll.

1. Stadiet för att bestämma och skriva omfattningen av arbetet som en lista. Ganska ofta görs misstag på grund av att det är omöjligt att presentera alla verk på en gång. För en kvalitativ definition av operationernas omfattning är det användbart att använda grunderna för metoden för sekventiell arbetsnedbrytning.
2. Stadiet för att bestämma genomförandet av projektet när det gäller sekvensen och varaktigheten av arbetet, som beror på tekniken för deras genomförande. För att skapa ett kvalitativt resultat av detta skede är den redan namngivna metoden för sekventiell uppgiftsnedbrytning och expertbedömning av arbetets varaktighet med metoder som till exempel brainstormingmetoden väl lämpade.
3. Fastställande av tillgång på resurser. Evenemanget använder en mängd olika resurser: ekonomiska, material, arbetskraft, information, etc. Från ställningen av ekonomiska resurser krävs att arbetsschemat kopplas till finansieringsplanen. Begreppet knappa resurser introduceras: unika specialister och kapaciteter. Detta lämnar ett avtryck i arbetets sekvens och varaktighet.
4. Definition av yttre begränsningar. Dessa begränsningar inkluderar säsongsvariationer, tekniska processer för leverans av utrustning och olika externa händelser. Om vi ​​tar hänsyn till exemplet med kundens speciella önskemål (för specifika partners) eller externa evenemang (till exempel tidpunkten för slutförandet av en etapp vid tidpunkten för en nationell helgdag), så ingår sådana händelser i evenemanget i formen av milstolpar.
5. Stadiet för att skapa en riskhanteringsplan. Vi analyserar riskerna med projektet och tar fram en insatsplan för de största hoten. Utifrån denna plan slutför vi sedan kalenderplanen.

Det tredje och fjärde steget hänför sig till begränsningarnas positioner, det femte steget - till riskerna. Två baser för svar (aktiv och passiv) bestämmer beslutstillfället och dess inkludering i projektplanen. Aktiv respons innebär att vi i kalenderplanen inkluderar merarbete som syftar till att minimera risker. Detta kan påverka tidpunkten för annat arbete.

Som ett exempel kan vi överväga ett projekt för att lansera en ny tjänst på marknaden. Låt oss säga att risken för dess bristande efterfrågan på marknaden avslöjas. Sedan, för att minimera denna risk, är det nödvändigt att göra en ytterligare studie, och detta arbete måste inkluderas i kalenderplanen. Passiv respons innebär att ytterligare finansiella reserver bildas för identifierade risker. Schemautvecklingsstegen kan också presenteras i den logiska sekvensen som visas nedan.

Den logiska sekvensen av utvecklingen av schemat

Grundläggande projektplaneringssteg

För att skapa en översiktsplan implementerar projektledaren en serie planeringsiterationer. Under planeringsprocessernas gång bildas viktiga instrumentella och slutgiltiga dokument som tillsammans utgör översiktsplanen. Bland dem:

• arbetsnedbrytningsstruktur (WBS);
• Nätverks diagram;
• kvalitetsstyrningsplan;
• projekt schema;
• budget;
• organisationsschema;
• riskregister;
• kommunikationsplan;
• översiktsplan för projektet.

Visuell modell av projektplaneringsprocesser

Ovan finns en modell av planeringsprocesser för en projektuppgift. Du har möjlighet att se hela sammansättningen av processerna i diagrammet. Planeringsprocesser för poolbanor är knutna till nästan alla delar av projektledning. Många av de processer som anges i modellen kommer att ha möjlighet att presenteras i separata artiklar på vår webbplats. I detta dokument fokuserar vi kort på viktiga planeringsprocedurer.

1. Omfattningsdefinitionsprocessen genomförs för att klargöra projektets omfattning, gränserna med beskrivningen av dess produkt. Processen börjar med att klargöra evenemangets mål, dess koppling till företagets strategi och överväga alternativa tillvägagångssätt för genomförandet. PM ska vara tydlig med vilket arbete som ligger utanför projektets ram och vilka produktkraven är.
2. Processen för att bestämma omfattningen av arbetet. Grunderna som lagts i den tidigare processen utvecklas till ett komplett utbud av nödvändiga operationer för framgång. Deras struktur och sammansättning är relaterade till projektets huvudmål. WBS är det huvudsakliga verktyget som används av PM för att lösa problemet med denna process.
3. Definition av arbetsrelationer. Den logiska sekvensen av verk är ämnet och syftet med denna process. Det bästa verktyget och resultatet av processimplementeringen är en nätverksmodell (diagram, graf) byggd och optimerad med PERT- och CPM-metoden.
4. Processen för att uppskatta arbetets varaktighet. Att prognostisera varaktigheten för varje jobb som ingår i WBS och nätverksmodellen baseras på en mängd olika tillvägagångssätt. De huvudsakliga metoderna är metoder för utvärdering av analoger, "bottom-up", från utförare, expert- och parametrisk utvärdering.
5. Process för bedömning av resursbehov. Syftet med processen är att bestämma den nödvändiga mängden mänskliga resurser, resurser av maskiner och mekanismer. Resurser delas in i grupper: förnybara, förbrukningsbara och finansiella.
6. Schemalägg utvecklingsprocessen. Processen genomförs för att fastställa den uppskattade tidpunkten för enskilda arbeten och projektet som helhet. Frågan om att detaljera planen är viktig. Djupet av dess studie bör vara tillräckligt så att projektledaren kan kontrollera arbetets framsteg och fullgörandet av de tilldelade uppgifterna.
7. Utveckling av en översiktsplan för projektet. Den kombinerar alla resultat av evenemangsplaneringsarbetet i ett enda projektintegreringsdokument.

I den här artikeln har vi bekantat oss med den "maximala konfigurationen" av procedurer och dokument som skapar en projektplan. I praktiken, särskilt när projektet är medelstort eller litet i omfattning och är av regelbunden karaktär, krävs ofta inte överdrivna planeringsinsatser. I sådana fall kan du begränsa dig till typiska planeringslösningar och en ofullständig uppsättning dokument. Samtidigt är det knappast möjligt att klara sig utan en grundläggande dokumentär som finns i översiktsplanen, och de ansträngningar som läggs på utvecklingen av den lönar sig väl.

Projektplaneringsprinciper.

Arbetsfördelningsstruktur.

Projektering efter tidsparametrar.

Projektnätverksplaneringsmetoder.

Organisering av projektplaneringsaktiviteter.

Projektledning: lärobok / A.G. Ivasenko, Ya.I. Nikonova, M.V. Karkavin. - Rostov n/a: Phoenix, 2009. - P.177-212.

Mazur I.I. Projektledning: lärobok. manual för studenter som studerar i specialiteten "Organisationsledning" / I.I. Mazur [i dr.]. ; under den allmänna redaktionen av I.I. Mazur och V.D. Shapiro. - 6:e upplagan, Sr. - M.: Förlaget "Omega-L", 2010. -960 sid.

Kärnan i planering är att sätta upp mål och sätt att uppnå dem baserat på bildandet av en uppsättning arbeten (åtgärder, åtgärder) som måste utföras, tillämpningen av metoder och medel för att genomföra dessa arbeten, koppla de resurser som krävs för deras genomförande. , och samordna åtgärderna hos organisationer som deltar i projektet.

Aktiviteten att utveckla planer täcker alla stadier av skapandet och genomförandet av projektet. Det börjar med deltagande av projektledaren (projektledaren) i processen att utveckla konceptet för projektet, fortsätter med valet av strategiska beslut för projektet, såväl som med utvecklingen av dess detaljer, inklusive utarbetande av kontraktsförslag, tilldelning av kontrakt, utförandet av arbeten och avslutas med slutförandet av projektet.

På planeringsstadiet bestäms alla nödvändiga parametrar för genomförandet av projektet:

varaktighet för vart och ett av de kontrollerade delarna av projektet,

behovet av arbetskraft, materiella, tekniska och ekonomiska resurser,

leveransvillkor för råvaror, material, komponenter och teknisk utrustning,

villkor och volymer av engagemang från design, konstruktion och andra organisationer.

Projektplaneringsprocesser och procedurer bör säkerställa att projektet är genomförbart inom den angivna tidsramen, till lägsta möjliga kostnad, inom standardresurskostnader och av adekvat kvalitet.

I ett välorganiserat projekt bör ett specifikt ledningsorgan ansvara för genomförandet av varje mål: projektledaren för alla mål (projektuppdraget), ansvariga utförare för privata mål, etc. Det vill säga att trädet av projektmål ska sammanfalla med strukturen för den organisatoriska enhet som ansvarar för genomförandeprojektet. För detta utvecklas en så kallad ansvarsmatris, som definierar det funktionella ansvaret för projektutförarna, specificerar uppsättningen av arbeten för genomförandet av vilka de är personligen ansvariga.

Ju högre nivå det styrande organet har, desto mer generaliserade, aggregerade indikatorer fattar det beslut om förvaltningen av underordnade enheter. Med en ökning av nivån på hierarkin ökar tidsintervallet mellan utfärdande av planmål, övervakning av deras genomförande etc. Samtidigt, i intervallen mellan ingripandemomenten (utfärdande av planmål, fastställande av riktmärken) , etc.), arbetar divisioner på lägre nivå självständigt, oavsett divisioner på samma eller angränsande nivå. Enheternas oberoende funktion bör förses med vissa resursreserver, som också behöver planeras.

Huvudsyftet med planering är att bygga en projektgenomförandemodell. Det är nödvändigt att samordna projektdeltagarnas aktiviteter, det bestämmer i vilken ordning arbetet ska utföras etc.

Planering är en uppsättning sammankopplade procedurer. Det första steget i projektplaneringen är utvecklingen av initiala planer, som ligger till grund för att utveckla projektbudgeten, fastställa resursbehov, organisera projektstöd, sluta kontrakt etc. Projektering föregår projektstyrning och ligger till grund för dess tillämpning, eftersom en jämförelse görs mellan planerade och faktiska siffror.

Planering är en av de viktigaste processerna för ett projekt, eftersom resultatet av dess genomförande vanligtvis är ett unikt objekt, produkt eller tjänst. Planeringens omfattning och detalj bestäms av användbarheten av den information som kan erhållas som ett resultat av processen och beror på projektets innehåll (avsikt).

Planeringsprocessen i sig kan inte helt algoritmiseras och automatiseras, eftersom den innehåller många osäkra parametrar och ofta beror på slumpmässiga faktorer. Därför kan de planalternativ som föreslås som ett resultat av planering skilja sig om de utvecklas av olika team, där specialisterna bedömer påverkan av externa faktorer på projektet olika.

TILL kärnprocesser planering inkluderar:

planering och dokumentation av projektets omfattning;

upprätta en budget, uppskatta kostnaden för resurser som krävs för att utföra projektets arbete;

definition av verk, bildande av en lista över specifika verk som säkerställer att projektmålen uppnås;

arrangemang (sekvens) av arbetet, definition och dokumentation av tekniska beroenden och restriktioner för arbetet;

bedömning av arbetets varaktighet, arbetskostnader och andra resurser som krävs för att utföra individuellt arbete;

beräkning av schemat, analys av tekniska beroenden av arbetets utförande, arbetets varaktighet och resursbehov;

resursplanering, bestämma vilka resurser (människor, utrustning, material) och i vilka mängder som kommer att krävas för att slutföra projektets arbete. Bestämma i vilka termer arbetet kan slutföras, med hänsyn till de begränsade resurserna;

budgetering, koppla beräknade kostnader till specifika aktiviteter;

skapa (utveckling) av en projektplan, insamling av resultaten från andra planeringsprocesser och deras sammansättning till ett gemensamt dokument.

Hjälparprocesser utförs efter behov. Dessa inkluderar:

kvalitetsplanering, definiera kvalitetsstandarder som är lämpliga för ett givet projekt och hitta sätt att uppnå dem;

organisationsplanering (design), definition, kartläggning, dokumentation och fördelning av projektroller, ansvar och underordningsrelationer;

val av personal, bildande av ett projektteam i alla skeden av projektets livscykel, en uppsättning nödvändiga mänskliga resurser som ingår i projektet och arbetar i det;

planering av kommunikation, bestämning av projektdeltagarnas informations- och kommunikationsbehov: vem och vilken information som behövs, när och hur den ska levereras till dem;

identifiera och bedöma risker, bestämma vilken osäkerhetsfaktor och i vilken utsträckning som kan påverka projektets framsteg, fastställa det gynnsamma och ogynnsamma scenariot för projektgenomförande, dokumentera risker;

leveransplanering, bestämma vad, hur, när och med vem som ska köpas och levereras;

planeringsförslag, dokumentera produktkrav och identifiera potentiella leverantörer.

Bestämning av planeringsnivåer är också föremål för planering och utförs för varje specifikt projekt, med hänsyn till dess särdrag, skala, geografi, tidpunkt etc.

Under denna process bestäms typen och antalet planeringsnivåer som motsvarar de tilldelade arbetspaketen för projektet, deras materiella och tidsmässiga samband.

Planer (grafer, nätverk) som ett uttryck för resultaten av planeringsprocesser bör sammantaget bilda en viss pyramidstruktur som har egenskaperna att aggregera information, differentierad av nivåer av medvetenhetshantering, åtskilda av utvecklingstidsramar (kortsiktig, medellång- sikt och långsiktig). Planeringsnivåerna och plansystemet bör byggas enligt principerna om "feedback", vilket säkerställer en konstant jämförelse av planerade data med faktiska data och har stor flexibilitet, relevans och effektivitet.

Planering är grunden på vilken ett projekt byggs. Och ju starkare det är, desto mer sannolikt är det att projektet blir framgångsrikt. För detta finns en projektledningsplan, som består av tre block: aktiviteter (mål, projektkoncept, resursuppdrag etc.), uppgifter och resurser (människor, utrustning, pengar etc.).

Vad är en projektledningsplan?

En projektledningsplan är ett dokument som innehåller alla delar av ett projekt: från aktiviteter och resurser till kriterier för att bedöma framgång och risker. Genom att ta fram denna plan försöker projektledaren täcka hela projektet, från initiering till stängning.

Planen är det viktigaste dokumentet när man skapar ett projekt – på nivån för intressenternas engagemang. Precis som ett projekt inte kan genomföras utan medverkan av en intressent, kommer ett projekt att misslyckas utan en genomtänkt förvaltningsplan. Dokument som en plan för hantering av kostnader, deadlines, kvalitet, risker, resurser m.m. ingår i en större förvaltningsplan.

I traditionell projektledning ger planen begränsningar i alla fem faserna: starta, planera, utföra, övervaka och slutföra. Agila projekt kan inte planeras till slutet på grund av karaktären av att arbeta med en agil modell. Därför utvecklas och godkänns planer under projektets livscykel.

Det finns vanligtvis två förvaltningsplaner involverade i ett projekt:

1. bas— godkänd av ledningen (kund). Det avgör framgången för uppgifterna, styr timingen och kvaliteten.
2. arbetstagare- till skillnad från den tidigare, gör projektledaren ändringar i den enligt ny information eller uppgifter.

Vad är det för?

En bra plan bör svara på grundläggande frågor:

• Varför?— Vilket problem löser projektet, vad är dess värde? Varför är projektet sponsrat?
• Vad?— Vilka är projektets huvudprodukter (leveranser)? Vad behöver göras för att lyckas?
• WHO?— Vem kommer att involveras i arbetet med projektet och vad kommer var och en av deltagarna att ansvara för? I vilket format kommer de att organiseras?
• När?- Vad är tidsramen för projektet? När kommer viktiga milstolpar att uppnås?

En milstolpe är en milstolpe under ett projekt (till exempel att flytta till en ny iteration).

Målen för projektledningsplanen är:

Nyckelkomponenter i en projektledningsplan

Det kommer inte att fungera att göra planer enligt en mall, men det finns en uppsättning grundläggande element, med vetskap om vilka, det är lätt att bygga ett ramverk för ett framtida projekt:

• kort beskrivning av planen- ett par stycken om de viktigaste delarna av projektet, som beskrivs i planen.
• strategisk och organisatorisk anpassning- detta inkluderar resultaten av analysen av intressenter och organisatoriska mål som kommer att stödjas under genomförandet av projektet.
• definition av projektets omfattning- detta stycke innehåller följande delar: uppgift och mål, förväntade resultat, verktyg PBS Och WBS. I avsnittet är det också viktigt att ange kvalitetsspecifikationer - kriterier för effektiviteten hos en produkt eller tjänst ur kundens synvinkel.

PBS (product breakdown structure) är ett verktyg för att analysera, dokumentera och kommunicera projektresultat. PBS är en del av den produktbaserade planeringsmetodiken (en av huvudmetoderna i PRINCE2-projektledningsmodellen).

WBS (work breakdown structure) - en hierarkisk uppdelning av projektarbete i mindre uppgifter (operationer) till den nivå där sätten att utföra arbetet är tydliga, det finns möjlighet till utvärdering och planering.

• genomförbarhetsbedömning och beredskapsplaner- innehåller en bedömning av projektets ekonomiska, tekniska och organisatoriska genomförbarhet, identifiering och analys av risker, erbjuder handlingsplaner i kritiska situationer för att eliminera riskfaktorer.
• restriktioner- En lista över kända restriktioner som ålagts av miljön eller ledningen (fast budget, brist på resurser etc.).
• projektgruppens krav— definiera projektgruppens organisation, deltagarnas roller och ansvar. Det är här utbildningskraven kommer in.
• materialkrav- innehåller delar av webbplatsen, mjukvara, hårdvara och andra resurser för att slutföra projektet.
• schema och milstolpar- Det här avsnittet definierar milstolpar och schema för projektaktiviteter, inklusive tre nyckelelement: leveranser (arbetsresultat), datum eller varaktighet och kritiska beroenden.
• budget (uppskattning)- förväntade utgifter delas vanligtvis in i tre typer: kapital (inköp av ett lager för att lagra produkter), förbrukningsvaror (veckovisa inköp av material för inköp) och arbete (betalning av löner till teammedlemmar)
• Hantering av risker— En detaljerad beskrivning av riskhanteringsprocessen: från identifiering (genom brainstorming, intervjuer, SWOT-analys) till valet av ett övervakningssystem (pro- eller reaktivt).
• förändringsledning- i likhet med föregående stycke, gäller endast möjliga ändringar (och det kommer att finnas många av dem). Här är det värt att föreskriva en algoritm för att göra förändringar, hanteringsmetoder (ADKAR, AIM och andra), en formel för att beräkna sannolikheten för framgång för förändringar, etc.
• kommunikationshantering— Punkten berör både teamet och intressenterna. Projektledaren i detta avsnitt ska beskriva vilket kommunikationssystem som kommer att användas och kanalerna för att kommunicera projektresultatdokumentation till projektparterna.
• bilagor- alla dokument kan komma hit: från enskilda anteckningar till presentationer och certifikat.

Listan över delar av planen kompletteras beroende på detaljerna för ett visst projekt.

Grundläggande och arbetsplaner för projektet

Under arbetet med ett projekt, projektledaren, teammedlemmar och Intressenter arbetar med två typer av planer:

• bas- primär, stabil, godkänd av kunden eller annan förutbestämd person, överenskommen med alla berörda parter.
• arbetstagare- version av basplanen, som visar ändringar i termer, kostnad och andra projektparametrar.

Under utvecklingen av projektet du kan jämföra grund- och arbetsplanerna, att förstå var arbetet ”saknar” och där tvärtom projektet slutförs snabbare (mer ekonomiskt) än planerat. I sällsynta fall förändringar under projektets gång görs i den grundläggande förvaltningsplanen.

I Worksection låter Gantt-diagrammet dig se skillnaden mellan grund- och arbetsplanen
(blå - total tid, röd - försenade uppgifter, grön - slutförda uppgifter i tid)

Utveckling av en projektledningsplan

Precis som med nyckeldelarna i en projektledningsplan finns det inget rätt sätt att utveckla den.

Vi har utformat en enkel steg-för-steg-procedur för att skriva en plan, bestående av 16 punkter:

1. Bestäm startvillkoren för att utveckla en plan- det är viktigt att förstå med vem du kommer att utveckla det (ensam, med deltagande av ledning, intressenter), var och när, etc. Det är viktigt att föreskriva de tekniker (till exempel brainstorming) och programvara (som Microsoft Visual Studio) som kommer att användas för att skapa planen - detta kommer att spara mycket tid och förenkla uppgiften.
2. Bestäm startvillkoren för projektet- detta beskriver projektets innehåll, en lista med krav på resultaten och dess ledning. Till exempel skapades ett projekt för att sälja högkvalitativa neonspinnare med superhjältetryck. Som ett resultat av det framgångsrika genomförandet av det årliga projektet måste 100 000 enheter av varor säljas inom 12 månader från projektets start, varefter försäljningen av verksamheten kommer att ske. Projektledningsstrukturen kommer att bestå av en allmän projektledare på centralkontoret och relevanta avdelningar på projektets regionkontor.
3. Definiera de åtgärder som ska vidtas för dem som kommer att göras av projektgruppen, och outsourcing.
4. Skapa ett projekt WBS genom att dela upp det i mindre, hanterbara bitar. Detta liknar Agile-metoden, när hela koden är uppdelad i många små arbetsstycken.
5. Skriv en uppsättning uppgifter för att utföra varje del av WBS och skapa ett beroende mellan dem. Så uppgiften att köpa och utrusta ett regionalt lager för lagring av spinnare kan slutföras först efter att ha analyserat marknaden och sålt en viss mängd varor i ett visst område.
6. Bestäm vilka kompetenser som krävs för att slutföra varje uppgift. Det är här viktigt att inte anpassa de kunskaper och färdigheter som krävs för att passa potentiella projektdeltagare, utan att fokusera på de "ideala" kraven.
7. Beräkna tid och kostnad att slutföra uppgifter.
8. Designa ett projekt. Tekniken är bra bara för dagligvarubranschen och det är lätt att visa den genom diagram (till exempel ett Gantt-diagram).
9. Skapa ett projektschema- start-, mellan-, slutdatum. Till exempel, ett förenklat schema: den 1 november lanseras ett projekt, den 1 december, försäljningsstarten för det nya året, den 31 december, som summerar resultatet av nyårsförsäljningen, den 15 januari, lanseringen av en specialiserad linje för alla hjärtans dag, den 20 februari, sammanfattning, etc.
10. Beräkna kostnaden för projektet(i vårt fall, hur mycket det kommer att kosta att framgångsrikt sälja 100 000 spinnare och sälja verksamheten).
11. Ange kvalitetskrav(till exempel föreskrivna kvalitetsstandarder för tillverkning av spinnare).
12. Tilldela specifika personer ansvariga för uppgifter. Det är här punkt 6 kommer väl till pass, med listan över vilka du kommer att associera teammedlemmarnas kompetenser.
13. Planera formatet för arbetet med intressenter- välja kommunikationskanaler, bestämma graden av deras engagemang i arbetet med projektet, etc.
14. Beräkna riskerna (till exempel genom att använda den kumulativa metodformeln). I vårt exempel med spinnare kan detta vara en banal övermättnad av marknaden, brott mot villkoren i kontraktet av speditörer, etc. Använd data från föregående stycken i riskanalysen.
15. Skriv ner projektbegränsningar och, med hänsyn till dem, skriv in data i projektledningsplanen. I vårt fall levereras spinnerdelar från Kina, montering sker i Ukraina, och detta begränsar redan möjligheten till strikt kvalitetskontroll av material och snabba byten.
16. Gå igenom alla punkter i planen igen att nå zen. Det återstår att slutföra listan över inköp och krav på dem, samordna med intresserade parter - och du har en färdig projektledningsplan i dina händer.

Den kumulativa riskberäkningsmetoden är en metod för att bedöma riskfaktorer som kan hindra dig från att få den planerade inkomsten. När man konstruerar en diskonteringsränta med denna metod utgår man från den riskfria avkastningen och lägger till avkastningsräntan för risken att investera i ett projekt eller företag.

I Vladislav Gagarsky, som ett exempel, ger han följande påståendeschema:

1. Projektgruppsledarna skickar den gemensamt framtagna planen till projektledaren.
2. Chefen godkänner projektledningsplanen eller, vid fel, ombesörjer ändringar.
3. Projektledaren skickar den godkända planen till projektgruppsledarna för vidare implementering.

Men detta schema är mer lämpligt för färdiga lag som genomför flera projekt efter varandra eller har ändrat sin verksamhetsprofil. För dem som "från grunden" bestämt sig för att skriva och godkänna en projektledningsplan, kommer tekniken inte att fungera. I sådana fall godkänns grundprojektet av chefen för företaget eller projektet (kunden) på förslag av projektledaren.

Dom

Inte livräddare.

Det kommer till en början att vara en deklaration utan verktyg för dess genomförande. Verktyget kan bli med det projekt / uppgifter / deluppgifter och med hänsyn till pengar, tid och ansvarsfulla personer rätt i arbetsuppgifterna. Detta är det bästa sättet att organisera det visuella arbetet i företaget, var kopplingen mellan baslinje och arbetsplaner är uppenbar för alla.

Men planen är starten som kommer att avgöra 50 % av projektets framgång.

Föreställ dig att du ställs inför behovet av att utveckla en webbplats för första gången. Hur man inte glömmer något på vägen och redan i det inledande skedet för att uppskatta de ekonomiska kostnaderna och arbetskostnaderna? Nedan delar jag med mig av min erfarenhet av att utarbeta en projektplan för att utveckla en marknadsföringswebbplats för ett tjänsteföretag.

Det finns enklare alternativ, som att skapa en landningssida med hjälp av tjänsten LP Generator eller liknande. Du kan inte begränsas till en ensidigare och skapa en fullfjädrad webbplats på en webbplatsbyggare. Det här är arbetsalternativ, jag avråder ingen från dem. Allt beror på de mål som du sätter upp för webbplatsen och följaktligen på dina krav. Jag föreslår en projektplan för en flersidig SEO-orienterad webbplats utan att använda en webbplatsbyggare.

Definition av de viktigaste arbetsblocken

Uppgiften att utveckla en sajt omfattar olika stadier där olika specialister är involverade. Jag börjar med att identifiera de viktigaste stora blocken. Vid det här laget ser planen ut så här:

1. Klassisk marknadsföring: lära känna produkten, konkurrenter, utveckla en USP
2. Urval av semantik
3. Utveckling av webbplatsstruktur
4. prototypframställning
5. Design
6. Layout
7. Programmering
8. Testning
9. lansera

Bilden blir tydligare, men det finns inte tillräckligt med detaljer, så jag delar upp stora uppgifter i mindre.

Ungefärligt antal och typer av sidor

För att beräkna planen för projektet sammanställer jag en vägledande lista över webbplatssidor och de typer av uppgifter som krävs för denna sida. Det hjälper mig att beräkna arbetstimmar för uppgifter. Listan över sidor kommer sannolikt att ändras under arbetets gång, men i detta skede kommer det att räcka för beräkningar. Bordet kommer att se ut ungefär så här.

Sidor (masker)	Antal sidor	Samla SA	TK från en SEO-specialist	Text	Prototyp	Design	Layout	Programmering
Hem	1	1	1	1	1	1	1	1
till företagskunder	1	1	0	1	1	1	1	1
Tjänster (sektionssida)	1	1	1	1	1	1	1	1
Tjänster avsnitt	3	3	3	3	2	2	2	2
Tjänster underavsnitt	7	7	7	7	1	1	1	1
Frågor och svar (FAQ)	1	0	1	0	1	1	1	1
Enstaka artikelsida	X	X	X	X	1	1	1	1
Kontakter	1	0	1	1	1	1	1	1
Om företag	1	0	1	1	1	1	1	0
Priser	1	0	1	0	1	1	1	1
	17	13	16	15	11	11	11	10

Detaljera listan över uppgifter

För att beräkna arbetskostnaden försöker jag dela upp arbetsuppgifterna så att en ansvarig specialist kan tilldelas varje uppgift. Omedelbart till listan över uppgifter lägger jag till kolumnen "Entreprenör" och det beräknade antalet timmar för att slutföra uppgiften.

Uppgift	Testamentsexekutor	Kolla på	En kommentar
Identifiering av kärntjänster och identifiering av konkurrenter	Marknadsförare	6	Det är viktigt att förstå omfattningen av webbplatsen. Efter att ha studerat de tävlande kan listan justeras.
Expressanalys av konkurrenters webbplatser	Marknadsförare	24	Beroende på kunskapen om marknaden och projektets komplexitet kan tiden anpassas.
Uttalande av fördelar och utveckling av USP	Marknadsförare	8	Baserat på information om företaget och konkurrenter tar vi fram huvuderbjudandet och svarar kort på frågan: ”varför ska du köpa av oss”.
Inledande planering av platsstruktur	Marknadsförare	2	Först då kan den grundläggande strukturen för webbplatsen sammanställas, som i detta skede ser ut som en lista med sidor.
Samling av den semantiska kärnan och segmentering	SEO-specialist	26	En SEO-specialist samlar in en komplett lista med frågor och kombinerar dem i semantiska grupper. Tiden jag beräknar är cirka 2 timmar för varje sida i den preliminära strukturen på sajten (för vilken SEO är relevant, förstås). Om en webbplats redan finns, bör du ta hänsyn till frågor där webbplatsen redan finns i sökresultaten.
Samordning och godkännande av detta. kärnor	Marknadsförare	8	Det är bättre att samordna den semantiska kärnan med kunden för att undvika missförstånd i framtiden.
Korrigering av webbplatsens struktur, med hänsyn till familjens kärna	SEO-specialist	6	SEO-specialistförslag för listan över sidor, navigering.
Förfining och koordinering av webbplatsens struktur, med hänsyn till familjens kärna	Marknadsförare	4	I detta skede får vi skelettet av webbplatsen. Vidare antar jag förekomsten av typiska sidor. Till exempel att alla sidor av olika tjänster är gjorda efter samma mall.
Grundläggande SEO-riktlinjer för innehåll för sidor för sida	SEO-specialist	8	För att inte behöva omarbeta prototyper eller ens färdiga sidor rekommenderar jag att du redan i detta skede får SEO-önskningar. Det här stycket handlar om block på sidan. Jag lägger 0,5 timme på 1 sida.
SEO TOR för sidinnehåll	SEO-specialist	30	Det här stycket handlar om rekommendationer om de texter som ska finnas på sidorna. Jag lägger in 2 timmar per sida.
Att skriva texter	Copywriter/Marknadsförare	90	Om du har turen att hitta en bra copywriter kan du anförtro skrivandet av texter till honom. I de flesta fall kommer texter till servicesidor, unika sidor som "Om företaget", "404", "Kontakter" m.m. Jag skriver själv. Jag tar tiden enligt mina egna normer, så jag avsätter 6 timmar per sida, men det kan ändras från projekt till projekt.
Sidprototyper	Marknadsförare	82	Jag planerar också 6 timmar för 1 sida, plus 2 arbetsdagar för den huvudsakliga, eftersom det är nödvändigt att förbereda layoutlayout, sidhuvud och sidfot. Det är bekvämt för mig att göra prototyper parallellt med att skriva texter.
Utarbetande av tekniska specifikationer för konstruktören	Marknadsförare	13	Även om prototyperna i Axure RP är ganska beskrivande, finns det några punkter som måste ges till designern, särskilt i början. Beskriv stilen, färgschemat. Det är bekvämt för mig att skicka exempel på stil och diskutera verbalt för att vara säker på att vi pratar om samma sak.
Hemsidadesign + rekommendationer för adaptiv	Designer	16	Eftersom det nu är omöjligt att leva utan en mobilsajt råder jag dig att tänka på en adaptiv version redan i detta skede. Det visade sig vara ett fungerande schema när designern inte förbereder flera designalternativ, utan skriver rekommendationer. Det går åt mindre tid och resultatet är detsamma.
Design av andra sidor + rekommendationer för adaptiv	Designer	66	Jag räknar 6 timmar per sida. Någonstans kan det vara mer, någonstans mindre. Vid denna tidpunkt fastställer jag också utarbetandet av rekommendationer för layoutdesignern för adaptiv layout.
Godkännande och godkännande av designen	Marknadsförare	14	Att godkänna layouter tar alltid tid, speciellt när det gäller att godkänna stilen och designen på de första sidorna. Jag råder dig att planera tid för detta.
Förberedelse av optimerade metataggar och H1	SEO-specialist	16	I allmänhet kan det här objektet aktiveras när som helst före lanseringen av webbplatsen, men glöm inte!
Utarbetande av tekniska specifikationer för layout och programmering	Marknadsförare	17	Eftersom jag funderar på en variant av tjänstesidan utgår jag inte från moduler som är svåra att implementera. Därför lägger jag 1,5 timme per sida.
SEO-rekommendationer för layout- och programmeringsstadiet	SEO-specialist	6	Återigen, för att inte göra om det, är det bättre att omedelbart förbereda webbplatsen, med hänsyn till ytterligare marknadsföring i sökmotorer.
Layout (adaptiv)	Sättare	104	Allt beror på komplexiteten i layouterna. Jag antar 2 dagar för utbyggnad av infrastruktur, förberedelser för arbete och 8 timmar för 1 sida.
Godkännande och samordning av layout	Marknadsförare	24	Du kan inte inkludera denna artikel, men du måste fortfarande kontrollera layouten, skriva ändringar och acceptera den. Beroende på team och projekt kan detta ta mycket tid. Därför rekommenderar jag att lägga det i projektet.
Programmering	Programmerare	80	Sammansättning av olika sidor till en färdig webbplats. Slutsats i CMS av moduler för vidare hantering av webbplatsens innehåll utan medverkan av utvecklaren.
Godkännande och godkännande av mjukvarudelen	Marknadsförare	15	För att vara ärlig verkar jag inte lägga mycket tid på den här uppgiften. Utan detta stadium kommer du inte att klara dig 100%, lämna tid för det.
Testning och felsökning	Marknadsförare	40	Denna uppgift är att klicka på alla knappar, se alla sidor, prova alla funktioner i CMS och kolla sidan i olika webbläsare och på olika enheter. Om projektet är litet kan det räcka med att kontrollera på egen hand, för komplexa inkluderar vi testare.
Lansering av stridsversionen av webbplatsen	Programmerare	8	Fram till denna punkt har alla kontroller utförts på en testplats. Först nu går vi över till en öppen sida för användare.
Connecting analytics + CallTouch + sätta upp mål	Marknadsförare/programmerare	16	Ett valfritt föremål som börjar bli normen, eftersom det utan analys är omöjligt att förstå hur sajten klarar av sina uppgifter.
Rekommendationer för primär SEO-optimering	SEO-specialist	8	Vi lyssnar noga på vad SEO-specialisten säger till oss och följer hans rekommendationer. Om webbplatsen ursprungligen förbereddes enligt den nuvarande planen bör det finnas ett minimum av förbättringar, men vi förbereder robots.txt och webbplatskartan först nu.
Implementering av SEO-rekommendationer	Typsättare/programmerare	16	Jag räknar 2 arbetsdagar.
Kontrollera tillämpningen av SEO-rekommendationer på testsidan	Marknadsförare	4
Tillämpa SEO-rekommendationer på huvudsidan	Programmerare	3

Beräkning av projektvillkor

Det mesta är klart, sedan målar vi de mottagna timmarna för dygnet. Vissa etapper kommer att löpa parallellt. Till exempel ger jag en beräkning när 1 specialist i varje riktning arbetar med ett projekt respektive, max antal arbetstimmar per dag är 8 timmar per specialist.

Tabellen är stor, så jag ger en länk till ett Google-kalkylblad, där du kan se det färdiga resultatet.

I slutet ger jag arbetskostnaderna för varje specialist. Genom att känna till priset per timme kan du alltså uppskatta kostnaden för projektet. Tabellen ser ut så här.

Jag lägger också till en allmän tabell över villkoren för projektet.

	Timmar	dagar
Total tid för projektet:	760	62
Arbetsdagar per månad		20
Projektperiod (månader)		3.1

Jag förstår att 62 dagar inte är lika med 760 timmar. Skillnaden beror på att vissa uppgifter utförs samtidigt av olika specialister.

Denna webbplatsutvecklingsplan är baserad på personlig erfarenhet och är inte det enda rätta alternativet. Men jag hoppas att det kommer att vara användbart som utgångspunkt om du utvecklar en sajt för första gången eller, som företagsrepresentant, planerar att beställa en sajt i en studio och vill förstå denna process bättre.

Facebook

Twitter

I kontakt med

Klasskamrater

Google+