Підготовка веб-розробки та весь робочий процес проекту

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

Що я шукаю, це:
1. Підготовка / планування, яке, як правило, робиться перед початком розвитку, як тільки ви точно знаєте, що потрібно будувати.
2. Зі свого досвіду, будь ласка, дайте мені відгуки / пропозиції щодо процесу, який я слідкую зараз.

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

Зараз я слідую за цим процесом:
1. Оцініть масштаби проекту та спробуйте зрозуміти, що вони намагаються здійснити за пару зустрічей.
2. Дайте їм грубу фігуру з кульовим парком із цитатою, яка загалом описує, що вони очікують отримати від проекту, я намагаюся бути конкретним щодо особливостей, але, я не вкладаю занадто багато часу на це, тому що я знаю клієнт може просто просити котирування, а насправді не конвертувати.
3. Я дотримуюся пропозиції Джеффа Етвуда щодо оплати та роботи:

15% оплата - вперед перед початком будь-якої роботи
Під час цієї фази робиться макет HTML кінцевого веб-сайту, блок-схема (з yEd ), яка описує веб-сайт якомога детальніше та документ, в якому згадуються інші функції, яких немає у блок-схемі потоків. . Це робиться, вивчивши всі деталі проекту та доопрацювавши біти, які впишуться, та інше, що надто багато роботи для впровадження за домовленою ціною. Оскільки особливості не обговорювались раніше, їх частина також є більш-менш переговорним питанням щодо того, що вони дійсно отримають. Оскільки це проект з фіксованим бюджетом, там потрібно встановити вимоги, інакше моя ціна продовжує знижуватися, оскільки додаються нові функції
Також доопрацьовується кольорова схема, дизайн-каркас та PSD-дизайн.

35% оплата - початок розробки
Проект фіксований, почніть розробку. Я розміщую сайт на своєму сервері, де клієнт може отримати доступ до інтерфейсу, але не має доступу до жодного коду.

30% оплати - переключіть код на сервер клієнта / надайте клієнтові серверну інформацію про доступ
до сайту.

20% оплата - через кілька тижнів після запуску сайту з'являються усі помилки.

Запитання:
1. Коли ви точно знаєте, що збираєтеся будувати, яке планування ви б зробили, перш ніж розпочати кодування?

2. З вашого досвіду, які частини всього процесу ви б зробили по-різному?

Чудові бали для обговорення!

Для отримання кваліфікації - я працюю в проектах веб-розробок BIG в оборонній промисловості. Як правило, у нас працює команда з 10-40 людей, які підтримують єдиного замовника, проекти минулих років, а у замовника є і гроші, і високі вимоги. Тож пробіг може змінюватися - ви не хочете перепланувати!

1 Як тільки ви точно дізнаєтесь, що збираєтеся будувати, яке планування ви б зробили, перш ніж розпочати кодування?

Це після розділу 15%, на початку 35%, так?

• Визначте цільовий веб-сервер та мову
• Вирішіть питання зберігання даних - XML, база даних, яка база даних?
• Вибирайте основні API - збереження даних, GUI, ведення журналів, введення залежностей тощо.
• Вирішіть механізми входу - з огляду на ризики та інформацію, яку ви намагаєтесь захистити. Може включати механізми оплати.
• Сплануйте архітектуру високого рівня та конвенції про іменування
• Виберіть порядок розгортання функцій, щоб ви знали добре місце для початку
• Визначте стратегію тестування та, якщо застосуємо, автоматизовану рамку тестування
• Налаштування системи CM

2 З вашого досвіду, які частини всього процесу ви б зробили по-різному?

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

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

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

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

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

Переконайтеся, що вони підписуються у межах дії! Компанії, які наполягають на фіксованій ціні і відмовляються виходити із сфери застосування, - БАГІ КЛІЄНТИ, і ви не хочете витрачати на це свій час. Ви завжди програєте.