Розробка та підтримка веб-додатків та сайтів

На цьому етапі Замовник надає нашій компанії всю наявну інформацію про майбутній обсяг роботи, при необхідності, укладання угоди про конфіденційність наданих даних (NDA).

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

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

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

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

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

При написанні технічного завдання найчастіше залучаються фахівці:

• Бізнес-аналітик – розписує основу технічного завдання;
• Програміст - архітектор – програміст з тривалим стажем роботи, який повинен перевірити, чи можливо за допомогою описаних бізнес-аналітиком технологій, створити програмний продукт, чи немає прихованих моментів, які призведуть проект до повної чи часткової переробки та збільшення вартості);
• Дизайнер UI/UX – спеціаліст з інтерфейсів, малює скетчі майбутнього програмного продукту, якщо це необхідно;
• Тестувальник – тестувальник із тривалим стажем роботи, складає вимоги до тестування майбутнього програмного продукту, перелік платформ, дозволу екранів, навантажувальні тести тощо;
• Юрист – перевіряє законність та обґрунтованість документа;
• Інші фахівці (технологи, електронники та інші фахівці, якщо вони потрібні)

До чого призводять помилки у технічному завданні (якщо його розробляти самостійно):

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

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

Доступні такі моделі співробітництва:

Фіксована ціна (fixed price)

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

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

Час та матеріали (time and material)

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

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

Виділена команда

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

На цьому етапі з боку компанії комплектується команда необхідних фахівців. Як правило, це менеджер з ведення проекту, Backed програмісти, Frontend програмісти, UX/UI дизайнер, тестувальники. За потреби можуть бути залучені інші спеціалісти, пов'язані з особливостями проекту.

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

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

Для управління проектом ми використовуємо JIRA на власному сервері, Confluence

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

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

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