Як не втрачати гроші і час при розробці програмного продукту?

Дмитро Сікорський, власник, керівник, 14 вересня 2023

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

Дизайн і технічна документація

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

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

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

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

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

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

Інший приклад. Ви розробляєте систему обробки замовлень. Що буде, якщо зникне інтернет? За замовчуванням, ви просто не зможете приймати нові замовлення і переглядати існуючі. Одна справа, зробити можливим перегляд або відкладене створення замовлень в оффлайні, а зовсім інша — редагування існуючих замовлень, тому що різні користувачі можуть редагувати одне й те саме замовлення поки немає звʼязку, а потім ці зміни потрібно якось поєднати, і такі речі потребують взагалі спеціальних архітектурних рішень. Якщо не закладати це одразу, пізніше може бути простіше просто взяти і переписати роботу з замовленнями з нуля.

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

Команда

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

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

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

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

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