Здравствуйте, Dirichlet, Вы писали:
D>Как Вы считаете, какое минимально допустимое время разработчик ПО должен уделять непосредственно работе?
Я попробую рассмотреть данный вопрос с точки зрения типов индивидуумов и подходов к разработке каждым типом. Мерить всех под одну гребёнку проблематично, поскольку каждый разработчик имеет свой способ решения поставленной задачи, затрачивающий больше или меньше тех типов "рабочего времени", которые вы выделили. Ниже приведены несколько типов разработчиков (не все, конечно ), для которых соотношение времени "эффективной работы" и "времени безделья" разное.
ИМХО
1-ый тип: "искатели".
К искателям отнесём тех, кто, получив задачу, пытается найти оптимальное решение. Это оптимальное решение ищется везде — в форумах, в документации, в изучении технологий, в разговоре с коллегами и т.п. Наибольшее время искатель затрачивает на сбор информации, поиск решения отдельных кусков задачи, приспосабливание готовых решений (подгонка) и т.п. У искателя в голове постоянно в фоновом режиме проигрывается задача и различные варианты решения, складываются и разбегаются куски задачи, возникают фрагменты решений... В результате накопления "критической массы" понимания задачи у искателя в какой-то момент складывается чёткое понимание того, как, с его точки зрения, задача должна быть оптимально решена. После этого искатель садится и одним рывком прописывает решение.
Для искателей характерны постоянные отвлечения на непрофильные форумы, кратковременные отдыхи, трёп c коллегами ("прокачивание" своих идей через коллег).
Наиболее эффективен на задачах с нечётко поставленными условиями, а также на задачах, связанных с выбором технологии решения. Очень эффективен на "этюдных" задачах, даже более эффективен, нежели "снайпер". Требует контроля с точки зрения сроков на ранних стадиях решения задачи. Требует спарринг партнёра, который говорил бы искателю, что тот движется в правильном или неправильном направлении. Иногда охладевает к непосредственному решению задачи, когда полностью понимает, как она должна быть решена. В этом случае проблема решается подключением "бульдозера".
2-ой тип: "снайперы".
К снайперам относятся разработчики, которые мгновенно (ну или очень быстро) могут решить конкретно поставленную задачу. Снайперы, как правило, имеют достаточно богатый технологический опыт и хорошо теоретически подготовлены. Они решают задачу сходу, не задумываясь об архитектуре решения, технологиях и т.п., поскольку решение у них формируется в голове на стадии чтения требований. Снайперов отличает очень высокая эффективность рабочего времени, но они не могут постоянно работать в своём диком темпе. Они могут часами просиживать в форумах, читать документацию, тестировать новые технологии, прописывать сервисные библиотеки и т.п. Снайпер "стреляет" один или несколько раз в день, но практически всегда решает поставленную задачу качественно и в срок. Не очень хорошо работает в паре (в команде).
Наиболее эффективен на задачах, требующих неординарных решений, в "пилотных" проектах и для прописывания сложных, но небольших, участков различных проектов. Хорошо контролируем с точки зрения сроков исполнения задачи, поскольку решает в основном задачи сложные, но короткие и всегда знает, сколько нужно времени.
3-й тип: "строители".
К строителям относятся разработчики, которые проектируют решения в процессе его создания. Для них очень важно постоянно "итерировать" — делать кусок задачи, тестировать его, получать промежуточный результат, оценивать, частично его переделывать, приращивать к этому куску новые части решений и т.п. Строитель большую часть времени занят "непосредственно работой", но эффективность данной работы достаточно низка, поскольку постоянно идёт рефакторинг.
Для строителей характерна постоянная занятость "непосредственно работой" с малыми отвлечениями на внешние раздражители. Хорошо работает в команде — готов в любой момент сделать рефакторинг для обеспечения встраивания своего кода в чужой и наоборот. Хорошо подстраивается под общую задачу.
Наиболее эффективен на задачах, требующих освоение новых технологий, задачах, требующих широких знаний в разных областях. Хорошо решает нудные прикладные задачи за счёт снятие "занудности" постоянным получением промежуточных результатов. Хорошо работает на техподдержке (добавление небольших функциональных кусков, устранение ошибок). Не очень хорошо контролируем с точки зрения сроков (требуется бдительно внимание).
4-ый тип: "бульдозеры".
К бульдозерам относятся разработчики, которые методично и размеренно решают задачу. Бульдозеры могут решить любую задачу. Скажи им написать СУБД — они её напишут. Причём неважно, что у них на машине уже стоит другая СУБД — они не будут на неё смотреть — сказали написать, значит напишу!
Бульдозеры мало отвлекаются на внешний мир, однако у них есть несколько особенностей, снижающих эффективность работы. Первая — решение всех задач подряд. Если бульдозера вдруг не устраивает какой-то визуальный компонент (ну не нравится!) он напишет новый. Если не нравится, как реализован протокол — он напишет свою реализацию. Причём, как правило, бульдозер частенько отвлекается и его компонент или протокол может значительно больше, нежели этого требует задача.
Бульдозер медленно разгоняется, зато, когда распишется — его не остановить.
Соотношение "отвлечение" — "работа" примерно 20/80, однако эффективность не очень высока из-за "профильных" отвлечений.
Наиболее эффективен на длинных и сложных задачах, которые нужно прописывать по нескольку недель. С точки зрения сроков мало управляем, однако в большинстве случаев может быть учтён за счёт анализа предыдущих задач, поскольку эффективность очень стабильная.
Есть ещё несколько типов, но уже рука устала кнопки жать. В общем — мысль — каждому для эффективного результата требуется своё соотношение времени работы/отдыха.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Для этого нужно провести нормирование. Работу программиста можно разбить на ряд операций. КЛ>Готов посморить, что многие из этих операций будут стандартны. Их и надо пронормировать.
Простите Вы программист или конвеерный рабочий??? Или для Вас программирование эвивалентно кодерству??? Так вот — 80% разработки ПО не конвеерные работы, и там где Вы в прошлый раз затратили 20 минут счас может затратить 2-3 дня.
А да забыл сказать у меня в отделе 4 программист ушел, именно за то, что его пытались пронормировать, а точнее пару раз ткнули носом в о что он 2 часа из 9 часов проведенных на работе посвятил чтению форумов. А счас спроси себя, что для бизнеса лучше 1 кодер-стажер работающий 8 часов в день или профи-универсал, который работает всего 5 часов??? Так и быть можешь поставить 2 стажеров по 8 вместо 1 универсала по 5
Здравствуйте, aa_v, Вы писали:
_>Простите Вы программист или конвеерный рабочий???
Я — квалифицированный программист. Но моя квалификация как раз таки и не позволяет мне халявить, т.е. воровать время у работодателя. Проработав в IT-индустрии около 10 лет, могу поделиться наблюдением. Деградация (как профессиональная, так и личностная) начинается с мелочей. Сначала человек начинает посещать форумы, не относящиеся по тематике к его работе, и проводить на них какое-то время. Затем начинает качать видео, и, наконец, порнуху. (Нет, не подумайте, что я против порнухи. Но не в рабочее же время!) В конце-концов получается так, что человек работает от силы 2-3 часа в день, а все остальное время занято развлечениями. При этом он оправдывает себя тем, что он же профессионал и быстро справляется с заданиями.
_>Или для Вас программирование эвивалентно кодерству??? Так вот — 80% разработки ПО не конвеерные работы, и там где Вы в прошлый раз затратили 20 минут счас может затратить 2-3 дня.
Творческую работу тоже можно автоматизировать и пронормировать. О том, как это сделать, смотрите в статье: http://www.triz-ri.ru/themes/method/creative/creative50.asp
_>А да забыл сказать у меня в отделе 4 программист ушел, именно за то, что его пытались пронормировать, а точнее пару раз ткнули носом в о что он 2 часа из 9 часов проведенных на работе посвятил чтению форумов. А счас спроси себя, что для бизнеса лучше 1 кодер-стажер работающий 8 часов в день или профи-универсал, который работает всего 5 часов???
Я не верю в байки о том, что профессионал ушел с работы за то, что его упрекнули чтением форумов. Зато я верю в то, что там либо плохо платили, либо придирки носили систематический характер, либо работа была неинтересной, либо к нему придрались, не установив правил игры (стандартов на выполнение работы).
Если на работе хорошо платят (существенно выше, чем в остальных конторах) и требуют качества в выполнении работы систематически, а не от случая к случаю (т.е. не меняют правил игры), то из такой конторы профессионал не уйдет.
Здравствуйте, Dirichlet, Вы писали:
D>Так а сколько шеф имеет право требовать? Понятно, что чем быстрее разработчик сделает свое задание, тем счастливее будет шеф. Как шефу узнать, что на этого разработчика можно увеличить нагрузку?
Для этого нужно провести нормирование. Работу программиста можно разбить на ряд операций. Готов посморить, что многие из этих операций будут стандартны. Их и надо пронормировать.
Здравствуйте, Igor Trofimov, Вы писали:
L>>Если же надо крепко подумать, понапрягать мозг, то расклад примерно такой: L>>3. Рабочее время: 4-5 часов в день это максимум. И дело даже не в том, старается человек или нет. Многие проблемы просто требуют длительного обдумывания и устаканивания видения.
iT>Нет, позвольте! Никто ведь не говорит о кодировании в течении 8 часов! iT>Устал кодировать — пойди, попроектируй. Устал — пообщайся с коллегой, как лучше сделать что-то в вашем текущем проекте. Надоело — иди к шефу, решай проблемы, мешающие работать. Нет шефа — исправь старые баги. Нет багов — сходи в туалет и садись, покодируй
А давай посчитаем. Пришел на работу — взялся за проект системы, пока вспомнил модель, включился в процесс 20-30 минут прошло. Устал проектировать, решил переключится на кодирования — опять нужно посмотреть код, вспомнить название классов и т.д. Количество переключений * на время перелючения. В твоем примере еще меньше времени на работу остается.
iT>Но не так: пописал чуть-чуть, новости, анекдоты, форум, обед, новые новости, новые анекдоты, еще чуть-чуть пописал и домой.
Естественно соотношение полезного времени и к длительности рабочего дня должно быть адекватным. Но скорее всего оно не будет превышать пресловутых 50%. Силу массы объективных и субъективных причин.
L>>2. Обучение: 10-20%, не меньше. Иначе наступает деградация. Во-первых, мозг на рутинные операции настраивается.
iT>Образование — это твое личное дело. Без спорта тоже нельзя — давайте 10-20% времени тратить на работе на спорт. А еще без сна нельзя — давайте поспим в рабочее время.
Правильно! Мое дело вообще только зарплату получать. Конкурентноспособность компании и ее развитие мне вообще побоку.
Если компания не будет заботится о развитии сотрудников, то все время будет делать черную работу по кодированию сайтов под заказ. До самого последнего ее дня, когда безусловно более дешевые индийцы и китайцы вытеснят ее с рынка. Только вот я в такой компании вряд ли буду работать.
FYI, многие компании на западе и ,как ни странно, у нас поощеряют обучение работников (вплоть до явного выделения рабочего времени на эти нужды).
Здравствуйте, Chipsеt, Вы писали:
C>Вы не читали Джоэля случаем? Он говорит что счастлив поработать 2-3 часа в день, потому-что иногда бывает так что вообще ничего не получаеться сделать.
Он говорит, что счастлив эффективно поработать 2-3 часа в день. Чтобы достичь такого результата, большинству из нас потребуется работать существенно больше.
Чтобы работать эффективно, нас ничто не должно отвлекать. А нас отвлекают телефонные звонки, вопросы коллег, приходящие сообщение по ICQ, и т.д. Мы можем за весь день вообще не войти в "поток", в котором работаем эффективно.
Да и Джоель в конце статьи говорит, что надо работать:
Мы должны просто приходить каждое утро и, как-нибудь, запускать редактор.
Вообщем, эта статья не может служить оправданием людям, занимающимся нерабочими делами по 5-6 часов в день.
Здравствуйте, Igor Trofimov, Вы писали:
iT>А мое личное правило — работать столько, сколько указано в договоре.
в договоре обычно указывается время присутствия, а вот что делать в это время — определяется "текущей обстановкой"
скажем, для большой конторы характерна избыточность персонала и впридачу куча формальных процедур, никак напрямую с тем, что обычно программист понимает под работой в смысле третьего пункта, не связанных. бывают авралы (редко), тогда все работают много. все остальное время приходится просто поддерживать себя в тонусе. некоторым счастливчикам в таких конторах удается пристроится так, что нагрузка на них выравнивается, а задачи идут интересные — но они исключение из правила.
для маленькой конторы, напротив, каждый специалист на счету, а планирование делается не по фактическим имеющимся ресурсам, а так, чтобы взять заказ. в таких случаях, когда очевидно, что присутствие небольшого стресса вида "deadline уже близко" неизбежно, выгоднее позволить людям выполнять свою задачу в то время дня, когда они это могут сделать наиболее качественно. если им перед этим надо выспаться — пусть спят, если надо почитать форум — пусть читают. обычно у маленьких контор и так немного возможностей заинтересовать материально, поэтому чем строить, лучше дать свободы в меру. разбираться надо, только если они перестают давать результат.
Здравствуйте, Andy77, Вы писали:
A>Ага, "разработка архитектуры для приложениния типа клиент-сервер — 10 часов", так?
Вы утрируете, и зря. Для того чтобы разработать архитектуру "типа клиент-сервер" разработчику нужно:
— собрать требования клиента;
— описать эти требования в виде чернового документа, отослать клиенту и дождаться фидбэка;
— на основе ответа составить техническое задание (чистовой вариант);
— ознакомиться с паттернами проектирования для подобных архитектур;
— построить и описать черновой вариант модели системы;
— и т.д.
Здравствуйте, Chipsеt, Вы писали:
C>Программирование больше схоже на науку. Одна правильная мысль может заменить недели работы...
А я вот думаю, что программирование давно не похоже на науку — это должне быть чёткий и отлаженный производственный процесс в большинстве случаев (я, конечно, не беру в расчёт тех, кто занимается исключительно "наукой программирования"). Большинство задач решаются типовым набором способов, причём набор способов конечен. На тюнинг каждого способа решения для конкретной задачи должно тратиться не очень болшое время (по оч грубым оценкам — до 20%).
потому наверное у вас в Транзасе и такая текучка кадров ... особенно программерских
по поводу порнухи
не могу понять ... почему широкая общественность за образец непристойного интернет-поведения считает именно скачивание порнухи ? я во всем нете и порнухи нормальной-то не видел, хоть и не искал, да и не понимаю с какой целью ее нужно искать — как правило товарищи, занимающиеся бесполезным времяпровождением, к порнухе как раз равнодушны
порнуха — это детский и быстропроходимый (если с мозгом все в порядке) этап развития интересов интернетчика, самый злостный я считаю это общение , форумы, ЖЖ — даже это мелкое сообщение отняло минут 15 рабочего времени, а сколько мы их здесь с вами пишем ?
Что же до пресловутой порнухи.... зачастую посещение страницы содержащей оную вовсе не значит злой умысел сотрудника. Например, только сегодня, разыскивая в сети крек для одной проги, несколько раз по сцылке вывалился на страницу с флеш-мультиками "хочешь взять эту девочку ?". А мне крек нужен был, а не картинка с девочкой
Насчет профессиональных форумов ... общественное мнение тоже не всегда право. Иногда они чуть ли не единственное средство срочно решить в срок образовавшуюся производственную проблему. Так же как и поиск в инете.
Здравствуйте, Dirichlet, Вы писали:
VAB>>вообще говоря скорость вещь такая... подозрительная VAB>>возможно в ущерб было качество положено, так что тут нужен глаз да глаз D>Я не имею в виду случаи, когда от разработчиков пытаются добиться всего, на что они способны. Я имею в виду обычный рабочий процесс. Если человека, работающего 1 час в день, попросить работать 1,5 часа в день, то качество не пострадает. Например, у меня качество начинает снижаться только где-то на 6-ом часу работы.
я про то что если Вы запланировали человеку неделю на что-то, хорошо знаете что оно занимает минимум 3-4 дня даже у Вас (предполагаем квалификацию шефа "не хуже" априори + неделя простая страховка по срокам), а он приносит через полдня с гордым видом мол "шеф усе готово" — скорее всего задание было либо понято неправильно либо сделано неправильно — сделана только очевидная часть, а собственно основные моменты которые подразумевались так и остались проблемами.
чтобы было понятно, вот пример — подразумевалось нечто вроде описанной байки из: Re[6]: C# job in Spb
D>Тут ситуация такая: шеф работает мало, предпочитая трепаться со своими подчиненными о своей BMW, сидеть в Internet, читать о последних технологиях в 3D-графике или заниматься столь же не относящимися к его работе делами. D>При этом команда, смотря на шефа, перестает работать.
так с этого и надо было начинать: оригинальный вопрос в ветке после такого описания начинает играть новыми гранями
D>Хочется сделать так, чтобы шеф и все люди в команде занимались хотя бы какой-то минимум времени в день непосредственно работой.
Активный вариант — "шеф, ты не прав"
— просто попытаться объяснить шефу ситуацию со стороны, может быть он поймет.
— поговорить в команде и если Вы там не один такой энтузиаст, то поговорить с шефом командой
— например предложить ему найти какое-нибудь место в отдельном кабинете или хотя бы чтобы глаза не мозолил (и уши) где-нибудь в углу отгородить ему кубрик и т.п.
— есть ли над шефом другой шеф — может быть следует (командой?) с ним пообщаться? но тут уже все на свой страх и риск, изнутри виднее каки у вас отношения и т.п. похоже кадровые перестановки были бы кстати. либо внушение сверху, чтобы хотя бы команду не разлагал...
Пассивный вариант — "начни с себя"
— кто-то все-таки должен снабдить разработчиков четкими заданиями от и до, чтобы был фронт работ и сроки. а потом можно надеть уши и попытаться уйти от реальности в поток чтобы просто делать свою работу без оглядок на других (понятно это не отменяет коммуникацию по мере нужды). Если заданий не дают — попытаться самому себе их формулировать и ставить — почувствуй себя шефом, хуже не будет, может быть и другие со временем заметят и оценят?
— может быть самому себе установить жесткий распорядок дня — в такие-то часы (или после чтения таких-то форумов и утреннего warm-up о погоде к примеру) я работаю и что там вокруг не имеет значения, хоть потоп, от сих и до сих. это поможет легче входить в поток без оглядки на других и т.п. штуки. главное на шефа и других перестать оглядываться — или ходить к шефу самому и получать конкретные задания по мере выполнения старых. но нужно осознавать что тут есть опасность получить классическую ситуацию "кто везет на том и везут". может быть поэтому другие (включая шефа) и не кипят, их устраивает пинание в полноги с трепом о погоде 80%?
А вообще рыба гниет с головы, что тут еще скажешь... обычно шеф устанавливает порядки и коли у вас шеф как описано выше, странно было бы ожидать что все работают как бобики не разгибаясь 10 часов без выходных-праздников. в конце концов в Питере работу найти полегче разработчику, если ситуацию изменить не выходит.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Вообще-то это тебе должен сказать твой шеф.
Оттого, что шеф не говорит, я и задаю такие вопросы.
iT>А мое личное правило — работать столько, сколько указано в договоре. iT>О погоде и не связанном с текущими задачами — пожалуйста, в нерабочее время. Да и из "тематических форумов" только процентов 5..10 реально полезны для твоей текущей работы. Остальные 90..95 — из разряда "погоды".
Я тоже стараюсь на работе 100% времени уделять именно работе, оставив погоду и "околорабочие дела" на нерабочее время.
Только оказывается, что такой подход (реально работать ~ 100% времени, указанном в трудовом договоре) искренне возмущает многих разработчиков.
Обеденное время многие совершенно искренне считают рабочим. "Мы же во время еды беседуем о работе!". Треп по ICQ — это уже само собой разумеющиеся. Как и посещение всяких развлекательных и новостных сайтов. "Надо же нам отвлечься от работы!". Изучение каких-нибудь новых технологий — обязательно! "Ведь это повышает мой кругозор!"
Может произойти так, что тенденции "мы имеем право не работать на рабочем месте" превратятся в полный абсурд.
Есть же какая-то граница, ниже которой опускаться нельзя? Или она зависит от места работы?
Допустимо ли, например, посвящать работе 5 часов в неделю из 40?
Здравствуйте, Кирилл Лебедев, Вы писали:
A>>Ага, "разработка архитектуры для приложениния типа клиент-сервер — 10 часов", так? КЛ>Вы утрируете, и зря. Для того чтобы разработать архитектуру "типа клиент-сервер" разработчику нужно: КЛ>- собрать требования клиента; КЛ>- описать эти требования в виде чернового документа, отослать клиенту и дождаться фидбэка; КЛ>- на основе ответа составить техническое задание (чистовой вариант); КЛ>- ознакомиться с паттернами проектирования для подобных архитектур; КЛ>- построить и описать черновой вариант модели системы; КЛ>- и т.д.
КЛ>Вот эти операции и можно пронормировать.
только это задачи не разработчика, а аналитика. разработчик там нужен только в "и т.д." (я не исключаю, что это может быть одно и то же лицо-на-дуде-игрец, сам такой в некоторых случаях)
более того, упомянуто "дождаться". в случае "составить техзадание (чистовой вариант)" — тоже потребуется несколько циклов ожидания при подгонке и обсуждениях. это — то рабочее время, которое можно тратить так, чтобы по приходу ответа его адекватно восринять. т.е. — алкоголь исключается, а непрофильный форум — нет.
ситуацию, когда человека дергают на три проекта (в целях оптимизации его загрузки, что типа пока там ждет ответа от того клиента может здесь пару классов слабать) назвать хорошей я тоже не могу — получается везде по чуть-чуть и нигде на 100% возможностей. исключение — если контора готова платить такому в три раза больше средней температуры по палате, а человек в ответ способен реально тянуть одновременно три проекта.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>т.е. чтобы шеф был счастлив. О том что шеф глубоко несчастен обычно довольно быстро становится известно, а там и нагрузка в пользу пункта 3 быстро перебалансируется.
Так а сколько шеф имеет право требовать? Понятно, что чем быстрее разработчик сделает свое задание, тем счастливее будет шеф. Как шефу узнать, что на этого разработчика можно увеличить нагрузку?
Здравствуйте, genre, Вы писали:
D>>Как Вы считаете, какое минимально допустимое время разработчик ПО должен уделять непосредственно работе?
G>считается что из 8 часов рабочего дня на пункт три приходится примерно 5 часов. G>мне кажется что в нормальных условиях эта цифра оптимальна.
мои наблюдния показывают, что из 8 часов, проводимых на работе, 5 часов приходятся на второй и третий пункт вместе
еще мои наблюдения показывают, что добиться значительного прироста в среднем за длительный промежуток времени (а не локального за 1-2 дня) к третьему пункту можно только позволив сотруднику самостоятельно перегруппировать рабочее время.
хотя часто приходится слышать мнение, что рабочее время общего пребывания в офисе типа якобы нужно для того, чтобы видеть, что "мы все вместе работаем", "а вдруг ты понадобишься для срочного обсуждения" и проч.
обсуждения — это работа в работе. каждое собрание состоит из приведенных выше трех пунктов. сначала все, ожидая запаздывающих, треплются о погоде и спорте, потом, когда все соберутся, сначала обсуждают всю работу, кроме той, которой посвящено собрание. только потом начинается дело, обсуждение которого ограничивается моментом, когда первому надо "срочно бежать на другое совещание".
как следствие, количество обсуждений надо также сокращать для потенциального увеличения времени, посвященного третьему пункту.
iT>>Вообще-то это тебе должен сказать твой шеф. D>Оттого, что шеф не говорит, я и задаю такие вопросы.
Analyze this: а почему у тебя возник этот вопрос?
D>Только оказывается, что такой подход (реально работать ~ 100% времени, указанном в трудовом договоре) искренне возмущает многих разработчиков.
Такие времена. Впрочем, везде по разному.
D>Есть же какая-то граница, ниже которой опускаться нельзя? Или она зависит от места работы? D>Допустимо ли, например, посвящать работе 5 часов в неделю из 40?
Это должны определять твой шеф и ты, лично для себя, с точки зрения разума и совести.
Может быть очень не просто работать, когда сосед битый час "травит" новости и анекдоты из сети.
Ну, может он и правда, не может работать долго
Здравствуйте, mik1, Вы писали:
M>Дражайший, Вы кого нормировать собираетесь-то? Студентов или специалистов? Сейчас даже первых днем с огнем не найдешь, не говоря о вторых. Если меня кто-то попробует тыкнуть за то, что я тут Вам отвечаю, он тут же будет поставлен перед выбором между повышением моей зп или моим уходом. А я себе работу подберу без тыкателей.
Это значит только то, что:
— сейчас вы получаете меньше, чем могли бы в другом месте
— ваша работа вам неинтересна.
L>Если же надо крепко подумать, понапрягать мозг, то расклад примерно такой: L>3. Рабочее время: 4-5 часов в день это максимум. И дело даже не в том, старается человек или нет. Многие проблемы просто требуют длительного обдумывания и устаканивания видения.
Нет, позвольте! Никто ведь не говорит о кодировании в течении 8 часов!
Устал кодировать — пойди, попроектируй. Устал — пообщайся с коллегой, как лучше сделать что-то в вашем текущем проекте. Надоело — иди к шефу, решай проблемы, мешающие работать. Нет шефа — исправь старые баги. Нет багов — сходи в туалет и садись, покодируй
Но не так: пописал чуть-чуть, новости, анекдоты, форум, обед, новые новости, новые анекдоты, еще чуть-чуть пописал и домой.
L>2. Обучение: 10-20%, не меньше. Иначе наступает деградация. Во-первых, мозг на рутинные операции настраивается.
Образование — это твое личное дело. Без спорта тоже нельзя — давайте 10-20% времени тратить на работе на спорт. А еще без сна нельзя — давайте поспим в рабочее время.
L>Так же приходилось слышать, про некую рекоммендацию врачей, говорящую, что человек больше 4 часов за комьютером работать не должен.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, Spidola, Вы писали:
S>Доктор,а если я — и Снайпер, и Бульдозер, и строителем — это значет что меня вообще нельзя брать на работу ?
Пациент, вы всё-таки определитесь — вы мальчик или девочка. Посмотрите в зеркало, в конце концов...
Коллеги, как вы считаете, какое минимальное время допустимо посвящать работе?
Известно ("Peopleware", "Путь камикадзе", и т.д.), что постоянные переработки не увеличивают общую производительность труда. Что нельзя заставлять людей работать больше. Что на людей нельзя давить, и т.д.
У меня же вопрос другой. Возьмем программиста, у которого в трудовом договоре стоит 40-часовая рабочая неделя.
Эти 40 часов в неделю делятся на:
1) Нерабочее время. Разговоры о погоде, футболе, политике. Общение по ICQ со своими знакомыми и семьей на темы, никак не связанные с IT. Посещение Internet-ресурсов, никак не связанных с IT. Общение на RSDN в форумах "О жизни" и "Политика".
2) Околорабочее время. Время, затрачиваемое на деятельность, связанную с программированием, но напрямую не связанную с его текущими задачами на работе. Изучение новых технологий, не связанных с текущими обязанностями программиста. Треп на тему Windows vs Linux. Рассказы про то, как работается в других компаниях. Общение на RSDN в таких форумах, как "Этюды для программистов" или "О работе".
3) Рабочее время. Время, затрачиваемое на непосредственно выполнение текущих задач: кодирование, изучение проектной документации, отладка, тестирование, общение на RSDN в тематических форумах, посвященных используемым в данный момент технологиям.
Как Вы считаете, какое минимально допустимое время разработчик ПО должен уделять непосредственно работе?
Здравствуйте, Dirichlet, Вы писали:
D>Как Вы считаете, какое минимально допустимое время разработчик ПО должен уделять непосредственно работе?
определяется способностью укладываться в график (надеюсь у разработчика есть список задач\активностей и соотв время на это дело отведенное?)
т.е. чтобы шеф был счастлив. О том что шеф глубоко несчастен обычно довольно быстро становится известно, а там и нагрузка в пользу пункта 3 быстро перебалансируется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Dirichlet, Вы писали:
VAB>>т.е. чтобы шеф был счастлив. О том что шеф глубоко несчастен обычно довольно быстро становится известно, а там и нагрузка в пользу пункта 3 быстро перебалансируется. D>Так а сколько шеф имеет право требовать?
шеф имеет право требовать в соответствии с контрактом
шеф даже имеет право требовать невозможного, но тут есть сложность : когда невозможное не случится — ему придется уже самому выкручиваться.
посему все-таки лучше ставить реальные цели и давать реальные оценки как бы ни были они нежелательны высшему руководству.
D>Понятно, что чем быстрее разработчик сделает свое задание, тем счастливее будет шеф.
вообще говоря скорость вещь такая... подозрительная
возможно в ущерб было качество положено, так что тут нужен глаз да глаз
D>Как шефу узнать, что на этого разработчика можно увеличить нагрузку?
увеличить и посмотреть что будет \рекомендуется совмещать с увеличенными пряниками\
шутка... есть такие понятия как опыт, квалификация и профессиональнные секреты
А ответ в общем виде мне кажется невозможен без конкретизации ситуации:
— какова компетенция шефа в предметной области? есть ли опыт подобных проектов?
— есть ли опыт работы с конкретным разработчиком (или статистика по нему)?
— а опыт\статистика по другим ребятам, но в той же области?
— величина проекта и сложность в т.ч. конкретных задач
— какого рода активности у разработчика, рутина сплошная или наоборот
— какие стимулы у разработчика хорошо работать, есть ли команда не на бумаге
— и т.п.
вообще если вернуться в серьезное русло, то мне кажется часто 50% времени проведенного в потоке (не в конкретный день, а в неделю скажем) — уже весьма и весьма оптимистичный результат. знаю, проводятся исследования с замерами потраченного времени, но там результаты каждый раз сильно разнятся (в разы) и сильно зависят от того кто и для кого исследование проводит, ну и от прочих подобных факторов. так что мне кажется лучший способ это у себя как-то самому подобную статистику попытаться собирать и\или хотя бы примерно представлять.
PS для этого не обязательно внедрять жандармские порядки, лучше даже не афишировать
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, C0s, Вы писали:
C0s>мои наблюдния показывают, что из 8 часов, проводимых на работе, 5 часов приходятся на второй и третий пункт вместе
+1
C0s>как следствие, количество обсуждений надо также сокращать для потенциального увеличения времени, посвященного третьему пункту.
...а также по возможности сокращать список участников, заранее знакомить с повесткой собрания дабы минимизировать вступительную часть и налаживать дисциплину (это про опаздывающих, речь не на 30 сек конечно)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
D>Как Вы считаете, какое минимально допустимое время разработчик ПО должен уделять непосредственно работе?
Вообще-то это тебе должен сказать твой шеф.
А мое личное правило — работать столько, сколько указано в договоре.
О погоде и не связанном с текущими задачами — пожалуйста, в нерабочее время. Да и из "тематических форумов" только процентов 5..10 реально полезны для твоей текущей работы. Остальные 90..95 — из разряда "погоды".
Здравствуйте, xtile, Вы писали:
X>Интересная тема А что думают по поводу пунктов 1 и 2 менеджеры?
Ну на этот счёт можно и догадаться
X>А фрилансеры и прочие, работающие не фуллтайм, а почасово, к примеру? А их заказчики?
Фрилансеры должны быть только рады- обычно же никто над душой сидеть не станет а отведут Х часов на работу и заплатят соответсвенно, а т.к. Х частенько оценивается по производительности резидентов то фрилансер в накладе не остаётся.
C0s>скажем, для большой конторы характерна избыточность персонала и впридачу куча формальных процедур, никак напрямую с тем, что обычно программист понимает под работой
Ну, я так понимаю, что в данном случае мы говорим о ситуации, когда работа есть, есть чем заняться и есть план и все такое.
Конечно, странно было бы тратитить на работу 8 часов вместо двух, за которые ее спокойно и качественно можно сделать, если другой работы просто нет.
С авралами — тоже совершенно отдельная песня, думаю, автора топика интересовал именно случай "обычной" работы, которая идет равномерно из месяца в месяц.
Здравствуйте, Igor Trofimov, Вы писали:
C0s>>скажем, для большой конторы характерна избыточность персонала и впридачу куча формальных процедур, никак напрямую с тем, что обычно программист понимает под работой
iT>Ну, я так понимаю, что в данном случае мы говорим о ситуации, когда работа есть, есть чем заняться и есть план и все такое.
да, в больших конторах с точки зрения задач и планов работа есть, но в силу присущей избыточности все усредняется по "медленным исполнителям". часто ведь планирование делается до выделения конкретных ресурсов. если выделили медленных товарищей — менеджер, как минимум, не ошибся. а если выделили быстрых, то это уже их проблема самоорганизоваться и не помереть со скуки
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Для этого нужно провести нормирование. Работу программиста можно разбить на ряд операций. Готов посморить, что многие из этих операций будут стандартны. Их и надо пронормировать.
Я лет 8 назад работал в такой конторе. Зарплата была хорошая, но маразмы с нормированием рабочего времени были невыносимы. Все были помешаны на "научном" подсчете рабочего времени. Для каждой специальности (финансист, бухгалтер, программист и т.д.) были разработаны списки типовых задач со временем, затрачиваемым на каждую из них. Этот список был абсолютно бессмысленным — например, для программистов там были пункты "архивирование — 15 минут" и "разархивирование — 20 минут". Почему разархивирование занимает больше времени, так никто и не понял. В конце рабочего дня мы должны были заполнять матрицу рабочего времени (по одной оси время с дискретностью в 15 минут, по другой оси список действий), где-то через пару недель я написал для всего отдела программу, генерирующую эту чертову матрицу с соблюдением некоторых условий (например, не больше 2-х операций "дефрагментация жесткого диска" в месяц) . В общем, меня там хватило аж на три месяца, но до сих пор передергивает при воспоминании о той работе
Зато сейчас просто идеально — прихожу когда хочу, ухожу когда хочу, работаю над интересными мне проктами, идиллия
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>вообще говоря скорость вещь такая... подозрительная VAB>возможно в ущерб было качество положено, так что тут нужен глаз да глаз
Я не имею в виду случаи, когда от разработчиков пытаются добиться всего, на что они способны. Я имею в виду обычный рабочий процесс. Если человека, работающего 1 час в день, попросить работать 1,5 часа в день, то качество не пострадает. Например, у меня качество начинает снижаться только где-то на 6-ом часу работы.
VAB>А ответ в общем виде мне кажется невозможен без конкретизации ситуации:
Да, на самом деле у меня вполне конкретная проблема.
VAB>- какова компетенция шефа в предметной области? есть ли опыт подобных проектов?
Что-то понимает, опыт подобных проектов есть.
VAB>- есть ли опыт работы с конкретным разработчиком (или статистика по нему)?
Есть.
VAB>- а опыт\статистика по другим ребятам, но в той же области?
Есть.
VAB>- величина проекта и сложность в т.ч. конкретных задач
Задачи бывают разные. Проекты небольшие.
VAB>- какого рода активности у разработчика, рутина сплошная или наоборот
И так, и так.
VAB>- какие стимулы у разработчика хорошо работать, есть ли команда не на бумаге
Команда есть.
Тут ситуация такая: шеф работает мало, предпочитая трепаться со своими подчиненными о своей BMW, сидеть в Internet, читать о последних технологиях в 3D-графике или заниматься столь же не относящимися к его работе делами.
При этом команда, смотря на шефа, перестает работать.
Хочется сделать так, чтобы шеф и все люди в команде занимались хотя бы какой-то минимум времени в день непосредственно работой.
Здравствуйте, Igor Trofimov, Вы писали:
D>>Допустимо ли, например, посвящать работе 5 часов в неделю из 40?
iT>Это должны определять твой шеф и ты, лично для себя, с точки зрения разума и совести. iT>Может быть очень не просто работать, когда сосед битый час "травит" новости и анекдоты из сети. iT>Ну, может он и правда, не может работать долго
Да, у меня в такой обстановке работать совсем не получается. Либо что-то изменится, либо я уйду.
(Особенно бесит перед deadline делать за других их собственную работу, в то время как люди читаю анекдоты.)
Здравствуйте, Andy77, Вы писали:
A>Этот список был абсолютно бессмысленным
Никто ведь не мешает создать осмысленный список и нормировать не мелочи, а действительно крупные и сложные операции.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Andy77, Вы писали:
A>>Этот список был абсолютно бессмысленным КЛ>Никто ведь не мешает создать осмысленный список и нормировать не мелочи, а действительно крупные и сложные операции.
Ага, "разработка архитектуры для приложениния типа клиент-сервер — 10 часов", так?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, aa_v, Вы писали:
_>>Простите Вы программист или конвеерный рабочий??? КЛ>Я — квалифицированный программист. Но моя квалификация как раз таки и не позволяет мне халявить, т.е. воровать время у работодателя. Проработав в IT-индустрии около 10 лет, могу поделиться наблюдением. Деградация (как профессиональная, так и личностная) начинается с мелочей. Сначала человек начинает посещать форумы, не относящиеся по тематике к его работе, и проводить на них какое-то время. Затем начинает качать видео, и, наконец, порнуху. (Нет, не подумайте, что я против порнухи. Но не в рабочее же время!) В конце-концов получается так, что человек работает от силы 2-3 часа в день, а все остальное время занято развлечениями. При этом он оправдывает себя тем, что он же профессионал и быстро справляется с заданиями.
Вы не читали Джоэля случаем? Он говорит что счастлив поработать 2-3 часа в день, потому-что иногда бывает так что вообще ничего не получаеться сделать.
Здравствуйте, Dirichlet, Вы писали:
D>Коллеги, как вы считаете, какое минимальное время допустимо посвящать работе?
D>Известно ("Peopleware", "Путь камикадзе", и т.д.), что постоянные переработки не увеличивают общую производительность труда. Что нельзя заставлять людей работать больше. Что на людей нельзя давить, и т.д.
D>Эти 40 часов в неделю делятся на:
D>1) Нерабочее время. D>2) Околорабочее время. D>3) Рабочее время. D>Как Вы считаете, какое минимально допустимое время разработчик ПО должен уделять непосредственно работе?
1)
ИМХО, для пункта 1 хорошо подходят "перерывы на кофе". В моём контракте прямо так и сказано, что перерывы на кофе разрешены и оплачиваются компанией. Насколько я знаю, многие фирмы практикуют подобное. В результате, пару раз в день народ собирается на кухне и посвящает минут 20 пункту 1 — всё равно 8 часов подряд голова работать не сможет. Разумеется, самому пить кофе тоже можно. Количество безделья ограничивается тем, что каждый человек примерно представляет себе сколько перерывов на чай/кофе — "прилично"
Честно говоря трачу несколько больше времени на пункт 1 — в основном, на чтенеие газеты.ру. Начинаю читать во время длинной компиляции, но обычно, читаю дольше. Считаю для себя лично приемлемым тратить на чистое разгильдяйство примерно половину времени затрачиваемого на разбор утренней почты.
2) As a rule of thumb на HR страницах моей компании рекомендуют 20-30% времени тратить на сомообразование, самообучение, и т.д. Частично это время выбирается различными курсами. Вот оставшееся и считается приличным для околорабочих действий. Только я бы считал околорабочими гораздо более полезные вещи
Например, поиск решения задачи на форуме и ответ в своей области компетенции — это 2), а трём о Windows vs Linux — 1)
Здравствуйте, Spidola, Вы писали:
D>>Как Вы считаете, какое минимально допустимое время разработчик ПО должен уделять непосредственно работе? S>ИМХО S>1-ый тип: "искатели". S>2-ой тип: "снайперы". S>3-й тип: "строители". S>4-ый тип: "бульдозеры". S>P.S. А кто вы?
Спасибо.. теперь я знаю кто я Искатель..
интересно.. а как зависит "это" от возраста и опыта?
Здравствуйте, neFFy, Вы писали:
FF>Здравствуйте, Spidola, Вы писали:
D>>>Как Вы считаете, какое минимально допустимое время разработчик ПО должен уделять непосредственно работе? S>>ИМХО S>>1-ый тип: "искатели". S>>2-ой тип: "снайперы". S>>3-й тип: "строители". S>>4-ый тип: "бульдозеры". S>>P.S. А кто вы?
FF>Спасибо.. теперь я знаю кто я Искатель.. FF>интересно.. а как зависит "это" от возраста и опыта?
Здравствуйте, Dirichlet, Вы писали:
D>Здравствуйте, Chipsеt, Вы писали:
D>Вообщем, эта статья не может служить оправданием людям, занимающимся нерабочими делами по 5-6 часов в день.
Эта статья должна послужить упреком для всех кто упрекает своих сотрудников в том что они не работают, в то время как эти самые сотрудники делают больше чем остальные.
Программирование больше схоже на науку. Одна правильная мысль может заменить недели работы...
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Dirichlet, Вы писали:
D>>Так а сколько шеф имеет право требовать? Понятно, что чем быстрее разработчик сделает свое задание, тем счастливее будет шеф. Как шефу узнать, что на этого разработчика можно увеличить нагрузку?
КЛ>Для этого нужно провести нормирование. Работу программиста можно разбить на ряд операций. Готов посморить, что многие из этих операций будут стандартны. Их и надо пронормировать.
Дражайший, Вы кого нормировать собираетесь-то? Студентов или специалистов? Сейчас даже первых днем с огнем не найдешь, не говоря о вторых. Если меня кто-то попробует тыкнуть за то, что я тут Вам отвечаю, он тут же будет поставлен перед выбором между повышением моей зп или моим уходом. А я себе работу подберу без тыкателей.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Я не верю в байки о том, что профессионал ушел с работы за то, что его упрекнули чтением форумов. Зато я верю в то, что там либо плохо платили, либо придирки носили систематический характер, либо работа была неинтересной, либо к нему придрались, не установив правил игры (стандартов на выполнение работы).
КЛ>Если на работе хорошо платят (существенно выше, чем в остальных конторах) и требуют качества в выполнении работы систематически, а не от случая к случаю (т.е. не меняют правил игры), то из такой конторы профессионал не уйдет.
Здравствуйте, mik1, Вы писали:
M>Дражайший, Вы кого нормировать собираетесь-то? Студентов или специалистов? Сейчас даже первых днем с огнем не найдешь, не говоря о вторых. Если меня кто-то попробует тыкнуть за то, что я тут Вам отвечаю, он тут же будет поставлен перед выбором между повышением моей зп или моим уходом. А я себе работу подберу без тыкателей.
В том-то и состоит проблема для работодателя. После нормирования ряд квалифицированных операций отдается квалифицированному спецу, а большая часть — неквалифицированных — отдается студентам. Квалифицированному спецу платится зарплата выше рыночной. Но при условии, что он укладывается в нормативы. Если не укладывается или начинает шантажировать руководство в стиле "Без меня вы не обойдетесь", то пусть идет на все 4 стороны. На его место найдется вменяемый чел, который хочет получать зарплату выше средне рыночной.
Если же требования к качеству работы возникают от случая к случаю (например, после длительного "расслабона") или работодатель зациклен на нормировании дешевых операций (типа архивирования/разархивирования) и не пытается упростить сложные (квалифицированные) операции, то согласен, что такое нормирование только хуже.
Здравствуйте, Dirichlet, Вы писали:
D>Известно ("Peopleware", "Путь камикадзе", и т.д.), что постоянные переработки не увеличивают общую производительность труда. Что нельзя заставлять людей работать больше. Что на людей нельзя давить, и т.д. D>Эти 40 часов в неделю делятся на: D>1) Нерабочее время. D>2) Околорабочее время. D>3) Рабочее время.
Хорошая классификация
Что касается процента нерабочего времени, то меняется это "простым" способом — повышением мотивации труда. Если сотрудник будет знать, что за бОльшую работу он получит бОльшую отдачу, то он вряд ли будет в рабочее время читать анекдоты.
Что касается околорабочего времени, то тут сложнее. ИМХО нормальная фирма должна поощрять повышение квалификации сотрудников. Поэтому даже если официально такого нет, то я не вижу ничего столь плохого чтобы в рабочее время почитать MSDN или другие специальные источники, даже если прямо сейчас мне по работе это не надо. Более того, повышение общего уровня разработчика так или иначе положительно скажется и на производительности труда сотрудника в перспективе.
Естественно, тут ещё много косвенных факторов, например уровень текущей зарплаты сотрудника. Например, одно дело если человек получает з/п заведомо выше рыночной именно за то чтобы делать конкретную работу, а совсем другое если его з/п ниже рыночной и пр. По этому поводу вспоминается старый советский анкдот:
— что должен делать инженер на одну зарплату?
— ничего, и даже немножечко вредить
Так что в общем и целом, "бороться" с чтением анекдотов в рабочее время можно только одним — нормальной зарплатой и нормальной мотивацией труда.
С другой стороны, не вижу ничего столь плохого если сотрудник занимается работой на 100% времени. Люди ведь не роботы. Лично я не знаю ни одного программиста (включая меня который бы на работе 100% занимался только работой не отрываясь по 8 часов в сутки. Да и бороться с этим ИМХО не имеет смысла, куда проще лишь учитывать этот фактор при расчете производительности труда. ИМХО куда проще "закрыть глаза" на то что сотрудник 5% времени посвятит чтению анекдотов, чем давить на него или повышать зарплату (что опять же расходы) требуя чтобы он анекдоты не читал.
Более того, возможность сделать что-либо в рабочее время (найти и скачать нужный MP3, просмотреть прайс Интернет-магазина и пр) — также является плюсом для работника, например при поиске/смене места работы. И если при прочих равных одна фирма разрешает "нецелевое" использование Интернета а другая нет, то понятно какая будет выбрана в итоге.
Так что не всё тут так просто как кажется на первый взгляд...
S>А я вот думаю, что программирование давно не похоже на науку — это должне быть чёткий и отлаженный производственный процесс в большинстве случаев (я, конечно, не беру в расчёт тех, кто занимается исключительно "наукой программирования"). Большинство задач решаются типовым набором способов, причём набор способов конечен. На тюнинг каждого способа решения для конкретной задачи должно тратиться не очень болшое время (по оч грубым оценкам — до 20%).
Есть у разработки ПО такая приятная черта — большая часть рутинной работы может быть автоматизирована. И если у вас есть стандартная задача разработки сводного отчета из таблицы операций, выполняемая квалифицированным кодером на 2 дня, то скорее всего при использованнии надлежащего инструментария (OLAP и MS Excel к примеру), она может быть выполнена за 2 часа. И тут для разработчика мало что остается. Это работа скорее внедренца/аналитика/бухгалтера. Хотя, отсутствие инструментария и нежелание его покупать вносят свои коррективы.
Опять же, это только если откинуть такая "незначительные" вещи, как унаследованный код, сложность дискретных систем, использования упрощенных моделей при проектировании и атмосферу на рабочем месте.
Если у вас к примеру одна и таже задача периодически решается с небольшими вариациями, то почему бы ее решение не реиспользовать каждый раз? Или сделать универсальный инструмент, для ее решения?
С другой стороны, сложность создания универсального инструментария на порядок выше. И вот тут то начинается главное веселье. Поэтому комании занимающиеся инновационными разработками, гораздо свободнее относятся к срокам.
Все зависит от того, чем заниматься. Тупо кодить, когда все уже ясно или ненапряжно общаться с пользователями можно и по 8 часов в день. Только тогда у человека как правило мотивация пропадает, так как это сплошная рутина.
Если же надо крепко подумать, понапрягать мозг, то расклад примерно такой:
3. Рабочее время: 4-5 часов в день это максимум. И дело даже не в том, старается человек или нет. Многие проблемы просто требуют длительного обдумывания и устаканивания видения. Плюс работать в потоке непрерывно 8 часов просто нереально. Либо имир умрет, либо ишак сдохнет, либо шеф придет поговорить, о том как идет проект.
2. Обучение: 10-20%, не меньше. Иначе наступает деградация. Во-первых, мозг на рутинные операции настраивается. Во-вторых, рынок ПО еще достаточно быстро развивается. Поэтому если ты на работе 100% времени колбасишь на JSP, то через полгода может оказаться, что твои навыки никому не нужны и контора на рынке не может конкурировать так, как просто не имеет людей с нужными скилзами. Конечно для программеров которые пишут проприетарные системы это не действует.
1. Все остальное время нужно куда-то девать. Плюс голове все-же нужен отдых. Итак где-то 20% времени остается на околачивание груш или ИМБУРДЕ.
Так же приходилось слышать, про некую рекоммендацию врачей, говорящую, что человек больше 4 часов за комьютером работать не должен. Длительность рабочего дня в 8 часов и волшебный множитель 2 для определния реальных сроков выполнения проекта, наводят на размышления....
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, aa_v, Вы писали:
КЛ>Я — квалифицированный программист. Но моя квалификация как раз таки и не позволяет мне халявить, т.е. воровать время у работодателя.
А кто сказал воровать??? работодатель при планировании работ умножает необходимое вемя на 1,5... ты просто береш время которое тебе уже заложили на развитие.
КЛ>Проработав в IT-индустрии около 10 лет, могу поделиться наблюдением. Деградация (как профессиональная, так и личностная) начинается с мелочей. Сначала человек начинает посещать форумы, не относящиеся по тематике к его работе, и проводить на них какое-то время.
Кто сказал что не относящиеся по тематике?? если ты читал 1 сообщение, то заметил что в нерабоее время входит также чтение тематичнеских форумов.
КЛ>Затем начинает качать видео, и, наконец, порнуху. (Нет, не подумайте, что я против порнухи. Но не в рабочее же время!)
А на это есть ограничение трафика.
КЛ>В конце-концов получается так, что человек работает от силы 2-3 часа в день, а все остальное время занято развлечениями. При этом он оправдывает себя тем, что он же профессионал и быстро справляется с заданиями.
Кстати профессионализм какраз нормируется, в отличии от творческих работ.
КЛ>Я не верю в байки о том, что профессионал ушел с работы за то, что его упрекнули чтением форумов. Зато я верю в то, что там либо плохо платили, либо придирки носили систематический характер, либо работа была неинтересной, либо к нему придрались, не установив правил игры (стандартов на выполнение работы).
Когда человека нагружают под 150% еженедельной чистой работой, то долго он не протянет... именно это и продемонстрировали мои коллеги.
КЛ>Если на работе хорошо платят (существенно выше, чем в остальных конторах) и требуют качества в выполнении работы систематически, а не от случая к случаю (т.е. не меняют правил игры), то из такой конторы профессионал не уйдет.
Если в конторах не оставляют времени на саморазвитие, а требуют 150% напряжения рутиной, то люди тоже не выдерживают. Поверь человеку который седня после работы второй раз в жизни написал резюме.
iT>>Образование — это твое личное дело. Без спорта тоже нельзя — давайте 10-20% времени тратить на работе на спорт. А еще без сна нельзя — давайте поспим в рабочее время.
L>Правильно! Мое дело вообще только зарплату получать. Конкурентноспособность компании и ее развитие мне вообще побоку.
Если ты заботишься о конкурентоспособности компании — будь добр делать это нормальными методами. Если ты чувствуешь, что для компании было бы полезхно, если бы ты лично или отдел изучили какую-то новую технологию — иди к руководству, рассказывай им об этом, выбивай курсы.
Это будет время, которое компания целенаправленно тратит на обучение сотрудников.
А если ты сам решил, что будет полезно компании, если ты изучишь brainfuck, и тратишь на это рабочее время — то это ну никак не способствует конкурентоспособности компании, скорее наоборот.
Здравствуйте, Igor Trofimov, Вы писали:
L>>2. Обучение: 10-20%, не меньше. Иначе наступает деградация. Во-первых, мозг на рутинные операции настраивается.
iT>Образование — это твое личное дело.
Повышение квалификации сотрудника — это и дело компании тоже.
Конечно, если компании нужны лишь тупые кодеры для ваяния форм по 8 часов без перерыва — то пусть компания именно с такими и работает. А я в такой ситуации лучше другую работу поищу.
iT>Без спорта тоже нельзя — давайте 10-20% времени тратить на работе на спорт.
Будете-таки смеяться, но есть конторы в которых дают абонемент в спорт-зал например. Кто-то говорил о наличии в одной конторе комнаты для тенниса.
Да и по идее, размяться минут 15 в перерыве между работой — не так уж и плохо для повышения производительности труда.
iT>Но не так: пописал чуть-чуть, новости, анекдоты, форум, обед, новые новости, новые анекдоты, еще чуть-чуть пописал и домой.
Любое времяпровождение можно довести до абсурда, понятное дело. Если сотрудник полдня читает анекдоты, то понятно что это перебор.
А вообще, управление персоналом — это ИМХО не строго формальный процесс, а во-многом искусство. Ведь на качество работы влияют такие факторы, как уровень з/п, режим рабочего дня, да и удовлетворение от условий работы, к примеру. Например, вы можете запретить на работе Интернет и аську вообще, ввести жесткий режим дня, поставить spy-ware и прочее, но при этом придется давать сотруднику бОльшую зарплату чтобы у него была мотивация работать именно здесь. И в итоге, выиграете ли Вы что-то материально? То на то и получится.
PS: Я уже говорил как-то, у нас в конторе шеф прекрасно знал что после обеда народ время от времени полчаса играл в CS. И никаких санкций по этому поводу не было, была даже негласная игра, кто быстрее — шеф успеет войти в комнату или сотрудник закроет CS И в принципе, не сказал бы что производительность работы в целом от этого сильно ухудшалась.
Здравствуйте, Spidola, Вы писали:
S>Есть ещё несколько типов, но уже рука устала кнопки жать.
Хочется продолжения!
Вообще очень похоже на концепцию разделения людей по типам командных ролей, только для IT
Иследователь похож на Исследователя ресурсов
Снайпер ==Генератор идей
Бульдозер ==Рабочая пчелка
Здравствуйте, Spidola, Вы писали:
S>P.S. А кто вы?
Я наверное что-то среднее между искателем и снайпером. Вернее так: если решение рождается на стадии чтения ТЗ то снайпер иначе превращаюсь в искателя.
Причем мне кажется что искатель с набором опыта постепенно преобретает некоторые черты снайпера. Ибо если решение извесно то что думать трясти надо.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
), для которых соотношение времени "эффективной работы" и "времени безделья" разное.
Конкурентноспособность компании и ее развитие мне вообще побоку. 
: когда невозможное не случится — ему придется уже самому выкручиваться. 
"Всё что не убивает нас, делает нас сильнее..."
И тут для разработчика мало что остается. Это работа скорее внедренца/аналитика/бухгалтера. Хотя, отсутствие инструментария и нежелание его покупать вносят свои коррективы. 
