Brooks hävdade att när det gäller att skapa programvara finns det två stora hinder att övervinna: oavsiktlig komplexitet och nödvändig komplexitet.
Med oavsiktlig komplexitet menas utmaningar som utvecklare oavsiktligt skapar för sig själva när de försöker lösa ett problem. (Lyckligtvis kan denna typ av komplexitet också åtgärdas eller förbättras av utvecklare).
Väsentlig komplexitet är bara naturen hos den best du försöker tämja. Brooks använder exemplet att om användarna behöver ett program som kan göra 30 saker, så är dessa 30 saker nödvändiga; man kan inte helt enkelt ta bort några av dem för att göra programvaran mindre komplex. När man löser ett problem finns det vissa komplexa områden som man inte kan minska på.
Brooks syftade på komplexitet och hur det hänger samman med att skapa och ändra kod, men det gäller även för slutprodukten.
Försäljningsprognoser, att väga sannolikheten för att leads avslutas inom en pipeline och att analysera beteendet i din funnel är alla viktiga delar i ett CRM-system. Å andra sidan är svårlästa diagram, mental matematik eller rapporter som inte uppdateras omedelbart i realtid exempel på oavsiktlig komplexitet.
När jag tänker på den programvara vi skapar på Nutshellfrågar jag mig ofta: Hur mycket av den är nödvändig för det problem vi försöker lösa, och hur kan vi ta bort all oavsiktlig komplexitet? Hur kan vi undvika de hinder som finns för att skriva programvaran - och använda den?
Din kod är din organisation
Conways lag säger att "Varje organisation som designar ett system kommer att producera en design vars struktur är en kopia av organisationens kommunikationsstruktur." Med andra ord kommer den programkod som du skriver i princip att spegla hur ditt företag är uppbyggt.
Jag har tjatat om det här så mycket att mitt team förmodligen är trött på att höra det, men jag tror att en av de viktigaste sakerna man kan göra för att skapa effektiv kod är att skapa rätt organisatorisk miljö.
För mig handlar det om att göra teamet mer platt och öppet, så att det inte finns några hinder för att prata med andra medlemmar i teamet, eller uppdatera och förbättra koden. I slutändan är målet att öka hastigheten, minska kunskapssilos och förbättra slutprodukten.
Utmaningen för stora företag som Google eller Facebook är att de har alla dessa team - som ibland till och med konkurrerar med varandra om samma produkt - med varierande nivåer av byråkrati, processer och svårare kommunikationskanaler.
Nu kommer det med kompromisser, eftersom värdet och skalan som dessa produkter ger är oöverträffad, men komplexiteten har sina kostnader, och att isolera din arkitektur från den är en viktig kamp för programvaruutveckling team.
Ingen plats för hjältar
Ett annat sätt att minska komplexiteten är att begränsa antalet "teamhjältar" så mycket som möjligt.
Ibland har man en rockstjärna i teamet som, när något går sönder, säger: "Jaja, jag fixar det." Det är en vanlig dynamik i många programvaruteam, men att ha dessa fickor av hjältedyrkan kan vara mycket skadligt för kunskapsdelning.
Kanske har du hört talas om "bussfaktorn" -hur stor inverkan skulle det ha på vårt företag om den här killen blev påkörd av en buss? Det kan gälla vilken avdelning som helst på ett företag, men det är särskilt kännbart inom programvaruutveckling. På grund av antalet rörliga delar i programvaruutveckling kan den där hjälten med hög bussfaktor gå oupptäckt, och plötsligt har du ett dolt enskilt beroende som om det går förlorat kommer att ge upphov till olyckliga överraskningar. Det där är oavsiktlig komplexitet!
Vi är inte så riskabla som det på Nutshell, tack och lov, men det är något jag försöker vara medveten om. Vi utför kodgranskningar, håller lunchmöten och bygger vidare på beprövade tekniker för att hålla teknikstacken lättillgänglig. Att minska "busfaktorn" handlar inte bara om omedelbar riskreducering utan också om att förbättra vår kollektiva teamkunskap, vilket leder till en bättre produkt.
Fokuseringens kraft
Det finns många taktiska saker du kan göra för att öka enkelheten och minska komplexiteten, från hur du skriver kod till hur du levererar den. Vi gillar till exempel att släppa saker i små, inkrementella, iterativa bitar så att det inte blir en stor övergång som kan skapa en massa problem som vi måste reagera på.
Men det vi gör som har störst effekt är helt enkelt att begränsa oss till det som är viktigast.
Som Fred Brooks påpekade skapas nödvändig komplexitet när användaren säger att det finns 30 saker som programvaran måste göra, och att det inte finns någon väg runt det. Men jag skulle säga, ja, hur kan vi minska listan till de 30 funktioner som faktiskt är faktiskt är nödvändiga?
Ett av Nutshell:s kärnvärden är fokus. I min roll innebär det att hitta den bredaste överlappningen av de viktiga saker som programvaran måste göra och säga "nej" till de saker som faller utanför den.
Vi kan inte försöka genomföra varenda funktionsförfrågan som kommer in, eftersom varje marginell input potentiellt har en exponentiell räckvidd av komplexitet. Man måste våga säga: "Det där kommer vi inte att göra för produkten."
Tänk på hur du skulle marknadsföra ett företag: Det är inte meningen att ditt budskap ska gå hem hos alla människor där ute - du måste välja de målmarknader och personas som mest sannolikt kommer att använda och dra nytta av din produkt.
Jag ser på produktutveckling på samma sätt. Du måste välja vissa personas för varje funktion, och det innebär i sig att du kommer att utesluta andra.
Om du begränsar vad du försöker göra kan du förbättra de saker som är viktiga och göra rätt insatser för att minska komplexiteten. Det är inte bara "trevligt att ha" i bra programvara, det är nödvändigt.
LADDA NED
Du har dina pipelinefaser...vad händer nu?
Uppgifter är återkommande aktiviteter som vägleder dina säljare genom en försäljning. Bläddra bland våra förslag på uppgifter och ta din säljprocess från bra till enastående.
