Усі стартапи пов’язані з певним ризиком, особливо коли у вас є ідея, але немає технічного співзасновника. Atlas — це індивідуальна компанія з розробки програмного забезпечення, яка в минулому виступала саме таким відсутнім технічним співзасновником для стартапів. І ось наші напрацювання щодо того, як стартапи можуть зменшити ризики проєктів з розробки програмного забезпечення, звернувшись до компанії з розробки як до свого технічного співзасновника.
Atlas працює понад 10 років, і за цей час ми з’ясували, що працює, а що — ні, коли мова йде про зменшення ризиків провалу програмних проєктів. Ми надаємо перевагу гнучкій (agile) методології в індивідуальній розробці, і нижче пояснимо чому. Водночас важливо розуміти, що гнучкий підхід до розробки програмного забезпечення може в деяких випадках виявити проблеми з управлінням проєктом, але не вирішує їх.
Перш ніж заглиблюватися у переваги гнучкої розробки, давайте розглянемо традиційний метод, який найчастіше запитують клієнти Atlas — модель «водоспаду».
Модель «водоспаду» — це послідовний (неітеративний) процес проєктування, що використовується в процесах розробки програмного забезпечення. У ній прогрес відбувається рівномірно вниз (як водоспад) через фази: задум, ініціація, аналіз, проєктування, створення, тестування, впровадження у виробництво та підтримка. Вона виникла в промисловості та будівництві — суворо структурованих фізичних середовищах, де зміни після запуску надзвичайно дорогі або взагалі неможливі. Оскільки на той час ще не існувало формалізованих методологій розробки програмного забезпечення, цю орієнтовану на апаратне забезпечення модель просто адаптували для програмної розробки.
Wikipedia
Попри всі свої недоліки, модель «водоспаду» успішно застосовувалася в різних галузях, зокрема у військовій справі, космічних розробках і системах охорони здоров’я. Це високорегульовані, контрольовані сфери, де рішення приймаються експертами, і від них буквально залежать людські життя. Там не допускається підхід на кшталт:
Ой, не вийшло — заховали тіла і спробували ще раз.
Ця ілюстрація наочно демонструє модель «водоспаду». Ви одразу помітите: як тільки процес розробки програмного забезпечення розпочався, повернутися на початок вже неможливо — і в цьому полягає головна проблема цієї моделі. Багато проєктів зі створення застосунків, які запускаються цьогоріч і запустяться наступного, ініціюються та фінансуються людьми, які не розуміють усіх складнощів розробки програмного забезпечення і не знають наперед усіх своїх вимог.
Скільки б технік збору вимог ми не використовували в Atlas, щоб отримати вичерпні специфікації від замовників, якщо власник продукту сам не знає, чого він не знає — він не зможе надати правильну інформацію. І це не його провина — на жаль, це просто факт.
А тепер уявімо собі ситуацію: команда розробників ігнорує всі вищезгадані проблеми, бо клієнт розмахує перед ними пучком грошей. Вони збирають настільки повні вимоги, наскільки це можливо, і стрімголов кидаються у вир моделі «водоспаду», тримаючись за функціональну специфікацію розміром з повну «Енциклопедію Британіку», мов за рятівний круг. Клієнт стоїть поруч із цим водоспадом (тобто моделлю), збуджений і впевнений, що вони разом із командою розробки врахували абсолютно всі вимоги. І тут — БАХ! — команда досягає дна водоспаду й починає тонути. Виявляється, у функціональній специфікації були діри, і скільки б не загрібали веслами чи не вичерпували воду — це вже не допоможе.
До того ж клієнт побачив попередню версію застосунку — і тепер у нього ціла купа правок, які він хоче внести в останню мить.
І от, під тиском фіксованого дедлайну й бюджету, команда розробки змушена працювати ще інтенсивніше, щоб усе встигнути. У результаті вони створюють нефункціональний або мінімальний застосунок, який формально відповідає техзавданню клієнта, але міг би бути значно кращим — аби лише був обраний більш ітеративний підхід.
Одна з головних проблем методу «водоспаду» — відсутність гнучкості. Сучасні потреби в розробці програмного забезпечення постійно змінюються, тому дедалі частіше потрібен більш динамічний підхід. Неможливість повертатися до попередніх етапів призводить до марнування ресурсів і втрати шансів на оптимізацію чи нововведення. І саме тут на сцену виходить agile.
Agile побудований на принципах безперервного вдосконалення, співпраці та гнучкості, що дозволяє командам адаптуватися в процесі реалізації проєкту й гарантує, що кінцевий продукт краще відповідатиме змінним потребам клієнта.
А тепер переходимо до гнучкої методології, зображеної на ілюстрації. Чи вважаєте ви, що agile — це шлях уперед? Насправді agile може бути не менш небезпечним, якщо впроваджується неправильно, і точно не є універсальним рішенням усіх наведених вище проблем.
Щоб працювати ефективно, agile усе одно вимагає загального плану, а також чіткого планування кожної ітерації до початку розробки. Водночас гнучка методологія справді забезпечує спільну роботу над програмним забезпеченням і дозволяє більш рівномірно розподілити ризики між обома сторонами. Іншими словами, команда розробників може знову кинутися у вир, але цього разу клієнт буде з ними в одному човні — допомагаючи веслувати й вичерпувати воду. Усе тримається на співпраці.
Крім того, agile сприяє формуванню культури прозорості та постійної комунікації між командою розробників і клієнтом. Це означає, що власник продукту активно залучений до процесу розробки: він допомагає спрямовувати проєкт у правильному напрямку, вносити корективи за потреби й гарантувати, що кінцевий продукт буде максимально наближений до його первісного бачення. Така залученість зміцнює довіру й зменшує ризики непорозумінь, які можуть виникнути пізніше в циклі розробки.
Atlas ще у 2011 році перевів більшість своїх проєктів з моделі «водоспаду» на гнучку методологію і надалі ми прагнемо використовувати виключно agile скрізь, де це можливо. Нижче — наші найкращі поради та прийоми, які ми використовуємо для того, щоб усі наші проєкти з розробки програмного забезпечення, незалежно від їхнього розміру та рівня ризику, мали максимальні шанси бути завершеними вчасно і в межах бюджету:
- Якщо до нас звертається клієнт, який хоче створити вебзастосунок, і це його перший такий проєкт або він входить у нову галузь, ми настійливо рекомендуємо почати зі створення MVP (мінімально життєздатного продукту). Намагатися одразу реалізувати застосунок з усіма можливими функціями — це необґрунтовано дорого і зазвичай веде до провалу.
- Час від часу ми рекомендуємо створити proof of concept (прототип концепції). Це особливо корисно, якщо одна або кілька складових вимог до застосунку пов’язані з високими ризиками — через технічну складність або залежність від сторонніх систем.
- Якщо ми створюємо proof of concept, ми показуємо його якомога більшій кількості людей ще до того, як рухатися далі. Якщо застосунок внутрішній — покажіть його вашим співробітникам. Якщо ви плануєте його продавати — покажіть потенційним клієнтам. Так, це потребує часу й зусиль, але набагато дешевше дізнатися на ранньому етапі, що ви рухаєтеся в неправильному напрямку.
- Якщо proof of concept — це надто складно, ми принаймні створюємо wireframes (каркаси інтерфейсу). Ми надаємо перевагу Balsamiq, якщо тільки HTML-прототип не є логічнішим варіантом. Навіть найпростіші каркаси стимулюють уяву власника продукту і змушують замислитися про деталі, які раніше залишалися поза увагою. Оскільки зображення варте тисячі слів, ми обов’язково включаємо каркаси до наших ітераційних планів — вони важко піддаються хибному тлумаченню, а отже знижують ризик неоднозначностей.
- Ми використовуємо клієнтський портал для забезпечення прозорості. Зокрема, ми стежимо за тим, щоб клієнти могли бачити, над чим ми працюємо в поточній ітерації. У Європі стартапи, які хочуть ефективно перевірити свої ідеї, часто звертаються до компаній, що розробляють MVP, аби зменшити ризики та забезпечити ефективне масштабування. Ми додаємо до порталу всі потенційні проблеми для обговорення одразу, щойно з ними стикаємося, а не чекаємо наступної зустрічі.
- До речі, про зустрічі — ми наполягаємо, щоб усі ключові зацікавлені сторони продукту брали участь в усіх зустрічах наприкінці спринту та давали зворотний зв’язок. Ми настільки серйозно ставимось до цього пункту, що включили його як обов’язкову вимогу в наш контракт на гнучку розробку програмного забезпечення.
- Ми ніколи не загрузнемо в незручних договірних обговореннях. Розробка програмного забезпечення — це спільна справа з розподіленими ризиками, і наша угода на розробку програмного забезпечення це відображає. Замість того, щоб обговорювати контракт у деталях, ми завжди краще зосередимося на створенні вашого застосунку.
З agile чи без — ці поради та прийоми вже заощадили нам тисячі годин марної розробки. Сподіваємося, вони стануть у пригоді й вам.
