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


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

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

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

Почему одни продвигаются (ну а другие нет)

Понедельник, 18 Июля 2016 г. 17:23 (ссылка)

Предлагаю читателям перевод статьи «Why Some People Get Promoted (And Others Don’t)» за авторством Janet Coi.



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



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



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



Делай и рассказывай



Кто сказал, что «хорошими делами не хвастаются»? Кто-то же должен их представлять, и лучше делать это самим. Кратчайшая формула успеха по мнению программиста Carl Lange это «делай и рассказывай». И её второй элемент нами, конечно, часто опускается.



Мы должны продвигать свою работу; как люди от литературы и искусства, например, прибегают к услугам агенств и менеджменту. Видимость, заметность – жизненно необходимы для потока предложений, повышений и перспектив, считает Jeffrey Pfeffer, профессор Standford’s Graduate School of Business.



В его книге «Power: Why Some People Have it and Others Don’t» исследование подтверждает, что нет прямой связи между производительностью и результатом работы. Трудовой стаж на текущем месте, перспективы продвижения и результаты бесчисленных оценок производительности – всё это значит намного меньше, чем мы себе представляем. Несправедливо, и даже раздражает – наш имидж это реалии работы.



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



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



Ещё раз представьте себе: никто реально не знает, над чем вы работаете. Чтобы быть видимыми для «радаров», нужно посылать чёткий сигнал.



Вторая половина дела



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



Tom Sachs, современный художник, знаменитый по части скульптуры, рассказывает про работу своей студии:

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


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



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



Отправьте один простой емейл



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



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



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



Но главный потенциал этой идеи-одного-емейла – превратить отдельные акты самопродвижения (или саморекламы, если хотите) в обычное и привычное информирование, которое постепенно и вас сделает более убедительными. Пока остальные будут из кожи вон лезть именно во время оценок продуктивности (англ. performance review), вы можете уже и без этого оказаться на виду, как бы «первыми, кто приходит на ум».



Не обязательно отправлять такой емейл каждую пятницу (и именно в пятницу). Еженедельно для вас – слишком часто? Делайте это раз в две недели, например. Главное, рассказывайте начальству хоть что-нибудь! На их языке, манере и с любой частотой, подходящей для конкретной ситуации.



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




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



А вот ещё три тактики, позволяющие быть на виду:



1. Не заканчивайте неделю незаметно



Предприниматель Patrick McKenzie советует работать над более «видными» проектами:

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




А если короче: «оптимизируйте влияние и видимость». Природа интеллектуальной деятельности такова, что людям бывает сложно увидеть конкретные её плоды. Спросите себя: могу ли я выбрать более влиятельный проект? могу ли работать над той его частью, которая более остальных соприкасается с живыми людьми? могу ли превратить свои знания по менеджменту, работе с клиент(к)ами или продажам в презентацию или практическое руководство?



2. Просите помощи и отзывов



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



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



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



3. Работайте там, где вас видно



Наработка видимости может потребовать выхода за пределы офиса. Возможно, вы заведёте сторонний проект. А быть может, среда вокруг вас к этому и не располагает.



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

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



Делайте невидимое видимым, обретайте влияние, открывайте новые перспективы.
Original source: habrahabr.ru.

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

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

Homo Multitaskingus: человек многозадачный

Четверг, 14 Июля 2016 г. 08:05 (ссылка)

Люди, одновременно выполняющие несколько дел, кажутся нам просто гуру эффективности. Но иногда бывает как в анекдоте: «Да, я печатаю 300 знаков в минуту. Правда, такая ерунда получается». Вы хотите быть эффективным или слыть им?

"



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



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



Вред многозадачности



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



• Снижается умственный коэффициент. По данным Лондонского университета, в момент многозадачности IQ взрослого мужчины снижается на 15 баллов, что соответствует уровню 8-летнего ребенка. Поэтому, составляя важное письмо клиентам во время семинара или совещания, помните, что качество работы неизменно пострадает.



• Затрудняется возврат к предыдущей деятельности. После проверки электронной почты мозгу нужно более минуты, чтобы вернуться к прошлому занятию. Если в течение часа проверять почту или соцсети 10 раз, то смело вычитайте от рабочего времени десять минут. А Глория Марк, профессор Калифорнийского университета ужесточает рамки. Она говорит, что каждое отвлечение человека от занятия обходится ему в 23 минуты и 15 секунд – именно столько времени требуется головному мозгу, чтобы настроиться на выполнение начатой задачи.



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



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



Игорь Полонский, руководитель и основатель event-агентства «Режиссерская версия», размышляя о работе в режиме многозадачности, говорит: «Если ты строишь систему, в которой за каждую функцию отвечает отдельный человек, многозадачному сотруднику не находится в ней места. Какое-то время он еще может поработать, но в итоге будет проигрывать узкоспециализированным коллегам, которые с каждой отдельной задачей справляются эффективнее и быстрее». Результаты работы агентства подтверждают эти слова: за первый год реализовано около 12 проектов, за второй – более 40 проектов.



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



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



""



Внимание: что это?



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



Свойства внимания



• Переключение. Переключение внимания осознанное и должно быть связано с постановкой новой цели. Хорошая новость – это свойство можно тренировать!



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



• Устойчивость. Это длительность сосредоточенности или концентрации. Это свойство зависит от регулярного появления новых впечатлений. Формируйте интерес к материалу, связывайте суть работы со своими потребностями, создавайте комфортные условия для работы.



• Распределение. Яркий пример – обучение вождению автомобиля. Нужно одновременно выполнять несколько действий: смотреть в зеркала заднего и бокового вида, переключать скорость, да еще и следить за тем, в ту ли сторону едешь. А если в это время звонит телефон и на заднем сиденье истошно вопит ребенок, то распределять внимание очень непросто.



• Объем. Это количество отдельных объектов, которые мы способны воспринимать ясно и четко в одно и то же время. В среднем это 3-5 объектов.



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



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



Что делать?



Секрет мнимой многозадачности в правильном сочетании самих задач. Важное правило – хотя бы одно действие должно осуществляться автоматически. Если вы в совершенстве владеете английским, то ваять письмо на инглише и отвечать на периодические вопросы коллег вам будет не так и трудно. А коллеги будут удивляться: «Как у него получается делать несколько дел одновременно?».



""



Практические советы:



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

2. Расставляйте приоритеты. В помощь вам матрица Эйзенхауэра с ее важными/неважными и срочными/несрочными делами.

3. Компонуйте рабочие блоки исходя из главного правила многозадачности – автоматизма действий. Переключение внимания от неинтересной и менее важной работы к интересной и более значимой происходит легче. Поэтому сначала «ешьте лягушек».

4. Ставьте только одну главную задачу на день. Так вы избежите хаоса и суеты.

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

6. Тренируйте свойства внимания. Находите отличия на картинках, ищите цифры в таблицах на скорость и так далее.

7. Игнорируйте лишнюю информацию, старайтесь оградить себя от нее. Когда я ищу информацию в интернете, всегда велик соблазн зайти на развлекательный портал. Но я держусь))



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

""

Original source: habrahabr.ru.

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

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

Фотографии от Варламова. Честный бизнес, разводка или неверно трактованный закон

Пятница, 08 Июля 2016 г. 21:48 (ссылка)



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



Для погружения в контекст надо посмотреть на две ссылки:



www.business-gazeta.ru/article/315148 — Это, вероятно основной текст, с которого пошла история.

www.facebook.com/groups/pressuha/permalink/1108364145904244 — Обсуждение ситуации в ФБ



Для тех, кому лень ходить по ссылкам, а зря, вкратце суть истории:

Открыть тем, кто не ходил по ссылкам
Речь о том, что Варламов «поставил на конвейер иски к тем изданиям, где находятся его фотографии» (это цитата). По утверждению издания часть фотографий они «нашли в интернете» с уже обрезанными копирайтами и не знали что берут, а часть — использовалась ими не для иллюстрирования, а в как добросовестная цитата, потому как сами материалы был про Варламова. Дальше идет сетование на то, что для некоммерческих проектов Варламов вроде как говорил всегда, что главное не забывать ставить его авторство, и что он не зарабатывает на фото, а теперь задним числом передумал. И вообще там статья про него, то есть авторство указано мегакрупно.



Далее приводятся история, как Варламов же судится с ВГТРК, где уже один раз чуть не проиграл, но нашел способ вернуть дело и его теперь рассматривают повторно.



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





Итак. как же дела с правами.



Начали мы с того, что написали Варламову с запросом разрешения использовать вот то фото, которое вы видите в заголовке. Ответ был получен через 6 часов:



Приветствую!

Просто статья про Илью и других?

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



К





Поскольку статья точно не оскорбительная, то как можно заметить никаких проблем с получением разрешения на публикацию у нас не возникло. Почему это несложное телодвижение не смогла сделать редакция издания, которая, в теории, должна была уже свору собак съесть на использовании чужих материалов — непонятно. История с «мы нашли фото в интернете» по идее подсказывает нам, что кому-то стоило бы подучить матчасть, но разве что косвенно.



Вернемся к сути вопроса.



А можно ли взять просто так фотографию, если она составляет суть новости, и в теории как бы её можно цитировать. Это, кстати, позиция, которую заняло ВГТРК.



Давайте посмотрим на историю с точки зрения авторского права.



Хотя ВГТРК и продавили в первый раз судью, но, как показала практика, вернуть это дело через Суд по интеллектуальным правам не сильно сложно, потому что новость-новостью, но фотография еще и продукт интеллектуального труда, а новостной характер не отменяет его охрану.



Из этой истории можно выжать два момента по существу:



1) оценка уровня творчества

2) тупая формула закона о минимальной компенсации за одно нарушение в 10 тыс.р.



1. Закон защищает только творческие результаты.



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



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



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



И!



Со всем этим можно бы согласиться, если бы не п. №2 — минимальный размер компенсации, который не возможно снизить!



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



Получается, что закон не так плох?



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



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

https://habrahabr.ru/post/305318/

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

Добро пожаловать

Пятница, 08 Июля 2016 г. 10:46 (ссылка)

Мы – молодая команда разработчиков из Санкт-Петербурга (хотя с нами сотрудничают люди из разных городов и даже стран), и мы рады приветствовать вас в своей первой публикации. Мы называемся «ТаймВизор» и продвигаем программное приложение и сервис с таким же названием (англ. TimeVizor).



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



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



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



Какие проблемы мы хотим решить



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



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



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



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



Другая проблема некоторых известных решений – низкая точность замера времени (например по 10 минут) либо стремление округлять время в ту или иную сторону. В этой ситуации компаниям особенно сложно учитывать время работы. ТаймВизор считает время честно и с точностью до минуты.



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



Некоторые функции и особенности ТаймВизора




  • Подсчет отработанного времени с точностью до минуты без округлений.

  • Съемка скриншотов рабочего стола с заданным интервалом (опционально).

  • Съемка фотокадров с веб-камеры с заданным интервалом (опционально).

  • Добавление произвольных отрезков времени вручную.

  • Чрезвычайно низкая нагрузка на ресурсы компьютера.

  • Фоновая работа, не отвлекающая пользователя.

  • Доступ ко всей статистике работы в онлайне через любой браузер (как для фрилансера, так и для заказчика).

  • Отправка еженедельных отчетов о работе на email.

  • Фиксированная оплата без привязки к объему выполненной работы.

  • Качественная техническая поддержка.

  • Бесплатный пробный период в две недели.



И это далеко не все, потому что в наших ближайших планах:




  • Учет времени работы в конкретных приложениях и на конкретных веб-сайтах.

  • Построение сравнительного анализа эффективности работы сотрудников.

  • Обмен мгновенными сообщениями через ТаймВизор между членами группы.

  • Мгновенное оповещение на почту о критичных действиях сотрудников (например вход в социальные сети).

  • Поддержка прокси-серверов, включая NTLM.

  • И др.



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



Мы хотим наполнять этот блог содержательными рассказами об использовании ТаймВизора, о решаемых нами проблемах, а также просто интересными мыслями из области фриланса, тайм-менеджмента и менеджмента в целом. Надеемся, вам с нами будет интересно!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/305270/

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

Фриланс от А до Я - 3. От новичка до специалиста за короткий срок (2016) pdf+mp4 » SoftLabirint.Ru: Скачать бесплатно и без регистрации - Самые Популярные Новости Интернета

Понедельник, 27 Июня 2016 г. 22:30 (ссылка)
softlabirint.ru/video/video...dfmp4.html


Фриланс от А до Я - 3. От новичка до специалиста за короткий срок (2016) pdf+mp4

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



Название: Фриланс от А до Я — 3. От новичка до специалиста за короткий срок

Год издания: 2016

Автор: Стрекоза

Издательство: Интернет-издание

Жанр: Фриланс, заработок

Количество страниц: 294

Формат: PDF+MP4

Язык: Русский

Размер: 261 Mb



Скачать: Фриланс от А до Я - 3. От новичка до специалиста за короткий срок (2016) pdf+mp4



Скачать | Download | TurboBit.net

http://turbobit.net/nowm9fz4fu0x/Frilans_otA_doJa-3.rar.html



Скачать | Download | HitFile.net

http://www.hitfile.net/P2uKzT2/Frilans_otA_doJa-3.rar.html



Скачать | Download | Файлообменник.рф

http://файлообменник.рф/y908dvjsrb4k/Frilans_otA_doJa-3.rar.html



Скачать | Download | DepFile.com

http://kyc.pm/ivdjCFNLl/Frilans_otA_doJa-3.rar



Скачать | Download | DataFile.com

http://www.datafile.com/d/TVRrMU1USTBPREUF9/Frilans_otA_doJa-3.rar

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
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)КомментироватьВ цитатник или сообщество

Следующие 30  »

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

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

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