Devo essere coinvolto nel lato commerciale del mio progetto?

In molti progetti essere coinvolti nel lato commerciale delle cose non è solo inevitabile, ma buono. Se comprendi le ragioni del proprietario per desiderare le cose, puoi reagire meglio a / suggerire / riparare / anticipare le funzionalità su cui devi lavorare.

Specificamente alla tua domanda finale: ho, e il più delle volte perdi più di quanto hai vinto fino a quando non inizi ad avere una storia positiva per essere nel giusto con i tuoi suggerimenti.

Una cosa che a volte mi ha aiutato è fare una demo con le cose a modo mio e mostrarla agli utenti come alternativa o, al contrario, fare una demo abbastanza del loro modo di evidenziare i problemi.

Nella maggior parte delle situazioni aziendali è il tuo compito portare a termine le cose, ma alla fine la loro decisione se pensano che il loro pazzo sia migliore.

Quando scelgono il pazzo, la cosa migliore che puoi fare è assicurarti di avere una chiara strategia di uscita per tornare a essere sana quando si rendono conto del loro errore.

Se il pazzo inizia a prendere il sopravvento, considera un altro datore di lavoro ...

Sì, in molte aziende per cui ho lavorato. E ho sempre perso gli uomini d'affari; hanno comunque una posizione più alta nelle società di software.

Curiosamente, rendere il tuo prodotto più interessante e più piacevole per i tuoi utenti è l'intero punto di forza del business: più è divertente, più denaro, di norma. D'altra parte fare soldi con non rendendo il tuo prodotto migliore, più spesso significa affari non etici, che funziona a breve termine e sicuramente fallisce nel lungo periodo.

In effetti, potresti avere torto e potrebbero avere ragione su alcuni, o sulla maggior parte o su tutti i problemi su cui non sei d'accordo, ma comunque: avvia la tua startup e metti fine a questa frustrazione.

In base alla mia esperienza, avere un tecnico sul lato economico delle cose può essere davvero utile per un'azienda SE , e questo è un importante "se", la persona tech prende il tempo per parlare la lingua degli uomini d'affari.

Sì, la meraviglia tecnica a volte deve scendere a compromessi con UX. Se vuoi i soldi degli utenti, devi dare loro un valore loro .

A volte deve scendere a compromessi con i fattori aziendali. Uber-database-awesomeness potrebbe rendere il DB migliore o le prestazioni un po 'migliori, ma se la licenza costa più della società, non può essere implementata.

Tuttavia, se la meraviglia tecnica mai compromette (come spesso accade) la mancanza di comprensione della leadership non tecnica, ALLORA hai un problema. O la dirigenza aziendale non sta ascoltando (nel qual caso, trova un nuovo lavoro), o non stai facendo il tuo lavoro - parte della quale sta imparando a mettere le tue competenze in parole che possono capire.

Penso che tu abbia solo bisogno (e probabilmente solo dovrebbe ) di essere abbastanza familiare con il lato business per poter entrare nel cervello degli utenti. Quello che stai vivendo non è necessariamente alcuna differenza fondamentale tra codice e prodotto. È una questione di diversi obiettivi.

Gli uomini d'affari in genere hanno l'obiettivo di costruire un prodotto che le persone desiderano. Le tecniche hanno l'obiettivo di creare codice manutenibile e non buggato in grado di scalare con l'azienda.

In altre parole, i tipi di business si fanno beffe dei requisiti tecnici perché è il loro lavoro. Non vengono pagati per assicurarsi che venga scritto un buon codice. Vengono pagati per costruire un prodotto interessante. Tu, d'altra parte, non sei pagato per creare un prodotto interessante. Sei pagato per assicurarti che un buon codice venga scritto.

Il mio consiglio è di prendere nota dagli uomini d'affari. È necessario concentrarsi sul fare il tuo lavoro correttamente. Se tagli gli angoli e metti fuori un buggy adatto a loro, ti prenderà la colpa. In effetti, direi che meriti la colpa. È il tuo lavoro mantenere i requisiti tecnici.

Ora, è allettante dare la colpa agli uomini d'affari per non averti ascoltato. Loro ti ti trattano ingiustamente, ma non è questo il punto. Il punto è come reagisci a quella situazione. Permettetemi di condividere un segreto per lavorare con voi con le società di software: il codice è il prodotto. Potrebbe sembrare ovvio, ma ce ne siamo dimenticati così tante volte. Quindi, la chiave è rendersi conto che stai aiutando gli uomini d'affari a realizzare un prodotto migliore. Una volta che te ne rendi conto, diventa facile esprimere le cose nei loro termini: "Possiamo farlo, ma farà un prodotto bacato che nessuno comprerà" o "Possiamo farlo, ma metterebbe a repentaglio la nostra capacità di mettere prodotti più veloci in futuro ".

Non sto suggerendo che i cattivi ambienti di lavoro in cui non puoi mai far sì che gli uomini d'affari ti ascoltino non esistono. Sto suggerendo che il modo di gestire questa situazione è quello di attenersi alle tue pistole mentre realizzi che l'altra parte ha obiettivi diversi da te. Il modo corretto per gestirlo è trovare una soluzione che benefici entrambi i lati.

Se non sei coinvolto nel mondo degli affari, stai facendo solo quello che le altre persone ti dicono di fare. Se lo sei, allora hai almeno una leggera influenza sui requisiti del progetto.

Dovresti davvero avere un'idea di come ciò che fai si adatta alla tua attività (e al business del tuo cliente, se stai facendo software per un cliente), se vuoi fare dei suggerimenti intelligenti. Se sei percepito come un suggerimento poco pratico, avrai solo più problemi nel far accettare quelli pratici. Alcune persone hanno le abilità sociali per affrontare quella situazione, ma il tipico techie, quello con più probabilità di avere questo problema, quasi certamente non lo è.

Dipende anche da cosa vuoi fare con la tua carriera. Se vuoi sviluppare software per il resto della tua vita, va bene. È quello che mi piace. Se vuoi entrare nella gestione, compresa la gestione del software, dovrai capire il business.

Nel lontano passato ho lavorato in una compagnia di giochi. Avevano tutta la tecnologia intelligente per sviluppare qualcosa con l'appeal del mercato di massa di Quake (e prima del rilascio di quel prodotto) ma a causa della mancanza di qualsiasi input / controllo di marketing ha scelto di sviluppare il tipo di gioco che gli sviluppatori volevano giocare; una stravaganza geektastic con una trama letteraria contorta e dove quasi ogni chiave (ok, esagerazione) sulla tastiera ha fatto qualcosa. Il gioco è stato ben accolto in modo critico e ora è generalmente considerato un classico; il team di creazione può essere applaudito per rimanere fedele alla propria visione ... ma non sono mai riusciti a creare il gioco di successo che la società aveva davvero bisogno di assecondare in questo tipo di progetto di "integrità artistica" (non sono più in giro).

Ho lavorato anche per altre "migliori trappole per topi" (suggerimento: il mondo non ha bisogno di una trappola per topi migliore) che pensava di poter prevalere sul mercato solo con la tecnologia e le capacità di sviluppo superiori. Nessuno di loro ha avuto successo con quello che stavano cercando di fare (non con la loro idea originale, comunque). Credimi: ascolta e rispetta le tue persone di marketing (almeno quelle buone e con esperienza) e loro ti ascoltano e ti rispettano.