Успішна розробка програмних продуктів Кілька порад

Успішна розробка програмних продуктів: Кілька порад

розробка

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

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

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

Однак як можна розробити таке програмне забезпечення на майбутнє, яке замінить попередні ІТ-послуги? Кілька порад щодо цього у дописі.

Не поспішай

Більшість проектів, на жаль, розпочато з твердження «Це дуже великий проект. Але не поспішайте. Нам не потрібна готова версія протягом двох місяців ".

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

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

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

Для того, щоб мати першу бета-версію програмного продукту, завжди потрібно не менше 9 - 12 місяців.

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

Тож для створення продукту вам швидко потрібно один-два роки.

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

Міцна технологічна база/правильний вибір

Важливий також технологічний підхід.

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

Одним із прикладів є PHP. Ця ІТ-система існує з 1995 року і з тих пір постійно вдосконалюється.

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

Інакше це виглядає з іншими підходами. Наприклад, якщо ви програмуєте за допомогою Node.JS (у статті також скорочений як N), ви можете припустити, що вам доведеться витратити зайвий час, роздумуючи, як вирішити конкретне завдання програмування за допомогою Node.JS.

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

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

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

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

Для середніх проектів (наприклад, корпоративні рішення, які потрібні керованій кількості користувачів) PHP може бути правильним рішенням.

Для великих проектів, в яких багато користувачів одночасно отримують доступ до одного рішення через Інтернет, N може бути правильним підходом.

ASP.NET, Java, Python, Android, iOS - це інші підходи, які можуть підійти в деяких випадках.

Зберігайте документацію

Однією з найбільших проблем програмного забезпечення є ремонтопридатність та безперервність.

Часто майбутнє не розглядається. Такі питання, як:

  • Що якщо іншим розробникам доведеться працювати над цим продуктом?
  • Наскільки зрозумілою є логіка розвитку зовнішнього постачальника послуг?
  • Як реагує програмування на зовнішні зміни, які можуть відбутися в майбутньому?

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

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

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

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

Оплата клієнтів з самого початку

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

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

Це має багато переваг:

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

Альтернатива 1: ангельські інвестори/інвестори

Інша альтернатива - робота з інвесторами.

Найчастіше вам доводиться платити принаймні за прототип зі своєї кишені.

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

Потім ви можете подарувати це інвесторам.

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

Альтернатива 2: від наявного доходу

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

Альтернатива 3: власні гроші

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

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

І якщо весь проект не має успіху, то гроші були витрачені.

Тож радше покладайтесь на альтернативи, згадані на початку.

Щоб його округлити: Система підтримки

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

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

А ще є той факт, що ви можете створити своєрідний відділ продажів для тих, хто запитує, хто ще не платить клієнтам.

Висновок

Основними напрямками успішного програмного забезпечення є:

  1. підняти необхідний час
  2. використовувати правильну технологію
  3. Зберігайте документацію
  4. З самого початку знаходите клієнтів, які платять, або покладайтесь на інвесторів (або фінансуйте за рахунок наявного доходу від інших підприємств)
  5. Вбудуйте систему підтримки та передпродажної системи

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

Flickr.com/ GDC/Jeremy/thethreesisters

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