Today I had the chance (aka enough free time) to see the “Lean Startup Meets Design Thinking” video from the Google for Entrepreneur channel.
One of the most important concept of the video, with Eric Ries and Tim Brown, is IMHO the Ries’s digression about the modern (agile)companies.
We are all quite familiar with the Big Bang theory, not the TV serie but the astrophysical thing, from a single instant we have a big explosion and life, universe and everything were created [ok, it’s a little more complex, but who cares?].
Lets try to use the big bang metaphor for our normal (web)work. We start with a single idea and then we have to expand it exponentially adding customer validation, ux design, frontend and backend development, community management and everything is needed to fulfil the scope of the idea.
The Big Crunch is just the opposite. We start with a complex and expanded system and then, little by little, it will be condensed in a single, unique and clear point.
Time by time some customers send me a “Big Crunch Spec Document“.
Come qualcuno di voi saprà da quest’anno ho messo le mie mani (anche) su BetterSoftware. Conferenze fino allo scorso anno gestita da Develer ed ora in mano ad un manipolo di soggetti con l’idea di rilanciarla in una nuova veste.
In realtà, il “nuovo” BetterSoftware è un ritorno alle origini. Quindi piuttosto che andare a parlare di come “spaccare il bit” cercheremo di portare interventi utili ed a corredo del mondo del software. Non solo sul project management, ma anche su come si fa impresa (tech), come la si mantiene, come si fa evolvere un progetto, etc. Se hai idee interessanti il CfP è ancora aperto.
Dedicheremo quindi l’evento ad un range di partecipanti che spazino dal CTO, o Lead Developer, fino allo startupper o imprenditore scafato per spiegare loro che il brief con 2 fogli powerpoint spesso non è il miglior modo di approcciare un progetto, che chiedere ad un account (preso in stage) senza nessuna esperienza di gestire un team di lavoro distribuito (e magari in outsourcing) non è la scelta migliore, e che sviluppare e mantenere codice senza i giusti strumenti, metodologici (agile, lean startup, xp) o tecnologici (continuos integration server, scm, etc) rappresenta un salto nel vuoto.
Quindi cari sviluppatori che vi lamentate che il vostro management è illuminato come una candela perché non lo convincete a farsi un po’ di cultura? ;)
Ho tenuto questo speech all’ottimo php.to.start di Torino, ricevendo molti feedback interessanti.
Preparandolo mi sono accorto come in ideato le idee cardini della filosofia lean fossero presenti prima ancora che quest’ultima diventasse un qualcosa di mainstream. Tutto quello che abbiamo fatto negli ultimi anni infatti è basato sul concetto di fare, analizzare quello che (ci) succede e far evolvere (pivotare) il nostro modo di lavorare e collaborare con i clienti.
Con la mia azienda le cose vanno abbastanza bene e per questo motivo, mio malgrado, ho dovuto ridurre drasticamente le mie ore da sviluppatore per dedicarmi ad attività un tempo da me considerate marginali (alla produzione di buon codice) ma ora indispensabili al fine favorire ed aiutare una sana crescita d’impresa.
Una di queste è la contrattazione delle modalità di fornitura dei servizi con i clienti, attività che porta via, proporzionalmente alla grandezza del cliente, tempo e sanità mentale. Se volete sapere quanto manca ad un mio possibile ricovero, considerate che ultimamente le trattative (se così possono essere definite) sono portate avanti con multinazionali che cubano quanto piccoli stati e che prima di dare una qualsiasi risposta (tipo: “bella giornata, eh?“) passano le domande al vaglio di un pool di avvocati…
Ogni tanto, durante un colloquio o uno scambio di email abbastanza acceso, mi arrivano frasi e concetti, espressi quasi come se rappresentassero La Verità Assoluta, a cui ci si aspetta una accettazione passiva.
A seguire, per mio e vostro diletto, alcune delle chicche che reputo come rappresentanti di un modo di lavorare vecchio e sorpassato.
Quality assurance, or QA for short, refers to a program for the systematic monitoring and evaluation of the various aspects of a project, service, or facility to ensure that standards of quality are being met.
fonte wikipedia
Sarà che sono sempre stato abbastanza sensibile all’argomento (vedi anche il mio ultimo talk al phpDay 2010) e che ho sempre pensato al mio lavoro su criteri molto simili a quelle citati nel craftsmanship manifesto, ma ultimamente (diciamo nell’ultimo anno) mi pare che sempre più persone (e personaggi) che vivono nell’enorme calderone del mondo agile/xp/dialetti-vari parlino di QA.
Il problema è che, imho, ognuno riporta la QA al proprio mondo dimenticandosi di tutte le altre sfaccettature e che spesso QA nel mondo agile venga intesa in termini di code coverage.
Non sono mai stato un esperto di arti marziali, quello che però mi ha sempre affascinato di queste discipline è la necessità di viverle come uno strumento necessario al continuo miglioramento.
Un miglioramento necessario, negli anime a combattere il nemico più forte (la cosiddetta sindrome da DragonBall), ad affrontare i nuovi ostacoli che ci si pongono davanti con rinnovato vigore, non solo fisico ma soprattutto, psicologico.
Tra un paio di giorni scadrà l’early bird di BetterSoftware.it, conferenza dedicata alle buone pratiche di sviluppo del software orientata però a manager ed imprenditori.
L’evento è rivolto ad una varietà eterogenea di argomenti legati alla produzione di software: dalla raccolta delle specifiche al design, dal project management allo sviluppo, dal licensing al marketing.
La conferenza porta sul palco i più importanti esperti nazionali e internazionali su progettazione agile, open source, web2.0 e tutte le discipline che contribuiscono alla costruzione di un prodotto stabile, usabile e vendibile.
Se avete dubbi sul registrarvi o meno vi consiglio di dare un occhio alla scaletta degli interventi perchè ce ne sono alcuni molto interessanti.
ciauz