31 lines
2.7 KiB
Markdown
31 lines
2.7 KiB
Markdown
|
# План обработки заказа
|
|||
|
|
|
|||
|
|
1. Получение/согласование ТЗ по заказу
|
|||
|
|
|
|||
|
|
Для начала любых работ необходимо не только побеседовать с заказчиком, но и согласовать с ним ТЗ, в котором необходимо прописать все тонкости этого заказа как сто стороны клиента, так и с нашей стороны. Нужно минимизировать кол-во "очевидных" моментов с каждой из сторон.
|
|||
|
|
|
|||
|
|
2. "Дробление" ТЗ и выставление цены
|
|||
|
|
|
|||
|
|
Для уменьшения времени и увеличения качества разработки необходимо дробить проект на модули для повторного их использования. Таким образом можно написать код для создания платежных ссылок, а затем этот контейнер использовать ещё в множестве последующих проектов.
|
|||
|
|
|
|||
|
|
3. Разработка API
|
|||
|
|
|
|||
|
|
Перед тем как создавать интерфейс необходимо создать API и прописать к нему документацию для уменьшения кол-ва ситуаций, когда сайт переписывается целыми сегментами, так как инструментарий поменялся.
|
|||
|
|
|
|||
|
|
4. Тестирование
|
|||
|
|
1. Внутреннее тестирование
|
|||
|
|
|
|||
|
|
Перед публикацией кода необходимо провести внутреннее тестирование. Под этим подразумевается не только проверка документации и соответствие ей модуля, но и код этого модуля.
|
|||
|
|
|
|||
|
|
2. Тестирование заказчиком
|
|||
|
|
|
|||
|
|
Это необходимо сделать, так как даже при наличии ТЗ могут существовать функции, которые будут некорректно работать, но мы (как неразбирающие в теме люди) можем этого не заметить.
|
|||
|
|
|
|||
|
|
5. Разработка интерфейса
|
|||
|
|
6. Тестирование
|
|||
|
|
1. Внутреннее тестирование
|
|||
|
|
2. Тестирование заказчиком
|
|||
|
|
7. Приемка
|
|||
|
|
8. Дальнейшая поддержка
|
|||
|
|
|
|||
|
|
Дальнейшая поддержка осуществляется только при запросе модернизации продукта
|