Еще 7 ошибок чтобы закопать свой проект мобильного приложения. Часть 2

Ошибка № 10: Продолжать дорабатывать МВП

MVP запускают, чтобы протестировать гипотезу на целевой аудитории продукта и получить обратную связь. Например, «быстрый» интернет-магазин на бесплатном движке, чтобы проверить интерес аудитории. Интерес проверили, он есть и весьма большой. Вместо того чтобы оставить первую версию как есть, и разрабатывать с нуля полноценную версию со всем функционалом, клиент решил «докручивать» первую версию, MVP.

В итоге система не держала нагрузку, любое дописывание функционала сопровождалось крокодильими слезами разработчиков, а операторы стерли пальцы о клавиатуру, составляя список правок на устранение проблем. Проблемы возникали из-за того, что приходилось дописывать функции движка интернет-магазина, который изначально не был для этого предназначен.

Единственное решение — переписать все с нуля, как и планировалось после проверки гипотезы.

Но клиент считал, что это дорого и продолжал просить закрывать баги и добавлять костыли для нового функционала.

Итог: недовольный клиент, недовольные пользователи, потерянное время, мы ушли из проекта. Насколько я знаю, клиент перестал работать над проектом и снова стал продавать через соцсеть, ныне запрещенную в России.

Мой вывод: если система написано по-быстрому для конкретных целей, не нужно надеяться, что она внезапно переродится в жар-птицу. Лучше за 4 месяца написать свою рабочую систему, способную к масштабированию, чем потратить 1,5 года впустую.

Ошибка № 11: Отказываться от внедрения готовых решений

Мне пока всегда удавалось отговорить клиентов от «написания своего чата с нуля». Но на всякий случай уточню, что написать свой чат с нуля займет 4-6 месяцев. Не знаю с чем это связано, но почему-то чаты просят написать с нуля чаще всего.

Существует много готовых отличных SaaS-решений. Тот же чат можно интегрировать в свое приложение за 600-1000 рублей в месяц. Просто нерационально платить за разработку чата команде из 5 человек. Если есть опасения за сохранность данных, надо внимательно читать договор с сервисом. Но даже если вы хотите собственное решение вместо SaaS-сервиса, то данные все равно будут храниться у хостера. И у него также будет к ним доступ. Кстати, про доступ к данным будет следующая ошибка.

Ошибка № 12: Разрешить разработчику регистрировать доступы к ресурсам не на вас. Загружать репозитории проекта не на ваши учетки.

Привычная ситуация: к нам часто приходят клиенты, у которых нет доступов даже к своему хостингу. И к исходным данным проектов (говоря просто, к коду, который написали программисты).

Причина: клиент поссорился с разработчиками и те поменяли логины и пароли, отключили сервер.

Что делать в такой ситуации. Мы составляем список материалов, которые нам нужны для начала разработки, и начинается веселый процесс получения доступов. Иногда нужно отправить множество писем на разные ресурсы с документами, чтобы объяснить хостеру и другим сервисами: этот клиент — правообладатель материалов на их ресурсе. Ответа можно ждать неделями.

Моя строгая рекомендация: обязательно оформляйте все доступы к ресурсам на ваши почты и номера телефонов. Также просите разработчиков, чтобы они загружали коммиты на вашу учетную запись хотя бы раз в неделю, иначе у вас не будет исходников вашего проекта. И, по возможности, создавайте отдельный дочерний доступ, а не просто логин и пароль от главной учетки.

Ошибка № 13: Хочу работать по фиксе!

Fixed Price — это работа по фиксированной стоимости. Time and Material (TM) — это почасовая оплата работы.

Кажется, что работать по фиксированной стоимости выгоднее: известно сколько времени займет разработка. Но если ТЗ не четкое, разработчикам трудно определить точный срок. Разработчик, может завысить срок просто для собственной подстраховки, а клиент за это переплатит. Как с этим быть? Согласовывать стоимость ближайшего этапа только после согласования предыдущего. Чем четче ТЗ и макеты, тем яснее сроки и бюджет.

Ошибка № 14: Ругаться с разработчиками :)

У нас были клиенты (к счастью, всего два), уверенные, что разработка — это на самом деле не дорого, а их просто хотят «развести» на деньги.

Клиент был убежден, что платить 200 тысяч рублей в месяц команде из 5 человек, которая работает на его проекте, это чересчур дорого. Аргументов слышать не хотел. Мы перестали работать с этим клиентом, потому что оцениваем свой труд адекватно. Он стоит дороже.

Если у вас есть вопросы или недопонимания, лучше спокойно задать их, либо разойтись, если что-то не устраивает. Получить репутацию скандалиста — не очень хорошая перспектива, ведь мир разработки тесен.

Вместо вывода

Я просто снова повторю то, что сказала в финале первой части: стремитесь работать с профессионалами, обращайте внимание на репутацию команды. Этот подход сбережет ваши нервы, время и деньги. Я видела доказательства много раз: и лично, и в историях наших клиентов. Об этом и хотела вам рассказать.

Конечно, список ошибок, который я составила, не исчерпывающий. Возможно, вам есть что добавить. Смело обращайтесь к нам в CREAZARD и рассказывайте об ошибках, которые мешают разработке. Я не просто добавлю их в свой список, но и помогу!

В связи с поправками в законе о рекламе, вынуждены поставить метку: Реклама, ИП Громова, ИНН 772850165163 erid: 2Vtzqwkzs23