Здравствуйте, 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 часов???

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

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

Здравствуйте, Andy77, Вы писали:

A>Этот список был абсолютно бессмысленным
Никто ведь не мешает создать осмысленный список и нормировать не мелочи, а действительно крупные и сложные операции.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, Andy77, Вы писали:

A>>Этот список был абсолютно бессмысленным
КЛ>Никто ведь не мешает создать осмысленный список и нормировать не мелочи, а действительно крупные и сложные операции.

Ага, "разработка архитектуры для приложениния типа клиент-сервер — 10 часов", так?

Здравствуйте, Andy77, Вы писали:

A>Ага, "разработка архитектуры для приложениния типа клиент-сервер — 10 часов", так?
Вы утрируете, и зря. Для того чтобы разработать архитектуру "типа клиент-сервер" разработчику нужно:
— собрать требования клиента;
— описать эти требования в виде чернового документа, отослать клиенту и дождаться фидбэка;
— на основе ответа составить техническое задание (чистовой вариант);
— ознакомиться с паттернами проектирования для подобных архитектур;
— построить и описать черновой вариант модели системы;
— и т.д.

Вот эти операции и можно пронормировать.

Здравствуйте, Кирилл Лебедев, Вы писали:

A>>Ага, "разработка архитектуры для приложениния типа клиент-сервер — 10 часов", так?
КЛ>Вы утрируете, и зря. Для того чтобы разработать архитектуру "типа клиент-сервер" разработчику нужно:
КЛ>- собрать требования клиента;
КЛ>- описать эти требования в виде чернового документа, отослать клиенту и дождаться фидбэка;
КЛ>- на основе ответа составить техническое задание (чистовой вариант);
КЛ>- ознакомиться с паттернами проектирования для подобных архитектур;
КЛ>- построить и описать черновой вариант модели системы;
КЛ>- и т.д.

КЛ>Вот эти операции и можно пронормировать.

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

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, aa_v, Вы писали:

_>>Простите Вы программист или конвеерный рабочий???
КЛ>Я — квалифицированный программист. Но моя квалификация как раз таки и не позволяет мне халявить, т.е. воровать время у работодателя. Проработав в IT-индустрии около 10 лет, могу поделиться наблюдением. Деградация (как профессиональная, так и личностная) начинается с мелочей. Сначала человек начинает посещать форумы, не относящиеся по тематике к его работе, и проводить на них какое-то время. Затем начинает качать видео, и, наконец, порнуху. (Нет, не подумайте, что я против порнухи. Но не в рабочее же время!) В конце-концов получается так, что человек работает от силы 2-3 часа в день, а все остальное время занято развлечениями. При этом он оправдывает себя тем, что он же профессионал и быстро справляется с заданиями.

Вы не читали Джоэля случаем? Он говорит что счастлив поработать 2-3 часа в день, потому-что иногда бывает так что вообще ничего не получаеться сделать.

Здравствуйте, Chipsеt, Вы писали:

C>Вы не читали Джоэля случаем? Он говорит что счастлив поработать 2-3 часа в день, потому-что иногда бывает так что вообще ничего не получаеться сделать.

Он говорит, что счастлив эффективно поработать 2-3 часа в день. Чтобы достичь такого результата, большинству из нас потребуется работать существенно больше.

Чтобы работать эффективно, нас ничто не должно отвлекать. А нас отвлекают телефонные звонки, вопросы коллег, приходящие сообщение по ICQ, и т.д. Мы можем за весь день вообще не войти в "поток", в котором работаем эффективно.

Да и Джоель в конце статьи говорит, что надо работать:

Мы должны просто приходить каждое утро и, как-нибудь, запускать редактор.

Вообщем, эта статья не может служить оправданием людям, занимающимся нерабочими делами по 5-6 часов в день.

Здравствуйте, Dirichlet, Вы писали:

VAB>>вообще говоря скорость вещь такая... подозрительная
VAB>>возможно в ущерб было качество положено, так что тут нужен глаз да глаз
D>Я не имею в виду случаи, когда от разработчиков пытаются добиться всего, на что они способны. Я имею в виду обычный рабочий процесс. Если человека, работающего 1 час в день, попросить работать 1,5 часа в день, то качество не пострадает. Например, у меня качество начинает снижаться только где-то на 6-ом часу работы.
я про то что если Вы запланировали человеку неделю на что-то, хорошо знаете что оно занимает минимум 3-4 дня даже у Вас (предполагаем квалификацию шефа "не хуже" априори + неделя простая страховка по срокам), а он приносит через полдня с гордым видом мол "шеф усе готово" — скорее всего задание было либо понято неправильно либо сделано неправильно — сделана только очевидная часть, а собственно основные моменты которые подразумевались так и остались проблемами.

чтобы было понятно, вот пример — подразумевалось нечто вроде описанной байки из: Re[6]: C# job in Spb

Автор: Valerio
Дата: 15.02.05

D>Тут ситуация такая: шеф работает мало, предпочитая трепаться со своими подчиненными о своей BMW, сидеть в Internet, читать о последних технологиях в 3D-графике или заниматься столь же не относящимися к его работе делами.
D>При этом команда, смотря на шефа, перестает работать.
так с этого и надо было начинать: оригинальный вопрос в ветке после такого описания начинает играть новыми гранями

D>Хочется сделать так, чтобы шеф и все люди в команде занимались хотя бы какой-то минимум времени в день непосредственно работой.

Активный вариант — "шеф, ты не прав"

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

Пассивный вариант — "начни с себя"

— кто-то все-таки должен снабдить разработчиков четкими заданиями от и до, чтобы был фронт работ и сроки. а потом можно надеть уши и попытаться уйти от реальности в поток чтобы просто делать свою работу без оглядок на других (понятно это не отменяет коммуникацию по мере нужды). Если заданий не дают — попытаться самому себе их формулировать и ставить — почувствуй себя шефом, хуже не будет, может быть и другие со временем заметят и оценят?
— может быть самому себе установить жесткий распорядок дня — в такие-то часы (или после чтения таких-то форумов и утреннего warm-up о погоде к примеру) я работаю и что там вокруг не имеет значения, хоть потоп, от сих и до сих. это поможет легче входить в поток без оглядки на других и т.п. штуки. главное на шефа и других перестать оглядываться — или ходить к шефу самому и получать конкретные задания по мере выполнения старых. но нужно осознавать что тут есть опасность получить классическую ситуацию "кто везет на том и везут". может быть поэтому другие (включая шефа) и не кипят, их устраивает пинание в полноги с трепом о погоде 80%?

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

Здравствуйте, Dirichlet, Вы писали:

D>Как Вы считаете, какое минимально допустимое время разработчик ПО должен уделять непосредственно работе?

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

ИМХО

1-ый тип: "искатели".

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

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

2-ой тип: "снайперы".

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

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

3-й тип: "строители".

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

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

4-ый тип: "бульдозеры".

К бульдозерам относятся разработчики, которые методично и размеренно решают задачу. Бульдозеры могут решить любую задачу. Скажи им написать СУБД — они её напишут. Причём неважно, что у них на машине уже стоит другая СУБД — они не будут на неё смотреть — сказали написать, значит напишу!
Бульдозеры мало отвлекаются на внешний мир, однако у них есть несколько особенностей, снижающих эффективность работы. Первая — решение всех задач подряд. Если бульдозера вдруг не устраивает какой-то визуальный компонент (ну не нравится!) он напишет новый. Если не нравится, как реализован протокол — он напишет свою реализацию. Причём, как правило, бульдозер частенько отвлекается и его компонент или протокол может значительно больше, нежели этого требует задача.
Бульдозер медленно разгоняется, зато, когда распишется — его не остановить.
Соотношение "отвлечение" — "работа" примерно 20/80, однако эффективность не очень высока из-за "профильных" отвлечений.

Наиболее эффективен на длинных и сложных задачах, которые нужно прописывать по нескольку недель. С точки зрения сроков мало управляем, однако в большинстве случаев может быть учтён за счёт анализа предыдущих задач, поскольку эффективность очень стабильная.

Есть ещё несколько типов, но уже рука устала кнопки жать. В общем — мысль — каждому для эффективного результата требуется своё соотношение времени работы/отдыха.


P.S. А кто вы?

Здравствуйте, 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>>Так а сколько шеф имеет право требовать? Понятно, что чем быстрее разработчик сделает свое задание, тем счастливее будет шеф. Как шефу узнать, что на этого разработчика можно увеличить нагрузку?

КЛ>Для этого нужно провести нормирование. Работу программиста можно разбить на ряд операций. Готов посморить, что многие из этих операций будут стандартны. Их и надо пронормировать.

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

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Я не верю в байки о том, что профессионал ушел с работы за то, что его упрекнули чтением форумов. Зато я верю в то, что там либо плохо платили, либо придирки носили систематический характер, либо работа была неинтересной, либо к нему придрались, не установив правил игры (стандартов на выполнение работы).

КЛ>Если на работе хорошо платят (существенно выше, чем в остальных конторах) и требуют качества в выполнении работы систематически, а не от случая к случаю (т.е. не меняют правил игры), то из такой конторы профессионал не уйдет.

А вот с этим я уже полностью согласен.

Здравствуйте, Chipsеt, Вы писали:

C>Программирование больше схоже на науку. Одна правильная мысль может заменить недели работы...

А я вот думаю, что программирование давно не похоже на науку — это должне быть чёткий и отлаженный производственный процесс в большинстве случаев (я, конечно, не беру в расчёт тех, кто занимается исключительно "наукой программирования"). Большинство задач решаются типовым набором способов, причём набор способов конечен. На тюнинг каждого способа решения для конкретной задачи должно тратиться не очень болшое время (по оч грубым оценкам — до 20%).

А вот "кулибиных" надо обучать.

Здравствуйте, mik1, Вы писали:

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

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

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

Здравствуйте, Dirichlet, Вы писали:

D>Известно ("Peopleware", "Путь камикадзе", и т.д.), что постоянные переработки не увеличивают общую производительность труда. Что нельзя заставлять людей работать больше. Что на людей нельзя давить, и т.д.
D>Эти 40 часов в неделю делятся на:
D>1) Нерабочее время.
D>2) Околорабочее время.
D>3) Рабочее время.

Хорошая классификация

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

Что касается околорабочего времени, то тут сложнее. ИМХО нормальная фирма должна поощрять повышение квалификации сотрудников. Поэтому даже если официально такого нет, то я не вижу ничего столь плохого чтобы в рабочее время почитать MSDN или другие специальные источники, даже если прямо сейчас мне по работе это не надо. Более того, повышение общего уровня разработчика так или иначе положительно скажется и на производительности труда сотрудника в перспективе.

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

С другой стороны, не вижу ничего столь плохого если сотрудник занимается работой на 100% времени. Люди ведь не роботы. Лично я не знаю ни одного программиста (включая меня который бы на работе 100% занимался только работой не отрываясь по 8 часов в сутки. Да и бороться с этим ИМХО не имеет смысла, куда проще лишь учитывать этот фактор при расчете производительности труда. ИМХО куда проще "закрыть глаза" на то что сотрудник 5% времени посвятит чтению анекдотов, чем давить на него или повышать зарплату (что опять же расходы) требуя чтобы он анекдоты не читал.

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

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

Здравствуйте, DmitryElj, Вы писали:

DE>С другой стороны, не вижу ничего столь плохого если сотрудник занимается работой на 100% времени.

Опечатка, естественно надо читать "не"