ИМХО обсуждение с живыми опытными людьми всегда лучше, чем литература. Например, тем, что "литератор" — всего лишь один из этих людей, и не всегда самый успешный — часто это просто-напросто тот, у кого руки дошли книгу написать.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>ИМХО обсуждение с живыми опытными людьми всегда лучше, чем литература. Например, тем, что "литератор" — всего лишь один из этих людей, и не всегда самый успешный — часто это просто-напросто тот, у кого руки дошли книгу написать.
Я так пониямаю что книжки по программированию тоже не стоит читать?
Мне кажеться можно подчитать пару книженций, пообщаться с опытными людми и родить свое видение рассматриваемой проблеммы.
Kaa>>Сергей Сушко, "Управление удаленной разработкой"
SS>Уже это читал, для меня она оказалась очень ценной. Собственно после ее прочтения я и кинул пост о поиске еще литературы
А все остальное имхо как в обычных софтверных проектах.
Только выше риски что:
1. работник окажется некомпетентен
2. работник забьет на работу и завалит сроки
3. продуктивность работников вообще не стабильна
И
4. выше расходы на коммуникации.
Здравствуйте, savaDAN, Вы писали:
Kaa>>>Сергей Сушко, "Управление удаленной разработкой"
SS>>Уже это читал, для меня она оказалась очень ценной. Собственно после ее прочтения я и кинул пост о поиске еще литературы DAN>А все остальное имхо как в обычных софтверных проектах. DAN>Только выше риски что: DAN>1. работник окажется некомпетентен DAN>2. работник забьет на работу и завалит сроки DAN>3. продуктивность работников вообще не стабильна DAN>И DAN>4. выше расходы на коммуникации.
Кроме того,
5. более высокие требования к чёткости процесса разработки (к РМ).
6. задания должны быть конкретными и структуированными (лучше — ТЗ).
С одной стороны, это новая проблема. С другой стороны, сильно растёт предсказуемость сроков/качества и требуются менее квалифицированные разработчики.
СШ>5. более высокие требования к чёткости процесса разработки (к РМ). СШ>6. задания должны быть конкретными и структуированными (лучше — ТЗ).
я ж и говорю
а все остальное имхо как в обычных софтверных проектах
Здравствуйте, savaDAN, Вы писали:
СШ>>5. более высокие требования к чёткости процесса разработки (к РМ). СШ>>6. задания должны быть конкретными и структуированными (лучше — ТЗ). DAN>я ж и говорю DAN>
DAN>а все остальное имхо как в обычных софтверных проектах
DAN>
В обычных проектах небольших компаний ТЗ редко встречается. Как и чёткая организация работы
СШ>В обычных проектах небольших компаний ТЗ редко встречается. Как и чёткая организация работы
Ну... эдак мы дойдем до того, что в этот пост будем писать необходим трекинг дефектов, система хранения исходных кодов, тестирование и т.п.
Т.е. в конечном итоге тема будет выглядеть следующим образом:
Q: Какие особенности организации удаленной работы?
A: Нужны программисты
Впрочем я прекрасно понимаю о чем вы. это у меня так чувство юмора выпирает. извините если не к месту
savaDAN wrote: > Только выше риски что: > 1. работник окажется некомпетентен
он и в офисе может таким оказаться, на то есть испытательный срок
> 2. работник забьет на работу и завалит сроки
чтобы этого не было, или не было ущерба это надо проверять каждый день
> 3. продуктивность работников вообще не стабильна
вот именно вообще, а не удаленных
> И > 4. выше расходы на коммуникации.
вот с этим согласен, только расходы финансовые они не сильно напрягают,
больше напрягают временные расходы
P.S. У нас сейчас "эксперимент" идет, уже 3 разработчиков удаленных
работают. Четвертая неделя пошла — полет нормальный. В целом молодцы —
сделали не меньше, чем ожидали от офисных работников. Есть конечно еще
"шероховатости", еще народ не притерся, еще не конца друг друга
понимаем, но положительный прогресс налицо.
Я не говорил что подобных проблем не присутствует при офисной разработке.
Я говорил что при разработке удаленной больше вероятность что случатся нижеперечисленные неприятности.
Естествено всех этих неприятностей можно избежать, например если принять меры которые вы перечислили.
>> 1. работник окажется некомпетентен V>он и в офисе может таким оказаться, на то есть испытательный срок
— несколько сложней произвести отбор если ты человека ни разу не видел.
— turnover среди удаленных работников как правило выше чем среди офисных.
>> 2. работник забьет на работу и завалит сроки V>чтобы этого не было, или не было ущерба это надо проверять каждый день
— в офисе это проверить проще.
— на офисного работника больше рычагов воздействия (см. про второй приоритет)
>> 3. продуктивность работников вообще не стабильна V>вот именно вообще, а не удаленных
— имелось ввиду что для многих удаленных работников удаленная работа это некий аналог "шабашки", т.е. второй приоритет.
— да и квалификация удаленных работников все таки ниже как правило. (ногами не пинать, тут все зависит от отбора).
V>вот с этим согласен, только расходы финансовые они не сильно напрягают, V>больше напрягают временные расходы
время = деньги. Т.е. если менеджер может управлять допустим 5ю офисными работниками, то удаленно он сможет управлять например 4-мя, следовательно на 20 человек уже нужно на одного менеджера больше.
V>P.S. У нас сейчас "эксперимент" идет, уже 3 разработчиков удаленных V>работают. Четвертая неделя пошла — полет нормальный.
по моему крайне рано делать выводы после 3х недель.
