Дмитрий Бойцов: список можно расширить анимацией, доступом к датчикам и всем платформенным фишкам, улучшающим UX. Сюда же можно добавить возможность автономной работы приложения, в отличие от мобильной версии сайта.
Smith07: и на вашем бы месте я задумался бы об адекватности разработчиков. Решение на in-app purchase поставит крест на дальнейшем существовании любого маркетплейса. Никто не будет идти работать на площадке, которая приносит на 30% прибыли меньше, чем другие.
Smith07: а тут и обходить ничего не надо, в правилах Apple четко написано, что оплата цифровых товаров осуществляется только через in-app purchase. Для оплаты же физических товаров, билетов и услуг можно использовать сторонние платежные системы. Именно так я и поступаю, принимаю оплату через яндекс.кассу, через которую также можно и организовать выплаты исполнителям.
Демоверсия -плохая практика. Есть куча халявщиков, которые будут каждый раз регистрироваться заново. Лучше через онбординг показать как проходит процесс.
Z-r: так здравомыслящий человек скажет, что подобный код, особенно после рефакторинга, может быть разработан собственными силами. Типичные задачи зачастую решаются одними и теми же алгоритмами, методами и паттернами.
Назвали высказыванье "ложью", так потрудитесь поделиться правдой. Желательно с ссылками на какие-либо судебные решения.
Z-r: окей, расскажите тогда чем будет руководствоваться экспертиза при сверке кода? Какие будут аргументы что код скопирован, а не написан с нуля? поделитесь "умностями".
ТЗ на этом этапе не нужен и строго противопоказан. Как календарное планирование.
Ваш план отлично работает на аутсурсинговых проектах. В стартапах же только приводит к лишним расходам.
Андрей: и на .Net все идеально, надо просто понимать что крупные интересные проекты на фриланс не отдают. Но в них можно устроиться удаленно с равнозначной а то и большей ставкой.
spotifi: работал над крупных проектами в командах до 6 разработчиков с разным уровнем разделения:
1. Проект под управлением параноика. Весь код разделен на отдельные куски. Исполнители друг друга на знают, получают задания от параноика и ему же сдают их. Доверенное лицо параноика собирается проект из результатов остальных исполнителей. Лютый ад, работать так крайне тяжело, муторно и долго.
2. Каждый исполнитель пилит свой кусок: бэкэнд, мобильное приложение или сайт. Если речь идет о постояннянных сотрудниках, то периодически кто-то будет простаивать в ожидании коллег. ПМ придется долго и муторно разруливать граничные ситуации, когда непонятно где же баг: на бэке или на фронте.
3. Все работают над всеми частами проекта. Разделение задач между исполнителями идет по требованиям\фичам. Тут не получится спихнуть баг на другого - каждый видит и знает код всего проекта. Полкоманды скосил грипп? не проблема, критичные требования будут сделаны в срок, некритичные отложены. Баг в бэкэнде, а человек писавший код в отпуске? не беда, другой член команды поправит его. Закончил со всеми задачами? можно помочь коллегам. Особенно хорошо это работает, когда все части проекта делают на одном стеке. Идеально для Java и .Net.
Надо учитывать, что пункт №1 приводит к излишней сложности в разработке и поддержке. Это ведет к излишним затратам и тормозит сроки релиза. На этапе MVP вообще может загубить проект.
Максим Тимофеев: для личного использования бесплатен, 10$ - это для командной работы и отчетности перед заказчиком.
Мне показался удобным - есть desktop и web-приложения для замера времени. UI вполне удобный, хорошие отчеты. Мои задачи покрывает на 150%.
Матвей Мамонов: именно так - приходишь, стучишься в офис, спрашиваешь.
Удаленно новички и тем более перфекционисты не нужны никому - профита с них никакого, одни проблемы.
