Упрощение законного вывода денег с фриланс-бирж очень актуально для многих. Большое спасибо Вам.
Думаю главный вопрос — это согласование этого упрощения с налоговой. Уже несколько лет некоторые фрилансеры пользуются таким хитрым инвойсом вместо договоров и актов выполненных работ. Некоторые банки уже давно принимают такое. А вот что скажет на это налоговая при проверке — это наверно единственное важное препятствие.
А справка из банка не является документом подтверждающим получение дохода?
1. Налог 15% вместо 5% на ФЛП.
2. Если часто так делать, то могут обвинить в предпренимательской деятельности без регистрации.
Зачем переходить на личности? О неэффективном процессе вообще то Вы писали. А я всего лишь описал известные вещи, и даже поддержал один Ваш коммент...
А статистика из книги «Совершенный код».
Это статистика. Ни одна методика тестирования не способна обнаружить все дефекты. Поэтому нужно использовать несколько. А инспекция кода, согласно статистике, наиболее эффективна (до 60% дефектов). Также, согласно статистике, инспекция кода существенно сокращает затраты на разработку.
Это не я предлагаю. Это известные вещи. Если у вас это неэффективный процесс, значит что-то не так делаете.
Очень часто я обнаруживаю причину ошибки путем просмотра кода, и это часто значительно быстрее, чем искать отладчиком.
Главная цель инспекции кода — это обнаружение ошибок. Она позволяет не только найти ошибки, которые трудно обнаружить при обычном тестировании, но и значительно уменьшить затраты на разработку (минимум на 20%).
Згадані найбільш часто вживані діаграми інтуітивно зрозумілі і без знання UML. А навчитися створювати іх в якомусь засобі моделювання (наприклад Visio) можна за 1 годину. Знати всю специфікацію UML нема сенсу, бо реально з неі викиростовують мало, а засоби моделювання значно спрощують створення діаграм і містять «знання» UML.
UML дозволяє суттєво зменшити витрати на перші ітераціі формування архітектури програми, оскільки вони здійснюється без зміни коду. Також він значно спрощує комунікацію між учасниками проекта, зменшує час на входження нових програмістів в проект і покращує якість архітектури.
Ефект UML — це візуалізація релевантних особливостей програми. Як і будь-який інструмент, його треба використовувати з розумом. Занадто багато деталей на діаграмах може мати негативний ефект.
Реально використовував діаграми класів, прецедентів і послідовностей.
Скрам — это только фреймворк, и его успех зависит от выбранной реализации (например extreme programming). Многие упускают из вида необходимость детализации процесса. При формальном применении скрам может не только не решить проблемы процесса разработки, но и значительно увеличичить трудоемкость проекта.
ИМХО проще и эффективнее применять составляющие разных процессов (ежедневные митинги, детальная документация требований, итерации, дизайн архитектуры, автоматическое тестирование, ...) исходя из специфики проекта и четкого понимания целесообразности каждого метода. В первую очередь нужно учитывать наличие четких требований, их изменчивость и необходимость как можно скорее получить работающий продукт.
Достатньо подивитися його передвиборчу рекламу: у війні винна теперішня влада і т.д.
А коли розстрілювали майдан, він у Верховну Раду так і не прийшов.
И какой результат? Какое отношение налоговой к этой схеме?