Як розробити програмний продукт швидше та дешевше, не допустивши при цьому великої кількості помилок

Дмитро Сікорський, власник та керівник компанії UBRAINIANS, в колонці для AIN.UA розповідає, що необхідно зробити до того, як підписувати договір про розробку програмного забезпечення, щоб у ньому була вказана якомога менша сума, та щоб (майже) нічого не забути і зрештою отримати продукт, що вирішує проблему бізнесу оптимальним шляхом.

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

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

З чого все починається

Зазвичай, ви відчуваєте проблему й хочете її усунути.

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

Інший приклад. Компанія, що надає в оренду легкові автомобілі. Через ріст кількості клієнтів ставало все складніше контролювати процес: які автомобілі наразі вільні чи звільнюються найближчим часом, які з них вже заброньовані й ким, які пошкоджені (як, ким і коли) чи потребуються сервісу (якого саме — необхідна історія). Також, потрібно було друкувати все більше і більше документів (вручну вносити дані у шаблони), готувати фінансові звіти тощо. Це потрібно було автоматизувати до того, як воно стане обмеженням для росту бізнесу.

Отже, не беремо до уваги проблеми, гіпотези щодо їх вирішення, які привели вас до необхідності щось розробити, та їх перевірку. Просто факт: така необхідність наразі існує.

Скільки приблизно коштує проєкт?

Зрозуміло, що перше питання, яке у вас одразу виникає, це вартість розробки. Я думаю, що з цього починається більше 90% звернень до нас. Але як можна оцінити невідомо що?

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

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

• Краще йти від загального до деталей. Рекомендую на початку декількома реченнями описати всю суть проєкту. Поверхневе резюме того, що вам потрібно. Так, щоб одного погляду було достатньо, щоб зрозуміти, із чим доведеться мати справу. Наприклад:

«Мобільний застосунок під Android та iOS для замовлення піци та панель керування для нього.»

Або.

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

Або.

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

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

• Далі необхідно розповісти, які типи користувачів будуть у вашій системі, та які можливості матиме кожен із них (це має назву «сценарії використання»). Наприклад:

«1. Збиральник заходить у застосунок використовуючи ім’я користувача і пароль, які надає йому адміністратор.

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

3. Збиральник складає у коробку деталі та ставить відповідні позначки у чеклісті.

4. Коли складання деталей завершено, збиральник фотографує вміст коробки за закриває їх.»

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

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

Мені також подобається приклад із багатомовністю. Зазвичай, якщо продукт розробляється для ринку, де є лише одна мова (наприклад, англійська), то з точки зору простоти, ефективності та швидкості роботи програмного забезпечення буде вірним зробити його одномовним. Але якщо пізніше буде прийнято рішення про вихід на інші ринки і виникне необхідність у локалізації, доведеться вносити зміни на всіх рівнях (для звичайного мобільного застосунку це: база даних, серверний застосунок з API, мобільні застосунки під Android та iOS, вебсайт). Якщо на цей момент продукт уже буде використовуватись, необхідно буде забезпечити сумісність нової та старої версій. Це досить складно, довго й дорого. А головне, що безглуздо. (Але й робити усе багатомовним наперед завжди теж неправильно, оскільки це робить програмне забезпечення складнішим та повільнішим.)

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

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

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

Наприклад, так почалася багаторічна співпраця з одним із наших клієнтів — мережею магазинів взуття. Їх проблема полягала в тому, що кожного дня необхідно було фотографувати та додавати на сайт десятки пар взуття. Для цього потрібно було створювати Excel-файл, копіювати всі характеристики кожної пари у відповідні клітинки (включаючи й назви файлів з фотографіями, через кому). Кожну фотографію необхідно було окремо обробляти та робити квадратною.

Далі цей Excel-файл за допомогою спеціальної програми конвертувався у файл імпорту, який розумів інтернет-магазин, і вже він завантажувався туди. На це йшов цілий день, постійно траплялись помилки. Коли ми обговорили це, виявилось, що достатньо написати маленький застосунок, що дасть змогу просто відсканувати штрихкод на коробці, підтягнути зі складської системи дані про пару (їх туди заносили при отриманні товару), та зробити п’ять фотографій, що автоматично будуть оброблені та прив’язані до цього товару. А далі, зробивши це для всіх товарів, — просто натиснути кнопку «Завантажити на сайт». І все. Те, що займало цілий день, тепер займає 20-30 хвилин. І без помилок.

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

Сценарії використання, прототипи та технічне завдання

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

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

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

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

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

Раніше ми починали кожен проєкт із того, що, зібравши від клієнта вимоги та обравши разом із ним найкраще рішення, розробляли прототипи (чорно-білі малюнки екранів; увесь набір можливостей, але без дизайну) майбутніх інтерфейсів. Це давало непогані результати, оскільки все одразу ставало наочним. Але у деяких випадках було складно зрозуміти, чи все ми врахували. Тому часто бувало так, що вже на етапі написання технічного завдання чи розробки дизайну ми згадували про щось важливе, приходили нові ідеї, і потрібно було вносити зміни у вже затверджені прототипи. (А інколи, на жаль, логічні помилки доводилось виправляти навіть на етапі програмування.)

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

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

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

Після цього ми розробляємо прототипи усіх майбутніх інтерфейсів. Ми робимо їх просто у вигляді чорно-білих картинок. Часто їх ще роблять інтерактивними, щоб можна було натискати «кнопки» та переходити між екранами. Ось приклад прототипу екрану для входу у застосунок для замовлення піци:

Як бачите, все стає доволі очевидним.

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

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

Точна оцінка та вибір розробника

Тепер коли ви маєте повноцінне технічне завдання, можна переходити до точної оцінки проєкту та вибору розробника для його реалізації. Це вже окрема тема, можу лише порадити розбити весь проєкт на невеликі шматки так, щоб кожен із них займав не більше 2-8 тижнів, та приймати й оплачувати ці проміжні результати окремо (поетапно отримуючи всі розроблені матеріали). Так ви завчасно зможете помітити що щось іде не за планом на навіть змінити розробника не втрачаючи все.

Автор: Дмитро Сікорський, власник та керівник компанії UBRAINIANS