Цена проекта. Ожидание и реальность
Время прочтения — 10 минут
Содержание
Натали
PR
Когда я придумывала заголовок, то несколько раз начинала писать фразу «по вине клиента» и стирала. Потом поняла, если хочу сделать текст полезным, а не детективным, лучше рассказать «что делать?», а не искать «кто виноват?».
Поэтому от лица аутсорс компании по веб и мобильной разработке поделюсь кейсами, как стоимость проекта на выходе может сильно отличаться от ожиданий клиента. И почему так происходит. Конечно же, все совпадении случайны, имена вымышленны и т.п, что обычно пишут в дисклеймерах.
Чужой back
Маша
Mobile developer
Представьте, к вам приходит типичный проект, допустим, это приложение доставки пирогов. Каталог продуктов, корзина, возможность оформить заказ, – ничего не предвещает беды. Есть готовые бэк и дизайн. Казалось бы, передай проект мобайлу и живи припеваючи. Особенно, если у вас он пишет на чем-то кросс-платформенном. Например, на React Native, как у нас. Но…будьте готовы скидываться ему на валерьянку. Почему?
Нет стандартизированной документации
Вместо стандартизированной документации, вместо нее гугл документ на 60+ страниц. Почему при создании документации важно использовать инструмент для описания и документирования API?
1
Самодокументирование: Swagger автоматически создает документацию для вашего API на основе информации, которую вы предоставляете в формате JSON или YAML. Это уменьшает вероятность ошибок в документации. В противном случае – полный швах: каких-то методов не хватает, в других примеры не соответствуют запросам, в части методов нет обязательных полей, в других методах указаны поля, которые на самом деле не нужны.
2
Интерактивность: Swagger позволяет протестировать API прямо из документации. Это сильно упрощает разработку и процесс тестирования. А значит, мобайлу нужно меньше часов. Меньше часов – меньше денег. Смекаете?
3
Удобство: Swagger позволяет сделать API более прозрачным для других разработчиков. Он предоставляет полное описание API, которое легко и удобно читать. Не нужно искать необходимый метод на 60 страницах.
API не соответствует ни одному из протоколов
Почему использование стандартизированного API лучше, чем создание собственного? Стандартизированные API:
1
Совместимы с приложениями и сервисами, что упрощает интеграцию с другими системами и повышает уровень переносимости.
2
Имеют общую структуру и формат данных, что делает их более понятными для других разработчиков и упрощает их использование.
3
Обычно имеют установленные стандарты безопасности и авторизации, что обеспечивает безопасность передаваемых данных.
4
Могут использовать общие компоненты и решения, что упрощает разработку и снижает затраты на поддержку и обслуживание.
Короче говоря, использование стандартизированного API – это безопасно, удобно, эффективно и популярно. Собственное API может привести к нежелательным проблемам совместимости, что, по-любому, скажется на производительности и стабильности системы.
В ответах сервера приходит невалидный JSON
Это приводит к проблемам при обработке данных на стороне клиента. Например, когда вы ждете, что сервер вернет список объектов, а в ответ получаете строку. Приходится писать парсеры на клиентской стороне. Это, конечно, не занимает много времени, однако тормозит разработку каждый раз, когда приходят невалидные данные. Ну и тратит деньги клиента.
Бэк не придерживается одного стандарта именования переменных
Вам кажется, это ерунда? А вот мобайлу значительно усложняет процесс чтения кода и увеличивает шансы на ошибки. Плюс уходит дополнительное время на переименование.
Вся логика работы приложения вынесена на клиентскую сторону
Что тут такого? Если у клиента уже есть сайт, который использует тот же бэкенд, что и приложение, общую логику следует реализовывать на сервере. Это обеспечит единообразие в работе приложения и сайта и позволит избежать дублирования кода на клиентской стороне. Когда общая логика реализована на стороне клиента, мобильное приложение и сайт будут зависеть от различных версий этой логики. Это может привести к несогласованности в работе и проблемам с обновлением приложений.
ТЗ не соответствует бэкенду
Это значит на клиентской стороне вам периодически могут говорить: «ой, я забыл сказать, что здесь будут приходить еще вот такие данные». Эта «забывчивость» может повлиять на продумывание архитектуры на начальном этапе, а может всплыть только при тестировании задачи.
Бэкенд не соответствует дизайну
Во-первых, дизайнеры на стороне заказчика, частенько оказывают «не причастными» к миру UX/UI. Из-за этого у вас постоянно будет не хватать большого количества отрисованных состояний. Мы же надеялись хотя бы на то, что бэкенд, который знает все нюансы и процессы, работает в связке с дизайнером. Значит, итоговый дизайн отображает полную картину приложения, – сделали мы вывод и оценили проект. А потом все приходилось додумывать нам, ведь дизайн не отображает реальную логику работы приложения.
Резюмируя эту «боль», хочется сказать, что проекты, у которых «всё своё», конечно, тоже бывают разными: гибкими, адекватными, готовыми к коммуникациям и совместной работе. И в таком случае получается классный продукт. Но чаще нет, чем да. Ведь человеческий фактор, страх ответственности и лень никто не отменял.
Чужой дизайн
В последнем пункте мы медленно подъехали к следующей теме. Это чужой дизайн. Как он может влиять на стоимость конечного продукта, если вы обращаетесь за разработкой к компании на аутсорсе?
Давайте для начала разберемся, могут ли дизайнер сумок или верстальщик книг сделать хороший дизайн сайта/приложения/админки? Если ваш ответ «да», попробуем открыть вам глаза. Если вы ответили «нет», смело спускайтесь на главу ниже.
Так вот, особенность хороших (!) UX/UI дизайнеров в том, что они, когда читают ТЗ или рисуют прототипы, задают много вопросов: как это будет работать, а если зарегистрироваться нельзя, что он увидит, а если баллов будет очень много и адрес длинный, как отображаем строку…и т.д и т.п. Они погружаются в бизнес, изучают конкурентов, знают как ведут себя пользователи.
Еще они примерно представляют, возможно ли реализовать их фантазии в жизни. Или фронтенд, которому придется верстать, сойдет с ума. Когда мы устали бороться с нерадивыми дизайнерами и поправлять за ними всю работу, написали свой чеклист.
Еще UX/UI дизайнеры знают, что помимо разных состояний у кнопок, есть еще масса экранов, которые не несут в себе никакой «изюминки», но нужны пользователю, потому что все уже так привыкли. По-другому человеку будет не понятно, как юзать приложение или сайт, где регистрироваться, где искать настройки и т.п.
К сожалению, обладая лишь хорошим вкусом, но не имея прикладных знаний, нельзя предоставить рабочий дизайн проекта. Значит, время разработчиков и деньги заказчиков будут уходить на постоянные правки, объяснения и ожидание пока человек со стороны клиента дорисует все, что нужно. А это простой, сдвиг сроков. Думаю, картина ясна.
Человеческий фактор
Да, следующая история она скорее не про то, что лучше обращаться за комплексом услуг в одно место. Сейчас поясню, о чем я, и пойду дальше.
Рисуем в голове картинку: вы купили квартиру – прекрасное событие. Однако, чтобы заселиться, нужен ремонт. Вместо того, чтобы нанять одну бригаду, агентство (как хотите) и получить квартиру под ключ, вы решаете сэкономить и ищете по знакомым электриков, штукатурщиков и т.д. Вам дают неплохих ребят, но потом оказывается, что один проштробил стену, а у другого там водопровод. Короче, с ролью менеджера, который контролирует весь процесс, вы не справились. А все потому, что думали, что они все сами между собой договорятся.
Вот и в разработке, если вы отправитесь с работой одного специалиста к другим, ничего хорошего не будет. Придется городить костыли, считаться с человеческим фактором и смотреть, как растет стоимость проекта. Предлагаю теперь разобраться с этим самым фактором. Можно ли на него повлиять, если вы – владелец бизнеса?
Человек ничего не хочет менять
Эта история характерна для стран СНГ, для людей в возрасте, для ленивых людей. Чаще всего она возникает, когда приходится настраивать интеграции с другими системами. Обычно «с той стороны» оказывается специалист, который не хочет ничего у себя менять, чтобы разработка была проще, быстрее, удобнее. И вместо того, чтобы этот специалист поработал неделю и привел все данные к единообразию, программисты трудятся 3 недели, а тестировщики нервно курят в коридоре, представляя, как будут искать баги в этих костылях.
Человек долго согласовывает
Эта прекрасная история посвящена всем, у кого юристы, замы замов и куча других важных людей, которые влияют на процесс согласований. Именно из-за такой проблемы один из клиентов остался без приложения на крутом ивенте, где хотел демонстрировать его потенциальным клиентам.
Человек сидит на зарплате и ему ваш бизнес «до фени»
Это значит, он может растягивать сроки, бесконечно переделывать, выполнять только для галочки или, не вникая в задачу. Что сказали, то и делаю, мозг включать не хочу. Такой «работник» не заинтересован в результате, он не чувствует себя причастным к нему, не стремится сделать лучше. Как правило, когда нанимаешь команду на аутсорсе получаешь обратный эффект, потому что им важно сделать круто и качественно. Ведь проект можно положить в портфолио, да и сарафанное радио никто не отменял.
Человек не умеет приоритизировать задачи — делает кучу другой работы
Этот пример можно было привести в истории про чужой бэк. Но я решила все-таки отнести к человеческому фактору. Ведь на его месте может быть любой специалист, который работает у клиента, но должен взаимодействовать и выполнять какие-то таски, которые прилетают от разработчиков. Например, правильно отдавать данные, писать быстро API. А они вместо этого делают какие-то другие задачи. И получается, что команда на аутсорсе ждет у моря погоды, а клиент ждет, пока его проект разморозится. Он потратил $100 000 на приложение, а оно не работает, потому что надо ждать API.
Стартапы/предприниматели не умеют приоритизировать хотелки и заливают все деньгами
Этот пример про то, как мы долго и упорно реализуем какие-то несильно приоритетный фичи, или про то, как резко меняются приоритеты, в результате получается, что никакого ощутимого результата нет. Проект не закончен, MVP не выпущено, а деньги потрачены. Причем в разы больше запланированных. Хорошо, когда такие средства есть. Но в целом, лучше так не делать.
В этой длинной истории мы поделились примерами, которые встречались порой неоднократно в нашей практике. Зачем? Чтобы клиенты понимали, в каких моментах сами влияют на цену своего проекта, видели, где и как можно поступить по-другому.
Очень интересно послушать и ваши истории. Не важно, по какую сторону баррикад находитесь вы. Делитесь ими в комментах, возможно, это кому-то это поможет заметить собственные недочеты.
