Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 3184 сообщений
Cообщения с меткой

фриланс - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Перевод] Как стать профессиональным веб-разработчиком: практическое руководство

Среда, 23 Июня 2016 г. 01:46 (ссылка)



Дорога длинна и трудна, но интересна и полезна!



Статья задумывалась как практическое руководство для желающих стать профессиональным веб-разработчиком. Я уже более 20 лет пишу код для веба. Я ежедневно работаю с веб-разработчиками и помогаю им. В статье я опишу, что вам нужно выучить, когда вам нужно это выучить и где взять информацию (чаще всего даже бесплатно). Затем я дам совет по получению реального опыта, и что самое важное – по получению денег за написание кода.



По статье разбросано множество ссылок на бесплатные и важные ресурсы. Для простоты я собрал их в PDF и разбил по категориям. Мне не платят за упоминания сайтов, ссылки на которые я привёл – я всего лишь хочу порекомендовать вам лучшие ресурсы, чтобы помочь вам достичь вашей цели.



Что нужно помнить:



1. Статью разрешается пролистывать



Руководство может помочь вам вне зависимости от вашего положения на дороге к профессиональной разработке. Прокрутите его к тому заголовку, который лучше всего описывает ваше сегодняшнее положение, и читайте оттуда. Если вы только начали этот путь, или пока размышляете об этом – последуйте совету Короля из «Алисы в стране чудес»:



Начните с начала, и продолжайте, пока не дойдёте до конца; и там уже остановитесь.



2. Попробуйте всего понемногу, а затем выбирайте специализацию.



Деньги – не самое важное. Вам необходимо ЛЮБИТЬ ваше занятие! Но вы не узнаете, что вам нравится, пока не попробуете.





Найдите свою страсть, а потом монетизируйте её



Руководство поможет вам ознакомиться с как можно большим количеством областей веб-разработки как можно быстрее. А потом поможет вам выбрать специализацию в той области, что вам понравилась. Сначала вы не достигнете совершенства ни в чём – вы выучите основы, и потом продолжите изучение. Найдите свою страсть, и я покажу вам, как двигаться дальше.



Я решил писать код. Мне нравится веб. Я не знаю, с чего начать





У вас всё получится!



Поздравляю! Это серьёзный первый шаг и начало чего-то весьма захватывающего. Но это может оказаться и очень сложным. Не волнуйтесь, я помогу.



Сначала вам нужно быстро познакомиться с основами всех областей веб-разработки («полный цикл»). Обучение будет разнообразным, но неглубоким. Это нужно для того, чтобы найти область, которая вам нравится, а также приобрести основные навыки в разных областях. Тогда вы сможете понимать и работать с большим набором задач, вне зависимости от того, на чём вы остановите свой выбор.



Изучите основы HTML



Язык разметки гипертекста, Hypertext Markup Language (HTML), контролирует содержимое и разметку того, что вы видите в браузере. Начав с него, вы получаете интерфейс пользователя, с которым можно взаимодействовать, и видите результаты работы своего кода. При изучении более сложных языков его важность будет возрастать. Вам ведь не нужно кодить вслепую.



Вот, что вам нужно изучить на тему HTML:





Я уже знаю основы HTML



Круто! Это очень важный шаг. Теперь изучите основы JavaScript.



Изучите основы JavaScript



JavaScript – язык веба, и все основные браузеры (Chrome, Firefox, Safari, IE, множество других) поддерживают его. Каждый сайт, каждое веб-приложение, которым вы пользовались, скорее всего, содержит огромное количество JS-кода. Не говоря уже о том, что язык набирает популяность и на других платформах – сервера, настольные компьютеры, другие устройства.



Пока вам нужны основы, и для этого подойдут следующие ресурсы:





Я знаю основы JavaScript и HTML



Потрясающе! Теперь добавим к вашим навыкам CSS



Изучите CSS



CSS, или Cascading Style Sheets (каскадные таблицы стилей). Используются для настройки внешнего вида элементов HTML на странице. Ознакомьтесь с бесплатным обучающим материалом от Mozilla, а затем обращайтесь к ресурсу CSS-Tricks для решения самых сложных проблем (справа вверху есть поиск).



Переходим к бэкенду



До сих пор мы с вами рассматривали то, что называют «фронтендом» веб-разработки. Вы ознакомились с основными языками, работающими в браузере. Пора переходить к бэкенду – коду, работающему на сервере. Не волнуйтесь, сервер вам не понадобится – ваш компьютер справится с этим.



Языков для бэкенда масса, но поскольку вы знакомы с JavaScript, я порекомендую изучить использование Node.js. Он позволяет запускать JS-код на сервере, а не в браузере.



В дополнение к этому вам необходимо изучить Express и MongoDB.



Express


Это библиотека, с помощью которой Node.JS может работать веб-сервером (слушать запросы от страниц и отправлять им ответы).



MongoDB


Это база данных, позволяющая вам хранить и извлекать информацию.



Изучить три эти темы можно благодаря следующему прекрасному и бесплатному обучающему материалу, и его продолжению.



Мне нужно выбрать между «фронтенд», «бэкенд» и разработкой полного цикла



После того, как вы попробовали оба варианта разработки, настало время делать выбор. Если вы не успели их попробовать – обратитесь к предыдущему разделу статьи, чтобы заполнить пробелы в ваших знаниях.









К этому моменту вы писали два типа кода. Один предназначен для взаимодействия с пользователем, другой – с данными. Что вы предпочитаете?



Взаимодействие с пользователем? Поздравляю, вы фронтенд-разработчик!



Взаимодействие с данными? Поздравляю, вы бэкенд-разработчик!



Оба? Поздравляю, вы разработчик полного цикла!



Ничего не понравилось? Поздравляю, веб-разработка – это не для вас. Возрадуйтесь, что вы поняли это сейчас, и не потеряли кучу времени и денег. Не готовы сдаваться? Может, вам не попался язык, который пришёлся бы вам по душе? Попробуйте изучить другие языки в разделе «Я хочу быть бэкенд-разработчиком».



Я хочу быть разработчиком полного цикла



Круто. Вам нужно ознакомиться со всем содержимым разделов «Я хочу быть бэкенд-разработчиком» и «Я хочу быть фронтенд-разработчиком».



Я хочу быть фронтенд-разработчиком и я знаю основы JavaScript, HTML и CSS



Для эффективной работы фронтенд-разработчиком вам необходимо в совершенстве овладеть HTML, CSS и клиентским JavaScript. Также вам нужно будет хорошо разобраться в нескольких важных фреймворках. Вы приобретёте навыки, которые работодатели и клиенты ожидают найти в разработчиках фронтенда.



К этому моменту вы уже должны знать основы HTML. В противном случае вернитесь к разделу «Изучите основы HTML».



Изучите промежуточный и продвинутый HTML


Ознакомьтесь с обучающим материалом по промежуточному HTML, а затем – по продвинутому.



Изучите продвинутый клиентский JavaScript




Отличная серия книг по JS, при этом бесплатная



Для поднятия вашего уровня владения JavaScript, я рекомендую серию книг «You Don’t Know JS» за авторством Кайла Симпсона. Автор выложил всю серию в онлайн совершенно бесплатно:





Кроме того, вашим лучшим другом должен стать и MDN JavaScript.



[Также совершенно бесплатно вам доступен превосходный перевод отличной книги "Выразительный JavaScript" — прим.перев.]



Знать «троицу фронтенда», HTML, CSS и JavaScript – это, конечно, здорово. Но для зарабатывания денег придётся вам познакомиться с некоторыми фреймворками.



Изучите jQuery


Это самая популярная библиотека JS всех времён. Хотя из-за некоторых новых фреймворков важность jQuery чуть поуменьшилась, если вы ищете работу, велика вероятность, что jQuery будет присутствовать в описании необходимых навыков (и упоминаться на собеседовании) ещё много лет.



Рекомендую изучить jQuery при помощи материалов FreeCodeCamp – это быстрый и эффективный метод. После этого отправляйтесь на официальный обучающий сайт – там вы найдёте дополнительные инструкции.



Также вам понадобится держать под рукой документацию по jQuery API.



Изучите популярный JS-фреймворк


Фреймворки делают работу с определённым языком или технологией легче, поскольку решают наибольшие проблемы, существующие у выбранной технологии. JavaScript очень благотворно повлиял на разработку и популяризацию фреймворков.



Чуть ли не раз в неделю появляется новый фреймворк, который прочат на место нового стандарта разработки. Вам нужно будет прошерстить сайты с вакансиями и немало погуглить, чтобы выяснить, какой фреймворк популярен на вашем рынке. Также рекомендую инструмент от Hacker News по оценке тенденций рынка вакансий.



Во время написания этой статьи следующие фреймворки пользовались популярностью:







React JS


React создали разработчики Facebook для работы с их архитектурой Flux. Это JS-библиотека для создания интерфейсов. Не так давно она вырвалась на первое место по популярности, перегнав Angular. Начинайте с React. Здесь можно найти хороший бесплатный курс для начинающих.



Angular 1 и 2


Angular JS создали разработчики Google, и он быстро набрал популярность. Многие компании сильно вложились в него, и, судя по графику выше, он всё ещё популярен. К сожалению, в Google приняли решение полностью переписать Angular при разработке 2-й версии. Поэтому Angular 1 и Angular 2 получились практически полностью разными. Если вам хочется стать экспертом в Angular, придётся изучить оба фреймворка. Возможно даже, что вам окажется достаточно и первой версии – пока ещё есть время. Но время это уже на исходе. Большинство работы, связанной с Angular, постепенно переходит на Angular 2. В Code School есть интересный бесплатный курс по Angular 1. А для изучения Angular 2 посмотрите бесплатные видео.



Ember JS


Для людей с опытом работы в Ember JS пока ещё есть места, но судя по графику, он уже помирает. Его не поддерживают такие монстры, как Google или Facebook, а вы и так будете загружены изучением React и Angular. Но если вам интересно, можете почитать официальное руководство по Ember JS.



Выбрав наиболее подходящий фреймворк и хорошенько ознакомившись с ним, стоит изучить идущий в паре с ним CSS-фреймворк. Два крупнейших игрока на этом рынке сегодня – Bootstrap и Material Design.



Bootstrap


Bootstrap сделали разработчики Twitter, и он уже довольно взрослый и популярный. Версии Bootstrap существуют для Angular, Angular 2 и React.



Material


Material – это набор правил дизайна, разработанный в Google. Он набирает популярность, существуют его версии для Angular и React. Поскольку Angular – это тоже детище Google, сочетается Material с ним превосходно.



Вот вам несколько ссылок:





Поздравляю! У вас есть ключевые навыки фронтенд-разработчика!





Вы только посмотрите на него!



Я хочу быть бэкенд-разработчиком



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





TIOBE Index of Programming Languages, www.tiobe.com/tiobe_index?page=index



Концентрируйтесь на языках, чьи названия я обвёл зелёной рамкой. Если вы не знаете их, начинайте сверху таблицы и идите вниз. Останавливайтесь, когда найдёте то, что вам нравится, и копайте вглубь!



Если вы знакомы с одним из отмеченных зелёным цветом языков, и он вам нравится – концентрируйтесь на нём.



Java


Чрезвычайно популярный язык, запускающийся почти везде. Разработан в Sun Microsystems (сейчас им владеет Oracle). На этом языке пишутся приложения для Android. Его также можно использовать для создания десктопных приложений, и, конечно, веб-приложений (как отдельных приложений бэкенда, так и работающих в паре с JSP). Он развитый, стабильный, и для его изучения есть огромное количество ресурсов. Кроме того, это самый популярный язык для изучения объектно-ориентированного программирования в колледжах и университетах. Вот неплохой курс по Java для начинающих.



C#


C# был создан в компании Microsoft как прямой конкурент Java. До недавнего времени его поддержка на системах, не принадлежащих Microsoft, была не ахти – но сейчас ситуация выправляется. Как и Java, этот язык объектно-ориентирован, и может использоваться как для создания веб-приложений (как отдельно, так и совместно с ASP.Net), так и десктопных приложений. Если вы пользуетесь ОС Windows, и вам нужна более привычная среда разработки, C# может подойти вам. Ознакомьтесь с бесплатным курсом по языку от Microsoft Virtual Academy.



Python


За ним не стоит огромная компания, как за языками Java или C#, но Python – отличный язык для того, чтобы быстро выполнять поставленные задачи. Его относительно легко учить, и с каждым годом он набирает популярность. Если другие языки пришлись вам не по вкусу, вы можете углубиться в него. Лучше всего начать отсюда.



JavaScript


Если вы читаете эту статью с начала, то с JS вы уже разобрались. С пришествием Node.JS и популярностью npm (системы управления пакетами, Node Package Manager), серверный JavaScript несомненно будет и дальше набирать популярность. Стоит изучения.



Если вы раньше этого не сделали, сейчас самое время изучить Node.JS, Express и MongoDB при помощи этого превосходного бесплатного изучающего материала и его продолжения.



Ruby


Это странный язык. Те, кому он нравится, влюблены в него по уши. Он входит в десятку лучших, но рост его популярности замедляется. Он представляет собою гибрид между функциональным и императивным программированием. Рекомендую попробовать – вдруг вы станете одним из ярых его приверженцев. Рабочие места для Ruby будут существовать ещё долго. Но обязательно проверьте свой рынок вакансий, чтобы хоть какие-то компании были заражены интересом к Ruby.



Лучше всего учить Ruby на ресурсе RubyMonk



Что насчёт PHP?


На рынке полно вакансий для PHP, но, по крайней мере, судя по нашей табличке, он теряет популярность. Я выделил его жёлтым, поскольку это всё ещё неплохой выбор для создания карьеры. Если говорить честно, я сам не большой фанат PHP – возможно, это предубеждение играет свою роль. Но я не могу представить, чтобы через 5-10 лет PHP стал бы популярнее JavaScript, хотя сейчас он более популярен, и вакансии для PHP всё ещё будут существовать.



Я много чего изучил, но у меня нет реального опыта





Ну что, давайте наработаем вам опыт!



Без опыта работы очень сложно устроиться на работу. Сначала нужно закончить парочку персональных проектов, чтобы освоиться с их созданием от начала до конца. А когда вы начнёте работать над ними, очень полезным будет изучить способ управления и публикации кода. Для этого вам потребуется GitHub.



GitHub


GitHub это онлайн-репозиторий на платформе Git. Он позволяет хранить, управлять и публиковать код. Если вы уже работаете разработчиком, вы просто обязаны иметь там учётную запись. Изучить работу с GitHub вы сможете из этого обучающего материала «Hello World», а также из интерактивного обучающего материала по использованию платформы Git.



Личные проекты


Разобравшись с GitHub, нужно приступать к разработке своих проектов. И вот вам пара идей:


  • Сделайте простенький блог (вот вам обучалка для React и Node);

  • Сделайте простой календарь (обучалка для C# и .Net).





На ресурсе Free Code Camp вы найдёте разнообразные примеры проектов, включая те, что требуют только фронтенд. Два моих любимых, это:





Реальный опыт


Теперь вам нужен реальный опыт. Это значит, работать на кого-то ещё. Персональные проекты – вещь хорошая, но их недостаточно для того, чтобы успешно соревноваться на рынке работы. Для этого существует несколько вариантов.



1. Внесите вклад в проект с открытым кодом



Благодаря популярности GitHub существуют миллионы открытых проектов, в которых есть проблемы (ошибки), которые только и ждут, чтобы их исправил кто-то вроде вас. Включить в резюме упоминание об участии в известном открытом проекте – это отличный способ повысить ваш статус. Лучше всего найти себе проект по душе при помощи ресурса Code Triage. Он поможет выбрать наилучший проект для вас и будет отправлять вам задачи по почте каждый день.



2. Поработайте на знакомого или родственника



Выберите друга или родственника, владеющего своим предприятием, и сделайте для него веб-приложение или сайт, или улучшите существующий. Только выбирайте аккуратно – вам нужен проект подходящего масштаба. Правильный выбор родственника также поможет вам избежать неприятностей. В идеале вам нужен проект, который вы сможете сделать за срок менее 90 дней, и человек, с которым у вас очень честные взаимоотношения. Не бойтесь признаваться, когда что-то пошло не так, как было запланировано, и не бойтесь отказывать и давать отпор на определённые запросы или ожидания. Также убедитесь, что ваш отказ от проекта или отказ от него вашего партнёра не повлияет на ваши отношения.



3. Поработайте на благотворительные организации



Очень полезный способ набрать опыт – поработать на благотворительные и некоммерческие организации. Вы можете обратиться к милой вашему сердцу организации подобного рода и предложить свою помощь. Вы можете найти нужный проект через сайт Catch a Fire. А если вы полностью пройдёте программу обучения на сайте Free Code Camp и получите все сертификаты, вы получите доступ к некоммерческим проектам, где сможете применить ваши навыки.



4. Рабский труд



Дерзкий получился заголовок для следующего предложения – но, по-моему, если вы выберете этот вариант, а потом найдёте нормальную работу или пойдёте фрилансить, он покажется вам рабским трудом. На сайтах Upwork, Fiverr и PeoplePerHour можно преуспеть в роли разработчика, но вам придётся назначать очень маленькую плату и смириться с положением человека, просто зарабатывающего опыт.



У меня есть опыт, помогите мне с работой





Готовы бросить вызов миру?



Первое правило – не называйтесь «веб-разработчиком».







А что же это за разница такая между веб-разработчиком и разработчиком полного цикла? А вот получается, что разница составляет $7000 в год. Если серьёзно, простая смена названия может решать довольно много.



Сделайте приличное резюме


Несмотря на все весёлые истории про людей, которые вытворяют что-то невообразимое, чтобы привлечь внимание работодателя, вам всё равно необходимо будет подготовить хорошее резюме. Эта статья с ресурса Tech Republic поможет вам с этим.



Создайте веб-сайт с портфолио


Ещё важнее, чем резюме, иметь хороший веб-сайт с портфолио. Возьмите все реальные проекты, которые вы делали, разместите их на персональной страничке. Почитайте хорошие советы по созданию такого сайта в статье с SitePoint. Ещё очень важно пояснить, как именно каждый из ваших проектов решил бизнес-задачу вашего клиента (или работодателя). В таком случае ваш сайт будет на голову выше других.



Подготовьтесь для интервью


С этим вам поможет моя предыдущая статья How to Win the Coding Interview.



Подкачайте необходимые для интервью умения


Вам нужно подготовиться не только к написанию кода. В хорошей статье с Life Hacker описано много полезной и ценной информации.



Главное – закрепиться на рынке


Не сильно переживайте насчёт получения работы мечты у работодателя мечты с зарплатой мечты. Сначала просто добейтесь получения работы, где вы будете писать код за деньги. Получив больше опыта, сможете планировать следующий шаг.



Хочу быть фрилансером


Сам себе хозяин – это хорошо, но это одновременно и огромное давление, и большие сложности. Лучший источник информации по фрилансу из всех, что я видел — DoubleYourFreelancing.com. У него есть серия статей, которые помогут вам стать фрилансером лучше, чем это получилось бы у меня. Читайте.



Ещё один вариант, если вы в себе уверены – сервис Toptal. Они принимают лишь 3% из всех, кто подаёт заявки, и этот процесс очень сложен, но если вы попадёте туда – у вас будет доступ к хорошо оплачиваемым работам, над которыми вы сможете трудиться удалённо.



Я начал работу, но чувствую, что зашел в тупик


Понимаю. Это нелегко, и если кто-то говорил вам обратное – он либо этим не занимался, либо пытается выманить у вас деньги. Если вы чувствуете, что зашли в тупик, попробуйте следующие варианты:



Освежите ваше первоначальное намерение


Спросите себя, запишите на бумаге, почему вы решили идти по этому пути. В силе ли всё ещё ваш ответ? Если да – то зачем останавливаться? Вперёд!



Оцените свои реальные возможности


Теперь, когда вы знаете больше о том, что требуется для реализации ваших желаний, и что вы можете сделать – у вас есть хорошее представление о том, что может случиться в лучшем случае, в худшем случае. Поймите, что, скорее всего в жизни реализуется «наиболее вероятный» случай, который будет чуть ближе к «лучшему случаю», чем к «худшему». Вам не надо бояться – идите вперёд. У вас всё получится!



Прочтите следующую статью



"Не бросайте – каждый эксперт был когда-то новичком"
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303896/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как общаться с заказчиками и договариваться о проектной работе

Понедельник, 13 Июня 2016 г. 11:28 (ссылка)

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



Введение



Когда возникает необходимость создания какого-либо сервиса вообще или мобильного приложения в частности, у заказчика есть три подхода к реализации своей идеи:


  • Создание юр. лица и наём работников в штат (в соответствии с ТК РФ);

  • Заказ работ у студии разработки;

  • Заказ работ у фрилансеров (индивидуальных предпринимателей).



В п. 1. сравниваются затраты для каждого из трёх подходов. И говорится о формировании стоимости разработки.

В п. 2. рассматриваются нюансы общения с заказчиком и жизненный цикл проекта.

В п. 3. говорится, на что следует обращать внимание, общаясь с заказчиком и принимая решение о работе или об отказе от работы.

В п. 4. говорится о спорных ситуациях, путях их предотвращения и о том, что делать, когда они возникают.

В заключении подводится итог проведённой работы.

Доступно также видео доклада c конфенции @CocoaHeads.



1. Сколько стоит труд разработчика



Заказчика интересуют сроки и стоимость выполнения работ. Так повелось, что стоимость разработки измеряют в пересчёте на часы. Как рассчитать стоимость одного часа разработки? Для ответа на этот вопрос нужно понять, сколько стоит такой труд (стоил бы) на наёмной работе, а также узнать стоимость работ у студий разработки. То есть нужно определить сумму, в которую разработчик обходится своему работодателю, а следовательно, и заказчику. Другими словами, нужно определить себестоимость разработчика.



1.1. Как прикинуть свою стоимость



Рассмотрим налогообложение наёмных сотрудников.

Все мы знаем, что у нас в стране существует налог на доходы физических лиц (НДФЛ), равный 13%. Однако не все знают, или делают вид, что не знают, что работодатель помимо 13% НДФЛ отчисляет ещё ряд взносов во внебюджетные фонды (пенсионный — ПФР, медицинского страхования — ФФОМС, социального страхования — ФСС). Подробнее тут.

• пенсионное страхование в ПФР 22% до 796 000 в год (менее 60 000 в месяц net) + 10% от суммы превышения;

• медицинское страхование в ФФОМС 5,1%;

• социальное страхование в ФСС 2,9% до 718 000 в год;

• взносы на страхование от несчастных случаев и профзаболеваний 0,2%-8,5%.

Нужно отметить, что дальнейшие подсчёты несколько упрощены. Существует огромное множество замечаний, «но», льготных видов деятельности, просто льгот. Например, для Сколково взносы в ПФР 14%, а в ФФОМС и ФСС вообще платить не нужно. Эти случаи не рассматриваются. Важно и другое замечание: рассматривается 100% белая зарплата.

Итак, стоимость наёмного сотрудника составляет:

<Зарплата gross> + <Отчисления ПФР> + <Отчисления ФФОМС> + <Отчисления ФСС> + <Страхование от несчастных случаев>

А на руки сотрудник получает

<Зарплата net> = <Зарплата gross> — 13% НДФЛ

Например, как наёмный работник, разработчик зарабатывает 100 000 рублей в месяц или 1,2 млн в год.

<Зарплата net> = 1 200 000

<Зарплата gross> = 1 200 000 / 0.87 = 1 379 310

<Отчисления ПФР> = 796 000*0,22+(1 200 000/0,87-796 000)*0,1 = 233 451

<Отчисления ФФОМС> = 1 200 000 / 0,87 * 0,051 = 70 344

<Отчисления ФСС> = 718 000 * 0,029 = 20 822

<Страхонвание от несчастных случаев> = 1 200 000 / 0.87* 0.002 = 2 758

Стоимость такого разработчика в год составляет

1 379 310 + 233 451 + 70 344 + 20 822 + 2758 = 1 706 687

Это не всё. Наёмный работник имеет множество прав по трудовому законодательству и по доброте работодателя:


  1. Отпуск. 28 дней в году;

  2. Премии;

  3. Как минимум двойной оклад за работу в выходные и праздничные дни;

  4. Оплата больничного. Обычно в убыток зарплате;

  5. Добровольное медицинское страхование;

  6. Компенсация обедов;

  7. Компенсация проезда;

  8. Компенсация (частичная или полная) проживания. Актуально для квартирантов;

  9. Компенсация занятий спортом



И всё это влияет на сумму, в которую наёмный работник обходится работодателю, а, значит, и заказчику. В случае обыкновенного, не социально ориентированного работодателя рассмотрим только п. 1 и случай, когда зарплата не изменялась за последний год, а премии не выплачивались. Тогда за 28 отпускных дней работник получит чуть меньше 1 оклада. Если слегка округлить расчёты, то можно сказать, что работая год по найму за 1,2 млн, стоимость разработчика составляет 1,7 млн.

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

Для расчёта стоимости часа разработки нужно узнать количество рабочих часов в году. В 2016 году их 1974. Вычитаем 28 отпускных дней – 28 * 8 = 224 часа. Тогда стоимость часа наёмного работника составляет

1 706 687 / (1974 – 224) = 1 706 687/1750 = 975



Теперь рассмотрим упрощённую систему налогообложения для ИП.

Налог и взносы ИП:


  1. Налог на доход 6% + 1% за доход, превышающий 300 000 в год;

  2. Взнос в ПФР 19 356,48 рублей/год;

  3. Взнос в ФФОМС 3 796,85 рублей/год.



Мы определили, что себестоимость разработчика составляет чуть более 1,7 млн/год. ИП, заработав 1,7 млн, на руки получает

1,7 млн – 6% – (ПФР+ФОМС) – (1% от 1,7-0,3 млн) = 1,56 млн

В пересчёте на часы получится 895.

Расчёты для разных белых зарплат:







Теперь рассмотрим стоимость работ у студий разработки (отсюда):







Таким образом, разработка в успешных студиях стоит 1500-3200 рублей в час, а среднее значение составляет 2290 рублей. При этом существует нижний порог входа от 0,5 до 3 миллионов (среднее значение 1,28 млн). Правда, этот порог представлен для всего проекта (не всегда на одну платформу iOS). Тем не менее не всегда заказчику нужно много работы на большую сумму. Бывает весь проект будет стоить меньше миллиона. Или ему нужна только мобильная разработка. Случаи когда мобильная разработка дешевле миллиона вообще не редки.

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

Есть и более дешёвые варианты. Стоимость часа работ в таких компаниях дешевле, но за дешевизной может скрываться невысокая квалификация или, что хуже, низкая квалификация, подаваемая и продаваемая под видом высокой.

В студиях обычно выделяется от 10% до 50% времени и денег на управление. Сочетая в себе эти 2 направления (а может, не только эти 2 направления), фрилансер может поднять свой ценник.

Здесь хотелось бы отметить ещё одно из преимуществ индивидуальных разработчиков перед студиями. Отсутствие сложной иерархии “разработчики – руководители – высшие директора”, нет испорченного телефона, нет звеньев, требующих дополнительной оплаты, нет бюрократии. Но есть прозрачность.

Кроме того, находясь с исполнителем в одном городе, заказчик имеет возможность встречаться с ним. Это – прекрасная возможность решить многие вопросы. Такой возможности нет у студий из других городов и стран СНГ. Не всегда удобно общаться электронным способом, живое общение это замечательно, а порой незаменимо. Например, когда заказчик хочет показать что-то на своём устройстве в режиме отладки.

Пример:
Заказчик утверждает, что у него «тормозит» приложение. Я проверил на iPhone 5 – тормозов нет. На встрече оказалось, что под тормозами заказчик имел в виду долгую загрузку списковой структуры, а не лаги при пролистывании.



1.2. Что включать в стоимость



Всё, на что вы тратите своё время:


  • разработка ПО;

  • консультирование в этой области (разговоры и обсуждение);

  • написание ТЗ;

  • время, потраченное на оценку;

  • время на создание приложения в AppStore, сопровождение в iTC;

  • создание снимков экранов;

  • время на заведение учётных записей в различных системах;

  • время на добавление устройств в TestFlight, HockeyApp И так далее;

  • другие издержки.



Кроме того, нужно не забыть использование платных сервисов и ПО:


  • github от 7$/месяц;

  • Photoshop от 300 рублей/месяц;

  • Illustrator 1500 рублей/месяц;

  • Sketch 99$ навсегда.



Работая как ИП, в оплату можно включать расходы на руководителя, директора, уборщицу, на свет, интернет и вообще всё, что угодно. Не забудьте о рабочем месте. Компьютер и тестовые устройства тоже стоят денег. В подсчёте стоимости часа разработчика эти расходы не были учтены. Это означает, что представленные выше ценники – уровень ниже минимального.

Есть и другие статьи расходов:


  • Аренда офиса, она же квартплата;

  • Оплата интернета;

  • Другое.



Если сравнивать с компаниями, то для организаций есть статьи расходов, облагаемые НДС. Это может быть аренда, коммунальные услуги, телефонная связь и многое другое. Эти расходы также включаются в стоимость услуг.

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

Заказчику не обязательно напоминать обо всех этих издержках, за которые платить ему, а вот исполнителю забывать о них нельзя.

1.3. Что включать в стоимость не нужно




  • Apple developer program 99$/год, если у вас есть собственные опубликованные приложения;

  • Sketch, если он у вас уже есть;

  • время, потраченное впустую с другими заказчиками;

  • время на поиск заказчика.





2. Как себя вести исполнителю



2.1. Не повторять чужих ошибок



С экономической точки зрения работа с фрилансерами выгодна. Но многие заказчики не работают с фрилансерами.







Разобравшись, почему так происходит, можно стать очень ценным исполнителем.

Заказчики из жизни и из интернета с негативным опытом работы с фрилансерами отмечают следующие черты:

• Лень, недисциплинированность, неумение управлять собственным временем, срыв сроков, прокрастинация;

• Потеря связи: выключенный телефон, отсутствие доступа к фрилансеру по email, skype, slack итд;

• Недоведение проекта до конца. Даже в ущерб оплате;

• Враньё, увиливание;

• Чрезмерные обещания. Клянутся сделать красиво и классно;

• Желание показаться лучше, чем на самом деле;

• Потопы в квартире, поездки в больницу, поминки бабушек, отключение интернета, смерть хомячков и прочие проблемы;

• Ведут себя как маленькие: обижаются, не признают вину, не предупреждают беды;

• Редко являются хорошими менеджерами;

• Доплата за любой чих;

• Делают не так, отказываются переделывать;

• Работа над несколькими проектами;

• Работают на постоянке, фрилансят по вечерам.

Дело в том, что экономическая сторона вопроса – не самая важная. Для заказчика гораздо важнее:

• Результативность;

• Ответственность;

• Честность;

• Зрелость;

• Гибкость;

• Сосредоточенность.

Проще говоря, заказчику нужен профессионал.







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



2.2. Какую лексику использовать



Общаясь с заказчиком, вы представляете собой руководителя, а не программиста. Разговаривать нужно на чистом языке, используя высокоуровневую лексику взамен жаргонизмам. Как говорил А. Н. Толстой, обращаться с языком кое-как — значит и мыслить кое-как: приблизительно, неточно, неверно. Заказчик может быть не в курсе ИТ-терминологии и может понять вас неверно или вообще не понять.







Пример:
Общаясь с заказчиком, он использовал термин MVP. Я думал, это Model-View-Presenter и недоумевал, зачем он лезет в проектирование. Через 2 минуты я спросил, что такое MVP. «Minimum viable product» — ответил заказчик. То есть продукт с минимумом необходимых функций.



2.3. Знакомство с заказчиком и проектом



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

Если вы видите себя пользователем разрабатываемого продукта, вам понравился проект, обязательно выскажите свои соображения. Возможно, одна из ваших задумок уже записана у заказчика в списке на будущее. А может, она просто будет отмечена заказчиком, как хорошая идея. В любом случае вы продемонстрируете себя не просто как руки, готовые делать только то, что скажут, а как вовлечённый человек, и что вы на одной волне с заказчиком. Быть в теме проекта – ваш большой плюс.

Если вы не видите себя будущим пользователем сервиса, не стоит торопиться давать советы и тем более выступать с критикой. Однако вопросы целевой аудитории сервиса, какую проблему решает приложение всегда уместны.

Если заказчик чего-то не понимает, например, в силу слабых технических знаний, не нужно думать, что он глупый, плохой или что-то ещё. Заказчик обыкновенно – человек, сумевший построить свою жизнь так, что может нанять такого как вы. Ваша задача – коротко и ясно объяснять непонятные вещи. Если ученый не может объяснить, чем он занимается, уборщице, моющей пол в его лаборатории, значит, он сам не понимает, чем он занимается (приписывается Э. Резерфорду).

Если вы заметили, что заказчик хочет выбрать или выбрал неправильные технические решения, обязательно укажите на это и объясните, почему это решение неверное. При этом не забывайте, что последнее слово всегда остаётся за заказчиком.

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

Если вам по каким-либо причинам не хочется браться за проект, нужно уметь отказываться и говорить “нет”. Это – очень нужное умение, отсутствием которого могут пользоваться упорные заказчики.

Не нужно браться за невыполнимые проекты. Следует разделять задачи, которые вы не делали, но можете сделать, от тех, которые вам выполнить в адекватный срок не под силу.

Два примера:
Вы не работали с веб-сокетами. Этой технологии много лет, она обкатана, поэтому вы найдёте подходящую библиотеку и изучите работу с ней. Просто на обзор существующих решений и изучение нужно заложить дополнительное время. Или вам предложили разработать двухмерную или трёхмерную игру. Если у вас нет соответствующего опыта, на реализацию такой задачи уйдёт так много времени, что лучше сразу обратиться к игровому разработчику.



2.4. Оценка времени и денег



Чем больше нечёткости в требованиях, тем выше стоимость. Если вас просят оценить примерно, не стесняйтесь завышать оценку. Когда нечёткость будет разрешена, заказчику будет гораздо приятнее услышать меньшие сроки и стоимость, чем увеличенную на 30, 50, 200 процентов. Да и вообще, морально готовить заказчиков к дорогой работе часто бывает уместно.

Старайтесь внести как можно больше чёткости в понимание границ вашей работы. Если вы задаёте много вопросов до начала работ, чёткость появится и у вас, и у заказчика. Чем больше заказчик видит ваше понимание, тем выше его лояльность. Будет неприятно по ходу проекта вспомнить, что нужно ещё добавить пуш-уведомления, добавить метрики для маркетинга и кучу других мелочей.

Распространена проблема, когда заказчик и исполнитель не полностью понимают, чего они хотят друг от друга. Так называемый, разрыв ожиданий. Например, вы оценили только мобильный клиент, а заказчик, подумал, что в стоимость заложен ещё и бэкенд. Или заказчик хочет сделать регистрацию, думая об имени пользователя и пароле. А исполнитель думает об email и пароле. Или о регистрации через соц. сети. Чтобы снизить риск быть не понятым или не понять заказчика, бывает уместно перефразировать свои вопросы и ответы, убеждаясь, что все всё поняли правильно. Но поскольку всего не предусмотреть, в оценке исполнителя должен быть некоторый запас.

Если у заказчика нет чёткого понимания того, что он хочет, можно предложить ему зафиксировать некоторый объём работ, который оценивается весь. А дополнительный функционал будет оплачиваться по часам. Такая схема стимулирует заказчика напрячь свои силы в сторону конкретизации требований, и страхует исполнителя от бесплатной работы.

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

Бывает, ТЗ в явном виде отсутствует, и оценка формируется только по макетам дизайна. Бывает, что и макетов-то нет.

Пример:
Я делал клиент для программы лояльности одного торгового центра с одним заказчиком. Когда им понадобилось аналогичное приложение для другого ТЦ, меня попросили дать оценку для случая, когда изменится только пользовательский интерфейс: изменятся фоны, расположение кнопок, иконки. В этом случае не было ни ТЗ, ни макета.

Но это редчайший случай, когда требуется выполнить 2 почти одинаковые работы. Поэтому дизайн должен быть обязательно.



Вёрстка приложения занимает примерно половину времени от всей разработки, но в зависимости от сложности вёрстки, трудозатраты могут изменяться в любую сторону. И без макетов можно сильно не угадать в оценке. Кроме того, от дизайна пляшут и другие клиенты (Android, web), а также серверная разработка. В свою очередь дизайн пляшет от бизнес-требований и функциональных требований, т. е. от ТЗ. Отсюда вытекает необходимость наличия ТЗ. И чем на более ранней стадии находится проект, тем очевиднее необходимость в ТЗ. То есть, когда у сервиса нет ни сайта, ни дизайна, ничего, без ТЗ нельзя двигаться дальше. А когда, например, есть сайт, серверная часть, и требуется мобильное приложение, необходимость ТЗ уже не столь очевидна для заказчика. Но лучше короткое ТЗ, чем его полное отсутствие. Достаточно описать, что требуется от мобильного клиента и готово.

Написанием ТЗ может заниматься заказчик, а может исполнитель. Для исполнителя это работа оплачивается. И об этом нужно сразу же сказать. Что вы готовы написать ТЗ, скорректировать по требованиям заказчика, и это будет стоить денег.

При оценке проекта нужно задать вопросы по дизайну:

• анимации переходов между экранами;

• экраны-заглушки (для пустых списков);

• индикаторы загрузки;

• индикация сообщений об ошибках;



При этом, как бы внимательно вы ни оценивали проект, каким бы прозрачным он вам не казался, возьмите некоторый запас на непредвиденные случаи. Размер этого запаса составляет от 15 до 50 процентов и зависит от

• вашего понимания проекта;

• количества мест, с которыми вы не сталкивались ранее. На обзор существующих решений и изучение нужно заложить дополнительное время;

• стиля оценки и некоторых субъективных факторов. Например, вы можете потратить много времени на уточнение деталей и взять меньший запас, или же умножить трудозатраты на 1,5 и быть готовыми к любому повороту.

Пример:


Это – фрагмент дизайна. Нужно выбрать дату и время. Казалось бы, ничего трудного:

• время до 16 часов уже прошло, поэтому оно неактивно;

• время, которое можно выбрать, выделено чёрным шрифтом;

• выбранное время подсвечено оранжевым фоном и белым шрифтом.

Однако, оказалось, что список доступного времени нужно запрашивать у сервера. Для дней также бывают выходные или неактивные даты. Таким образом, задача по выбору даты оказалась не просто вёрсткой, но и скрыла в себе некоторую логику и работу с сетью.



Пример 2:




Это — тоже фрагмент дизайна. Есть сущность Задача (Task), нужно отобразить её атрибуты. С виду обычный список свойств некоторой сущности оказался динамически формируемым списком свойств, а не статическим набором. Кроме того, о некоторых атрибутах TaskAttribute я узнавал с большим опозданием (dontShowIfNull, dataType).







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



Важно понимать, что на некоторые части программы вам придётся уделить значительно больше времени, чем вы думали до начала проекта.

Отдельная песня – взаимодействие с чужим АПИ. Id типа Строка, передача параметров как multipart data, получение «json-строки» вместо json и прочие проблемы. Во избежание проблем с АПИ, очень полезно поинтересоваться о его работе на этапе оценивания проекта. Можно ли изменять выдачу под свои нужды, или АПИ изменяться не будет? Если будет изменяться, как нужно строить взаимодействие с серверным разработчиком: ставить задачи напрямую или через кого-то? Всё это влияет на время, требуемое для запуска обновления на боевом и тестовом серверах. И тут нужно сказать о простое.

Очень часто разработчикам клиентов приходится ждать разработчиков серверной части. Если такое случается в начале или середине проекта, нужно просто переключиться на другую задачу, например, вёрстку. Но когда такое случается в конце проекта, происходит простаивание.

Пример:
Нужно реализовать пуш-уведомления. iOS-разработчик создаёт сертификаты, рассказывает про openssl для конвертации сертификатов в нужный формат, заказывает метод для обновления токена, заказывает payload и реализует обработку payload. И после этого может начаться процесс ожидания.



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

Ещё один пример:
Заказчик хочет реализовать некоторый функционал, требующий работы и на сервере, и на клиенте. Клиент готов, а сервер нет. Можно предложить выпустить приложение, не дожидаясь сервера. А тот функционал добавить в обновлении.



Когда вам предлагают решить сложную задачу, с которой вы не сталкивались, вы имеете право предложить провести блиц-изучение проблемы за короткое время. За деньги, разумеется. По результатам вы сможете дать оценку или скорректировать требования или отказаться от работы, предоставив развёрнутую консультацию.

Если заказчика не устраивает стоимость работ, торговаться можно и нужно. Заказчик может сказать – дорого. И попросить сбросить цену. Но бывает это довольно редко, если он понимает ценность результата, и она выше названой цены. Если сейчас загрузка исполнителя низкая, или заказчик ой как хорош, то исполнителю придется взять на себя риск, срезать «подушку» и согласиться на цену ниже. Если загрузка высокая, или вы любите риск, можно сказать: «Нет, цена такая и только такая, ниже никак». Или можно поторговаться. Главное понимать, что если результаты вашей деятельности имеют ценность, то заказчик легко согласится на ваши условия, и еще будет уговаривать это сделать, иногда повышая цену. А если ценность того, чем вы занимаетесь, ниже названой цены и даже себестоимости, то заказчику стоит задуматься – зачем вообще это делать.

Но если заказчик хочет, чтобы вы сильно демпинговали, вежливо откажитесь: он ещё может к вам вернуться, когда поймёт, что ваша цена нормальная. Или не вернётся, видимо, из-за отсутствия денег. Не нужно цепляться за каждого встречного заказчика. Если заказчик вам не понравился по каким-либо другим причинам, о которых будет сказано ниже, то и в этом случае нужно суметь сказать твёрдое нет. Вообще, отказывать – полезное умение, которое лично у меня начало формироваться совсем недавно и продолжает формироваться с опытом.



2.5. Документы



До начала работ всегда важно соблюсти формальности: составить и подписать договор. Договор описывает отношения между заказчиком и исполнителем. В частности в нём указываются:

• Предмет договора;

• Срок выполнения работ;

• Порядок выполнения, сдачи и приёмки работ;

• Размер и порядок оплаты;

• Срок бесплатной поддержки;

• Ответственность сторон;

• Порядок досрочного расторжения;

• Конфиденциальность;

• Реквизиты сторон.

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

Договор должен содержать в качестве приложения техническое задание и дизайн. Техническое задание состоит как минимум из следующих пунктов:

• Состав работ;

• Требования к программному и аппаратному обеспечению;

• Функциональные требования;

Дизайн позволяет не допустить разрыва ожиданий по части интерфейса.



2.6. Предоплата



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

Откуда взялось это значение – 50%? Половина проекта – это та минимальная часть работы, которую вы выполните во что бы то ни стало. Я не могу представить, что должно произойти, чтобы вы не смогли этого сделать. Для исполнителя эта сумма достаточна, чтобы не остаться без денег, пока длится проект. Нельзя путать: предоплата – это не гарантия платёжеспособности заказчика, а деньги на обеспечение жизнедеятельности исполнителя.

Часто бывает, что исходный код находится на стороне заказчика, а сборки в iTunesConnect заказчика. Это означает, что по завершении работ исполнителю остаётся лишь надеяться на порядочность заказчика, и что он не будет задерживать выплату.

Бывает, что заказчик только к концу проекта начинает проверять работы и не спеша предъявлять претензии. То есть исполнитель уже готов получить оплату, а заказчик – нет. И это – дополнительный риск для исполнителя.

Есть схема, при которой роль администратора в iTC есть только у исполнителя. Тогда вы сообщаете пароль от учётной записи только после последней оплаты. Но если у заказчика уже есть приложения на этой учётной записи, то такая схема не уместна.

50% – это справедливая сумма для обеих сторон. Увеличение или уменьшение предоплаты – перестраховка. По моему опыту заказчик попытается уменьшить предоплату прежде всего, если у вас недостаточно опыта. Исполнитель имеет право увеличить размер предоплаты, если у него сложился негативный опыт с заказчиком. Например, исполнитель шёл навстречу в спорных ситуациях, а заказчик не платил вовремя. Значит, исполнитель зарекомендовал себя хорошо, а заказчик – плохо. И если он хочет работать с этим исполнителем, можно требовать 100% предоплату.

Иногда заказчик может сказать, что ему страшно отдавать 50% незнакомому человеку. Но ответственность ИП всем своим имуществом, а не уставным капиталом в 10 000 рублей как в случае в ООО, разбивает этот довод. Работая по-белому, по договору с ИП, заказчик рискует не более, чем работая со студией разработки.

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



2.7. Работа



Перед началом разработки вам следует продоставить заказчику план выполнения работ. Чтобы обе стороны чувствовали, что всё идёт по плану. Не реже завершения каждого этапа исполнителю следует предоставлять сборки заказчику для контроля. Это – обязательное требование. Заказчик обыкновенно хочет видеть, что процесс идёт, хочет понимать, когда наступит завершение.

Если в процессе реализации проекта у вас возникают проблемы, то об этом нужно сообщать заказчику.

Заказчику следует сообщать о любой нештатной ситуации:


  • о вашей болезни и невозможности работать, если это срывает сроки выполнения работ;

  • если вы собираетесь быть недоступны в сети ближайшие несколько часов, а заказчик собирается с вами связываться;

  • о проблемах в разработке. Если вы столкнулись с проблемой и застряли, обсудите её с заказчиком. Обе стороны заинтересованы в выполнении проекта в срок, а не в жесточайшем следовании ТЗ, дизайну итд. Поэтому вы скорее всего сможете найти компромиссное решение. Или же вы можете узнать у своих коллег, что делать, а сами тем временем приступить к следующему этапу, предупредив заказчика.



Помните: в людях очень ценится ответственность и честность. Ценится даже выше, чем навыки. Свободные художники, не способные управлять своим временем, следовать договорённостям, выходить на связь, исполнители, срывающие сроки, утаивающие проблемы, исполнители, которые берутся за невыполнимые для себя задачи, доставляют только головную боль своим заказчикам и редко доводят проекты до конца. Для фрилансера, годовой оборот которого редко превышает пять проектов, репутация, рекомендации заказчиков и расширение профессиональных связей – залог загруженности работой и повышения своей стоимости в будущем. Всё это возможно только после того, как он покажет своим трудом и результатами, что достоин этого.



2.8. Завершение проекта



Каждый проект нужно завершать подписанием акта о выполнении работ, в котором указано, что работы выполнены в срок, в полном объёме, и что заказчик не имеет претензий к исполнителю. Об этой бумажке часто забывают.

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



3. Как отличить хорошего заказчика от плохого



Проверяйте заказчика «на вшивость». Если место встречи предлагают выбрать вам, договоритесь встретиться в хорошем кафе. Если заказчик готов платить сотни тысяч или миллионы рублей за разработку, он скорее всего заплатит и за ваши кофе и пирожок. На встрече вы проводите полноценную консультацию. Хороший заказчик понимает, что это не должно быть бесплатно, и оплачивает счёт.

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

Хороший заказчик приходит к вам с идеей и хочет узнать, сколько стоит её реализация. Плохой заказчик приходит с бюджетом и хочет в него уложиться. Такой заказчик может вести торг, обоснованный только отсутствием денег. Например, можно спросить, что нужно изменить в проекте для уменьшения стоимости. А можно тупо просить скидку 20%. Прижимистые заказчики как можно раньше хотят определить точную стоимость работ, несмотря на их нечёткость на начальном этапе.

Если на начальных этапах у вас возникают проблемы (обычно из-за денег), то дальше лучше не будет. Негативный опыт учит, чем дальше в лес, тем больше дров. Например, если заказчик задерживает предоплату, предлагает хитрые схемы оплаты, при этом форсирует начало работ, он скорее всего перестраховывается (проверяет вас) или у него просто нет денег. Следовательно и дальше можно ожидать недоверия или задержек по выплатам.

Если заказчик в ходе проекта обманул вас хотя бы однажды, в будущем с этим заказчиком иметь дел не стоит. Если были проблемы только с выплатами, то в будущем работать можно, но по 100% предоплате.

Обычно заказчика интересует срок выполнения работ и его стоимость. Реже заказчик интересуется стоимостью часа вашей работы. Ещё реже интересуется, сколько вы собираетесь зарабатывать в месяц. На этом вопросе можно прекращать разговаривать.

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

Хороший заказчик умеет слушать и нередко больше слушает, чем предлагает. Такой заказчик может записывать отмеченные вами моменты. Потому что в технических вопросах экспертом выступает опытный исполнитель, а не заказчик. Хороший заказчик сам поинтересуется вашим мнением о том или ином техническом решении. Первая встреча может дать заказчику богатую пищу для размышлений, и заказчик может взять паузу на обдумывание. Хороший заказчик обязательно сообщит о своём решении, плохой заказчик может пропасть после первой встречи совсем или «всплыть» через месяц, хотя собирался ответить через несколько дней.

Заказчиков можно условно разделить на тех, кто вообще не знаком с ИТ, и тех, которые что-то да понимают. Кто лучше? В этом вопросе мнение коллег разделилось. Я считаю, что заказчиков с «ИТ-бэкграундом» стоит опасаться. Такие люди имеют свои представления о том, как нужно работать. При этом скорее всего их опыт поверхностный, потому что из ИТ они перешли в управление или куда-то ещё. Такие люди порой считают себя выше разработчиков, дороже разработчиков. От них можно услышать: «А почему так долго? Я бы на PHP за 2 часа сделал». Или «Я в институте писал на C++, мне кажется, тут будет нетрудно сделать». Такие заказчики порой предлагают вам свои «готовые» решения. Или им может казаться, что кругом полно типовых задач, которые практически бесплатно переделываются под нужды разных заказчиков. Например, был один интернет-магазин, значит, сделать любой другой будет быстро и дёшево.

Кто-то, напротив, предпочитает общаться с подкованными в ИТ людьми. Объясняя это тем, что таким заказчикам проще растолковать низкоуровневые проблемы. Или что такие люди задают меньше глупых вопросов.

Хороший вариант – работать с заказчиком, имеющим опыт в ИТ-проектах. Плохой или хороший. Заказчик с хорошим опытом понимает стоимость разработки и понимает величину доходов от успешного проекта. Заказчик с любым опытом понимает важность чётких формулировок, ясных целей, необходимость ТЗ.

Хороший заказчик может сам спросить о предоплате. А если и нет, то спокойно воспринимает информацию о ней. Хороший заказчик также, говоря об изменениях, первым подчёркивает, что изменения требует дополнительной оценки и оплаты. Плохой заказчик не только торгуется на этапе предоплаты, но и доп. работу не хочет оплачивать сразу. Например, просит включить стоимость доп. работ в следующий этап. Это – очень распространённый ход, целью которого является рассрочка и удерживание исполнителя на коротком поводке. Нет гарантий, что следующий этап не наступит никогда или будет проходить без вашего участия.

Хороший заказчик чётко видит и понимает свой проект, позитивно настроен. А там, где он видит нечёткости, старается вникнуть и разрешить нечёткость. Плохой заказчик плавает в своих требованиях, из-за чего может вносить изменения тех или иных частей проекта уже в процессе реализации.

Хороший заказчик смотрит предварительные результаты работ. Это позволяет устранить разрыв ожиданий на ранних стадиях. Плохой заказчик ждёт, когда будет готово всё, а потом заваливает претензиями.

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

Более того, если заказчик – ваш знакомый или знакомый знакомого, то это – совсем другой разговор. По собственному опыту скажу, абсолютно всем моим заказчикам меня рекомендовали знакомые, прошлые заказчики и их знакомые. Можно ли им доверять, честные ли это люди – проверять исполнителю и лучше перестраховываться. Наличие позитивного опыта с заказчиком, совершенно не означает адекватность его партнёров и знакомых. Если заказчика привёл ваш знакомый, задайте своему знакомому несколько вопросов о заказчике. Кто он, чем занимается, как они общаются? Проявлял ли он себя с хорошей или плохой стороны?



4. Разрешение спорных ситуаций



Существуют 2 главные проблемы, составляющие суть споров:


  1. неоплата и задержки при оплате;

  2. определение объёма работ.



Первая проблема частично решается предоплатой. Обе проблемы практически полностью решаются договором. Договор описывает отношения между заказчиком и исполнителем и обязательно включает в себя 2 приложения: ТЗ и дизайн. Поэтому при наличии договора даже если возникают споры, их можно разрешить справедливо.

Никто не любит формальности, но и формалистов тоже никто не любит. Поэтому нужно быть гибким. Если заказчик решает что-то изменить по ходу реализации, то возникает спорная ситуация. Я, например, делаю так. Если работа, требующая изменений ещё не начата, я соглашаюсь внести изменения. Если же работа уже начата или сделана, то изменения требуют дополнительной работы, и тогда нужно писать доп. соглашение с ценой этой работы. В конце концов всё зависит от трудозатрат, требующихся для реализации изменений. Если работы мало, вы можете сделать её и бесплатно. Так вы заработаете несколько очков репутации в уступчивости, гибкости. Заработаете лояльность заказчика. Сегодня уступили вы – завтра можете просить уступить вам.

Что делать, если вам задерживают оплату? Юридически у вас есть договор с указанными сроками выполнения работ. Когда всё готово, заказчик должен подписать акт об их выполнении. Или предоставить свои претензии. Поэтому при составлении договора внимательно указывайте сроки. С одной стороны так, чтобы иметь небольшой запас, и, с другой стороны, чтобы вам не пришлось ждать оплаты несколько месяцев. Если же письменный договор составлен не был, то, во-первых, это нарушение ГК РФ, а, во-вторых, риск исполнителя остаться без денег или ждать их неопределённый срок.

Пример:
Заказчик отправил мне договор на подпись по электронной почте. Я распечатал договор, подписал его, отсканировал и отправил обратно. Получил предоплату, начал работу. А получить подписанный экземпляр заказчика забыл. Заказчик тоже забыл или сделал вид, что забыл. К концу проекта со стороны заказчика обозначились некоторые проблемы, требующие отсрочки закрытия проекта. И мне пришлось ждать, пока заказчик разрешил свои проблемы.

Вывод: начинать работу до получения предоплаты – огромный риск потерять время и остаться без денег, но нельзя забывать и о подписании договора: он определяет сроки оплаты.



Конечно, проблемы могут возникать и с наличием на руках подписанного заказчиком экземпляра. Заказчик может объявить о каких-то проблемах, например, серверная часть что-то не успевает сделать или существуют нетехнические проблемы (заведение аккаунта в iTC, продление Apple developer program, денежные проблемы, наконец). В таких случаях вы можете пойти навстречу заказчику и подождать. А можете просить оплату по договору, а доделки выполнить, когда будет возможность, бесплатно. Вопрос, сколько ждать. Будьте осторожнее: заказчик, почувствовав вашу слабость, вряд ли упустит возможность этим воспользоваться.

В общем случае, нужно стараться решать проблемы так, чтобы вы не выглядели как упрямый баран, но в то же время нельзя давать прогибать себя слишком сильно или слишком часто. Другими словами, нужно уметь договариваться.

Если для реализации какой-либо части проекта предполагается использовать готовые компоненты (например, чат или хранилище для медиа-файлов), принятие решения о выборе компонента необходимо согласовывать с заказчиком. Опять-таки предоставив ему консультацию в области существующих решений на рынке. Для проведения такой консультации исполнителю нужно будет провести ознакомление с такими решениями, узнать цены, ограничения и прочее. Исполнитель, не согласовавший свой выбор с заказчиком, берёт полную ответственность за возможные проблемы на себя.

Если вы взяли крупный проект, и люди, за работу которых вы отвечаете, не справляются, пропадают или срывают сроки, возникает спорная ситуация. Кто виноват и что делать? Если вы – человек ответственный, то вину берёте на себя. Потому что это вы набрали такую команду. Иногда приходится работать с меньшей выгодой или даже в убыток, но не потеряв репутацию и лицо. Сетовать на кого-то в таких ситуациях крайне непрофессионально. Порядочный человек всегда выполняет свои обязательства перед другими и не боится ответственности. При возникновении проблем с другой стороны (заказчик отказывается платить), вы также ответственны перед своими коллегами, потому что они договаривались с вами, а не с вашим заказчиком. Для того и берётся предоплата, вводятся этапы, чтобы свести к минимуму риски опростоволоситься перед коллегами.



Заключение



Индивидуальные разработчики могут зарабатывать больше, чем наёмные работники, при этом всё ещё оставаясь более дешёвыми исполнителями для заказчика. Поэтому заказчики нередко обращаются к фрилансерам. Но часто заказчикам куда важнее профессионализм исполнителя, чем возможность сэкономить.

Деятельность и зона ответственности такого разработчика уходит далеко за пределы только технической работы. Фрилансер материально ответственен за свои слова и принятые решения, которые закрепляются в договоре. Поэтому к своим решениям нужно подходить очень взвешенно. Семь раз отмерь – один отрежь.

Принятие решения о начале работ с заказчиком или отказ от сотрудничества – главное решение в каждой работе. Это решение должно быть хорошо взвешено. Не нужно бояться говорить “нет”. Лучше 2 недели простоя, чем 2 месяца геморроя. Приглядитесь получше к заказчику.

Если вы берётесь за работу, то отвечаете за результат не только деньгами, но и репутацией. Взялся за гуж – не говори, что не дюж.

Бумажки играют важную роль в отношениях между заказчиком и исполнителем. Особенно их роль возрастает при возникновении проблем. Серьёзность отношения к договору, приложениям к договору, ТЗ, акту о выполнении работ не зависит от степени близости с заказчиком. Будь то друг или человек из другого города. Эти документы вносят ясность не только в спорных ситуациях, не только оказывают профилактическое действие, но и просто упорядочивают процесс разработки.

Ссылки

Original source: habrahabr.ru.

https://habrahabr.ru/post/302340/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Матрица прокрастинации (откладывания дел «на потом»)

Воскресенье, 13 Июня 2016 г. 00:34 (ссылка)

Для лучшего понимания этого поста, прочитайте сначала предыдущий пост про прокрастинацию.



Если бы, когда я учился в школе, вы спросили меня прокрастинатор ли я, я бы конечно ответил “да”. Учеников школы учат “держать темп” с крупными проектами. И я гордо не торопил себя больше чем кто-либо кого я знаю. Я никогда не пропускал дедлайн, но делал все ночью перед сроком сдачи. Я был прокрастинатором.



На самом деле я не был. Учебная программа в школе полна дедлайнов и коротких заданий. И даже долгие проекты состоят из промежуточных дедлайнов, которые не позволяют сильно расслабиться. Было всего несколько ужасных моментов, но в большинстве случаев, я все равно делал все в последнюю минуту, потому что знал, что все со мной будет хорошо, так почему бы нет.



Без всякого сомнения в моей голове была Обезьянка Немедленного Удовольствия, но она была милее всего не свете. С постоянно маячащими дедлайнами, Панический Монстр никогда не спал и обезьянка знала об этом. Она конечно постоянно отвлекала, но не была за главного.



Мой мозг в школе:

image







image

— Если я сейчас сделаю домашнюю работу, я смогу потом посмотреть ТВ

— Или!



image

Или ты можешь позаниматься фигней в течение 4 часов и увеличить уровень стресса!



Спустя 4 часа:

image



image



image

Достаточно, обезьянка! Теперь действительно время поработать!



Однажды школа закончилась, и вместе с ней закончилась моя жизнь в качестве нормального человека. Колледж не похож на школу. Задания крупные, с большим количеством времени между дедлайнами, и так как ты уже не ребенок, никто не относится к тебе как ребенку — никто не заставляет держать темп. Большинство моих занятий включали несколько курсовых работ, экзамены в середине семестра и окончательный экзамен в течение 4 месяцев, что значит на горизонте не было никаких строгих дедлайнов.



Без дедлайнов, мой Монстр Паники, который не может думать слишком наперед, проводил много времени в спячке. Мой Человечек, Принимающий Решения (ЧПР), который не когда не осознавал как сильно он всегда полагался на Монстра Паники, начинает испытывать трудности с выполнением планов.



image

— Чтобы получить наибольшую пользу от занятий, нужно прочитать заданное.

— Никогда никогда



image



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



image

— Эй! Мы идем в кино. Пойдешь с нами?

— Я бы с удовольствием, но мне нужно работать. В другой раз.



image

— До срока сдачи курсовой работы осталось всего 2 дня. Это было правильное решение.

— Очаровательно



Спустя 2 часа:

image

— Какой прекрасный фильм!

— Как твоя работа?



image

Работу сдавать через 5 часов, а я еще даже не начал. Как я опять это допустил?



image



image



image

Не важно каким очевидным было решение для ЧПР (Человечка, Принимающего Решения), совершенно ясно он был не в состоянии контролировать Обезьянку без помощь Монстра Паники.



image

Подождите… подождите… было продолжение



image

Было продолжение восхвалять каждую хрень



image



image

Слишком хорошо, чтобы быть правдой. Минуту назад я ругался на себя за то, что довел дела до такого ужасного положения. А теперь, как будто сам Бог, мне подарили новую жизнь. У меня теперь достаточно дополнительного времени о котором я мечтал. Я могу расслабиться, действительно заняться курсовой и сделать ее. Это лучшее…



image

Время для развлечений



В то время как для ЧПР колледж был чаще всего обескураживающим опытом, для Обезьянки это было полным ренессансом, которая изучала весь спектр активностей в поисках себя. С синтезатором рядом с моим столом, обезьянке невероятно хотелось поиграть на пианино. Было ощущение, что чем сильнее нужно было поработать тем сильнее Обезьянке хотелось надеть наушники и поиграть на пианино.



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



Мой ЧПР много об этом думал, и понимал, что в колледже обезьянка пыталась сказать ему кое-что очень важное — я хочу быть композитором. Очевидно это была вещь, которой я был полностью поглощен, и наконец, это станет тем чем мне следовало бы заниматься каждый день. Никаких больше сражений с Обезьянкой — она наконец получила бы то что хотела. Я разобрался в жизни и переехал в ЛА писать музыку к фильмам.



Чтобы оплачивать счета, я начал заниматься с детьми в школе их домашней работой и подготовкой к SAT (тест для приема в университет в США). Я выбрал эту работу, потому что она не отвлекала бы меня от становления следующим Джоном Уильямсом (американский композитори дирижёр, один из самых успешных кинокомпозиторов в истории — прим. пер.). Затем случилась самая странная вещь. Только я был уверен, что нашел себя, Обезьянка начала душевные поиски. Когда ЧПР и я садились бы за пианино написать что-то — Обезьянка отказывалась присоединяться к нам. ЧПР начинал чувствовать себя беспомощным, как в колледже.



Тем временем, Обезьянка нашла новый интерес — ее заинтересовала моя репетиторская работа. Все шло хорошо, рекомендации росли и как только ЧПР настаивал, что мы уже работаем со слишком большим количеством учеников, Обезьянка принимало каждое новое входящее предложение о работе. Затем Обезьянка начала мыслить шире и нанимать моих друзей, которые бы занимались репетиторством для меня. Весь день проходил за телефонными звонками. Обезьянка занялась бизнесом.



Обезьянка отказывалась давать нам возможность заниматься музыкальной карьерой, а ЧПР отказывался включаться в бизнес карьеру Обезьянки.



image



Это было в то время когда мой лучший друг Эндрю переехал в ЛА. Эндрю не такой как я. Он живет и дышит бизнесом, без какого либо интереса достичь чего-либо в искусстве, и с тех пор как я его встретил когда мне было 5, его обезьянка были приученной маленькой заразой, которая делала что ей скажут. После переезда мы обсуждали возможность заняться бизнесом вместе каким-то образом. Мой ЧПР отказывался воспринимать бизнес серьезно, но перспектива заняться бизнесом с Эндрю и действительно приложить к этому все усилия была соблазнительна. И Обезьянка очевидно была очень заинтересована в бизнесе, там что может быть ЭТО то, чем я должен был бы заниматься на самом то деле. Мы вместе основали репетиторскую компанию.



ЧПР все еще боролся с решением отложить музыкальную карьеру, но компания быстро росла и ЧПР потихоньку начал чувствовать себя “ок" по поводу бизнеса.



Что для Обезьянки стало сигналом стать заядлым блоггером



image

Ой, да ладно тебе



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



В 2013 году Эндрю и я решили начать что-то новое, мы посмотрели на обезьянку и ее погруженность в блог и решили может быть ЭТО то чем я должен был бы заниматься все это время. И мы начали Wait But Why. Эндрю бы продолжал развивать компанию, а я бы полностью погрузился в новый проект, дав Обезьянке то, что она так страстно желала.



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



Это то, чем я занимался. Каждый раз когда Обезьянка увлекалась чем-то новым, я строил свою жизнь вокруг этого увлечения. Проблема была в том, что это было похоже на мираж. Как только я оказывался там, Обезьянки там уже не было. Она была где-то в другом месте. Это сбивало с толку. Была она там, потому что хотела там быть или потому что там не было ЧПР. Были ли это действительно ее призвания или она постоянно отвлекала меня от достижения чего-либо великого с моими талантами и энергией?



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



image



1 квадрант = важное и срочное

2 квадрант = важное, но не срочное

3 квадрант = срочное, но не важное

4 квадрант = не срочное и не важное



Матрица Эйзенхауэра относит все что вы делаете в 2 спектра: от самого срочного до самого не срочного, и от самого важного до не важного.



Матрица была популяризирована книгой Стивена Крови “Семь навыков высокоэффективных людей” и названа в честь президента Эйзенхауэра. Эйзенхауэр был известен своей необыкновенной продуктивностью, которую Кови кредитует к его “первые вещи первыми” отношению к трате времени. А для Эйзенхауэра “первыми вещами” всегда были важные вещи. Он верил, что вы должны проводить практически все свое время в квадранте 1 и 2.



image



Q1 — делать сейчас

Q2 — решить когда делать

Q3 — делегировать

Q4 — удалить



И это отлично для Дуайта черт его возьми Эйзенхауэра. Но знаете ли вы, чего не было у Эйзенхауэра в его лысой голове? Всемогущей Обезьянки Немедленного Удовольствия. Если бы была, он бы знал что матрица прокрастинатора выглядит так:

image



Q1 — делать когда из срочного превращается в ужасающе срочное

Q2 — делегировать для будущего себя

Q3 — делать когда Q1 срочен

Q4 — делать сейчас



Если вам нужна любая информация по квадранту 4 — как доехать, где покушать и так далее — спросите любого прокрастинатора. Они там живут. Для не-прокрастинатора, Q4 счастливое место проведения времени. После продуктивного дня, поработав над важными задачами, очень приятно проводить время в Q4. И для этого квадратна есть название — _Счастливая Игровая Площадка_. Но прокрастинаторы не имеют тенденции проводить там время после продуктивного трудового дня — они там гораздо чаще, против их воли, потому что Обезьянка затащила их туда, в то время как ЧПР умолял уйти оттуда. И у них для этого квадранта есть свое название — Темная Игровая Площадка.



Что до квадрантов 1 и 3 — срочных квадрантов — большинство прокрастинаторов окажутся там время от времени, обычно в холодном поту, с кричащим у их лица Монстром Паники.



Есть еще Q2. Для прокрастинатора, Q2 — странное и незнакомое место, где-то далеко далеко. Типа Атлантиды, или Нарнии. Он знает, что это важное место, и много раз пытался туда попасть, но есть проблема — Обезьянка отказывается туда идти, а Монстр Паники не очень обеспокоим им. И это смертельная комбинация.



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



Если ты прокрастинатор — тебе повезло. У нас есть туз в рукаве — кое-кто отважный и бесстрашный, с безграничной энергией и талантом, кто-то кто может побороть Обезьянку так же легко как наступить на муравья — Будущий Ты.



Будущий Ты — твой самый важный союзник — кто-то кто всегда там и готов поддержать не смотря ни на что. Я знаю все об этом парне. Будущий Тим — отличный парень.



Мой список дел состоит из двух частей — короткой, легкой части для меня, и длинного, состоящего из вещей которые я даже не могу представить что я буду делать, потому что они заставляют меня нервно чесаться. Будущий Тим всегда справляться с ним, без жалоб. У Будущего Тима также нет никаких проблем с мерзкими социальными обязательствами. Меня недавно пригласили на дать фидбек 3-4 часовому спектаклю, написанному кем-то кого я практически не знаю. У меня конечно не было никаких намерений участвовать, но я бы чувствовал себя виноватым ответив отказом. Поэтому я сказал, что у меня очень занятые 2 месяца, в противном случае я был бы счастлив присоединиться в следующий раз этим летом, тогда это будет проблема Будущего Тима, не моя.



Будущий Тим также обладает дисциплиной и балансом жизни о которой я мог бы только мечтать. Я никогда особенно не ходил в тренажерный зал, но Будущий Тим живет в нем и делает все упражнения за нас обоих. И мне нравится как Будущий Тим увлечен здоровым питанием, потому что персонально у меня на это нет времени. Будущий Тим — это такой парень на которого мы все хотим быть похожи. Узнать его можно будет, купив его книги, ибо он плодовитый автор.



Но наиболее важная роль, которую играет Будущий Тим в моей жизни, возвращает нас к Матрице Эйзенхауэра. По счастливому совпадению, Будущий Тим больше всего времени проводит в месте, в которое я бы сам никогда не попал, в Q2. Будущий Тим — смотритель Q2. И когда я составляю список важных дел и замечаю, что большинство из них приходятся на Q2, мне не нужно отчаиваться, я знаю что Будущий Тим над ним. Что хорошо, принимая во внимание в какой ужасной ситуации Прошлый Тим, этот бесполезный хер с горы, меня оставил:



image

Посмотри на себя, сраный Прошлый Тим. Ты единственная причина по которой мы сейчас в этой ужасной ситуации. Видишь вон там Будущего Тима? Слава Богу, он здесь, чтобы все исправить. Я бы сам убрал твой беспорядок, если бы не был занят с этой чертовой Обезьянкой.



Но ко всем достоинствам Будущего Тима, у него есть один недостаток, который типа все портит: он не существует.



Оказывается Будущий Ты — это такой же мираж, как и Обезьянья страсть к хобби. Будущего Тима никогда не оказывается рядом, есть только эта бестолочь Настоящий Тим. Который не может выполнить никаких задач, так как они могут быть выполнены только кем-то без обезьянки. Ты ставишь задачи Будущему Тебе и все надеешься, что он будет существовать.



Вот что произошло, когда я преследовал карьеру композитора:

image

Q1 — ничего

Q2 — все важные вещи для моей карьеры композитора

Q3 — репетиторство с учениками

Q4 — управление репетиторской компанией



И когда я решил последовать за Обезьянкой и заняться бизнесом, я пропустил важный момент: “заняться” бизнесом означало сделать бизнес тем, чем мне следовало заниматься, что перевело его из разряда не важных задач в важные задачи — перемещение из Q4, любимое место Обезьянки, а Q2, наименее любимое.



image

Q1 — управление репетиторской компанией

Q2 — развитие репетиторской компании

Q3 — тонна незначительных вещей, которые отнимают как минимум половину моего времени

Q4 — блоггинг



Тот факт, что я думал Обезьянка сохранит увлеченность бизнесом после перемещения его в Q2, говорит о том как мало я понимал Обезьянку. Страстью Обезьянки никогда не была музыка или бизнес или блоггинг. Страстью Обезьянки всегда была Q4.



Когда я начал писать посты для Wait But Why, я знал что хочу писать про прокрастинацию. Нужно было как-то выговорить то безумие, которое происходило в моей голове. Однажды я это сделал.



Реакция была ошеломляющая. В дополнение к 1 300 комментариям, я получил огромное количество e-mailов:

image

— Emailы по поводу прокрастинации

— Emailы по поводу остальных постов блога



Тысячи email-ов. Похоже все это не только обо мне.



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



Профили тех, кто мне писал сильно отличались. Все возраста, разные профессии из почти всех стран мира. Но у всех у них и у меня в том числе была одна и та же проблема — Обезьянка Немедленного Удовольствия, которую невозможно контролировать. Ноя заметил одну вещь. Различия между историями можно разделить на 3 категории:



1. The Disastinators (Катастрофики)



image



Из всех прокрастинаторов катастрофики — самая худшая форма. Катастрофик постоянно находится в Q4, и прокрастинация полностью уничтожает их жизнь. Чаще всего прокрастинатор становится Катастрофиком по 2 причинам:



А. Их обезьянка перестала бояться Монстра Паники и стала всемогущей

Б. Они обычные прокрастинаторы, но в их жизни нет никакого внешнего дедлайна или давления



Ситуация А очень мрачная, и как я узнал из писем, не такая уж и редкая. Эти люди потеряли способность делать практически все что важно для них и либо летят вниз по спирали либо сдались совсем.



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



image



В результате Катастрофики не чего не выполняют, никогда. Многие доктора философии попадают в эту категорию



2. The Impostinators. (Жулики)



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

image



Жулик кажется продуктивным, но на самом деле он самозванец — прокрастинатор, надевший маску продуктивного человека. Он кажется всегда занятым, так как проводит много времени в Q3. Он на самом деле занят. Но похоже никогда не добивается прогресса в истинных целях.



У Жуликов умные Обезьянки, и Q3 самый умный трюк Обезьянки. Обезьянка знает, что ЧПР может быть довольно легковерным, может быть успокоен если большую часть времени она проводит вне Q4 Темной Игровой Площадке. Обезьянка Жулика устраивает битву между Q3 и Q4, и это работает так как Q3 чувствуется продуктивным. Жулику кажется, что быть занятым = продуктивным.



Жулик будет весь день отвечать на email, звонить по телефону, выполнять поручения, организовать списки и расписания, участвовать в совещаниях. Т.е. если осуждать себя только за время проведенное на Темной Игровой Площадке, то можно считать это успехом. Но в конце дня удовлетворенность от проделанной работы кажется пустой и Счастливая Игровая Площадка никогда не приносит полного состояния счастья. Он может и сбил себя с толку, думая что живет продуктивной жизнью, но в подсознании, он знает что не занимается тем чем ему следует заниматься. Его чувство выполненного долга идет бок о бок вместе с затаенным отчаянием.



Другая сложность для жулика заключается в том, что иногда Q3 маскируется под Q1. Занятой Жулик часто верит, что срочная работа, которой он занимается является важной, но как сказал Эйзенхауэр:



То что важно — редко срочно, а то что срочно — редко важно.




Другими словами Q1 чаще всего не существует. Не всегда так, но скорее всего для большинства людей которые только развивают свою карьеру это так, потому что если если что-то важное на самом деле срочное, значит с вашей развивающейся карьерой происходит что-то хорошее.



Но чем дальше, тем больше ваша постоянная занятость означает, что вы все время тратите в Q3 (в перемешку с Q4). Я знаю, что когда я в зоне когда говорю всем вокруг как я занят и что у меня на них совсем нет времени, это почти всегда происходит из-за загруженности в Q3 всякой хренью. Люди, которые действительно на вершине своей жизни, у которых все под контролем, имеют более свободное расписание. Но общество улыбается занятым людям. Фраза “Я думаю у вас слишком много свободного времени” — это оскорбление, поэтому Жулики чаще всего выглядят и чувствуют себя так будто делают все верно. В то время как Жулик всегда будет чувствовать превосходство над Катастрофиком, правда в том, что в терминах продуктивности они равны.



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



Самые частые профессии в этой категории — артисты и предприниматели. В обоих случаях, вы хозяин своей жизни, и важная работа, такая как развивать ваши навыки, увеличивать круг общения, работать над креативным видением, очень редко является срочной.



3. The Successtinators (Успешники)



После того как я начал Wait But Why, я написал 250 000 слов. Это примерно 1000 страниц в книге. И то что я делаю действительно важно для меня. Впервые, удовлетворение от выполненной работой не идет вместе с чувством вины или пустоты. Я это сделал! Я — делатель!



Не совсем.



В реальности я не преодолел проблемы моей Обезьянки ни на грамм больше чем Катастрофики или Жулики. Разница в том, что я загнал себя в ситуацию с большим, толстым Q1 в моей жизни. Ни фейковый Q1, который на самом деле Q3, а настоящим Q1.



Для прокрастинатора это обратная ситуация типу PhD, который я описал как катастрофический для прокрастинатора. Регулярно писать для большой аудитории идеально для прокрастинатора. Это делает Монстра Паники вашим близким другом.



С другими проектами, моя Обезьянка проводила время в Q4 преследуя амбициозные проекты и ей было позволено делать это, так как ЧПР не был уверен в том, чего хочет он сам. Но пока что работа над Wait But Why удовлетворяет ЧПР. Он позволяет Обезьянке танцевать вокруг Q3 и Q4, потому что у него нет власти не позволять, но он не позволит Обезьянке заняться чем-то серьезным.



На текущий момент я — Успешник. Наименьшее зло из всех трех типов.



image



Успешник нашел решение, ну или типа того, своих проблем, но оно не лучшее, чаще всего не очень полезное для здоровье и чаще всего не устойчивое. Умное заклеивание скотчем проблемного механизма для поддержания временной работы.



Успешники могут быть счастливы по поводу своей жизни, но чаще всего не счастливы в своей жизни. Это потому что Успешничество не делает вас успешным. Кто-то кто успешно что-то делает в своей профессиональной жизни в ущерб балансу, отношениям, и здоровью не является успешным человеком. Быть успешным значит быть успешным как в профессиональной, так и личной жизни. А Успешники находятся в постоянном стрессе, слишком недоступны и часто лишены Счастливой Игровой Площадки, а это критичный компонент счастливой жизни. Успешник часто ограничим в своих профессиональных возможностях. Отличная работа может быть проделана в Q1, но чаще всего это поддержание текущих дел. И как все прокрастинаторы, Успешник редко занимается Q2.



В мире существуют и бОльшие проблемы чем прокрастинация. Бедность, болезни, психические расстройства, и наркотическая зависимость заставляют прокрастинацию выглядеть как проблему для привилегированных. Типа страдания для тех людей у которых нет настоящих страданий.



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



Проясняя заблуждение

Если вы хотите увеличить продуктивность, первый шаг — это начать воспринимать мир сквозь Матрицу Эйзенхауэра. Нужно научиться разграничивать срочное и важное. “Что имеет для меня наибольшее значение?” — вопрос над которым стоит серьезно подумать.



Брет МакКей определяет “важную задачи” как вещи, которые окажут влияние на долгосрочную перспективу и цели.



В идеале, срочными будут не дела, “которые хватают вас за воротник”, а список вещей который принесет максимальную пользу раньше чем позже. Используя это определение, время с детьми точно подпадает под срочное, тогда как по типичному определению оно не срочно. Порядок ваших приоритетов должен быть определен ЧПР, а не Монстром Паники.



Вам, возможно, захочется понять как сейчас вы расходуете время, записывая часы в течение недели и видя как много из них падает в Q4. Скорее всего вы будете неприятно удивлены.



Становление боссом вашего мозга

Как только вы разберетесь со своей Матрицей Эйзенхауэра, начнется самая сложная часть — взять контроль над тем как вы тратите свое время. Для прокрастинатора, величайшее жизненное испытание.



Награда очевидна. Невероятно как много может сделать один человек, поддерживая при этом баланс в жизни, когда он контролирует куда тратит время. А те, кто проведут время в Q3 и Q4 будут чувствовать, что у них нет времени либо на работу либо на личную жизнь, и при этом достигая очень малого.



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



Единственная возможность это сделать — Сюжетная Линия.



На глубоком уровне все сводится к битве уверенности. У ЧПР и Обезьянки свои представления о том как нужно проводить время. И у кого из них больше уверенности, что он альфа-самец, тот и превалирует. Разница между прокрастинатором и не-прокрастинатором в том, что и Обезьянка и ЧПР в голове прокрастинатора оба верят, что Обезьянка является альфа-самцом, тогда как не-прокрастинатор верит, что босс — ЧПР.
Original source: habrahabr.ru.

https://habrahabr.ru/post/303140/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как приблизить удаленную команду

Среда, 08 Июня 2016 г. 13:33 (ссылка)

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



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







1. Нужен полный парк collaboration-инструментов

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



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



Во-вторых, все инструменты нужно по максимуму интегрировать между собой. Стоит обратить внимание на поддержку интеграции с нужными сервисами еще при выборе инструментов.



2. Ответственность важно четко разделить и обозначить

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



Кстати, полезным в удаленных командах может оказаться наставничество — когда кто-то из ветеранов команды отвечает за то, чтобы ввести новичка в курс дел.



3. Формируйте неформальные отношения

С одной стороны, замечательно, когда сотрудники сфокусированы на работе, а не участвуют в конкурсе историй “как я провел выходные” у кулера. С другой — недостаток неформального общения не прибавит им продуктивности и хорошего настроения. Люди не ходят вместе обедать, не играют в настольные игры и не обсуждают новости. Нужно что-то придумать вместо этого, чтобы развивать личных отношений между сотрудниками. Это могут быть отдельные чаты для общения на нерабочие темы или видеоконференции, на которых новые и старые сотрудники могут представиться и рассказать о себе. Другой пример из нашего опыта — для того чтобы объединить нашу команду саппорта, распределенную между тремя городами, мы устраиваем ежегодный слет всей команды в разных уголках мира.



4. Доносите общее видение через регулярные совещания

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



5. Личные качества могут быть важнее опыта

Над шаблонной последней строчкой требований в каждой второй вакансии не шутил только ленивый — все эти “инициативность, организованность, умение общаться”. Их трудно оценить на собеседовании и не особо понятно, насколько критичны для работы. Однако, в случае с удаленной работой эти качества внезапно становятся топовыми требованиями. Иногда они могут оказаться даже важнее профессионального опыта и навыков.



Суть в том, что нельзя отбирать сотрудников в офис и удаленно по одним и тем же критериям. Спрашивайте другие вещи, подготовьте специальные тестовые задания и используйте испытательный срок, чтобы понять, насколько самостоятелен человек и получается ли у него взаимодействовать с коллегами.



Если у вас есть свои советы по организации удаленной команды, набитые шишки и интересная история на эту тему, добро пожаловать в комментарии.

Original source: habrahabr.ru.

https://habrahabr.ru/post/302894/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Фрилансер и предприниматель

Вторник, 07 Июня 2016 г. 21:20 (ссылка)

К какой категории вы себя относите? Вы уверены?



image

Лучший способ измениться в лучшую сторону состоит в том, чтобы определить — кем же вы хотите стать



Фрилансер — это тот, кто получает деньги за свою работу. Оплата его почасовая или, возможно, за проект целиком. Фрилансеры пишут, проектируют, консультируют, советуют, платят налоги и клеят обои. Фриланс — единственный, самый лёгкий путь начать новое дело.



Предприниматели используют деньги (преимущественно не свои деньги), чтобы создать бизнес, крупнее имеющегося. Предприниматели «зарабатывают», даже когда они спят. Предприниматели сосредоточены на росте и соразмерности систем, которые они создают. Чем больше, тем лучше.



Цель фрилансера состоит в том, чтобы иметь постоянную работу без начальника, чтобы работы было много, чтобы спрос постепенно рос и, соответственно, росла почасовая зарплата, как и качество заказов.



Целью предпринимателя является продать созданное за большие деньги или построить «машину по долгосрочному получению прибыли», которая будет устойчивой, стабильной и не очень опасной в эксплуатации. Предприниматель создаёт структуру, которая вносит изменения в окружающую среду.



Заблуждение простое: иногда во фрилансере пробуждается желание заняться предпринимательством и он начинает нанимать других фрилансеров для работы на себя. Это ничего не меняет. Администрирование фрилансеров отличается от прямой фрилансерской деятельности. Администрирование фрилансеров и сохранение самых хороших проектов для себя создаёт проблему для вас. Оплата наличными создаёт проблему для вас. Инвесторы не хотят инвестировать в вас, потому что вы не можете продавать, если вы — фрилансер в своём сердце.



Если вы — предприниматель, то невозможно преуспеть, заполняя какие-то упущения вашим собственным трудом, потому что ваши трудовые возможности ограничены. Вы ничего не сможете изменить один. Если работа такая, что только вы можете её сделать, то вы не создаёте систему — вы просто нанимаете самого себя (и, вероятно, не доплачиваете, так ведь?).



Эта проблема появляется у многих время от времени, и приятно думать, что, приложив больше усилий, мы можем решить её — что мы можем быть сразу в обеих ипостасях. Новые инструменты дают фрилансерам больше средств достижения целей, чем когда-либо прежде, и наша культура продолжает заставлять нас расти прямо сейчас.



Суть в том, что большее усилие не может решить эту дилемму для вас. Рано или поздно станет ясно, что рост усилий ничего не меняет. Трэвис Каланик, основатель сервиса Uber, не ведёт такси, вызванное вами через его систему; Шерил Сандберг, член совета директоров Фейсбука, не занимается написанием программ, а Жаклин Новограц, глава Фонда социального предпринимательства (США), не может заниматься каждой инвестицией каждый день.



Но решение проблемы удивительно простое.



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



Спрос на фрилансеров растёт, они зарабатывают всё больше (и вполне заслуженно). Они развиваются, становясь более коммуникабельными, более способными, более эффективными.



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



Можно изменять направление работы, иметь параллельные проекты, иметь два «дела». Но мы не можем одновременно выполнять обе роли; фриланс — не путь к предпринимательскому успеху.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/302784/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Простой и бесплатный способ осуществлять платежи с Payoneer

Понедельник, 06 Июня 2016 г. 10:28 (ссылка)

image



В предыдущей статье мы подробно разобрали Биллинг-сервис, позволяющий получать платежи напрямую от клиентов со всего мира. Сегодня мы продолжаем тему обзоров новых продуктов и представляем вам услугу Make a Payment («Сделать платеж»).



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



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



Для кого актуален этот сервис



Вы представляете команду, предоставляющую услуги на международном рынке, и вам необходимо разделить гонорар за проект между ее членами? Вы постоянно сотрудничаете с поставщиками и субподрядчиками для работы над проектами? Так или иначе, возможность использовать сеть Payoneer для бесплатных платежей станет для вас простым и выгодным решением.

Очень вероятно, что ваши партнеры уже являются пользователями Payoneer, а если нет – мы предложим им зарегистрировать аккаунт для получения платежа от вас.



Как использовать сервис «Сделать платеж»



image

Пользователи Payoneer могут «Сделать платеж» непосредственно из своего аккаунта, заполнив форму, включающую электронный адрес получателя, сумму и назначение платежа.

Ознакомиться с видео-инструкцией можно на нашем канале YouTube.









Если получатель уже является пользователем Payoneer, средства поступят на его баланс автоматически. В случае, если за указанным имейлом еще не закреплен аккаунт, получатель получит приглашение зарегистрироваться в Payoneer.



Если у вас еще нет аккаунта Payoneer – пройдите регистрацию по этой ссылке.



Преимущества сервиса




  • Это бесплатно. Вы ничего не платите, даже если отправляете международный платеж.

  • Это просто. Вы совершаете оплату прямо из своего аккаунта, просто указав адрес эл. почты получателя, сумму и назначение платежа.

  • Доступно в любое время. После активации сервис доступен 24/7.



Как начать использовать сервис



Сервис «Сделать платеж» доступен для пользователей Payoneer, принимающих платежи от партнеров Payoneer (онлайн-бирж) или с использованием Global Payment Service.

Если данная услуга еще не активирована в вашем аккаунте, обратитесь в Центр поддержки для получения подробной информации.

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



Как всегда, будем рады ответить на ваши вопросы в комментариях к этой статье.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/302612/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<фриланс - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda