Russian Qt Forum

Так как достаточно много комментариев в теме http://www.prog.org.ru/topic_24027_15.html (http://www.prog.org.ru/topic_24027_15.html) о том что необходимо работодателю от программиста и наоборот, я предлагаю обсудить это здесь.

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

Программист, считая, что от него требуют скорость работы, чаще всего предлагает быстрое "наколеночное" решение, так называемые "костыли". Можно даже умудриться сдать работодателю такую работу. Когда требования к программе меняются программист разводит руками и говорит, что все нужно переделывать. Таким образом умудряется одну и ту же работу продать работодателю по несколько раз. Бывает получается, что код написан так, что сопроводить его может только автор  :o (это верх совершенства работы "программиста").

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

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

Эти ответы как бы снимают с него всякую ответственность за качество.

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

Моё скромное ИМХО:

1) Работодателю нужен результат. И точка. Его не волнует такая проблема как совместимость, стоимость поддержки и прочая, ибо до него на этом этапе эти слова пустой звон.
2) Программисту нужно чёткое задание от и до. Программисту нужна связь с работодателем и/или его менеджером. Программисту в результате нужна галочка о выполненной работе и бонус в виде денег :)
3) Этот пункт должен описываться в договоре. Либо на словах в каждом конкретном случае :) Универсальных запросов не существует.

Хотя есть основные - такие как то присутствие на связи (т.е. способ связаться при любом исходе событий), аванс и так же процедура оплаты.

4) Чистый более-менее код + комментарии в непонятных местах. Придерживаться одного стиля программирования. В общем стандартные требования + опять таки оговоренные в договоре :)

PS а хороший программист сделает так, чтобы добавление нового функционала в ужас не превращались :D

Интересная тема, но почему в "Говорилке"? Ладно
С этой точки зрения обсуждать особо нечего. Конечно работодателю нужен хороший код как можно быстрее. Конечно программисту надо чтобы платили прилично и вовремя. Вот собственно и все.

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

Беда только в том что готового-то НЕТУ и/или найти его непросто. Освежив в памяти законы Ньютона Вы вероятно обнаружите что здесь они никак не помогут. Открыв физику жидкостей Вы вероятно тоже уйдете ни с чем. Через 4-5 дней гугления Вы начинаете понимать что топчетесь на месте. А время идет..  

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

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

Я так понимаю в данном случае нужно придумать что-то похожее на движение капель, желательно простое. Да, нужно копать. Эта уже научная работа, а не программирование.

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

Вы всегда берете "слишком широко"  :) Нет, движения не требуется, нужно только деформировать капли так чтобы они свисали под действием силы тяжести (ну как красивые сиськи). Наибольшая трудность - учесть что капли могут сливаться друг с другом. Ну и у пользователя есть параметр gravity (мять сиськи больше/меньше). Конечно никакой научной работой здесь не пахнет, рядовой 3D эффект.

"А давай вот так - хм, сиськи интересные".

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

я то полагал тут про потребности заказчиков и разрабов. А тут про сиськи :) Когнитивный десонанс наступает.

Это ж говорилка.

Вон к тому ж вроде в гимпе имелся где то аддон для создания капель. И вполне реалистичный. Коды посмотреть можно :)

Нет ничего плохого в использовании выразительной аналогии. А если уж умничаете, то пишите правильно "диссонанс"  :)

У игровых программ другие цели/задачи, и вряд ли там уместно создавать hi-resolution капли. Там и на character полигонов кот наплакал, абы шустрее бегало. А здесь качество/разрешение нужны довольно высокие (на аттаченной картинке они явно недостаточны). Чего-то там "подмазать текстурой" не выйдет, это не ширпотреб.

По другому вопросу
Судя по этому (и другим) высказываниям Вы вступили на (ой нелегкий) путь нанимающего :) Да, именно так все и происходит. В этом смысле с контрактором легче. Разбиваете оплату на 2 части. Первая (бОльшая) выплачивается за "ходящую" бету. Вторая по истечении периода бета-тестирования (месяц-два). Да, не все удается отловить за это время, но результаты обычно очень положительные, и недоразумений не возникает. А вот если штатный работник "застрял" в пучине багов - намного хужее. Возможно есть смысл переключить его на др задачу.

Давайте сразу уберем из обсуждения специальный софт (управление атомными станциями, крылатыми ракетами и искусственными спутниками). К нему особые требования и особый режим контроля.
Остановимся на коммерческом софте.
Есть заказчик - это тот парень который платит деньги. Ему нужны только сроки. У него появилась идея, ее нужно максимально быстро запустить в дело. С ошибками, недочетами с урезанным функционалом. Главное, что бы быстрей появилось на рынке. Если программа пошла - хорошо, исправляем ошибки, добавляем удобности и няшки. Не пошла - выкидываем/оставляем на потом.
Программисту нужны деньги. Ну и если он не хочет потом долго и мучительно тратить свое время, то и умение хорошо спроектировать проект. Для того, что бы если проект "пошел", то его можно было довести до ума в реальные сроки.
Если это проект не коммерческий, то тут все может быть по-другому.

Конечно нет. :)

На капли не действует сила земного притяжения? Или физика жидкостей это фейк? Или вы просто не умеете готовить эти знания?

У большинства на этом форуме такие же проблемы.

Это зависит от условий. Если вам красивую каплю нарисовать - это одно, а если моделировать ее поведение в заданных условиях, то совсем другое. И математика будет нужна разная и время на вхождение в тему.

Ну это наши тяжелые будни. :)

Задача построить 3D модель капель деформированных под действием силы тяжести. Я (наивно) полагал что это вполне ясно из картинки :)

Нууу, а какой закон описывает силу тяжести?

Смотрю интерес к теме капель пропал? :)

Что бы я смотрел:
1. Те самые законы Ньютона, которые никак здесь не помогут:
Гравитационные силы. Закон всемирного тяготения (http://www.edu.yar.ru/projects/socnav/prep/phis001/dyn/dyn12.html)
Сила тяжести. Вес тела. Невесомость (http://www.edu.yar.ru/projects/socnav/prep/phis001/dyn/dyn13.html)
Силы трения. Коэффициент трения  (http://www.edu.yar.ru/projects/socnav/prep/phis001/dyn/dyn11.html)

2. Физика жидкостей
Жидкость (http://ru.wikipedia.org/wiki/%D0%96%D0%B8%D0%B4%D0%BA%D0%BE%D1%81%D1%82%D1%8C)
Поверхностное натяжение (http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B2%D0%B5%D1%80%D1%85%D0%BD%D0%BE%D1%81%D1%82%D0%BD%D0%BE%D0%B5_%D0%BD%D0%B0%D1%82%D1%8F%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5)
Вязкость (http://mosgruz.net/gidrot1r11part1.html)

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

Это мысли, куда бы я начал смотреть.
В тему не входил, это то, что нашел за 15 минут.

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

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

Ладно, рассмотрим как сделать "просто капли" которые могут сливаться (пока без всякой гравитации). Здесь используется фундаментальный алгоритм "marching cubes". Форма задается ф-цией Surface(х, y, z). Если ф-ция возвращает положительное значение - мы внутри поверхности, иначе снаружи. Отлавливая нули ф-ции мы строим полигоны/модель. Об этом был диссер еще в середине 80-х. Ф-ция может задаваться всяко-разно, для простоты полагаем что множеством точек в пр-ве + радиусами для каждой капли. Псевдокод

C++ (Qt)
float Surface( const Point & pt ) 
{
 float sum = 0.0f;
 for (size_t i = 0; i < points.size(); ++i) {        // цикл по всем каплям
  float distance = (pt - points[i].mCenter).length();  // расстояние от точки до центра капли
  float factor = 1.0f - distance / points[i].mRadius;    // относительный радиус
  if (factor < 0.0f) continue;   // точка снаружи капли 
  sum += factor;                 // накапливаем              
 }
 return sum - viscosity;  
} 
 

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

Без Ньютона? Я пас.

Igors, вам не кажется что вы усложняете себе работу? :)

Вы начинаете со слияния, а закончите созданией капли.

К тому же у вас наверняка есть условия этих "капель".

PS и я к тому же не верю, что каждый кадр с каплями /водой /сосулями /заморозкой капель нарисован вручную. Повторяюсь - видел в гимпе вроде инструмент, который позволяет создать капли. Правда на весь фон, правда сила гравитации ставилась одна для всех, рандом там сам разбрасывался. Но готовая капля 2D была. От 2D до 3D далеко, согласен. Ноо... Но думаю вы не первый кто сделает такой класс и такое отображение. Мб стоит спросить на специализированных форумах?

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

Ой, igors, а Вы там, часом, уж не Матрицу ли пишите?
А то встанешь вот так утром - и вроде всё так, а вроде и нет.. ))
Физики, кстатии, до сих пор с этой гравитацией мучаются, всё никак её проквантовать не могут) Это не Ваших ли рук дело?  ;)

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

По поводу специализированных форумов - там крутой уклон в real-time, fps, для чего хороши любые компромиссы по качеству. Здесь "другой жанр", поэтому я не особо рвусь к игровым исходникам и.т.п. Однако если Вы считаете тот аддон интересным - покажите, обсудим.

Совершенно верно

Та какая там матрица - это скромная опция в скромном продукте, не более того. Вообще идея "создавать модель по формуле" (implicit) выглядит очень привлекательно, но только на первый взгляд. Когда доходит до дела - полезных формул почему-то не оказывается :) А замутить что-то фантастическое можно, но оно никому особо не нужно. Ну и как всегда, обратная сторона красивой идеи - низкая скорость и качество.

Это понятно, моделировать в реальном времени поведение жидкости не простая затея и для этого случая не нужная.
Но от чего то нужно начинать плясать, а упростить потом всегда можно.
:)

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

Кстати, в PhysX заявлена физика жидкостей и взаимодействие жидкостей и твердых тел. Т.е. кто-то уже сел и это сделал.

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

Да я это не про вашу задачу, а про:

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

Приоритеты различны для различных областей и проектов. Если взять какой-нибудь крупномасштабный проект вроде марсохода или БАК, то там главное качество и надёжность, а сроки и бюджет отходят на второй план. Напротив, если взять сферический веб-сайт или стартап в вакууме, то там главное "давай-давай, быстрее-быстрее!" и как можно дешевле, потому что продукт нужен уже вчера, инвесторы недовольны, и конкуренты не дремлют.

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

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

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

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

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

Примеров то достаточно:
http://habrahabr.ru/post/167999/
http://habrahabr.ru/post/167011/
http://www.profkonsultant.ru/poleznoe/1-2009-12-14-11-11-56/286-2012-11-22-08-40-13
http://37signals.com/ - тут люди работают удалённо
http://habrahabr.ru/post/143044/ - немного философии :)

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

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

1) По-моему "русский менталитет" здесь ни при чем, во всяком случае никакой статистикой не подтверждается.  

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

3) Главная беда - переоценка работником своих возможностей. Он абсолютно уверен что сделает работу "на своем высоком классе". Настойчивые просьбы вникнуть как можно глубже - пофиг. "Вот заключим контракт - а потом разберемся. А так чего я буду свое время тратить". Если наниматель увидел/понял такое - ему лучше сразу сказать "нет" (це дiла не буде)

4) Timeline удаленной работы тоже проблема. Очевидно человеку нужно время чтобы въехать, месяц-два его трогать нет смысла. Но рано или поздно выплывает вопрос "ну так что??". Увы, минимум в половине случаев выясняется что работник просто прогулевонил  

5) Первая увиденная альфа/бета повергает в глубокий шок. Нередко это вообще "не по теме", т.е. не имеет к задаче никакого отношения. Какого ж ты брался если не можешь и/или не хочешь? Начинается разное виляние. "Да исправим" - но через месяц то же самое. В конце концов сваливается в "да, работа сделана не полностью, но 50-99% готовы и вы должны оплатить". (вилка 50-99 обратно пропорциональна совести работника). Начинаются разборки. Конечно ничего работник не получает, но время нанимателя сожрет сполна.                          

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

7) Продолжение предыдущего. Все успехи были только для "локальных" задач,  т.е. не зависящих от приложения (эту связку делали сами). А все задачи связанные с приложением (где требовалось писать в его контексте, с его классами) были провалены 100%

8 ) Написание ТЗ, переговоры с контрактником - да, это неизбежно, но это съедает массу времени.

Ну а так, в общем, конечно "благо"  :)

Давайте определимся, о ком мы говорим, о фрилансерах или о штатных сотрудниках, которые работают удалённо?
Этот самый "русский менталитет" как раз таки причём, причем мешает он и с той и с другой стороны.

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

А для штатных вы ТЗ не пишете что-ли? Начиркал на бумажке "вот как-то так, тут всё понятно, не боги горшки обжигают, сделаешь это к понедельнику"? :)

Я лично пару своих фриланс проектов делал проще - получаю аванс, разбиваю задачу на части, примерно разбиваю на равные части времени срока. 20% оставляю на "форс-мажор". И в трекере примерно каждые 2-4 дня отписывал результаты и % выполненных работ по частям. Заказчик доволен как слон - видит что идёт работа. При добавлении новых требований, срок раздвигается и вставляются соответственно части.

PS после второго изменения требований, заказчик сказал - "*ера себе сроки сдвинулись, давай лучше сначала сделаем как сначала хотели, а это добавим потом " :)

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

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

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

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

Я предлагаю обсуждать действительно удаленную работу, когда заказчик и исполнитель находятся в разных городах, а то и странах, и личный контакт между ними невозможен. А полемика "как лучше организовать работу штатного/офисного работника" мне лично неинтересна.

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

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

Ну а почему нет - по крайней мере в некоторых случаях? :) А вот для удаленного работника нужно выверить каждое слово и каждую формулировку - и это обычно занимает не день и не два. Он имеет полное право ответить "в ТЗ этого нет", и тогда мне придется просить его и/или еще платить.

Igors - контроль как раз осуществлялся в моём случае отдельными частями. загрузка в базу и анализ порядка 20 млн записей + построение графика =
1) загрузка в базу 20 млн записей.
2) анализ записей.
3) построение графа.
4) соединение частей.

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

Верю :). Я говорю что просто так лицезреть написанный код на трекере не имеет особого смысла. Проверять можно/нужно что-то хоть как-то "ходящее"

А вот это, как раз, очень хорошо характеризует разработчика. :)

Еще немного диссонирую.  8)

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

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

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

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

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

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

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

Хранение идёт в репозиториях. Там же разграничиваются права.

Система отлажена чуть больше, чем полностью :)

Проблема только в другом, вы смотрите на "дать кусок проекта" и пусть делает.

А необходимо "дать ТЗ на составную часть", которую ВАШИ программисты смогут без особых усилий впихнуть в ваш проект :)

Работа над проектом вместе - это одно. Работа оутсорсером над отдельной частью - другое :)

Как бы вы не хотели сказать "сделай программу чтобы чики-пуки", ТЗ необходимо будет всегда :) Или чики-пуки будут неправильными.

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

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

Ну штат не штат, но это действительно больное место. Да, приходится "снимать части с фронта" и перебрасывать их на "обслуживание". Идешь на работу, ну думаешь подтяну это, закончу наконец то.... да куда там  :'( Опять пол-дня просидел отписываясь, в чате или скайпе. Эти расходы минимум соразмеримы с трудом самого контрактника. Именно это резко охлаждает энтузиазм к удаленке. Вот напр та задачка с деформацией капли. Если б человек дал аналитику - с удовольствием бы проплатил. Но если маячит "ТЗ" - выйдет совсем нерентабельно, лучше самому.

1) Подписывается NDA
2) Компилируется ну очень большая статик либа, вместе с ней даются только нужные исходники

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


Очень верное замечание ВАШИ. Так где взять НАШИХ, если все хотят работать удаленно. ;D


1) Как минимум нужна хотябы одна очная встреча для знакомства и подписания NDA.
2) Опять же на стороне работодателя должен быть спец.  :-\, который обеспечит сборки таких SDK для каждого удаленного работника.

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

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

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

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

2kambala Радий за Вас, але краще бути обережним. Не шукайте зустрiчi з податковими дiвчатами  :)

я и не шукаю: налоги исправно платятся с зарплаты аспиранта :)