Сроки приемки проекта со стороны заказчика
УТВЕРЖДАЮ
Руководитель Axelerator
__________________Лукашевич А.Н.
Инструкция №3
Стандарт разработки виджета
Бизнес-процесс оценки стоимости виджета 3
Оценка в деньгах 4
Оценка сроков разработки 4
Оценка сроков сдачи проекта 5
Сроки приемки проекта со стороны заказчика 6
Техподдержка разработки 6
Основные пункты технического задания 6
Прототипирование 7
Правила оформления виджета в каталоге интеграций 7
|
|
|
Дизайн 8
Верстка 9
Разработка 9
Тестирование 9
Сдача заказчику 10
Приемка у разработчика 10
Баги после сдачи проекта 11
Документация API 11
|
|
|
Инструкция по работе 11
Основные ошибки 11
Бизнес-процесс оценки стоимости виджета
После поступления запроса на разработку виджета, первым делом необходимо узнать у старшего и коллег или обратиться в реестр виджетов, были ли ранее подобные разработки. Если да, то взять готовую цену. Если нет, но была оценка, сравнить описание и если подходит, выставить готовую оценку, скорректировав ее под новые стандарты.
Если нет, то приступить к процедуре оценки.
1. Четко сформулировать суть задачи и конечный результат, который необходимо получить.
2. Согласовать это описание с заказчиком. Если заказчик сам давал описание, то проверить его на предмет понимания, адекватности, если надо, задать уточняющие вопросы и дополнить.
3. После согласования с заказчиком предварительного описания, перейти в Asana в раздел “1_Оценка задач по разработке” и на этапе “Новый проект на оценку” поставить задачу. Заголовок задачи должен тезисно отражать суть задачи. Описание задачи должно содержать описание, либо содержать ссылку на объемное описание, если оно выполнено в гугл доке.
|
|
|
Обязательно!!! указать ссылку на сделку в amoCRM.
Указать ответственного разработчика за оценку и срок. Следует помнить, чем раньше будет получена оценка и названа стоимость клиенту, тем дешевле обойдется для компании и менеджера данный проект в любом случае, купит клиент или откажется. И тем выше шанс, что купят у нас.
4. После того, как разработчик приступил к оценке, необходимо передвинуть задачу на этап “На оценке у разработчика”
Если разработчик задал уточняющие вопросы и ответы на них не получается дать быстро или клиент взял паузу, задача перемещается на этап “на стороне клиента”. После получения ответа, задача возвращается на прежний этап.
5. После получения оценки от разработчика, задача перемещается на этап “оценка получена”
6. После того, как клиент купил данную разработку, задача перемещается на этап “Пишем ТЗ ” и к ней добавляется хэштег от воронки “Разработка” с этапом “Новый проект”
7. В случае, если оценка задачи невозможна до написания ТЗ, то задача перемещается на этап “Пишем ТЗ ”
|
|
|
8. Если клиент дал добро. но не оплатил и ТЗ не написано, то перемещаем на этап “Пишем ТЗ” и пишем его. Как только получена оплата, ставим задачу в работу в воронку Разработка.
8. Как только написано ТЗ и разработчик приступил к работе, перемещаем задачу на этап “В работе”
9. Когда разработчик занончит работу, перемещаем задачу на этап “тестирование и доработка”. на этом этапе необходимо протестировать виджет и отправить на исправление выявленных багов. Все комментарии и ссылку на баг-лист прикрепить к задаче в комментариях.
10. После исправления багов, перемещаем задачу на этап “Сдача руководителю”. В задаче на этот момент надо указать все доступы к виджету, где смотреть. Руководитель проверяет задачу
и если не отправляет на доработку, передвигает на этап “Перенос и отладка у клиента”. Если отправляет на доработку, то возвращает на предыдущий этап. На этапе “Перенос и отладка у клиента” аккаунт дает задание разработчику на перенос виджета. После чего уведомляет заказчика о возможности тестирования. Если заказчик не выявил багов, то выставляется акт, если выявил, задача остается на данном этапе до устранения всех багов.
Оценка в деньгах
Окончательная стоимость оценивается в рос. рублях исходя из трудозатрат выраженных в человеко-часах.
Стоимость часа - для конечных заказчиков х и для партнеров у (цены см в прайсе) там же можно воспользоваться готовым калькулятором расчета стоимости
Пример расчета:
Ц=((ТЗ+Ч+Т)*стоимость часа + (Д+В)*стоимость часа)*1,1
где
● Ц - цена (стоимость озвучиваемая заказчику)
● ТЗ - трудозатраты на техническое задание, если ранее они не были оплачены, а ТЗ писали на этапе оценки.
● Ч - часы от разработчика
● Т - часы на тестирование
● Д - часы на дизайн
● В - часы на верстку
● 1,1 - коэф запаса
Пример:
((2+30+3)*1300+(2+2)*1000)*1,1=54450 руб.
Оценка сроков разработки
Р=1,5*(Д+В+Ч+Т)/6
где
● 1,5 - коэф запаса по срокам
● Р - срок разработки в рабочих днях
● Д - часы, которые выставил дизайнер
● В - часы, которые выставил верстальщик
● Ч - часы, которые выставил разработчик
● Т - часы на тестирование и устранение багов (в зависимости от размера виджета, от 2-х до 10 часов) с уведомлением клиента, что к разработке прибавлена стоимость тестирования. Если он хочет, то мы уберем и тестированием будет заниматься он сам. Но только тестирование нашими силами позволит выдать качественный продукт
● 6 - количество рабочих часов в день за минусом часов на оценку и отвлечение.
Пример:
Разработчик выставил 60 часов, Тестировщик - 5 часов, дизайна нет, верстка минимальная и выполняется разработчиком.
Р = 1,5*(60+5)/6=16,25 дней, округляем до целого в большую сторону = 17 рабочих дня - это срок разработки и тестирования с устранением багов, т.е. за 17 дней нужно сделать и поставить на аккаунт заказчика.
В зависимости от загрузки разработчика, можно уменьшать коэф 1,5 до 1,1, но с обязательным уведомлением об этом заказчика в формате: Идем на встречу, будем стараться раньше, но если качество будет страдать, то будем работать по изначальным срокам, где мы учли коэф 1,5.
Оценка сроков сдачи проекта
Х+Дата сдачи = дата старта + Р + 5 + ПЗ
где
● Дата старта - календарная дата рабочего дня, в который стартует разработка проекта
● Р - срок разработки в рабочих днях (см. пункт 3)
● 5 - отладка на аккаунте заказчика - 5 рабочих дней. Это значит, что мы ставим виджет, но еще неделю он может работать со сбоями, так как необходимо откатать только на аккаунте заказчика. Есть случаи, когда сторонние интеграции влияют на разработки других компаний.
● ПЗ - проверка заказчиком (закладываем 3 дня)
● Х - устранение багов после проверки заказчиком, как правило 3-5 дней.
При вычислении даты сдачи, необходимо исключать выходные и праздничные дни.
Пример:
Срок разработки (Р) - 17 рабочих дней.
Дата сдачи с учетом отладки, если стартуем 1 числа
1 число+17+5+3+Х=4 число следующего мес. + Х
Т.е. практически 1 мес - это гарантированный срок сдачи, после которого мы готовы оплачивать штрафные санкции, если затянули. + Х
Т.е., в договоре всегда прописываем дату сдачи, как дату сдачи на тест заказчику.
Сроки приемки проекта со стороны заказчика
Заказчик обязан в 3-х дневный срок принять проект или отправить на доработку, отправив письменно через e-mail объективные причины доработки. Если за 3 дня клиент не принял проект, то он считается принятым по умолчанию и ему выставляется акт выполненных работ. Об этом также важно предупреждать заказчика сразу после подписания договора и оплаты разработки (аванса) путем отправки файла Как мы работаем
Техподдержка разработки
В течение 2-х недель после подписания акта устранение выявленных багов за наш счет. После этого по тарифам компании или на основе платной техподдержки.
Техподдержка оценивается по ставке 1000 руб 1 час.
Стоимость техподдержки:
1000 руб/мес для виджетов до 20 000 руб.
2000 руб/мес для виджетов до 40 000 руб.
5000 руб/мес для виджетов до 80 000 руб.
6000 руб/мес для виджетов до 120 000 руб.
7000 руб/мес для виджетов от 120 000 руб.
Техподдержка включает в себя восстановление работоспособности после обновлений, устранение багов, выявленных в процессе эксплуатации разработки, доработка решения под новые требования в рамках данной суммы, превышение часов оценивается по тарифам компании, установленным на день оценки.
Бесплатная ТП по тикетам на e-mail support@axelerator.bz
Дата добавления: 2019-08-30; просмотров: 65; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!