Личный опыт работы с экспертом по маркетплейсам Bright Mobile
В марте 2018 года, увидел на профильных площадках, громко заявляющего о конструкторе мобильных приложений «Сервис ПИ» руководителя студии, Гордиенко Дениса. Нам как раз, на тот момент очень было необходимо приложение и сайт для сервисной службы со схожим с «Сервис ПИ» функционалом. Расскажу о своем опыте далее.
Безотносительно темы:
Единая проблема многих заказчиков - посредственный подход к оформлению и проработке деталей проекта, игнорирование и зачастую «юмористическое» отношение к составлению технического задания, в надежде на то, что «вроде всё проговорили значит проект будет соответствовать ожиданиям…» - Нет, он не будет соответствовать ожиданиям.
Вообще никакой проект не будет соответствовать ожиданиям без скрупулёзно составленного технического задания на уровне фанатизма.
Отсутствие фанатизма при составлении технического задания и соблюдении всех формальных процедур возможно, и приходит со временем в процессе длительной работы, когда люди уже достаточно хорошо знают друг-друга, понимают кто что может выдать, каковы компетенции, чего ожидать, с учётом накопленного опыта взаимодействия по текущему/прошлому проекту.
Составление технического задания это всегда больной вопрос для заказчика, потому что разработчик его (ТЗ) ждёт, а никакой заказчик его дать самостоятельно не способен, за редкими исключениями.
Соответственно, если своими силами, или в результате коллегиального обсуждения ТЗ составить не удаётся - лучше его заказать. Да, это отдельная статья расходов, но оно того стоит, т.к.:
Составив раз - это хорошая основа для собственного переиспользования в будущем с поправкой на проект.
В процессе его (ТЗ) разработки, как правило, заказчику и/или исполнителю раскрываются детали о которых они ранее не думали и не учитывали (если составитель не имеет цели что-либо скрыть/умолчать).
Корректное, не расплывчатое ТЗ с чёткими формулировками и техническими/технологическими требованиями однозначно дисциплинирует исполнителя, и с высокой степенью вероятности сильно укрепляет позиции добросовестного заказчика в случае судебных разбирательств или предварительной претензионной работы, и в случае судебного разбирательства существенно повышает шансы на взыскание/компенсацию.
Тоже самое что в п.3, только для исполнителя.
Есть и минусы:
Зачастую такой подход с учётом новых деталей проекта даёт увеличение стоимости проекта.
Наличие ТЗ не предусматривает и не учитывает изменения взглядов заказчика на проект, особенно если разработка занимает продолжительный период времени. Т.е. Если в процессе, условно через полгода заказчику проект «разонравился» - придётся заплатить.
По теме:
Конечно, наверняка за 8 (или сколько там) месяцев материала у вас сильно больше чем эти несколько скриншотов. Соответственно детали скрыты, поэтому что-то конкретное тут сложно понять. Но, если всё что я написал выше не ваш случай, и всё было надлежащим образом оформлено, то нужно более основательно подойти к вопросу и продолжить разбирательства.
Но если в суде ставился вопрос наличия проводимых работ в рамках абонентского обслуживания в принципе, и если либо подписанные акты, либо автоматически принятые например в следствие истёкшего срока возражений по актам - то хз что тут оспаривать. Для арбитража то всё равно, есть текст договора, если фактические обстоятельства - результат решение.
Оснований настаивать на экспертизе я так понимаю у вас не было, в плане того что если вы оспаривали время, то на какие вопросы должен ответить эксперт?
Если речь о технической экспертизе, то это наверное отдельный иск, не об абонентском обслуживании. Опять таки, на какие вопросы должна ответить экспертиза? Т.е. например прописаны некие требования, они не соблюдены и т.д.
Если не было никаких конкретных требований, то экспертиза для вас автоматически в результате обернётся расходами без удовлетворительного результата.
Экспертиза не отвечает просто на вопрос что там в проекте говнокод или не говнокод, т.к. Это неформальное понятие всё таки :)
Чисто по человечески всё разумеется понятно конечно же.