Gestione dei requisiti di progetto in conflitto

Sembra che il tuo problema non sia uno dei requisiti poco chiari, ma piuttosto un ruolo mancante di cui hai bisogno nel tuo team. Quello di cui hai bisogno è un proprietario del prodotto .

Communication is a main function of the product owner. The ability to convey priorities and empathize with team members and stakeholders are vital to steer the project in the right direction. Product owners bridge the communication gap between the team and their stakeholders. As Figure 1 shows, they serve as a proxy stakeholder to the development team and as a project team representative to the overall stakeholder community.

Citato da Wikipedia, fonti: Pichler, romano. Gestione del prodotto agile con Scrum: creazione di prodotti che i clienti amano. Upper Saddle River, NJ: Addison-Wesley, 2010.

Nel tuo caso specifico in cui hai più clienti come stakeholder ciascuno con richieste in competizione e conflittuali, il proprietario del prodotto agisce come un proxy e dirige i requisiti del software per fornire il massimo valore a tutti i clienti. Considera la seguente user story dal client A:

As a [user] I need the Submit button on form A to be Blue, so that I can appease my need to see blue buttons.

Ora il client B ha un requisito in conflitto:

As a [user] I need the Submit button on form A to be Red, so that I can satisfy my hatred for the color blue.

Il Product Owner ascolta entrambe le esigenze degli stakeholder e decide:

As a [user] I need the Submit button color to be configurable to my needs, so that I can see my favorite color on form A.

Per il team di sviluppo non è nemmeno necessario conoscere o preoccuparsi del fatto che il Cliente A ama Blu e il Cliente B disprezza Blu. Il proprietario del tuo prodotto a tutti gli effetti è l'attività giusta per te.

Sei molto astuto per uno sviluppatore junior per rendersi conto di quanto possa essere caotico formulare un prodotto per diversi clienti senza un proprietario del prodotto. Ciò può causare una serie di problemi:

1. La necessità di puntare su esigenze diverse dei clienti.
2. Necessità di correggere bug in molti luoghi diversi in quanto ogni cliente ha una base di codice diversa
3. L'accumulo di debito tecnico che rende le correzioni di bug e lo sviluppo di nuove funzionalità esponenzialmente più costose.

Perché l'azienda non ne vede la necessità, quindi?

1. Le vendite non si preoccupano necessariamente che il lavoro di sviluppo sia più difficile e più soggetto a errori. La tua squadra potrebbe essere molto brava a fare sforzi extra e ad essere vigile nel gestire il debito tecnico, rendendo i problemi più difficili da vedere per loro.
2. Le vendite non promettono necessariamente ai clienti un software OOB (Out-of-Box). Potrebbero essere più interessati a fornire uno sviluppo personalizzato ai propri clienti che a costruire un prodotto.

Il punto 2 ha un aspetto interessante se si considera che molti ISV realizzano la maggior parte dei loro profitti su mercati specializzati o di nicchia con una manciata di clienti. Questo mercato potrebbe essere più captive, quindi la qualità del software non è così importante. Anche i profitti anno dopo anno hanno maggiori probabilità di venire dai contratti di supporto rispetto a qualsiasi altra fonte di reddito. L'acquisto della licenza iniziale è solo una ciliegina sulla torta. Le vendite in questo caso sono meno propense a cercare di attirare un mercato più ampio e più sulla gestione delle relazioni con la manciata di clienti importanti che hanno.

Sono d'accordo con maple_shaft che hai un ruolo mancante ma non sono d'accordo sullo stesso ruolo. Quello che ti manca è il lead tecnico del programma (o qualunque titolo tu voglia chiamarli). Supponendo che ogni cliente sia considerato un progetto separato, il responsabile tecnico del programma è responsabile di sapere cosa sta succedendo con tutti i vari progetti.

Una delle responsabilità del piombo tecnico è garantire che i vari progetti non si sovrappongano. Pertanto, tutte le modifiche devono essere eseguite su un ramo biforcato che non può essere unito al ramo principale finché gli impatti su altri progetti non vengono valutati, rettificati e approvati dal lead tecnico.

Ovviamente questo non funzionerà se il responsabile tecnico non ha l'autorità per far rifare il lavoro agli altri sviluppatori a causa dei suoi impatti e / o non è vigile nel garantire che le forche siano unite nel main ramo in modo tempestivo. Se l'atteggiamento è costantemente "lo fonderemo più tardi quando avremo tempo", allora non può funzionare perché non avrai mai tempo e il codice base si sarà allontanato troppo se mai avessi tempo. Ma, fare software efficacemente a lungo termine richiede un po 'di disciplina. Se non lo hai, non c'è una metodologia che ti possa aiutare.