(Сторінка 2 з 4)
? Своєчасно давати зворотний зв'язок по проекту і направляти в потрібне русло. На мою думку, це найважливіша функція замовника. Його завдання - не дати проекту піти з потрібного курсу. Замовник повинен постійно відслідковувати поточний результат проекту і вживати заходів, якщо отримує невідповідний результат. Менеджер проекту і команда розробки не завжди можуть повністю оцінити бізнес-потреба в тому чи іншому елементі. Саме замовник краще за всіх знає, як це буде застосовуватися в його бізнесі. Тому тільки він може внести істотні корективи, які дозволять максимально ефективно використовувати сайт в його бізнесі.
? Тестувати з точки зору бізнес-процесів замовника. Цей пункт дещо перегукується з попереднім. Тестировщики від розробників зазвичай просто тестують функціональність на предмет відповідності рішення умовами завдання. Однак вони не зможуть виявити організаційні помилки та невраховані бізнес-потреби. Це можна зробити тільки задіявши ресурси замовника. Чи правильно йдуть інформаційні потоки, чи всі дані враховані, чи буде зручно співробітникам замовника працювати в системі, які показники ефективності кожної ролі і т.д.
Крім необхідних дій, є ще побажання до замовників. Це кілька рекомендацій, які збільшують шанси проекту на успіх.
Стежити за проектом. Ми про це вже говорили і ще раз повторимо. Не можна пускати проект на самоплив, яка б хороша команда розробки у вас не була.
Виконувати побажання і запити за проектом від виконавця. Це прискорить процес виконання проекту, а також дозволить уникнути можливих помилок.
Узгодити взаємодія з виконавцем. Що це означає? Це означає, що виконавець повинен чітко знати ваші пріоритети і цілі, пов'язані з проектом. Це спрощує прийняття рішень і взаємодія. Також бажано визначити пріоритети по параметрам проекту (бюджет, терміни, обсяг, якість). При необхідності, це дозволить менеджеру проекту правильно перерозподіляти ресурси.
вручну пройти програму і подивитися внутрішні обчислення).
Відразу визначати свої очікування щодо термінів і бюджетам. Якщо якийсь параметр для вас дуже критичний і має строгий дедлайн - то дайте цю інформацію менеджеру проекту. Не повинно бути такого, коли ви посередині проекту починаєте раптом вимагати його форсованого завершення. У цьому випадку це вкрай негативно впливатиме на якість.
Уникати затримок, пов'язаних з фінансами і контентом. Заздалегідь готуйте матеріали і відкладайте гроші під бюджет проекту. Це дозволить уникнути непродуктивних затримок з вашого боку. Затримки в будь-якому випадку будуть в проекті, і тут рідко кому вдається їх уникнути. Тому завдання замовника - хоча б у відносно простих моментах їх не допускати.
У цьому розділі ми розглянули, ніж на проекті займаються менеджер і замовник. Далі ми переходимо до першого етапу ведення проекту - опрацювання ідеї проекту і її тестування.
Глава 3. Ідея проекту. Як опрацювати і перевірити ідею.
Складно переоцінити цей етап. Саме тут ви можете заощадити велику купу грошей. Перед початком проекту ви зобов'язані перевірити - чи дійсно проект дасть той результат, на який ви націлилися? У вас повинна бути деяка ступінь впевненості, що виконавши проект, ви отримаєте той чи інший бізнес-результат.
Маючи в голові цю мету, ми займемося питанням опрацювання ідеї проекту, а також розглянемо питання "Як протестувати свою ідею на ринку".
Перше, що вам треба зробити - це зрозуміти, а чи потрібен комусь проект крім вас. Тобто важливо на самому початку визначити аудиторію, яка буде споживати результати вашого проекту. Для цієї мети дуже зручно використовувати сервіс Wordstat - wordstat.yandex.ru. Визначте цільові запити, які буде набирати ваша цільова аудиторія в пошукових системах і подивіться, яка у них частотність в Wordstat - там самим ви зрозумієте, чи є у вас ринок чи ні, і наскільки він великий.
Якщо у вас ринок є, то вітаю, рухаємося далі.
Вивчаємо конкурентів - хто вони, яка у них відвідуваність, скільки їх в ніші, яка у них товарна лінійка і т.д. Складіть список своїх конкурентів і проаналізуйте їх. Чим краще ви будете знати конкурентів, тим більше нюансів ви зможете врахувати в своєму проекті.
Примітка. Тут ми не будемо детально зупинятися як проводити дослідження цільової аудиторії, конкурентів і їх продукції. Зараз наша мета - це управління проектом в цілому. Тому, ми лише поверхнево торкнемося цих, без сумніву, важливих питань.
В результаті ви отримаєте якусь кількість кліків (нехай буде наприклад 200 або 500). З них до вас звернулося 5 осіб. У підсумку ви отримуєте конверсію - 5/200 * 100% = 2,5%. Якщо ваша конверсія складе більше 1%, то, значить, ваша ідея варта того, щоб спробувати. Якщо ні - то, можливо, ваша пропозиція не настільки приваблива, і слід над ним попрацювати.
При створенні пропозиції робіть його трохи краще, ніж в середньому по ринку (мається на увазі за ціною). В ідеалі, це має бути пропозиція, від якого просто нерозумно відмовлятися.
Етап тестування дуже часто пропускається (ми і самі його пропускали в деяких своїх проектах, і обпікалися на цьому). Зробіть хоча б простий опитування з 100 чоловік (бажано якомога ближче до цільової аудиторії проекту). Це не займе багато часу, але зате може вам заощадити дуже пристойну суму грошей і час.
З тестами закінчили, тепер давайте сформулюємо мету проекту. Що ми в підсумку хочемо від нього отримати. При цьому мета, звичайно, краще ставити в речових параметрах і в цифрах. Напишіть, який конкретно результат у вас буде по завершенню проекту. Це можуть бути:
Визначте точну метрику і дату, до якої ви хочете її отримати. Ставте значення на межі своїх можливостей. Занадто багато - це буде демотивувати і підривати весь проект, мало - теж погано (буде все затягуватися і інтерес до проекту швидко пропаде).
Наступний момент - оцініть, від чого вам доведеться відмовитися. У світі дуже багато можливостей і успіху досягає той, хто вміє відмовитися від хорошого в користь великого. Ваші ресурси не безмежні, тому визначтеся відразу, чи готові ви пожертвувати всім іншим заради цього проекту.
Напишіть список альтернативних проектів і усвідомлено відмовтеся від кожного на користь поточного проекту. Звичайно, якщо у вас велика команда, то ви можете делегувати дрібні проекти. Тут ми говоримо про проекти, які можуть займати практично всі ваші поточні ресурси (час, люди, гроші, енергія).
Також варто розглянути питання про запуск спочатку якогось більш дрібного проекту, пілотного проекту. Мені подобається ідея прототипну рішень - ви не робите відразу велике повноцінне рішення - спочатку ви робите пілотний швидкий проект для отримання зворотного зв'язку. Тобто цей проект набагато легше основного проекту і на ньому ви розумієте, чи буде це працювати чи ні. В якомусь сенсі, проведення тесту і є пілотним проектом, але ступінь "пілотних" може бути різною.
Як ми вже згадували, відразу співвідносите свої ресурси з проектом. Чи зможете ви його потягнути в тому вигляді, який ви визначили. Чи немає розриву між можливостями і потребами? Найважливіше - будьте чесними з собою. На березі вирішите всі моменти з ресурсами для проекту, щоб потім не закривати проект на середині шляху. Два найважливіших параметра - це гроші і час. Чи вистачить вам фінансових коштів для підняття проекту до того моменту, поки він не стане окупати сам себе? Чи буде у вас час на повноцінну участь у проекті? Без опрацювання цих 2 параметрів ризики проекту істотно збільшуються.
На цій трохи суворої ноті ми закінчуємо главу про опрацювання ідеї проекту і переходимо до передпроектної діяльності. На цьому етапі ви вже твердо вирішили, що проект будемо робити і тепер ми переходимо до тактичних питань підготовки проекту до запуску.
Глава 4. Передпроектна діяльність
Що ми повинні зробити до початку проекту?
По-перше, це загальна оцінка проекту.
По-друге, визначити основні параметри проекту.
І, по-третє, формалізувати всі моменти по проекту у вигляді концепції проекту (це письмовий документ, а не щось, що у вас в голові).
Почнемо з оцінки. Найважливіший момент, треба розрізняти оцінку, зобов'язання і фактичний показник. Оцінка - це прогноз по метриці. Зобов'язання - це обіцянка зробити в рамках певних метрик. І фактична метрика - це те, що за фактом вийшло.
Дуже часто просять назвати дуже точну оцінку по короткому змісту проекту. Тим самим замовник вже закладає гігантські ризики в проект. Неможливо дати точну оцінку на початковому етапі. Вона в принципі не може бути точною. Є таке поняття як "Конус невизначеності". На початковому етапі оцінка дуже широка, потім у міру руху проекту вилка оцінки зменшується (тому що зменшується невизначеність в проекті). Таким чином, не намагайтеся дуже точно оцінити проект на самому ранньому етапі. Краще зосередьтеся на наступному - зробіть так, щоб в 90% випадків фактична метрика увійшла в ваша початковий діапазон оцінки.
Які бувають види оцінки?
Швидка оцінка. Робиться через сам погляд на проект. Ми її дуже часто використовуємо для первинної оцінки проекту. Як вона робиться:
Робимо градацію по проектам. Наприклад, 3 градації, у кожної своя вилка і критерії попадання під неї.
При оцінці проекту співвідносимо її з однією з градацій.
Отримуємо оцінку (оцінка цієї градації, яка зроблена заздалегідь).
Плюс цього підходу в швидкості і малих витратах. Мінус - це дуже приблизний спосіб. Але для першого ознайомлення з проектом цього буває цілком достатньо. Ще момент - цей спосіб практично не вимагає технічної кваліфікації від оцінювача. Його завдання - просто коректно співвіднести проект з потрібною градацією.
Модульна оцінка. Ви розбиваєте конкретний проект на великі блоки, модулі і окремо оцінюєте кожен модуль. Зазвичай це робить вже технічний фахівець, або менеджер. Тут, як мінімум, потрібно детально ознайомитися з концепцією або ТЗ проекту. Модулями можуть бути великі функціональні блоки, які є більш-менш типовими. Для таких блоків можна зробити типові оцінки. Наприклад, зробити форум - це N годин (або X рублів). Це трохи спрощує оцінку.
Ця оцінка істотно точніше попереднього способу і, якщо у вас одиночний проект, то саме її найкраще використовувати на початковому етапі. Ви також можете попросити дати оцінку у інших людей, не тільки проекту, а окремого модуля. Це також дозволить вам отримати більш об'єктивне уявлення про кожному модулі.
Детальна оцінка. Ви розбиваєте весь проект на дрібні шматочки - функції і компоненти і детально оцінюєте кожен з них. Буде дуже добре якщо це будуть робити розробники, і їх буде кілька. Це зробить оцінку істотно точніше. Паралельно ви можете опрацювати проект - виявити відсутні нюанси.
Для цієї оцінки дуже важливо, щоб ТЗ було вже написано і воно було досить детальним. Якщо цього не буде, то розробники завалять вас купою питань по деталях проекту.
Оцінку краще вести в годинах і визначити нормовану вартість цієї години. У кожного компонента (або сторінки) буде 2 оцінки - мінімальна і максимальна. Чим точніше написано завдання, тим ближче вони будуть один до одного.
У підсумку, підсумовуючи ці оцінки, ви отримаєте досить точне уявлення про бюджет і терміни проекту.
Дуже важливо при цій оцінці врахувати всі додаткові роботи (про яких можуть забути розробники), а саме:
? первинна пошукова оптимізація
? винесення налаштувань в адмінку
? дизайн для адмінки
? типовий функціонал, не врахований в ТЗ (зміна пароля, відновлення пароля, вихід і т.д.)
? створення системи бекапів
? настройка моніторингу доступності
? реєстрація в пошукових системах
? обробка нових запитів клієнта
? складання звітності по проекту.
Ще важливий момент, враховуйте, що в будь-якому випадку будуть невраховані доопрацювання. Їх розмір залежить, в основному, від клієнта - саме він в кінцевому рахунку визначає які функції треба змінити. Тут важливо пам'ятати, що чим пізніше ви впроваджуєте зміни, тим дорожче вони коштуватимуть. Тому бажано відразу правильно визначати склад функціональності в проекті.
При оцінці важливо враховувати такий показник як рівень абстракції. Виберіть прийнятний для себе рівень абстракції і саме на ньому проводите оцінку. Якщо у вас немає ресурсів для уточненої оцінки, оцінюйте на рівні модулів. У будь-якому випадку починайте рухатися про верхнього рівня до нижнього, тобто спочатку в цілому зрозумійте на рівні підсистем що це буде, а потім розбирайте кожну підсистему на модулі, а модулі на компоненти. На будь-якому з рівнів абстракції ви можете зупинитися, вважаючи його достатнім для цілей оцінки.
Ще момент, виберіть рівень технічних рішень і якості. Тут має сенс брати орієнтир на інші сайти, тобто цей блок зробити приблизно як на site.ru. Звичайно, це дуже суб'єктивно, але дозволить команді розробці зробити своє уявлення про обраному рівні якості.
Після того як ми зробили оцінку за термінами і бюджету, добре б зібрати всю інформацію воєдино в так звану концепцію проекту.
Що в неї входить:
1. Основні параметри проекту:
a. Проект має на меті і результат. Що в підсумку ви повинні отримати? Навіщо вам потрібен цей проект? Вхідними даними для якого наступного проекту буде результат поточного проекту? Чітко визначте критерії завершення проекту.
b. Терміни. Скільки в цілому місяців / тижнів займе проект?
c. Бюджет. Скільки ви запланували закласти коштів на реалізацію проекту?
d. Об `єм. Що потрібно реалізувати в рамках проекту? Що ми залишимо за бортом? Визначте межі проекту.
e. Команда. Хто буде реалізовувати цей проект? Хто за що буде відповідати на проекті?
f. Ресурси. Які додаткові ресурси вам будуть потрібні для реалізації проекту? Це можуть бути знання, технічні засоби, місце для роботи і т.д.
i. Орієнтовний план. Ви приблизно повинні визначити, як ви досягнете мети проекту. Тут не потрібна деталізація - просто визначте етапи досягнення мети. Це дозволить команді розробки в цілому розуміти в який бік треба рухатися. Для кожного етапу намітьте орієнтовні терміни. Тут слід розуміти, що це не зобов'язання або план до виконання. Це просто бажаний план розвитку проекту, який в процесі може змінюватися.
2. Короткий опис. Дуже бажано мати лаконічний опис, яке дозволить відразу схопити суть проекту і показати його особливість. Це потрібно для взаємодії із зовнішнім світом (дизайнери, програмісти, партнери і т.д.). Хороший опис заощадить вам купу часу при взаємодії з можливими виконавцями на проект - вам не писатимуть ті, хто свідомо не підходить.
3. Критерії відбору виконавців. Краще їх заздалегідь опрацювати, щоб знову ж заощадити час. Що можуть включати ці критерії:
b. Міні тест на адекватність. Якщо кандидат хоче з вами працювати, то нехай зробить просту послідовність дій, яку ви для нього підготували. Наприклад, відправити на пошту лист з темою «ХХХ» з вкладенням КП в форматі PDF. Якщо виконавець вам пише не в вашому форматі, то швидше за все він буде так само поводитися і на проекті. Старанність - це перше, що потрібно перевіряти для кандидатів.
Отже, ми написали концепцію. Виходячи з цієї концепції, ми будемо ініціювати проект. У наступному розділі ми вивчимо моменти, пов'язані безпосередньо з початком проекту.
Глава 5. Починаємо проект
Для початку давайте визначимося, з чого ми виходимо на початку проекту:
У нас є концепція з усім параметрами.
У нас є технічне завдання. Ми не розглядали його написання в цій книзі. По суті, це технічний опис, що треба зробити на проекті. Зазвичай воно складається з макетів і системних вимог.
Склад команди розробки визначено. Знову ж ми лише частково торкнулися момент з пошуком виконавців на проект. Припускаємо, що команда розробки у нас вже є.
Ви - менеджер цього проекту. Тобто у вас є всі повноваження щодо прийняття рішень на цьому проекті, а також виділені ресурси на проект, якими ви можете розпоряджатися.
Ініціацію проекту можна умовно розділити на 2 пункти:
Підготовка та виділення ресурсів
У плані підготовки інструментів і виділення ресурсів вам необхідно розглянути наступні моменти:
Ви повинні забезпечити підготовку тестового домену, сервера, де буде працювати тестове додаток, бази даних, інструментів розробки (SVN, середовища розробки та ін.). Одним словом, ви повинні підготувати тестову середу.
Дайте права і повноваження членам проекту. Це доступи до системи планування, доступ до тестового додатку (база, код, іноді сервер). Дайте контакти учасників проекту.