Ragazzo, se avessi un nichelino per ogni società di software che ho cercato di creare...stavo scherzando. Ho costruito team intorno a prodotti e società di consulenza. Non sono l'esperto di ciò che serve per costruire una società di software, ma vi dirò alcune cose che mi vengono in mente.
C'è una differenza tra un team di prodotto e un team di software, almeno nella mia mente. Sono simili nel senso che stanno spedendo cose a persone reali intente a risolvere un problema reale. Un team di prodotto completo ha bisogno di capire il pubblico/mercato/persone che questo prodotto serve. Si concentrano molto su tutti gli eventi e su come il prodotto funziona nella vita delle altre persone. Un team di software a volte deve gestire anche questi problemi. Un team di software ha certamente bisogno di avere una mentalità agile per adattarsi alle esigenze del prodotto. Qualche mese fa ho scritto su alcune lezioni che ho imparato duramente cercando di mantenere una prospettiva agile in una grande azienda (Agile and Agility). Dovreste avere una forte sensazione di come la vostra azienda sta risolvendo problemi reali per le persone.
Qualunque cosa facciate, dovete avere un'idea se la vostra gente del software è efficace o meno. Questo di solito significa che avete i sistemi di supporto giusti: issue tracking, controllo di versione, deployment, chat, servizi per le riunioni. Se il tuo team lavora in remoto, questi strumenti sono ancora più importanti di un team che si riunisce nello stesso spazio condiviso. I miei strumenti preferiti sono Slack, Google Hangouts, Github. Ho avuto grandi esperienze con PivotalTracker, Skype, Workflowy, Trello e Draftin. È importante trovare gli strumenti che rendono il polso dell'azienda evidente a tutte le persone coinvolte.
Ci sono molte scuole di pensiero sugli stili di gestione. Alla business school, mi è stato insegnato un approccio pratico che francamente mi dà fastidio ora. Sono più nel campo di assumere le persone più intelligenti che puoi trovare e dare loro spazio per fare cose sorprendenti. Gli sviluppatori di software che hanno passato i primi anni della loro carriera hanno impegnato una parte molto grande della loro vita per essere eccellenti. Come ogni essere umano, siamo stanchi, distratti e sopraffatti. I codificatori, tuttavia, tendono ad avere una resilienza e a spingersi di nuovo in un flusso produttivo. Vorrai avere delle scadenze chiare, comunque, guidate da qualcosa di reale come il rilascio del prodotto o le aspettative del cliente. Dare ai tuoi programmatori la possibilità di mostrare i loro successi spesso può gestire la maggior parte dei tuoi problemi di responsabilità.
Il lavoro dei clienti tende a raggrupparsi. Alcune buone idee per rompere il ciclo sono qui: Feast (or famine) // Articles // Studio Fellow
Le persone hanno bisogno di una comunicazione regolare, anche i clienti. Assicurati di avere abitudini di comunicazione chiare, proattive e oneste con le persone. Dite loro per tempo quando c'è un problema. Chiedi scusa per i tuoi errori. Impara ad essere un po' vulnerabile e cerca di capire come avere relazioni commerciali valide con le persone. Questo mi ispira: The Art of Asking: How I Learned to Stop Worrying and Let People Help: Amanda Palmer, Brené Brown: 9781455581085: Amazon.com: Books
Hai bisogno di concentrazione e credibilità nel tuo business. Se stai aprendo una consulenza, prenditi del tempo per produrre il tuo servizio. Questo ti permette di creare clienti regolari e buone relazioni commerciali in modo delicato, evidenziando i tuoi punti di forza rispetto ad altri negozi di software. Se state costruendo un'azienda intorno ad un prodotto, gli stessi consigli verranno naturalmente.
Se non vi siete sintonizzati su 37Signals (creatori di Rails, Bootcamp e altre cose interessanti) dovreste dare un'occhiata. Hanno costruito una grande squadra nel corso degli anni e sono davvero il gold standard. Getting Real (uno dei loro libri) è una visione particolarmente chiara delle difficili domande e risposte che probabilmente state affrontando ora: Il libro bestseller di 37signals
Questo è probabilmente tutto il consiglio generale che posso pensare. Se vuoi aggiungere qualche dettaglio su ciò che stai cercando di realizzare, potrei avere qualche consiglio migliore da condividere.