Intenționați să implementați Kanban în procesele dvs. de afaceri? Iată de unde să începi. Sistemul Kanban: ce este, de unde să începeți, cum să îl implementați, principii principale

Cât mai pe scurt posibil despre metoda Kanban, termenii ei de bază și domeniile de aplicabilitate.

Am descris metoda Kanban, termenii ei de bază și domeniile de aplicabilitate cât mai pe scurt posibil.

1. Ce este metoda Kanban?

Metoda Kanban este o metodă de îmbunătățire a muncii tale. Orice ai face, ipoteza este că practicarea metodei Kanban îți va permite să-ți faci treaba și mai bine. Din perspectiva Kanban, asta înseamnă că vei îndeplini mai bine așteptările clienților.

Kanban ca instrument în managementul IT a fost introdus de David J. Anderson la Microsoft (2005) și Corbis. Și metoda a devenit larg răspândită și numită în 2007.

2. Metoda Kanban și Toyota Kanban sunt același lucru?

(Cea mai mare carte). Nu cu siguranță în acest fel. Kanban de la fabricile Toyota este o producție slabă, al cărei principiu definitoriu este conceptul de „just la timp”. Kanban, ca termen de management, chiar a venit de la Toyota. Tradus din japoneză, acest cuvânt înseamnă „semnal” sau „card”. În fabricile de automobile, astfel de carduri erau folosite pentru a transmite informații de la o etapă la alta despre câte și ce piese ar fi necesare.

Să ne uităm la un exemplu scurt. Trebuie să facem trei mașini „just la timp”. Aceasta înseamnă că putem determina cu exactitate în avans de câte piese vom avea nevoie în anumite etape și începem de la sfârșit să scoatem numărul necesar de piese pentru a crea această mașină, răspunzând la întrebările: „Câți litri de vopsea vom avea nevoie?”, „Câte roți?”, „Câte motoare?” și așa mai departe. Astfel, nu creăm surplus de piese de schimb sub formă de resturi și economisim la depozite, logistică și alte costuri.

Metoda Kanban aderă și la conceptul de „just la timp”, dar spre deosebire de fabricile Toyota, aici vorbim despre munca intelectuală. Cu alte cuvinte, codul unui programator sau ideea unui marketer nu poate fi atins și văzut de omul obișnuit până când nu se transformă într-un produs sau serviciu final. Astfel, metoda Kanban este folosită pentru a vizualiza fluxul muncii intelectuale și pentru a reduce cantitatea acestei lucrări neterminate. Datorită acestui fapt, se obține o viteză uniformă și previzibilă de furnizare a serviciilor către consumatorul final.

3. Metoda Kanban poate fi folosită în afara IT?

Da. Metoda Kanban este potrivită pentru vizualizarea fluxului oricărei lucrări creative și intelectuale. Dar este mult mai eficient să-l folosești prin prisma paradigmei serviciului. Uită-te la ce faci ca serviciu. Prin ce etape parcurge lucrarea pentru ca serviciul sa fie prestat? După ce criterii veți înțelege că serviciul este furnizat în conformitate cu așteptările Clientului? Acesta este punctul de plecare pentru utilizarea metodei Kanban. Practicanții Kanban numesc acest punct „începe cu ceea ce ai acum”.

4. Este Kanban ca Scrum?

Nu. Scrum este un cadru cu reguli și limite stricte. Puteți folosi diferite instrumente și metodologii în cadrul Scrum, dar dacă abandonați ceva necesar în Scrum, acesta nu mai poate fi considerat Scrum. Kanban este o metodă, un instrument cu un set de practici și principii. Puteți folosi toate practicile, unele dintre practici sau nu le folosiți deloc. În Kanban nu există un concept strict despre ceea ce este Kanban și ce nu este Kanban. Cu toate acestea, utilizarea judicioasă a practicilor vă poate ajuta în mod semnificativ să oferiți servicii de cea mai înaltă calitate și să îndepliniți așteptările clienților.

5. Kanban are valori?

Da. Sunt nouă: transparență, echilibru, colaborare, orientare către client, flux, leadership, înțelegere, acord, respect.

6. Ai scris despre principiile Kanbanului. Ce sunt ei?

Kanban are principii de bază, care sunt numite și principii de management al schimbării:

1. Începe cu ceea ce ai acum.
2. De acord asupra dezvoltării evolutive.
3. Încurajează dezvoltarea leadershipului la toate nivelurile.

Deoarece metoda Kanban trăiește într-o paradigmă de serviciu, aderă la principiile sale:

1. Aflați nevoile și așteptările clientului.
2. Gestionați munca, lăsați oamenii să se organizeze în jurul ei.
3. Elaborați reguli pentru îmbunătățirea performanței.

7. Care sunt practicile în Kanban?

Există și șase dintre ele:

1. Vizualizați.
2. Limitați munca neterminată.
3. Gestionați fluxul de muncă.
4. Folosiți reguli explicite.
5. Introduceți bucle de feedback (cadențe).
6. Îmbunătățiți și evoluați.

Acestea sunt tehnici direct practice pe care le folosim pentru a ne îmbunătăți munca și a îmbunătăți calitatea serviciilor.

8. O, cadențe! Ce sunt cadențe în Kanban?

Cadence este un termen din muzică. În contextul metodei Kanban, denotă ritm. Cadențele sunt întâlniri regulate care sunt, de asemenea, bucle de feedback. Regularitatea stabilește ritmul cu care curge fluxul de muncă. Șapte cadențe:

1. Întâlnire Kanban (zilnic). Aici discutăm despre starea sarcinilor blocate.
2. Întâlnire de umplere a cozii (de obicei la fiecare două săptămâni). Ne asumăm responsabilitatea a ceea ce vom face ca serviciu.
3. Întâlnire de planificare a livrării (de obicei la fiecare două săptămâni). Ne returnăm obligațiile îndeplinite.
4. Întâlnire de evaluare a serviciului (de obicei la fiecare două săptămâni). Folosind valori, discutăm despre calitatea serviciului și despre cum să-l îmbunătățim, dacă este necesar.
5. Întâlnire operațională (de obicei o dată pe lună). Discutăm despre calitatea interacțiunii serviciilor conexe cu valorile.
6. Întâlnire de evaluare a riscurilor (de obicei, o dată pe lună). Discutam cu metrica impactul sarcinilor blocate asupra functionarii serviciului.
7. Întâlnire de revizuire a strategiei (de obicei trimestrială). Discutăm schimbările de strategie cu metrici.

9. Am auzit ceva despre orele de serviciu. Ce este asta?

Kanban folosește clase de servicii pentru a prioritiza anumite tipuri de muncă, clienți sau pentru a atenua impactul asupra afacerii, cum ar fi costul întârzierii. Costul întârzierii reprezintă profitul pierdut sau costurile suportate din cauza întârzierii livrării serviciilor. Să ne uităm la impactul costurilor de întârziere și al clasei corespunzătoare de servicii folosind exemple:

1. Clasă accelerată – prim ajutor de urgență-resuscitare. Conducerea pe o bandă dedicată. Nu există timp pentru a amâna rezolvarea problemei. Am nevoie de el cât mai curând posibil.
2. Clasă cu dată fixă ​​– Costurile de întârziere cresc dramatic după o anumită perioadă. Exemplu: un proiect sub forma unei legi federale cu o dată fixă ​​de începere. Dacă nu ajungem la timp, există riscul să ne pierdem permisul.
3. Clasa standard - costul întârzierii crește proporțional cu timpul. Dacă o facem imediat, obținem imediat profit. Dacă o facem pentru o perioadă lungă de timp, obținem profit pentru o perioadă lungă de timp.
4. Clasă intangibilă - o facem, dar această muncă nu aduce niciun profit evident, costul întârzierii crește încet. De exemplu, curățarea casei. Nu trebuie să curățați în mod regulat, dar după jumătate de an va trebui să faceți o curățare temeinică.

10. Cum rămâne cu valorile? Cum se măsoară eficiența unui serviciu?

Metoda Kanban are metrici care vă permit să răspundeți la întrebări: care sunt problemele în fluxul de lucru, care este debitul serviciului, care este timpul de execuție, care este timpul de rezoluție a blocării, care este timpul ciclului și ce tipuri de muncă este distribuită? Toate acestea permit managerului de servicii să ia decizii privind dezvoltarea și îmbunătățirea calității serviciului pe baza datelor acumulate.

11. Cu ce ​​provocări se confruntă Kanban în timpul implementării?

Principala provocare este de a explica oamenilor de la toate nivelurile valoarea practicilor Kanban: vizualizarea și limitarea lucrărilor în curs. Din cauza faptului că oamenii nu văd volumul muncii intelectuale, le este greu să înțeleagă încărcătura la care sunt expuși. Dar creierul, de exemplu, este același mușchi ca și bicepsul. Imaginează-ți o sală de sport: intri și vezi greutatea de pe bară: „Bine, e prea puțin. Și acum este prea mult. Dar asta este corect!” Trebuie să lucrați cu creierul exact în același mod: „Aceasta este o sarcină mare, iar aceasta este una mică și, în general, mi-am luat cumva mult pe mine. Voi limita sarcina.” Când vizualizăm fluxul de lucru de la capăt la cap la toate nivelurile și limităm cantitatea de lucru în desfășurare, creăm un principiu de atracție pentru munca de cunoștințe și facem un flux uniform al rezultatelor sale către clienții noștri.

12. Ce programe există pentru metoda Kanban?

Sunt și o mulțime. Enumerăm doar pe cele profesionale, dezvoltate special pentru metodă. Inima noastră este dăruită dezvoltării ruse Kaiten. Pe lângă acesta, există și TargetProcess, SwiftKanban, LeanKit și altele.

13. Și care companii folosesc deja metoda Kanban?

Printre cele rusești se numără Alfa-Bank, Home Credit Bank, Pochta-Bank, Dodo Pizza, HeadHunter, Clever și altele. Din străinătate: Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr Dobb’s, Siemens, Tupalo. Această listă poate fi continuată mult timp.

14. Mai este ceva important?

Da. În cele din urmă, aș dori să subliniez importanța a două roluri în metoda Kanban. Aceștia sunt managerul de livrare a serviciilor și managerul cererilor de servicii. Primul este responsabil pentru eliminarea obstacolelor din fluxul de alimentare. Al doilea este pentru gestionarea fluxului de cereri către serviciu de la mulți clienți. Este foarte important ca aceste două roluri să fie parteneri și să lucreze împreună.

15. Bine, înțeleg. De unde să începeți implementarea Kanban într-o organizație?

Pentru a începe implementarea Kanban în organizații, folosim instrumentul S.T.A.T.I.K. – o abordare sistematică a utilizării Kanbanului. Puteți citi mai multe despre el pe Internet. Dar vă recomandăm să participați la un training unde acest instrument este predat în formatul unui joc de afaceri. Folosind serviciul (organizația) dvs. ca exemplu, puteți proiecta un sistem Kanban pentru utilizare ulterioară în condiții de luptă.

Trainer și consultant pe metodologii agile, Scrumtrack.

Bună ziua

Unul dintre interesele mele profesionale, în calitate de coordonator al echipei de testare, îl reprezintă metodologiile de dezvoltare software. În prezent, așa-numitele metodologii Agile, în special Scrum și Kanban, devin din ce în ce mai populare. „Formatorii” fără scrupule joacă în termeni „exagerat”; seminariile și certificările („maestru Scrum certificat”, „Proprietar certificat de produs”, etc.) cresc cu un pas.

În majoritatea articolelor și antrenamentelor fără scrupule, orice metodologie este prezentată ca un glonț de argint magic care va rezolva instantaneu problemele de comunicare și va salva imediat membrii echipei individuale de incompetență. În general, vă va ajuta să vă rezolvați exact problemele. Anul acesta intru în programul de master la Universitatea de Stat din Belarus cu o diplomă în tehnologii de management al resurselor umane și plănuiesc să iau în considerare în detaliu argumentele pro și contra, precum și limitările aplicabilității celor mai comune metodologii de dezvoltare software.

În procesul de lucru, am întâlnit adesea neînțelegeri și interpretări incorecte ale instrumentelor metodologice, utilizarea metodologiei la modă fără a ține cont de context. După ce am citit articolul, mi-am dat seama că problema este mai mult globală decât locală. Astăzi îmi propun să arunc o privire asupra Kanbanului, a istoriei sale, a principiilor de bază și a posibilelor limite de aplicare.

Istoria termenului

Kanban este un termen japonez care a început să fie folosit în relație cu producția în anii 60 ai secolului XX la Toyota. Acest principiu se bazează pe metoda de producție a transportoarelor, precum și pe diferite viteze pentru efectuarea operațiunilor tehnologice individuale în producție. Voi încerca să explic cu degetele mele. În orice producție există o producție principală („conveior principal”) și o producție suplimentară („conveioare suplimentare”). Rata de producție a produselor finale este stabilită de transportorul principal, în timp ce transportoarele suplimentare nu pot accelera rata de eliberare a produsului, dar o pot încetini dacă piesele necesare nu sunt eliberate la timp.

În plus, în timpul producției poate exista o schimbare a priorităților. De exemplu, s-a dovedit că stația care a produs oglinzi din stânga a produs 20 de bucăți, iar stația care a produs oglinzi din dreapta a produs 10 bucăți, în timp ce pe linia de asamblare sunt 15 mașini și sunt necesare 15 piese de oglinzi de ambele tipuri. Există un conflict de metrici - producția nu a scăzut cantitativ (transportoarele suplimentare au produs 30 de produse la timp), dar producția riscă totuși să se oprească. Kanban este conceput pentru a ajuta cu această problemă.

În forma sa cea mai simplă, Kanban include două reguli simple:

• Stația de producție are un plan de producție de piese („backlog”). Planul este sortat în funcție de prioritate și se poate schimba în orice moment (de exemplu, o stație care produce prea multe oglinzi din stânga ar trebui să poată trece la oglinzile din dreapta cât mai curând posibil);
• numărul de sarcini efectuate simultan la stație este limitat (adică să producă nu mai mult de un număr dat de oglinzi în același timp). Această limitare este necesară pentru a controla viteza de producție la stație, precum și viteza de răspuns la modificările planului.

Timpul prezent

În ultimul timp, Kanban a câștigat multă popularitate în producția de software. Unele echipe găsesc această metodologie extrem de utilă, altele o folosesc ca „cult Cargo”. Pe baza experienței mele empirice, Kanban pur funcționează prost pentru echipele de produse (a se citi „core pipeline”), dar funcționează excelent pentru echipele de asistență, cum ar fi:

• grupuri de suport software, unde „planul” nu este important, dar viteza de răspuns la schimbări este importantă;
• echipe de testare care lucrează separat de echipele de dezvoltare;
• servicii suport;
• alte exemple de „industrii neesențiale”.

Separat, trebuie menționat că Kanban funcționează bine în startup-urile care nu au un plan clar, dar lucrează activ la dezvoltare. Propun să luăm în considerare un exemplu de utilizare a Kanbanului în dezvoltarea de software. Îmi cer scuze anticipat pentru ilustrațiile urâte. Să ne imaginăm o echipă de un dezvoltator care lucrează la un proiect mic. Planul de dezvoltare (backlog) este sortat în ordinea priorității lucrărilor, limita echipei pentru sarcinile din proces este de 1 bucată.

Pentru a gestiona procesul, managerul de proiect poate:

1. modificați limita numărului de sarcini în muncă;
2. adăugați o sarcină cu o prioritate mai mare (de exemplu p0) astfel încât să fie preluată cât mai curând posibil;

În timpul procesului de lucru, se poate întâmpla ca munca să fie blocată (gazduirea s-a defectat, cadrul necesar nu a fost descărcat etc.). În general, munca blocată este returnată în așteptare și este selectată o nouă sarcină cu cea mai mare prioritate. În funcție de natura sarcinilor și de tipul de echipă, limita poate fi mărită sau micșorată. De exemplu, dezvoltatorul nostru poate să deseneze simultan un formular de înregistrare și să urmărească procesul de implementare a unui nou server. Cu toate acestea, dacă timpul de finalizare a sarcinii este mai mic decât cel necesar, managerul de proiect poate reduce limita sau poate mări echipa. Astfel, cu un management adecvat, Kanban oferă cea mai mare viteză posibilă de lucru pentru o anumită echipă, viteza maximă de răspuns la schimbări și în același timp reduce „costurile” de susținere a metodologiei. Ei bine, asta-i tot! Kanban nu este ușor, simplu. E foarte simplu!

Limitările Kanban atunci când sunt utilizate în echipe de produse includ:

• această metodologie nu funcționează bine cu echipe mari (mai mult de 5 persoane);
• În forma sa pură, Kanban nu funcționează bine cu echipele interfuncționale. Acestea. Spre deosebire de Scrum, este dificil să combinați testarea și dezvoltarea într-o singură echipă. O idee mai bună este să împărțiți procesul într-o „stație” de dezvoltare și o „stație” de testare cu manageri și întârzieri separați;
• Datorită istoriei și specificului său, Kanban nu este destinat planificării pe termen lung.

Concluzie

În concluzie, aș dori să adaug că compararea oricăror metodologii pe principiul „cine este mai rece” nu este productivă și contra-constructivă (Captain Obvious). Fiecare metodologie mai mult sau mai puțin comună are avantajele, dezavantajele și limitele ei de aplicare. În plus, metodologiile Agile impun în mod inerent cerințe mai mari asupra muncii în echipă și experienței membrilor echipei.

Dacă există interes pentru subiect, voi continua să iau în considerare Kanban mai detaliat. Ulterior, îmi propun să sortăm Scrum și RUP în bucăți și imagini.

Mai detaliat și clar, puteți privi.

Kanban - ce este? Câte informații interesante conține un card Kanban și ce funcție servește metoda în producție? În articol, vom explica în detaliu regulile pentru utilizarea eficientă a kanbanului și, de asemenea, vom oferi o descriere clară a schemei de utilizare a cardurilor corespunzătoare folosind un exemplu specific. În plus, după ce te-ai familiarizat cu materialul, vei afla de ce este nevoie de o placă Kanban, în ce domenii, pe lângă producție, este recomandabil să folosești această metodă și ce poate servi ca o alternativă bună la aceasta.

Esența conceptului și principalele caracteristici ale metodei

Astăzi se poate observa o tendință clară de creștere a costurilor pentru stocarea stocurilor, care este motivul principal pentru formarea unor complexe de gestionare a stocurilor „instantanee”, care include sistemul kanban. Tradus din japoneză, „kanban” înseamnă „etichetă”, „insignă”. Acest termen servește ca metodă de informare prin care se acordă permisiunea sau indicația pentru producerea sau excluderea (transferul) unui produs într-un sistem de tragere.

Opțiunea prezentată pentru transmiterea informațiilor vă permite să gestionați pe deplin liniile de producție slabe prin utilizarea cardurilor de informații pentru a transfera o anumită comandă de producție din etapa următoare la cea anterioară.

Dezvoltatorul unui astfel de sistem productiv este Toyota Motors, ceea ce explică ideea prezentată ca fiind una dintre primele încercări de a implementa practic metoda just-in-time. Conform sistemului kanban, producția se desfășoară în conformitate cu următoarea regulă: diviziile întreprinderii sunt aprovizionate cu resurse într-o anumită cantitate și într-un termen clar definit necesar pentru finalizarea comenzii.

Detalii proces

Schema metodei prezentate este extrem de simplă, cu toate acestea, are un impact foarte eficient asupra organizării procesului de producție. După furnizarea diviziunilor întreprinderii în ceea ce privește resursele, se efectuează un calcul detaliat al volumului necesar de lucru în curs, care ar trebui să provină direct din penultima etapă (comanda pentru produsul finit, în consecință, este etapa finală a procesul). În mod similar, din penultima etapă se face o cerere până la etapa anterioară pentru un anumit volum de semifabricate.

Astfel, scara producției la un anumit loc se formează în conformitate cu nevoile următoarei etape de producție. Este logic ca între fiecare două etape ale procesului de producție situat în vecinătate să se stabilească un dublu tip de legătură:

1. De la a n-a etapă până la n-1, este solicitată cantitatea necesară de lucru în curs („tras”).
2. De la etapa n-1 până la etapa a n-a, resursele materiale sunt trimise în volumul necesar.

Instrumente de transfer de informații

Pentru a înțelege mai bine kanban - ce este, ar trebui să înțelegeți că instrumentul de transmitere a informațiilor în acest sistem sunt carduri speciale, care sunt clasificate în două grupuri:

1. Instrumente legate direct de comanda de producție. În acest tip de carduri este mai întâi indicat numărul de piese care trebuie produse în etapa anterioară a procesului de producție. Ele sunt trimise din etapa a n-a de producție în etapa n-1 și servesc drept motiv principal pentru dezvoltarea programului de producție pentru aceste site-uri.
2. Instrumentele de selecție conțin informații referitoare la volumul resurselor materiale necesare (acestea pot include semifabricate, materiale, piese etc.) care trebuie luate la etapa anterioară de asamblare. Cardurile de acest fel afișează volumul de resurse efectiv primit de etapa a n-a a procesului de producție de la n-1.

Este important de menționat că cardurile pot circula nu numai în raport cu infrastructura internă a întreprinderii, ci și între sucursalele sau corporațiile acesteia care susțin cooperarea.

Metode eficiente de utilizare a Kanban - ce este?

Taiichi Ohno, președintele Toyota Motor Corporation, a dezvoltat o serie de principii pentru utilizarea cardurilor kanban cu eficiență maximă:

• Operarea ulterioară a activității de producție elimină din operațiunea anterioară volumul de piese indicat de card.
• Operațiunea de producție situată în față se desfășoară în conformitate cu crearea pieselor în cantitatea și succesiunea indicate pe un card specific.
• Nu există piese care să poată fi create fără un card. Această prevedere permite reducerea supraproducției, precum și circulația excesivă a produselor. Astfel, volumul cardurilor aflate in circulatie este egal cu cantitatea maxima de inventar.
• Un card este o comandă pentru fabricarea unui produs (produsul este în orice caz atașat cardului corespunzător).
• Piesele care au vreun defect nu pot fi transmise procesului din aval. Această prevedere face posibilă producția de produse cât mai lipsită de defecte.
• Reducerea numărului de carduri crește nivelul de sensibilitate al acestora. Astfel, ies la iveală problemele existente și se realizează un control eficient asupra stocurilor.

Caracteristici de utilizare a cardurilor

După cum s-a dovedit, gestionarea kanban este efectuată conform unei anumite scheme, care implică utilizarea de carduri speciale. Astfel, în timpul utilizării lor, cerințele pentru asigurarea unei vizibilități absolute și a unei siguranțe maxime a sistemului în cauză trebuie să fie pe deplin implementate: pierderea cardurilor, precum și amestecarea acestora, este complet eliminată.

Experții au dezvoltat un instrument eficient care vă permite să oferiți productivitate maximă sistemului Kanban. Tabloul acestei metode servește ca punct de colectare a cardurilor active, deoarece angajații folosesc adesea mai multe instrumente diferite la locul de muncă. Astfel, cardurile care merg la producător sunt plasate pe placa de control. Și când instrumentele de card nou primite ajung în câmpul „start”, întregul set de carduri cu numărul de piese corespunzător este transferat pentru a efectua procesul de producție ulterioară.

Beneficiile utilizării metodei Kanban - ce este?

Întreprinderile care îl folosesc primesc provizii zilnice de resurse materiale (și adesea de mai multe ori pe parcursul zilei). Acest lucru face posibilă actualizarea completă a stocurilor de producție de aproximativ 100-300 de ori pe parcursul anului. Dacă comparăm Kanban cu sisteme precum MRP sau MAP, atunci în acest caz, actualizările apar de aproximativ 10 ori mai des.

Este indicat să evaluați metoda kanban cu exemple care să dezvăluie avantajul ei absolut față de altele, mai puțin productive. Astfel, Toyota Motors Corporation a furnizat resurse unuia dintre numeroasele site-uri de producție de trei ori pe zi în 1976, iar în 1983 - la fiecare zece minute.

Kanban-urile sunt adesea folosite în lucrul cu supermarketuri (stoc special format în acest scop). Astfel, consumatorul trimite supermarketului un kanban de selecție, care indică, după cum s-a menționat mai sus, volumul produsului, iar supermarketul îi transferă numărul specificat de produse. În același timp, supermarketul trimite furnizorului un kanban de reaprovizionare, după care furnizorul transferă produsele în supermarket.

Elemente fundamentale ale metodei

Cele mai importante componente ale unui sistem kanban sunt următoarele:

1. Un complex de informatii care contine in structura sa nu doar carduri, ci si grafice de productie, transport sau aprovizionare, precum si harti tehnologice.
2. Un complex care este direct legat de controlul asupra nevoilor și din punct de vedere profesional.
3. Un complex care permite controlul total (TQM) și selectiv (Jidoka) al calității produselor.
4. Un complex care asigură nivelarea absolută a producției.

Elementele prezentate, utilizate împreună, fac posibilă realizarea celui mai scurt ciclu de producție, un nivel ridicat de rotație a activelor (inclusiv stocurile), precum și eliminarea sau minimizarea costurilor de depozitare atât pentru producție, cât și, bineînțeles, realizarea celei mai înalte calități a produs în fiecare etapă a procesului de producție.

Dezavantajele sistemului și rezultatele utilizării acestuia

Ca orice dezvoltare, sistemul just-in-time are unele dezavantaje. În primul rând, este dificultatea de a organiza un nivel ridicat de consistență între etapele producției unui anumit produs.

În al doilea rând, există un risc semnificativ de perturbare a procesului de producție și, în consecință, a vânzării produselor. Cu toate acestea, o analiză detaliată a practicii mondiale în legătură cu aplicarea metodei în cauză a arătat că sistemul prezentat face posibilă reducerea la jumătate a stocurilor de producție și a stocurilor cu 8%, cu o accelerare semnificativă a cifrei de afaceri a capitalului de lucru și , firesc, o creștere a calității produsului finit.

Este important de menționat că utilizarea kanban-urilor nu se termină cu procesele de producție. Astfel, sistemul este utilizat activ în activități de birou și de proiect, în programare (există un întreg complex de dezvoltare kanban), precum și în obținerea de rezultate personale (tip personal de kanban).

Sistemul kanban și-a început călătoria în anii 1950 pe liniile de producție ale Toyota Corporation, după care a migrat către birouri și a devenit un instrument important pentru managerii de proiect.

Flexibilitatea nesfârșită a practicii și oportunitățile sale de auto-organizare a personalului au făcut posibilă atingerea eficienței acolo unde alte abordări nu au funcționat. Acesta este cazul când cardul în sine a devenit cartea de vizită a sistemului - s-a impus ca monedă internă în organizațiile care au implementat Kanban.

Origine

La fel ca și conceptul de manufactură lean, sistemul kanban a fost dezvoltat de managerii Toyota. Autorul sistemului, inginerul japonez Taiichi Ono, s-a inspirat din principiul de funcționare al supermarketurilor americane, unde cumpărătorul însuși alegea bunurile de care avea nevoie. Rolul de „supermarket” în corporația Toyota a fost îndeplinit de un depozit.

Acolo, carduri de semnal - și așa este tradus literalmente „kanban” din japoneză - lucrătorii au schimbat carduri de semnal, reglând procesul de producție cu propriile mâini.

Cardurile au fost atașate la containere cu piese. Aceste etichete conțineau informații despre numărul și cantitatea pieselor, care departament le trimitea și unde ar trebui să ajungă.

Muncitorul care s-a implicat direct în instalarea și asamblarea mașinilor - cel din aval - a preluat piese din container, pe care a fost atașat un „kanban” cu cerere pentru depozit. Cardul a fost scos și, împreună cu cutia goală, a fost transferat de către transportator la depozit. Acolo, un alt angajat pregătise deja un nou container de piese de schimb, pe care era atașat un „kanban” de producție - o etichetă cu informații despre piesele de schimb produse.

Kanbanul de producție a fost înlocuit cu un kanban de cerere pentru depozit și trimis la linia de producție de piese - în amonte. Prin urmare, a fost produs exact numărul de piese care a fost indicat pe card. Containerele cu piese de schimb noi au fost duse la transportatorii de pe linia de asamblare.

Principiile Kanban

Managerii Toyota au formulat 6 reguli de formare a sistemului:

1. Muncitorii din aval scot din depozit exact atâtea piese cât este indicat în kanban
2. Reprezentanții din amonte furnizează și piese de schimb strict în conformitate cu cardurile
3. Nimic nu este produs sau mutat fără un Kanban.
4. Kanban ar trebui să fie întotdeauna atașat la piese
5. Piesele defecte nu sunt utilizate în sistem
6. Reducerea numărului de carduri kanban face managementul mai receptiv la schimbare. Dar dacă nu este absolut necesar, nu ar trebui să modificați numărul stabilit de cărți.

Kanban este un sistem „pull”. Acesta creează un echilibru între fluxul constant, care elimină costurile de așteptare și lucru minim în proces (WIP), care reduce riscul de supraproducție. RVP-ul este reglementat folosind carduri: numărul lor este fix, iar instrucțiunile din ele ghidează performanții din aval.

Regula unei etichete obligatorii funcționează ca legea conservării energiei.

Limita RVP se întocmește proporțional cu numărul de carduri kanban, care se calculează în funcție de nivelul vânzărilor și de variația statistică a proceselor curente. Numărul maxim de etichete – aceeași „energie” în sistem – fixează nivelul superior al RVP la un moment dat. RVP este, de asemenea, limitat de principiul de tragere: viteza de producție a debitului superior depinde de viteza debitului inferior.

Graficul arată că unul dintre elementele de bază ale sistemului este cultura Kaizen. Procesul autonom și variația standard eliberează managementul de managementul constant, astfel încât să se poată concentra pe îmbunătățirea performanței angajaților.

Aplicarea Kanban în IT

În timp ce Kanban continuă să ofere valoare pe liniile de producție, și-a făcut loc în lumea software-ului.

Numai cardurile care conțin informații despre termene limită, o descriere sau un număr de proces și numele executantului sunt acum atașate nu la containerul cu piese de schimb, ci la o tablă cu coloane căptușite:

• Backlog - sarcini care trebuie finalizate
• Sarcini care sunt în curs de dezvoltare
• Sarcini care sunt finalizate, dar care nu au fost încă transferate către testeri
• Sarcini gata pentru a fi transferate departamentului de testare
• Sarcini care sunt revizuite de managerul de proiect (PM)
• Sarcini finalizate

Un număr este de obicei scris deasupra coloanelor - limită, indicând numărul maxim de procese din acesta. Limita de backlog este calculată în funcție de timpul de livrare. Dacă sistemul are 5 lucrări în desfășurare, iar fiecare dintre ele durează în medie 1 zi pentru a se finaliza, atunci restanța poate fi limitată la o limită de 5.

Structura de mai sus nu este strictă - În funcție de specificul proiectului, pot fi adăugate difuzoare improvizate. Adesea există un sistem kanban în care este necesar să se determine criteriile pentru pregătirea unei sarcini înainte de executarea acesteia. Apoi apar două coloane, care în engleză se numesc specifica(precizați parametrii) și a executa(incepe munca).

• Mai mult se poate adăuga o coloană cu o coadă de prioritate.Când executantul este liber, el trebuie să golească această coloană specială de sarcini și apoi să preia altele.
• Sarcinile care nu au fost finalizate sunt fie returnate în restante, fie eliminate din schemă.

• Kanban nu încurajează multitasking-ul, așa că o limită de proces este stabilită pentru un executor.

• Lucrarea finalizată este de preferat decât mai multe începute.

• Puteți prelua un al doilea loc de muncă dacă primul a fost blocat.
• Timpul pentru finalizarea unei sarcini trebuie să fie echilibrat.O perioadă prea scurtă va afecta calitatea. O limită supraextinsă risipește resursele echipei și crește costul procesului.

De ce se folosește o placă Kanban peste tot și nu, de exemplu, tablete sau un monitor uriaș? Pe măsură ce fanii sistemului răspund la această întrebare, o placă obișnuită are două avantaje: este simplă și oferă control vizual. Este ușor să faci schimbări și oferă interacțiune tactilă și socială între membrii echipei.

Avantajele și dezavantajele Kanbanului

Kanban are următoarele avantaje:

1. Flexibilitatea planificării. Echipa se concentrează doar pe munca curentă, prioritatea sarcinii este stabilită de manager.
2. Implicarea ridicată a echipei în procesul de dezvoltare. Prin întâlniri regulate, procese transparente și oportunități de auto-organizare, angajații se unesc și manifestă un interes real.
3. Durată mai scurtă a ciclului. Dacă mai multe persoane au abilități similare, durata este redusă, dar dacă există doar una, apare un blocaj. Prin urmare, angajații trebuie să împărtășească cunoștințele și, prin urmare, să optimizeze timpii de ciclu. Apoi, întreaga echipă poate prelua munca care s-a blocat și poate restabili curgerea fluidă.
4. Mai puține blocaje. Limitele RVP vă permit să găsiți rapid blocaje și zone cu probleme care au apărut din cauza lipsei de atenție, de oameni sau de abilități.
5. Vizibilitate. Când toți lucrătorii au acces la date, blocajele sunt mai ușor de detectat. Echipele Kanban, pe lângă cardurile în sine, folosesc de obicei două rapoarte generale: grafice de control și flux cumulativ.

În practică, sistemul funcționează bine în zonele de producție non-core:

• asistență software sau echipe de birou de asistență.
• Kanban funcționează bine atunci când gestionați startup-uri fără un plan clar, dar în care dezvoltarea avansează în mod activ.

Kanban are și dezavantaje:

1. sistemul nu funcționează bine cu echipe de mai mult de 5 persoane
2. nu este destinat planificării pe termen lung.

Diferențele față de Scrum

Scrum, ca și kanbanul agil, este o metodologie flexibilă și este adesea folosită și în domeniul IT. Diferențele dintre ele nu sunt evidente la prima vedere. Există multe asemănări, de exemplu, prezența unui întârziere în ambele abordări.

	Scrum	Kanban
Ritm	Sprinturi repetabile de durată fixă	Proces continuu
Eliberare de eliberare	La sfârșitul fiecărui sprint după aprobarea de către managerul de proiect (proprietar de produs)	Fluxul continuă fără întrerupere sau la discreția echipei
Roluri	Product Owner, Scrum Master, Echipa de dezvoltare	O echipă condusă de un prim-ministru, în unele cazuri, este implicată traineri kanban agile
Principalii indicatori	Viteza echipei	Timp de conducere
Acceptabilitatea modificărilor	Schimbările în timpul unui sprint sunt nedorite, deoarece pot duce la estimări incorecte ale sarcinilor	Schimbarea poate avea loc oricând

Exemple de aplicații în IT

Direct de la Microsoft: Kanban debutează în dezvoltarea de software

Utilizarea principiilor Kanban în industria tehnologiei informației a început cu puțin peste 10 ani în urmă. David Anderson, unul dintre principalii popularizatori ai Kanban pentru dezvoltatorii de software, a consultat pentru Microsoft în 2005. Au fost nemulțumiți de munca departamentului lor - XIT Sustained Engineering, care a eliminat erorile din aplicațiile interne. La începutul anului de raportare, acest departament era cel mai prost din departamentul său. Întârzierea a depășit de 5 ori dimensiunea permisă, iar timpul de procesare a unei cereri a fost timp de conducere- dura de obicei 5 luni.

Noul PM, cu ajutorul consultărilor lui Anderson, a crescut productivitatea departamentului cu probleme cu 155% în 9 luni. Timp de conducere a fost acum 5 săptămâni, restanța a revenit la dimensiunea normală, iar finalizarea la timp a sarcinilor a fost stabilită la 90%. Toate aceste rezultate au fost obținute cu implicarea minimă a noilor angajați; personalul a continuat să corecteze erorile software folosind aceleași metode - S-au schimbat doar abordările de organizare a muncii.

Fapt interesant: managerul de program Dragoș Dumitriu, care s-a angajat să schimbe curentul la XIT, a fost fascinat de cartea lui Anderson. Spre surprinderea lui, l-a întâlnit pe ideologul software-ului Kanban chiar la Microsoft, unde își găsise un loc de muncă cu o zi înainte. Dumitriu i-a cerut lui Anderson să-l ajute în sarcina sa, iar acesta din urmă a acceptat să pună în practică principiile cărții sale.

Dumitriu a găsit un departament format din trei dezvoltatori și trei testeri care aveau 80 de solicitări acumulate în backlog. Prim-ministrul însuși a fost numit temporar, deoarece cerințele pentru post includeau capacitatea de a lucra cu tehnologia ASP, administrarea folosind SQL Server și cunoștințele MS Project Server. Șefii au văzut această poziție ca pe un „tehnist” care știe să programeze, ar trebui să întocmească rapoarte și să prezică încărcarea în așteptare. Se credea atunci că problema departamentului va fi identificată dacă s-ar colecta o serie impresionantă de date. Dumitriu nu era un astfel de „techie”.

Cu toate acestea, pe măsură ce el și Anderson au început să analizeze performanța XIT, el a identificat rapid factorii cheie care aveau un impact negativ asupra vitezei departamentului:

• A durat prea mult timp pentru a prezice consecințele (ROM) ale executării unei cereri. Atât dezvoltatorul, cât și testerul au trebuit să petreacă o zi întreagă pentru a efectua calculele necesare, revizuirea codului și documentația completă. În medie, o solicitare a fost primită zilnic. Conform estimărilor PM, 40% din productivitatea departamentului a fost cheltuită pe ROM;
• S-a acordat prioritate cererilor cu valoare mai mare. XIT a primit finanțare din costul comenzii. Prioritatea solicitarilor a fost discutata lunar la o intalnire a managerilor de departamente cu clientii – managerii altor departamente. Cu un restanțe explozive la viteza actuală, când erau procesate doar 6-7 solicitări pe lună, prioritățile altor solicitări se schimbau constant din cauza trecerii timpului. Mulți dintre ei au fost amânați pentru un impresionant „mai târziu”, nici măcar egal cu luna următoare.
• La etapa ROM, jumătate din solicitări au fost eliminate. Unele dintre ele erau prea mari și au fost recalificate ca proiecte pentru a fi transferate în alte departamente, altele erau prea scumpe și pur și simplu au fost anulate. Unele solicitări nu au fost luate în dezvoltare deoarece implementarea lor ar fi fost prea lungă. Astfel, 40% din productivitatea departamentului a fost cheltuită pe analiza cererilor, dintre care 50% au fost respinse. Aproximativ 15-20% din resursele de muncă au fost irosite.
• Lucrările pregătitoare pentru cerere ar putea dura luni de zile înainte de a începe implementarea. Calculele din etapa ROM se pot pierde sau uita în acest timp. Mai ales dacă implementarea nu a fost realizată de același dezvoltator care a început analiza.

Soluții Kanban pentru un departament Microsoft cu probleme

1. Dumitriu și Anderson au insistat în discuțiile cu managementul și cu managerii clienți să abandoneze etapa ROM. Calculele au fost făcute imediat înainte de implementare și de același executant, adică au rămas „proaspete”.
2. Prioritizarea cererilor s-a realizat nu în cadrul ședințelor lunare, ci în funcție de situație, prin apeluri telefonice sau e-mailuri. 80 de sarcini din backlog au fost sortate în funcție de clienți. Aceștia din urmă au fost rugați să evidențieze principalele interogări care trebuie completate mai întâi.
3. Finanțarea XIT a devenit fixă.
4. Costul cererilor nu mai este luat în considerare.
5. Premierul a intrat în buffere pe panoul Kanban. Dezvoltatorii au preluat lucrări din două zone: sarcini aprobate și finalizate. Au fost 6 cereri în buffer, 5 au fost duse la muncă. Testeri selectați din memoria tampon „în așteptare pentru testare”. Unele sarcini care nu necesitau modificări ale codului au ajuns acolo, ocolind dezvoltatorii. Prin împărțirea cererilor în procese cu o singură sarcină, PM ar putea avea un control mai mare asupra situației, precum și să ofere transparență clienților. Introducerea tampoanelor a redus timpul de conducere. Clienții, într-un sistem previzibil, sunt mai capabili să determine a cui cerere ar trebui să fie tamponată în continuare.
6. Dacă cererile erau prea mari sau scumpe, o decizie a fost luată imediat. Dacă dezvoltatorul a confirmat că este gata să finalizeze sarcina în termen de 15 zile sau că modificările au meritat, atunci cererea a fost preluată, indiferent de dimensiune sau cost.
7. După ce a observat fluxul din departament, prim-ministrul a ajuns la concluzia că structura personalului ar trebui schimbată în favoarea dezvoltatorilor care erau mai încărcați de muncă. Modificările au fost efectuate într-un raport de 2:1: 4 dezvoltatori și 2 testeri au început să lucreze la XIT.

La sfârşitul anului 2005, productivitatea departamentului a crescut cu 155%. Pentru a îmbunătăți și mai mult activitatea XIT, acolo au fost angajați doi angajați: un dezvoltator și un tester. Numărul de solicitări din backlog a scăzut la 10, iar un dezvoltator a început să proceseze în mod constant 11 solicitări pe trimestru. În medie, au fost finalizate 56 de solicitări pe trimestru, comparativ cu 11 anterior. Costul cererilor a scăzut de la 7.500 USD la 2.900 USD.

Aplicație la Corbis

După ce a obținut succes la Microsoft, Anderson a început să rezolve o nouă provocare în 2006. Acum lucra la Corbis, o altă companie a lui Bill Gates, care încă nu părăsise MS. Una dintre activitățile lui Corbis a fost acordarea de licențe pentru fotografii. La acea vreme, era al doilea cel mai mare stoc de fotografii din lume, cu o bază de date de aproximativ 3,5 mii de imagini.

Sarcina lui Anderson era să accelereze lansările majore ale companiei. Intervalul dintre ieșirile lor era de trei luni și putea crește și mai mult. Doar discutarea planului de lansare a durat două săptămâni. A fost necesar să se organizeze lansări sau actualizări minore la fiecare două săptămâni. În același timp, resursele cheie trebuiau direcționate pentru a lucra la proiectul principal.

O tablă Kanban a apărut în biroul Corbis, unde Anderson comunica zilnic cu echipa. Scopul PM a fost de a îmbunătăți controlul vizual asupra proceselor, de a promova auto-organizarea și o mai mare responsabilitate personală a interpreților. Sistemul Kanban a avut ca scop, de asemenea, reducerea supravegherii managementului și creșterea productivității.

Pe lângă cărți și grafice multicolore, pe tablă a apărut un „coș de gunoi”; sarcinile prea mari au fost trimise în ea.

Fotografie de la oficial

Un sistem Kanban pentru susținerea ingineriei pe sisteme software de David J Anderson

Sistemul kanban a arătat clar unde fluxul încetează să mai fie fluid și unde apar întârzieri, așa-numitul blocaj. Discuțiile rapide cu echipa au ajutat la identificarea problemelor actuale. De exemplu, testarea a durat 3 zile, ceea ce a afectat negativ data lansării. Trei angajați au făcut echipă și au găsit o modalitate de a reduce timpul la o zi.

Un blocaj este o secțiune a schemei de operare sau a algoritmului unei companii în care limitările de resurse sau productivitatea oamenilor reduc drastic fluxul de sarcini. Lipsa de muncitori, internet slab sau un director în blocuri de vacanță sau încetinește îndeplinirea sarcinilor.

Limitele cardurilor Kanban au fost stabilite empiric de două ori. În coloana „gata pentru dezvoltare”, limitele au fost mărite. Există, de asemenea, o nouă coloană - „gata pentru testare”. Multe cereri pentru aval au fost formulate incorect, provocând pierderi de timp inutile. Prin urmare, PM a examinat funcționarea fluxului superior și a găsit erori.

Procesarea cererilor ar putea dura 100 de zile, dar lansările au început totuși să apară la fiecare două săptămâni, așa cum era planificat. Decizia asupra conținutului ediției a fost luată cu 5 zile înainte de publicare. Practicile de numărare, ca în cazul departamentului XIT al Microsoft, au fost abandonate în favoarea productivității. Sarcinile au fost prioritizate în funcție de „costul întârzierii” sau disponibilitatea resurselor.

Sistemul Kanban nu numai că l-a ajutat pe Anderson să-și atingă obiectivul, dar a îmbunătățit și starea de spirit în echipă. Datorită discuțiilor comune și vizibilității proceselor, angajații au dezvoltat încredere unii în alții. De asemenea, personalul s-a alăturat Kaizen, adică practica de îmbunătățire continuă.

Ce este metodologia kanban și cum vă ajută să finalizați sarcinile la timp?

În condiții de multitasking constant și un număr mare de clienți, mai devreme sau mai târziu orice sistem devine supraîncărcat. Termenele încep să fie ratate, așteptările nu sunt îndeplinite, iar sistemul se transformă în haos. Astăzi îmi propun să facem cunoștință cu o metodologie precum kanban. Această abordare promite alocarea eficientă a resurselor și rezolvarea tuturor problemelor noastre. Sa verificam.

Un moment al istoriei kanban

Baza ideii kaban a fost inventată de Toyoyta Motors. Un producător de mașini suferea pierderi mari din cauza alocării necorespunzătoare a stocurilor și a capacității pe linia de producție. Unele etape de producție ar putea fi inactive, iar unele au fost supraîncărcate.

În 1959, a fost propus un sistem de control al producției care a făcut posibilă echilibrarea tuturor secțiunilor liniei. Principiul de bază a fost că, în fiecare etapă, lucrătorii au postat carduri cu numărul necesar de piese, care au fost transmise pe linie. Fiecare muncitor care a urmat de-a lungul liniei de producție a luat din precedentul exact atâtea piese câte i-au fost alocate pe card.

În acest fel, fiecare parte avea un card și pur și simplu nu putea exista niciun surplus. Ca urmare, stocurile nu au crescut în zone și fiecare muncitor ulterior a primit exact numărul de piese de care avea nevoie.

Să formulăm ce este kanban și să-l aplicăm în dezvoltarea produselor de pe Internet.

Kanban este un sistem de management lean manufacturing (în japoneză: „semnal”/„card”) care utilizează carduri de informații pentru a comunica comenzile prin toate etapele producției. Cu cuvinte simple, urmărim întreaga cale a unui produs, de la idee până la lansare pe raftul magazinului.

Mai sus este o placă kanban. Acesta este instrumentul principal pentru afișarea stării sarcinii. Principiul principal: vedem în ce stadiu al procesului de producție se află o anumită sarcină. În plus, timpul este urmărit în toate zonele, adică puteți găsi întotdeauna „ ” în sistem și puteți lucra cu ele.

Numărul de coloane îl determinați singur pe baza caracteristicilor proiectului dumneavoastră. Este important ca acestea să fie principalele etape prin care trece produsul tău. Exemplul de mai sus este în plus sau în minus principalele etape prin care trece un produs online.

Aplicarea metodologiei este foarte largă. Kanban este folosit pentru implementarea proiectelor, managementul vânzărilor, linii de producție, dezvoltare IT și chiar pentru organizarea propriei vieți.

Îmi pare rău că întrerup lectura. Alăturați-vă canalului meu Telegram. Anunțuri noi de articole, dezvoltare de produse digitale și hack de creștere, totul este acolo. Te aştept! Hai sa continuăm...

Principiile Kanban

• Afișarea vizuală a sarcinilor. Toate sarcinile trebuie prezentate sub formă de cartonașe și reflectate pe tablă. Este foarte important să actualizați starea sarcinilor. De exemplu, dacă dezvoltatorii au pregătit codul și l-au trimis pentru testare, atunci cardul de sarcini ar trebui să meargă în coloana corespunzătoare. Astfel, orice membru al echipei poate vedea în orice moment în ce stadiu se află sarcina.
• Limitarea coloanelor WIP (lucrări în derulare sau lucrare efectuată simultan) la fiecare etapă de producție. Pentru a vă asigura că sistemul nu se „suflă” mai devreme sau mai târziu din fluxul de sarcini, este necesar să stabiliți restricții. De exemplu, pe panoul kanban de mai sus în coloana Analiză (analitice), avem 2 persoane care lucrează și se pot ocupa de cel mult 2 sarcini, nu are rost să le încărcăm mai mult, deoarece etapele ulterioare ale sistemului vor fi inactive. Restricțiile coloanelor sunt selectate empiric.
• Concentrați-vă pe sarcinile neîndeplinite. Când vă uitați la tabla cu sarcini, acordați atenție în primul rând acelor sarcini care „atârnă” într-una sau alta coloană. Dacă una dintre etape vă ia cel mai mult timp, atunci încercați să redistribuiți resursele sau să adăugați oameni, dacă este posibil.
• Imbunatatire continua. Odată ce echilibrați sarcina din sistem, vă va fi mai ușor să monitorizați întregul proces. Măsurați timpul ciclului (cât timp se blochează sarcina într-o coloană separată și cât timp din momentul în care intră în Pentru a face până la lansarea Terminat). Schimbați sarcinile din sistem și reduceți timpul necesar pentru a finaliza toate etapele.
• Acordați atenție detaliilor. De exemplu, dacă codul pe care dezvoltatorii îl scriu periodic nu trece testarea și este returnat pentru revizuire, atunci poate că există opțiuni pentru a îmbunătăți calitatea dezvoltării, astfel încât un produs de calitate superioară să fie testat?

Abordarea kanban poate părea idealistă, dar vă asigur că principiile sale produc rezultate. În primul rând, trebuie să adaptați metodologia la situația dvs. și apoi să lustruiți sistemul.

Instrumente Kanban

Sau unde să întreținem o placă kanban.

• tabele Excel
• Placă cu autocolante
• O altă fantezie...

De fapt, există o mulțime de opțiuni, îl puteți căuta pe google și vă puteți inspira. Principalul lucru este că aveți această tablă și toți participanții la proces pot vedea ce se întâmplă cu sarcinile în acest moment.

Exemple de panouri kanban

Iată o tablă care atârnă pe perete, unde fiecare sarcină este reflectată pe note lipicioase.

Sau ar putea fi un serviciu cloud precum Trello.

Există o serie de opinii despre ce instrumente și opțiuni să utilizați în munca dvs., dar aceasta este în mare parte o chestiune de gust. Doar încercați diferite soluții și decideți-vă pe cea care vă place cel mai mult. Ideea este să începeți să utilizați kanban și să nu rămâneți blocat în utilizarea celei mai frumoase table posibile.

Părerea mea este următoarea: pentru brainstorming sau lucrul la cazuri offline, funcționează bine o tablă obișnuită cu autocolante. Dar pentru munca de zi cu zi, desigur, trebuie să utilizați o soluție cloud precum Jira, Kanbantool, Trello etc. În ele, întreaga echipă poate adăuga comentarii la sarcini, le poate muta pe coloane și multe altele.

Nuanțe/gânduri

Dacă vorbim despre produse de internet, atunci kanban funcționează, ajută și se îmbunătățește, dar există o serie de preocupări sau nuanțe care trebuie luate în considerare.

• Cel mai probabil, introducerea limitelor WIP pe o coloană poate speria puțin echipa de management al proiectului. La urma urmei, cum poți determina câte sarcini poate rezolva în paralel un dezvoltator sau, de exemplu, un tester? Ce se întâmplă dacă introducem restricții și pur și simplu se relaxează?

Vedeți, dacă o persoană nu este complet încărcată, acest lucru nu este rău. Poate să studieze și să analizeze munca depusă, să găsească deficiențe și să le corecteze și chiar să se odihnească. În plus, vă puteți ajuta camarazii din alte părți ale procesului (coloane), mai multe detalii mai jos.

• Potrivit guruilor kanaban, sistemul funcționează ideal în echipe interfuncționale. Ei bine, așa ceva, dacă nu ai ce face, du-te să ajuți un coleg de muncă. Adevărat, pentru a forma o echipă în care dezvoltatorii pot fi testeri și invers, iar arhitectul de sistem îl va ajuta pe designer, va trebui să plătiți o mulțime de bani și merită?

Desigur, este grozav când membrii echipei învață unii de la alții și pot ajuta într-un fel dacă se întâmplă ceva. Dar pentru ca această condiție să fie îndeplinită, este necesar să existe echipe mici care de preferință să stea undeva în apropiere și să comunice constant. La proiectele mari este dificil de reprodus un astfel de schimb de experiență.

Prin urmare, sunt mai înclinat să-mi perfecționez abilitățile dacă am un moment de liniște. Uită-te la ce ai făcut, gândește-te cum poți să-l îmbunătățești, citește articole utile. O persoană este un organism viu, nu un roți dințat într-o bandă transportoare.

Total

Ne-am uitat la metodologia kanban și acum, sper că înțelegi cum să o aplici în proiectul tău. Încercați să vă împărțiți procesele în etape principale și să optimizați sistemul pe baza cunoștințelor acumulate.