Ответы пользователя по тегу Фриланс
  • Как лучше получать деньги из-за рубежа (в т.ч. фриланс) в РФ на 2016 год и дальше?

    Все зависит от источника доходов:
    - Если доходы от объекта авторского права, т.е. прямая продажа прав, лицензионные отчисления, мобильные/десктопные приложения, то можно оставаться физиком и подавать раз в год 3-НДФЛ. В данном случае предпринимательская деятельность отсутствует.
    - Если источником доходов является оказание услуг, то лучше открыть ИП на упрощенке, т.к. в противном случае это попадает под нелегальную коммерческую деятельность. Расчетный счет вам открывать не обязательно и можно использовать лицевые счета. Расчетный счет желательно иметь если вы получаете деньги внутри россии, т.к. некоторые банки отказываются проводить подобные платежи с расчетного счета на лицевой. Про пионера лучше узнать на сколько он легализован в РФ, но с PayPal проблем точно нет. Налоговую теперь тоже уведомлять об этих счетах не нужно, достаточно указать их в КУДИР (расшифровка далее). Раз в год будете подавать декларацию, вести Книгу учета доходов и расходов (КУДИР), в которую будете записывать свои доходы, и раз в квартал платить страховые/налоговые отчисления. С учетом того, что налоговые отчисления будут уменьшаться на 100% от страховых отчислений, то реальных расходов на ведение ИП не много и, как правило, это гораздо выгоднее НДФЛ.
    Открыть ИП выйдет в районе 2 килорублей, с учетом заказа всех бумажек для открытия, и 1 неделю по времени.

    С валютным счетом немного сложнее, т.к. вам нужно будет проходить валютный контроль. А с ним главное быстро-быстро шевелиться, т.к. времени потупить там крайне мало. Но это тоже не такая уж большая проблема, если не жалеть денег на сопровождение. На хабре этот вопрос не раз поднимался, еще со времен, когда сайты были одним целым.
    Ответ написан
    Комментировать
  • Как эффективно работать с программистом?

    ТЗ + Система управления проектами (PM, мы используем feng office) + система контроля версий (SVN).
    На первом этапе составляется ТЗ с планом работ и детализацией.

    ПП: разработка модуля обработки испытания:
    1. Адаптация модели данных: 4 часа,
    2. Выборка из протокола данных: 2 типа протоколов по 2 часа на каждый + 1 час на отладку = 5 часов,
    3. Разработка GUI: 3 контрола с графической обработкой * 4 часа на каждый + 2 контрола для таблиц * 1 час на контрол + 1 контрол общей информации * 0.5 часа = 14.5 часов
    4. Тестирование GUI: 3 графической обработки * 0.5 часа = 1.5 часа
    5. Разработка отчета: дизайн 16 часов + верстка 8 часов + отладка 16 часов = 40 часов
    Итого: 60 часов

    Составляем ТЗ на весь проект, добавляем от 50% до 200% запаса по времени. В дальнейшем ТЗ будет пересматриваться, работы будут переставляться, сроки сдвигать в меньшую или большую сторону, но фактически разработка займет рассчитанное время с небольшим отклонением. Правда на составление такого ТЗ уходит довольно много времени.

    Далее контролировать исполнение необходимо по завершенным этапам в PM и сопоставленным им коммитам в системе управления версиями. Так же необходимо жестко контролировать работоспособность релизной ветки в SVN. Для длительной задачи необходимо создавать ветки, и только для минимальных изменений, которые не затронут работоспособность или были полностью протестированы, вести коммит в основную (ПП изменение дизайна GUI без изменения функциональной части).

    При разработке вдвоем показала себя хорошей практика 1-го коммита в 1-4 часа в ветку и каждые 4-7 часов слияние веток. Большие изменения не накапливаются и оба работаем над актуальной версией. Для своих личных проектов стараюсь придерживаться такого же ритма. Главным преимуществом при разработке в одиночку является возможность быстрого отката последних изменений, да и затраты времени считать удобно.

    Максимально допустимым сроком комита является 8 часов (1 рабочий день). Если интервал коммитов превышает этот срок, то возможны только 3 варианта: 1. Работа стоит, 2. Возникла серьезная проблема, 3. Задача слишком большая и нужно было ее более подробно детализировать. Если возникает именно 3-й случай, то нужно проверить ТЗ на похожие задачи и детализировать их. Так же коммит должен идти на каждое исправление бага, с обязательным оповещением остальных о необходимости срочно получить свежую версию.

    Минимум 1 раз в неделю детальное обсуждение состояния проекта всем отделом(компанией, группой, нужное подчеркнуть), желательно с чек-листами проверки работы программы. Так же 1 раз в месяц можно требовать отчет о проделанной работе в письменном виде, возможно с пакетом документации на программу. Главное не забудьте внести в ТЗ минимум 4 часа в месяц на него (если с документацией, то минимум 8-16).

    PS. Что касается выбора разработчика, то лучше всего попросите помочь в выборе знакомого программиста. Если его нет, то попросите кандидата прислать пример кода и оцените его на качество форматирования. Правила форматирования найти очень легко. Или попросите оценить код любого программиста, например с хабра, какого нибудь форума или еще откуда нибудь.

    PSS. Удачи!
    Ответ написан
    1 комментарий