Комментарии 189
Рискну предположить, что только что состоявшееся привлечение компанией Slack $120 млн. — также косвенное подтверждение того, что доля удаленной работы будет и дальше расти. Ибо с подобными инструментами это становится делать все проще.
> С точки зрения эффективности (КПД) общения, отсутствие прямого контакта не накладывает почти никаких ограничений при современном уровне развития сетевых технологий.
Как бывший фрилансер с шестилетним стажем скажу, что отсутствие прямого контакта с коллегами крайне негативно сказывается и на качестве работы, и на профессиональном росте. Человеку жизненно необходимо напрямую контачить с себе подобными, вариться в коллективе, обсуждать на коленке проблемы. Это такой опыт, который невозможно получить по каналам связи. Обязательно нужно невербальное общение, а его каналы связи предоставляют в обрезанном и сильно искаженном виде.
Получается, что ты все время общаешься с человеком через сильно шумящий фильтр, который искажает и обрезает визуальный и звуковой тракт восприятия, вносит задержку в реакцию, а тактильный тракт отсутствует напрочь — ты не можешь погрузиться в ту же среду, где находится собеседник, и вас это разделяет. Множество таких моментов приводит к тому, что невозможно полноценно общаться. А значит невозможно полноценно делиться опытом. А значить падает эффективность. И это реально.
> Более того, в ВУЗах прямо сейчас учится поколение людей, для которых общение в социальных сетях, онлайн-играх и VoIP-мессенджерах так же (а для кого-то более) привычно, как и общение оффлайновое.
Это бедные люди, которые не понимают прелестей личного общения, и поют дифирамбы суррогату.
Читайте классиков. Они про все эти вещи размышляли когда еще и техногий толком не было. «Все на свете вздор, есть только одна роскошь — роскошь человеческого общения».
Как бывший фрилансер с шестилетним стажем скажу, что отсутствие прямого контакта с коллегами крайне негативно сказывается и на качестве работы, и на профессиональном росте. Человеку жизненно необходимо напрямую контачить с себе подобными, вариться в коллективе, обсуждать на коленке проблемы. Это такой опыт, который невозможно получить по каналам связи. Обязательно нужно невербальное общение, а его каналы связи предоставляют в обрезанном и сильно искаженном виде.
Получается, что ты все время общаешься с человеком через сильно шумящий фильтр, который искажает и обрезает визуальный и звуковой тракт восприятия, вносит задержку в реакцию, а тактильный тракт отсутствует напрочь — ты не можешь погрузиться в ту же среду, где находится собеседник, и вас это разделяет. Множество таких моментов приводит к тому, что невозможно полноценно общаться. А значит невозможно полноценно делиться опытом. А значить падает эффективность. И это реально.
> Более того, в ВУЗах прямо сейчас учится поколение людей, для которых общение в социальных сетях, онлайн-играх и VoIP-мессенджерах так же (а для кого-то более) привычно, как и общение оффлайновое.
Это бедные люди, которые не понимают прелестей личного общения, и поют дифирамбы суррогату.
Читайте классиков. Они про все эти вещи размышляли когда еще и техногий толком не было. «Все на свете вздор, есть только одна роскошь — роскошь человеческого общения».
Это видимо индивидуально. Я за ~4 года работы из дома вырос профессионально намного больше, чем за примерно тот же срок работы в офисе до этого.
В любом случае, это скорее к пункту №2, там же и ответ: удалённая работа не значит обязательно работу из дома. Коворкинг набирает обороты.
В любом случае, это скорее к пункту №2, там же и ответ: удалённая работа не значит обязательно работу из дома. Коворкинг набирает обороты.
Вставлю свои копейки про индивидуальность. Да, это индивидуально ровно настолько, насколько профессионален коллектив в который вы вливаетесь, каждый его сотрудник. Работая в больших компаниях это особенно заметно: слабенький новичок невольно подтягивается под общий уровень (если он хочет этого, конечно), а спец гораздо высшей профессиональной квалификации невольно обленивается под «среднюю температуру по больнице».
Поэтому вопрос проф.роста здесь да, индивидуален. Кто чего хочет, короче.
Поэтому вопрос проф.роста здесь да, индивидуален. Кто чего хочет, короче.
Вопрос в чём: на дому занимался ТЕМ-ЖЕ, что и в офисе, или нет?
Ну и это всё сильно зависит от коллектива, от направления деятельности, от человека и т.д.
Ну и это всё сильно зависит от коллектива, от направления деятельности, от человека и т.д.
Отчасти согласен, но если есть желание и время, то курсы Coursera и участие в конференциях, хакатонах и всяких user group, должны хотя бы отчасти решить эту проблему.
Тоже длительное время работал удаленно и спустя какое-то время начал понимать что у меня профессиональная стагнация. Согласен с комментарием выше — нам нужно свое окружение которое будет помогать росту, но жаль я не понял раньше что это не обязательно офис, а как вы и сказали какие-то конференции, юзер группы и тд и тп.
По своему опыту скажу что действительно помогает, главное хотеть и искать что может помочь в росте, а когда не хочется особо то и офис и коллеги, какие они умные не были бы, не помогут.
Сейчас работаю удаленно с периодическими выездами в офис для коллективного обсуждения прошлого, будущего и настоящего. Пока что, а это спустя пару лет, считаю самым удачным вариантом удаленной работы.
По своему опыту скажу что действительно помогает, главное хотеть и искать что может помочь в росте, а когда не хочется особо то и офис и коллеги, какие они умные не были бы, не помогут.
Сейчас работаю удаленно с периодическими выездами в офис для коллективного обсуждения прошлого, будущего и настоящего. Пока что, а это спустя пару лет, считаю самым удачным вариантом удаленной работы.
НЛО прилетело и опубликовало эту надпись здесь
Простите, что начинаю холивар, но я бы не относил написание тестов к «новомодным вещам».
А это зависит от вашего стажа. И с тестами, на самом деле, всё очень и очень непросто. Понятно что какие-то тесты писались всегда. И будут писаться всегода. Просто невозможно написать программу, скажем, в миллион строк не написав ни одного теста.
Но в последние лет примерно так 10-15 тесты превратились в религию. Особенно среди Java и C# разработчиков. Вместо того, чтобы писать тесты, которые проверяют нетривиальные участки кода разработчики молятся на покрытие и, зачастую, даже не задумываются о том, что тесты — всего лишь инструмент, а никак не цель.
В одном из проектов меня заставили перед сдачей написать тесты к одному компоненту строящему конечный автомат. К которому у меня тестов никогда не было и которые я не планировал писать в принципе ибо у меня были тесты на сам конечный автомат порождаемый оным генератором. Это потребовало фактически переписать генератор с нуля, добавить к тем полутора тысячам строк, которые в этом компоненте уже были ещё почти столько же и, в конечном итоге, позволило найти пару ошибок в генераторе, которые на реальных данных не проявлялись (иначе бы их заметили тесты на автомат).
Ну и? Что получил заказчик за потраченные, причём весьма немалые, деньги? Возможность гордо заявить что у нас теперь в проекте покрытие тестами достигло XX%. Но кому от этого стало лучше?
Но в последние лет примерно так 10-15 тесты превратились в религию. Особенно среди Java и C# разработчиков. Вместо того, чтобы писать тесты, которые проверяют нетривиальные участки кода разработчики молятся на покрытие и, зачастую, даже не задумываются о том, что тесты — всего лишь инструмент, а никак не цель.
В одном из проектов меня заставили перед сдачей написать тесты к одному компоненту строящему конечный автомат. К которому у меня тестов никогда не было и которые я не планировал писать в принципе ибо у меня были тесты на сам конечный автомат порождаемый оным генератором. Это потребовало фактически переписать генератор с нуля, добавить к тем полутора тысячам строк, которые в этом компоненте уже были ещё почти столько же и, в конечном итоге, позволило найти пару ошибок в генераторе, которые на реальных данных не проявлялись (иначе бы их заметили тесты на автомат).
Ну и? Что получил заказчик за потраченные, причём весьма немалые, деньги? Возможность гордо заявить что у нас теперь в проекте покрытие тестами достигло XX%. Но кому от этого стало лучше?
Как минимум стало лучше программисту, который будет рефакторить код генератора, если, например, потребуется перенести его в другой конечный автомат.
Изначально вы написали интеграционные (или функциональные) тесты на конечный продукт, желание заказчика иметь покрытие различных модулей юнит-тестами (они же «модульные тесты») вполне обоснованно. Особенно если планируется передать разработку другим командам или использовать уже написанные модули в других продуктах.
Так же не совсем понимаю, как написание модульных тестов привело к «полному переписыванию генератора» – там что-то страшное было?
Изначально вы написали интеграционные (или функциональные) тесты на конечный продукт, желание заказчика иметь покрытие различных модулей юнит-тестами (они же «модульные тесты») вполне обоснованно. Особенно если планируется передать разработку другим командам или использовать уже написанные модули в других продуктах.
Так же не совсем понимаю, как написание модульных тестов привело к «полному переписыванию генератора» – там что-то страшное было?
Как минимум стало лучше программисту, который будет рефакторить код генератора, если, например, потребуется перенести его в другой конечный автомат.То есть мы, условно говоря, потратили 100 рублей сейчас, чтобы возможно (не гарантированно, но возможно) не тратить те же 100 рублей в будущем? Смысл где? За те же 100 рублей можно породить ещё один автомат с нуля, так что нужно говорить уже не о следующем программисте, а о том, который будет этот автомат встраивать ещё куда-то второй раз. Это ж как нужно поклоняться повторному использованию кода, чтобы планировать куда-то там встраивать трижды программу, для которой пока и второго-то применения нету!
Так же не совсем понимаю, как написание модульных тестов привело к «полному переписыванию генератора» – там что-то страшное было?Там был самый обычный код. Была процедура: «прочитать конфигурацию, создать автомат», она вызывала другие процедуры («создать подавтомат для префикса», «создать подавтомат для суффикса») и т.д. Без всяких инверсий управления и прочей всякой мути. Разумеется протестировать что-либо отдельно было нельзя — да и не планировалось. В конце автомат превращался в C модуль путём запуска ragelя.
Изначально вы написали интеграционные (или функциональные) тесты на конечный продукт, желание заказчика иметь покрытие различных модулей юнит-тестами (они же «модульные тесты») вполне обоснованно.Чем обосновано? Кому обосновано? Мне никто никаких обоснований привести не смог. Ну то есть разумных обоснований.
Под разумными обоснованиями я понимаю обоснования, начинающиеся со слов «для того, чтобы конечный пользователь получил A, нужно сделать B, а это, в свою очередь требует C...» и дальше следует цепочка рассуждений, которая кончается словами «и вот тут вложенные нами X часов приведут к выигрышу в Y часов». Дальше мы смотрим на вероятность вещей, куда относится A (не только та вещь, которая обсуждается в примере, а весь класс действий, которые могут с разумной вероятностью облегчиться нашими действиями) и сравниваем X и Y. В идеале A должно быть у нас в планах ибо только тогда ему можно приписывать какую-то вероятность, отличную от нуля (если уже известно кто его будет делать и когда — тогда совсем хорошо, но хотя бы в каких-нибудь планах с Milestorne-X его бы нужно иметь, чтобы было о чём предметно говорить).
Все «обоснования», которые я слышал ссылались на разнообразную «богословную литературу» в которой обсасывались разные теоретические построения. Без всяких чисел и рассмотрения конкретных случаев. Извините, но я подобных доводов не признаю. Вся наша (ITшная) деятельность — она вспомогательная, в ней в самой по себе нет никакого смысла. Если она не помогает никому добиться ничего полезного вне IT, то зачем это всё?
То есть мы, условно говоря, потратили 100 рублей сейчас, чтобы возможно (не гарантированно, но возможно) не тратить те же 100 рублей в будущем? Смысл где?
Объясню: программист с высокой культурой разработки делает достаточно много долгосрочных инвестиций в свой код. Он старается продумывать архитектуру, придерживаться принятого стиля кода, думает о лаконичности и поддерживаемости, пишет тесты. Программист пишет код не для пользователя «А», он пишет код для другого программиста (и автоматически для себя). Если он будет каждый раз задавать вопросы вроде «А в чем смысл архитектуру продумывать? Набросаю что-нибудь рабочее побыстрому. Зачем код-стайл соблюдать? Все равно этот код никто читать не будет...», то сразу после релиза его код можно просто выбросить. Поддерживать и добавлять в него новую функциональность будет очень дорого. Дешевле за 100 рублей заново написать.
Листер\Де Марко\МакКоннел уже давно изложили все необходимые обоснования в своих книгах, причем с числами из различных исследований крупный компаний (BellLabs, Microsoft и т.д.). Интересно куда ссылались данные вам «обоснования». Мне кажется что жизнь любого программиста делится на «до» и «после» этих книг, до их прочтения ты просто пишешь код, после – начинаешь всеми средствами повышать культуру написания кода.
Разумеется протестировать что-либо отдельно было нельзя
Я не совсем понял такой резкий переход к «разумеется», но если протестировать было нельзя, значит архитектура системы была неудачной — логика была недостаточно гранулирована в процедуры, скорее всего были процедуры с огромным количеством кода (возможно заказчик увидел это?). В результате написания тестов вы:
- улучшили архитектуру системы
- нашли несколько ошибок
- написали тесты, которые очень сильно сэкономят время программистам, которые будут поддерживать и развивать код
Таким образом ваш заказчик сделал хорошую инвестицию в долгосрочное использование вашего кода, и это достаточно продуманный и мудрый шаг.
Объясню: программист с высокой культурой разработки делает достаточно много долгосрочных инвестиций в свой код. Он старается продумывать архитектуру, придерживаться принятого стиля кода, думает о лаконичности и поддерживаемости, пишет тесты.Это напоминает какую-то религию, чесслово. Ну или моральный кодекс строителя коммунизма. Спасибо, я уже этого наслушался.
Если он будет каждый раз задавать вопросы вроде «А в чем смысл архитектуру продумывать? Набросаю что-нибудь рабочее побыстрому. Зачем код-стайл соблюдать? Все равно этот код никто читать не будет...», то сразу после релиза его код можно просто выбросить.Это почему ещё? Всё зависит, в общем-то, от ответов на эти вопросы. Архитектуру нужно соблюдать, чтобы можно было внести определённые изменения. И, разумеется, от того — какие запланированы изменения и зависит наша архитектура. Если код таки никто читать не будет — то да, код-стайл соблюдать не нужно, но если его кто-то будет читать, то нужно смотреть — кто это будет и насколько для него важно соблюдение код-стайла. И так далее.
Поддерживать и добавлять в него новую функциональность будет очень дорого. Дешевле за 100 рублей заново написать.Возможно. Но если это действительно следует из ответов на соответствующие вопросы — то это и будет самым дешёвым вариантом в долгосрочной перспективе!
Конечно можно считерить и в ответе на вопрос «кто будет этот код читать?» сказать «никто» имея в виду «кто угодно, только не я», но это другая история. Среди «свидетелей культуры написания кода» я скорее наблюдаю людей, которые склонны отвечать на этот вопрос как «много, очень много, возможно миллионы» в случае, когда код, дай бог, прочитают пару его коллег до того, как код будет выкинут.
Листер\Де Марко\МакКоннел уже давно изложили все необходимые обоснования в своих книгах, причем с числами из различных исследований крупный компаний (BellLabs, Microsoft и т.д.). Интересно куда ссылались данные вам «обоснования».Примерно туда. Но когда я просил конкретных выкладок (вот у нас есть конкретный код, мы хотим в него внести вполне конкретные изменения, кто и когда выиграет от этих изменений) мне вместо этого в очередной раз зачитывали байки. IMNSHO это значит, что люди ничего не поняли в этих книгах — они в них поверили, что совершенно не одно и то же.
В данном, конкретном, случае, кроме абстрактных «преимуществ» от переработки кода был ещё один, четвёртый, результат: вся эта бурная деятельность вокруг «культуры кода и его тестирования» (переписывание генератора было лишь малой частью — там было много всего, люди, похоже, уверовали в Листер\Де Марко\МакКоннела серьёзно) привела к тому, что продукт вышел на рынок не в Xм году (когда была куча людей, которые его хотели и были готовы мириться с его недостатками), а в (X+3)м (когда он, по большому счёту, уже нафиг никому не был нужен). Может быть когда-нибудь я опишу всю историю более подробно (сейчас я бы не хотел этого делать, так как заказчик, выкинувший, как мне кажется, деньги на ветер всё ещё пытается что-то сделать с никому уже не нужным продуктом; подожду пока всё окончательно накроется медным тазом).
Это был не первый такой случай в моей практике, так что, извините, но в эту религию я больше не верю.
Это напоминает какую-то религию, чесслово. Ну или моральный кодекс строителя коммунизма. Спасибо, я уже этого наслушался.
Я бы назвал это тем, что отличает профессионального программиста от обычного и большинство крупных IT-компаний со мной согласны.
Это почему ещё? Всё зависит, в общем-то, от ответов на эти вопросы.
Это же риторические вопросы. Соблюдение стиля кода вообще не требует усилий — есть автоматическое форматирование. Все перечисленные мной best practices обязательны по-умолчанию, конечно в реальности на все это чаще всего не хватает времени и программист отказывается от чего-то менее критичного.
И все-таки хочется увидеть примеры, как отказ от зарекомендовавших себя практик привел к выпуску успешного продукта на N лет раньше своих конкурентов. Вы уже приводили в пример сравнение андроида и windows phone — так стало известно, что программисты во время разработки андроида не писали тесты? не проводили код-ревью? не продумывали архитектуру?
Вы ведь просите конкретных выкладок, возможно у вас есть контр-выкладки, которые заткнут за пояс МакКонелла и перевернут культуру разработки?
Соблюдение стиля кода вообще не требует усилий — есть автоматическое форматирование.
Резануло глаз.
Из серии «Грамотность вообще человеку не нужна — есть же проверка орфографии в Word». Мне всегда казалось, что, по крайней менее, про грамотность так пишут те, у кого с этой грамотностью большие проблемы, и они даже не осознают, насколько велики у них эти проблемы. Они еще обычно, увидев текст после автокоррекции Word, искренне полагают, что в нем все гладко и нет ошибок.
Аналогия с программированием IMHO прослеживается четко. Для меня очень плохой знак, если человек использует автоформатирование и остается доволен результатом.
Мне кажется вы сравниваете теплое с мягким: форматирование не связано с логикой работы кода — у вас может быть напиша каша из кода и при этом программа будет отлично работать без ошибок. Поэтому проверка орфографии не является в данном случае прямой аналогией.
Вот например выравнивание параграфов и юстификация текста — это и есть аналог для код-стайла (пробелы в нужном месте, перенос строк и скобок и т.д.). Ведь если бы в ворде не было юстификации пришлось бы в ручную количество пробелом между словами выставлять — так же как и в коде отступы, но сейчас всем этим занимается IDE.
Вот например выравнивание параграфов и юстификация текста — это и есть аналог для код-стайла (пробелы в нужном месте, перенос строк и скобок и т.д.). Ведь если бы в ворде не было юстификации пришлось бы в ручную количество пробелом между словами выставлять — так же как и в коде отступы, но сейчас всем этим занимается IDE.
форматирование не связано с логикой работы кода
Форматирование — это самый быстрый и доступный способ продемонстрировать человеку логику работы кода.
Неграмотная речь без пунктуации выглядит как поток сознания (коим и является). Аналогично и с неформатированным кодом.
Ручное переформатирование кода требует его осознания, когда автор пишет код, форматируя его в ходе написания, он лучше осознает его структуру, может выявить общие моменты и опечатки.
Есть два близких но разных спора:
- Нужно ли форматирование кода вообще, или автоформат исправит код любой горбатости?
- Какое нужно форматирование: Египетские скобки или одна-под-другой? А сколько ставить пробелов? Может, лучше табуляция?
В первом споре, подход под названием «не приходя в сознание приступил к кодингу....» («Я тут три примера эта… на стековерфлоу скопипастил, переменные автозаменой сопоставил, вроде компилируется XDD») борется со здравым смыслом.
Во втором споре мы имеем банальный конфликт вкусов, сформированных в процессе реализации синдрома утенка — кто-то любит скобки по-египетски, кто-то о них спотыкается, а третьим и вовсе подавай отступ в четыре пробела.
Вот сюда-то и подходит ответ: «Настрой автоформат и преобразуй в то, что тебе нужно, если тебя бесят мои раскиданные всюду скобки». А когда будешь отдавать код назад, преобразуй все обратно. В этом случае оба автора увидят свой любимый стиль и сразу почувствуют себя комфортно*.
_________________________
*Однако, если авторы при обмене кодом вручную его переформатируют в свой любимый стиль, возможно, они быстрее и лучше осознают его.
Все перечисленные мной best practices обязательны по-умолчанию, конечно в реальности на все это чаще всего не хватает времени и программист отказывается от чего-то менее критичного.Вы тут сами себе противоречите. Либо ваши best practices — есть какая-то ценность сами по себе (тогда мы имеем дело с религией и отступление от неё карается всякими карами), либо они — всего лишь инструмент и нужно оценивать целесообразность применения их каждый раз, когда оказывается, что следование им требуют нетривиального времени и сил.
Вы уже приводили в пример сравнение андроида и windows phone — так стало известно, что программисты во время разработки андроида не писали тесты?Писали, но гораздо меньше, чем, скажем, разработчики Chrome (которые в большинстве своём работают в той же компании).
не проводили код-ревью?Проводили, но, опять-таки, далеко не с такой тщательностью.
не продумывали архитектуру?Конечно продумывали! Там где это имело смысл и где было понятно, что архитектуру будет тяжело изменить в дальнейшем.
Вы ведь просите конкретных выкладок, возможно у вас есть контр-выкладки, которые заткнут за пояс МакКонелла и перевернут культуру разработки?Что за детский сад? Это как раз выигрыш от применения best practices сложно посчитать, а выигрыш от их неприменения самоочевиден. Контр-выкладки совершенно элементарны: смотрим сколько времени уйдёт на то или иное действие (рефакторинг, написание тестов, etc), умножаем на почасовую ставку программиста, добавляем потери от сорванного контракта (или примерно оцениваем «упущенную прибыль», если работа делается не на заказ), получаем некоторую сумму. Которую желательно бы сравнить с другой суммой — потенциального выигрыша от проведения всей этой деятельности. Причём при подсчёте этой суммы неплохо бы учесть, что «завтрашние» деньги всегда куда дешевле сегодняшних — особенно на быстрорастущих рынках.
Собственно в эту проблему все эти best practices и упираются почти всегда: когда вы работаете на более-менее стационарном рынке, то они действительно себя окупают (иначе бы вокруг не было столько разговоров). А вот если мы говорим о новом, растущем, рынке… тут ситуация совсем-совсем иная. И не учитывать этого просто нельзя. Хотя часто и очень хочется. Но это — прямой путь в никуда.
Работаю на удаленке около восьми лет, одним из топовых разработчиков. Из них года 3 фрилансил, потом работал в трех разных коллективах, разного объема и качества. Никогда не было проблем с общением. Да, конечно прикольно пожать коллеге руку и похлопать по плечу, а для всего остального есть скайп и свобода.
Поддерживаю ораторов выше, все это очень очень индивидуально. Но как проблему я бы это не рискнул выставлять.
Поддерживаю ораторов выше, все это очень очень индивидуально. Но как проблему я бы это не рискнул выставлять.
-3 сейчас потому, что я промахнулся, хотел нажать +. webhamster держите витруальный плюс. Люди, что с вами? Мнение человека минусуется, потому что оно не совпадает с большинством?
Сейчас там 7 плюсов, 9 минусов. Что не так?
Я, например, поставил минус не за мнение, за догматичный ответ на последнюю цитату:
Это же не карма, влияющая на возможность постить и прочее.
Я, например, поставил минус не за мнение, за догматичный ответ на последнюю цитату:
Это бедные люди, которые не понимают прелестей личного общения, и поют дифирамбы суррогату.
Читайте классиков. Они про все эти вещи размышляли когда еще и техногий толком не было. «Все на свете вздор, есть только одна роскошь — роскошь человеческого общения».
Это же не карма, влияющая на возможность постить и прочее.
В чем-то с вами можно согласиться, но далеко не во всем. Смотрите, вы сами говорите о поколении, которому комфортнее общаться в онлайне. Так почему таким людям не работать таким же образом? Зачем издеваться над собой, пытаясь работать в офисе, рядом с людьми, которые, как минимум, не очень нравятся? И почему бы не вспомнить такое высказывание «Так как это было никому не нужно, то все только об этом и говорили» (Михаил Мамчич). Зачастую в офисном формате именно так и происходит… А что касается проф.роста — так было бы желание, найдется 1000 возможностей
Очень странно, что в тексте нет самого частого(во всяком случае в моей практике) довода из-за которого пза которого работодатели предпочитают работать в офисах.
«Надежность удаленщиков в среднем ниже».
На самом деле надежность удаленщиков такая же как и у офисных сотрудников. Вот только контролировать офисных сотрудников гораздо проще. А понять, что удаленщик вместо работы ездит по ушам — получается далеко не сразу.
При этом ужесточать контроль через просмотр компа удаленщика, жесткий контроль времени присутствия онлайн и т.п. — тоже не вариант, потому что большая часть удаленщиков на такие условия не согласится.
Так что вот он — основной довод.
А то что вы перечислили — дело десятое.
«Надежность удаленщиков в среднем ниже».
На самом деле надежность удаленщиков такая же как и у офисных сотрудников. Вот только контролировать офисных сотрудников гораздо проще. А понять, что удаленщик вместо работы ездит по ушам — получается далеко не сразу.
При этом ужесточать контроль через просмотр компа удаленщика, жесткий контроль времени присутствия онлайн и т.п. — тоже не вариант, потому что большая часть удаленщиков на такие условия не согласится.
Так что вот он — основной довод.
А то что вы перечислили — дело десятое.
А зачем их вообще контролировать? Есть задачи, которые работники должны решать. Задачи решены — хорошо, не решены — плохо. Контролировать надо процесс выполнения задач, а не действия сотрудников.
Как «время присутствия онлайн» связано с эффективностью сотрудника?
Собственно, одна их самых частых причин того, что на удаленную работу смотрят криво — это страх менеджера перед вопросом «а где все?» от вышестоящего менеджера, случайно заглянувшего в офис. А если все на местах — то есть, хотя бы, видимость занятости.
Как «время присутствия онлайн» связано с эффективностью сотрудника?
Собственно, одна их самых частых причин того, что на удаленную работу смотрят криво — это страх менеджера перед вопросом «а где все?» от вышестоящего менеджера, случайно заглянувшего в офис. А если все на местах — то есть, хотя бы, видимость занятости.
Именно. Проблема контроля удаленных сотрудников скрывается как раз в навыках менеджера. И зачастую им страшно, что они не смогут отконтролить людей, не видя их время работы, хотя это никак не связано с реальной производительностью.
Задача — эстимейт — результат. Только это есть реальный контроль любого сотрудника, а не как часто он опазывает в офис (ну пробки же) или тратит времени на обед (ну час же).
Задача — эстимейт — результат. Только это есть реальный контроль любого сотрудника, а не как часто он опазывает в офис (ну пробки же) или тратит времени на обед (ну час же).
Понимаете, какая штука… Нет такого дискретного разделения — «задача решена/не решена» (если только компания не делает одноиазовые сайты-визитки). Разработка — очень многогранное занятие, есть такие понятия, например, как «технический долг», «удачный выбор архитектуры», «общее улучшение и упрощение системы в процессе решения задачи» и т.д. Не говоря уж о том, что одну и ту же задачу один человек может решить за X часов, а другой — за X*10 часов. Или хуже: задачу можно решить за Y часов тяп-ляп или за Y*2 часов с общем улучшением системы.
Я не говорю, что удаленные работники хуже офисных (всегда можно найти пример компании, в которой удаленный уделывает остальных офисных, вместе взятых). Я просто даю комментарий к расхожему штампу «задача решена/не решена». Но сдается мне, что среди офисных работников все же больше шанс, что задача будет не просто «решена», а решена так, чтобы минимизировать технический долг и параллельно улучшить архитектуру системы, чем среди удаленных (в среднем, естественно).
Я не говорю, что удаленные работники хуже офисных (всегда можно найти пример компании, в которой удаленный уделывает остальных офисных, вместе взятых). Я просто даю комментарий к расхожему штампу «задача решена/не решена». Но сдается мне, что среди офисных работников все же больше шанс, что задача будет не просто «решена», а решена так, чтобы минимизировать технический долг и параллельно улучшить архитектуру системы, чем среди удаленных (в среднем, естественно).
НЛО прилетело и опубликовало эту надпись здесь
Влезу с контрвопросом. Удаленщик — вовсе не обязательно фрилансер. Он может быть на трудовом договоре или контракте. Насколько просто его уволить?
Мне кажется, так же, как и офисного, без действительно весомой причины по трудовому кодексу — разве что, попросить «по собственному».
Мне кажется, так же, как и офисного, без действительно весомой причины по трудовому кодексу — разве что, попросить «по собственному».
Он будет работать ответственнее, ежеминутно испытывая стресс и трясясь, а вдруг работодателю не понравится его продуктивность или ещё что-то.
Работник, который сидит в офисе, более уверен в своём месте.С чего вдруг? Одной из «плюшек» для работника в предыдущей статье преподносилась возможность выбирать из гораздо более широкого круга работодателей.
А фрилансера заменить гораздо проще, поэтому он будет работать ответственнее,Опять-таки: зачем? Фрилансеру не имеет особого смысла заморачиваться с архитекторой и прочими мелочами: он всегда может «ускакать» и оставить расхлёбывать результат кому-то другому. Потому инициатива проста: породить как можно больше вещей, которые можно выставить своими «достижениями» и свалить.
А человеку, работающий в офисе волей-неволей придётся в будущем расхлёбывать свои косяки. Именно потому что его не уволят, а если уволят, то вариантов трудоустройства у него будет куда меньше.
Тут критерий «решена» должен быть более полным — требования выполнены, следовательно, задача решена. Если явно не поставлено требование «снизить технический долг», «выбрать хорошую архитектуру», решающий в это лезть не обязан (это аналитик ушами прохлопал, а PM пропустил). Разраб может выступить с предложением, но тогда надо и задачу перезапускать. Когда разраб сам начинает менять архитектуру (потому что я — могу!!1), есть риск наступления разрухи.
Если бить по рукам за любой внеплановый рефакторинг, то работники, имеющие энтузиазм, сначала будут выносить все улучшения в таски а затем, увидев, что их таски менеджер ни во грош не ставит, предпочитая наращивать функции и фиксить баги, задумаются о другом месте работы. Останутся лишь пофигисты, которым лишь бы таск закрыть, чтобы все тесты прошли, а какие возникли проблемы, не пойманные в приёмочном тесте, их не волнует — надо было лучше продумывать тест.
Если в конторе рефакторинг и техническая стройность держатся на энтузиазме, то:
- Они готовы за такое барахло платить, потому как:
- Это барахло приносит денежки.
- Самовольный рефакторинг дополнительно оплачен не будет, все вознаграждение — моральное удовлетворение, причем даже менеджер его скорее всего с разрабами не разделит («А если бы сроки сорвали?! Меня премии лишат! Выдумали какой-то рефакторинг еще, нам проще другой тариф в облаке подкупить!»).
- Когда этот костыльный домик рухнет, можно будет показать задачи в системе и сказать «ну мы же предупреждали».
Попробую по-другому. У разработчика может быть разное отношение к коду.
Либо ощущать полный контроль, и тогда он имеет право его колбасить как нравится, но так и получаются чистые и эффективные системы.
Либо быть гостем и делать ровно то, что скажет хозяин. «Вот здесь подпилить?», «Да, сэр».
По моим личным ощущениям, потребность что-то капитально изменить может возникнуть спонтанно, и пока она «тащит», легко заниматься изменениями хоть 6 часов без перерыва. Позже, мотивация перегорает и уже кажется: «да ну его нафиг, и так работает». Отрефакторить-то можно по плану, только это займёт в 3-5 раз больше времени. Поэтому лучше не гасить энтузиазм.
Либо ощущать полный контроль, и тогда он имеет право его колбасить как нравится, но так и получаются чистые и эффективные системы.
Либо быть гостем и делать ровно то, что скажет хозяин. «Вот здесь подпилить?», «Да, сэр».
По моим личным ощущениям, потребность что-то капитально изменить может возникнуть спонтанно, и пока она «тащит», легко заниматься изменениями хоть 6 часов без перерыва. Позже, мотивация перегорает и уже кажется: «да ну его нафиг, и так работает». Отрефакторить-то можно по плану, только это займёт в 3-5 раз больше времени. Поэтому лучше не гасить энтузиазм.
С первой частью согласен, именно о ней я и говорил.
А вот по поводу «офисный решит лучше» — вся моя натура удаленщика протестует. :)))
А вот по поводу «офисный решит лучше» — вся моя натура удаленщика протестует. :)))
НЛО прилетело и опубликовало эту надпись здесь
А если код проходит ревью, то не все ли равно откуда приходит коммит?Нет, не всё равно. Для того, чтобы «удалёнщик» мог породить что-то хотя бы отдалённо напоминающее архитектуру, которую остальные хотят увидеть, в своём коммите — он должен как-то о ней узнать. То есть она должна быть где-то обговорена, записана, etc. А если она обсуждается, грубо говоря, во время обеда, то как он о ней узнает?
Удалёнка предполагает куда более формализованные процессы, что хорошо заметно, когда над одной задачей работает несколько офисов: на «стыках» зон ответственности людей, работающих в разных офисах, проблемы возникают куда чаще. А вы хотите эти проблемы устроить между всеми участниками процесса.
НЛО прилетело и опубликовало эту надпись здесь
Самый толковый комментарий к этой статье! Анархии быть не должно, сам не раз видел этих ваших обиженных гениев с нереализованными амбициями :) Архитектуру пусть тимлиды строят, а у тебя своя зона ответственности.
Ну как вас сказать, чтобы не обидеть. Архитектуру пусть тимлиды строят, а у тебя своя зона ответственности — это Windows Phone. А люди, которым некомфортно заниматься разработкой строго по бумажке — сделали Android и iOS. Причём до недавнего времени и в Apple и в Google соответствующие команды сидели не просто в одном кампусе, а буквально всех свозили в одно здание, чтобы можно было теснее общаться.
Результаты вы знаете: если бы в своё время кто-то не подсыпал белены акционерам лидера рынка смарфонов, то о Windows Phone сейчас бы уже все окончательно забыли, но даже и применение этого традиционного для Microsoft «финта ушами», похоже, Windows Phone не спасёт.
Всему своё время: если вы хотите сделать что-то новое, передовое, что-то, чего до вас никто не делал — то люди, которым «некомфортно «обсуждать» архитектуру в команде» и, тем более, удалёнщики — не для вас. Если ваша задача — клепать очередной 100500й сайт (CRM-систему, программу автоматизации деятельности банки и т.д.), то да — удалёнщики вам уже вполне годятся, а на аутсорсинге можно и экономию получить. Опять-таки в последнем случае особо и спорить об архитектуре незачем: она уже вылизана на 100499 предыдущих проектах.
Результаты вы знаете: если бы в своё время кто-то не подсыпал белены акционерам лидера рынка смарфонов, то о Windows Phone сейчас бы уже все окончательно забыли, но даже и применение этого традиционного для Microsoft «финта ушами», похоже, Windows Phone не спасёт.
Всему своё время: если вы хотите сделать что-то новое, передовое, что-то, чего до вас никто не делал — то люди, которым «некомфортно «обсуждать» архитектуру в команде» и, тем более, удалёнщики — не для вас. Если ваша задача — клепать очередной 100500й сайт (CRM-систему, программу автоматизации деятельности банки и т.д.), то да — удалёнщики вам уже вполне годятся, а на аутсорсинге можно и экономию получить. Опять-таки в последнем случае особо и спорить об архитектуре незачем: она уже вылизана на 100499 предыдущих проектах.
А люди, которым некомфортно заниматься разработкой строго по бумажке — сделали Android
В смысле, тот самый Android, который во второй версии жутко начинал тормозить при попытке ответить на звонок (в итоге ответить получалось не всегда, без всяких шуток)? Я то есть не знаю, как там с этим сейчас, но несколько лет назад Android у меня был, говорю со своего личного опыта. Проблем явно архитектурного характера там хватало. Между прочим, система года три на рынке была к этому времени.
У Windows Phone проблемы есть, но связаны-то они как раз не с архитектурой. Во всяком случае, на бюджетном виндофоне у жены проблем со звонками никогда не наблюдалось.
В смысле, тот самый Android, который во второй версии жутко начинал тормозить при попытке ответить на звонок?Угу. Тот самый. Заметьте, что iPhone тоже страдает проблемами с приёмом звонков.
Между прочим, система года три на рынке была к этому времени.И заняла за эти три года почти половину его.
У Windows Phone проблемы есть, но связаны-то они как раз не с архитектурой.Ну конечно они связаны с архитектурой. С чем же ещё? Просто у вас, по всей видимости, такой же подход к «правильной» архитектуре как у Танненбаума (помните его безаппеляционное Дебаты окончены. Микроядра победили?): какие-то там бенчмарки, способности делать те или иные вещи… ерунда всё это. Правильная архитектура — та, которая используется на бо́льшем числе устройств. Можно сколько угодно смеяться над архитектурой iOS (которая является злой пародией на микроядро), но если она позволяет сделать то, за что люди будут готовы платить деньги — это правильная архитектура. И можно сколько угодно расхваливать правильное ядро NT, но если оно не позволяет сделать продукт, который люди будут покупать — то это неправильная архитектура.
В то время, когда команда Android'а, сидящая в одном здании и имеющая в качестве документации чуть не карандашные наброски, выпустила кое-как работающее нечто Microsoft (начавшая заниматься всеми этими смарфонными делами задолго до Android'а и Google'а, напомню: Pocket PC 2000, в которой уже была поддержка телефонии, вышла, как несложно догадаться, в 2000м году) продолжала выпускать временные, мертворождённые, полуфабрикаты и объясняла как следующая версия (Windows Phone 7? или Windows Phone 8? или, может, Windows 10 Phone, наконец) всё сделает «правильно» и завоюет-таки наконец рынок.
Причём у Баллмера даже никаких сомнений не было в том, что так будет (когда он говорил о том что Apple заработает кучу денег, но завоюет 2-3% рынка в то время как Microsoft'у достанутся оставшиеся 60%-70%-80% он, надо полагать в это верил). Так в чём случилась беда? А беда случилась в том, что когда у вас рынок пуст вам не нужна самая «правильная», «разработанная по науке» архитектура — вам нужно что-то кое-как работающее (в достаточной степени работающее для того, чтобы первые покупатели не зареклись покупать ваши изделия — и не более того) но «здесь и сейчас».
Всё. Приехали. Все эти ваши «четко документированные процессы разработки структуры проекта» неспособны на это: они транжирят время. Которого у вас нет. В результате если вы работаете в компании, у которой «денег куры не клюют» (Microsoft, Nokia, etc), то вы разрабатываете нечто, что будет чудесно смотреться на выставках, но провалится на рынке (к моменту когда вы доведёте свою разработку «до ума» рынок буде уже твёрдо поделен между другими компаниями). Если у компании нет столько денег — то вы обанкротитесь ещё до этого момента.
Во всяком случае, на бюджетном виндофоне у жены проблем со звонками никогда не наблюдалось.Раз за вашу жену, но есть у меня один вопрос: а ей точно нужен смарфон? Если ей нужно только принимать звонки и всё, то не проще ли купить просто кнопочный телефон? Он ещё надёжнее будет. И дешевле.
У моей жены тоже WinPhone, и она тоже не жалуется. Он быстро работает, быстро лазит по сайтам и выглядит ничуть не хуже iOS и Android. Рынок приложений и архитектура оси — да, подкачали с моей точки зрения. Но осмелюсь предположить — так используют телефон процентов 60-70 моих знакомых не-айтишников.
Тем не менее, как iOS программист последние 5 лет, я с вами во всем согласен. И про один кампус тоже — с программистами я привык работать в одном здании, но с дизайнерами никогда не работал до этого. И вот, в 2013 году поработал — мы сидели напротив. Как же быстрее пошла продуктовая разработка, чем через джиру и чейндж-реквесты!
Тем не менее, как iOS программист последние 5 лет, я с вами во всем согласен. И про один кампус тоже — с программистами я привык работать в одном здании, но с дизайнерами никогда не работал до этого. И вот, в 2013 году поработал — мы сидели напротив. Как же быстрее пошла продуктовая разработка, чем через джиру и чейндж-реквесты!
Ну конечно они связаны с архитектурой. С чем же ещё?
Ну очевидно с 1) UX (в меньшей степени) 2) временем выхода на рынок (в большей)
Да, я знаю про PocketPC и Windows Mobile, там был целиком пункт 1. А с WP 8 уже 2, то есть когда всё сделали более-менее по уму, было уже поздно.
тот самый Android, который во второй версии жутко начинал тормозить при попытке ответить на звонок (в итоге ответить получалось не всегда, без всяких шуток
Android опередил своё время. Когда шикарным для телефона считалось 400MHz/256MB, managed-среде на таком железе было неуютно. Позже, когда Android мощно прокачал ARM-чипы (не только по мегагерцам), пришёл WP, тоже с managed средой, на хорошее железо. Посмотрел бы я на винду, поставленную на какой-нибудь Acer E120 (с его 192MB RAM).
Нет, там не во времени дело. Я читал как-то давно про эту проблему, точно всё не перескажу, но примерно смысл в том, что там архитектурно у UI-слоя средний приоритет заложен, поэтому какое-нибудь качающееся обновление вполне могло оказаться для системы более важным, чем графический интерфейс ответа на звонок.
Потом, у первых iPhone таких проблем не было насколько я помню.
В общем, это именно архитектурная проблема.
Потом, у первых iPhone таких проблем не было насколько я помню.
В общем, это именно архитектурная проблема.
Мы не знаем, как поведёт себя WP в условиях жёсткой нехватки ресурсов. Сейчас он просто завален мощностью и недогружен функциональностью, чтобы эту мощь потратить.
У первых iPhone не было этой проблемы просто потому, что они работали только с одной задачей. Что позволяло жёстко контролировать всю среду и потребление ресурсов. У звонилок за $20 проблемы нет по той же причине.
Ну то есть звонок для телефона не главное, главное что многозадачность? И это хорошая архитектура? Ну ок.
Ну то есть звонок для телефона не главноеА вы посмотрите иногда по сторонам: сколько людей используют смарфон чтобы звонить. Будете удивлены. То что в слове смартфон есть и часть «фон» — это скорее дань традиции. Он используется для серфинга, обмена SMS'ками (хотя в последнее время всякие WhatsApp'ы подпирают), как фотоаппарат и т.д. и т.п. Ах, да, иногда ещё и для звонков.
главное что многозадачность?Может и не самое главное, но да — это важная часть.
И это хорошая архитектура?Ещё раз: хорошая архитектура — та, которой люди пользуются. Плохая — та, которой не пользуются. Можно высказывать разные априорные предположения о том как улучшить архитектуру, конечно (иначе разрабатывать ничего не получится: между разработкой архитектуры и выходом на рынок проходят годы) но единственный и окончательный конечный критерий именно таков.
Вы говорите об успешности продукта. Который к собственно архитектуре имеет отношение очень условное. Или маркетинг — это у вас тоже архитектура?
Давайте я сразу это озвучу, прежде чем вы очередной простынёй разродитесь.
Успешность программного продукта зависит от:
— ситуации на рынке (наличия запроса, актуального или потенциального и ситуации с конкурентами)
— маркетинга (в широком смысле, не буду отдельно по составляющим раскладывать)
— дизайна (тоже в широком смысле)
— и где-то вот на четвёртом месте — архитектуры
Продукт с хорошей архитектурой может не быть популярным, а продукт с плохой архитектурой может быть. Например, если рынок уже прочно поделен, никакая архитектура уже не поможет вывести на него новый продукт.
А то у вас как-то всё в кучу смешалось.
Успешность программного продукта зависит от:
— ситуации на рынке (наличия запроса, актуального или потенциального и ситуации с конкурентами)
— маркетинга (в широком смысле, не буду отдельно по составляющим раскладывать)
— дизайна (тоже в широком смысле)
— и где-то вот на четвёртом месте — архитектуры
Продукт с хорошей архитектурой может не быть популярным, а продукт с плохой архитектурой может быть. Например, если рынок уже прочно поделен, никакая архитектура уже не поможет вывести на него новый продукт.
А то у вас как-то всё в кучу смешалось.
> То есть она должна быть где-то обговорена, записана, etc. А если она обсуждается, грубо говоря, во время обеда, то как он о ней узнает?
По-моему, четкое документирование процесса разработки и структуры проекта — это такая штука, которая must have и её наличие должно быть по дефолту. Не?
По-моему, четкое документирование процесса разработки и структуры проекта — это такая штука, которая must have и её наличие должно быть по дефолту. Не?
Совершенно не обязательно. «Чёткое документирование» часто позволяют экономить время, но на поддержание в адекватном состоянии всего этого также требуются ресурсы. Всегда есть некоторые вещи которые описаны и что-то, что передаётся «из уст в уста». Добавление в систему удалёнщиков обозначает, что все участники проекта должны начать более формально относиться к этому делу.
Ну просто все обсуждения архитектуры вести через групповой чат или там Slack. Никакого особого формализма, заодно потом и найти легче будет, чем вспомнить, что там кто кому за обедом сказал.
Документирование позволяет не просто экономить время, а повысить «передаваемость» проекта/его узлов. Т.е. вот вдруг внезапно человек, который писал модуль «А» уходит в Гугл, документации по модулю нет, и во весь рост встает вопрос — что делать? Ну и кроме того, то, что «обсуждали на кухне во время обеда», скажем, год назад вполне может быть (частично) забыто или «креативно дополнено» принимавшими участие в обсуждении. Если же документировать все этапы разработки — то таких проблем не будет.
Т.е. вот вдруг внезапно человек, который писал модуль «А» уходит в Гугл, документации по модулю нет, и во весь рост встает вопрос — что делать?А почему вдруг документации совсем нет? Если модуль «А» приняли-таки, то документация должны быть какая-никакая. Но её вовсе не обязательно поддерживать в адекватном состоянии во время разработки модуля «А» раз и в ней совершенно не нужно описывать то, что и так видно из кода (IDL'ей, заголовочных файлов и т.п.) модуля «А» два. Это делает её сильно меньше и проще.
Если же документировать все этапы разработки — то таких проблем не будет.Вот только времени на всё это уйдёт заметно больше.
Это — тоже вполне жизнеспособный вариант, никто не спорит, но он — далеко не единственный из возможных.
> А почему вдруг документации совсем нет?
Ну так выше же говорили, что «совершенно не обязательно»?
> Но её вовсе не обязательно поддерживать в адекватном состоянии
Тогда смысла в ней особого нет. Ибо с момента написания там все может поменяться десять раз.
Ну так выше же говорили, что «совершенно не обязательно»?
> Но её вовсе не обязательно поддерживать в адекватном состоянии
Тогда смысла в ней особого нет. Ибо с момента написания там все может поменяться десять раз.
Ну так выше же говорили, что «совершенно не обязательно»?
А в вашем мире есть либо «чёткое документирование», либо «документации совсем нет»? Цветов между белым и чёрным не существует?
Тогда смысла в ней особого нет. Ибо с момента написания там все может поменяться десять раз.С момента, когда вы начнёте готовить свою разработку или компонент к запуску? Вряд ли. Всё может «поменяться десять раз» в то время, когда ведёте активную разработку — но тут как раз особо и документация не нужна, так как есть куча людей, которые знают как что работает. А вот когда вы активную разработку сворачиваете — тут как раз важность документации возрастает, но и писать её становится легче, так как никаких «поменяться десять раз» больше быть не может.
Но это, понятно, если все в офисе работают, с удалёнщиками такой номер сложнее провернуть: обедать они с вами вместе не ходят, устроить спонтанную встречу на кухне возле кофе-машины тоже не получится, нужно как-то всё более формально оформлять с самого начала.
> А в вашем мире есть либо «чёткое документирование», либо «документации совсем нет»? Цветов между белым и чёрным не существует?
В нашем мире вот так — документация либо есть, и она более-менее полна и актуальна, либо практически бесполезна (или даже вредна в таком виде).
> А вот когда вы активную разработку сворачиваете
Мы её никогда не сворачиваем :(
В нашем мире вот так — документация либо есть, и она более-менее полна и актуальна, либо практически бесполезна (или даже вредна в таком виде).
> А вот когда вы активную разработку сворачиваете
Мы её никогда не сворачиваем :(
Мы её никогда не сворачиваем :(Извините, но позвольте мне не поверить. Я работал в разных компаниях — от стартапов в три человека до огромных монстров в десятки тысяч человек и нигде не видел такого, чтобы разработка всех компонентов велась непрерывно. Ну разве что в молодом стартапе где ещё ничего нет и потому нечего поддерживать. Ресурсы конечны, потому приходится выбирать. Даже если вся система, которую вы разрабатываете «всегда в разработке» в ней неизбежно есть компоненты, которые считаются «готовыми» и куда никто без необходимости не лазит и те, которые активно проектируются/перепроектируются.
Позволю, но это действительно так.
Да, есть участки кода, которые относительно давно не менялись. Но в целом, постоянно добавляются новые фичи, оптимизируются старые, т.е. код в целом постоянно меняется.
Ну и кроме этого, есть другая ветка/мажорная версия софта, которая вообще очень активно пилится.
Активная разработка != все переделывается с нуля в каждой версии.
Хотя, есть еще старая версия нашего софта, которая уже много лет не менялась. Но эта версия уже считается устаревшей, и её поддерживает (== в нем более-менее разбирается) ровно один человек.
Да, есть участки кода, которые относительно давно не менялись. Но в целом, постоянно добавляются новые фичи, оптимизируются старые, т.е. код в целом постоянно меняется.
Ну и кроме этого, есть другая ветка/мажорная версия софта, которая вообще очень активно пилится.
Активная разработка != все переделывается с нуля в каждой версии.
Хотя, есть еще старая версия нашего софта, которая уже много лет не менялась. Но эта версия уже считается устаревшей, и её поддерживает (== в нем более-менее разбирается) ровно один человек.
Нет.
1. Документация слишком быстро устаревает.
2. Документацию должны писать программисты проекта, а не отдельный человек.
3. Не у каждого есть способности внятно написать, чтобы не выглядело потоком сознания.
Вообще, давно замечаю, что людям очень тяжело читать «много букв». Даже если будет актуальная документация, не факт что все её прочтут и осмыслят (а не просто пробегуться взглядом для галочки «ознакомлен»).
1. Документация слишком быстро устаревает.
2. Документацию должны писать программисты проекта, а не отдельный человек.
3. Не у каждого есть способности внятно написать, чтобы не выглядело потоком сознания.
Вообще, давно замечаю, что людям очень тяжело читать «много букв». Даже если будет актуальная документация, не факт что все её прочтут и осмыслят (а не просто пробегуться взглядом для галочки «ознакомлен»).
НЛО прилетело и опубликовало эту надпись здесь
Для описания архитектуры и вообще нюансов проекта существуют вещи типа вики.
А что мешает наладить производственные процессы и использовать инструменты для коллективной разработки. Взять тот же crucible от atlassian (не реклама) и ввести правило по которому код не прошедший ревью не допускается к коммиту. +Настроить чекстайл чтоб алармировал если кто-то нарушил конвеншены. По моему этого должно хватить для того чтобы решить описанные вами проблемы.
Это тот же вопрос с эффективностью, и тот же ответ.
Что касается ужесточения контроля — да почему не согласятся-то? На oDesk этим занимается платформа (т.к. время нужно отмечать через клиент, который делает снимки экрана раз в 10 минут). И ничего, все как-то соглашаются. Вопрос договорённостей просто.
Что касается ужесточения контроля — да почему не согласятся-то? На oDesk этим занимается платформа (т.к. время нужно отмечать через клиент, который делает снимки экрана раз в 10 минут). И ничего, все как-то соглашаются. Вопрос договорённостей просто.
пункт про Эффективность — это описание ситуации, когда человек хочет работать.
А я говорю про ситуации, когда человек «ездит по ушам». В офисе сложно ездить по ушам, на удаленке — просто.
Этого заказчики и боятся.
При этом все мы знаем основную беду фриланса — это удаленщики, которые пропадают. У которых постоянно ломаются компы, отключают электричество и «родственники умирают»(с).
По сути работа с удаленщиками — это очень тщательный отсев мусорных кадров. Значительно более сложный и дорогой, чем отсев в офисе.
P.S.
Про oDesk — я бы не согласился. Лично мне сложно работать в условиях, когда кто-то стоит за спиной. Реально или виртуально.
А я говорю про ситуации, когда человек «ездит по ушам». В офисе сложно ездить по ушам, на удаленке — просто.
Этого заказчики и боятся.
При этом все мы знаем основную беду фриланса — это удаленщики, которые пропадают. У которых постоянно ломаются компы, отключают электричество и «родственники умирают»(с).
По сути работа с удаленщиками — это очень тщательный отсев мусорных кадров. Значительно более сложный и дорогой, чем отсев в офисе.
P.S.
Про oDesk — я бы не согласился. Лично мне сложно работать в условиях, когда кто-то стоит за спиной. Реально или виртуально.
Откуда вообще эта проблема? Человек не хочет работать — его увольняют, на его место нанимают другого.
Такой человек не нужен ни в офисе, ни на удалёнке. При том, в офисе его уволить намного сложнее (трудовой кодекс и т.д.) и да, приходится заставлять работать.
Такой человек не нужен ни в офисе, ни на удалёнке. При том, в офисе его уволить намного сложнее (трудовой кодекс и т.д.) и да, приходится заставлять работать.
Проблема в том, что в офисе нужно очень мало времени, чтобы поймать сотрудника на раздолбайстве.
На удаленке «профессионал» по ушам может ездить очень и очень долго.
На удаленке «профессионал» по ушам может ездить очень и очень долго.
Если такой «профессионал» может долго ездить по ушам лиду, это вопрос компетентности лида.
Если на то пошло, точно так же можно ездить по ушам и в офисе, в чём проблема изображать бурную деятельность и ничего не делать?
Но сколько по ушам ни езди, результат работы либо есть, либо нет. Если лид/менеджер/кто там работу контролирует не способен увидеть отсутствие результата, то ну что тут сказать.
Если на то пошло, точно так же можно ездить по ушам и в офисе, в чём проблема изображать бурную деятельность и ничего не делать?
Но сколько по ушам ни езди, результат работы либо есть, либо нет. Если лид/менеджер/кто там работу контролирует не способен увидеть отсутствие результата, то ну что тут сказать.
В офисе все перед глазами. А по удаленке — только то, что сам удаленщик предоставит.
В мало-мальски сложном проекте в первые месяцы результата нет ни на удаленке, ни в офисе. Потому что просто въехать в код, в архитектуру, в проект — требует времени. И не мало.
результат работы либо есть, либо нет.
В мало-мальски сложном проекте в первые месяцы результата нет ни на удаленке, ни в офисе. Потому что просто въехать в код, в архитектуру, в проект — требует времени. И не мало.
Не знаю, какой такой нужен проект, чтобы в него въезжать несколько месяцев.
На первой моей работе (в офисе) я начинал с проекта, над которым трудились сотни человек в течение нескольких лет. Точный объем кода не скажу уже, но думаю можно представить. Например, Visual Studio на таких объёмах вешался, поэтому пользовались только SourceInsight.
На подготовку мне дали неделю, после чего начали выдавать реальные задачи.
На первой моей работе (в офисе) я начинал с проекта, над которым трудились сотни человек в течение нескольких лет. Точный объем кода не скажу уже, но думаю можно представить. Например, Visual Studio на таких объёмах вешался, поэтому пользовались только SourceInsight.
На подготовку мне дали неделю, после чего начали выдавать реальные задачи.
Ну давайте возьмём для примера проект, который у всех на слуху: Chromium. Попробуйте его хотя бы собрать для начала, а там уже можно будет говорить — какие «реальные задачи» вы сможете решать через неделю.
Перед товаристчами из Samsung'а порождающие ужасы, типа этого была явно поставлена задача сделать за неделю какую-нибудь «реальную задачу». И это ещё не самый худший возможный вариант, который можно получить от фрилансера, найденного на бирже.
Перед товаристчами из Samsung'а порождающие ужасы, типа этого была явно поставлена задача сделать за неделю какую-нибудь «реальную задачу». И это ещё не самый худший возможный вариант, который можно получить от фрилансера, найденного на бирже.
А почему «реальная задача» обязательно должна означать «сложную задачу»? Первая задача, которую мне дали, состояла в том, чтобы поменять текстовый ресурс.
Задача к слову не вполне элементарная, потому что его нужно было а) найти б) понять, как скомпилировать. Но и не что-то сверхсложное.
Реальная это задача? Да. Можно такую задачу дать через неделю после начала работы? Можно. Можно по ней судить о том, работал человек или нет? Да.
Вы спорите не с моим утверждением, а со своими мыслями на тему.
Задача к слову не вполне элементарная, потому что его нужно было а) найти б) понять, как скомпилировать. Но и не что-то сверхсложное.
Реальная это задача? Да. Можно такую задачу дать через неделю после начала работы? Можно. Можно по ней судить о том, работал человек или нет? Да.
Вы спорите не с моим утверждением, а со своими мыслями на тему.
А почему «реальная задача» обязательно должна означать «сложную задачу»?Потому что время людей, которые смотрять на ваш CL тоже чего-то стоит. Если усилия, которые они потратили на review вашего кода окажутся больше, чем те, которые они потратили бы на это дело сами, то, при всём уважении, задачу нельзя назвать «реальной»: это учебная задача и давая её вам компания теряет, а не приобретает!
Первая задача, которую мне дали, состояла в том, чтобы поменять текстовый ресурс.Нет. Скорее всего люди, которые давали вам эту задачу могли сами бы всё сделать с куда меньшими затратами, чем те, которые ушли на то, чтобы ввести вас в курс дела.
Реальная это задача?
Вы спорите не с моим утверждением, а со своими мыслями на тему.Мы, похоже, спорим о терминологии. С вашей точки зрения человек начинает «выдавать на гора» результат не тогда, когда от его появления в команде возрастает её производительность, а когда он получает свой первый LGTM. Что ни разу не так. Первое время (в зависимости от сложности проекта это могут быть дни, недели, а то и месяцы) он снижает скорость работы всей команды: потому что CLи от него поступают элементарные, а на разговоры с ним уходит время у людей, которые могли бы делать что-то более сложное. Называть это «реальной работой» IMNSHO нельзя — скорее это интерншип, пусть даже формально он так не называется. Вот когда вам доверят делать что-то такое, что «старшие члены» команды не могут сами за 5 минут сделать — вот тогда только вы можете считаться полноценным членом команды.
Вы невнимательно читали обсуждение. Речь не о том, чтобы через неделю выдавать что-то сильно полезное. Речь о том, что оценить, работает человек или нет, легко можно и через неделю, а не через несколько месяцев, даже на самом крупном проекте.
Через неделю вы сможете оценить, в лучшем случае, его умение читать документацию и задавать вопросы. Сможет ли он что-то полезное создавать и, что ещё важнее, какие ресурсы будут нужно выделять остальным на общение с ним — вы сможете узнать только через несколько месяцев.
Я видел как людей, которые «что-то-такое» выдавали почти сразу после начала работы над проектом, так и людей, которые вначале тратили кучу времени у всех окружающих на то, чтобы разобраться в происходящем в проекте и долгое время не порождали ничего — и первые далеко не всегда лучше вторых в долгострочной перспективе.
Идеал, конечно — это когда человек во всём сразу сам разбирается и сразу начинает порождать полезный код, который не вызывает замечаний у «старожилов», но я как-то сомневаюсь, что такое вообще бывает.
Я видел как людей, которые «что-то-такое» выдавали почти сразу после начала работы над проектом, так и людей, которые вначале тратили кучу времени у всех окружающих на то, чтобы разобраться в происходящем в проекте и долгое время не порождали ничего — и первые далеко не всегда лучше вторых в долгострочной перспективе.
Идеал, конечно — это когда человек во всём сразу сам разбирается и сразу начинает порождать полезный код, который не вызывает замечаний у «старожилов», но я как-то сомневаюсь, что такое вообще бывает.
Ещё раз, прочитайте пожалуйста, с чего начиналась эта ветка и о чём в ней речь.
На всякий случай, упрощаю вам задачу, отвечал я вот на эти два тезиса:
На всякий случай, упрощаю вам задачу, отвечал я вот на эти два тезиса:
пункт про Эффективность — это описание ситуации, когда человек хочет работать.
А я говорю про ситуации, когда человек «ездит по ушам». В офисе сложно ездить по ушам, на удаленке — просто.
Проблема в том, что в офисе нужно очень мало времени, чтобы поймать сотрудника на раздолбайстве.
На удаленке «профессионал» по ушам может ездить очень и очень долго.
Угу. И вашим ответом было: «результат работы либо есть, либо нет».
А теперь посмотрите на то, что я написал. Исходя из принципа «увольняем тех, кто не выдаёт результат» вы уволите как раз тех, кто «долго запрягает, но быстро едет» (ну и бездельников, конечно).
IT-разработка — это не наука, а искусство (всё что становится рутиной может и должно быть автоматизировано), так что наилучшие результаты показывают не команды, которым руководят «правильные менеджеры», а сплочённые коллективы, которые управляют собой сами.
А с этим у удалёнки — проблема. «Кристаллизация команды» — вещь, которая при общении в офисе происходит достаточно легко, а на удалёнке — только в совершенно исключительных случаях.
А теперь посмотрите на то, что я написал. Исходя из принципа «увольняем тех, кто не выдаёт результат» вы уволите как раз тех, кто «долго запрягает, но быстро едет» (ну и бездельников, конечно).
IT-разработка — это не наука, а искусство (всё что становится рутиной может и должно быть автоматизировано), так что наилучшие результаты показывают не команды, которым руководят «правильные менеджеры», а сплочённые коллективы, которые управляют собой сами.
А с этим у удалёнки — проблема. «Кристаллизация команды» — вещь, которая при общении в офисе происходит достаточно легко, а на удалёнке — только в совершенно исключительных случаях.
IT-разработка — это не наука, а искусство
Тогда тем более о чём речь? Правильный менеджер вычислит бездельника и без формальных признаков. Я просто привёл схему, которая точно работать будет (да, со сбоями и недостатками, но бездельников она отсеет).
Правильный менеджер вычислит бездельника и без формальных признаков.О, святая простота. Если бы менеджеры были в состоянии «вычислять бездельников» (пусть даже и с формальными признаками), то мир был бы совсем другим. Не умеют они этого. Если компания перешла в состояние, когда она опирается на умения менеджеров, то это значит, что она — больше не лидер, всё, её время — ушло. Хороший пример — Microsoft при Баллмере.
Ну так вы определитесь, либо искусство, либо «не умеют».
Где искусство — там и формальные критерии не нужны. Где нужны, их всегда можно ввести (да, они будут неидеальными, но своё дело делать будут).
Вот и весь мой несложный посыл.
Где искусство — там и формальные критерии не нужны. Где нужны, их всегда можно ввести (да, они будут неидеальными, но своё дело делать будут).
Вот и весь мой несложный посыл.
Ну так вы определитесь, либо искусство, либо «не умеют».
Что значит «определитесь»? Да, программирование — это искусство и именно поэтому менеджеры и не умеют «вычислять бездельников».
Где искусство — там и формальные критерии не нужны.Большего бреда и ляпнуть нельзя. Кино — это, разумеется, искусство (по крайней мере какая-то его часть), но это не значит что «критерии не нужны»: иначе бы все производители давно обанкротились. Критерий один: популярность полученного результата. Вот только предсказать его довольно-таки сложно (иначе не выпускали бы известные студии провальных фильмов). Приходится угадывать с помощью разных критериев. Получается… с переменным успехом. И чем меньше у вас возможностей для общения с человеком (неважно: это языковый барьер или удалённая работа) тем процент успеха меньше.
Где нужны, их всегда можно ввести (да, они будут неидеальными, но своё дело делать будут).Не будут. К моменту когда вы точно знаете чего из себя человек представляет может быть уже поздно. Либо вы следите за каждым шагом разработчика (и тогда обычно дешевле просто обойтись без него), либо он имеет возможность подложить вам такую свинью, что и 100 ваших программистов с ней не расхлебаются вовремя.
Удел удалёнки — типовые несложные проекты в фирме, которая может себе позволить провал любого из них. Тут — да, она позволяет экономить. За счёт качества, разумеется. Всё.
Попытка перевести что-то другое на удалёнку рано или поздно кончится слезьми.
Удел удалёнки — типовые несложные проекты в фирме, которая может себе позволить провал любого из них. Тут — да, она позволяет экономить. За счёт качества, разумеется. Всё.
Вы сейчас свои фантазии озвучиваете. 37 Signals тому доказательство (тем более что критерий у вас один — популярность).
Не будут. К моменту когда вы точно знаете чего из себя человек представляет может быть уже поздно.
Не обязательно знать точно, достаточно с высокой вероятностью. А этого можно добиться быстро.
Вы сейчас свои фантазии озвучиваете.Серьёзно?
37 Signals тому доказательствоНу как вас сказать, чтобы не обидеть. Вы бы хоть на их вебсайт зашли разок, а? А то получается, что в качестве «доказательства» мне предъявляется компания, которая бо́льшую часть своей истории занималась разработкой кучи всякого добра но кончила при этом тем, что все эти «великолепные» разработки были выкинуты к чёртовой матери и фирма вернулась к тому, что она изначально разрабатывала небольшим коллективом.
(тем более что критерий у вас один — популярность).Угу. И я вполне готов признать, что Basecamp [пока ещё] популярен. Но он — далеко не #1 и я вовсе не уверен, в том, что он уверен благодаря их упору на удалёнщиков, а не вопреки ему. Попытки же сделать что-то большее — провалились, это уже видно.
Эти разработки приносили доход. Этого более чем достаточно, чтобы судить об успешности продукта. Так что нет, не провалились. Тот же Highrise вывели в отдельную компанию например.
А про Ruby on Rails вы как умудрились забыть? Это тоже провал видимо? Программисты-удалёнщики создали фреймворк, фактически определивший архитектуру большинства современных веб-фреймворков.
А про Ruby on Rails вы как умудрились забыть? Это тоже провал видимо? Программисты-удалёнщики создали фреймворк, фактически определивший архитектуру большинства современных веб-фреймворков.
А были у RoR сроки/бюджеты? Или это разработка в своё удовольствие, в режиме сам-себе-заказчик.
Потом, даже если считать всё кроме Basecamp провалом — извините, а сколько было провальных проектов у Google? До сих пор поиск — их основной продукт.
Для команды из нескольких человек создать многомиллионный бизнес и занять на своём рынке второе место между, на минуточку, Microsoft и Atlassian — это такая степень успеха, о которой большинство компаний могут только мечтать.
Для команды из нескольких человек создать многомиллионный бизнес и занять на своём рынке второе место между, на минуточку, Microsoft и Atlassian — это такая степень успеха, о которой большинство компаний могут только мечтать.
Всё верно, но вот в чём вопрос: был ли успех Basecamp вызван «инновационным» подходом к разработке с упором на удалёнщиков или же, наоборот, успех Basecamp позволил поддерживать на плаву неэффективную модель разработки?
Если исходить из того, что всё кончилось «возвратом к истокам», то вероятнее, всё-таки второе.
Что касается Гугла: разумеется у Google была куча провальных проектов. И ещё будет. Но когда речь заходила о том, чтобы разработать что-то, что было критично для будущего компании, то выделяли маленькую, нифига не распределённую, команду — и они делали в нужные сроки то, что было нужно. Android, Chrome, ChromeOS. Правда с Google+ получилась проблемка — но уж очень далеко вперёд вырвался Facebook к моменту начала этого проекта. Ничего подобного в 37signals нет и не было, наоборот: все проекты, которые они затевали с целью чего-то добиться «плохо кончили», взлетел же при этом один-единственный проект, который они делали «для себя».
Это скорее из серии «даже незаряженное ружьё стреляет раз в год», а не из серии «переходите на удалёнку — и будет вам счастье».
Если исходить из того, что всё кончилось «возвратом к истокам», то вероятнее, всё-таки второе.
Что касается Гугла: разумеется у Google была куча провальных проектов. И ещё будет. Но когда речь заходила о том, чтобы разработать что-то, что было критично для будущего компании, то выделяли маленькую, нифига не распределённую, команду — и они делали в нужные сроки то, что было нужно. Android, Chrome, ChromeOS. Правда с Google+ получилась проблемка — но уж очень далеко вперёд вырвался Facebook к моменту начала этого проекта. Ничего подобного в 37signals нет и не было, наоборот: все проекты, которые они затевали с целью чего-то добиться «плохо кончили», взлетел же при этом один-единственный проект, который они делали «для себя».
Это скорее из серии «даже незаряженное ружьё стреляет раз в год», а не из серии «переходите на удалёнку — и будет вам счастье».
Если совсем коротко, то вы сейчас всё-таки ведёте речь о возражении №3, конкретно о той части, которая касается удалённого управления командой.
Все эти смешные вопросы «а как я узнаю что человек ничего не делал» (да элементарно) — они возникают только из-за лени управляющего состава, привыкшего работать в конкретных условиях и не желающего приспосабливаться к другим.
Все эти смешные вопросы «а как я узнаю что человек ничего не делал» (да элементарно) — они возникают только из-за лени управляющего состава, привыкшего работать в конкретных условиях и не желающего приспосабливаться к другим.
В ближайшие годы 30% всей работы связанной с интернетом будет удаленной.
Основным направлением развития объединенных крупнеших бирж фриланса в мире odesk и elance не борьба с другими фриланс биржами, а откусывание пирога хедхантинговых сайтов, по сути биржа становится резюме работников, полностью верифицированным и открытым бекграундом. ПОчти идел при найме сотрудников.
Основным направлением развития объединенных крупнеших бирж фриланса в мире odesk и elance не борьба с другими фриланс биржами, а откусывание пирога хедхантинговых сайтов, по сути биржа становится резюме работников, полностью верифицированным и открытым бекграундом. ПОчти идел при найме сотрудников.
Фриланс — это очень частный и специфический пример деятельности, которую называют «разработкой». Большинство проектов, как мне кажется, — это сложные системы, которые развиваются годами и требуют глубокого понимания со стороны команды разработчиков. Например, когда в проект приходит новый человек, его производительность может быть низкой первые несколько месяцев, т.е. первые несколько месяцев компания как бы инвестирует в обучение нового сотрудника себе в убыток. И только потом человек начинает решать задаяи так, что это укладывается в общую архитектуру и не вредит системе (а в лучших случаях — улучшает эту архитектуру или даже меняет ее).
В случае фриланса все это затруднительно. Фриланс больше подходит для относительно коротких и законченных задач. Длительная разработка сложной системы — это все-таки удаленна работа, не фриланс. Не думаю, что биржи сильно помогают удаленщикам, они все-таки больше именно для фрилансеров.
В случае фриланса все это затруднительно. Фриланс больше подходит для относительно коротких и законченных задач. Длительная разработка сложной системы — это все-таки удаленна работа, не фриланс. Не думаю, что биржи сильно помогают удаленщикам, они все-таки больше именно для фрилансеров.
Я работаю на одку компанию у которой полностью распределенная айти комманда, разработчики, админы и пр.
Ну несколько месяцев на вход вы конечно загнули, если это уж совсем никакой документации нет, если вести вменяемую вики за пару недель можно спокойно войти в понимание процессов и разработки.
Я имел ввижу перерождение фриланса в удаленную работу, то есть по сути в обычную работу в офисе, только удаленно и с удобным графиком, от этого никуда не уйти, уже сейчас есть достаточно крупные распределенные команды, скайп, гиты, редмайны и прочие плюшки для командной разработки делают своё дело.
Если скажем в году 2004 я вообще ни разу не видел удаленных сотрудников, максимум офлайноприходящий админ, то сейчас уже есть полностью удаленные компании по разработке и администрированию.
Ну несколько месяцев на вход вы конечно загнули, если это уж совсем никакой документации нет, если вести вменяемую вики за пару недель можно спокойно войти в понимание процессов и разработки.
Я имел ввижу перерождение фриланса в удаленную работу, то есть по сути в обычную работу в офисе, только удаленно и с удобным графиком, от этого никуда не уйти, уже сейчас есть достаточно крупные распределенные команды, скайп, гиты, редмайны и прочие плюшки для командной разработки делают своё дело.
Если скажем в году 2004 я вообще ни разу не видел удаленных сотрудников, максимум офлайноприходящий админ, то сейчас уже есть полностью удаленные компании по разработке и администрированию.
НЛО прилетело и опубликовало эту надпись здесь
Ну так и не надо путать фрилансеров и удаленщиков. В статье идет речь о людях, которые дома по 8 часов в день работают на одну и ту же компанию.
НЛО прилетело и опубликовало эту надпись здесь
Не соглашусь, с тем, что нет будущего — знаю две аутсорс конторы, у которых сотрудники на удаленке. За счет экономии на офисе, HR и т.п. по цене для клиента уделывают индусов, при высоких зарплатах самих разработчиков.
Я работаю в удаленной команде, разницы с работой в офисе я вообще не вижу. То же планирование, тот же стендап в 10 утра, те же митинги. Давление/влияние у работодателя только одно — или дать премию или уволить. Чем он еще может давить даже в офисном варианте?
отсутствие коммуникации и хоть какого-то давления\влияния на потенциального сотрудника со всеми вытекающими.
Я работаю в удаленной команде, разницы с работой в офисе я вообще не вижу. То же планирование, тот же стендап в 10 утра, те же митинги. Давление/влияние у работодателя только одно — или дать премию или уволить. Чем он еще может давить даже в офисном варианте?
Вы правы в вашем конкретном случае. Возможно, вы как раз тот самый звездный инженер, который способен эффективно работать удаленно, и которых (ИМХО) мало. Но беда не только в том, что таких мало: беда также в том, что даже если набрать таких инженеров, то нужно иметь много нетривиальных навыков для организации их работы и управления ими (т.е. получается «мало в квадрате»).
Я соглашусь, что быть фрилансером может не каждый. Я имею ввиду найти клиента и продать ему свои услуги, спланировать работу и сроки и т.п.
Но вы же к экзаменам готовились дома? Курсовые и дипломные работы? И все как бы получалось.
По моему мнению не нужно иметь уникальные качества, что бы работать удаленно
Но вы же к экзаменам готовились дома? Курсовые и дипломные работы? И все как бы получалось.
По моему мнению не нужно иметь уникальные качества, что бы работать удаленно
Самодесциплина нужна. Она далеко не у всех есть.
Сам наверно года полтора привыкал к тому, что надо самостоятельно контролировать свою загруженность.
Нас с детства учат работать под контролем: школа->вуз->работа в офисе. Всегда есть контроль. А тут на тебе: работай, при этом никто не штрафует за опоздания, не следит за рабочим временем и т.д.
Тяжело первое время.
Хотя я 6 лет удаленщик, а до сих пор бывают дни когда тяжело себя заставить работать.
Сам наверно года полтора привыкал к тому, что надо самостоятельно контролировать свою загруженность.
Нас с детства учат работать под контролем: школа->вуз->работа в офисе. Всегда есть контроль. А тут на тебе: работай, при этом никто не штрафует за опоздания, не следит за рабочим временем и т.д.
Тяжело первое время.
Хотя я 6 лет удаленщик, а до сих пор бывают дни когда тяжело себя заставить работать.
Ну как никто не следит? Все работают по соглашению в одной таймозоне, стендап в одно и тоже время. Движение в треккере задач и коммиты. Все ж прекрасно видно
Вы лукавите. Видно гораздо хуже.
Из офиса раньше времени не уйдешь, потому что это сразу видно. И опаздывать тоже не захочешь.
А удаленно в митинге можно и в трусах поучаствовать, сразу после него продолжив спать.
Офис просто самим своим распорядком и открытостью дисциплинирует.
Удаленка это большое о самоконтроле.
Из офиса раньше времени не уйдешь, потому что это сразу видно. И опаздывать тоже не захочешь.
А удаленно в митинге можно и в трусах поучаствовать, сразу после него продолжив спать.
Офис просто самим своим распорядком и открытостью дисциплинирует.
Удаленка это большое о самоконтроле.
НЛО прилетело и опубликовало эту надпись здесь
Может быть сначала поясните на чём основано это утверждение?
> Исходя из контекста статьи, вы наверное имели в виду «удаленная фрилансовая работа по принципу аутсорсинга».
А то вы как-то его привели как нечто само собой разумеющееся.
> Исходя из контекста статьи, вы наверное имели в виду «удаленная фрилансовая работа по принципу аутсорсинга».
А то вы как-то его привели как нечто само собой разумеющееся.
Всегда забывают про особенности психики людей.
Во-первых, ощущение команды без личного общения размывается.
Во-вторых, без личного общения снижается значимость слов (и мотивационный эффект). На эту тему даже проводили эксперименты — отдавая команду испытуемому лично, по телефону и с помощью аудиозаписи.
Банальный пример — вы утром договорились с напарником сделать фичу и вечером он спрашивает, как у вас дела (а вы ничего не сделали). Что психологически проще — сказать ему это в лицо или написать в скайп «доделаю завтра» и уйти гулять?
Если задуматься, то кто подходит для full remote? Люди, не нуждающиеся в обществе и умеющие держать мотивацию на постоянном уровне. Плюс, у них дома должно быть рабочее место без отвлекающих факторов. Сколько таких в типичной софтверной конторе? 1 из 50?
А вот иногда поработать из дому — это да. Разнообразие это всегда хорошо. Думаю, во многих компаниях такое разрешено (или закрывают глаза, если не наглеть).
Во-первых, ощущение команды без личного общения размывается.
Во-вторых, без личного общения снижается значимость слов (и мотивационный эффект). На эту тему даже проводили эксперименты — отдавая команду испытуемому лично, по телефону и с помощью аудиозаписи.
Банальный пример — вы утром договорились с напарником сделать фичу и вечером он спрашивает, как у вас дела (а вы ничего не сделали). Что психологически проще — сказать ему это в лицо или написать в скайп «доделаю завтра» и уйти гулять?
Если задуматься, то кто подходит для full remote? Люди, не нуждающиеся в обществе и умеющие держать мотивацию на постоянном уровне. Плюс, у них дома должно быть рабочее место без отвлекающих факторов. Сколько таких в типичной софтверной конторе? 1 из 50?
А вот иногда поработать из дому — это да. Разнообразие это всегда хорошо. Думаю, во многих компаниях такое разрешено (или закрывают глаза, если не наглеть).
Почему в комментариях удаленных работников рассматривают чаще всего как фрилансеров?
Удаленный работник != фрилансер
Удаленный работник != фрилансер
Однако если бы система массового образования прививала навыки удалённого командного взаимодействия (а я уверен, что рано или поздно это случится), проблемы бы просто не было.
А чем Вам дистанционное образование это не обеспечивает? Конечно же не всякое, но тем не менее.
НЛО прилетело и опубликовало эту надпись здесь
У нас в компании, в которой работаю я, используется следующая система работы.
Есть необходимость обслуживать клиентов и решать технические вопросы 24 часа в сутки. Но при этом перечень вопросов не очень высокого уровня, а со сложные баги решаются в течение недели с передачей их в главный офис компании в отдел разработки.
Чтобы организовать полноценные 24 часа онлайн требуется организация сложных сменных групп и прочее. Так как мало кто из людей согласится хотя бы месяц работать каждый день в ночное время. В тоже время открытие своих представительств невыгодно для компании.
В итоге компания сделала следующее:
Наняла отдельных людей в Москве, Владивостоке и Нью-Йорке, оформила их официально в штат. Получился 24 стабильный онлайн, а люди работают комфортно в своем часовом поясе. Удобно и «дешево» относительно.
Т.е. модель мини-представительств что ли. Либо небольшие филиалы.
Есть необходимость обслуживать клиентов и решать технические вопросы 24 часа в сутки. Но при этом перечень вопросов не очень высокого уровня, а со сложные баги решаются в течение недели с передачей их в главный офис компании в отдел разработки.
Чтобы организовать полноценные 24 часа онлайн требуется организация сложных сменных групп и прочее. Так как мало кто из людей согласится хотя бы месяц работать каждый день в ночное время. В тоже время открытие своих представительств невыгодно для компании.
В итоге компания сделала следующее:
Наняла отдельных людей в Москве, Владивостоке и Нью-Йорке, оформила их официально в штат. Получился 24 стабильный онлайн, а люди работают комфортно в своем часовом поясе. Удобно и «дешево» относительно.
Т.е. модель мини-представительств что ли. Либо небольшие филиалы.
ну да, аграрной промышленностью удаленно не займешься, не займешься удаленно и работой на производстве, так же удаленно нельзя строить дома или подстричь человека, будущее в таком ракурсе пока видно лишь IT специалистам и прочим областям, зависимым только от информации, к примеру журналюги, репортеры и так далее, ученые какие-то.
Заголовок уж слишком желтый, получается, что такое будущее может коснуться очень небольшой доли общей массы людей.
Заголовок уж слишком желтый, получается, что такое будущее может коснуться очень небольшой доли общей массы людей.
Никакой, даже самый современный офис не заменит мурчанье твоего кота на коленях
Вообще, при грамотной самомотивации, удачном рабочем и всем-таком личная производительность фрилансера будет значительно выше.
Однако, если вы считаете, что производительность команды равна сумме производительностей ее членов, то вам, скорее всего просто не везло с менеджерами.
При удаленной работе вряд ли может произойти то, что Де Марко называл «кристаллизацией команды»
Так что таки да — удаленная работа хороша в тех случаях, когда задача легко разбивается на атомарные и формальные таски, которые несложно контролировать.
Кровавый же энтерпрайз, да и просто задачи высокой сложности, решаемые таким способом потребуют затрат на контроль соизмеримых со стоимостью разработки.
Так что, кмк — удаленка имеет ограниченную нишу применимости, внутри которой она может развиваться, вне — не очень.
Однако, если вы считаете, что производительность команды равна сумме производительностей ее членов, то вам, скорее всего просто не везло с менеджерами.
При удаленной работе вряд ли может произойти то, что Де Марко называл «кристаллизацией команды»
Так что таки да — удаленная работа хороша в тех случаях, когда задача легко разбивается на атомарные и формальные таски, которые несложно контролировать.
Кровавый же энтерпрайз, да и просто задачи высокой сложности, решаемые таким способом потребуют затрат на контроль соизмеримых со стоимостью разработки.
Так что, кмк — удаленка имеет ограниченную нишу применимости, внутри которой она может развиваться, вне — не очень.
Вообще, при грамотной самомотивации, удачном рабочем и всем-таком личная производительность фрилансера будет значительно выше.
Хорошо бы такого самомотивированного человека пересадить в офис на некоторое время и сравнить результаты.
Самомотивация — полезный навык и в офисе и на удаленке.
Можно пахать дома, а можно филонить в офисе)
Вообще по моим наблюдениям отношение производительностей дома/в офисе в наибольшей степени зависит от организации домашнего рабочего места и убеждения семьи, что «работа — это работа», остальное — о-малое.
Вообще по моим наблюдениям отношение производительностей дома/в офисе в наибольшей степени зависит от организации домашнего рабочего места и убеждения семьи, что «работа — это работа», остальное — о-малое.
Близкие люди имеют неприятную фичу — чувствовать за километр, что они — о-малое, а потом очень обижаются-расстраиваются-на развод подают и кота с собой увозят.
Может, это и к лучшему? По жизни лучше идти с проверенными людьми, которые поддержат в трудную минуту и включат мозг для оперирования элементарной логикой. Жизнь-то одна всего.
Профессор M(ФТИ) Д. В. Беклемишев (тот который из кричалки «Каждому лектору — в ухо по вектору, а Дмитрию Валадимировичу — ортонормированный базис), однажды составил прекрасные заметки о женской логике. Увы с формальной логикой она и близко не сходится.
У меня жена тоже удаленщица. Без проблем работаем и друг друга без необходимости не дергаем.
Полагаю мифы о женской логике сформированы в целом на основе общей женской тупости которая объясняется доминированием до недавнего времени мнения «жена должна быть домохозяйкой» и, соответственно, отсутствие какого-либо образования у женщин.
Знаю многоженщиндевушек, которые вполне разумны и с логикой проблем не имеют.
Полагаю мифы о женской логике сформированы в целом на основе общей женской тупости которая объясняется доминированием до недавнего времени мнения «жена должна быть домохозяйкой» и, соответственно, отсутствие какого-либо образования у женщин.
Знаю много
Почти согласен с вами) Требуется немало времени, чтобы убедить близких людей, что когда вы работаете — вас нет дома. Нет и точка.
С противоположной стороны, для улучшения обстановки в семье, когда вы не работаете (вне определенного вами самостоятельно и заранее времени) — вы не работаете, не думаете сверх необходимого о работе и вообще всячески радуете вниманием близких и котов.
Очень частая ошибка фрилансера в том, что «работать когда хочешЬ» быстро превращается в «полуработать вообще всегда».
Для любых сторонних инициатив есть внутренний голос «но мне же нужно сделать это», а для «мне нужно сделать этО» не хватает мотивации.
С противоположной стороны, для улучшения обстановки в семье, когда вы не работаете (вне определенного вами самостоятельно и заранее времени) — вы не работаете, не думаете сверх необходимого о работе и вообще всячески радуете вниманием близких и котов.
Очень частая ошибка фрилансера в том, что «работать когда хочешЬ» быстро превращается в «полуработать вообще всегда».
Для любых сторонних инициатив есть внутренний голос «но мне же нужно сделать это», а для «мне нужно сделать этО» не хватает мотивации.
НЛО прилетело и опубликовало эту надпись здесь
Я точно решил, как контракт закончится текущий, буду снимать место в офисе у знакомого и ходить на удаленную работу в свой кабинет. И работаешь спокойно (в компании тихих айтишников) и дисциплина будет. Дома не получилось.
Поделитесь, пожалуйста, почему именно не получилось — желательно как можно более подробно.
Просыпаешься. Вокруг комфортная обстановка дома, где тело привыкло нежиться и филонить. Пока перевалишься с боку на бок, перетекая с дивана в тапки и ползёшь неторопливо варить кофе с мыслями «успею, куда спешить», потом процесс питья кофе растягивается на час с чтением всяких вконтактов, хабрахабров и т.п. уже и время обеда настало. Дома постоянно что-то отвлекает, в том числе приятные мелкие задачи на компе: фотографию обработать, дописать заметку, посмотреть чужие снимки и т.п. А на работу пришел с ноутом в котором текущий проект и музыка и сидишь спокойно работаешь не отвлекаясь. Я не совсем понимаю как вам это поможет, все мы разные.
Что-то мешает работать из дома с ноута, где только «текущий проект и музыка»? Ничего же, кроме вас самих.
Кстати, есть вариант работы в кафешках с вайфаем. Большинство не против посетителя, если вы что-то закажете и сидите тихо, а кафе все-равно выбирается обычно полупустое.
Кстати, есть вариант работы в кафешках с вайфаем. Большинство не против посетителя, если вы что-то закажете и сидите тихо, а кафе все-равно выбирается обычно полупустое.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Эффективность удаленки, как сравнительную величину, нельзя сравнивать между разными людьми.
Сравнение имеет смысл в пределах одного человека — вот его эффективность в офисе и вот на удаленке.
Например, если человек хорошо работает на удаленке, он организован, мотивирован, и т.д., может быть в офисе он сможет добиваться больших результатов.
И его смело можно повышать до тимлида, давать команду и доверять серьёзные проекты.
А так же повышать оклад, дать отдельный кабинет, готовить ему крем-брюле и прочие плюшки, чтобы он оставался в офисе (крем брюле помог google нанять Луиса Андре Баррозо).
Хотя возможен и обратный эффект — в офисе эффективность человека может снизиться.
Но тогда руководитель будет четко понимать, какие плюсы и минусы при удаленной работе конкретного сотрудника.
А без такого сравнения получаем неопределенность и лотерею.
Если человек работает на удаленке и не справляется, остается только гадать — это изза удаленки, или скиллов человека не хватает?
Попробовать пересадить его в офис, или искать ему замену?
Можно даже задать тот же самый вопрос для офиса — вдруг на удаленке человек будет более эффективен?
Лотерея в том, что одним повезло с удаленщиками и они пишут, что удаленка — это хорошо.
А другим не повезло и для них удаленка — плохо.
А различия — в людях.
Сравнение имеет смысл в пределах одного человека — вот его эффективность в офисе и вот на удаленке.
Например, если человек хорошо работает на удаленке, он организован, мотивирован, и т.д., может быть в офисе он сможет добиваться больших результатов.
И его смело можно повышать до тимлида, давать команду и доверять серьёзные проекты.
А так же повышать оклад, дать отдельный кабинет, готовить ему крем-брюле и прочие плюшки, чтобы он оставался в офисе (крем брюле помог google нанять Луиса Андре Баррозо).
Хотя возможен и обратный эффект — в офисе эффективность человека может снизиться.
Но тогда руководитель будет четко понимать, какие плюсы и минусы при удаленной работе конкретного сотрудника.
А без такого сравнения получаем неопределенность и лотерею.
Если человек работает на удаленке и не справляется, остается только гадать — это изза удаленки, или скиллов человека не хватает?
Попробовать пересадить его в офис, или искать ему замену?
Можно даже задать тот же самый вопрос для офиса — вдруг на удаленке человек будет более эффективен?
Лотерея в том, что одним повезло с удаленщиками и они пишут, что удаленка — это хорошо.
А другим не повезло и для них удаленка — плохо.
А различия — в людях.
Будущее за теми кто умеет планировать свое время.
НЛО прилетело и опубликовало эту надпись здесь
> Можно целый день переписываться по какой-то одной проблеме, когда на рабочей встрече с участием всех заинтересованных людей все вопросы решаются менее чем за час
К сожалению, я лично чаще видел обратное — постоянные сборы _всей_ команды, потеря рабочего времени и т.д. для обсуждения вопросов, 95% которых можно решить за 10 минут в чате или групповой рассылкой только необходимым людям.
К сожалению, я лично чаще видел обратное — постоянные сборы _всей_ команды, потеря рабочего времени и т.д. для обсуждения вопросов, 95% которых можно решить за 10 минут в чате или групповой рассылкой только необходимым людям.
То есть созвониться по скайпу некомфортно, а собрать кучу человек в одном кабинете комфортно?
Как-то не вполне вписывается в мои представления о комфорте.
Как-то не вполне вписывается в мои представления о комфорте.
НЛО прилетело и опубликовало эту надпись здесь
1) А болтать через стол каждые 15 минут комфортно? Мне нет, от работы отвлекает жутко. Кстати очень рад, что больше не приходится.
2) Так я не понял, почему «встречу с участием всех заинтересованных людей» нельзя заменить на «звонок с участием всех заинтересованных людей».
2) Так я не понял, почему «встречу с участием всех заинтересованных людей» нельзя заменить на «звонок с участием всех заинтересованных людей».
НЛО прилетело и опубликовало эту надпись здесь
> 2) Потому что при звонке не получится обсудить всё так же эффективно. Не откроете код, чтобы тыкнуть туда пальцем, не нарисуете схему, иллюстрирующую мысль.
Почему? В том же скайпе можно расшарить экран. А еще есть штуки вроде teamviewer.
Почему? В том же скайпе можно расшарить экран. А еще есть штуки вроде teamviewer.
1) если обсуждение вялотекущее, есть групповой чат; если срочное/важное — звонок
2) ну так наш проект примерно для этого :)
2) ну так наш проект примерно для этого :)
Подстригите когти мопсу (если на фото ваш), они уже начали закручиваться и скоро будут травмировать лапу…
Однако как часто такая вовлечённость действительно требуется? Мозговой штурм? Пожалуй, но это ситуация принятия ключевых решений;Справедливости ради, при мозговом штурме не принимаются решения. При мозговом штурме генерируются идеи.
Спасибо за статью. В целом согласно кивну на все «возражения», кроме «возражения 1»:
В общем, что я хочу этим сказать) Если, помимо «софт»-части работа включает ещё и «хард» — удалённо уже не получится.
Хотя, это, скорее, частный случай…
Долгий нудный текст
в своё время пришлось работать в местном вентиляционном заводе. И хоть я и был программистом (язык FBD), но отлаживать программу нужно было именно вместе с ШСАУ. Конечно, можно было бы организовать и удалённый доступ, но всё равно нужно было подключить испытательный стенд, эмулирующий все датчики и концевики.
А так как отладка программы всё-таки занимает большую часть времени, то удалённо уже поработать не получится — потому, что вместе с отладкой программы проверяется ещё и правильность электромонтажа, и исправлять всё, в случае чего.
А так как отладка программы всё-таки занимает большую часть времени, то удалённо уже поработать не получится — потому, что вместе с отладкой программы проверяется ещё и правильность электромонтажа, и исправлять всё, в случае чего.
В общем, что я хочу этим сказать) Если, помимо «софт»-части работа включает ещё и «хард» — удалённо уже не получится.
Хотя, это, скорее, частный случай…
Первый пост я пропустил и прочёл только сейчас…
Ещё один минус — дома есть жена и дети. Они должны привыкнуть и понять, что Вы на работе??! Да, конечно. «Удалённая работа требует специфического навыка и умения планировать время, но разве работать в офисе с 9 до 7 вы умеете от рождения?» Несомненно. Но! только от меня. А удалённая работа требует специфических навыков ещё и от жены/мужа и от детей(!!!).
Ещё один минус — дома есть жена и дети. Они должны привыкнуть и понять, что Вы на работе??! Да, конечно. «Удалённая работа требует специфического навыка и умения планировать время, но разве работать в офисе с 9 до 7 вы умеете от рождения?» Несомненно. Но! только от меня. А удалённая работа требует специфических навыков ещё и от жены/мужа и от детей(!!!).
Я долгое время придерживался той же точки зрения, что и автор статьи, но наблюдая за жизнью пришло разочарование.
Во-первых, я до сих пор просматривая биржи фриланса не найти действительно интересных задач. Не хочу никого обидеть, но мне как бекенд-разработчику просто в западло заниматься правкой тем CMS, делать что-либо под WordPress и вообще возиться с говносайтами. Интересно заниматься большим проектом долгое время, делать различные интеграции, реализовать сложную бизнес-логику и т.д. Таких задач на удалённой работе практически не встречается. Даже на Odesk. Иными словами, в веб-сфере интересных задач на удалёнке крайне мало.
Во-вторых, даже если найдешь интересный проект и с тобой подпишут контракт, всё равно ты будешь человеком вне системы. Это значит, что ты всегда будешь менее осведомлён о состоянии дел в компании, чем штатный сотрудник. Ты всегда будешь последним вариантом из списка на повышение. И что в итоге? Ну вот поработал так 5, 10, 20 лет. Чему научился кроме кодинга или куда продвинулся? Конечно, не все могут стать хорошими менеджерами. Но некоторым тоже хочется попробовать свои силы в управлении. Да и менеджерский состав больше исполнителей зарабатывает. Удалённое управление? Это смешно. Итого: отсутствие карьерного роста, не самый высокий уровень дохода до самой пенсии.
Во-первых, я до сих пор просматривая биржи фриланса не найти действительно интересных задач. Не хочу никого обидеть, но мне как бекенд-разработчику просто в западло заниматься правкой тем CMS, делать что-либо под WordPress и вообще возиться с говносайтами. Интересно заниматься большим проектом долгое время, делать различные интеграции, реализовать сложную бизнес-логику и т.д. Таких задач на удалённой работе практически не встречается. Даже на Odesk. Иными словами, в веб-сфере интересных задач на удалёнке крайне мало.
Во-вторых, даже если найдешь интересный проект и с тобой подпишут контракт, всё равно ты будешь человеком вне системы. Это значит, что ты всегда будешь менее осведомлён о состоянии дел в компании, чем штатный сотрудник. Ты всегда будешь последним вариантом из списка на повышение. И что в итоге? Ну вот поработал так 5, 10, 20 лет. Чему научился кроме кодинга или куда продвинулся? Конечно, не все могут стать хорошими менеджерами. Но некоторым тоже хочется попробовать свои силы в управлении. Да и менеджерский состав больше исполнителей зарабатывает. Удалённое управление? Это смешно. Итого: отсутствие карьерного роста, не самый высокий уровень дохода до самой пенсии.
Не буду много писать, просто скажу свой факт.
Работаю более 5 лет удаленно.
Когда работал в офисе, реально рабочего процесса выходило на 3-4ч., остальное время куда то утекало.
Работая дома, у меня сейчас выходит 5-6 часов продуктивного программирования, 2-3 часа на размышления/поиск материалов/чтение технической и т.д.
Т.е. в общем я работаю часов 8-9 ежедневно. Плюс еще 3-4 часа если есть настроение.
Итог: работа дома приносит следующие плюсы как мне так и работодателю
1) Финансовый вопрос — в итоге я выигрываю в деньгах, нежели кататься каждый день в офис и там кушать и т.д. Процентов 20 я выигрываю находясь дома. С другой стороны, выигрывает и работодатель, не тратя на меня лишних средств.
2) Общее время работы и ее выполнения увеличивается в 2-3 раза. Работодатель доволен, и мне хорошо.
3) Все свои личные дела я могу решать в любое время, работу всегда можно делать ночью (что я собственно и делаю). Опять же, не надо бегать из офиса и терять драгоценное время
4) Дома я имею большой ком. стол с кожаным креслом, несколько мониторов по 27 и мощный компьютер. В офисе такого предложить вероятно не смогут. Так же у меня на столе стоит термоспот и кофемашина. Все эти вещи, улучшают общую производительность на ~10%;
Можно еще много чего описать, но пожалуй остановлюсь, а то и так «немного написал».
Сейчас же, я работаю сам на себя, имею небольшую команду разработчиков, имею инвесторов.
У нас с ребятами ежедневные видео-конференции, и проблем в работе и общении не возникает. К тому же ребята из разных стран а не только Россия и СНГ.
P.S.
Сейчас я могу спокойно найти работу в офис на 130-150т.р.
Удаленную на 100-120 т.р.
Если скажем из 150 вычитать обеды, транспорт/бензин, пабы после работы, то остается 80т.р. и усталость от поездок.
Сидя дома, остается 100т.р. если вычитать еду и содержание )
Работаю более 5 лет удаленно.
но разве работать в офисе с 9 до 7
Когда работал в офисе, реально рабочего процесса выходило на 3-4ч., остальное время куда то утекало.
Работая дома, у меня сейчас выходит 5-6 часов продуктивного программирования, 2-3 часа на размышления/поиск материалов/чтение технической и т.д.
Т.е. в общем я работаю часов 8-9 ежедневно. Плюс еще 3-4 часа если есть настроение.
Итог: работа дома приносит следующие плюсы как мне так и работодателю
1) Финансовый вопрос — в итоге я выигрываю в деньгах, нежели кататься каждый день в офис и там кушать и т.д. Процентов 20 я выигрываю находясь дома. С другой стороны, выигрывает и работодатель, не тратя на меня лишних средств.
2) Общее время работы и ее выполнения увеличивается в 2-3 раза. Работодатель доволен, и мне хорошо.
3) Все свои личные дела я могу решать в любое время, работу всегда можно делать ночью (что я собственно и делаю). Опять же, не надо бегать из офиса и терять драгоценное время
4) Дома я имею большой ком. стол с кожаным креслом, несколько мониторов по 27 и мощный компьютер. В офисе такого предложить вероятно не смогут. Так же у меня на столе стоит термоспот и кофемашина. Все эти вещи, улучшают общую производительность на ~10%;
Можно еще много чего описать, но пожалуй остановлюсь, а то и так «немного написал».
Сейчас же, я работаю сам на себя, имею небольшую команду разработчиков, имею инвесторов.
У нас с ребятами ежедневные видео-конференции, и проблем в работе и общении не возникает. К тому же ребята из разных стран а не только Россия и СНГ.
P.S.
Сейчас я могу спокойно найти работу в офис на 130-150т.р.
Удаленную на 100-120 т.р.
Если скажем из 150 вычитать обеды, транспорт/бензин, пабы после работы, то остается 80т.р. и усталость от поездок.
Сидя дома, остается 100т.р. если вычитать еду и содержание )
Наткнулся на интересную картинку — хирург после 23 часовой успешной операции по трансплантации сердца. Ассистент спит в дальнем углу.
Расскажите ему про удалённую работу. А также пациенту.
Расскажите ему про удалённую работу. А также пациенту.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему будущее за удалённой работой (часть 2)