Кажуть, «Не важливо, як ти проект зробиш. Важливо, як ти його здаси ».
І правда, якщо про здачу проекту замислюватися на самому початку, то шанси його успішного виконання значно зростають. Причому існує як мінімум 3 важливих етапи, коли важливо підняти це питання під час спілкування з замовником - на початку проекту, в середині або по досягненню проміжних етапів виконання проекту, і по завершення проекту.
На початку проекту все, і команда, і замовник перебувають у щасливій ейфорії. Проект бачиться в райдужному світлі. І найчастіше з замовником проговорюється все, що потрібно зробити по ходу проекту, але момент і формат складання упускається з виду. При цьому і замовник також не поспішає піднімати це питання, тому що якщо не обумовлені критерії приймання - це дає йому свободу нескінченно пред'являти претензії по виконаній роботі. «Як, система не працює у всіх відомих йому браузерах? Або чому у мене попливло розташування елементів на сторінці ХХХ? А ось тут ось помилочка знайдена - будьте ласкаві виправити ... »І так до нескінченності. На жаль, на сьогоднішній момент, на жаль, софт зовсім без багів не виходить, тому якщо відразу не погодити критерії приймання - це може перетворитися на нескінченний процес.
Що робити на самому початку проекту:
- Погоджуємо з клієнтом обсяг завдань. що має бути зроблено, і фіксуємо ці завдання. Відразу уточнюємо правило, що до приймання неспроможні фрази:
- «Це ж очевидно» - якщо щось важливо, це повинно бути висловлено і зафіксовано (наприклад, для клієнта може бути само-собою зрозумілим, що «система повинна працювати у всіх браузерах», але це вимога тягне за собою значне збільшення часу на тестування, і, відповідно, має бути включено в бюджет, якщо замовнику це дійсно потрібно).
- «Ми про це говорили» - знову-таки, буває, що потік вимог у клієнта настільки великий, що навіть записати все не встигаєш. Тому розроблені специфікації і висилаються для підтвердження клієнтам, щоб переконатися, що нічого не забуто. Якщо щось упущено - це не може бути обов'язковим для приймання.
Важливо! Слід відрізняти приймальне тестування від повного тестування системи. Мета приймального тестування - переконатися, що система працює при найбільш очікуваних сценаріях використання. Для середніх систем такий план буде містити близько 30-100 сценаріїв, розробка яких зазвичай займає не більше 1-2 днів, а саме проходження приймання - близько 2-8 годин.
Наступна важлива контрольна точка виникає в процесі виконання проекту.
З досвіду - чим тісніше замовник залучений в проект і в курсі того, що відбувається, тим він краще розуміє всю ситуацію і більш схильний йти на компроміси в разі форс мажорів. Крім цього ви можете отримати оцінку проміжних робіт і при наявності будь-яких зауважень відразу їх виправити і врахувати в майбутній розробці, а не виправляти потім сніжний ком проблем в самому кінці проекту.
Що робити по ходу проекту:
- Надаємо клієнту статус звіти по проекту - що зроблено, що залишилося, з якими проблемами зіткнулися, де потрібне втручання замовника і що можна вирішити самостійно.
Важливо! Обов'язково в форматі: 1-сторінкові підсумки + деталізація. Напевно, у замовника мало часу вникати в усі нюанси, тому основною інформацією для нього стане ваш зведений звіт, а в деталі він буде дивитися вже по мірі необхідності. Зручна також «модель світлофора», коли на самому початку звіту надсилається статус: GREEN - все відмінно, ORANGE - так собі, RED - все погано. - Проводимо проміжні демо - скажімо, кожні 2 тижні (або частіше / рідше в залежності від тривалості проекту) демонструємо результат, запитуємо думку замовника і отримуємо підтвердження, що або все йде за планом, або потрібні коректування, тут же переконуємося, чи були правильно сприйняті все вимоги клієнта.
Важливо! В процесі демо у клієнта можуть виникнути нові «хотілки». Це абсолютно нормально. Просто тоді відразу і вирішуємо, що з ними робити - включаємо в проект і зрушуємо терміни або залучаємо доп.ресурси для їх реалізації або ж залишаємо на майбутнє - це можна і потрібно відразу ж узгодити. А якщо є зауваження - то, звичайно, виправити, щоб до моменту приймання не було неприємних сюрпризів.
І, нарешті, коли проект добігає кінця важливо грамотно провести його завершення і здавання-прийняття, орієнтуючись на критерії, вироблені на початку проекту.
Найбільш часто зустрічаються помилки - клієнтові просто відправляється версія системи і як би команда вважає, що на цьому справа зроблена, або ж з клієнтом не обмовляються терміни, в які повинно прийти підтвердження робіт, можуть призводити до того, що приймання затягується на довгі місяці.
Що робити до кінця проекту:
- Проводимо фінальне внутрішнє «приймальне» тестування. в ході якого переконуємося, що всі необхідні сценарії працюють.
- Погоджуємо з клієнтом дату і проводимо фінальне демо системи. де демонструємо фінальний результат розробки замовнику. Якщо все зроблено правильно, то на демо не повинно бути виявлено критичних або серйозних проблем, а все дрібне фіксується і буде вже виправлятися в рамках супроводу.
- Домовляємося про конкретний термін завершення здачі-приймання. в разі, коли погоджено, що клієнт має деякий час, протягом якого він може ще додатково самостійно протестувати систему. При цьому дуже важливо, щоб цей час було звичайно. Тобто щоб була чітко узгоджена дата, до якої приймаються зауваження.
Ось, мабуть, ці 8 нехитрих правил, і є той базис, який дозволить вам успішно здавати ваші проекти!