Нет, там не во времени дело. Я читал как-то давно про эту проблему, точно всё не перескажу, но примерно смысл в том, что там архитектурно у UI-слоя средний приоритет заложен, поэтому какое-нибудь качающееся обновление вполне могло оказаться для системы более важным, чем графический интерфейс ответа на звонок.
Потом, у первых iPhone таких проблем не было насколько я помню.
В общем, это именно архитектурная проблема.
Ну конечно они связаны с архитектурой. С чем же ещё?
Ну очевидно с 1) UX (в меньшей степени) 2) временем выхода на рынок (в большей)
Да, я знаю про PocketPC и Windows Mobile, там был целиком пункт 1. А с WP 8 уже 2, то есть когда всё сделали более-менее по уму, было уже поздно.
А люди, которым некомфортно заниматься разработкой строго по бумажке — сделали Android
В смысле, тот самый Android, который во второй версии жутко начинал тормозить при попытке ответить на звонок (в итоге ответить получалось не всегда, без всяких шуток)? Я то есть не знаю, как там с этим сейчас, но несколько лет назад Android у меня был, говорю со своего личного опыта. Проблем явно архитектурного характера там хватало. Между прочим, система года три на рынке была к этому времени.
У Windows Phone проблемы есть, но связаны-то они как раз не с архитектурой. Во всяком случае, на бюджетном виндофоне у жены проблем со звонками никогда не наблюдалось.
Ну так вы определитесь, либо искусство, либо «не умеют».
Где искусство — там и формальные критерии не нужны. Где нужны, их всегда можно ввести (да, они будут неидеальными, но своё дело делать будут).
Вот и весь мой несложный посыл.
Тогда тем более о чём речь? Правильный менеджер вычислит бездельника и без формальных признаков. Я просто привёл схему, которая точно работать будет (да, со сбоями и недостатками, но бездельников она отсеет).
Ещё раз, прочитайте пожалуйста, с чего начиналась эта ветка и о чём в ней речь.
На всякий случай, упрощаю вам задачу, отвечал я вот на эти два тезиса:
пункт про Эффективность — это описание ситуации, когда человек хочет работать.
А я говорю про ситуации, когда человек «ездит по ушам». В офисе сложно ездить по ушам, на удаленке — просто.
Проблема в том, что в офисе нужно очень мало времени, чтобы поймать сотрудника на раздолбайстве.
На удаленке «профессионал» по ушам может ездить очень и очень долго.
Вы невнимательно читали обсуждение. Речь не о том, чтобы через неделю выдавать что-то сильно полезное. Речь о том, что оценить, работает человек или нет, легко можно и через неделю, а не через несколько месяцев, даже на самом крупном проекте.
Ну просто все обсуждения архитектуры вести через групповой чат или там Slack. Никакого особого формализма, заодно потом и найти легче будет, чем вспомнить, что там кто кому за обедом сказал.
1) А болтать через стол каждые 15 минут комфортно? Мне нет, от работы отвлекает жутко. Кстати очень рад, что больше не приходится.
2) Так я не понял, почему «встречу с участием всех заинтересованных людей» нельзя заменить на «звонок с участием всех заинтересованных людей».
То есть созвониться по скайпу некомфортно, а собрать кучу человек в одном кабинете комфортно?
Как-то не вполне вписывается в мои представления о комфорте.
А почему «реальная задача» обязательно должна означать «сложную задачу»? Первая задача, которую мне дали, состояла в том, чтобы поменять текстовый ресурс.
Задача к слову не вполне элементарная, потому что его нужно было а) найти б) понять, как скомпилировать. Но и не что-то сверхсложное.
Реальная это задача? Да. Можно такую задачу дать через неделю после начала работы? Можно. Можно по ней судить о том, работал человек или нет? Да.
Вы спорите не с моим утверждением, а со своими мыслями на тему.
Если совсем коротко, то вы сейчас всё-таки ведёте речь о возражении №3, конкретно о той части, которая касается удалённого управления командой.
Все эти смешные вопросы «а как я узнаю что человек ничего не делал» (да элементарно) — они возникают только из-за лени управляющего состава, привыкшего работать в конкретных условиях и не желающего приспосабливаться к другим.
Не знаю, какой такой нужен проект, чтобы в него въезжать несколько месяцев.
На первой моей работе (в офисе) я начинал с проекта, над которым трудились сотни человек в течение нескольких лет. Точный объем кода не скажу уже, но думаю можно представить. Например, Visual Studio на таких объёмах вешался, поэтому пользовались только SourceInsight.
На подготовку мне дали неделю, после чего начали выдавать реальные задачи.
Потом, у первых iPhone таких проблем не было насколько я помню.
В общем, это именно архитектурная проблема.
Ну очевидно с 1) UX (в меньшей степени) 2) временем выхода на рынок (в большей)
Да, я знаю про PocketPC и Windows Mobile, там был целиком пункт 1. А с WP 8 уже 2, то есть когда всё сделали более-менее по уму, было уже поздно.
В смысле, тот самый Android, который во второй версии жутко начинал тормозить при попытке ответить на звонок (в итоге ответить получалось не всегда, без всяких шуток)? Я то есть не знаю, как там с этим сейчас, но несколько лет назад Android у меня был, говорю со своего личного опыта. Проблем явно архитектурного характера там хватало. Между прочим, система года три на рынке была к этому времени.
У Windows Phone проблемы есть, но связаны-то они как раз не с архитектурой. Во всяком случае, на бюджетном виндофоне у жены проблем со звонками никогда не наблюдалось.
Где искусство — там и формальные критерии не нужны. Где нужны, их всегда можно ввести (да, они будут неидеальными, но своё дело делать будут).
Вот и весь мой несложный посыл.
Тогда тем более о чём речь? Правильный менеджер вычислит бездельника и без формальных признаков. Я просто привёл схему, которая точно работать будет (да, со сбоями и недостатками, но бездельников она отсеет).
На всякий случай, упрощаю вам задачу, отвечал я вот на эти два тезиса:
такая партиятакой вариант :)2) ну так наш проект примерно для этого :)
2) Так я не понял, почему «встречу с участием всех заинтересованных людей» нельзя заменить на «звонок с участием всех заинтересованных людей».
Как-то не вполне вписывается в мои представления о комфорте.
Задача к слову не вполне элементарная, потому что его нужно было а) найти б) понять, как скомпилировать. Но и не что-то сверхсложное.
Реальная это задача? Да. Можно такую задачу дать через неделю после начала работы? Можно. Можно по ней судить о том, работал человек или нет? Да.
Вы спорите не с моим утверждением, а со своими мыслями на тему.
Нет, проницательность не ваш конёк. Начинал как раз с проектов в несколько сотен человек.
Наш проект примерно из этих соображений и создавался.
Все эти смешные вопросы «а как я узнаю что человек ничего не делал» (да элементарно) — они возникают только из-за лени управляющего состава, привыкшего работать в конкретных условиях и не желающего приспосабливаться к другим.
На первой моей работе (в офисе) я начинал с проекта, над которым трудились сотни человек в течение нескольких лет. Точный объем кода не скажу уже, но думаю можно представить. Например, Visual Studio на таких объёмах вешался, поэтому пользовались только SourceInsight.
На подготовку мне дали неделю, после чего начали выдавать реальные задачи.