Viktigt med tidig, tät och bred dialog

Sven R, arbetsro.... in your dreams. Det är ju just korridorsplaneringen som ska bort. Planarkitekterna får 10 veckor på sig att vara hur kreativa som helst. Om det sedan inte passar arkitekter att arbeta utifrån en dialog med beställarna (medborgare och politiker) så är det något fel på självbilden. Men jag tvivlar att de generellt har den inställningen som du hävdar. Erik Berg på inobi var tydlig i Pennypodden. Arkitekter är lakejer som arbetar på beställarens uppdrag.

Samråden idag fyller bara en ren kontrollfunktion. När det gått så långt som till samrådet så rättas rena felaktigheter till men that's it. Funktionen kommer vara kvar som dels juridiskt gällande och dels som kontrollinstans för nämnda felaktigheter där bland annat förvaltningar, bolag, myndigheter och länsstyrelsen granskar. Förhoppningsvis blir det lite mindre gnäll om den föreslagna dialogprocessen har verkat innan. Men det kan man ju inte veta. Det är till sist politikerna som ska ta beslutet och med den föreslagna dialogprocessen är de väl informerade om vad ett brett spektrum av medborgare tycker.

KRISTER, vad menar du med din kommentar 18:27. Inte bara missar du namnet på den jag förmodar du tilltalar, ditt "förslag" är ju heller inget förslag utan goddag yxskaft.

Woyland Wallin, mycket intressant information du kommer med. Jag har hört liknande tongångar om att små projekt skulle vara ineffektiv ur SBKs synvinkel. Det är något djupt fel i tankesättet. Visst blir det jobbigt att planera en massa små projekt om man ska hålla på med en massa ovidkommande detaljer. Men varför inte köra ett ganska standardiserat planförfarande. Eller ännu hellre börja förhandsplanera en stadsplan över stora områden så det i förhand är klart vad som gäller.

Sven R, jag ser i din första kommentar att du missuppfattade förslaget. Det är inte tanken att planarkitekterna ska interagera "varje vecka". Jag förslog att de skulle få 10 veckor på sig att köra sin process. Men den tiden kan ju åtminstone delvis anpassas till planarkitektens önskemål och planens komplexitet - men bara lite. Även planarkitekter behöver tydliga deadlines för att kunna prioritera bort oviktiga detaljer i arbetet. Sedan är det dags för medborgare och politiker att stämma av och ge nytt input.

Som sagt är våra politiker som tar besluten och inte medborgarna. Poängen är inte direktdemokrati utan bara att politiker blir informerade om medborgarnas önskemål. Och att medborgarna kan vara med och påverka i ett skede när det faktiskt går att påverka. Medborgarna blir informerade i ett tidigt skede. Och som jag påpekade så ska kraften läggas på att fånga upp de direkt berörda som är inaktiva. Det måste gå att hitta former för att åtminstone till viss det lyckas med det. Men även om det kommer 20 närboende nimbys och 1 yimby så ska ju politikerna väga in dels hur rationella argumenten är och dels hur många respektive egentligen representerar i sitt beslut.

Jag kommer från mjukvarusidan och vill dela med mig av en grej som är otroligt stort i "min" värld; "Agila"-metoder, specifikt något som kallas "SCRUM". Det är en reaktion mot att större delen av alla mjukvaruprojekt som kördes för ett par decennier sedan gick käpprätt åt skogen. De utvecklades enligt den välkända "vattenfall"-processen:

Krav->Design->Implementation->Verifikation

Faserna genomförs (idealt) linjärt sekventiellt i ordning. Först Krav, sedan Design osv. Den processen går i ett typiskt mjukvaruprojekt mellan 3 månader och 1,5 år. Kund inbjuds att delta i fasen "Krav" och fasen "Verifikation". Merparten av tiden får uvecklarna sitta inlåsta för sig själva på kontoret. Nu till problemen och skälet till att mjukvaruprojekten blev så fel. För det första tar processen inte hänsyn till att kunden är dålig på att uttrycka sina verkliga behov och för det andra tar den inte hänsyn till att kundens behov förändras snabbt.

Lösningen handlar om att köra alla de där faserna ovan fast i korta iterativa så kallade "sprintar" om 2-4 veckor. Idealt får kunden möjlighet att komma in i processen efter varje sprint. De får då se en "Potentially Shippable Product Increment" (PSPI), en körbar prototyp, och ge sin input. Processen svarar både på föränderliga behov OCH gör det lättare för kunden att uttrycka sina behov genom att de får testa på vad de trodde att de behovde och ofta då förstå att det inte riktigt passade.

Det man upptäckt är att projekten ofta blir mer lyckade och kunden blir mer nöjd med resultatet.

Let the city-planning go agile!

Planerna skulle kunna läggas ut "as is" som en PSPI varje månad. Respons skulle kunna samlas in, sorteras och prioriteras med hjälp av ett webbsystem. Det skulle gå att utveckla smarta algoritmer för att aggregera informationen och presentera koncis och användbar input till planeringsprocessen. Planerarna tar detta med sig in i nästa "sprint" och varje PSPI skulle kunna läggas ut med en kommentar "vi uppfattade a,b och c som efterfrågat och prioriterat av allmänheten och gjorde därför förändringar x,y och z". INTE svar på varje enskild idé, utan på en "högre" abstraktionsnivå. Jag tänker ett stycke på 5-10 rader. Det borde man klara av utan att tiden springer iväg.

Den extra tiden som investeras i processen betalas idealt av minskade problem med överklaganden och att medborgarna upplever att de inbjuds att delta och att deras input tillvaratas, tas på allvar. Därför är den där kommentaren så viktig, så att allmänheten ser att planerarna tagit till sig av input och får återkoppling på det.

Jag avser replikera Sven Renquists kommentar och reda ut vissa missuppfattningar.

Processen jag föreslår syftar inte till att skapa lekstuga. Läs gärna på om agila processer, så kanske det klarnar. Om man för ett ögonblick bortser ifrån att våra stadsplanerare i själva verket tycks sakna all form av yrkeskunskap, eftersom de misslyckats i cirka 70 år med att skapa stad, så finns ändå inget i den process jag anför som syftar till att skapa hinder för tjänstemännen. Det är lika löjligt som att få för sig att agila mjukvaruutvecklare skulle ha kunder inne och rota i produktionskoden, det är en fullkomligt absurd tanke. Det hade blivit lekstuga. Processens idé är att göra vissa anpassningar efter "kunden", intressenter, och hur de fungerar för att kunna utvinna information (krav, önskemål) för att skapa en bättre lösning. Processens idé är inte att skapa en lekstuga på SBK eller någon annanstans. Det kanske är tydligare i mitt blogginlägg där jag utvecklar detta något:
http:​/​/​minvision.​blogg.​se/​20​14/​february/​lat-​stadsplane.​.​

När det gäller Yimby's process är samma angreppssätt poänglöst. SCRUM förutsätter att det finns en uppdelning av beställare/utförare, där jag räknar även medborgarna som beställare eftersom de finansierar och politiskt delegerat makten över stadsplaneringen på förvaltningar. Därav skapas behovet av att låta utförarorganisationen arbeta iterativt och att skapa fixa punkter där iterationen slutar och återkoppling sker.

Yimby har inte den här uppdelningen, nätverket är sin egen beställare/utförare när det kommer till att producera artiklar, yttranden och liknande. Yimby jobbar ganska nära någon form av open-source-modell. Vilket i och för sig kan kallas agilt, agilitet i sig själv handlar bara om att hantera sena förändringar. Hur som helst är det öppet för vem som helst att bidra. Nätverket ställer inga som helst krav för medlemsskap, vilket är det enda som krävs för att få delta i nätverkets arbete med till exempel yttranden. Nätverket som sådant behöver dock inte ha en demokratisk legitimitet då nätverket inte arbetar inom det politiska systemet och inte heller vare sig finansieras eller arbetar på uppdrag av väljare. Yimby är en gräsrotsrörelse som bedriver påverkansarbete. Legitimerande faktorer är rörelsens oberoende, medlemmarnas samlade höga kunskap och kompetens samt den högkvalitativa faktabaserade (logos-) argumentation rörelsen använder. Jag tycker inte det är önskvärt att arbeta särskilt för att nå någon slags "demokratisk legitimitet". Den som vill är välkommen. Nätverket hindrar inget. Vill du se någon annan infallsvinkel så bli medlem och verka för den.