1) У людей западной культуры (в т. ч. россиян) производительность постоянна, не меняется во времени. Т. е. если человек дебил и лентяй — то он всегда филонит. Если разработчик грамотный, то он опять-таки всегда работает хорошо.
2) А у этих азиатских разработчиков бывают пики производительности. То есть, 80 % времени они работают как дебилы, но время от времени выполняют ту или иную задачу на удивление хорошо, все понимают, все делают качественно. Я говорил с тимлидом и он мне тоже сказал, что наблюдал этот феномен.
Вопрос: В чем причина таких перепадов?
Моя гипотеза: Так как общение на 80 % идет через скайп и на 20 % через таск-трекер, я никогда не вижу лицо человека (удаленного разработчика), с которым говорю.
Из этого можно предположить, что в моменты пиков производительности я общался с другим удаленным разработчиком, нежели когда производительность была мизерной. Т. е. под одним и тем же ником в скайпе может скрываться более одного человека.
В пользу этой гипотезы говорит еще то, что иногда я долго объясняю удаленному разработчику, что мы делаем и зачем, а на следующий день обнаруживаю, что он все это забыл (судя по вопросам). Ну и опять приходится все разжевывать.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Из этого можно предположить, что в моменты пиков производительности я общался с другим удаленным разработчиком, нежели когда производительность была мизерной. Т. е. под одним и тем же ником в скайпе может скрываться более одного человека.
Я слышал, что в Китае есть места, где 200$ это огромные деньги, но при этом есть возможность получить доступ к компьютеру и стать программером. Так что в теории возможно Если это так, то делаю очередной facepalm в сторону Китая.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>2) А у этих азиатских разработчиков бывают пики производительности. То есть, 80 % времени они работают как дебилы, но время от времени выполняют ту или иную задачу на удивление хорошо, все понимают, все делают качественно. Я говорил с тимлидом и он мне тоже сказал, что наблюдал этот феномен.
На наших широтах постоянно такое. 80% времени человек сидит в LJ, хабре, SO и филонит, потом вспоминает что сдавать проект то надо и вкалывает в поте лица...
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>1) У людей западной культуры (в т. ч. россиян) производительность постоянна, не меняется во времени. Т. е. если человек дебил и лентяй — то он всегда филонит. Если разработчик грамотный, то он опять-таки всегда работает хорошо.
Ну вообще-то это не так, смотрю по своим коллегам. Есть периоды подъёма и периоды спада.
Другой вопрос, что обычно человек об этом честно говорит, например: "У меня сегодня голова не работает на новый код, буду вместо этого писать доку или разгребать старые тикеты".
ДП>Из этого можно предположить, что в моменты пиков производительности я общался с другим удаленным разработчиком, нежели когда производительность была мизерной. Т. е. под одним и тем же ником в скайпе может скрываться более одного человека.
ДП>В пользу этой гипотезы говорит еще то, что иногда я долго объясняю удаленному разработчику, что мы делаем и зачем, а на следующий день обнаруживаю, что он все это забыл (судя по вопросам). Ну и опять приходится все разжевывать.
А это коррелирует с качеством мышления? То есть оно между такими днями сильно меняется?
Вообще я был бы не удивлён, если бы они действительно так работали.
The God is real, unless declared integer.
Re: Пики производительности
От:
Аноним
Дата:
31.08.11 13:55
Оценка:
Здравствуйте, Дмитрий Писаренко, Вы писали:
Не знаю, что в вашем конкретном случае, но, вроде, два и более индуса под одним аккаунтом — это классическая ситуация.
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>На наших широтах постоянно такое. 80% времени человек сидит в LJ, хабре, SO и филонит, потом вспоминает что сдавать проект то надо и вкалывает в поте лица...
На товарищей, с которыми работаю я, приближение дедлайна не действует.
Давление, наезды — помогают, но на них никаких нервов (моих) не хватит.
Здравствуйте, netch80, Вы писали:
N>А это коррелирует с качеством мышления? То есть оно между такими днями сильно меняется?
Мне это трудно оценить. Я несколько месяцев каждому из них рассказывал про разные "теоретические" вещи, которые должны были способствовать улучшению их работы.
Как прикинуть трудозатраты, как проектировать код, как анализировать дефект (как от симптома перейти к его причине) и т. п.
Я надеялся, что они под воздействием этих материалов и объяснений станут работать лучше (такие вещи работали в отношении некоторых удаленных разработчиков, правда, российских и украинских).
Потом я на эту образовательную программу забил, потому что не было никаких абсолютно результатов. То есть — вообще никаких.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Здравствуйте!
ДП>Я работаю с удаленными разработчиками из Азии.
ДП>Заметил одну удивительную особенность.
ДП>1) У людей западной культуры (в т. ч. россиян) производительность постоянна, не меняется во времени. Т. е. если человек дебил и лентяй — то он всегда филонит. Если разработчик грамотный, то он опять-таки всегда работает хорошо.
ДП>2) А у этих азиатских разработчиков бывают пики производительности. То есть, 80 % времени они работают как дебилы, но время от времени выполняют ту или иную задачу на удивление хорошо, все понимают, все делают качественно. Я говорил с тимлидом и он мне тоже сказал, что наблюдал этот феномен.
ДП>Вопрос: В чем причина таких перепадов?
ДП>Моя гипотеза: Так как общение на 80 % идет через скайп и на 20 % через таск-трекер, я никогда не вижу лицо человека (удаленного разработчика), с которым говорю.
ДП>Из этого можно предположить, что в моменты пиков производительности я общался с другим удаленным разработчиком, нежели когда производительность была мизерной. Т. е. под одним и тем же ником в скайпе может скрываться более одного человека.
ДП>В пользу этой гипотезы говорит еще то, что иногда я долго объясняю удаленному разработчику, что мы делаем и зачем, а на следующий день обнаруживаю, что он все это забыл (судя по вопросам). Ну и опять приходится все разжевывать.
ДП>У кого-нибудь такое бывало?
ДП>Всего доброго
ДП>Дмитрий
Я не согласен, что у "Наших" производительность труда константна... например, я тоже лучше думаю и работаю по утрам....
Тем не менее, скорее всего, у азиатов это как-то может коррелировать с климатом, температурой... Вспомним сиесту (хоть это и не Азия)
Re: Пики производительности
От:
Аноним
Дата:
31.08.11 22:04
Оценка:
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>У кого-нибудь такое бывало?
У нас в компании было 2 "азиата" на контракте через посредника. У них производительность по очереди выстреливала. Один работает другой вроде бы тоже работает но как спросишь что нибудь — ерунду говорит. Смотришь логи в СВН — все красиво. Первый у него типа ТимЛид и поэтому все таски через него проходят. Появилось подозрение что второй ничего не делает, а первый его покрывает. Контракт второму не продлили. Общая производительность осталась на преженем уровне.
Мое субьективное мнение — даже хорошего программиста из Индии нужно пресовать. Это культурное различие, они не обижаются а только лучше работают (по краыней мере мне так кажется что не обижаются ).
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Как прикинуть трудозатраты, как проектировать код, как анализировать дефект (как от симптома перейти к его причине) и т. п.
Пользуясь случаем, спрошу по выделенному. Как вы прикидываете трудозатраты? Какой метод?
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>>Как прикинуть трудозатраты, как проектировать код, как анализировать дефект (как от симптома перейти к его причине) и т. п.
0K>Пользуясь случаем, спрошу по выделенному. Как вы прикидываете трудозатраты? Какой метод?
2) Потом думаем как это сделать и разбиваем весь этот процесс на элементарные операции, для каждой из которых легко прикинуть трудозатраты.
3) Оцениваем для каждой операции время (2 значения — минимум и максимум), приплюсовываем 30 % на непредвиденные дела. В результате получаем 3 значения — мин., средние и макс. трудозатраты.
Примечание: Этап 2 происходит в голове, т. е. мы не программируем (исключение: прописывание интерфейсов для функциональных блоков).
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Здравствуйте!
ДП>Я работаю с удаленными разработчиками из Азии.
ДП>Заметил одну удивительную особенность.
ДП>1) У людей западной культуры (в т. ч. россиян) производительность постоянна, не меняется во времени.
как русский человек скажу, что у меня голова может работать только в импульсном режиме.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
В принципе довольно разумно.
ДП>3) Оцениваем для каждой операции время (2 значения — минимум и максимум), приплюсовываем 30 % на непредвиденные дела. В результате получаем 3 значения — мин., средние и макс. трудозатраты.
А вот на этом этапе не возникает проблем? Откуда вы знаете, сколько времени писать для того или иного действия (особенно если не сталкивались с подобным)? Ведь мелочь, которой вы напишите 5 мин., может занять пол дня... Даже из вашей таблицы видно, что это цифры с потолка:
Кроме того, вы бы быстрее содали поле "Логин", чем написали бы о нем в таблицу. На составление таких таблиц и продумывание деталей уходит много времени.
Возможно будет более рационально использовать метод функциоальных точек: http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml Он решает проблему сколько писать, если ранее не сталкивался + привносит некую объективность. Ведь заказчику нужно обосновать почему вы написали именно 4 часа, а не 20 минут... Вдруг вы завышаете стоимость свой реботы. Вот FP -- объективный метод оценки.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, Дмитрий Писаренко, Вы писали:
0K>В принципе довольно разумно.
ДП>>3) Оцениваем для каждой операции время (2 значения — минимум и максимум), приплюсовываем 30 % на непредвиденные дела. В результате получаем 3 значения — мин., средние и макс. трудозатраты.
0K>Откуда вы знаете, сколько времени писать для того или иного действия (особенно если не сталкивались с подобным)?
Из опыта. Вот у меня есть свой проект, на платформе "Ява+Vaadin+Maven+git". В ходе работы над ним я понял, сколько времени нужно на те или иные элементарные операции.
А потом ко мне приходит заказчик и говорит, что ему нужно сделать проект на базе GWT, можно и на Ваадине.
Ну и какая проблема оценить каждую операцию, если я уже занимался этим в своем проекте?
Если же техническая платформа новая, то прежде, чем давать заказчику смету, я с ней поиграюсь (сделаю прототип) и опять-таки опытным путем пойму, что сколько времени занимает.
0K>http://dl.dropbox.com/u/11776689/blog/2011_05_05/img/img24-entry-page-effort-estimate.png
0K>Кроме того, вы бы быстрее содали поле "Логин", чем написали бы о нем в таблицу. На составление таких таблиц и продумывание деталей уходит много времени.
О чем в моей статье речь?
О том, чтобы сказать потенциальному заказчику, сколько его продукт может стоить.
Вы говорите о следующем этапе, о реализации.
Этот этап может наступить (мы договоримся), а может и не настуить.
Но — заказчик точно, со 100 % вероятностью, откажется работать, если не дать ему представления о сроках и стоимости.
Поставьте себя на место заказчика: Вы хотите положить плитку в ванной. Спрашиваете мастера — сколько времени это займет, и сколько будет стоить?
Я по опыту знаю, что если расчитывать трудозатраты моим методом, то в 90 % случаев реальные трудозатраты будут находится в интервале между минимальными и средними.
0K>Возможно будет более рационально использовать метод функциоальных точек: http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml Он решает проблему сколько писать, если ранее не сталкивался + привносит некую объективность. Ведь заказчику нужно обосновать почему вы написали именно 4 часа, а не 20 минут... Вдруг вы завышаете стоимость свой реботы. Вот FP -- объективный метод оценки.
Я знаю, что такое FP и в молодости даже серьезно думал о том, чтобы применять его на практике.
У него есть 2 недостатка, которые делают его применение в реальной жизни невозможной:
1) Метод основывается на статистических данных разработки ПО в больших компаниях
То есть, взяли 100 проектов в Ай-Би-Эм, посчитали их стоимость, а потом построили модель, которая объясняет зависимости трудозатрат от разных факторов.
Если бы я
а) работал в Ай-Би-Эм,
б) делал ПО на тех. платформах, которые использовались в исследовании и
в) пользовался теми же процедурами (технологией разработки), что и подопытные разработчики,
тогда FP можно было бы использовать.
Если же у меня
а) другие организационные рамки,
б) другие тех. платформы и
в) другие технологии разработки,
то и трудозатраты будут другими.
Теперь подробнее.
Организационные рамки (пункт а) выше) сильно влияют на объем работы. В некоторых случаях двое талантливых разработчиков в маленькой конторе сделают ПО быстрее, качественнее и дешевле, чем двое таких же талантливых разработчиков в компании-гиганте.
Если у Вас оффшорные разработчики, то это тоже другие организационные рамки. Если у Вас разработчики из другой культуры, опять все иначе.
Технические платформы (пункт б) выше). На разных тех. платформах одинаковые операции требуют разных трудозатрат.
Пример: Вам надо сделать формы для ввода, редактирования и удаления записей из некой таблицы, в веб-приложении.
Я по опыту знаю, что на Ruby on Rails выполнение такой операции займет минут 15-30, а на Яве на это может уйти несколько часов.
Технологии разработки (пункт в) выше). Трудозатраты зависят также и от того, КАК именно человек работает.
Наиболее яркий пример — это отсутствие цели. Выглядит это так: Человек часами что-то пишет, ковыряется в коде и как-то все бестолку.
Я его спрашиваю: Что ты делаешь? Зачем ты пишешь этот код, чтобы что? И как ты поймешь, что все сделал?
Как правило, такие вопросы повергают разработчика в ступор.
Естественно, что если человек не понимает сам, что он делает и зачем, то ему потребуется больше времени на работу, чем если человек это все понимает.
Если еще много "хитростей", которые позволяют сократить трудозатраты.
2) Этот метод невозможно адаптировать под мои условия
Насколько мне известно, есть коэффициенты для пересчета FP в строки кода разных языков программирования, а из строк кода теоретически можно высчитать трудозатраты.
Но... это опять, усредненные данные, магические цифры. Средняя температура по больнице.
Кроме того, там нет данных, например, для Ruby on Rails и 1С. И непонятно, как эти коэффициенты вывести самостоятельно.
* * *
А для того, чтобы посчитать приблизительные трудозатраты на каждую операцию, Вам достаточно компьютера, секундомера и немного рефлексии.
Тогда Вы можете вывести данные не для каких-то абстрактных среднестатистических разработчиков, а данные, которые отражают конкретно Ваши условия.
Образно говоря, Вы оперируете не средней температурой по больнице, а берете градусник и измеряете лично Вашу температуру.
0K>Ведь заказчику нужно обосновать почему вы написали именно 4 часа, а не 20 минут...
Это все теория. В моей практике не разу не было, чтобы заказчик стал требовать таких объяснений.
Если заказчик такое требует, это свидетельствует о дефиците доверия, это уже другая степь.
Доверие можно усилить простым способом: Сказать заказчику, что перед заключением договора будет "тест-драйв" — разработка прототипа (2-4 недели) его ПО без каких-либо обязательств с его стороны.
Если тест-драйв будет успешным, то к моменту подписания договора будет прототип.
Такие вещи на заказчиков действуют (проверял).
И я сомневаюсь, что на заказчика могут подействовать какие-то сложные подсчеты заокеанских перемалывателей чисел.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Из опыта. Вот у меня есть свой проект, на платформе "Ява+Vaadin+Maven+git". В ходе работы над ним я понял, сколько времени нужно на те или иные элементарные операции.
Проблема в том, что вы смотрите не на те операции. Вы пишите: создать поле, создать метод, создать обработчик, создать класс... Это все секунды (я печатаю со скоростью 300 символов в секунду).
Вот скажите мне пожалуйста, на что у вас ушло 10-30 минут при создании класса окна? Просто выбрать в студии Add New WebForm вы пол часа делаете? Это же ровно 5 секунд!!!
Основные затраты в процессе разработки -- это мыслительный процесс, а не то что вы считаете.
У вас этого нет. То что вы пытаетесь оценить по времени -- слабо коррелирует с затратами времени. Кроме того, гораздо быстрее создать поле, чем занести информацию о нем в таблицу (создать поле такое, время мин., время макс.).
То что вы писали ранее (Use Case, структура проекта, структура данных) -- правильно. А вот далее что-то не определенное.
ДП>А потом ко мне приходит заказчик и говорит, что ему нужно сделать проект на базе GWT, можно и на Ваадине. ДП>Ну и какая проблема оценить каждую операцию, если я уже занимался этим в своем проекте? ДП>Если же техническая платформа новая, то прежде, чем давать заказчику смету, я с ней поиграюсь (сделаю прототип) и опять-таки опытным путем пойму, что сколько времени занимает.
Т.е. посоздаете поля и классы и посмотрите колько минут у вас это займет?
ДП>Но — заказчик точно, со 100 % вероятностью, откажется работать, если не дать ему представления о сроках и стоимости. ДП>Поставьте себя на место заказчика: Вы хотите положить плитку в ванной. Спрашиваете мастера — сколько времени это займет, и сколько будет стоить? ДП>Если этот мастер скажет "займет столько, сколько займет", то Вы его, наверное, пошлете подальше.
Вовсе не обязательно. Штукатурка и прочая механическая работа рассчитывается очень просто. Разработка ПО -- это не штукатурка и не кладка плитки, здесь сроки называются лишь примерно.
0K>>Возможно будет более рационально использовать метод функциоальных точек: http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml
ДП>Нет, не будет. ДП>Я по опыту знаю, что если расчитывать трудозатраты моим методом, то в 90 % случаев реальные трудозатраты будут находится в интервале между минимальными и средними.
Ну вот так всегда у русских. Мой метод самый точный. То что там люди годами изучали -- это все чепуха...
ДП>1) Метод основывается на статистических данных разработки ПО в больших компаниях
Ну и что?
ДП>То есть, взяли 100 проектов в Ай-Би-Эм, посчитали их стоимость, а потом построили модель, которая объясняет зависимости трудозатрат от разных факторов.
Кстати, очень хороший и правильный подход: наблюдение при большой выборке.
ДП>а) работал в Ай-Би-Эм,
А какая разница где работать?
ДП>б) делал ПО на тех. платформах, которые использовались в исследовании и ДП>в) пользовался теми же процедурами (технологией разработки), что и подопытные разработчики,
Рекламный звон вокруг инструментов и методов — это чума индустрии ПО. Большая часть усовершенствований средств и методов приводит к увеличению производительности и качества примерно на 5-35%. Но многие из этих усовершенствований были заявлены как дающие преимущества на "порядок".
ДП>Организационные рамки (пункт а) выше) сильно влияют на объем работы. В некоторых случаях двое талантливых разработчиков в маленькой конторе сделают ПО быстрее, качественнее и дешевле, чем двое таких же талантливых разработчиков в компании-гиганте.
Ну конечно. Это зависит от способности разработчиков работать (включая способность делать то, что нужно, а не то, что им интересно). В зависимости от этого и считается оплата за разработку. Должно ли интересовать заказчика то, что вы не умеете быстро делать вещи, которые вам не интересны? Раз не умеете -- то и получайте соответственно.
ДП>2) Этот метод невозможно адаптировать под мои условия
ДП>Насколько мне известно, есть коэффициенты для пересчета FP в строки кода разных языков программирования, а из строк кода теоретически можно высчитать трудозатраты.
ДП>Но... это опять, усредненные данные, магические цифры. Средняя температура по больнице.
Усредненные значения. Вы можете получить свои на 1 FP и они сильно отличаться не будут.
ДП>Кроме того, там нет данных, например, для Ruby on Rails и 1С. И непонятно, как эти коэффициенты вывести самостоятельно.
Ну да.
ДП>А для того, чтобы посчитать приблизительные трудозатраты на каждую операцию, Вам достаточно компьютера, секундомера и немного рефлексии.
Какую операцию? Ака создать поле, создать метод, создать класс, создать обработчик? Откуда у вас взялись 20 минут на создание класса окна?
ДП>Тогда Вы можете вывести данные не для каких-то абстрактных среднестатистических разработчиков, а данные, которые отражают конкретно Ваши условия.
Как раз нужно для усредненных разработчиков. И платить вашим в зависимости от того, насколько они соответствуют требованиям. Иначе -- это распил бюджета.
ДП>Образно говоря, Вы оперируете не средней температурой по больнице, а берете градусник и измеряете лично Вашу температуру.
Я оперирую температурой 36.6. А вы измерили среднюю температуру по больнице, и на основнии нее пытаетесь понять кто болен а кто нет.
0K>>Ведь заказчику нужно обосновать почему вы написали именно 4 часа, а не 20 минут...
ДП>Это все теория. В моей практике не разу не было, чтобы заказчик стал требовать таких объяснений. ДП>Если заказчик такое требует, это свидетельствует о дефиците доверия, это уже другая степь.
Заказчик имеет право на сомнение.
ДП>Доверие можно усилить простым способом: Сказать заказчику, что перед заключением договора будет "тест-драйв" — разработка прототипа (2-4 недели) его ПО без каких-либо обязательств с его стороны.
А что если исп. срок вы работаете на всю катушку, а потом спустя рукава? Ведь многие так и делают. Даже не этом форуме признавались.
ДП>Если тест-драйв будет успешным, то к моменту подписания договора будет прототип. ДП>Такие вещи на заказчиков действуют (проверял).
Не на всех. Кто давно в сфере разработки -- прекрасно знает эти фишки.
ДП>И я сомневаюсь, что на заказчика могут подействовать какие-то сложные подсчеты заокеанских перемалывателей чисел.
Как раз эти цифры -- наиболее строгий и объективный метод оценки. А то что вы предлагаете -- это лапшание и распил бюджета.
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>2) Потом думаем как это сделать и разбиваем весь этот процесс на элементарные операции, для каждой из которых легко прикинуть трудозатраты.
Для знакомой, хорошо изученной задачи можно оценить сложность и сроки. Но эта задача, которую уже решали.
Зачем такую задачу второй раз?
Процесс разбиения задачи на подзадачи является самым сложным этапом.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, malkolinge, Вы писали:
M>Здравствуйте, Дмитрий Писаренко, Вы писали:
M>Я не согласен, что у "Наших" производительность труда константна... например, я тоже лучше думаю и работаю по утрам....
M>Тем не менее, скорее всего, у азиатов это как-то может коррелировать с климатом, температурой... Вспомним сиесту (хоть это и не Азия)
Аналогично, но только вечером.
С 16-оо до 21-оо у меня пик производительности.
В 8 утра смотрю на экран монитора как баран на новые ворота.
--------------------
с таким графиком жить очень тяжело, т.к. жаворонки захватили мир.
Всё сказанное выше — личное мнение, если не указано обратное.
Ф>с таким графиком жить очень тяжело, т.к. жаворонки захватили мир.
Не жаворонки, а те, кто умеют работать.
Вы — видимо, не умеете, раз ваши "пики производительности" обусловлены кривым графиком жизни. Ложитесь в 11-12, вставайте в 7 утра каждый день, и через полгода вы будете прекрасно работать с 10 утра до 16.
Не верите?
А в армии все — "жаворонки", и прекрасно работают. В одно и то же жаворонковское время.
Просто они не могут свою лень оправдать словами "да я ваще сова". Отбой — отбой. Подъем — подъем. Человек быстро приходит в норму.
Здравствуйте, SkyDance, Вы писали:
Ф>>с таким графиком жить очень тяжело, т.к. жаворонки захватили мир.
SD>Не жаворонки, а те, кто умеют работать. SD>Вы — видимо, не умеете, раз ваши "пики производительности" обусловлены кривым графиком жизни. Ложитесь в 11-12, вставайте в 7 утра каждый день, и через полгода вы будете прекрасно работать с 10 утра до 16. SD>Не верите? SD>А в армии все — "жаворонки", и прекрасно работают. В одно и то же жаворонковское время.
SD>Просто они не могут свою лень оправдать словами "да я ваще сова". Отбой — отбой. Подъем — подъем. Человек быстро приходит в норму.
Наблюдаю классический случай жаворонкового шовинизма, когда человек в принципе не способен представить себе, что бывают и другие с другим оптимальным режимом.
И не надо рассказывать про армию. Современная армия советско-американско-etc. образца превращает людей в штампованное быдло, используя их потенциал на считанные проценты.
N>Наблюдаю классический случай жаворонкового шовинизма, когда человек в принципе не способен представить себе, что бывают и другие с другим оптимальным режимом.
Ага, разумеется. Назвать меня жаворонком — это сильно
Нет, я тоже ленивый, и тоже мне более комфортно вечерком-ночью посидеть-потупить, утром поспать часиков до 10, потом пойти на работу. Собственно, когда у меня нет внешних факторов в виде жены-ребенка-иных-причин, я к этому режиму и скатываюсь. Но! Дисциплина и самодисциплина: спать — не позже 23:30, вставать — не позже 7:15 — творят чудеса. Все дело в дисциплине. Не в "сове" или "жаворонке".
Сила воли. И дисциплина. Повторяйте это. Не верите? Попробуйте _на практике_. Через полгода можем вернуться к разговору.
Но только — _как следует_ попробуйте. Безо всякого "ну ладно, я вот только сегодня разочек еще дочитаю книгу/досмотрю фильм, и в час ночи спать пойду". И без "дак выходной же, чего в 7 вставать".
Если это так, то делаю очередной facepalm в сторону Китая.
