ronu pri rabote nad pervym proektom. V rezul'tate poluchaetsya, govorya slovami Ovidiya, "bol'shaya kucha". Rassmotrim, naprimer, arhitekturu IBM 709, voploshchennuyu pozdnee v mashine 7090. |to - modernizaciya, vtorya sistema dlya ochen' uspeshnoj i horosho skroennoj sistemy 704. Nabor komand byl nastol'ko bogat i izobilen, chto regulyarno ispol'zovalas' primerno lish' polovina ego. Rassmotrim v kachestve bolee sil'nogo primera arhitekturu, razrabotku i dazhe realizaciyu komp'yutera Stretch, kotorye dali vyhod sderzhivayushchimsya izobretatel'skim stremleniyam mnogih lyudej, dlya bol'shinstva kotoryh eto bylo vtoraya sistema. Vot chto pishet v svoem obzore Strejchi (Strachey): U menya sozdalos' vpechatlenie, chto nekotorym obrazom Stretch yavlyaet soboj okonchanie opredelennogo napravleniya razrabotok. Kak i nekotorye rannie komp'yuternye programmy, eta sistema chrezvychajno izobretatel'na, chrezvychajno slozhna i ochen' effektivna, no v to zhe vremya yavlyaetsya syroj, rastochitel'noj i neizyashchnoj, ostavlyaya oshchushchenie, chto eti veshchi mozhno delat' luchshim obrazom.1 Operating System/360 byla vtoroj sistemoj dlya bol'shinstva svoih proektirovshchikov. Gruppy proektirovshchikov prishli posle raboty nad diskovoj operacionnoj sistemoj 1410-7010, operacionnoj sistemoj Stretch, sistemoj real'nogo vremeni Project Mercury i IBSYS dlya 7090. Edva li kto-to iz nih imel opyt raboty nad dvumya predshestvuyushchimi operacionnymi sistemami. Poetomu OS/360 yavlyaetsya yarkim primerom effekta vtoroj sistemy, analogom Stretch v iskusstve programmirovaniya, k kotoromu v polnoj mere primenimy i pohvaly, i upreki privedennoj kritiki Strejchi. Naprimer, v OS/360 otvoditsya 26 bajt dlya rezidentnoj procedury preobrazovaniya daty, chtoby pravil'no obrabatyvat' 31 dekabrya v visokosnom godu (kogda eto 366-j den'). |to mozhno bylo ostavit' operatoru. |ffekt vtoroj sistemy imeet i drugoe proyavlenie, krome prostogo ukrashatel'stva funkciyami. |to - sklonnost' k usovershenstvovaniyu metodov, samo sushchestvovanie kotoryh stalo anahronizmom blagodarya izmeneniyam v bazovyh principah sistemy. OS/360 soderzhit mnogochislennye primery, podtverzhdayushchie eto. Rassmotrim redaktor svyazej, prednaznachennyj dlya zagruzki nezavisimo skompilirovannyh programm i razresheniya ih perekrestnyh ssylok. Pomimo etoj osnovnoj funkcii on takzhe upravlyaet programmnymi overleyami. |to odno iz luchshih kogda-libo sozdannyh sredstv raboty s overleyami. Ono pozvolyaet sozdavat' overlejnuyu strukturu vneshnim obrazom pri redaktirovanii svyazej, ne trogaya ishodnogo koda. Ono pozvolyaet izmenyat' strukturu overleev bez perekompilyacii pri kazhdom progone. Ono predostavlyaet bogatyj vybor poleznyh opcij i vozmozhnostej. V izvestnom smysle, eto zavershayushchij itog mnogoletnej razrabotki tehnologii staticheskih overleev. I v to zhe vremya eto poslednij i sovershennejshij dinozavr, poskol'ku vhodit v sistemu, v kotoroj mnogoprogrammnost' yavlyaetsya obychnym rezhimom, a dinamicheskoe raspredelenie pamyati - bazovym principom. |to vstupaet v pryamoj konflikt s ponyatiem ispol'zovaniya staticheskih overleev. Neskol'ko luchshe rabotala by sistema, esli by usiliya, potrachennye na upravlenie overleyami, byli perenapravleny na to, chtoby uskorit' rabotu sredstv podderzhki dinamicheskogo raspredeleniya pamyati i perekrestnyh ssylok! Bolee togo, redaktor svyazej trebuet tak mnogo pamyati, i sam soderzhit stol'ko overleev, chto dazhe pri ispol'zovanii tol'ko dlya redaktirovaniya bez upravleniya overleyami ustupaet v skorosti bol'shinstvu sistemnyh kompilyatorov. Ironiya sostoit v tom, chto naznachenie redaktora svyazej - izbezhat' povtornoj kompilyacii. Kak u kon'kobezhca korpus okazyvaetsya vperedi nog, tak i usovershenstvovaniya prodolzhalis', poka ne vyshli daleko za ramki sistemnyh principov. Drugim primerom etoj tendencii yavlyaetsya otladchik TESTRAN. |to sovershennyj paketnyj otladchik, predostavlyayushchij dejstvitel'no elegantnye sredstva polucheniya mgnovennyh snimkov i dampov pamyati. V nem ispol'zuetsya ponyatie upravlyayushchih razdelov i iskusnaya tehnologiya generacii, pozvolyayushchie osushchestvlyat' izbiratel'nuyu trassirovku i poluchenie mgnovennyh snimkov bez dopolnitel'nyh rashodov na interpretaciyu ili rekompilyaciyu. Zdes' pyshnym cvetom rascveli vpechatlyayushchie koncepcii operacionnoj sistemy Share Operating System3 dlya modeli 709. Mezhdu tem ustarela sama ideya paketnoj otladki bez rekompilyacii. Glavnyj vyzov byl broshen interaktivnym vychislitel'nym sistemam s interpretatorami yazykov programmirovaniya i poshagovymi kompilyatorami. No dazhe v sistemah s paketnoj obrabotkoj poyavlenie kompilyatorov s bystroj kompilyaciej i medlennym vypolneniem sdelalo bolee predpochtitel'noj tehnologiyu otladki na urovne ishodnogo koda i polucheniya mgnovennyh snimkov. Naskol'ko luchshe okazalas' by sistema, esli by sily, potrachennye na proekt TESTRAN, byli perenapravleny na uskorennoe sozdanie luchshih sredstv dlya interaktivnoj raboty i bystroj kompilyacii! Eshche odin primer - planirovshchik, predostavlyayushchij dejstvitel'no otlichnye vozmozhnosti dlya upravleniya potokom fiksirovannyh paketov zadanij. Na praktike etot planirovshchik yavlyaetsya usovershenstvovannoj, uluchshennoj i nadelennoj raznymi ukrasheniyami vtoroj sistemoj, kotoroj predshestvovala diskovaya operacionnaya sistema 1410-7010 - sistema paketnoj obrabotki, ne yavlyayushchayasya mnogoprogrammnoj, za isklyucheniem vvoda-vyvoda, i prednaznachennoj, glavnym obrazom, dlya delovyh prilozhenij. V etom kachestve planirovshchik OS/360 horosh. No na nego pochti nikakogo vliyaniya ne okazali potrebnosti OS/360 v udalennom vvode zadanij, mnogoprogrammnosti i rezidentnom razmeshchenii interaktivnyh podsistem. I dejstvitel'no, proekt planirovshchika zatrudnyaet reshenie etih zadach. Kak arhitektoru izbezhat' effekta vtoroj sistemy? Ochevidno, propustit' svoyu vtoruyu sistemu on ne mozhet. No on mozhet otdavat' sebe otchet v osobyh opasnostyah, kotorym ona ego podvergaet, i proyavit' dopolnitel'nuyu samodisciplinu, chtoby izbezhat' funkcional'nogo ukrashatel'stva i sohraneniya funkcij, nuzhda v kotoryh otpala vvidu izmenenij v principah i celyah. Poryadok, sposobnyj otkryt' arhitektoru glaza, zaklyuchaetsya v tom, chtoby prisvoit' chislennoe znachenie kazhdoj, pust' maloj, funkcii: harakteristika x dolzhna obojtis' ne bolee chem v m bajtov pamyati i n mikrosekund na odin vyzov. |ti velichiny dolzhny sluzhit' rukovodstvom pri prinyatii nachal'nyh reshenij, a takzhe napominaniem i rukovodstvom pri realizacii. Kak menedzheru proekta izbezhat' effekta vtoroj sistemy? Nastaivat' na tom, chtoby ego starshij arhitektor imel opyt razrabotki hotya by dvuh sistem. Krome togo, buduchi osvedomlennym o vozmozhnyh opasnostyah, on mozhet pred座avlyat' neobhodimye trebovaniya dlya togo, chtoby v detal'nom proekte nashli polnoe otrazhenie ideologicheskih koncepcij i celi. Glava 6. Donesti slovo On syadet zdes' i budet rasporyazhat'sya: "Sdelajte eto! Sdelajte to!" A delo i s mesta ne sdvinetsya. GARRI S. TRUMEN. "O PREZIDENTSKOJ VLASTI"1 Kak menedzheru, imeya opytnyh disciplinirovannyh arhitektorov i dostatochnoe chislo ispolnitelej, dobit'sya togo, chtoby vse uslyshali, ponyali i vypolnili resheniya arhitektora? Kak gruppe iz 10 arhitektorov podderzhivat' konceptual'nuyu celostnost' sistemy, nad kotoroj truditsya 1000 chelovek? Dlya dostizheniya etogo pri osushchestvlenii programmy proektirovaniya apparatnoj chasti System/360 byla razrabotana celaya tehnologiya, kotoraya v ravnoj stepeni primenima dlya proektov sozdaniya programmnogo obespecheniya. Pis'mennye specifikacii - rukovodstvo Rukovodstvo, ili pis'mennaya dokumentaciya, yavlyaetsya neobhodimym, hotya i ne dostatochnym, instrumentom. Rukovodstvo yavlyaetsya vneshnej specifikaciej produkta. V nem raspisany vse podrobnosti togo, chto vidit pol'zovatel', i potomu ono yavlyaetsya glavnym produktom, kotoryj sozdaet arhitektor. Ego podgotovka idet krugami, sobiraya zamechaniya pol'zovatelej i razrabotchikov o nedostatkah proekta, zatrudnyayushchih ispol'zovanie ili realizaciyu. Dlya udobstva razrabotchikov neobhodimo kvantovat' izmeneniya: soglasno opredelennym v grafike datam vypuskat' ocherednye versii. Instrukciya dolzhna ne tol'ko opisyvat' vse, chto vidit pol'zovatel', v tom chisle vse interfejsy, no i vozderzhivat'sya ot opisaniya togo, chego pol'zovatel' ne vidit. Poslednee - zabota razrabotchika, i zdes' svoboda ego reshenij ne dolzhna byt' ogranichena. Arhitektor vsegda dolzhen byt' gotov pokazat' primer realizacii lyuboj opisannoj im funkcii, no on ne dolzhen pytat'sya navyazyvat' opredelennuyu realizaciyu. Stil' dolzhen byt' tochnym, polnym i ochen' podrobnym. Pol'zovatel' chasto obrashchaetsya k otdel'nomu opredeleniyu, poetomu vo vseh iz nih dolzhny byt' povtoreny vse sushchestvennye elementy, i vse oni dolzhny byt' soglasovany drug s drugom. Po etoj prichine instrukcii chasto skuchno chitat', no tochnost' imeet prioritet pered uvlekatel'nost'yu. Edinstvo "Principov raboty System/360" proistekaet iz togo, chto u nih bylo lish' dva avtora: Dzherri Blau i Andris Padega. Avtorami idej yavlyayutsya poryadka desyati chelovek, no esli trebuetsya soblyusti soglasovannost' opisaniya i produkta, otlivku reshenij v prozaicheskie specifikacii dolzhny osushchestvlyat' ne bolee dvuh chelovek. Dlya napisaniya opredeleniya trebuetsya prinyat' massu mini-reshenij, kotorye ne stol' vazhny, chtoby vynosit' ih na vseobshchee obsuzhdenie. Dlya System/360 primerom sluzhat podrobnosti togo, kak posle kazhdoj operacii ustanavlivaetsya kod usloviya. Odnako zadacha vseobshchej soglasovannosti takih mini- reshenij ne yavlyaetsya trivial'noj. Dumayu, chto luchshij vidennyj mnoj obrazec rukovodstva - eto napisannoe Blau prilozhenie k "Principam raboty System/360". V nem tshchatel'no i tochno opisany granicy sovmestimosti System/360. Dano opredelenie sovmestimosti, predpisyvaetsya, k chemu nuzhno stremit'sya, i perechisleny te oblasti vneshnih proyavlenij, gde arhitektura namerenno molchit, i gde rezul'taty, poluchennye na raznyh modelyah, mogut otlichat'sya mezhdu soboj, gde raznye ekzemplyary odnoj modeli mogut dat' razlichnye rezul'taty i dazhe odin i tot zhe ekzemplyar mozhet davat' razlichiya posle konstruktivnyh izmenenij. |to uroven' tochnosti, k kotoromu stremyatsya sostaviteli rukovodstv. Oni dolzhny odinakovo opisyvat' kak to, chto mozhno delat', tak i to, chto delat' nel'zya. Formal'nye opredeleniya Anglijskij yazyk, kak i lyuboj drugoj estestvennyj yazyk, po svoej prirode ne yavlyaetsya tochnym instrumentom, prigodnym dlya takih opisanij. Poetomu sostavitel' rukovodstva dolzhen derzhat' v uzde sebya i svoj yazyk, chtoby dostich' neobhodimoj strogosti. Privlekatel'na vozmozhnost' ispol'zovaniya dlya takih opredelenij formal'nyh oboznachenij. V konce koncov, cel'yu yavlyaetsya tochnost', chto obuslovlivaet pravo formal'nyh oboznachenij na zhizn'. Rassmotrim dostoinstva i slabosti formal'nyh opredelenij. Kak otmechalos', formal'nye opredeleniya yavlyayutsya tochnymi. Oni tyagoteyut k polnote: probely zametnee, a potomu skoree vosstanavlivayutsya. Ih nedostatok - trudnost' ponimaniya. Na anglijskom yazyke mozhno opisat' strukturnye principy, ochertit' struktury po etapam ili po urovnyam i privesti primery. Legko otmetit' isklyucheniya i podcherknut' protivopolozhnosti. Eshche vazhnee, chto mozhno ob座asnit' prichiny. Predlagavshiesya do sih por formal'nye opredeleniya vyzyvali voshishchenie svoej elegantnost'yu i uverennost' v ih tochnosti. No oni trebovali tekstual'nyh poyasnenij dlya oblegcheniya izucheniya svoego soderzhaniya. Po etoj prichine ya polagayu, chto v budushchem specifikacii budut sostoyat' kak iz formal'nyh, tak i iz tekstovyh opisanij. Drevnee izrechenie preduprezhdaet o tom, chto v more nel'zya vyhodit' s dvumya hronometrami: nuzhno vzyat' odin ili tri. To zhe, ochevidno, primenimo i k tekstovym i formal'nym opredeleniyam. Esli imeyutsya oba vida, to odin dolzhen byt' standartom, a drugoj - proizvodnym opisaniem, o chem dolzhno byt' pryamo ukazano. Osnovnym standartom mozhet byt' lyuboj iz nih. V Algol 68 v kachestve standarta vybrano formal'noe opredelenie, a tekstovye opredeleniya yavlyayutsya opisatel'nymi. V PL/I standartom yavlyaetsya tekst, a formal'noe opredelenie - proizvodnym. V System/360 takzhe v kachestve standarta prinyat tekst, a proizvodnymi yavlyayutsya formal'nye opisaniya. Est' mnogo sredstv sozdaniya formal'nyh opredelenij. Dlya opredeleniya yazykov chasto ispol'zuetsya forma Bekusa-Naura, po kotoroj est' bogataya literatura.2 V formal'nom opisanii PL/I ispol'zuyutsya novye oboznacheniya abstraktnogo sintaksisa, nadlezhashchim obrazom opisannye.3 APL Iversona byl ispol'zovan dlya opisaniya mashin, v chastnosti, IBM 70904 i System/360.7 Bell i N'yuell predlozhili novye notacii dlya opisaniya kak konfiguracij, tak i mashin, i proillyustrirovali ih na neskol'kih mashinah, vklyuchaya DEC PDP-8,6 70906 i System/360.7 Pochti vse formal'nye opredeleniya okazalis' prigodnymi dlya voploshcheniya ili opisaniya apparatnyh sredstv ili programmnyh sistem, vneshnie specifikacii kotoryh oni reglamentiruyut. Sintaksis mozhno opisat' bez etogo, no semantika obychno opredelyaetsya s pomoshch'yu programmy, vypolnyayushchej opredelyaemuyu operaciyu. Konechno, eto yavlyaetsya realizaciej i v etom kachestve pereopredelyaet arhitekturu. Poetomu nuzhno ukazat', chto formal'noe opredelenie otnositsya tol'ko k vneshnim specifikaciyam, i ob座asnit', chto imi yavlyaetsya. Ne tol'ko formal'noe opredelenie yavlyaetsya realizaciej, no i realizaciya mozhet sluzhit' formal'nym opredeleniem. Kogda byli sozdany pervye sovmestimye komp'yutery, ispol'zovalas' imenno eta tehnologiya. Novaya mashina dolzhna byla sootvetstvovat' imeyushchejsya. Rukovodstvo tumanno v nekotoryh mestah? Zadajte vopros mashine! Sozdavalas' testovaya programma dlya vyyasneniya povedeniya, i novaya mashina stroilas' tak, chtoby dostigalos' sootvetstvie. Programmnaya model' apparatnoj ili programmnoj sistemy mozhet ispol'zovat'sya tochno takim zhe obrazom. |to - realizaciya. Ona rabotaet. Poetomu vse voprosy, svyazannye s opredeleniem, mogut byt' resheny putem proverki. Ispol'zovanie realizacii v kachestve opredeleniya imeet nekotorye preimushchestva. Vse problemy mozhno odnoznachno reshit' putem eksperimenta. Diskussij ne trebuetsya, poetomu otvet poluchaetsya bystro. Otvet mozhet byt' skol' ugodno tochnym i, po opredeleniyu, vsegda yavlyaetsya pravil'nym. S drugoj storony, est' znachitel'noe kolichestvo nedostatkov. Realizaciya mozhet pereopredelyat' dazhe vneshnie specifikacii. Dazhe pri oshibochnom sintaksise vsegda poluchaetsya nekotoryj rezul'tat; v kontroliruemoj sisteme etot rezul'tat yavlyaetsya ukazaniem na oshibku i nichem bol'she. V nekontroliruemoj sisteme mogut vozniknut' lyubye pobochnye effekty i byt' ispol'zovany programmistami. Kogda my, naprimer, emulirovali IBM 1401 na System/360, vyyavilos' 30 razlichnyh "kur'ezov" - pobochnyh effektov predpolozhitel'no nezakonnyh operacij, kotorye shiroko ispol'zovalis' i dolzhny byli byt' priznany chast'yu opredeleniya. Realizaciya v kachestve opredeleniya vozobladala. Ona ne tol'ko govorila o tom, chto dolzhna delat' mashina, no i mnogoe skazala o tom, kak mashina ne dolzhna byla eto delat'. Krome togo, na pronicatel'nye voprosy realizaciya inogda daet neozhidannye otvety, i opredelenie de-fakto chasto okazyvaetsya neizyashchnym v etih osobyh sluchayah potomu, chto nad nimi nikogda ne zadumyvalis'. Kopirovanie etoj neelegantnosti v drugoj realizacii chasto okazyvaetsya zamedlyayushchim ili dorogostoyashchim. Naprimer, v nekotoryh mashinah v registre mnozhimogo posle umnozheniya ostaetsya musor. Tochnaya priroda etogo musora stanovitsya chast'yu opredeleniya de-fakto, odnako ego kopirovanie mozhet pomeshat' ispol'zovaniyu bolee bystrogo algoritma umnozheniya. Nakonec, ispol'zovanie realizacii v kachestve formal'nogo opredeleniya mozhet sozdat' neyasnost', kakoe iz opisanij - tekstovoe ili formal'noe - v dejstvitel'nosti yavlyaetsya standartom. |to otnositsya osobenno k programmnym modelyam. Sleduet takzhe vozderzhivat'sya ot vneseniya izmenenij v realizaciyu, poka ona sluzhit v kachestve standarta. Pryamoe vklyuchenie U arhitektorov programmnyh sistem est' chudesnyj metod rasprostraneniya i vnedreniya opredelenij. On osobenno polezen pri ustanovlenii esli ne semantiki, to sintaksisa mezhmodul'nyh interfejsov. |tot priem sostoit v sozdanii ob座avlenij peredavaemyh parametrov ili sovmestno ispol'zuemoj pamyati i trebovanii vklyucheniya etih ob座avlenij pri operaciyah vremeni kompilyacii (makros ili %INCLUDE v PL/I). Esli, krome togo, vse ssylki na interfejs proishodyat tol'ko po simvolicheskim imenam, ob座avleniya mozhno menyat', dobavlyaya ili vstavlyaya novye imena i lish' zanovo kompiliruya, no ne izmenyaya ispol'zuyushchuyu ego programmu. Konferencii i sudy Net nuzhdy govorit' o tom, chto soveshchaniya neobhodimy. Sotni chastnyh konsul'tacij dolzhny dopolnyat'sya krupnymi i bolee formal'nymi sobraniyami. My priznali poleznymi dva urovnya takih sobranij. Pervyj - eto ezhenedel'naya konferenciya vseh arhitektorov vmeste s oficial'nymi predstavitelyami razrabotchikov apparatnoj i programmnoj chasti i sotrudnikami marketinga prodolzhitel'nost'yu v polovinu rabochego dnya pod predsedatel'stvom glavnogo arhitektora sistemy. Predlagat' zadachi i izmeneniya mozhno vsem, no obychno predlozheniya rasprostranyayutsya v pis'mennom vide do soveshchaniya. Obychno novaya zadacha nekotoroe vremya obsuzhdaetsya. Upor delaetsya na tvorcheskoj storone, a ne prosto na prinyatii resheniya. Gruppa pytaetsya predlozhit' neskol'ko reshenij problemy, zatem ryad predlozhennyh reshenij peredaetsya odnomu ili neskol'kim arhitektoram dlya razrabotki podrobnyh i tochno sformulirovannyh predlozhenij po vneseniyu izmenenij v rukovodstvo. Podrobnye predlozheniya ob izmeneniyah zatem vynosyatsya dlya prinyatiya resheniya. Predlozheniya tshchatel'no izuchayutsya ispolnitelyami i pol'zovatelyami, i vyyasnyayutsya vse "za" i "protiv". Esli voznikaet vseobshchee soglasie, vse v poryadke. V protivnom sluchae reshenie prinimaet glavnyj arhitektor. Vedetsya protokol, i resheniya formal'no, operativno i shiroko rasprostranyayutsya. Resheniya ezhenedel'nyh konferencij dayut bystrye rezul'taty i pozvolyayut prodolzhit' rabotu. Esli kto-to ochen' nedovolen, dopuskaetsya nemedlennaya apellyaciya k menedzheru proekta, no eto proishodit ochen' redko. Plodotvornost' etih soveshchanij obuslovlena neskol'kimi prichinami: 1. Odna i ta zhe gruppa - arhitektory, razrabotchiki i ispolniteli - na protyazhenii mesyacev vstrechayutsya mezhdu soboj kazhduyu nedelyu. Ne trebuetsya vremeni, chtoby vvesti lyudej v kurs dela. 2. Gruppa sostoit iz predpriimchivyh, sposobnyh, horosho osvedomlennyh v voprosah i gluboko zainteresovannyh v konechnom rezul'tate lyudej. Nikto ne uchastvuet s "soveshchatel'nym" golosom. Vse upolnomocheny prinimat' na sebya obyazatel'stva. 3. Pri vozniknovenii problem resheniya ishchutsya kak vnutri, tak i vne ochevidnyh granic. 4. Blagodarya formalizmu pis'mennyh predlozhenij sosredotochivaetsya vnimanie, trebuetsya prinyatie resheniya i ustranyaetsya nesoglasovannost', svojstvennaya chernovym resheniyam komissij. 5. Otkrytoe predostavlenie prava prinyatiya resheniya glavnomu arhitektoru pomogaet izbezhat' poiska kompromissov i zaderzhek. So vremenem vyyasnyaetsya, chto nekotorye resheniya ne v polnoj mere vypolnyayutsya. Tot ili inoj iz uchastnikov tak i ne prinyal vsej dushoj kakuyu-libo meloch'. Drugie resheniya porodili nepredvidennye problemy, i ezhenedel'noe soveshchanie otkazyvaetsya povtorno ih rassmatrivat'. Tak voznikaet hvost iz melkih vozrazhenij, otkrytyh tem ili razdrazheniya. Dlya ih uregulirovaniya my provodim ezhegodnye "sessii verhovnogo suda", obychno prodolzhayushchiesya dve nedeli. (Esli by ya provodil ih sejchas, to delal by eto raz v polgoda.) |ti sessii provodilis' nakanune vazhnyh dat okonchatel'nogo prinyatiya razdelov rukovodstva. Prisutstvovali ne tol'ko predstaviteli programmistov i proektirovshchikov po arhitekture, no i menedzhery programmnyh, marketingovyh i realizacionnyh proektov. Predsedatel'stvoval menedzher proekta System/360. Povestka raboty vklyuchala obychno okolo 200 punktov, v osnovnom melkih, perechislennyh v razveshannyh po komnate spiskah. Zaslushivalis' vse storony i prinimalis' resheniya. Blagodarya chudu komp'yuternoj verstki (i prevoshodnoj rabote sotrudnikov) kazhdoe utro kazhdyj uchastnik obnaruzhival na svoem rabochem meste ispravlennoe rukovodstvo, v kotoroe byli vneseny resheniya, prinyatye nakanune. |ti "osennie festivali" byli polezny ne tol'ko dlya peresmotra reshenij, no i dlya togo, chtoby oni byli prinyaty. Kazhdyj byl uslyshan, kazhdyj prinimal uchastie, kazhdyj luchshe ponimal slozhnye ogranicheniya i vzaimosvyazi mezhdu resheniyami. Mnozhestvennye realizacii U arhitektorov System/360 bylo dva pochti besprecedentnyh preimushchestva: dostatochno vremeni dlya tshchatel'noj raboty i takoe zhe politicheskoe vliyanie, kak u proektirovshchikov. Nalichie vremeni bylo obespecheno grafikom po novoj tehnologii; politicheskoe ravenstvo proishodilo blagodarya odnovremennomu sozdaniyu neskol'kih realizacij. Neobhodimost' ih strogoj sovmestimosti luchshe vsego sposobstvovala ispolneniyu specifikacij. V bol'shinstve komp'yuternyh proektov nastupaet den', kogda okazyvaetsya, chto mashina i rukovodstvo po ee ispol'zovaniyu ne soglasuyutsya. V posleduyushchem konflikte obychno proigryvaet rukovodstvo, poskol'ku ego mozhno izmenit' znachitel'no bystree i men'shej cenoj, chem mashinu. Odnako eto ne tak, esli sushchestvuet neskol'ko realizacij. Togda vremennye i finansovye izderzhki, svyazannye s ispravleniem mashiny s oshibkami, mogut byt' nizhe, chem svyazannye s peredelkoj mashin, verno sledovavshih rukovodstvu. |to zamechanie mozhno s pol'zoj primenit' pri opredelenii yazyka programmirovaniya. Mozhno s uverennost'yu utverzhdat', chto rano ili pozdno potrebuetsya sozdat' neskol'ko interpretatorov ili kompilyatorov dlya raznyh celej. Opredelenie budet yasnee, a disciplina bolee krepkoj, esli iznachal'no stroyatsya kak minimum dve realizacii. ZHurnal registracii telefonnyh razgovorov Kakimi by tochnymi ne byli specifikacii, po hodu proektirovaniya voznikaet neschetnoe mnozhestvo voprosov kasatel'no interpretacii arhitektury. Ochevidno, mnogie iz etih voprosov trebuyut bolee yasnogo izlozheniya v tekste. Prochie prosto otrazhayut nepravil'noe ponimanie. Vazhno, chtoby ozadachennye ispolniteli zvonili otvetstvennym arhitektoram i zadavali voprosy, a ne prodolzhali rabotu na osnovanii dogadok. Vazhno takzhe ponimat', chto otvety na takie voprosy yavlyayutsya avtoritetnymi zayavleniyami arhitektorov i dolzhny dovodit'sya do vseh. Poleznym mehanizmom yavlyaetsya vedenie arhitektorom zhurnala registracii telefonnyh razgovorov, v kotoryj im zanosyatsya vse voprosy i otvety. Kazhduyu nedelyu zhurnaly neskol'kih arhitektorov ob容dinyayutsya voedino, razmnozhayutsya i raspredelyayutsya sredi pol'zovatelej i ispolnitelej. Nesmotrya na svoyu neformal'nost', takoj mehanizm yavlyaetsya i bystrym, i ponyatnym. Testirovanie produkta Luchshij drug menedzhera proekta - ego postoyannyj protivnik, nezavisimaya organizaciya, testiruyushchaya produkt. Gruppa proveryaet sootvetstvie mashin i produktov specifikaciyam i vystupaet posobnikom d'yavola, ukazyvaya na vse zamechennye defekty i nesootvetstviya. Kazhdoj organizacii, vedushchej razrabotki, nuzhna takaya nezavisimaya gruppa tehnicheskogo audita, kotoraya dolzhna byt' nepodkupna. Poslednij analiz v kachestve nezavisimogo auditora osushchestvlyaet pokupatel'. V bezzhalostnom svete prakticheskogo primeneniya stanet viden kazhdyj ogreh. Gruppa testirovaniya produkta kak raz zamenyaet pokupatelya, nastroennogo na poisk oshibok. Vremya ot vremeni tshchatel'naya proverka produkta obnaruzhivaet mesta, gde ne uslyshali ukazanie, gde proektnye resheniya ponyali nepravil'no ili vypolnili netochno. Poetomu takaya gruppa proveryayushchih yavlyaetsya neobhodimym zvenom v cepochke, po kotoroj dohodit slovo proektirovshchika, zvenom, kotoroe dolzhno nachat' dejstvovat' rano i odnovremenno s proektirovaniem. Glava 7. Pochemu ne udalos' postroit' Vavilonskuyu bashnyu? Na vsej zemle byl odin yazyk i odno narechie. Dvinuvshis' s vostoka, oni nashli v zemle Sennaar ravninu i poselilis' tam. I skazali drug drugu: nadelaem kirpichej i obozhzhem ognem. I stali u nih kirpichi vmesto kamnej, a zemlyanaya smola vmesto izvesti. I skazali oni: postroim sebe gorod i bashnyu, vysotoyu do nebes, i sdelaem sebe imya prezhde, nezheli rasseemsya po licu vsej zemli. I soshel Gospod' posmotret' gorod i bashnyu, kotorye stroili syny chelovecheskie. I skazal Gospod': vot, odin narod, i odin u vseh yazyk; i vot chto oni nachali delat', i ne otstanut oni ot togo, chto zadumali delat'; sojdem zhe i smeshaem tam yazyk ih, tak chtoby odin ne ponimal rechi drugogo. I rasseyal ih Gospod' ottuda po vsej zemle; i oni perestali stroit' gorod [i bashnyu]. KNIGA BYTIYA 11:1-8 Audit menedzhmenta Vavilonskogo proekta Soglasno Knige bytiya, Vavilonskaya bashnya byla vtorym krupnym inzhenernym predpriyatiem cheloveka posle Noeva kovchega. Vavilonskaya bashnya stala pervym inzhenernym fiasko. |ta istoriya gluboka i pouchitel'na v neskol'kih otnosheniyah. Davajte, odnako, rassmotrim ee kak chisto tehnicheskij proekt i posmotrim, kakie uroki administrirovaniya mozhno iz nee izvlech'. Naskol'ko horosho proekt byl obespechen neobhodimymi sostavlyayushchimi uspeha? Imelis' li: 1. YAsnost' celi? Da, hotya i naivno nedostizhimoj. Proekt provalilsya zadolgo do togo, kak stolknulsya s eti principial'nym ogranicheniem. 2. CHelovecheskie resursy? V bol'shom chisle. 3. Materialy? Glina i bitum v izobilii imeyutsya v Mesopotamii. 4. Dostatochno vremeni? Da, net nikakih ukazanij na ogranicheniya po vremeni. 5. Adekvatnye tehnologii? Da, piramidal'noj ili konicheskoj strukture prisushcha ustojchivost' i horoshee raspredelenie nagruzki szhatiya. Ochevidno, svojstva kamennoj kladki byli horosho izvestny. Proekt provalilsya do togo, kak vyshel za predely tehnologicheskih ogranichenij. Tak pochemu zhe provalilsya proekt, esli vse eto u nih bylo? CHego u nih ne hvatalo? Dvuh veshchej - obmena informaciej i vytekayushchej iz nego organizacii. Oni ne mogli razgovarivat' drug s drugom i, kak sledstvie, soglasovyvat' usiliya. Kogda otkazala koordinaciya, rabota vstala. CHitaya mezhdu strok, my obnaruzhivaem, chto otsutstvie obmena informaciej privelo k sporam, durnomu nastroeniyu i vzaimnoj revnosti. Vskore klany nachali rashodit'sya, predpochtya obosoblennost' sporam. Obmen informaciej v bol'shom programmnom proekte V nashe vremya proishodit tozhe samoe. Otstavanie ot grafika, nesootvetstvie funkcional'nosti, sistemnye oshibki - vse eto iz-za togo, chto levaya ruka ne znaet, chto tvorit pravaya. Po hodu raboty uchastvuyushchie v nej neskol'ko brigad ponemnogu izmenyayut funkcii, razmer, bystrodejstvie svoih programm, yavno ili kosvenno menyayut dopushcheniya otnositel'no vhodnyh dannyh i ispol'zovaniya vyhodnyh. Naprimer, ispolnitel' funkcii, osushchestvlyayushchej overlejnuyu zagruzku programm, mozhet stolknut'sya s problemami i snizit' bystrodejstvie, osnovyvayas' na statisticheskih dannyh, ukazyvayushchih na redkost' ispol'zovaniya etoj funkcii v prikladnyh programmah. V to zhe vremya ego sosed mozhet razrabatyvat' vazhnuyu chast' supervizora takim obrazom, chto ona krajne zavisit ot skorosti vypolneniya etoj funkcii. |to izmenenie skorosti vypolneniya, v sushchnosti, stanovitsya znachitel'nym izmeneniem specifikacij, o nem nuzhno shiroko ob座avit' i ocenit' s tochki zreniya sistemy. Kak zhe dolzhny brigady obmenivat'sya mezhdu soboj informaciej? Vsemi vozmozhnymi sposobami: - Neformal'no. Horoshaya telefonnaya svyaz' i yasnoe opredelenie vzaimozavisimostej mezhdu brigadami dolzhny sposobstvovat' mnogochislennym telefonnym peregovoram, ot kotoryh zavisit edinaya interpretaciya pechatnyh dokumentov. - Soveshchaniya. Nel'zya pereocenit' znachenie regulyarnyh soveshchanij uchastnikov proekta s poocherednym zaslushivaniem tehnicheskih otchetov brigad. Takim putem ustranyayutsya sotni melkih neponimanij. - Rabochaya tetrad'. V samom nachale nuzhno zavesti rabochuyu tetrad' ucheta prodelannoj raboty. |ta tema zasluzhivaet otdel'nogo razdela. Rabochaya tetrad' proekta CHto. Rabochaya tetrad' proekta yavlyaetsya ne stol'ko otdel'nym dokumentom, skol'ko strukturoj, nalagaemoj na vse dokumenty, kotorye budut sozdany vo vremya vypolneniya proekta. Vse dokumenty proekta dolzhny vhodit' v etu strukturu, vklyuchaya celi, vneshnie specifikacii, specifikacii interfejsov, tehnicheskie standarty, vnutrennie specifikacii i administrativnye zapiski. Pochemu. Tehnologicheskij dokument prakticheski vechen. Esli issledovat' genealogiyu rukovodstva pol'zovatelya po kakomu-nibud' apparatnomu ili programmnomu produktu, mozhno prosledit' ne tol'ko idei, no i mnozhestvo otdel'nyh predlozhenij i paragrafov, vplot' do pervoj pamyatnoj zapiski, predlagayushchej produkt ili poyasnyayushchej pervyj proekt. Dlya sostavitelya dokumentacii nozhnicy i klej - takaya zhe vazhnaya veshch', kak pero. Raz eto tak, i zavtrashnie rukovodstva dlya gotovogo produkta razvivayutsya iz segodnyashnih pamyatnyh zapisok, ochen' vazhno pravil'no opredelit' strukturu dokumentacii. Razrabotka rabochej tetradi proekta na rannih etapah obespechivaet produmannuyu, a ne sluchajnuyu strukturu dokumentacii. Bolee togo, zadanie struktury pozvolyaet sostavlennye pozdnee dokumenty oformit' v vide otryvkov, kotorye vpisyvayutsya v etu strukturu. Vtoroj prichinoj dlya vedeniya rabochej tetradi yavlyaetsya neobhodimost' upravleniya processom rasprostraneniya informacii. Zadacha sostoit ne v ogranichenii dostupa k informacii, a v tom, chtoby sootvetstvuyushchaya informaciya dostigla vseh, komu ona mozhet ponadobit'sya. Pervym delom sleduet pronumerovat' vse pamyatnye zapiski, tak chtoby imelis' uporyadochennye spiski nazvanij, i kazhdyj rabotnik mog ubedit'sya v nalichii neobhodimyh emu materialov. Organizaciya rabochej tetradi idet znachitel'no dal'she, ustanavlivaya drevovidnuyu strukturu pamyatnyh zapisok. Drevovidnaya struktura pozvolyaet, esli nuzhno, organizovat' dostavku informacii sootvetstvenno podderev'yam. Mehanika. Kak i vo mnogih zadachah upravleniya programmnymi proektami, problema tehnicheskih memorandumov uslozhnyaetsya nelinejnym obrazom po mere uvelicheniya ob容ma dannyh. Esli v rabote uchastvuyut 10 chelovek, dokumenty mozhno prosto pronumerovat'. Esli uchastvuyut 100 chelovek, chasto dostatochno neskol'kih linejnyh posledovatel'nostej. Dlya 1000 sotrudnikov, neizbezhno razbrosannyh po neskol'kim ploshchadkam, vozrastaet potrebnost' v strukturirovannoj rabochej tetradi, i, sledovatel'no, vozrastaet ee ob容m. Kak postupat' v etom sluchae? YA dumayu, my pravil'no postupili pri rabote nad proektom OS/360. Na neobhodimosti horosho strukturirovannoj rabochej tetradi osobenno nastaival O. S. Loken, kotoryj ubedilsya v ee effektivnosti pri rabote nad svoim predydushchim proektom, - operacionnoj sistemoj 1410-7010. My bystro prinyali reshenie, chto kazhdyj programmist dolzhen imet' vozmozhnost' videt' ves' material, t.e. dolzhen imet' ekzemplyar rabochej tetradi v svoem ofise. Reshayushchee znachenie imeet svoevremennoe obnovlenie. Rabochaya tetrad' dolzhna otrazhat' tekushchee sostoyanie proekta. |to ochen' trudno osushchestvit', kogda dlya vneseniya obnovlenij nuzhno perepechatyvat' celye dokumenty. Odnako v tetradi s vynimayushchimisya listami dostatochno zamenit' otdel'nye stranicy. U nas imelas' komp'yuternaya sistema redaktirovaniya teksta, okazavshayasya bescennoj dlya svoevremennogo obnovleniya. Ofsetnye formy izgotavlivalis' neposredstvenno na printere, i cikl obrabotki sostavlyal men'she odnogo dnya. Pered poluchatelem vseh etih obnovlennyh stranic vstaet, odnako, problema usvoeniya. Kogda on vpervye poluchaet obnovlennuyu stranicu, to emu nuzhno znat', chto bylo izmeneno. Kogda on pozzhe obrashchaetsya k nej, to emu nuzhno znat', kakoe opredelenie dejstvitel'no na tekushchij den'. Poslednyuyu potrebnost' udovletvoryaet nepreryvnost' obnovleniya dokumentacii. CHtoby vydelit' izmeneniya, trebuyutsya drugie mery. Vo-pervyh, nuzhno otmetit' na stranice izmenennyj tekst, naprimer, s pomoshch'yu vertikal'noj linii na polyah ryadom s kazhdoj izmenennoj strochkoj. Vo-vtoryh, neobhodimo vmeste s izmenennymi stranicami rasprostranyat' kratkuyu otdel'nuyu svodku s perechisleniem izmenenij i harakteristikoj ih znacheniya. Nash proekt ne pereshel i shestimesyachnogo rubezha, kogda my stolknulis' s drugoj problemoj. Tolshchina rabochej tetradi sostavila okolo polutora metrov! Esli by my slozhili v odnu stopku trebuyushchiesya programmistam 100 ekzemplyarov v svoih pomeshcheniyah zdaniya Time-Life v Manhettene, ona by prevysila po vysote samo zdanie. Krome togo, ezhednevnye ispravleniya imeli tolshchinu bol'she pyati santimetrov i naschityvali okolo 150 stranic, kotorye nado bylo zamenit'. Podderzhka rabochej tetradi stala zanimat' znachitel'nuyu chast' ezhednevnogo rabochego vremeni. S etogo vremeni my pereshli na mikrofishi, chto sbereglo million dollarov dazhe s uchetom stoimosti ustrojstv dlya chteniya mikrofishej v kazhdom ofise. My smogli dostich' otlichnoj prodolzhitel'nosti cikla proizvodstva mikrofishej. Rabochaya tetrad' umen'shilas' v ob容me s 90 dm3 do 5 dm3 i, chto bolee vazhno, obnovleniya vypuskalis' porciyami po sotne stranic, stokratno umen'shaya slozhnost' zameny listov. Mikrofishi imeyut svoi nedostatki. S tochki zreniya menedzhera, neudobstvo zameny bumazhnyh stranic garantirovalo, chto ih prochtut, dlya chego i velas' rabochaya tetrad'. Mikrofishi slishkom oblegchili zadachu vedeniya rabochej tetradi, esli tol'ko oni ne soprovozhdalis' pechatnym dokumentom s perechisleniem izmenenij. Krome togo, mikrofishi ne pozvolyayut chitatelyu legko delat' vydeleniya, pometki i kommentarii. Dokumenty, s kotorymi chitatel' rabotal, prinosyat bol'she pol'zy avtoru i chitatelyu. Vzveshivaya vse, ya polagayu, chto mikrofishi yavlyayutsya ochen' udachnoj tehnologiej, i dlya ochen' krupnyh proektov ya by otdal im predpochtenie pered bumazhnoj rabochej tetrad'yu. Kak mozhno osushchestvit' eto segodnya? Segodnyashnie sistemnye tehnologii, ya dumayu, delayut predpochtitel'nee vedenie rabochej tetradi v fajle pryamogo dostupa s poloskami, pomechayushchimi izmenennye chasti, i datami vneseniya izmenenij. Lyuboj pol'zovatel' mozhet obratit'sya k zhurnalu s displejnogo terminala. Svodka izmenenij, gotovyashchayasya ezhednevno, dolzhna hranit'sya v vide steka (LIFO) s ustanovlennoj tochkoj dostupa. Programmist mozhet ezhednevno ee chitat', no esli on propustil odin den', emu pridetsya dol'she chitat' na sleduyushchij den'. Prochtya ob izmeneniyah, on mozhet prervat'sya i prochest' sam izmenennyj tekst. Obratite vnimanie, chto sama rabochaya tetrad' ostaetsya neizmennoj. Ona po- prezhnemu ostaetsya sobraniem vsej proektnoj dokumentacii, tshchatel'no organizovannoj. Edinstvennoe izmenenie - mehanizm raspredeleniya dostupa. D. S. |nglebart s kollegami sozdali takuyu sistemu v Stenfordskom issledovatel'skom institute i ispol'zuyut ee dlya vedeniya dokumentacii po seti ARPA. D. L. Pranas i Universiteta Karnegi-Melona predlozhil eshche bolee radikal'noe reshenie.1 On polagaet, chto proizvoditel'nost' programmista vyshe vsego, kogda on ograzhden ot podrobnostej konstrukcii teh chastej sistemy, nad kotorymi on ne rabotaet. |to predpolagaet, chto vse interfejsy polnost'yu i tochno zadany. Takoj proekt opredelenno horosh, no esli polagat'sya na ego ideal'noe osushchestvlenie, eto privedet k katastrofe. Horoshaya informacionnaya sistema ne tol'ko dolzhna vyyavlyat' oshibki v interfejsah, no i sposobstvovat' ih ispravleniyu. Organizaciya krupnogo programmnogo proekta Esli nad proektom rabotaet n chelovek, to sushchestvuet (n2-n)/2 interfejsov, cherez kotorye mozhet proishodit' obmen dannymi, i potencial'no sushchestvuet pochti 2n grupp, vnutri kotoryh dolzhno proishodit' soglasovanie. Cel' organizacii raboty sostoit v sokrashchenii neobhodimogo ob容ma obmena informaciej i soglasovaniya. Poetomu sozdanie pravil'noj organizacionnoj struktury yavlyaetsya reshayushchim napravleniem resheniya problem informacionnogo obmena, rassmatrivavshihsya vyshe. Sposoby, kotorymi sokrashchaetsya obmen informaciej, - razdelenie truda i specializaciya funkcij. Drevovidnaya organizacionnaya struktura otrazhaet umen'shenie potrebnosti v podrobnom obmene informaciej pri ispol'zovanii razdeleniya truda i specializacii. V dejstvitel'nosti, organizaciya v vide dereva voznikaet kak strukturizaciya polnomochij i otvetstvennosti. Princip, chto nikto ne mozhet byt' slugoj dvuh gospod, trebuet, chtoby struktura polnomochij byla drevovidnoj. Odnako struktura obmena informaciej ne stol' ogranichena, i derevo yavlyaetsya malo prigodnym priblizheniem struktury obshcheniya, kotoraya yavlyaetsya set'yu. Neadekvatnost' priblizheniya derevom sluzhit prichinoj vozniknoveniya brigad, celevyh grupp, komissij i dazhe organizacij matrichnogo tipa, sushchestvuyushchih vo mnogih inzhenernyh laboratoriyah. Rassmotrim drevovidnuyu organizaciyu programmistov i issleduem sushchestvennye harakteristiki, kotorymi dolzhny obladat' podderev'ya, chtoby byt' effektivnymi. Takovymi yavlyayutsya: 1 - zadanie, 2 - prodyuser, 3 - tehnicheskij direktor ili arhitektor, 4 - grafik rabot, 5 - razdelenie truda, 6 - opredelenie interfejsov mezhdu raznymi chastyami. Vse perechislennoe ochevidno i obychno, isklyuchaya razlichie mezhdu prodyuserom i tehnicheskim direktorom. Snachala rassmotrim sami eti dve funkcii, a zatem ih vzaimootnosheniya. V chem naznachenie prodyusera? On sobiraet brigadu, raspredelyaet rabotu i ustanavlivaet grafik ee vypolneniya. On zanimaetsya priobreteniem neobhodimyh resursov. |to oznachaet, chto bol'shaya chast' ego funkcij sostoit v obshchenii, kotoroe napravleno vne brigady, - vverh i v storony. On ustanavlivaet shemu svyazi i predostavleniya otchetnosti vnutri brigady. Nakonec, on obespechivaet vypolnenie grafika, osushchestvlyaya manevr resursami i menyaya organizaciyu v sootvetstvii s novymi obstoyatel'stvami. A chto zhe tehnicheskij direktor? On postigaet proekt, kotoryj dolzhen byt' realizovan, vyyavlyaet ego sostavlyayushchie, opredelyaet, kak on budet vyglyadet' vneshne, i delaet eskiz vnutrennej struktury. On obespechivaet edinstvo i konceptual'nuyu celostnost' proekta v celom i takim obrazom sposobstvuet ogranicheniyu slozhnosti sistemy. Pri vozniknovenii tehnicheskih problem on izyskivaet ih resheniya ili pri neobhodimosti izmenyaet sistemnyj proekt. On, soglasno prelestnomu vyrazheniyu Ala Kappa, yavlyaetsya "svoim chelovekom v parshivyh delah". Obshchenie ego proishodit preimushchestvenno vnutri komandy. Ego rabota pochti isklyuchitel'no tehnicheskaya. Teper' vidno, chto dlya etih dvuh funkcij trebuyutsya sovershenno raznye sposobnosti. Sposobnosti vstrechayutsya v raznyh sochetaniyah, i otnosheniya mezhdu prodyuserom i direktorom dolzhny opredelyat'sya temi konkretnymi sochetaniyami, kotorymi oni obladayut. Ne lyudi dolzhny byt' vtisnuty v chisto teoreticheskie organizacionnye formy, a organizaciya dolzhna stroit'sya vokrug teh lyudej, kotorye est'. Vozmozhny tri tipa otnoshenij, i vse oni s uspehom vstrechayutsya na praktike. Odno i to zhe lico mozhet byt' prodyuserom i tehnicheskim direktorom. |to vpolne opravdano v malen'kih komandah, naschityvayushchih ot treh do shesti programmistov. V bolee krupnyh proektah eto ochen' redko osushchestvimo po dvum prichinam. Vo-pervyh, redko vstrechayutsya lyudi, sochetayushchie v sebe bol'shie administrativnye i tehnicheskie sposobnosti. Mysliteli vstrechayutsya redko, praktiki eshche rezhe, no rezhe vsego - mysliteli-praktiki. Vo-vtoryh, v bol'shih proektah vypolnenie kazhdoj iz funkcij trebuet polnogo rabochego dnya ili dazhe bol'she. Prodyuseru trudno peredat' komu-libo dostatochnuyu chast' svoih obyazannostej, chtoby vysvobodit' vremya dlya tehnicheskoj raboty. Direktoru nevozmozhno peredat' svoi obyazannosti, ne nanosya ushcherba konceptual'noj celostnosti proekta. Prodyuser mozhet byt' nachal'nikom, a direktor - ego pravoj rukoj. Slozhnost' zdes' sostoit v tom, chtoby opredelit' polnomochiya direktora pri prinyatii tehnicheskih reshenij, s tem chtoby on ne tratil svoe vrem