Удаленная работа программиста

[simply2double]

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

P.S. Мысль возникла, после сорока минутного простоя в пробке...

[gudzon]

Привет !
А реальна ли вообще удаленная работа программиста (любого)?
Опыт есть у кого-нибудь?

любого - был. Много времени уходит на "стыковку" желаемого и действительного. Проекты идут намного медленнее. Можно вести несколько для эффективного использования времени.

[simply2double]

Цитата:

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

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

Тут уж не до удаленного программирования... программист нужен всегда под рукой... в отверткой... для подкручивания...

точно

[Bobkov]

Работа удаленная от кого?
1. От пользователей? Это запросто, еще и шума меньше, толку больше.
2. От всех остальных участников проекта? Это сильно затормозит процесс разработки из-за трудности понимания того "что же все-таки должно получиться". К сожалению, процесс этот получается итерационный, с обратной связью, следовательно - нужны коммуникации.
Мне кажется, должен неплохо помочь терминальный доступ (чтобы консультант и программист могли видеть один и тот же экран компьютера) + телефон (чтобы оперативно общались) + задание в письменном виде (чтобы была четкая постановка задачи).

[simply2double]

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

так все таки... что есть программист... в россии ??? )))

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

[Garic]

Цитата:

Изначально опубликовано gudzon
А реальна ли вообще удаленная работа программиста (любого)?

Реальна если программист участвует в постановке задачи (или постановку делает он сам). Он должен разбираться в предметной области.
Иначе, если он до конца не представляет что должно получиться, это действительно будет потеря времени.


P.S. Сижу дома, с сигаретой в руке и попиваю чаёк

[simply2double]

Цитата:

Изначально опубликовано Bobkov
Работа удаленная от кого?
1. От пользователей? Это запросто, еще и шума меньше, толку больше.
2. От всех остальных участников проекта? Это сильно затормозит процесс разработки из-за трудности понимания того "что же все-таки должно получиться". К сожалению, процесс этот получается итерационный, с обратной связью, следовательно - нужны коммуникации.
Мне кажется, должен неплохо помочь терминальный доступ (чтобы консультант и программист могли видеть один и тот же экран компьютера) + телефон (чтобы оперативно общались) + задание в письменном виде (чтобы была четкая постановка задачи).

Ответы:
1. по большому счету... программист и не должен общатся с юзерами... это удел консультантов, аналтитиков и остальной прокладки...
2. программист и не должен морочится... вопросом "что из всего этого получится"... это удел архитекторов... я так понимаю задача программиста... ЗАПРОГРАММИРОВАТЬ АЛГОРИТМ... реализовать чьи-то мысли... уровни абстракции при этом конечно зависят от удаленности реализатора от простого кодировщика...
хе-хе... любой процесс является итерационным... и если под итерацией понимается "ну ка подправь вот тут чуток, посмотрим что получится..." то тут ни какие комуникации не помогут )))

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

вот мы и опять уперлись в "задание в письменном виде (чтобы была четкая постановка задачи)"....

[simply2double]

Цитата:

Изначально опубликовано Garic


Реальна если программист участвует в постановке задачи (или постановку делает он сам).

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

[simply2double]

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

[Rungart]

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

2Rungart
более чем классический пример, спасибо

[Garic]

Цитата:

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

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

Я не говорил что программер ДОЛЖЕН разбираться в предметной области. Я имел в иду что если он разбирается, то ему не обязательно сидеть в офисе рядом с консультантом. Подкорректировать задачу он может и сам сидя дома.

Цитата:

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

А что поделаешь если людей не хватает

так что , программисты - это супер! (извини, Mazzy)

[simply2double]

Цитата:

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

интересно... а в этой организации... вообще были люди с экономическим образованием ???))) и если были... какой вес они имели... и нужна ли вообще была этой организации "системка, которую начальство прикупило" ....

[simply2double]

B]

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

[/B]

Нафига аналитику знать... как система живет... изнутри... его удел квадратики рисовать...

Понимание задачи у реализатора должно появлятся после прочтения техзадания... хотя как правило... этот документ более походит на тезисы типа: "Когда все сделаем... будет клево.."



А что поделаешь если людей не хватает

Насколько я понимаю... здесь речь идет.. не о написании программы в общем... а о автоматизации предприятия... а это дело командное... ))) разделение труда великая вещь... доказано Марксом...

Цитата:

доказано Марксом...

теоретически
на практике теория Маркса не сработала <нигде>

[Garic]

Цитата:

Изначально опубликовано simply2double
Нафига аналитику знать... как система живет... изнутри... его удел квадратики рисовать...

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

Цитата:

Изначально опубликовано simply2double
Понимание задачи у реализатора должно появлятся после прочтения техзадания... хотя как правило... этот документ более походит на тезисы типа: "Когда все сделаем... будет клево.."...

именно

Цитата:

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

Я ещё ни разу не видел ТЗ, которое после прочтения не приходилось дорабатывать. Всегда остаются моменты, которые аналитик не учёл. (Имеется в виду не задание на отчёт или добавление кнопочек).

Цитата:

Изначально опубликовано simply2double
Насколько я понимаю... здесь речь идет.. не о написании программы в общем... а о автоматизации предприятия... а это дело командное... ))) разделение труда великая вещь... доказано Марксом...

На этапах разработка -> опытная эксплуатация -> промышленная эксплуатация частенько забирают аналитиков. Хотя система ещё переделывается (сильно). Вот и приходится быть "три в одном".