La rakonto estas reala, mi vidis ĉion per miaj propraj okuloj.
Dum pluraj jaroj, unu ulo, kiel multaj el vi, laboris kiel programisto. Por la okazo, mi skribos ĝin jene: "programisto." Ĉar li estis 1Snik, sur solvo, produktentrepreno.
Antaŭ tio, li provis malsamajn fakojn - 4 jarojn en Francio kiel programisto, projektestro, li povis plenumi 200 horojn, samtempe ricevante procenton de la projekto, por administrado kaj farante iom da vendo. Mi provis evoluigi produktojn memstare, estis la estro de la IT-sekcio en granda kompanio kun 6 mil homoj, provis malsamajn eblojn por uzi mian citeblan profesion - 1C-programisto.
Sed ĉiuj ĉi tiuj pozicioj estis iom senelirejoj, ĉefe laŭ enspezo. Tiutempe ni ĉiuj ricevis proksimume la saman monon kaj laboris sub la samaj kondiĉoj.
Ĉi tiu ulo scivolis kiel li povus gajni pli da mono sen vendi aŭ krei sian propran komercon.
Li opiniis sin inteligenta ulo kaj decidis trovi niĉon en la firmao kie li laboris. Ĉi tiu niĉo devis esti io speciala, ne okupata de iu ajn. Kaj mi volis, ke la kompanio mem volu pagi monon al persono en ĉi tiu niĉo, por ke ne necesus trompi iun ajn aŭ trompi ion ajn. Por fari ĉi tiun celon: homo en ĉi tiu pozicio devas esti pagita multe da mono. Ekscentrulo, unuvorte.
La serĉo estis mallongdaŭra. En la kompanio, kie ĉi tiu ulo laboris, estis tute senpaga niĉo, kiu povus esti nomata "ordigi aferojn en komercaj procezoj". Ĉiu kompanio havas multajn problemojn. Io ĉiam ne funkcias, kaj ne ekzistas persono, kiu venos kaj riparos la komercan procezon. Do, li decidis provi sin kiel specialisto, kiu povas helpi la posedanton solvi siajn problemojn en komercaj procezoj.
En tiu tempo, li laboris por la firmao dum ses monatoj kaj ricevis la mezan salajron en la merkato. Estis nenio por perdi, precipe ĉar li povis facile trovi la saman laboron ene de unu semajno. Ĝenerale, ĉi tiu ulo decidis, ke nenio malbona okazos, se subite nenio funkcios kaj li estos maldungita.
Li kuraĝiĝis kaj venis al la posedanto. Mi sugestis, ke li plibonigu la plej probleman procezon en la komerco. Tiutempe ĝi estis magazena kontado. Nun ĉiuj, kiuj laboras en ĉi tiu kompanio, eĉ hontas memori tiujn problemojn, sed inventaroj, kiuj estis faritaj trimonate, montris diferencojn inter la kontada sistemo kaj realaj saldoj de dekoj da procentoj. Kaj en kosto, kaj en kvanto, kaj en la nombro da pozicioj. Estis katastrofo. La kompanio efektive havis la ĝustajn bilancojn en la kontada sistemo nur kvar fojojn jare - la tagon post la inventaro. Nia ulo komencis ordigi ĉi tiun procezon.
La ulo konsentis kun la posedanto, ke li devas redukti la deviojn de la inventarrezultoj je duono. Krome, la posedanto havis nenion specialan por perdi, ĉar antaŭ nia heroo diversaj laboristoj jam provis ĉion ripari, kaj ĝenerale la tasko estis konsiderata praktike nesolvebla. Ĉio ĉi multe nutris intereson, ĉar se ĉio funkcius, tiam la ulo aŭtomate fariĝus homo, kiu scipovas ordigi aferojn kaj solvi nesolveblajn problemojn.
Do, li alfrontis la taskon: redukti deviojn bazitajn sur inventarrezultoj je 2 fojojn ene de jaro. Je la komenco de la projekto, li tute ne sciis kiel atingi tion, sed li komprenis, ke magazena kontado estas simpla afero, do li ankoraŭ povos fari ion utilan. Cetere, redukti deviojn de dekoj de procentoj al unu dekoj de procentoj ne ŝajnas esti tiel malfacila. Ĉiu, kiu laboris en konsultado aŭ similaj agadoj, komprenas, ke la plej multaj procezaj problemoj povas esti solvitaj per sufiĉe simplaj paŝoj.
De januaro ĝis majo, li preparis, iom aŭtomatigis ion, reverkis la magazenan kontadan komercan procezon, ŝanĝis la laborfluojn de magazenistoj, librotenistoj kaj ĝenerale refaris la tutan sistemon, sen montri aŭ rakonti ion ajn al iu ajn. En majo, li disdonis novajn instrukciojn al ĉiuj, kaj post la unua inventaro de la jaro, nova vivo komenciĝis - laboranta laŭ liaj reguloj. Por observi la rezultojn, estonte la kompanio komencis fari inventarojn pli ofte - unufoje ĉiun duan monaton. Jam la unuaj rezultoj estis pozitivaj, kaj ĝis la fino de la jaro, devioj de la kontrolaj rezultoj falis al frakcio de unu procento.
La sukceso estis kolosa, sed oni ne povis kredi je ĝia daŭripovo. La ulo mem dubis, ke la rezulto estus konservita, se li flankenpaŝus kaj ĉesos observi la procezon. Tamen, estis rezulto, kaj la ulo ricevis ĉion, pri kio li konsentis kun la posedanto. Tiam, post pluraj jaroj, la stabileco de la rezulto estis konfirmita - dum pluraj jaroj la devioj restis ene de 1%.
Tiam li decidis ripeti la eksperimenton kaj sugestis, ke la posedanto plibonigu alian probleman procezon - provizon. Estis mankoj, kiuj ne permesis al ni sendi la volumojn, kiujn niaj klientoj deziris. Ni konsentis, ke ene de unu jaro la deficitoj estos duonigitaj, kaj la ulo ankaŭ kompletigos 10-15 projektojn rilatajn al 1C - por aŭtomatigi diversajn komercajn procezojn kaj aliajn herezojn.
En la dua jaro, ĉio estis sukcese kompletigita denove, deficitoj malpliiĝis je pli ol 2 fojojn, ĉiuj IT-projektoj estis kompletigitaj sukcese.
Ĉar la salajro jam plene kontentigis ĉiujn bezonojn de tiu ulo dum du jaroj anticipe, li decidis iom trankviliĝi, trankviliĝi kaj sidi en komforta, varma loko, kiun li kreis por si.
Kiel ĝi estis? Formale, li estis la IT-direktoro. Sed kiu li vere estis estas malfacile kompreni. Post ĉio, kion faras IT-direktoro? Kiel regulo, li administras la IT-infrastrukturon, administras sistemajn administrantojn, efektivigas ERP-sistemon kaj partoprenas en kunvenoj de la estraro de direktoroj.
Kaj ĉi tiu ulo havis unu el la ŝlosilaj respondecoj por partopreni en ŝanĝprocezoj, kaj ĉefe - generacio, iniciato de ĉi tiuj procezoj, serĉado kaj propono de solvoj, apliko de novaj administraj teknikoj, ekzameno de proponitaj ŝanĝoj, analizo de la efikeco de aliaj funkcioj kaj dividoj, kaj, finfine, rekta partopreno en la strategia evoluo de la entrepreno, ĝis la sendependa disvolviĝo de strategia plano por la tuta kompanio.
Li ricevis karton blankan. Li povis veni al iu ajn kunveno, kie li antaŭe ne havis aliron. Mi sidis tie kun notbloko, skribante ion, aŭ simple aŭskultante. Li malofte parolis. Tiam li komencis ludi per la telefono, asertante ke asocia memoro funkcias pli bone tiamaniere.
En la kunveno li malofte donis ion utilan. Li foriris, pensis, poste alvenis letero — ĉu kun kritiko, ĉu kun opinio, ĉu kun sugestoj, ĉu kun priskribo de la solvoj, kiujn li jam aplikis.
Sed pli ofte li mem kunvokis kunsidojn. Mi trovis problemon, elpensis solvojn, identigis interesatojn kaj venigis ĉiujn en la kunvenon. Kaj tiam — kiel eble plej bone. Li konvinkis, motivis, pruvis, argumentis, atingis.
Neoficiale, li estis konsiderita la tria persono en la firmao, post la posedanto kaj direktoro. Kompreneble, li terure furiozigis ĉiujn "personojn de la kompanio", komencante per la numero 4. Precipe kun siaj ŝiritaj jeans kaj brilaj T-ĉemizoj, kaj ankaŭ kun sia tempo kiel posedanto.
La posedanto donis al li 1 horon tage. Ĉiutage. Ili parolis, diskutis problemojn, solvojn, novajn entreprenojn, areojn de evoluo, indikilojn kaj efikecon, personan evoluon, librojn kaj simple vivon.
Sed ĉi tiu ulo estis stranga. Estas kvazaŭ, sidiĝu kaj estu feliĉa, la vivo estas bona. Sed ne. Li decidis pripensi.
Li demandis sin: kial ĝi funkciis por li, sed aliaj ne? Ankaŭ la posedanto puŝis lin: li diris, ke li volas, ke aliaj ankaŭ povu restarigi ordon, ĉar estas multaj administrantoj, ili kutime okupiĝas pri operacia administrado kaj strategia planado, sed preskaŭ neniu okupiĝas pri sistemaj ŝanĝoj. en iliaj procezoj. Eble estas skribite en ilia laborpriskribo, ke ili devas akceli sian procezon kaj pliigi ĝian efikecon, sed fakte neniu faras tion. Kial estas tio? La ulo ankaŭ interesiĝis pri kial, kaj li iris por paroli kun ĉiuj ĉi tiuj administrantoj.
Li venis al la vicdirektoro por kvalito kaj sugestis enkonduki Shewhart-kontroltablojn por ke la produktoj estu pli bonaj ol japanaj. Sed montriĝis, ke la kolego ne sciis, kio estas Shewhart-kontrolo-diagramoj, kio estas statistika proceza kontrolo, kaj nur aŭdis pri la uzo de la Deming-ciklo en kvalitadministrado. BONE…
Li iris al alia vicdirektoro kaj proponis enkonduki kontrolon. Sed ankaŭ ĉi tie mi ne trovis subtenon. Iom poste, li eksciis pri limadministrado (limadministrado) kaj sugestis, ke ĉiuj vicdirektoroj efektivigu la sisteman parton de ĉi tiu metodaro por plibonigi procezojn. Sed kiom ajn nia ulo parolis, neniu vere volis enprofundiĝi pri kio temas. Eble ili ne interesiĝis aŭ ĝi estis tro malfacila. Sed, fakte, neniu komprenis ĝin.
Ĝenerale, li parolis pri ĉio, kion li sciis kaj uzis en la kompanio. Sed neniu komprenis lin. Ili ankoraŭ ne komprenas kial, ekzemple, ĉio estis korektita en magazena kontado, kaj kion rilatas al ĝi kontrolado kaj landlima administrado.
Laste, li atingis siajn programistojn - la personaro inkludis 3 homojn. Li parolis pri limadministrado, pri kontrolado, pri kvalita administrado, pri lerta kaj scrum... Kaj mirinde, ili komprenis ĉion, kaj eĉ povis iel diskuti kun li, inkluzive de teknikaj kaj metodikaj subtilaĵoj. Ili komprenis kial la magazenaj kaj provizoprojektoj funkciis. Kaj tiam ekkomprenis la ulo: fakte, programistoj savos la mondon.
Programistoj, li rimarkis, estas la solaj, kiuj povas kompreni komercajn procezojn normale, kun la necesa detalo.
Kial ili? Fakte, li neniam trovis klaran respondon. Mi formulis nur tezajn sugestojn.
Unue, programistoj konas la temojn de la komerco, kaj ili konas ilin pli bone ol ĉiuj aliaj homoj en la kompanio.
Krome, programistoj vere komprenas, kio estas proceza algoritmo. Ĉi tio estas grava ĉar komercaj procezoj estas algoritmoj, kaj la elementoj en ili eble simple ne estas konsekvencaj. Ekzemple, en la aĉetprocezo pri kiu laboris la ulo, la unua paŝo estis krei jaran aĉetplanon, kaj la dua estis ĉiutaga aĉetado. Ĉi tiuj paŝoj estas ligitaj per rekta konekto, tio estas, oni supozas, ke homoj devas labori laŭ ĉi tiu algoritmo - ellaboru jaran akirplanon kaj tuj plenumu la peton. La jara aĉetplano estas ellaborita unufoje jare, kaj la kandidatiĝoj ricevas 50 fojojn tage. Ĉi tie finiĝas la algoritmo, kaj vi devas labori pri ĝi. Fakte, li rezonis, por programistoj, scio pri algoritmoj estas konkurenciva avantaĝo, ĉar iu ajn alia, kiu ne konas ilin, simple ne komprenas kiel komerca procezo devus funkcii kaj kiel ĝi povas esti reprezentita.
Alia avantaĝo de programistoj, laŭ la ulo, estas, ke ili havas sufiĉe da libera tempo. Ni ĉiuj komprenas kiel programisto povas elspezi trioble pli longe por tasko ol ĝi efektive postulas, kaj malmultaj rimarkos. Ĉi tio, denove, estas konkurenciva avantaĝo, ĉar por ordigi iun komercan procezon, vi devas havi multe da libera tempo - pripensu, observu, studu kaj provu.
Plej multaj administrantoj, laŭ la ulo, ne havas ĉi tiun liberan tempon kaj fieras pri ĝi. Kvankam fakte tio signifas, ke homo ne povas fariĝi efika ĉar li ne havas tempon por plibonigi efikecon - malvirtan cirklon. En nia kulturo, estas moda esti okupata, do ĉio restas same. Kaj por ni programistoj, ĉi tio estas avantaĝo. Ni povas trovi liberan tempon kaj pensi pri ĉio.
Programistoj, li diris, povas rapide ŝanĝi informsistemon. Ĉi tio ne aplikeblas ĉe ĉiuj entreprenoj, sed kie ajn li laboris, li povis fari ajnajn modifojn, kiujn li volis. Precipe se ili ne koncernas la laboron de iu alia. Ekzemple, li povus lanĉi sistemon, kiu sekrete mezurus uzantajn agojn, kaj tiam uzi ĉi tiujn informojn por analizi la efikecon de la sama kontada fako kaj spuri la koston de kontado.
Kaj la lasta afero, kiun mi memoras el liaj vortoj, estas, ke programistoj havas aliron al granda kvanto da informoj, ĉar... havi administran aliron al la sistemo. Tial ili povas uzi ĉi tiujn informojn en sia analizo. Neniu alia ĉe regula planto havas tian rimedon.
Kaj tiam li foriris. Dum la bezonata du-semajna aresto, ni devigis lin dividi lian sperton ĉar ni volis daŭrigi la laboron, kiun li faris. Nu, lia posteno iĝis vaka.
Dum pluraj tagoj, ili sidigis lin sur seĝon, ŝaltis la fotilon kaj registris liajn monologojn. Ili petis rakonti al ni pri ĉiuj finitaj projektoj, metodoj, aliroj, sukcesoj kaj malsukcesoj, kaŭzoj kaj efikoj, portretoj de administrantoj ktp. Ne estis specialaj limigoj, ĉar Ili ne sciis, kio okazas en lia kapo.
La monologoj, kompreneble, estis plejparte ĉiuj sensencaĵoj kaj ridoj - li estis en bonega humoro, ĉar estis forlasanta la dezerton al Sankt-Peterburgo. Kien vi iru labori en Sankt-Peterburgo? Al Gazprom, kompreneble.
Sed ni sukcesis eltiri ion utilan el liaj monologoj. Mi diros al vi, kion mi memoras.
Do, la rekomendoj de tiu ulo. Por tiuj, kiuj volas provi ordigi aferojn en komercaj procezoj.
Por fari tian laboron, unue, vi devas havi certan nivelon de "frosto". Vi ne timu perdi vian laboron, ne timu riski, ne timu konfliktojn kun kolegoj. Estis al li facile, ĉar li komencis sian vojaĝon, kiam li laboris en la kompanio nur ses monatojn, kaj ne havis tempon por kontakti neniun, kaj ne intencis fari tion. Li komprenis, ke homoj venas kaj iras, sed liaj propraj rezultoj kaj ilia takso de la entreprenisto estas gravaj por li. Ĉu liaj kolegoj traktis lin bone aŭ malbone, tiam malmulte zorgis por li.
La dua punkto estas, ke por efike fari ĉi tiun laboron, bedaŭrinde, vi devos studi. Sed studu ne por MBA, ne en kursoj, ne en institutoj, sed memstare. Ekzemple, en sia unua projekto, magazena projekto, li agis intuicie, li nenion sciis, kio estas "kvalita administrado".
Kiam li komencis legi la literaturon pri kiaj metodoj por pliigi efikecon ekzistis, li malkovris la teknologiojn kiujn li uzis. La ulo aplikis ilin intuicie, sed rezultas, ke tio ne estis lia invento, ĉio estis jam skribita antaŭ longe. Sed li pasigis tempon, kaj multe pli ol se li tuj legis la ĝustan libron. Ĉi tie estas nur grave kompreni, ke kiam vi studas specifan teknikon, ne unu el ili, eĉ la plej progresinta, tute solvos ĉiujn problemojn de komerca procezo.
La dua lertaĵo estas, ke ju pli da teknikoj vi scias, des pli bone. Ekzemple, en antikva Japanio vivis Miyamoto Musashi, unu el la plej famaj skermistoj, la aŭtoro de la duglava stilo. Li studis en iu lernejo kun iu majstro, poste vojaĝis tra Japanio, batalis kun malsamaj uloj. Se la ulo estis pli forta, tiam la vojaĝo ĉesis iom da tempo, kaj Musashi fariĝis studento. Kiel rezulto, dum pluraj jaroj li akiris la kapablojn de diversaj praktikoj de malsamaj majstroj kaj formis sian propran lernejon, aldonante ion propran. Kiel rezulto, li atingis unikan kapablon. Estas same ĉi tie.
Vi povas, kompreneble, agi kiel komercaj konsilistoj. Ĝenerale, ili estas bonegaj uloj. Sed, kiel regulo, ili venas enkonduki ian metodaron, kaj ili efektivigas la malĝustan metodaron, kiun la komerco bezonas. Ni ankaŭ havis tiajn malgajajn situaciojn: neniu scias kiel solvi la problemon kaj neniu volas pensi kiel solvi ĝin. Ni komencas serĉi aŭ en la Interreto aŭ vokas konsultiston kaj demandas lin, kio povas helpi nin. La konsultisto pensas kaj diras, ke ni devas enkonduki la teorion de limoj. Ni pagas lin pro lia rekomendo, ni elspezas monon por efektivigo, sed la rezultoj estas nulaj.
Kial ĉi tio okazas? Ĉar diris la konsultisto, ni enkondukas tian kaj tian sistemon, kaj ĉiuj konsentis kun li. Bonege, sed unu metodaro ne kovras ĉiujn problemojn de eĉ unu komerca procezo, precipe se la komencaj antaŭkondiĉoj - niaj kaj tiuj necesaj por efektivigi la metodaron - ne koincidas.
En la praktiko, kiun la ulo rekomendas, vi devas preni la plej bonan kaj efektivigi la plej bonan. Ne prenu la metodojn tute, sed prenu iliajn ĉefajn funkciojn, funkciojn kaj praktikojn. Kaj la plej grava afero estas kompreni la esencon.
Prenu, li diris, ekzemple, Scrum aŭ Agile. En siaj monologoj, la ulo multfoje ripetis, ke ne ĉiuj plene komprenas la esencon de Scrum. Li ankaŭ legis la libron de Jeff Sutherland, kiun kelkaj homoj trovas "malpezan legadon". Ŝajnis al li profunda legado, ĉar unu el la fundamentaj principoj de Scrum estas kvalita administrado, ĉi tio estas skribita rekte en la libro.
Ĝi diras pri Toyota Production, pri kiel Jeff Sutherland montris Scrum en Japanio, kiel ĝi enradikiĝis tie kaj kiom proksime ĝi estis al ilia filozofio. Kaj Sutherland parolis pri la graveco de la rolo de la Scrum Master, pri la Deming-ciklo. La rolo de la Scrum Master estas konstante akceli la procezon. Ĉio alia, kio estas en Scrum - laŭfaza livero, kliento kontento, klara listo de laboro por la sprinta periodo - ankaŭ estas grava, sed ĉio ĉi devas moviĝi pli kaj pli rapide. La rapideco de laboro devas konstante pliiĝi en la unuoj en kiuj ĝi estas mezurita.
Eble temas pri tradukado, ĉar nia libro estis tradukita kiel "Scrum - revolucia metodo de administrado de projektoj", kaj se la angla titolo estas tradukita laŭvorte, ĝi rezultos: "Scrum - duoble pli en duono de la tempo" , tio estas, eĉ en La nomo rilatas al rapido kiel ŝlosila funkcio de Scrum.
Kiam ĉi tiu ulo efektivigis Scrum, la rapideco duobliĝis en la unua monato sen gravaj ŝanĝoj. Li trovis punktojn por ŝanĝo kaj modifis Scrum mem por igi ĝin funkcii multe pli rapide. La sola afero, kiun ili skribas en la interreto, estas, ke ili alfrontis la demandon: "Ni duobligis la rapidecon, restas nur kompreni, kion ni faras kun tia rapideco?" Tamen, ĉi tio estas tute alia areo...
Li ankaŭ persone rekomendis plurajn teknikojn. Li nomis ilin fundamentaj kaj fundamentaj.
La unua estas limadministrado.
Ili instruas ĝin ĉe Skolkovo; laŭ la ulo, ne ekzistas aliaj libroj kaj materialoj. Li havis iel bonŝancon ĉeesti prelegon de profesoro el Harvard kiu predikas limadministradon, kaj ankaŭ legis plurajn artikolojn en la Harvard Business Review pri la laboro de Eric Trist.
Limadministrado diras, ke vi devas povi vidi limojn kaj labori kun limoj. Estas multe da limoj, ili estas ĉie - inter fakoj, inter diversaj laboroj, inter funkcioj, inter operacia kaj analiza laboro. Scio pri limadministrado ne rivelas iujn ajn pli altajn verojn, sed ĝi permesas al ni vidi realon en iomete malsama lumo - tra la prismo de limoj. Kaj sekve, administru ilin - starigu ilin kie necese, kaj forigu ilin kie ili estas en la vojo.
Sed plej ofte la ulo parolis pri regado. Li nur havis ian strangaĵon pri ĉi tiu temo.
Kontroli, mallonge, estas administrado bazita sur nombroj. Ĉi tie, li diris, ĉiu parto de la difino estas grava - kaj "administrado" kaj "bazita sur" kaj "nombroj".
Ni, li diris, estas malbonaj kun ĉiuj tri komponentoj de kontrolado. Precipe konsiderante, ke ili estas proksime interligitaj kaj unu kun la alia kaj kun aliaj partoj de la komerca sistemo.
La unua afero malbona estas la nombroj. Estas malmultaj el ili kaj ili estas de malalta kvalito.
Ni tiam prenis signifan parton de la nombroj el la informsistemo 1C. Do, la kvalito de la nombroj en 1C, kiel li asertis, ne estas bona. Minimume, pro la kapablo ŝanĝi datumojn retroaktive.
Estas klare, ke ĉi tio ne estas la kulpo de la 1C-programistoj - ili nur konsideras la postulojn de la merkato kaj la menson de hejma kontado. Sed por kontrolaj celoj, estas pli bone ŝanĝi la principojn de 1C-laboro kun datumoj ĉe specifa entrepreno.
Plue, la nombroj de 1C, laŭ li, spertas duonmanan prilaboradon, uzante Excel, ekzemple. Tia prilaborado ankaŭ ne aldonas kvaliton al la datumoj, same kiel efikecon.
Fine iu alia duoble kontrolas la finan raporton por ne hazarde sendi ciferojn kun eraroj al la administranto. Rezulte, la nombroj atingas la ricevanton bela, kontrolita, sed tre malfrue. Kutime - post la fino de la periodo (monato, semajno, ktp.).
Kaj ĉi tie, li diris, ĉio estas tre simpla. Se la nombroj pri januaro venis al vi en februaro, tiam vi ne plu povas administri la agadojn de januaro. Ĉar januaro jam finiĝis.
Kaj se la ciferoj baziĝas sur kontado, kaj la kompanio estas la plej ordinara, kun trimonata submetado de AVI, tiam ĝia administranto ricevas relative taŭgajn ciferojn unufoje trimonate.
La resto estas klara. Vi ricevas nombrojn unufoje monate - vi havas la ŝancon administri per nombroj (t.e., kontrolo) 12 fojojn jare. Se vi praktikas trimonatan raportadon, vi administras ĝin 4 fojojn jare. Plie bonuso - jara raportado. Direktu ankoraŭ unu fojon.
La resto de la tempo, kontrolo estas kutime farita blinde.
Kiam (kaj se) la nombroj ja aperas, tiam ekludas la dua problemo - kiel administri surbaze de la nombroj? Mi ne povis konsenti kun ĉi tiu punkto de lia rezonado.
La ulo argumentis, ke se la administranto ne havus la nombrojn antaŭe, tiam ilia aspekto kaŭzus wow-efekton. Li rigardos kaj tordos la ciferojn jen kaj jen, vokos homojn sur la tapiŝo, postulos klarigojn kaj esplorojn. Post ludado kun nombroj, farado de analizo kaj minace promesinte al ĉiuj dungitoj, ke "nun mi ne forigos vin", la administranto tre rapide trankviliĝos kaj rezignas pri ĉi tiu afero. Ĉesu uzi la ilon. Sed la problemoj restos en loko.
Ĉi tio okazas, li diris, pro nesufiĉaj administraj kompetentecoj. En kontrolado, unue. La administranto simple ne scias kion fari kun ĉi tiuj nombroj. Kio сfari — scias kion fari — ne. Fari estas tio, pri kio estas skribita supre (kvereli, ludi). Farado estas ĉiutaga komerca procezo.
Li argumentis, ke ĉio estas tre simpla: cifereca devas fariĝi parto de la komerca procezo. En la komerca procezo devus esti klare klare: kiu devas fari kion kaj kiam se la nombroj devias de la normo (ajna opcioj - super la limo, sub la limo, preterpasante la koridoron, la ĉeesto de tendenco, malsukceso renkonti la kvantilo, ktp.)
Kaj tiel li skizis la ŝlosilan dilemon: la nombro ekzistas, ĝi devus fariĝi parto de la komerca sistemo por pliigi administran efikecon, sed... tio ne okazas. Kial?
Ĉar la rusa gvidanto ne fordonos pecon de sia potenco al konkuranto.
La konkurantoj de la rusa administranto - altkvalita kaj laboranta komerca procezo, bone pripensita reciproke utila instigo kaj taŭga aŭtomatigo - ve, lasos la administranton sen laboro.
Ia sensencaĵo, ĉu vi ne konsentas? Precipe pri gvidantoj. Bone, mi diris al vi, vi mem decidas.
Iom malpli, sed tamen tro multe, laŭ mi, li parolis pri Scrum.
Nepre, mi diris, legu kaj provu Scrum praktike. Se, li diras, vi legis ĝin sed ne provis ĝin, konsideru vin malklera. Pli bone legi libron, ekzemple de Sutherland, prefere ol artikolojn kaj ĉiajn gvidojn (kio diable?) en Interreto.
Scrum, li diris, povas esti lernita nur per praktiko, kaj kun devigaj mezuradoj de la kvanto de laboro farita. Persone provu la du plej gravajn rolojn - Produktposedanto kaj Scrum Master.
Estas speciale grave, laŭ la ulo, sperti praktike la rolon de Scrum Master, kiam vi povas pliigi la volumon de taskoj plenumitaj per sprinto sen pliigi la rimedojn kaj koston de la sprinto.
Nu, en lia pinto estis TOS (teorio de sistemaj limigoj).
Ĉi tiuj, laŭ la ulo, estas la bazaj, fundamentaj principoj de kreskanta efikeco, kiuj povas esti aplikataj en preskaŭ ajna areo, en ajna komerca procezo kaj komerca sistemo entute.
Kiam li eksciis, ke ni ne konas TOS, li ĉesis diri al ni. Li nur aldonis, ke li ne senigos nin de la plezuro legi la librojn de Eliyahu Goldratt. Li donis similan rekomendon al Scrum - legu ĝin kaj provu ĝin. Kiel, negrave en kia pozicio vi estas, negrave kia laboro vi faras, ekzistas loko por pliigi efikecon uzante TOC-metodojn.
Tiam lia sako da teknikoj ŝajne sekiĝis, kaj li diris: miksu la principojn por krei aplikatajn solvojn en specifa situacio.
Ĉi tio, li diras, estas la ĉefa rekomendo, la ŝlosilo de sukceso. Komprenu la principojn, esencon, kaj kreu unikajn aplikajn solvojn - komercajn procezojn kaj komercajn sistemojn.
Poste li provis rememori ian citaĵon, kaj fine li devis enretiĝi. Ĝi rezultis esti citaĵo el la artikolo "Starante sur la Ŝultroj de Gigantoj" de Eliyahu Goldratt:
"Estas diferenco inter aplikataj solvoj (aplikoj) kaj la fundamentaj konceptoj sur kiuj tiuj solvoj estas bazitaj. Konceptoj estas ĝeneralaj; aplikataj solvoj estas la adaptado de konceptoj al specifa medio. Kiel ni jam vidis, tia adapto ne estas simpla kaj postulas la disvolviĝon de iuj elementoj de la solvo. Ni devas memori, ke aplika solvo baziĝas sur komencaj supozoj (foje kaŝitaj) pri specifa medio. Ĉi tiu aplika solvo ne devus esti atendita funkcii en medio por kiu la supozoj ne estas ĝustaj."
Li diris, ke la laboro de programisto kaj "komerca pliboniganto" estas tre similaj. Kaj foriris.
fonto: www.habr.com