Коли мова йде про людей, говорити про режими збою потрібно обережно. У англійців є стародавнє прислів'я: "Якщо ти даси собаці погане ім'я, то краще її відразу пристрелити". Справді, як ви побачите з наведених нижче прикладів, прості зміни в стилі управління та місцевої культури можуть привести до величезних змін видимого поведінки людей. І все ж, весь мій досвід говорить про те, що очікувати від людей послідовності і сталості дій практично неможливо. Як пише Джим Хайсмит (Jim Highsmith) [Hi]:
"... в цій коробочці НЕ гвинтики і шестерінки, а люди. Люди можуть робити постійно, раз по раз, схожі речі, але вони ніколи не зможуть зробити одне і те ж. У покрокової методології ми очікуємо, що, задаючи однакові дані на вході, ми будемо отримувати однакові результати на виході. Однак реакція людини на вступну інформацію може залежати від різних умов, причому більша частина цих умов може не мати ніякого відношення до виконуваної цією людиною завданню ".
Людям подобається відсутність точних приписів щодо їх власної поведінки. Одна з двох найважчих для людини завдань, які я можу собі уявити - це змусити людину робити щось дуже акуратно і одноманітно день за днем (інший найважчим завданням буде попросити його змінити свої звички). Нижче я наводжу витяг з недавно почутого діалогу, яка як не можна краще ілюструє цю думку.
"Як же мені впоратися з усіма цими паперами, які приходять в мій офіс?" - питає один. Інший відповідає: "Ну, це зовсім не складно! Просто стеж, щоб твій стіл завжди був порожнім - чотири кошики по кутах, кілька папок в верхньому ящику ...". Він не зміг закінчити. "Щоб стіл був порожнім ?!" - закричали всі. "Але ж це неможливо!"
Зверніть увагу, що порадник запропонував їм одночасно змінити свої звички, а також чинити певну дію постійно і одноманітно.
Якби люди мали послідовністю і сталістю, вони могли б прибирати паперу з робочого столу, запобігати карієс, позбавлятися від зайвої ваги, кидати курити, і може бути, навіть розробляти програмне забезпечення, вкладаючись в робочий графік.
Як саркастично зауважив Карл Вігерт (Karl Wiegert): "We are not short on practices. We are short on practice" ( "нам не вистачає практики, а не правил"). І таких правил, дійсно, чимало. Девід Гріз (David Gries) в своїй книзі "The Science of Programming" ( "Наука програмування") дає докладні інструкції по тому, як потрібно створювати правильні програми [Gr]. Хороший засіб проектування є CRC-картки [B87]. У методології під назвою "Extreme Programming" [EP], відомої своїм парним програмуванням і автоматичним тестуванням [Je], теж використовуються добре відомі ефективні методики. Докладно описані всі складові методології "Cleanroom" [Mi]. Уотс Хамфрі (Watts Humphrey) дає докладні інструкції програмістам, які хочуть працювати більш ефективно за допомогою "Personal Software Process" (PSP) [Hu]. Послідовне і постійне застосування будь-якої з цих методологій чудово поліпшило б будь-який проект з тих, які я бачив.
Проблема в одному - в словах "постійний" і "послідовний". Якщо PSP і Extreme Programming застосовувати лише час від часу, то вони втрачають свій сенс. Написаний наполовину код не може бути безпомилковим. Точно так же, як і у випадку з зайвими паперами на столі, методологію потрібно застосовувати повністю, послідовно, день у день.
Непослідовність - звичайна причина режиму збою у людини. Існують методології, які вимагають від своїх адептів суворій послідовності дій. Такі методології я називаю "високо дисциплінованими". Як показують опитування, проведені в різних проектах, саме такі методології найбільш уразливі, проте в деяких проектах вони використовуються досить успішно. Ось приклад застосування методології PSP в організації з п'ятим рівнем CMM. Мені він здається дуже повчальним: [Web]:
Щоб такого не сталося, в методологіях, що вимагають високої дисципліни, повинні існувати якісь регулюючі елементи, які змушували б людей бути більш послідовними. У методології "Cleanroom" є правило, яке забороняє компіляцію, яке підкріплено певним способом управління. Для Extreme Programming необхідний "наставник" ( "coach"), який стежить за дотриманням всіх приписів цієї методології. У PSP такі функції не були передбачені, тому не дивно, що група розробників з нашого прикладу перестала їй користуватися - у цій методології просто не було ніякої структури підтримки. Передбачається, що ці фактори будуть передбачені в TSP [Web].
Однак, незважаючи на все це, існують люди, які можуть протягом тривалого часу робити свою роботу послідовно і дисципліновано (це зайвий раз показує, наскільки всі ми відрізняємося один від одного). Іноді для того, щоб вплинути на дисциплінованість групи досить поміняти її керівника. Спасибі Трюгве Реенскаугу (Trygve Reenskaug) за історію, яка прекрасно показує, як стиль управління впливає на особисті якості:
Почуття громадянського обов'язку і здатність орієнтуватися в ситуації
Проблема людського непостійності відноситься до так званого "режиму збою", але у людини є ще і "режими успішної роботи". Ось три їх різновиди:
як правило, людина має почуття громадянського обов'язку,
людина вважає за краще брати ініціативу в свої руки,
Можливо, найбільш важливим (в довгостроковому плані) фактом було те, що в процесі роботи над проектом утворилася згуртована команда розробників, здатна здійснювати швидку розробку систем GN amp; C. Формування команди складалося з пошуку нових талановитих людей, їх навчання, накопичення досвіду роботи з інструментарієм, процесом і методологією, і подальшою інтеграцією в єдиний спаяний колектив.
Попрацювавши разом над проектом цілий рік, вся команда придбала хороші знання в предметній області, а також в методах і засобах розробки. Створення атмосфери дружби і взаємодопомоги серед розробників сприяло їх взаємному навчанню і всіляко заохочувала його. Готовність членів команди займатися будь-яким і всіма аспектами проекту багаторазово виявлялася безцінним підмогою в роботі ... (курсив мій, А.К.)
... така команда буде необхідна в подальшому і цього відділу, і всьому агентству ".
Що змусило людей вести себе таким чином? Одна з можливих причин - відчуття громадянського обов'язку.
Другий "режим успішної роботи" - це коли люди беруть ініціативу в свої руки. Цей принцип працює в повній відповідності з двома іншими - почуттям громадянського обов'язку і хорошої орієнтації в ситуації. Разом всі три призводять до того, що всі вважають звичайнісінькою причиною успіху в роботі: "в ключовий момент розробки кілька людей взяли на себе ініціативу".
"Добре орієнтуватися в поточній ситуації" - фраза досить невизначена, але має далекосяжні наслідки. Люди, які займаються сортуванням документів, часто просто розкладають всі папери на маленькі купки (використовуючи при цьому сортування методом Шелла). Найдивовижніше полягає в тому, що нерідко вони не розбирають ці купки далі, на окремі документи. Часто приблизного знання цілком достатньо, адже в разі необхідності вони завжди можуть перегорнути ту чи іншу купку і знайти необхідну (майбутні дослідження покажуть нам, які мнемонічні техніки для цього використовуються).
Ось приклад вже з області розробки програмного забезпечення. Ми намагаємося зробити документацію по проекту якісної, оновлюємо застарілі версії. Однак, знаючи, що мінливість - один з найбільш звичайних "режимів збою" у людини, можна сміливо передбачити, що документація все одно не буде оновлюватися досить часто. Що стосується мене, то я ще не бачив жодного успішно завершився проекту, у якого була б в порядку документація (за винятком тих випадків, коли код або документація створювалися автоматично). Зате бачив проект, який зазнав краху саме тому, що розробникам веліли оновлювати всю документацію після кожного внесеного зміни. Вартість розробки при цьому настільки зросла, а продуктивність так впала, що проект довелося незабаром закрити.
Тепер я вже знаю, що на здатність людей "добре орієнтуватися в ситуації" цілком можна покластися - і при розробці проекту, і при розробці методології.
Оскільки створювати і підтримувати документацію, яка відповідала б сучасному стану справ в системі, занадто дорого (особливо з огляду на нездатність людини до рутинних дій), я запропонував би підтримувати документацію на "досить хорошому" рівні. Іншими словами такий, щоб в ній завжди можна було приблизно зрозуміти, де шукати більш конкретну інформацію. А для решти достатньо буде навіть невеликих здібностей і старанності. Втім, "досить добре" стан документації - нездійсненне завдання для більшості проектів (проте, це якимось чином не грає великої ролі, оскільки людина швидше запитає того, хто знає, а не буде ритися в документації).
Поділіться на сторінці