Перейти до основного вмісту

Аналіз бізнес-процесів перед розробкою

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

Як проходить проєкт

Чотири етапи — від аналізу до передачі

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

  1. Аналіз

    Розбираємо ваш процес і вимоги

    Розмова про програмне забезпечення і про те, що воно має робити, а потім розбір того, як робота відбувається зараз. Якщо у вас є технічне завдання чи специфікація, ми розбираємо і їх.

    Що відбувається

    • хто які дані вводить і де
    • які дані вводять більше ніж один раз
    • кроки, що відбуваються поза будь-якою системою
    • де робота зупиняється або залежить від однієї людини

    Що ви отримуєте

    • Схема вашого поточного процесу
    • Виявлені в ньому проблемні ділянки
    • Початковий план програмного рішення
    • Прототип, якщо про нього домовилися
  2. Проєктування

    Проєктуємо рішення під вашу компанію

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

    Що відбувається

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

    Що ви отримуєте

    • Рішення, задокументоване до початку розробки
    • Погоджені обсяг, терміни й ціна
  3. Розробка

    Розробляємо й тестуємо

    Розробляємо програмне забезпечення, визначене аналізом. Орієнтовно перший прототип займає близько тижня, а робоча версія — близько місяця.

    Що відбувається

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

    Що ви отримуєте

    • Перший прототип
    • Робоча система, протестована перед релізом
  4. Передача

    Передаємо все повністю

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

    Що відбувається

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

    Що ви отримуєте

    • Робоча система та її вихідний код
    • Репозиторій і облікові записи інфраструктури
    • Коротка інструкція для тих, хто нею користується, і дзвінок для передачі системи

Технічне завдання

Як скласти технічне завдання на розробку програмного забезпечення

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

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

  1. Мета й проблема

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

  2. Хто користуватиметься і в якій ролі

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

  3. Поточний процес крок за кроком

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

  4. Інструменти й дані

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

  5. Що має змінитися

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

  6. Обов’язкове й бажане

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

  7. Обмеження

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

  8. Доступи й чутливі дані

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

Що допомагає

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

Чого варто уникати

  • Малювати екрани й кнопки, поки процес не зрозумілий.
  • Перелічувати всі функції з однаковим пріоритетом.
  • Замовчувати обхідні шляхи — додаткову таблицю чи чат, де відбуваються погодження. Вони часто показують, де саме проблема.
  • Чекати на завершений документ. Щоб почати, достатньо першої версії своїми словами.

Приклад

Приклад технічного завдання

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

Завантажити шаблон

Ті самі вісім пунктів із підказкою під кожним. Заповніть його або використайте як чекліст для листа — для початку достатньо будь-якого варіанта.

Ілюстративний приклад · вигадана компанія

Обробка замовлень для оптового дистриб’ютора

Мета й проблема

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

Хто користуватиметься і в якій ролі

  • Координатори продажів (2): вносять і підтверджують замовлення.
  • Працівники складу (4): комплектують, пакують і позначають замовлення як відвантажені.
  • Бухгалтер (1): рахунки та стан оплат.
  • Керівник компанії: щотижневий огляд замовлень, відвантажень і прострочених рахунків.
  • Клієнти: зараз вони пишуть листи, щоб дізнатися про замовлення; ми хотіли б, щоб вони бачили його статус.

Поточний процес крок за кроком

  1. Клієнт надсилає замовлення поштою — довільним текстом або власним PDF.
  2. Координатор вносить його в таблицю замовлень і перевіряє залишки в другій таблиці.
  3. Координатор надсилає складу список комплектації поштою.
  4. Склад відвантажує замовлення й відповідає листом.
  5. Бухгалтер створює рахунок у сервісі виставлення рахунків на основі таблиці.
  6. Оплати відстежують у третій таблиці.

Інструменти й дані

  • Google Sheets: замовлення, залишки й оплати, близько 4000 рядків замовлень на рік.
  • Хмарний сервіс виставлення рахунків, від якого залежать звіти бухгалтера.
  • Спільна поштова скринька для замовлень.
  • Сайт кур’єрської служби, де транспортні етикетки створюють вручну.

Що має змінитися

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

Обов’язкове й бажане

  • Обов’язково: введення замовлень, перевірка залишків, список комплектації, статус відвантаження й рахунок, створений із замовлення.
  • Бажано: статус замовлення для клієнтів, зчитування замовлень із пошти, кур’єрські етикетки.

Обмеження

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

Доступи й чутливі дані

  • Імена клієнтів, адреси й ціни — комерційно чутлива інформація; ми хотіли б підписати NDA.
  • Можемо надати доступ до копій таблиць і тестовий обліковий запис у сервісі виставлення рахунків.

Додаток: два приклади замовлень і поточні таблиці, без даних клієнтів.

Що нам надіслати

Технічне завдання своїми словами або кілька абзаців через форму нижче. Приклади документів і знімки екрана допомагають — без чутливих даних.

Скільки це коштує

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

Скільки це триває

Терміни визначаємо за результатами аналізу. Орієнтовно перший прототип займає близько тижня, а робоча версія — близько місяця.

Як почати

  1. Опишіть задачу

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

  2. Перший аналіз і початковий план

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

  3. Ціна вашого проєкту

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

Зв’язатися з нами

Розкажіть, яку задачу потрібно вирішити

Ми відповімо, розпитаємо про ваш поточний процес і запропонуємо, з чого почати. Якщо на цій сторінці немає відповіді на ваше питання, поставте його тут.

Відповідаємо протягом 24–48 годин, у порядку надходження запитів.

Або напишіть нам на hello@healed-code.com

Бюджетнеобов’язково
Оберіть діапазонПоки не знаюДо 1000 $Від 1000 до 5000 $Від 5000 до 15 000 $Понад 15 000 $
Бюджет
Термінинеобов’язково
Оберіть терміниЯкнайшвидшеПротягом місяцяВід одного до трьох місяцівПоки розглядаю варіанти
Терміни

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