У попередніх статтях (перша, друга) ми бігло і в жартівливій формі пройшлися за прикладами протидії, яку надають нам співробітники замовника на різних етапах проекту. Сьогодні предметом розгляду буде здача робіт, і ми підійдемо до цього етапу у всеозброєнні, щоб жоден троль не прорвався. Вийшло багато букв, але, сподіваюся воно того варте.
Здача результатів роботи є одним з найдраматичніших етапів проекту. Людино-місяці, витрачені на розробку, налагодження, тестування та впровадження вашого рішення, не повинні бути витрачені даремно. Якщо здача робіт доручена вам, то ваша роль в команді досить значна, а довіра керівництва велика, навіть якщо начальники вам цього ніколи не говорили. Облажатися на здачі робіт іноді означає кінець вашої блискучої кар'єри. Так що краще цього не робити.
Процес приймально-здавальних випробувань повинен бути строго формалізований. Всім зрозуміло, що наприкінці цього процесу повинен з'явитися протокол і акт, на підставі якого випускається наказ про переведення системи в дослідну або промислову експлуатацію. Акт також є формальним приводом для виставлення рахунку на оплату чергового етапу проекту.
У цій статті я без зайвих жартів (які вже тут жарти!) і максимально послідовно (ну, для блогу, звичайно) опишу процес здачі проектних робіт. Зрозуміло, багато речей досвідченим колегам здаються очевидними. Нехай. Зате менш досвідчені колеги або бажаючі приміряти відповідальну роль того, хто здає на себе, знайдуть цю публікацію корисною і пізнавальною.
Напрямки троллінгу в ході випробувань
Ви не уявляєте, скільки людей зацікавлено у вашому провалі! Хтось хоче довести свою правоту щодо ваших розумових здібностей, хтось хоче відтягнути терміни, хтось мріє про штрафні санкції, комусь потрібна нова гума на BMW... У подібних випадках в комісію підсадять троля-кілера (див. перший пост). На даному етапі є три напрямки троллінгу, з якими доводиться мати справу:
- Формальна приймка. Троль тикає в ТЗ, де написано щось на зразок цього: «система повинна мати архітектуру клієнт-сервер». Вам потрібно показати, як пункт закривається. А ви забули включити в пояснювальну записку до техпроекту рядок «Система має архітектуру клієнт-сервер» або з переляку не змогли її знайти. Витратьте час, прочитайте всі розділи ТЗ і знайдіть потрібні рядки.
- Помилки в тестах. При формулюванні тестів уникайте можливості навмисного невірного витлумачення. Наприклад, ви пишете, «Зі списку користувачів Оператор вибирає будь-якого користувача». Троль вибере зі списку системного юзера або адміна, під якими тести працювати не будуть. Або ви пишете «Відобразилися властивості всіх об'єктів». Троль ткне в той об'єкт, властивості якого не відобразилися. А ви мали на увазі «всіх необхідних об'єктів», але поїзд пішов, і ви отримуєте страшне зауваження «Властивості всіх об'єктів не відображаються».
- «Дуже важливі зауваження». Коли гармати основного бою відгриміли, починається розбір зауважень на критичні і не критичні. Критичні будуть у вас кісткою в горлі, вони заважають підписанню акта. Тому троль буде намагатися зробити кожне зауваження критичним. Включається весь наявний пафос, залучаються авторитетні товариші, які кивають головами, та інший цирк з конями.
А тепер розглянемо те, що нам потрібно, щоб уникнути описаних неприємностей при здачі робіт.
Програма і методика випробувань
Документ ПМІ, або програма і методика випробувань, на мій погляд, більш важливий, ніж навіть ТЗ. Від якості цього документа залежить половина, якщо не дві третіх успіху випробувань.
Вимоги до змісту документа описані в розділі 2.14 РТ РД 50-34.698-90, також відомого як Настільний Стандарт Техписьменника. Що повинен містити цей документ:
- Повну формальну частину за ГОСТ (об'єкт і мета випробувань, обсяги та умови випробувань тощо). У підсумку після прочитання цих розділів будь-який член комісії, навіть якщо він у проекті досі не брав участі, повинен зрозуміти, що здають і яка його особисто роль у всьому цьому.
- Перевірку комплектності всього і вся - документації, дисків, кількості копій, що передаються, тощо. Відповідно, до випробувань все це повинно бути присутнім фізично. Мета - закрити формальні вимоги ТЗ і договору в частині поставки.
- Опис того, як саме проводяться тести. Чи будете ви згодовувати системі реальні дані з фізичних датчиків або підсунете тестові файли або емулятор? Система буде керувати реальним об'єктом або досить подивитися логи, де написано про те, що вона робила те-то і те-то? Користувач повинен урочисто сидіти в диспетчерському залі або можна обмежитися ноутбуком в офісі?
- Високорівневі тести системи. Детальність може бути різною, залежно від замовника. Зустрічаються і загальні тести, і тести з покроковими інструкціями. Мета у тестів проста: коли пройдено останній тест ви повинні закрити всі без винятку функціональні вимоги ТЗ, а також зазначити той факт, що в експлуатаційних документах є необхідна інформація (тобто, вони придатні до роботи).
- Сценарій тестування. Тести повинні розташовуватися в потрібному вам порядку, щоб мінімізувати час випробувань і зайві питання. Наприклад, якщо ви перевіряєте прийом, переведення і звільнення співробітника в кадровій програмі, то нехай сценарій буде саме таким - ви приймаєте когось на роботу, потім його ж переводите, потім його ж звільняєте, щоб не довелося кожен раз заводити нового співробітника і витрачати на це час. Або інший приклад. В одному з тестів ви повинні перевірити резервування і відновлення системи. Якщо випробування йдуть кілька днів поспіль, розумніше було б запланувати тест на створення резервної копії на кінець першого дня. Тоді не довелося б чекати закінчення тривалої процедури. А відновлення можна запланувати на передостанній день. Перед відновленням можна виконати жорстокі тести, на зразок емуляції аварійного вимикання, втрати журналів і критичних файлів (якщо це потрібно випробовувати, зрозуміло). Зараз сказане здається очевидним, але почитайте реальні документи, щоб переконатися, що це очевидно далеко не всім!
Протокол випробувань
На основі тестів ПМІ ви повинні підготувати протокол випробувань. Протокол буде документом, що підтверджує те, що ваша система виконана відповідно до ТЗ, про що робиться відповідний запис в акті. Не довіряйте підготовку протоколу нікому іншому, якщо не хочете мати блідий вигляд перед комісією. Зазвичай протокол є «копіпастом» з ПМІ, так що його підготовка багато часу у вас не займе.
Протокол випробувань складається із загальної частини, таблиці тестів і списку зауважень.
Таблиця, в яку заносяться результати тестів, може складатися з таких колонок:
- Наскрізний номер (у зручному вам форматі). Наприклад, Номер _ теста.Номер _ кроку.
- Дії оператора. Що робить оператор, для того, щоб отримати результат. Переконайтеся, що формулювання виключають зловмисне неправильне тлумачення.
- Очікуваний результат. Простими словами описаний результат дій оператора, який можна перевірити (помацати, побачити, унюхати). Наприклад: «Запалилася зелена лампочка на верхній панелі», «У списку користувачів з'явився новий користувач», «На екрані відобразилося попередження системи про неправильно введений пароль», «У системному журналі X з'явився запис Y». Переконайтеся, що формулювання максимально конкретні і виключають зловмисне невірне тлумачення. Пам'ятайте також про слова, що є кормовою базою для тролів: «будь-який», «кожен», «все», «ніякі» тощо.
- Пункт документації (наприклад, Підручник з користувачем), у якому наведено детальний опис дій, що виконуються, або закриється нефункціональна вимога ТЗ. Наявність цього пункту дозволить вбити відразу двох зайців. По-перше, ви задокументуєте те, що все, що треба відображено в проектній документації. По-друге, вам не доведеться детально розписувати дії оператора, так як (увага!) до тестів допускаються співробітники, які відповідають вимогам технічного проекту, в яких ви написали, що вони повинні пройти такі-то курси і бути знайомі з експлуатаційними документами.
- Пункт або пункти ТЗ, що закриваються на цьому кроці. Сума за стовпчиком повинна дати все (саме всі, а не тільки функціональні!) вимоги ТЗ. Саме тому в протоколі будуть «тупі тести» на перевірку комплектності документації, на те, що програма написана на java і база даних Oracle DBMS є реляційною (тикаємо пальцем у відповідний розділ документації).
- Рішення комісії. Потрібно наполягати на таких рішеннях: «Пройдено», «Пройдено із зауваженнями», «Не пройдено», «Не тестувалося». Інших записів тут бути не повинно. Запис «Не тестувалося» робиться для тестів, проводити які комісія не захотіла або провести їх фізично неможливо на момент проведення випробувань. Наприклад, вони вирішили не висмикувати вузол кластера з розетки. Краще, щоб таких записів у протоколі не було, щоб не з'явилася зайва можливість для троллінгу.
- Коментарі. Якщо тест пройдено із зауваженнями, тут має стояти номер зауваження. Всі зауваження заносяться в додаток до протоколу у вільній формі. Можна вказувати номер тесту, під час виконання якого виникли зауваження. На більше вам банально не вистачить часу. Якщо рішення комісії «Пройдено», постарайтеся нічого не писати в колонці «Коментарі»
Генеральна репетиція
Без неї не можна. Тільки так ви можете відловити всі шорсткості в тестах, виявити тести, що крадуть час і тести, результати яких сумнівні. Пам'ятайте, що візуальна складова повинна бути бездоганна. Постарайтеся забити в систему дані, які виглядають натурально і схожі на те, з чим має справу клієнт. Прослідкуйте, щоб імена користувачів та інші поля не містили ненормативну лексику (улюблений жарт впроваджувачів і программерів). Ці «жарти» іноді діють на комісію як червона ганчірка на бика.
Не бійтеся переписати ПМІ з нуля. Одного разу ми пошкодували час і перекомпонували тести замість того, щоб переписати їх. У підсумку ми просто заспокоїли самі себе, не змінивши загальної плачевної картини. За що і огребли.
Якщо ви здаєте удвох, ганяйте тести разом. Запрошуйте колег, нехай вони прискіпуються, зображуючи із себе комісію. Витрачений на ці ігри час в результаті дозволить всім вам отримати гроші від задоволеного замовника.
Ефективний дует
Оптимальною командою для здачі є пара з впровадженця (або програміста) і бізнес-аналітика (консультанта).
Впровадженець (програміст):
- працює з системою, демонструючи віртуозне володіння інтерфейсом
- відповідає на технічні питання
Аналітик (консультант):
- говорить про систему з замовником, веде бесіду
- відповідає на загальні питання
- веде протокол
- копає під столом впровадженця (програміста)
Така бригада дозволить реалізувати прийом, який можна назвати «передача мікрофона». Якщо програміст раптом наступив на багу, консультант може дати йому запотиличник і швидко заболтати замовника, обурюючись з приводу чиїхось кривих рук. Ефект буде як у цирку. Замовник посміється про себе і тут же подумає, що він-то не клоун і руки-то у нього прямо будуть.
Точно так само, якщо консультант скаже дурість, а замовник нахмуриться у відповідь, програміст може з обличчям ображеної невинності продемонструвати чергову фішку системи і тоді замовник перейметься до нього симпатією, так як зрозуміє, хто тут справжній профі, а хто клоун в краватці.
В особливо напружені моменти можна влаштувати дружню перепалку, розрядивши тим самим обстановку і відвівши увагу аудиторії від не зовсім коректної роботи системи.
Не дарма ж західні «айтішні євангелісти» люблять працювати парами.
Процес пішов!
Коли ви приступили до випробувань, не змійте лізти в систему відразу! Постарайтеся пройти спочатку всю формальну частину. Зверніть коди документації, носіїв інформації, відкрийте ТЗ, покладіть на стіл Підручник користувача. Пройдіться по нефункціональним вимогам. ОС Windows - галочка. Підтримувані версії браузерів - раз, два, три, галочка. Мова розробки, архітектура, база даних, та мало що там в ТЗ понаписано! Все потрібно показати в документації. Хоча б там всього лише одна пропозиція, вона зобов'язана там бути! Не нехтуйте цією бюрократією, тролі тільки цього і чекають. Вам хочеться отримати в протоколі, що "Виконавець не продемонстрував, що мова java є кроссплатформною мовою високого рівня. Вимоги ТЗ 1.2.3 та 3.2.1 не виконані "? Адже це не придуманий маразм, це саме життя.
Коли ви закінчили з формальною стороною справи, теж не поспішайте лізти в систему! Наступна група тестів полягає у включенні монітора і демонстрації робочого столу, іконок і запуску програми (якщо запуск потрібно тестувати). Вхід в систему з неправильним паролем, галочка, вхід з правильним - знову галочка, галочка, галочка. Меню - ека невідаль! Головна форма, список чого-небудь. Галочка.
Коли дійде справа до натискання кнопок у системі, комісія вже порядком захистить і зголодніє. А ви в перший день зможете проскочити, наприклад, основні довідники і базові функції. А на інший день залишити бекапування, адміністрування і ще якусь дурницю.
Зауваження
Вони будуть, можете не сумніватися. Немає такої системи, до якої не було б зауважень. Ваше завдання - змусити замовника поділити всі зауваження на критичні і не критичні. Перші повинні бути виправлені для успішного переведення в дослідну експлуатацію. Другі можуть бути виправлені в ході дослідної експлуатації. Відповідно, краще, щоб перших взагалі не було або були тільки ті, виправити які не представляє особливої праці.
Коли замовник робить зауваження, ви фіксуєте його формулювання в протоколі. Обов "язково проговоріть записані слова, переконайтеся, що ви один одного зрозуміли. Буде краще, якщо в ході випробувань буде працювати диктофон. Постарайтеся зробити так, щоб формулювання зауваження було конструктивним, тобто, було зрозуміло, що потрібно зробити, щоб зауваження було знято. Слів «все», «нічого», «кожен», «будь-який», а також незмірних якісних оцінок «погано», «повільно», «занадто швидко» і т. п. в зауваженні бути не повинно! Якщо «система працює повільно», то має бути написано «запитана форма повинна відображатися протягом 5 сек». Якщо «символи на схемі погано відмінні», слід написати «збільшити символи на схемі до 18 пунктів». І так далі.
Конкретизація дозволить мінімізувати можливість необґрунтованого перетягування того чи іншого зауваження в ранг критичного. Замовник може стверджувати, що відпрацювання запиту за 6 секунд для нього неприйнятне, а за 5 секунд - у самий раз. Нехай це з'явиться в протоколі! Але щось мені підказує, що не з'явиться. Або зауваження буде визнано некритичним.
Всі зауваження, визнані критичним фіксуються в акті: "Комісія постановила, що система відповідає ТЗ і рекомендує прийняти її в дослідну експлуатацію за умов відпрацювання наступних зауважень:...» При цьому список некритичних зауважень краще безпосередньо в акт не включати. Їх зазвичай багато і вони можуть налякати відповідального співробітника, який ставить підпис. Якщо замовник турбується, що ви не будете відпрацьовувати некритичні зауваження, заспокойте його за допомогою документа «Методика проведення дослідної експлуатації», котрий наполегливо рекомендується підготувати. Там ви в простій і доступній формі повинні описати як буде проходити дослідна експлуатація, як будуть відпрацьовуватися знайдені баги і як буде заповнюватися журнал дослідної експлуатації, що є гарантом безболісного закінчення ОЕ, введення системи в промислову експлуатацію і салюту з шампанським через закінчення проекту.
Що робити, якщо все пропало
Коли ви розумієте, що випробування йдуть незадовільно, система потворно глючить, а замовник вже вичерпав запас лайок, не потрібно здаватися! Караван повинен продовжувати йти вперед, буде новий реліз, нові випробування. І навіть якщо проект буде завалений, нічого в цьому страшного для вас немає. В умовах гострого дефіциту розумних виконавців ви швидко знайдете роботу, тим більше, що я б на вашому місці не став би працювати в компанії, що допускає подібні ситуації.
Щоб не втрачати час у безплотних суперечках, я б рекомендував застосувати тактику «бий своїх, щоб чужі боялися». Почніть разом із замовником лаяти «цих криворуких программерів», «жадібне керівництво», а коли напруження пристрастей зменшиться, запропонуйте замовнику зібрати максимум багів «цього глюкалова», щоб показати цим нехорошим людям які вони нехороші.
Тоді активні співробітники замовника на чолі з тролем-кілером почнуть збирати баги і радісно наповнювати протокол сотнями зауважень. Фактично, за свої власні гроші вони проведуть вам високорівневе функціональне тестування, на яке, судячи з результатів випробувань, ваші розробники так і не спромоглися.
По хорошому, описаної потворної ситуації взагалі бути не повинно. Але проектний бізнес відрізняється іноді дивними флуктуаціями, коли перший прототип намагаються здати як повноцінну систему, начальство бреше підлеглим і самим собі, всі навколо роблять хорошу міну при поганій грі і запевняють один одного в обов'язковому і неодмінному успіху.
Другою радою в подібній ситуації було б, як я вже говорив, відразу звільнитися з контори, що допускає подібні «косяки». Тому що за всіма мірками справжньому професіоналу не варто псувати свою репутацію подібним чином.
Ув'язнення
Отже, колеги, на цьому я поспішаю завершити трилогію про корпоративні тролі, яких не потрібно боятися, а потрібно поважати і навіть деяким чином любити, так як вони не дають ледачим мавпам ІТ бізнесу падати від обжорства з дерев, тримають нас в тонусі і навіть привносять деякий інтерес в шалено нудні, але вкрай необхідні проектні роботи.
UPD від 23.06.2011. Користувач igendo додає в коментарях, що непогано б вже на етапі укладення договору затвердити форми офіційних документів проекту.
Цитую:
Додам, що дуже допомагає в роботі, коли форми актів, протоколів та інших формальних документів зафіксовані в контракті. Щоб не було необхідності їх попередньо погоджувати, переузгоджувати і переробляти\перепідписувати в середині проекту.
Від себе теж можу додати, що в зовсім вже важких і масштабних проектах прийнято складати статут проекту, якийсь документ про глибинний сенс якого можна говорити годинами. Там, крім усього іншого, можна обговорити і форми документів проекту, і процедури контролю ходу проекту, і високорівневі бізнес-завдання. Але це, знову ж таки, тема для іншого посту.
Користувач ЖЖ ryzhij_papa Додає, що існує практика ранжування зауважень за ступенем їх впливу на бізнес, методика ранжування також заноситься в ПМІ.
Цитую:
Потрібно формально описати що є зауваженнями кричного, високого, середнього і низького пріоритету. Опис робиться в термінах бізнесу. Якщо утрувати, то так: критичний пріоритет при втраті 1000 $, високий якщо 100 $, середній коли співробітники в милі, але збитків у нас немає, низький - можливі випадки легкого запаморочення на 5-6 році життя з такою багою...
