1. Як визначити великий проект?
2. Особливості великого проекту
3. питання клієнта
4. питання розробника
5. Основні ризики
6. Ключове питання прийняття рішення
7. Технологія взаємодії: ідеал і реальність
8. Оцінка і планування проекту
9. Договір і правила гри
10. Не потрібно автоматизувати бардак
11. документування завдання
12. Відстеження процесу розробки
13. Здача проекту. Тестування навантаження.
14. Парадокс великих проектів
15. Висновки
16. І ще висновок

Ця стаття була написана після серії доповідей на наших семінарах, які показали що тема вкрай цікава багатьом фахівцям і замовникам. Сподіваємося, і вам сподобається. Будемо раді коментарів.

Співавтор статті - Олексій Шкарупа, менеджер проекту Доміно.

Як визначити великий проект?

Що таке великий проект? Чим він відрізняється? Чим небезпечний і чим цікавий?

Правда в тому, що для кожного клієнта і розробника великий проект це поняття з різним наповненням.

Великий проект це унікальний замовлення, створює нові ризики для обох сторін.

Нові ризики - значить у вас немає відпрацьованої на практиці технології роботи з такими ризиками.

Що ж таке великий проект?

Ми сформулювали ряд ознак:

• запуск ведеться в кілька етапів.
  Поетапний запуск в експлуатацію завжди тягне більші ризики, ніж старт за 1 прийом. При цьому експерти вказують, що гранична тривалість одного етапу це 3-6 місяців. При більш довгих етапах накопичуються зміни, негатив з боку очікує замовника, змінюються пріоритети, все втомлюються і запуск стає все більш проблемним.
  
• проект перевищує попередній більш ніж в два рази.
  Цей критерій стосується і клієнта, і розробника. Якщо клієнт раніше замовляв тільки сайти-візитки, замовлення великого інтернет-магазину і спілкування з розробником будуть для нього сповнені несподіванок. Аналогічно з розробником - майже неможливо без серйозних промахів зробити проект, який перевищує ваш минулий досвід більш ніж удвічі.
  
• в основі проекту нова, необкатанная ідея або технологія.
  Невипробувані ідея або технологія, на яку покладають великі надії - це завжди ризик. Просте правило говорить: нова технологія в перший раз завжди ЗНИЖУЄ ефективність. Нова ідея, не приведи Боже, ставить під сумнів всі починання.

Особливості великого проекту

• Великий проект - завжди політика великий сайт, веб-проект, автоматизація завжди змінює логіку роботи бізнесу. Це завжди революція.
  А значить, будуть люди, які постраждають від впровадження, які НЕ зацікавлені в запуску проекту.
  Учасників проекту з боку клієнта завжди кілька, і паразитная потужність, їх зусилля, спрямовані на боротьбу один з одним, завжди створюють додаткові проблеми
  
• Невизначеність вимог і розкид оцінок
  У цьому блок будемо говорити про ризики клієнта.
  Великий проект тому і великий що в ньому багато невирішених питань.
  На початковому етапі завдання зазвичай описана лише в загальних рисах, що абсолютно зрозуміло і нормально
  З іншого боку, при ухваленні рішення про старт проекту і виборі підрядника керівник завжди хоче знати гранично точно термін і вартість проекту.
  А такої оцінки немає. Що робити?
  Поширена практика збору пропозицій у різних виконавців.
  Точність такого огляду завжди вкрай низька навіть при наявності загального ТЗ.
  У підсумку керівник перебуває в ситуації, коли у нього немає можливість вибрати розумно. Ціни відрізняються в десятки і сотні разів, компанії-виконавці при поверхневому розгляді всі однакові.
  
• Інтеграція з зовнішніми інформаційні системи і вбудовування в бізнес-процеси клієнта - особливий і великий ризик
  Великі веб-проекти існують не у вакуумі, вони обмінюються даними з іншими інформаційними системами. Такі обміни, як правило, вимагають доопрацювання як мінімум однієї з систем, часто - обох. Організаційно і технічно це питання лежить на кордоні повноважень і ответственнності сторін проекту, і тому часто його рішення затягується.
  Аналогічна ситуація з навчанням співробітників замовника і початком реальної експлуатації. Одностайне бажання працювати в новій системі зустрічається нечасто, і процес впровадження - окремий велике питання.
  Як сказав одного разу знайомий фахівець з впровадження бухгалтерських систем: «щоб це запрограмувати, потрібні лише гроші, а щоб воно потім запрацювало - інші».

У проекті Доміно сайт мав важливе стратегічне значення для бізнесу, і рівень зацікавленості керівництва був дуже високий. Насправді це великий плюс.

Первісне ТЗ опитані 50 команд веб-розробників оцінили від 30 тисяч рублів до 2 мільйонів. Такий розкид передбачувано не давав прийняти рішення з ким це робити.

Повною мірою реалізувався ризик інтеграції з зовнішніми системами - файли імпорту для сайту, довідники, парсер оголошень були готовий на 4 місяці пізніше треба, і це відсунуло запуск і зажадало в режимі ручного управління міняти порядок реалізації.

питання клієнта

Взагалі кажучи, клієнт і розробник - майже рівноправні сторони процесу розробки, і ризики у них схожі.

Які питання ставить (або повинен ставити) перед собою клієнт, який вирішив зробити щось незвичайне і велике - великий веб-проект:

• мета і завдання
  Потрібно зрозуміти навіщо створюється проект. Прибуток? Слава? Підтримка основного бізнесу? Новий ринок?
  Як результат буде перевірятися?
  Які терміни? зрозуміло, що «вчора», а реально які?
  На ці питання потрібно дати продумані і максимально достовірні відповіді.
  Маркетингові заклики замість цілей і завдань проекту - погана ознака.
  
• рамки і пріоритети
  Часто думають так: раз проект у нас великий і незвичайний, нехай відразу все робить. Дуже важливо зрозуміти і зафіксувати рамки, межі проекту. Пам'ятайте: шанси на успішний запуск зменшуються з кожним зайвим днем. Краще запустити менше функцій, але швидше і якісніше.
  Пріоритети дозволяють і замовнику, і розробнику розуміти що найважливіше в проекті, з чого треба починати, а що вторинне і може бути зроблено потім і з меншою увагою.
  Грамотний менеджер проекту завжди намагається зробити спочатку найскладніше, а не найпростіше. А зробивши - намагається запустити його в роботу на реальних клієнтів і співробітників.
  
• навантаження на фахівців клієнта
  Часто клієнт не підозрює як багато працювати доведеться йому самому. При створенні великого замовного проекту навантаження на фахівців клієнта може бути дуже значною. У нашій практиці кілька разів були випадки, коли проекти згорталися або їх терміни і склад сильно змінювалися тому, що менеджер клієнта не був готовий, не міг або не хотів приділяти проекту багато часу і виконувати кваліфіковано свою частину роботи - думати, готувати інформацію, приймати рішення , аналізувати варіанти.
  Часто з боку клієнта потрібен не тільки менеджер і оператор для введення даних, але і розробники, системні адміністратори, маркетологи, копірайтери.
  Неправильне розуміння поділу обов'язків ( «як, я думав це теж ви робите !?») - великий ризик.
  Розумний і далекоглядний клієнт, незалежно від того, викликають у нього довіру співробітники виконавця, обов'язково запитає: «що і коли повинні будемо зробити ми?». Обережний - ще і запише це в договір.
  У проекті Доміно нам пощастило, причому двічі. Спочатку проектом займалася Ольга Семірогова (Воробйова), якій належить колосальна роль в проектуванні сайту. На жаль, в розпал проекту вона покинула компанію, і запускали проект ми з Олексієм Маркеловим, який проявив і знання, і досвід, і здоровий глузд. Все вийшло, хоча зміна контактера в проекті це один з найважчих ризиків.
  
• хто буде робити і як?
  Якого розробника вибрати? Зовнішні люди або свої співробітники? Місцеві або «варяги»? Коробкова система, гнучкий фреймворк або оригінальний код, де «все своє»?
  Повний розбір цього питання не вміститься і в десяток таких статей, скажу коротко головне.
  Своя команда це добре, якщо вона у вас є: спрацьована, професійна, структурована і керована.
  Команда не може складатися з однієї особи. Спроба зібрати команду «з вулиці» і відразу доручити їй розробку примножує ризики.
  Територіальна близькість до розробника, можливість особисто зустрітися і поговорити, а при необхідності і попрацювати в одному приміщенні дуже спрощує діалог, особливо на етапі постановки завдань і здачі етапів, а потім і всього проекту. Часом замовник часто готовий заплатити в кілька разів більше саме за таку можливість.
  Один з головних принципів ефективної розробки програмного забезпечення говорить: особисте спілкування - найкращий спосіб діалогу.
  
• як бути впевненим що все вийде?
  замовна розробка великого проекту це завжди дуже ризикований крок. Опитування IT-директорів журналом Intelligent Enterprise показав, що
  31% проектів завершуються провалом
  53% проектів завершуються з перевитратою бюджету в середньому в 1,9 рази
  16% (всього!) Проектів закладаються в термін і бюджет.
  Погодьтеся, вам би хотілося потрапити в 16%? Однак куди більше шансів, особливо при відсутності досвіду, обережності і удачі, потрапити в інші групи.

питання розробника

Взагалі кажучи, відносини розробника і клієнта, особливо при першій спільній роботі, напруженої ситуації і гріхах з обох сторін, та ще й легкому почутті недовіри, легко можуть скотитися до сюжету «чужий проти хижака».

Це неприємно по-людськи і шкодить проекту. Крім думок про якість проекту, розробник повинен піклуватися і про відносини. Втім, як і клієнт.

Отже, що повинен зробити досвідчений розробник:

• розпізнати великий проект
  Вчасно зрозуміти що проект новий, великий, ризикований і побачити свої ризики, а потім зрозуміти як ними управляти.
• оцінити проект
  будь-яким способом, яким він володіє, постаратися оцінити обсяг трудовитрат, а потім розумно застосувати «множники»: нова технологія, слабке ТЗ, стислі терміни, відсутність злагодженої команди, погано опрацьовані обмеження.
  Взагалі кажучи, є статистично перевірені методики оцінки масштабу проекту PERT, CoCoMo II і інші. У чистому вигляді вони навряд чи спрацюють, але корисні думки в них є.
  
• визначитися з методикою управління проектом
  серед розробників часто популярні сучасні, так звані «гнучкі» технології управління проектом. У них є безліч переваг, але є і пов'язані з ними складності. Дуже важливо зрозуміти як ви будете працювати і домовитися про це з клієнтом.
• скласти список ризиків
  І вирішити що робити з кожним: прийняти, передати, застрахуватися, знизити. Головне - побачити.
• зробити все для успіху
  нормальний амбітний розробник захоче домогтися результату. Питання - чи зможе.
  

Основні ризики

Є загальні ризики великого проекту, які є завжди. Є і специфічні для веб-технологій. Ось найзначніші:

• неправильна оцінка завдання виконавцем і занадто велика довіра з боку клієнта.
  Погано навіть не те, що виконавець помиляється в оцінці завдання і своїх сил. Погано те, що він не розуміє що його оцінки дуже погано обгрунтовані.
• ризики, пов'язані з технічним завданням та іншими описами проекту Є дві головні проблеми:
  - клієнт може не розуміти мови технічного завдання і навіть відмовлятися взагалі працювати по ньому. Мовляв, я вам вже все сказав, ви мене почули, тепер робіть.
  - на великий проект виходить технічне завдання в десятки і сотні листів, з безліччю схем і таблиць. Навіть при виключно грамотних, організованих і мотивованих співробітників з обох сторін такий документ буде містити помилки, неточності і протиріччя. Він буде неповний і місцями неактуальний, особливо до кінця проекту. У керівництва обов'язково зміняться пріоритети і з'являться нові ідеї.
  Практика показує що навіть через кілька місяців читання ТЗ в ньому можна знайти пару дивовижних абзаців, істотно змінюють вже сформувалося розуміння.
  Чисто теоретично можна написати вичерпне несуперечливе і докладний ТЗ на проект, але на це буде витрачено величезну час, за яке текст ТЗ застаріє сам проект буде не настільки актуальне.
  
• великі терміни і втрата контакту
  Якщо розробка ведеться великими етапами, до чого логічно призводить спроба зробити «все відразу за великим ТЗ», в процесі роботи втрачається людський контакт між сторонами, багато деталей забуваються, замовник втомлюється чекати і відчуває швидше негатив ніж смакує успіх. Цей ризик лежить не стільки в раціональної сфері, скільки в емоційній, і тому він небезпечніше.
  Його наслідки - труднощі при прийманні, неконтрольований потік побажань, які замовник вважає помилками або логічними вимогами, а виконавець - чистими «хотєлками».
  Цей ризик в результаті загрожує не тільки проекту, але і відносинам між сторонами.
  Цей ризик частково реалізувався в нашому проекті Доміно. Ми робили його більше року, і за цей час багато чого змінилося. На наш погляд, краще було запустити спочатку один найскладніший розділ (наприклад Авто), обкатати на ньому загальний механізм і потім розвиватися. Замовник же вважав за краще дізнатися ціну і термін на «все відразу», хоча багато чого не було готове до такого великого етапу. В результаті було втрачено багато часу, нервів і грошей.
  
  
• зміна вимог і ціна розвитку
  Зміни в проекті це абсолютно нормально для клієнта, для бізнесу, для життя. Нічого залізобетонно усталеного в реальному житті немає. Незалежно від того, яку методику управління проектом ви вибрали - зміни будуть.
  Можливо, договором або практикою відносин їх вдасться мінімізувати або навіть задавити зовсім, але це протиприродно. І кожен наступний день проекту до запуску буде тільки збирати ці зміни
  Для розробника же робота в умовах мінливого завдання подібна гонці Ахіллеса за черепахою: близько, а наздогнати не вдається.
  Є кілька способів роботи з таким ризиком, вибір між ними залежить від проекту і від відносин клієнта з розробником.
  Загальна ж рекомендація - етапи менше, запуск швидше.
  При поганій роботі з цим ризиком можуть бути відразу 2 наслідки:
  - проект завжди готовий на 90%,
  - ціна розвитку (в часі, грошах, нервах стає неприйнятно високою: якість страждає, приймаються одномоментні рішення, тестування відсутня).
  
• реальний обсяг даних і продуктивність
  Окрема велика задача, про яку часто забувають або роблять поверхнево - протестувати проект повністю на реальний обсяг даних, користувачів, переглядів; знайти і усунути всі вузькі місця в проекті.
  Таке тестування навантаження не дуже складно технологічно, але вкрай корисно для майбутнього.

Ключове питання прийняття рішення

При створенні проекту найважливіше це люди, які будуть за нього відповідати. Ніякі технології не замінять мізків і бажання вирішувати питання проекту.

Які це мають бути люди? Вони повинні:

• мати досвід в таких завданнях (критерій розміру проекту)
• зрозуміють ідею і «загоряться» їй, захочуть займатися проектом
• зададуть вам такі питання, які ви самі собі не задавали
• будуть вам симпатичні. Ви багато будете спілкуватися з цими людьми, і якщо емоційний контакт відсутній, проблем не уникнути

Можливо, такий розробник здається вам суперменом, ідеальним підрядником, якого немає в природі? Може і так. Але взагалі кажучи, пристойних команд веб-розробників багато, і вибір є.
Потрібно просто його зробити, причому зробити усвідомлено.

Технологія взаємодії: ідеал і реальність

В теорії все просто.

• Замовник не хоче ніякого «напрягу». Він хоче поставити задачу, причому не технічною мовою, а мовою бізнесу.
• Він хоче що розробка велася швидко і без помилок, а результат задовольняв всім вимогам, у тому числі і не висловленим явно.
• Замовник всім видам спілкування віддає перевагу телепатію і схильний у всіх помилках розуміння звинувачувати Виконавця.

У його логіці все вірно.

Виконавець налаштований абсолютно інакше.

• Він чекає щоб замовник чітко поставив завдання і був здатний швидко давати відповіді на специфічні питання.
• Розробники будуть пропонувати свої варіанти, але чекають, що остаточні рішення прийме розумний і відповідальний контактер з боку клієнта.
• Виконавець всіх видах спілкування віддає перевагу паперове докладний несуперечливе завдання, бажано написане для нього або навіть самим виконавцем.
• Рішення всіх проблем взаєморозуміння такий розробник бачить лише через пошук відповідного пункту в ТЗ.

У його логіці все вірно.

Очевидна суперечність в пріоритетах і передумови для конфлікту.

На практиці все інакше.

• Замовник рідко готовий дати ту інформацію, яка об'єктивна потрібна для проекту. Змінюється не тільки технічна сторона вимог, а й розуміння бізнес-результату. Часто в ході проекту в найбільш непередбачуваний і незручний момент змінюються ключові співробітники замовника.
• Виконавець (під тиском замовника або від власної недосвідченості) рідко має запас по термінах і грошей на реалізацію ризиків. Якщо в малих проектах така стратегія ще життєздатна, то в великих, коли ризиків багато і частина з них точно реалізується, це вкрай небезпечно.
• Названі без запасу терміни і вартості потім складно поміняти, і вкластися в них не вийде якщо хоч щось піде не так.
• Майже виключено щоб розробник тримав напоготові програмістів щоб включити їх в проект. Швидше за все, люди будуть братися з інших робіт, часто з накладенням завдань. Це все вкрай ускладнює планування ресурсів і підвищує вимоги до дотримання термінів.
• А терміни в великих проектах майже завжди зриваються.

Часто протиріччя призводять до конфлікту.

Майже завжди у великому проекті реалізується хоча б частину ризиків, і майже завжди він йде не за узгодженим планом, а в режимі ручного управління.

У нашому проекті Доміно реалізувалися повною мірою ризики заміни контактера, інтеграції з зовнішніми системами, ризик довгих етапів і накопичення змін і частково - ризик великого ТЗ.

Оцінка і планування проекту

Я вже згадував ситуацію, коли один і той же проект цілком осудні розробники за технічним завданням оцінювали в різний час і вартість, і розкид оцінок був майже в 100 разів. На перший погляд причина проста - розробники жадібні ідіоти недостатньо досвідчені і помиляються.

Насправді все складніше. Навіть при наявності досвіду і знань точність оцінки проекту по ТЗ, особливо короткому, вкрай низька.

Якщо ж паперового виразного документа з описаними обмеженнями немає, вартість сміливо можна брати «зі стелі»: все одно помилитеся.

Це об'єктивна реальність, що спочатку проекту ніхто не знає його вартості і строків запуску. Існуючі науково і статистично обґрунтовані методики вкрай слабкі і на практиці малозастосовні.

Що ж можна зробити щоб проект вийшов (інтерес замовника) і приніс прибуток (інтерес розробника), а терміни вклалися у відведені рамки (всім хочеться):

• груба оцінка з запасом і детальний план
  Дійсно, можна зробити грубу оцінку, зробити на неї запас в 10 разів на всі ризики відразу (запас здається величезним, проте якщо ризики не аналізувалися, ніхто не знає чи достатній він), а потім скласти детальний план і по можливості не давати замовнику ніякої свободи в перегляді вимог і термінів.
• спочатку ТЗ, потім оцінка
  Можна укласти окремий договір на написання детального ТЗ. Це варто 10-30% ціни самої розробки. Проблема в тому, що клієнту зазвичай не подобається що він оплачує ТЗ, яке, на його погляд, потрібно тільки розробнику. Крім того, велике і докладний ТЗ це само по собі окремий ризик.
• розробка невеликими порціями
  Цей підхід стає все більш популярним. Розробка ведеться невеликими порціями тривалістю від 2 тижнів до 3 місяців, завдання на які не дуже великі. Оплачується кожна порція, кожна порція запускається і розширює можливості проекту. Технологія хороша тим, що у клієнта завжди є продукт, яким можна користуватися. Немає багатьох ризиків: втрати контакту, великого ТЗ, відсутність тестування. Є й мінуси: ніхто не знає скільки порцій потрібно, яка буде в підсумку вартість і термін розробки. Клієнту часто це не подобається.
  Втім, це симетрично: розробник ніколи не знає всієї завдання, що часто йому не подобається.

Всі технології оцінки і планування великого проекту мають свої недоліки, і ваш вибір повинен визначатися суттю проекту та відносинами із замовником.

Договір і правила гри

Парадокс в тому, що більшість розробників застосовують стандартний договір ні про що. Такий договір не фіксує терміни, зобов'язання, поділ відповідальності, форму подання матеріалів та інше.

За недавно опублікованому дослідженню, 30% сайтів робляться взагалі без договору.

Якщо при створенні сайтів-візиток це можна пробачити, але проекти на тисячі людино-годин робити по слабкому договором просто не можна.

Отже, яким повинен бути договір:

Не потрібно автоматизувати бардак

При проектуванні сайту, продумуванні інтерфейсу, логіки і деталей нормальний аналітик, менеджер буде пропонувати свої варіанти. Спростити логіку, змінити послідовність кроків, переглянути правила.

Це не тільки технічні або дизайнерські зміни, вони будуть стосуватися і суті процесів, бізнес-логіки.

«Якщо автоматизувати безлад, вийде автоматизований бардак». Чи не Варта.

Чому це відбувається? Сторонній аналітик це «свіжа голова», яка бачить не зовсім логічні або НЕ однакові елементи проекту і може запропонувати своє.

З одного боку, такі зміни часто вкрай корисні, так як роблять проект простіше, його запуск швидше, а підтримку дешевше. З іншого, тільки представник бізнесу, кінцевий замовник може прийняти зміну, оцінивши його зі своєї точки зору.

Наприклад, в групі газет Доміно Волгоградські і волзькі газети застосовують істотно різні способи розрахунку ціни оголошення. Якщо їх не привести до одноманітності, фактично будуть потрібні два різних інтерфейсу подачі, що заплутає людей. А якщо міняти формули, змінюються і фінансові показники і налагоджена схема роботи.

Великий проект це і економіка, і політика

Розробник повинен пропонувати, Замовник не дивуватися і розглядати пропозиції всерйоз, і всі повинні думати про якість проекту. Парадокс, що зазвичай всі хочуть успіху, але настільки по-різному його представляють і настільки не вміють говорити один з одним, що проблема взаємодії може все зіпсувати навіть при відсутності серйозних фактичних розбіжностей.

документування завдання

Документи - важлива частина організації роботи. Мені доводилося стикатися з проектами, де загальне число регламентів, інструкцій, специфікацій сягала кількох десятків.

Документи це не панацея, і універсального рецепта тут немає. У чому специфіка великого проекту:

• багато інформації
• складність висока
• деталі спочатку невідомі, а потім йде уточнення.

Яку схему ми застосували в проекті Доміно, і вона добре спрацювала:

• коротка постановка задачі в договорі. 6 аркушів тексту, де вказані обмеження: не більше 30 типів оголошень, не більше 10 форматів файлів обміну, не більше 300 полів у всіх формах введення даних. Ці обмеження дуже важливі
• власне технічне завдання ми робили на базі Axure, де створювалися живі клікабельні макети, кілька діаграм, які документують зміну станів оголошень
• текст ТЗ писався, читався, обговорювалося в google docs

ТЗ вийшло хоча і дуже великим, але зате наочним і колективно обговорювалося в процесі написання і редагування.

Відстеження процесу розробки

Після закінчення виконання завдання підписано і розпочато виробництво, деякі речі є просто необхідними:

• діаграма Гантта, де треба відзначати реальні і фактичні терміни
• багтрекер, куди має обмежений доступ і Закачика
• регулярні зустрічі з клієнтів (особливо якщо проект робиться одним величезним шматком)
  

Що було б вкрай корисно, але на жаль ми не зробили цього

• неминучі зміни в ТЗ, викликані виправленням помилок, уточненнями (наприклад, додали приватного будинку поле підвал) треба фіксувати в листі змін. У нас вони виявилися розкиданими по пошті.
• кожен здаваний етап потрібно перевіряти тестами, бажано автоматичними. І самі тести потрібно готувати до реалізації.

Здача проекту. Тестування навантаження.

При здачі проекту завжди роблять для користувача тестування, іноді unit-тести коду. Ми вважаємо що ще один вид тестування екстремально важливий: навантажувальний.

Розповім на прикладі Доміно:

• прямо в договорі ми записали вимоги до роботи сайту на разделяемом хостингу: 200 тисяч переглядів на добу (приблизно 3 перегляду в секунду), середній час генерації сторінок до 0.5 с, частка помилок 50? не більше 1%
• специфіка проекту в тому, що дані дуже інтенсивно оновлюються і механізми кешування працюють не дуже ефективно
• при здачі проекту ми провели тест (хостинг Timeweb, тариф Eterno). Середній час генерації було близько 0.2 секунд, помилок 500 не було взагалі. 200000 переглядів сайт витримав легко
• показово що в ході тесту було знайдено близько 10 вузьких місць в коді, які зажадали переробки. Усунення цих проблем дало приблизно дворазове скорочення.
• коли вирішили переїхати на окремий сервер з хостингу, ці ж механізми проведення навантажувального тестування допомогли швидко вибрати кращий варіант.

Парадокс великих проектів

Я вважаю що робити проект як набір етапів, кожен з яких оцінюється і запускається окремо - найкраща практика. Це кращий варіант і з точки зору планування, і якості результату, і для бізнесу.

Для клієнта зазвичай все доводи переважує єдиний плюс варіанти «один договір, одне ТЗ, один етап» - відразу зафіксована дата запуску і бюджет.

Печаль в тому, що термін витримати не вдається зі зрозумілих причин (затягування погоджень, реалізація ризиків, обробка побажань), і страждає замовник.

Відповідно проект через розтягування строків виявляється значно менш прибутковим ніж планувалося, і страждає розробник.

Парадокс в тому, що ризики при поетапній роботі менше, і шансів отримати якісний результат вище, незважаючи на відкритий бюджет і дату закінчення проекту.

Окремо треба сказати про цю саму «дату закінчення».

Сучасний проект, створений для бізнесу, постійно змінюється. І ніякої фінальної дати просто немає. Є поточний стан безперервного зміни.

Висновки

Великий проект не такий страшний як може здатися. Все можна вирішити, якщо у замовника і розробника є здоровий глузд, досвід і бажання вирішувати питання.

Ми вважаємо, що:

• робота етапами - кращий варіант;
• обмін даними з зовнішніми системами потрібно робити і тестувати на самому початку проекту;
• працювати над завданням потрібно колективно і «в прямому ефірі» через Google Docs;
• великий проект це завжди політика, і він завжди істотно змінює бізнес;
• і пам'ятайте: ваш наступний проект не повинен перевищувати попередній більш ніж в 2 рази.

І ще висновок

Замовник повинен розуміти що в проекті йому належить робити дуже багато. Потрібно буде виділити співробітника, який буде мати знання, компетентність і право приймати рішення по проекту.

Цей співробітник повинен буде виділяти на проект багато часу, можливо весь робочий день.

І все вийде.

Оцініть статтю: