Причём тут обман?
Мой комментарий к описанию случая, который, как заявляется «как раз тот, где удобно было обеим сторонам».
Удобство первой стороны (заказчика) в контроле процесса.
Удобство второй — в подтверждении того, что всё потраченное время было занято процессом (ведь так?). Что говорит о том, что финансово выгодно делать подольше, главное доказать потом скринами и трекером. А кто же против финансовой выгоды?
И тут, под новым углом, внезапно становится неудобно всем — заказчик платит за время, а не за результат, разработчик это время тратит на написание ботов.
Ну старое доброе «скажи мне, как ты будешь меня оценивать, и я скажу, как я буду себя вести».
То есть работая при таких правилах выгодно выполнять задачу очень долго, но постоянно держа открытые рабочие приложения на экране и водя по ним мышкой (набирая какой-то текст), а не сделать максимально быстро любым приемлемым способом?
Ну чтобы было «удобно» не только заказчику, но и исполнителю выгодно.
Это не печаль и не возмущение, не стоит включать этих менторских интонаций.
Как человек не первый год формирующий команды, и создающий вместе с ними какую-то ценность, могу уверенно утверждать, что «правильно выстроенная система администрирования», основанная на найме постредственных специалистов — иллюзия экономии. Поскольку вся экономия разбивается об операционные расходы раздувающихся средств этого самого администрирования и контроля (больше менеджеров и аналитиков), либо потери от низкого качества, либо и то и другое.
Если конечно речь не о макдональдсе, а действительно интеллектуальном труде
А попытка провести аналогию между людьми и серверным железом вообще впечатляет. Тот же Google почему-то не нанимает по той же системе кучу гастарбайтеров вместо программистов.
ИП или не ИП, а работать с трекером экрана и контролем времени это унижение. Не говоря уж о целом винегрете факторов, убивающих креативность, творческий подход, самоорганизацию и прочие элементы здоровой продуктивности.
И в этом контексте все рассуждения о «свободном ИП против крепостного ТК» кажутся смехотворными.
А было время, когда мне казалось, что кроссовер это и впрямь новое слово в организации рабочего процесса.
Команда кристаллизуется вокруг решения общей проблемы и с учётом человеческих взаимоотношений. А не специальным образом соответствующими кадрами.
Как уже замечено, новые люди либо принимают правила и становятся частью, либо отторгаются.
Такой человек может стать кем угодно, если продолжит развиваться.
Всё зависит от намерения. И объёма того самого «некоторого опыта». DevOps тоже бывают разные.
Спокойно, я усомнился только в вашем убеждении, что для чтения в оригинале надо знать много тысяч слов.
Есть разные книги с разным словарным запасом и я привёл примеры двух авторов, которые в этом плане удобны для начинания, а также вариант адаптации, на мой взгляд, оптимальный для перехода к чтению в оригинале.
И вы предлагаете во избежание одной рутины (лазить в словарь) воспользоваться другой рутиной (обработать весь текст, наделать карточек и заучивать их в течение какого-то промежутка времени), что мне кажется ещё более мучительным, потому я решил озвучить альтернативный вариант.
Если читать с электронного гаджета, то перевод непонятного слова — это 2-3 тапа в экран. Подавляюще большую часть своего словарного запаса я набрал именно переводами текстов, ещё со времён попыток разобраться с биографиями бойцов в Mortal Kombat. По крайней мере при попытке постичь текст есть интерес и фокус, которого в случае с карточками достичь сильно труднее.
И не все слова вообще требуется переводить, часть угадывается по контексту уже понятого.
Это не значит, что я отвергаю ваш вариант, как минимум он очень применим для просмотра фильмов, поскольку там как раз неудобно лазить в словарь (я вот просто распечатывал титры и переводил перед просмотром первые разы). Так что не знаю, кто вас минусует и почему.
P.S.: результат — at least 11,300 English word families!
Но читать первые книги (как раз «Бойцовский клуб» одной из первых) я начал в pre-intermediate ещё, когда уровня хватало только для чтения коротких статей и инструкций на айтишную тему.
Не надо много тысяч слов для чтения в оригинале. Не выбирайте британских классиков, читайте Чака Паланика или Дрю Карпишина.
После одной книги, адаптированной по методу Ильи Франка (оригинал + перевод с небольшими пояснениями), я теперь читаю художественную литературу спокойно. На неё я убил, правда почти два месяца, потому что Джером К. Джером, как раз один из британских классиков, но словарный запас пополнился очень мощно.
До этого прочитал пару книг неадаптированных, было тяжело из-за необходимости лазить в словарь по N раз на странице. Но даже этот тяжёлый формат сильно практичнее повлиял на расширение словарного запаса, чем заучивание слов.
Кстати, ряд слов я научился воспринимать и понимать не переводя, просто по контексту (he nodded, he shook his head..). А с некоторых пор стал использовать толковый словарь для ряда слов, особенно если не спешу. Потому что корректный перевод не всегда возможен.
Заучивание слов (использовал карточки, мобильные приложения и Lingua Leo) — самый бесполезный и непродуктивный вариант освоения языка. 90% забывается ввиду неиспользования и отрыва от контекста. И как тут уже не раз заметили в комментариях, заучивание слов по карточкам почти не помогает распознавать их в речи и использовать при письме (потому что не дают представления о грамматике и формах использования). Я уж молчу про всякие «Every now and then» и «fooling around»
Мне кажется, предыдущий оратор имеет ввиду, что вашим постам недостаёт содержательно-побудительной части.
То есть каких-то выводов и рекомендаций.
Без которых статья, на непосвящённый взгляд, воспринимается как «смотрите, как мы шутканули и сделали смешные картинки».
Следующая фраза непроста даже просто для понимания, не говоря уж о том, чтобы увидеть тут преимущество.
. Например, теперь можно пропустить некоторые будущие проверки для уже устраненных проблем, которые ранее вызывали сообщение об ошибке.
Из того, что пробилось сквозь критические барьеры, вызванные PR-стилем, можно сформулировать что-то типа «мы исправили ряд ошибок в нашем продукте, и теперь некоторые вещи работают как задумывалось. И это прорыв!».
Возможно и так. Но как-то проще стоило, наверное, донести это.
Если новоиспечённый работник подобно вам позаботился об обретении опыта до выпуска из учебного заведения, то он тоже получает выигрышное положение. Как минимум, может выбирать стажировку.
Кстати, с обретением большого и глубокого опыта в какой-то узкой сфере, например Enterprise решении какого-то вендора, вопрос смены работы становится не менее трудным, чем для стажёра. А может и более. Ну это так, отвлечённое размышление. Возможно, больше касается ИТ pro, а не разработки.
Как по мне, вышеприведённые примеры актуальны и для простой смены работы.
Никогда нельзя быть уверенным, что получишь приходя что в «молодую динамично-растущую компанию», что в крупную корпорацию, «зарекомендовавшую себя на рынке».
В изрядной степени это зависит от самопозиционирования, конечно, но иногда система прочнее.
Тогда это уже не Scrum.
Насколько я помню, в книге «Scrum» специально много раз обращается внимание, что не может быть никакой охоты на ведьм.
«Чем ты занимался?», «Чем ты планируешь заниматься» и «Что тебе мешает в твоей деятельности»?
Никаких «Почему так медленно?»
Задача менеджера — устранять помехи, а не третировать команду.
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
Сдаётся мне, что либо «внедрятели» скрама в компании не интересовались в чём суть скрама, либо автор статьи, либо и те и другой.
Скрам, как он описан в одноимённой книге от его основателя, ставит именно людей (команду) на первое место.
Менеджер не может приоретизировать UserStory. Менеджер не может давить сокращением сроков, требовать отчёта о потерянном времени, и заниматься прочими псевдоуправленческими глупостями.
По сути, scrum/agile — продолжение старых добрых идей Листера и Демарко о кристаллизации команд.
То что у нас внедряется под видом agile — старое доброе линейное гуано в новой обёртке и с новыми терминами.
В немалой степени потому что мало кто имеет интерес к чтению матчасти, всех тянет сразу внедрять в продакшен.
Мой комментарий к описанию случая, который, как заявляется «как раз тот, где удобно было обеим сторонам».
Удобство первой стороны (заказчика) в контроле процесса.
Удобство второй — в подтверждении того, что всё потраченное время было занято процессом (ведь так?). Что говорит о том, что финансово выгодно делать подольше, главное доказать потом скринами и трекером. А кто же против финансовой выгоды?
И тут, под новым углом, внезапно становится неудобно всем — заказчик платит за время, а не за результат, разработчик это время тратит на написание ботов.
Ну старое доброе «скажи мне, как ты будешь меня оценивать, и я скажу, как я буду себя вести».
Ну чтобы было «удобно» не только заказчику, но и исполнителю выгодно.
Как человек не первый год формирующий команды, и создающий вместе с ними какую-то ценность, могу уверенно утверждать, что «правильно выстроенная система администрирования», основанная на найме постредственных специалистов — иллюзия экономии. Поскольку вся экономия разбивается об операционные расходы раздувающихся средств этого самого администрирования и контроля (больше менеджеров и аналитиков), либо потери от низкого качества, либо и то и другое.
Если конечно речь не о макдональдсе, а действительно интеллектуальном труде
А попытка провести аналогию между людьми и серверным железом вообще впечатляет. Тот же Google почему-то не нанимает по той же системе кучу гастарбайтеров вместо программистов.
— Недякин — «Искренний сервис»
(подпишусь под каждым словом)
И в этом контексте все рассуждения о «свободном ИП против крепостного ТК» кажутся смехотворными.
А было время, когда мне казалось, что кроссовер это и впрямь новое слово в организации рабочего процесса.
Безотносительно остальной статьи, вот это предложение для меня говорит о многом.
Как уже замечено, новые люди либо принимают правила и становятся частью, либо отторгаются.
Всё зависит от намерения. И объёма того самого «некоторого опыта». DevOps тоже бывают разные.
Есть разные книги с разным словарным запасом и я привёл примеры двух авторов, которые в этом плане удобны для начинания, а также вариант адаптации, на мой взгляд, оптимальный для перехода к чтению в оригинале.
И вы предлагаете во избежание одной рутины (лазить в словарь) воспользоваться другой рутиной (обработать весь текст, наделать карточек и заучивать их в течение какого-то промежутка времени), что мне кажется ещё более мучительным, потому я решил озвучить альтернативный вариант.
Если читать с электронного гаджета, то перевод непонятного слова — это 2-3 тапа в экран. Подавляюще большую часть своего словарного запаса я набрал именно переводами текстов, ещё со времён попыток разобраться с биографиями бойцов в Mortal Kombat. По крайней мере при попытке постичь текст есть интерес и фокус, которого в случае с карточками достичь сильно труднее.
И не все слова вообще требуется переводить, часть угадывается по контексту уже понятого.
Это не значит, что я отвергаю ваш вариант, как минимум он очень применим для просмотра фильмов, поскольку там как раз неудобно лазить в словарь (я вот просто распечатывал титры и переводил перед просмотром первые разы). Так что не знаю, кто вас минусует и почему.
P.S.: результат — at least 11,300 English word families!
Но читать первые книги (как раз «Бойцовский клуб» одной из первых) я начал в pre-intermediate ещё, когда уровня хватало только для чтения коротких статей и инструкций на айтишную тему.
После одной книги, адаптированной по методу Ильи Франка (оригинал + перевод с небольшими пояснениями), я теперь читаю художественную литературу спокойно. На неё я убил, правда почти два месяца, потому что Джером К. Джером, как раз один из британских классиков, но словарный запас пополнился очень мощно.
До этого прочитал пару книг неадаптированных, было тяжело из-за необходимости лазить в словарь по N раз на странице. Но даже этот тяжёлый формат сильно практичнее повлиял на расширение словарного запаса, чем заучивание слов.
Кстати, ряд слов я научился воспринимать и понимать не переводя, просто по контексту (he nodded, he shook his head..). А с некоторых пор стал использовать толковый словарь для ряда слов, особенно если не спешу. Потому что корректный перевод не всегда возможен.
Заучивание слов (использовал карточки, мобильные приложения и Lingua Leo) — самый бесполезный и непродуктивный вариант освоения языка. 90% забывается ввиду неиспользования и отрыва от контекста. И как тут уже не раз заметили в комментариях, заучивание слов по карточкам почти не помогает распознавать их в речи и использовать при письме (потому что не дают представления о грамматике и формах использования). Я уж молчу про всякие «Every now and then» и «fooling around»
В своё время изложил свой опыт изучения английского в статье "Как выучить английский если вы интроверт"
То есть каких-то выводов и рекомендаций.
Без которых статья, на непосвящённый взгляд, воспринимается как «смотрите, как мы шутканули и сделали смешные картинки».
Горсть полезной информации прячется в мешке инфомусора.
Что такое
?
Следующая фраза непроста даже просто для понимания, не говоря уж о том, чтобы увидеть тут преимущество.
Из того, что пробилось сквозь критические барьеры, вызванные PR-стилем, можно сформулировать что-то типа «мы исправили ряд ошибок в нашем продукте, и теперь некоторые вещи работают как задумывалось. И это прорыв!».
Возможно и так. Но как-то проще стоило, наверное, донести это.
Кстати, с обретением большого и глубокого опыта в какой-то узкой сфере, например Enterprise решении какого-то вендора, вопрос смены работы становится не менее трудным, чем для стажёра. А может и более. Ну это так, отвлечённое размышление. Возможно, больше касается ИТ pro, а не разработки.
Никогда нельзя быть уверенным, что получишь приходя что в «молодую динамично-растущую компанию», что в крупную корпорацию, «зарекомендовавшую себя на рынке».
В изрядной степени это зависит от самопозиционирования, конечно, но иногда система прочнее.
Насколько я помню, в книге «Scrum» специально много раз обращается внимание, что не может быть никакой охоты на ведьм.
«Чем ты занимался?», «Чем ты планируешь заниматься» и «Что тебе мешает в твоей деятельности»?
Никаких «Почему так медленно?»
Задача менеджера — устранять помехи, а не третировать команду.
Сдаётся мне, что либо «внедрятели» скрама в компании не интересовались в чём суть скрама, либо автор статьи, либо и те и другой.
Скрам, как он описан в одноимённой книге от его основателя, ставит именно людей (команду) на первое место.
Менеджер не может приоретизировать UserStory. Менеджер не может давить сокращением сроков, требовать отчёта о потерянном времени, и заниматься прочими псевдоуправленческими глупостями.
По сути, scrum/agile — продолжение старых добрых идей Листера и Демарко о кристаллизации команд.
То что у нас внедряется под видом agile — старое доброе линейное гуано в новой обёртке и с новыми терминами.
В немалой степени потому что мало кто имеет интерес к чтению матчасти, всех тянет сразу внедрять в продакшен.