Ensimmäiset 30 päivää sulautetun ohjelmiston teknisenä vetäjänä

Päivät 1–5: kartoita todellinen järjestelmä ja ihmiset

Seuraa yksi muutos vaatimuksesta toimivaan laitteeseen. Katso, miten se määritellään, katselmoidaan, käännetään, asennetaan, testataan, julkaistaan ja diagnosoidaan. Merkitse, missä näyttö sijaitsee ja missä työ riippuu yhden ihmisen muistista. Tee käännös itse dokumentoiduilla ohjeilla. Jos se epäonnistuu, säilytä havainto perehdytysnäyttönä sen sijaan, että pyydät jotakuta korjaamaan tilanteen hiljaa.

Vietä aikaa siellä, missä tuote integroidaan ja huolletaan. Repositorion esittely ei paljasta liitinvikoja, ajoitusvaihtelua, tuotannon ohjelmointia tai huoltohenkilön näkyvyyttä. Pyydä nähdä oikea vikaselvitys ja näyttö, joka palautuneesta tai vikaantuvasta laitteesta on saatavilla. Näin prioriteetit perustuvat tuotteen todelliseen elämään.

Piirrä järjestelmäkuva, jossa näkyvät prosessorit, käyttöjärjestelmät, käynnistysketju, väylät, CAN-verkot, ulkoiset ohjaimet, käännösympäristö, laitevariantit, päivitystavat ja telemetria. Merkitse omistajuus sekä kriittiset rajapinnat. Liitä rinnalle sidosryhmäkartta: tuote, laitteisto, ohjelmisto, testaus, turvallisuus, tuotanto, huolto ja toimittajat.

Kysy, mikä on sattunut viime aikoina. Kenttäviat, epävakaat testit, myöhästynyt laitteisto, integraatioyllätykset ja pitkät katselmointijonot kertovat enemmän kuin yleinen työjono. Varmista, mitkä päivämäärät, turvallisuusrajat ja asiakaslupaukset ovat kiinteitä ja mitkä suunnitteluoletuksia.

• Käännä ja aja yksi edustava kohde puhtaiden ohjeiden perusteella.
• Jäljitä yksi CAN-viesti lähettäjältä vastaanottajalle ja diagnostiikkaan.
• Tunnista laitevariantit, päivityspolut ja kenttäpalautuksen vaihtoehdot.
• Listaa kriittiset rajapinnat ja omistajat molemmin puolin.
• Kirjaa yhden henkilön riippuvuudet syyllistämättä henkilöä.

Päivät 6–10: muodosta tekninen lähtötaso

Tee lyhyt tosiasioihin perustuva lähtötaso: tuetut työkaluketjut, kääntäjävaroitukset, riippuvuus- ja kernel-versiot, staattisen analyysin tila, testitasot, käännöksen toistettavuus, resurssimarginaalit ja avoimet kriittiset viat. Älä tee arvioinnista kypsyysteatteria. Tarkoitus on tunnistaa toimituksen vaarantavat riskit, ei pisteyttää tiimiä.

Valitse muutama päivitettävä terveystieto. Hyödyllisiä ovat puhtaan käännöksen onnistuminen, julkaisuehdokkaan tuottamiseen kuluva aika, epävakaiden testien osuus, kriittiset varoitukset, hardware-in-the-loop-ympäristön saatavuus ja aika kenttäilmoituksesta toistettavaan vikaan. Signaali ilman omistajaa ja toimintaa on koriste.

Erota välitön rajaaminen rakenteellisesta parannuksesta. Julkaisun estävä säikeistysvika voi vaatia kohdennetun korjauksen ja lisää lokitusta nyt, kun taas laajemmat rinnakkaisuussäännöt ja arkkitehtuurimuutokset kuuluvat myöhempään suunnitelmaan. Tee molemmat näkyviksi, jotta hätätyö ei hävitä oppia.

Päivät 11–20: tee päätökset ja rajapinnat näkyviksi

Ota käyttöön kevyt päätöstietue vaikeasti peruttaville valinnoille: tehtävien ajoitus, muistin omistajuus, prosessien välinen viestintä, CAN-viestien merkitys, yhteensopivuus, käynnistys- tai päivitysstrategia ja virheestä palautuminen. Kirjaa tausta, vaihtoehdot, päätös, seuraukset ja näyttö, joka käynnistää uudelleenarvioinnin. Lyhyt ylläpidetty tietue on parempi kuin täydellinen käyttämätön malli.

Kohdenna katselmointi riskiin. Matalan tason ajurimuutos voi vaatia laitejälkiä, rajatestejä ja palautumistilanteen. Nimeämisen siivouksen ei pidä odottaa samaa kokousta. Määritä, mitkä muutokset vaativat arkkitehtuurin, turvallisuuden, tietoturvan tai laitteiston näkemyksen ja anna vastausaika. Delegoi päätökset lähimmille kykeneville ihmisille selkein rajoin.

Vakauta rajapintojen omistajuus. Sovi jokaiselle tärkeälle laitteisto-ohjelmisto- tai komponenttirajalle versiointi, arvovälit, ajoitus, virhetilat, testivastuu ja yhteensopivuus. CAN-tietokannoilla ja generoiduilla aineistoilla pitää olla ensisijainen lähde sekä katselmointipolku.

Päivät 21–30: toimita yksi parannus ja 90 päivän polku

Valitse yksi toistuvaa kitkaa vähentävä parannus, joka voidaan tehdä turvallisesti valmiiksi: toistettava käännös, deterministinen rajapintatesti, kenttädiagnostiikan jälki, epävakaan julkaisutestin korjaus tai automaattinen yhteensopivuustarkistus. Toimita se tiimin kanssa, dokumentoi ennen ja jälkeen -näyttö sekä tee omistajuudesta pysyvää.

Rakenna seuraavat 90 päivää tulosten, ei henkilökohtaisen työjonon ympärille. Ryhmittele työ tuoteriskiin, toimitusvirtaan, arkkitehtuuriin ja tiimin kyvykkyyteen. Rajoita samanaikaisia rakenteellisia hankkeita. Aseta kokeet ennen sitoumuksia, kun laitekäyttäytyminen tai ajoitus on epävarma.

Esitä suunnitelma vaihtoehtoineen ja asiakkaalta vaadittavine päätöksineen. Tee riippuvuudet laitteistosta, toimittajista, ympäristöistä ja erikoisosaamisesta näkyviksi. Hyvä konsultti jättää johdon kykeneväksi valitsemaan, ei vain tietoiseksi koodin monimutkaisuudesta.

Jätä jälkeesi kyvykkyyttä, älä riippuvuutta

Jaa kontekstia jatkuvasti pariohjelmoinnilla, lyhyillä päätöstietueilla, todellisuutta vastaavilla kuvilla ja perusteluja opettavilla katselmoinneilla. Kierrätä kokousten ja katselmointien omistajuutta. Varmista, että useampi kuin yksi ihminen pystyy kääntämään, julkaisemaan, diagnosoimaan ja muuttamaan jokaista kriittistä aluetta. Konsultti voi kantaa vaikeaa vastuuta väliaikaisesti, mutta sille pitää olla selkeä siirtopolku.

Nordkoodin osaajakokemuksessa voit selata relevantteja toimeksiantoja, ilmaista kiinnostuksesi kevyesti pyyhkäisemällä ja seurata rekrytoinnin etenemistä samassa paikassa. Toimeksiannossa vahvin näyttösi ei ole se, kuinka moni päätös vaatii sinua, vaan kuinka varmasti tiimi tekee hyviä päätöksiä rakentamasi toimintamallin avulla.

Pidä viikoittaista siirtymämuistiota: päätökset, jotka muut osaavat nyt tehdä, menettelyt, jotka toinen henkilö on suorittanut, ja riskit, jotka riippuvat edelleen sinusta. Katselmoi se sisäisen työparin kanssa. Näin tiedonsiirto muuttuu epämääräisestä loppulupauksesta näkyväksi edistymiseksi koko toimeksiannon ajan.

Ensimmäisen kuukauden tarkistuslista

Käytä listaa keskusteluna tiimin ja asiakkaan kanssa, ei salaisena pisteytyksenä. Sovita järjestys välittömiin turvallisuus- ja toimitustarpeisiin, mutta pidä omistajuuden siirtyminen näkyvänä.

• Pystytkö kääntämään ja ajamaan edustavan kohteen dokumentoiduilla vaiheilla?
• Onko järjestelmästä ja omistajuudesta ajantasainen kartta?
• Perustuvatko suurimmat tuote- ja toimitusriskit näyttöön?
• Onko kalliisti peruttavista valinnoista lyhyet päätöstietueet?
• Ovatko kriittiset rajapinnat versioituja, testattavia ja yhdessä omistettuja?
• Onko yhtä toistuvaa kitkaa parannettu mitattavasti?
• Näyttääkö 90 päivän suunnitelma vaihtoehdot ja asiakkaan päätökset?
• Siirtyykö tieto päivittäisessä työssä loppuluovutuksen sijaan?